[Rich Goldstein]

-ologit- by default uses the lowest value of the outcome variable as its comparator; I would like an option added so that I could choose whether I wanted the lowest or the highest value; yes, I can "fake" this by reversing the order, but this does not quite match what other software does where the default in the other software is to choose the highest value (the cutpoints will have opposite signs using the Stata fix as compared to what the other software is doing) - I realize that this is not generally a big deal but when working with others using different software, it would be very convenieint to easily show them the results match by just changing the comparator (without having to explain the change in signs)

[Julian Reif]

The recode() command has a test option that displays a warning if the recoding rules overlap. It would be nice to have an option that generates an error rather than just a warning.

[FernandoRios]

Something simple, but perhaps useful.
It would be great if margins could store the results in e() without having to type post.
something like:
margins, dydx(x1 x2 x3) estore(m1)
That way, we do not "lose" the previous model, and still store the results for exploration

[John Mullahy]

re: #603. Just last week I stumbled on the fact that –margins– stores its results in r(b) without posting.

sysuse auto
qui reg price mpg i.foreign
margins, dydx(*)
matrix bmarg=r(b)
matrix list bmarg

. sysuse auto
(1978 automobile data)

. qui reg price mpg i.foreign

. margins, dydx(*)

Average marginal effects                                    Number of obs = 74
Model VCE: OLS

Expression: Linear prediction, predict()
dy/dx wrt:  mpg 1.foreign

------------------------------------------------------------------------------
             |            Delta-method
             |      dy/dx   std. err.      t    P>|t|     [95% conf. interval]
-------------+----------------------------------------------------------------
         mpg |  -294.1955   55.69172    -5.28   0.000    -405.2417   -183.1494
             |
     foreign |
    Foreign  |   1767.292    700.158     2.52   0.014     371.2169    3163.368
------------------------------------------------------------------------------
Note: dy/dx for factor levels is the discrete change from the base level.

. matrix bmarg=r(b)

. matrix list bmarg

bmarg[1,3]
                        0b.          1.
           mpg     foreign     foreign
y1  -294.19553           0   1767.2922

[FernandoRios]

#604
I usually rely on the r(table) after margins.
My main reason for this, of course, was as a request I m often asked. How to save "event studies outputs" after csdid.
My solution was to give people the option to store results without losing the main Equation output.
Just wished it was an official option!

[Joro Kolev]

The -save- command is fairly primitive, all one can do is save the whole dataset at hand. It would be very helpful if -save- is made more multifunctional like - use [varlist] [if] [in] using filename- is.

In particular I would like to be able to

1. Save only particular variables from my dataset.

2. Save only particular observations from my dataset, specified in the "if" and "in" conditions.

[Gorkem Aksaray]

Joro Kolev

The -save- command is fairly primitive, all one can do is save the whole dataset at hand. It would be very helpful if -save- is made more multifunctional like - use [varlist] [if] [in] using filename- is.

In particular I would like to be able to

1. Save only particular variables from my dataset.

2. Save only particular observations from my dataset, specified in the "if" and "in" conditions.

This could be a replacement until we have a more able save command:

ssc install frapply
sysuse auto, clear
frapply in 1/30 if price > 6000: keep price |> save hiprice

[Miguel Henry]

Sparse matrix capabilities (e.g., dgCMatrix)as a built-in command.

William Gould's book (https://journals.sagepub.com/doi/epu...36867X19874262) discusses sparse matrices on pp. 736 and 737 but as a guide to implementing sparse matrices rather than providing a built-in Stata sparse matrix command.

[Leonardo Guizzetti]

I don’t find this use of frapply to be any more clear or succinct than the few equivalent lines of Stata code that would be required. Also, it’s dangerous to combine in and if modifiers in the same command as they do not always play nicely together or as one may expect.

[Gorkem Aksaray]

Leonardo Guizzetti Fair enough. I personally like to be able to manipulate current frame and put it somewhere else (as I can in R or Python) without the frames housekeeping. OP was about saveing in one line instead of in multiple lines. Also, you may be right about the in and if modifiers, but those directly come from frame put, which is an official command.

[Bruce Weaver]

As discussed in this thread, there is no direct and easy way to use some of the alternative covariance structures (ACSs) Lesa Hoffman illustrates in Chapter 4 of her 2015 book on Longitudinal Analysis. I would like to see more ACS options for -mixed- similar to the options available in both SAS and SPSS.

• For SAS options, see Table 65.17 here
• For SPSS options, see this page

Cheers,
Bruce

[Haoran Liu]

Auto fill.

