[daniel klein]

The problem in #86 and the workaround in #87 remind me of a wish that I have stated at a Users Group Meeting a couple of years ago: make nclass programs respect r() results.

The problem is that many commands, e.g., graph save, do not return anything in r(). Yet, these commands call other commands, e.g., file, that do store contents in r(). As a result, previous results in r(), e.g., from margins, are wiped. Stata programs can already be declared nclass (i.e., declared to return nothing) but that does not seem to have any effect at all. I wish that nclass preserves r() (and e(), and perhaps even s()) results. Do this under version control or add a qualifier-syntax, e.g., nclass(preserve {r|e|s})to make sure that code continues to work.

Returning to #86, a solution that presreves both e() results from the estimation command and r() results from margins, is

tempname rr
_return hold `rr'
_return restore `rr' , hold
commands that wipe r()
_return restore `rr'

See

help _return

Best
Daniel

[Clyde Schechter]

I'm not sure exactly why this happens, but if you add the -post- option to your -margins- command, you will still be able to run -marginsplot- again after saving the graph that -marginsplot- creates. I don't know why -graph save- interferes with it in the first place, but -margins, post- seems to overcome that limitation.

[George Hoffman]

this should be simple (?):
if i run margins, followed by marginsplot - great.
if i re-run marginplot with different options (such as noci, axis range, etc), - great
but if i save the generated graph and try to re-generate the graph - go go
previous command was not margins
r(301)

for complex analyses, it may take many minutes or even hours to regenerate margins.
does saving the graph really destroy results of the last margins command to make marginsplot not work?

[Rich Goldstein]

re: #1 in #84 - please see

help cformat

I have no idea what is meant by the second point in #84

[Chris Martin]

I love Stata overall but here are a few enhancements that would make it better:

1 Schemes for output akin to the graph schemes. A lot of researchers want two decimal places for t statistics and coefficients and three for p values for which they want three. Others may want three. Either way a quick way to specify this would be nice. Some sort of native outreg command along with schemes would be good too. If I want to publish an APA style table, it would be nice if I could just specify a couple of options in the main regression command and not rely on outreg.

2. Something the like the PROCESS model that Preacher and Hayes created for SPSS and SAS--a single command that could be used to generate a test as PROCESS does with rich output showing you everything you need to know about the model.

[Joseph Coveney]

One of my wishes is to have the ability to append non dta files like xlsx or csv without having to save it as dta file first.

I don't have any problem with that, but if it bothers you, then you can import from Excel workbooks without having to save anything. Just use Stata's suite of commands for ODBC, as illustrated below. Begin at the "Begin here" command; the top part is just to set up an Excel workbook with two worksheets for illustration.

.ÿ
.ÿversionÿ16.0

.ÿ
.ÿclearÿ*

.ÿ
.ÿsetÿseedÿ`=strreverse("1530251")'

.ÿquietlyÿsetÿobsÿ3

.ÿ
.ÿgenerateÿbyteÿridÿ=ÿ_n

.ÿgenerateÿdoubleÿvanÿ=ÿruniform()

.ÿformatÿvanÿ%04.2f

.ÿgenerateÿstr1ÿvacÿ=ÿchar(64ÿ+ÿruniformint(0,ÿ26))

.ÿ
.ÿquietlyÿexportÿexcelÿusingÿTest.xlsx,ÿsheet(First10)ÿfirstrow(variables)ÿreplace

.ÿlist,ÿnoobs

ÿÿ+------------------+
ÿÿ|ÿridÿÿÿÿvanÿÿÿvacÿ|
ÿÿ|------------------|
ÿÿ|ÿÿÿ1ÿÿÿ0.48ÿÿÿÿÿGÿ|
ÿÿ|ÿÿÿ2ÿÿÿ0.89ÿÿÿÿÿOÿ|
ÿÿ|ÿÿÿ3ÿÿÿ0.03ÿÿÿÿÿLÿ|
ÿÿ+------------------+

.ÿ
.ÿquietlyÿreplaceÿridÿ=ÿ_Nÿ+ÿ_n

.ÿquietlyÿreplaceÿvanÿ=ÿruniform()

.ÿquietlyÿreplaceÿvacÿ=ÿchar(64ÿ+ÿruniformint(0,ÿ26))

.ÿ
.ÿquietlyÿexportÿexcelÿusingÿTest.xlsx,ÿsheet(Next10)ÿfirstrow(variables)

.ÿlist,ÿnoobs

ÿÿ+------------------+
ÿÿ|ÿridÿÿÿÿvanÿÿÿvacÿ|
ÿÿ|------------------|
ÿÿ|ÿÿÿ4ÿÿÿ0.86ÿÿÿÿÿXÿ|
ÿÿ|ÿÿÿ5ÿÿÿ0.43ÿÿÿÿÿGÿ|
ÿÿ|ÿÿÿ6ÿÿÿ0.86ÿÿÿÿÿIÿ|
ÿÿ+------------------+

.ÿ
.ÿdropÿ_all

