[Ben Jann]

Re #75: You could misuse heatplot for that (from SSC; also requires palettes and colrspace from SSC). Here is an example in which opacity and size of markers is proportional to a variable in the data.

sysuse auto
heatplot displ price weight, discrete stat(asis) scatter size(displ^2) colors(cyan, opacity(20(2)80)) p(mlc(black)) legend(off)

Options discrete stat(asis) scatter make heatplot behave like a regular scatter command (i.e. no binning or aggregation of data, use marker symbols instead of color fields).

Option size(displ^2) makes sizes of marker symbols proportional to the square of variable displ. This is equivalent to specifying [aw=displ^2] in twoway scatter.

Option colors(cyan, opacity(20(2)80)) specifies to use a cyan color gradient with opacity values between 20% and 80% (in steps of 2) based on the values of variable displ (if three variables are specified in heatplot, the first variable will be used for the color gradient).

Here is a second example with a gradient from grey to magenta.

heatplot displ price weight, discrete stat(asis) scatter size(displ^2) colors(gs10 magenta, opacity(50) ipolate(20)) p(mlc(black)) legend(off)

The ipolate() suboption determines how the colors are interpolated; default settings are used here, but the option is quite powerfull; have a look at help colorpalette for details. You can also interpolate across more than two colors.

[Ben Jann]

Correction for #91: I accidentally copied a wrong graph. The first graph has been produced using size(displ^1.5), not size(displ^2).

[Rene Macon]

The general principal should be implemented "All results displayed in the Stata output window should be stored!" such that they are accessible to be transferred in Excel or Word files.

Currently, only a subset of these results is stored (plus a set of results, which are not displayed - which should be kept).

Motivation: The manual transfer of test results in research papers is definitely out of time! In the future more and more users will certainly want to write results like test statistics, critical values and estimated coefficients directly in files that can be easily integrated in research papers.

[Nick Cox]

#93 I can readily think of stuff that goes in the Results window that really should not be stored!

Still, the principle of being able to access results is good. I am interested in where you think Stata misses out here in practice. Also, it is not automatic that results are (strictly) saved results; some results are in effect new data and saving or exporting them as new variables is the way to go.

I note that many users have no interest in MS Excel or Word, but the principle translates to anything else: LaTeX, HTML, XML, etc.

[Rene Macon]

#94 I have currently three examples, where I think certain results should be stored, first because I would need an access and secondly, because there are other tests, where these type of results are stored.

First example is the "dfuller" test, where I found no stored value for the estimated "drift" paramter and the standard deviation of the residauls. I have described the problem here. William found fortunately an undocumented option "certify" in the source code, that solved the problem for the drift parameter. To get the standard deviation of the residuals, I had to manipulate the source code somewhat.

Second example is the "pperron" test, where I could not find access to the critical values of the test statistic "r(Zt)". Fortunately these critical values differ only marginally from those of the "dfuller" test.

Third example is the "dfgls" test, where I do also not find the critical values for the dfgls test statistic. I have described the problem here. Unfortunately, nobody had so far an idea how to solve my problem. I found however an older post from Nora Kaimann with regard to the same problem here. If you have an idea, that would be great...

From an earlier study of mine, I can also remember missing stored critical values for the trace statistics of the Johansen cointegration test, where I could however modify the source code to solve the problem.

[William Lisowski]

#94 Regarding "stuff that goes in the Results window that really should not be stored" I can only think of the horizontal and vertical lines used in formatting tables.

I agree with the general principal in #93, which put another way is that, for a fairly broad definition of what constitutes "results", the generation of results and the presentation of results should be separate issues, and all presented results should be available for other purposes through mechanisms more congenial than copy-and-paste.

Stata had what I think was a brilliant insight when it chose to split out postestimation commands that build on retained estimation results. The principle expressed in #93 is an extension of that logic, motivated perhaps by the problems of presentation but really based in a broader principle of trying to limit as little as possible subsequent use of the results for whatever purpose the user has.

[Niels Henrik Bruun]

I so agree with #93. The basic priciple should always be: If it is worth showing in the log, it is worth reusing (returned in r and/or e as eg matrices). Log output and reuse should be one-to-one.
I also agree with #94 in that the reuse principle should not be limited to microsoft products.
It is far better to split reusing into "returned for further use in frames like estimates and matrices" and exporting these frames easily as said in 96.
Export should be quick and dirty with the possibility of going into details. Splitting "export to excel" into two commands without a Q&D is annoying.

Examples of where this not happening is eg 1) tab2 where cell information isn't returned 2) -summarize- over several variables where only information on the last variable is returned.

I do also think that returned information may returned in a redundant ways as eg r(table) and e(b) are returned from regression.
There can several quite different needs.

[Nick Cox]

#93 on. I thought that counter-examples were obvious but here we go. If I see results of list I really don't want Stata to store those, as they are (with small exceptions) stored already as data. If I fire up display I don't expect the result to be stored either (I can arrange for that directly).

If I quickly fire up summarize for several variables, I don't want results for them all to be saved, as that too can be arranged otherwise.

Otherwise specific examples are helpful here, and let's hope that oversights get corrected.

[Niels Henrik Bruun]

#98 on.
Nick Cox Maybe you are satisfied with -list- and -summarize-.
But I am not.

-list- would be a much better tool if one could subselect variables and (unique) rows by if and in.
And it would very nice if what I extracted with one command could be reused immediately without figuring out how to save it for reuse using af different command.

And likewise for -summarize- : Why is it that is worth printing means etc in the log using -summarize-.
Most of the times I have to report the found results somewhere else afterwards.

[Nick Cox]

I don’t follow all of #99. For example, list certainly supports selection of variables and if and in.

[Niels Henrik Bruun]

Yes, but you can't reuse the extracted from -list-. Sorry for being imprecise

[Sonnen Blume]

A friendlier version of sem. Currently its almost useless as it takes too long and returns many errors for the same data that Mplus caters in a blink.
AND, better description of the errors. Stata errors messages are usually very general and leaves no way to know where things have gone wrong, unlike those in R and Mplus.

[Marcos Almeida]

High density (>= 300 dpi) "for publishing" customized tiff or jpeg graphs. Nowadays I need to save as jpeg, then import in a different sotware so as to convert it to high densitiy graph.

[Clyde Schechter]

Re #101. I don't understand. If you have selected a subset of the data with -if- and -in- conditions, you can apply those conditions to nearly any subsequent command (and the ones you can't are just ones where it wouldn't make any sense). And if you want to retain that subset to work on separately, as of version 16 we can -frame put- them. Am I misunderstanding your meaning here?

[John Mullahy]

[Subtopic: –margins– and –suest–] Given the way -margins- and -suest- are programmed this is perhaps an unreasonable request, but it would be nice to be able to combine a series of posted -margins- results using -suest-. E.g.

(some command)
margins, dydx(*) post
est store e1
(some other command)
margins, dydx(*) post
est store e2
suest e1 e2

Now what one encounters is

. suest e1 e2
e1 was estimated with a nonstandard vce (delta)
r(322);

I don't see why the delta-method computations used by -margins- preclude in principle the combination of multiple stored estimates, but it's quite possible I'm missing something obvious.

Anyway, thanks for at least considering for v17.