[Fahad Mirza]

Would be nice to have Stata beautify its visual output with a modern default scheme and a diver color palette and tone range. Another thing i would love to see is Stata make available the changes we make in graph editor as a code once we close the window so that we can save and use it later. Similarly, i am not sure if there are good 3D graph options however would be nice to see those as well.

[John Mullahy]

While with a bit of effort it is possible to trick twoway into doing this, it would be valuable if it could have easily implemented options to produce scatter (and other) graphs where the displayed data can appear in any of four quadrants around specified origins (or x- and y-axis choices) that define the center of the visualization. E.g. familiar pictures of a Cartesian plane centered on (0,0).

[shem shen]

I wish xtile and by can be compatible

[FernandoRios]

I wish xtile and by can be compatible

Hi Shem,
While not exactly what you ask for, there is an "egen" function extension (ssc install egenmore), that allows you to do something like what you describe:

sysuse auto
 egen mpg5 = xtile(mpg), by(foreign) nq(5)
 tab mpg5 foreign

[Clyde Schechter]

Now that we have frames in Stata 16, it would be nice to be able to do a few more things with them. For example, it would be nice if the -saving()- option of any command that has such an option could be expanded to "save" the results in a new frame rather than writing to mass storage. And it would be nice to be able to do -joinby- with a frame. (Even better would be if -rangejoin- worked with a frame as its -using-, though I realize that's not even an official Stata command.)

[Sebastian H]

Further expansion of discrete choice capabilities:
- ability to obtain conditional parameters from panel mixed logit models (similar to the mixlogit command from Arne R. Hole)
- ability to use Sobol and MLH draws when estimating panel mixed logit models
- allow integration of latent variable (SEM) in panel mixed logit models
- panel latent class logit model (such as lclogit2) including the possibility to impose class-specific constraints
- hierarchical Bayes estimation of panel mixed logit models
- ability to specify utility function for panel mixed logit models to allow for complex models (e.g. integration of scale heterogeneity)

[Bert Lloyd]

A request for putdocx and some of the other reproducible research commands:

I wish there were an easy way to tell putdocx "please put whatever the screen output of the following command would be", even if only for simple commands like summarize, codebook, etc. I can usually approximate using putdocx table and the like, but it seems like a lot more effort and my results are (usually) not as nice as what Stata already gives us.

So, something like

putdocx outputof summarize mpg, detail

[Adrien Bouguen]

Two annoying things:

- When I run a complex command (that takes some time to run), the do file related to the output window is frozen. Yet, when I open another do file, I can easily write without restriction. I was wondering if Stata 17 could not make sure that the do file never freezes (since I am able to open a new dofile, I imagine that this is not a computing limitation) so that I can continue working while my command runs. Right now I often save my dofile before running a computing-demanding command and then open the same do file on another stata window which makes my life complicated and be the source of errors (like erasing part of my code)

- When I try to open a ado file with the do file editor instead of opening the do file, stata tries to open it as if it was a do which generates an error. It is annoying.

[Joro Kolev]

Can the linear GMM estimator in -ivregress gmm- be made a bit more flexible? E.g., it would be nice if it:

1. Has -onestep- option.
2. Has the option to calculate the estimator at a user defined weighting matrix.
3. Has the option of whether the first step is done with the identity weighting matrix, invsym(Z'Z), or any user specified matrix.

[Sebastian Kripfganz]

Can the linear GMM estimator in -ivregress gmm- be made a bit more flexible? E.g., it would be nice if it:

1. Has -onestep- option.
2. Has the option to calculate the estimator at a user defined weighting matrix.
3. Has the option of whether the first step is done with the identity weighting matrix, invsym(Z'Z), or any user specified matrix.

With the standard weighting matrix, the onestep estimator is simply the 2SLS estimator. I believe the situations where someone needs a different weighting matrix are rather rare. You can always use the gmm command to achieve this task.

[Joro Kolev]

Substituting non-linear, numerical optiminsation estimator, for a linear closed form estimator does not always work, Sebastian.

This is illustrated in this thread
https://www.statalist.org/forums/for...-is-this-a-bug
to which I never received a satisfactory answer. Stata Technical Support replied:

"-sureg- and -nlsur- use different algorithms for the underlying
computations, and so with borderline cases, for example with models that
are only weakly identified, results may not necessarily be the same. In
the case of your example, it looks like -nlsur- (with default
optimization settings) has problems fitting all the parameters as can be
seen from the missing standard error of the intercept from the first
equation. However, with well identified cases, they should generally
yield equivalent results:" (they proceed with an example where with strong identification, you get the same results).

With the standard weighting matrix, the onestep estimator is simply the 2SLS estimator. I believe the situations where someone needs a different weighting matrix are rather rare. You can always use the gmm command to achieve this task.

[John Mullahy]

RIght now one can do this:

twoway (scatter y x if x<5, mcol(blue) msym(d)) (scatter y x if x>=5, mcol(orange) msym(o))

Something like this would be nice:

twoway scatter y x, mcol(blue if x<5, orange if x>=5) msym(d if x<5, o if x>=5)

[Nick Cox]

John Mullahy I don't think StataCorp will ever allow if (or in) qualifiers within options and FWIW I don't support that idea.

sepscatter from SSC -- see https://www.statalist.org/forums/forum/general-stata-discussion/general/3803-sepscatter-available-from-ssc -- helps with some of these problems but does not improve on the first syntax you cite.

[John Mullahy]

re: #358 Thanks Nick. I was not aware of -sepscatter- which I see can be helpful in some instances.

I thought my request was a longshot in any event, and I suppose I can appreciate your reservations. But I'm wondering if those reservations would be any different were a new nomenclature implemented, e.g.

twoway scatter y x if x<10, mcol(blue when x<5, orange when x>=5) msym(d when x<5, o when x>=5)

or whether there's a more fundamental concern given the way -twoway- options operate.

[wbuchanan]

John Mullahy
Along the lines of what you are requesting, I think it could be handled more efficiently/effectively if it were possible to map aesthetic attributes to data values. In that case, your example above could potentially be created like;

qui: g str6 color = cond(x < 5, “blue”, “orange”)
qui: g str1 shape = cond(x < 5, “d”, “o”)
tw scatter y x if x < 10, mcol(color) msym(shape)

Since the purpose of using colors/shapes in visualizations is to encode information present in the data visually, it seems logical/reasonable for StataCorp to handle the aesthetic properties of the glyphs/marks in a way that is consistent with the way positions are handled (e.g., by mapping values in the data and/or computation to the visual representation).

That all said, I imagine this would require a non-trivial amount of effort to accomplish but would also make the data visualization capabilities much more comparable to capabilities in other software (e.g, Tableau, ggplot2, D3.js, Qlick, PowerBI, etc...).