.ÿ
.ÿ*
.ÿ*ÿBeginÿhere
.ÿ*
.ÿlocalÿdsnÿExcelÿFiles;DBQ=Test.xlsx;DefaultDir=`c(pwd)';

.ÿ
.ÿodbcÿload,ÿ///
>ÿÿÿÿÿÿÿÿÿexec("SELECTÿ*ÿFROMÿ[First10$]ÿUNIONÿALLÿSELECTÿ*ÿFROMÿ[Next10$];")ÿ///
>ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿdsn("`dsn'")

.ÿ
.ÿformatÿvanÿ%04.2f

.ÿlist,ÿnoobsÿseparator(3)

ÿÿ+------------------+
ÿÿ|ÿridÿÿÿÿvanÿÿÿvacÿ|
ÿÿ|------------------|
ÿÿ|ÿÿÿ1ÿÿÿ0.48ÿÿÿÿÿGÿ|
ÿÿ|ÿÿÿ2ÿÿÿ0.89ÿÿÿÿÿOÿ|
ÿÿ|ÿÿÿ3ÿÿÿ0.03ÿÿÿÿÿLÿ|
ÿÿ|------------------|
ÿÿ|ÿÿÿ4ÿÿÿ0.86ÿÿÿÿÿXÿ|
ÿÿ|ÿÿÿ5ÿÿÿ0.43ÿÿÿÿÿGÿ|
ÿÿ|ÿÿÿ6ÿÿÿ0.86ÿÿÿÿÿIÿ|
ÿÿ+------------------+

.ÿ
.ÿeraseÿTest.xlsx

.ÿ
.ÿexit

endÿofÿdo-file


.

[Oscar Ozfidan]

One of my wishes is to have the ability to append non dta files like xlsx or csv without having to save it as dta file first. This functionality could be restricted to files that has the same variable list initially later be expanded. I really dont understand why an xlsx file needs to be imported and saved as dta to be able to append it. Perhaps the import command may be modified to bypass that step.

[Clyde Schechter]

In earlier years I have proposed that -merge m:m- be eliminated. StataCorp has not done that. I imagine they have their reasons. So let me suggest a compromise position:

Since what -merge m:m- does is rarely needed in practical applications, change -merge m:m- so that, by default, it functions as a synonym for -joinby-. Allow those who want the old behavior to specify it as an option. ( I would call the option -datasalad-, but perhaps that's too snarky.) Do not sustain the old behavior under version control. I say that because I am willing to wager that for every existing correct application of -merge m:m- in existence there are hundreds if not thousands that are producing incorrect results, and in most cases changing that to -joinby- behavior will actually correct the problem..

[Clyde Schechter]

This should be a simple one, but it would be really convenient: make -fullnames- the default option for -describe-.

[Gio Russo]

I would be really happy if SEM and GSEM suites upgraded to match MPLUS and LATENT GOLD. I also would be happy to see a machine learning suite or data mining suite with trees, random forests,svm, and the likes.

[Victor Smith]

Bootstrapping in stata is too slow. Even for a simple model, stata takes 10 or even more times than it in R, SPSS, SAS, python, and Mplus. Could you make it faster in next version?

[JanDitzen]

To keep my Stata clean I usually have project specific ado paths. When moving from one project to another, I often use accidentally ados from the wrong project. It would be nice to have something like

adopath reset

, which re-sets the ado paths to those when Stata starts.

[Ariel Linden]

I am very excited that v16 includes a suite of LASSO commands. I will continue to beg (from previous wish-lists) that official Stata include a suite of machine learning tools that includes all of the common approaches: regression and categorical trees, random forests, svm, boosted models, etc...

[ericmelse]

Graded marker fill color by the values of a variable (like marker size), also Opacity controlled

The possibility to control the marker fill shading of colors using a variable, in graded steps from a base color, very much like how it is now possible to control the size of markers.

E.g., using the example on page 240 from A Visual Guide to Stata Graphics that uses the file allstates.dta where the size of markers is set by [aweight=propval100]:

use allstates , clear
twoway scatter ownhome borninstate [aweight=propval100], msymbol(o) mfcolor(cyan%20)

I added the parameter mfcolor(cyan%20) to set the symbol fill color to cyan and control the opacity. This renders the graph like:

As such, the above functionality is very nice but now a next improvement could be made to include the option to control opacity by means of its own weight as set by a variable.
I suppose the most simple syntax would be to enable the reference to a variable name after the opacity percentage indicator, like: mfcolor(magenta%ownhome).
To have an idea what this would look like, here is the same graph but with graded color opacity by the data of ownhome:

In this example the 'base color' against which the color is graded is a gray (but it could be white or any other color).
Of course, we need a new parameter to set the base color, something like: mfbcolor(gs10), or like mfbcolor("120 120 120") etc.
The graded scale should then be computed by Stata, preferably with equidistant (visually just) noticeable steps between the marker fill base color and the marker fill color along the data range (scale) of the selected variable for mfcolor.

More sophistication could be possible, but I suppose the mere option to control graded color and opacity, using data of a variable, would be a great visualization enhancement of the functionality to add visual relevant information to markers in Stata graphics.

(Note that a similar wish was written before, by me, on the wishlist for Stata 16: #96 7 Mar 2018, 10:41.)

[Leonardo Guizzetti]

I would second the ability to have a local which stores the current path of the do-file.