Alterantives to posting estimation results (ereturn)

[JanDitzen]

For a while I am thinking of a better way to post estimation results of my user written commands. Most of my commands are written in Mata and I find the ereturn capabilities sometimes limiting. In particular when it comes to returning large matrices, string matrices, transformed data (for example different residuals, outcomes of MCMCs) or set of results. In addition if I want to use ereturn(), it requires some additional coding.

My solution so far is to use Mata's array functions. For example for my program called "myprog" it returns a mata array "myprog" which then has a key called "N" for the number of observations, "T" for time periods, "res" for residuals etc. I find this solution quite handy because I can write mata subprograms which can alter the contents of the array or add keys. Also I can write predict or estat programs which use the array.

My question is: does anyone have experience using arrays or maybe even a better solution?

[Maarten Buis]

The advantage of using standard output is that the user knows what to expect and Stata knows what to expect. A big advantage of Stata is that its syntax and its output is very standardized. This makes it easy to learn new commands, unlike other programs like SPSS or R. This level of standardization also allows Stata to provide standard post-estimation commands.

There are always special circumstances that might justify deviating from the standard, but as a general rule I would say don't do that.

[Sebastian Kripfganz]

I am sympathetic to Jan's thoughts and I raised this before at a Wishes&Grumbles session. The problem I often encounter is that some postestimation commands (estat ...) may use some nonstandard intermediate results from the estimation command. There are different ways to deal with this:

1. Return a lot of additional hidden estimation results that can be accessed by the postestimation commands. Yet, this may not be very efficient in terms of speed or memory usage and involves a good chunk of extra code.
2. Re-compute the relevant intermediate results by the respective postestimation command. This is obviously not efficient either.
3. Similar to Jan's idea with a Mata array, my estimation commands often create a Mata structure and I then just return the name of that Mata structure with ereturn. The postestimation commands can then access all the intermediate results stored in that Mata structure. The problem here is: That Mata structure will not be preserved by estimates store or if someone clears the Mata memory. Also, if the postestimation command is doing a comparison among several estimates from the main estimation command, then you need to give that Mata structure a unique name. The downside of the latter approach is that running the estimation command a lot of times, say in a Monte Carlo simulation, will consume a lot of memory if you not not manually drop the Mata structures that are not needed any more.

My suggestion to StataCorp was to introduce something like ereturn mata, but I believe this may not be so straightforward to implement.

[Richard Williams]

I use ereturn all the time in my programs. But, if you want something possibly simpler, check out Ben Jann's estadd command, available from SSC.

The problem I often encounter is that some postestimation commands (estat ...) may use some nonstandard intermediate results from the estimation command.

Perhaps check to see if results you are interested in were returned rather than ereturned.

For example, somebody asked me how to store results produced by estat gof after running sem. The code would be something like

sem ...
estat gof
scalar rmsea = r(rmsea)
estadd scalar rmsea = rmsea

[Leonardo Guizzetti]

I have a related problem for a program I'm currently writing. Is there a way to return estimates by ereturn but suppress the usual p-value calculation based on the null value of 0, or supply a default null value, or custom p-value? If not, then I have to report my results a different way, but it would be nice to use solve of the existing machinery if I could.

[JanDitzen]

Thank you all for your comments. I do agree, the output should be standard in the sense that the user and Stata know what to expect. Of course using ereturn ensures compatibility with many other commands and I will always keep using it for this purpose. But the framework Stata offers (ereturn or similar) is often a bit limiting. The main purpose would be an internal method to save intermediate results for later use, very similar to ereturn hidden. However ereturn hidden comes with the restrictions of ereturn as Sebastian Kripfganz pointed out very well. I thought of structures, but I believe the limitations would be very similar to arrays.

Leonardo Guizzetti I believe you are thinking of the tables produced by ereturn display? You might need to create the table yourself. I have done it in the past and would be happy to share the code, just drop me a DM.