[Chen Samulsion]

Something big is coming! Something big is right around the corner! Wow~

[JanDitzen]

I think it is more likely Stata 18. Stata 17 was released in April 2021, so following their 2 year cycle, it would be time for Stata 18 this month!

[Leonardo Guizzetti]

Hmmm… thank you. Maybe it’s version 17.1?

[John Mullahy]

Re #674 Leonardo Guizzetti Not sure but I received ominous email from Stata this afternoon

Something big is right around the corner. We have some exciting news coming your way next week that you won't want to miss.Be sure you're among the first to know by signing up for text alerts.

[Leonardo Guizzetti]

It looks like it may be time to start the v19 Wishlist.

Is Stata 18 coming out already?

[John Mullahy]

It looks like it may be time to start the v19 Wishlist.

[Nick Cox]

Sorry; I still disagree. It’s not a matter of being for or against or more or less sympathetic to experienced users or beginners (I have done quite a lot to support beginners in various ways). Once the same syntax is interpreted differently in different contexts you are straight on the road to coding perdition. But you don’t have to convince me; you have to convince StataCorp.

Different difficulties: this is not even programmable without raising massive difficulties of principle. What other exceptions do you want? How does this play when existing users are tripped up by a change to behavior?

[Stephen Weinberg]

Nick,

Thank you very much for replying. To clarify, I am NOT suggesting a different syntax for DB or command lines!!! I am suggesting a change to the way the DB translates user entries into syntax.

If a dialog box has a blank for a string item, like a title, and the user enters Hello, World
then instead of translating this into syntax as title(Hello, World)
I was suggesting it would go in as title(`"Hello, World"')

Though this would keep more sophisticated users from entering multi-line titles directly into the DB. That might be an acceptable tradeoff, since such users should also know how to edit the syntax, but maybe they just really need the GUI's to have more tips hidden behind question marks for people who don't know what they're doing.

I get Stata's commitment to serving sophisticated users, but if there is any place that should assume the user is a newbie, it is the dialog boxes.

#662



I am sympathetic to anyone bitten by this, and it happens to me too, but here the solution is worse than the problem. It's not going to happen, but the idea that syntax rules might vary according to whether you are using a dialog or a command line is a terrible principle.

[John Mullahy]

Re: #668: Not a perfect solution but I sometimes use:

sysuse auto

qui gmm (price-exp({xb:mpg _cons})), inst(mpg) igmm vce(robust) winit(i) quickderivatives
gmm

which gives

. sysuse auto
(1978 automobile data)

.
. qui gmm (price-exp({xb:mpg _cons})), inst(mpg) igmm vce(robust) winit(i) quickderivatives

. gmm

GMM estimation

Number of parameters =   2
Number of moments    =   2
Initial weight matrix: Identity                   Number of obs   =         74
GMM weight matrix:     Robust

------------------------------------------------------------------------------
             |               Robust
             | Coefficient  std. err.      z    P>|z|     [95% conf. interval]
-------------+----------------------------------------------------------------
         mpg |  -.0434544   .0091973    -4.72   0.000    -.0614808   -.0254281
       _cons |   9.623275   .2025457    47.51   0.000     9.226293    10.02026
------------------------------------------------------------------------------
Instruments for equation 1: mpg _cons

.
end of do-file

[Clyde Schechter]

Re #667:

- Include all documentation for native commands in help files, users shouldn't have to download a PDF.

I disagree strongly. I think Stata has done an excellent job of picking out for the help files the things that are needed in the vast majority of situations. If the help files contained the full documentation they would be long, and unwieldy to search through to find the specific details you want when you are trying to code or debug. The full documentation is only needed in a minority of situations, and it is good that it is kept separate. Moreover, you don't have to download any PDFs for the documentation: you already have them--they are part of your Stata installation.

- Export tools to easily generate publication quality tables across formats. Almost every user I know still relies on an almost 20 year old SSC package to make tables.

What are you looking for that version 17's -table- and -collect export- commands don't give you?

[Sebastian Kripfganz]

It's probably too late to propose additions for Stata 18 (which could be there any minute), but anyway:
The gmm command does not appear to have a nolog option for supressing the iteration log. This would be a useful addition.

[Mike Murphy]

Personal wishlist:

- Overhaul error messages & add debugging. A common experience is running a large loop, getting "invalid syntax" and then having to either go through line by line or set trace on.
- Include all documentation for native commands in help files, users shouldn't have to download a PDF.
- Export tools to easily generate publication quality tables across formats. Almost every user I know still relies on an almost 20 year old SSC package to make tables.
- Significantly increase limit on variable name length

[John Mullahy]

As an alternative to defining new twoway schemes to accommodate customization (or always defining the same set of locals) would it be possible to allow various twoway options to be set "permanently" so that they would override whatever defaults are defined in any scheme a user might select?

I'm sure each user has their own idiosyncratic preferences on such options. Not that my preferences should matter but among those I would "set permanently" if I could are

set fintensity 100, permanently

and

set plotregion margin zero, permanently

Alternatively, and to the same effect, could such settings be specified in "Graph preferences"?

[Nick Cox]

#662

For the dialog box for graphing, if someone enters text that has a comma (e.g. in the title), this should NOT cause everything to crash, please, because Stata ends up parsing the comma as trying to add an option to the title. The text entered in dialog boxes should default to being put in quotes `" "'. I enjoy the teaching mileage I get by showing students this common way to break things, but I'd rather db work as I would expect it to. Maybe assume people using the GUI's aren't power users?

I am sympathetic to anyone bitten by this, and it happens to me too, but here the solution is worse than the problem. It's not going to happen, but the idea that syntax rules might vary according to whether you are using a dialog or a command line is a terrible principle.

[Abdullah Algarni]

Hope to see:

1. Multifractional polynomial support of mixed-effect model
2. Documentation be available online in html format (just like R)