e.g., I just tried to read a csv file into Stata,

import delimited using "xxx.csv", clear

but I found it takes too long to read, so I'd just read the first 10 rows. Then I tried another option, but I can only recall the grammar vaguely

import delimited using "xxx.csv", clear row???

If Stata can tell me the correct grammar should be

rowrange([start][:end])

it would be really nice, so I don't have to check the help.

[Daniel Feenberg]

I don’t find this use of frapply to be any more clear or succinct than the few equivalent lines of Stata code that would be required. Also, it’s dangerous to combine in and if modifiers in the same command as they do not always play nicely together or as one may expect.

-frapply- does have the advantage of being about 3 times as fast, or at least it was in an experiment I just ran. A bigger issue is that -if-, -in- and varlist are (nearly) language wide standards. Using a different syntax for -save- and -use- lacks a business purpose. Uniformity and consistency will ease learning and shorten programs.

I would like to endorse the original suggestion by Kolev that the -save- statement be upgraded with the same qualifiers that most other non-I/O commands recognize. I/O commands -insheet-, -outsheet- -xmluse-, -import sasxport- and -save- don't allow any of those (the -varlist- option in -infile- does something different). The new -import delimited- replacement for insheet has -rowrange- (a limited -in-) and -colrange- (a limited varlist). I fear Stata that may be a policy for new procedures leaving us with two competing standards within the same language.

Almost every reply in this "Wishlist" thread to any suggestion is of the form - "That isn't needed, Stata is already Turing complete". There isn't any way to offer support for a suggestion, other than a new message, which is less than optimal. I hope this doesn't give Statacorp the impression that no one other than the original poster favors any of the suggestions in the Wishlist, but I fear that it does. Perhaps some mechanism that didn't clutter the mailing list for showing support could be implemented? A vote counter of some sort?

[Leonardo Guizzetti]

-frapply- does have the advantage of being about 3 times as fast, or at least it was in an experiment I just ran. A bigger issue is that -if-, -in- and varlist are (nearly) language wide standards. Using a different syntax for -save- and -use- lacks a business purpose. Uniformity and consistency will ease learning and shorten programs.

I don't have anything against -frapply- or its author., I was simply expressing my opinion of what seemed easier to do (and read) with standard language commands. -frapply- looks like a useful command borrowing a concept from R, but it also contradicts your desire to have uniformity and consistency by introducing "pipes" into the syntax, which are a foreign concept to the Stata and Mata languages.

I did not have this experience that -frapply- was faster, it was consistently ~50% slower than the equivalent frame commands with this toy example. Further, -frame put- already supports -if- and -in-.

sysuse auto, clear

timer on 1
frapply in 1/30 if price > 6000: keep price |> save hiprice1, replace
timer off 1

sysuse auto, clear

timer on 2
frame put price in 1/30 if price > 6000, into(hi)
frame hi: save hiprice2, replace
frame drop hi
timer off 2

timer list

Result

. timer list
   1:      0.02 /        1 =       0.0230
   2:      0.02 /        1 =       0.0160

I would like to endorse the original suggestion by Kolev that the -save- statement be upgraded with the same qualifiers that most other non-I/O commands recognize. I/O commands -insheet-, -outsheet- -xmluse-, -import sasxport- and -save- don't allow any of those (the -varlist- option in -infile- does something different). The new -import delimited- replacement for insheet has -rowrange- (a limited -in-) and -colrange- (a limited varlist). I fear Stata that may be a policy for new procedures leaving us with two competing standards within the same language.

Agreed, there's nothing wrong with upgrading such commands to have more similar syntax so that there is consistency.

[William Lisowski]

#613 Daniel Feenberg -

Almost every reply in this "Wishlist" thread to any suggestion is of the form - "That isn't needed, Stata is already Turing complete".

No. those replies suggest workarounds that some readers of the thread may not have considered, in the spirit of being helpful and providing a forum in which readers can learn from the experiences of others.

I hope this doesn't give Statacorp the impression that no one other than the original poster favors any of the suggestions in the Wishlist, but I fear that it does.

Your "fear" suggests a lack of faith in the professionalism in the Stata developers. My experience does not support that. I think they're capable of getting what they need from this thread as it stands.

Perhaps some mechanism that didn't clutter the mailing list for showing support could be implemented? A vote counter of some sort?

Oh, please, no. Stata development isn't a popularity contest. A camel is a horse that was designed by a focus group. I prefer a product with a consistent vision that surprises me with commands like frames, the new table, and collect, that meet needs I didn't know I had in ways beyond what I would have envisioned.