[Alexandre Cazenave-Lacroutz]

Save mistakes from us, we recently showed that there are estimation mistakes in xtregar, FE and we suggested solutions: Please see
https://github.com/ACL90/rho_xtregar...ons_v1_0_0.pdf
I am aware that these are not big changes but:
1- Maybe our corrections could be taken into account?*
2- The documentation of xtregar could also be made clearer. (if you are not convinced of that, ask to a few people (that does not know the sourcecode of the command and that are outside StataCorp) what e(sigma_e) is.)

*As we modified xtregar code (that is a Stata official command), I do not know if we can freely share the code of our modifications online. But we can send it if asked.

[Enrique Pinzon (StataCorp)]

To all interested, we would like to clarify that there is nothing incorrect in our implementation of xtregar, fe. In his paper, Alexandre proposes a new method which differs from the one in the documentation for our command.

[Alexandre Cazenave-Lacroutz]

Thank you Enrique for highlighting it, as my message was imprecise. There is indeed nothing incorrect in the sense that the xtregar,FE command does indeed what the Stata documentation explains, and which might be the current common practice (namely, applying the Baltagi-and-Wu transformation before differentiating). However, save a mistake from us, although the Baltagi-and-Wu transformation is well-adapted to the random-effects AR(1) model (ie. xtregar,RE), we show that it is not well adapted to the fixed-effects AR(1) model (xtregar, FE). This may cause a bias in the various estimated quantities. Happily, we are able to propose consistent estimators for all parameters.

In case our consistent estimators cannot be implemented by StataCorp as long as our working paper above is not published somewhere, I will make available soon on my Github page the ado-file that I now use instead of xtregar.

PS: To all interested in those issues, note that in another working paper, we show that there is a similar phenomenon with the estimation of the autocorrelation coefficient, particularly in the unbalanced case. And we already proposed an implementation of our new estimation method for the autocorrelation coefficient. See ssc install rho_xtregar. (or go to my Github page for the lattest version)
https://github.com/ACL90/rho_xtregar...sturbances.pdf
(As there is still work on this working paper, I did not even dare to suggest it for Stata17.)

PS2: @Enrique: On the wish list, I still think that the documentation of xtregar could be improved regarding what e(sigma_e) means.

[Jean-Claude Arbaut]

Alexandre Cazenave-Lacroutz

Regarding your doubts about your rights to distribute your modified code, the Stata license states that:

2.5 License to StataCorp Enhancements.
Subject to the terms and conditions of this Agreement, StataCorp grants to Customer a non-assignable, nontransferable, royaltee-free license, without the right to sublicense, to use the StataCorp Enhancements solely with the Software for Customer's internal business, research, or educational purposes. In addition, subject to the terms and conditions of this Agreement, StataCorp grants to Customer a non-assignable, nontransferable, royaltee-free license to modify, reproduce, and distribute the StataCorp Enhancements to create Customer Enhancements solely for use with the Software. Customer may distribute the Customer Enhancements to third parties either at no charge of for a fee.

StataCorp Enhancements means, among others, ado files distributed with Stata.

So it seems you can distribute your modified xtregar. A good question, however, would be: under what type of license? I leave this to StataCorp to clarify. Enrique Pinzon (StataCorp)

---

It's an occasion to mention another problem regarding license and Stata programs. A common way to distribute Stata software is via SSC, and you may contact Kit Baum at Boston College to publish code there. However, I don't remember seeing any licensing terms in packages at SSC, which is not very satisfying. Compare to the (good) practice of always specifying the license on CRAN...

A related post, without an explicit answer either: st: RE: license type of user-written ado files on SSC. However, contrary to what this post seems to suggest, a program with no license information is absolutely not in the public domain - or even open source. See Open source code with no license… can I fork it? So, while StataCorp encourages reusing code, most SSC packages can't in fact be legally reused.

[Niels Henrik Bruun]

1. I often need to look into the code in ado and mata files. I would like the -Mata/Stata which- command to have an option open sending the ado file to the do-file editor. In the case of mlibs I think we to develop concepts like unit-testing and/or help files describing the content. Too much (including my own code) is too little documented. I am thinking in developing a concept like docutils from Python.
2. We need more than one "end", a mata-end and now also a Python-end. Having the same keyword ending different sets of code is bad.
3. In Mata I would suggest that optional parameters in function calls can be called by name and not just by position. And that default values for optional parameters can be set in the function header. Again, inspiration is from Python
4. I think for really being able to develop scientific concepts into Mata a sort of operator overload for classes is needed. In Stata, we know that the difference between two dates is the number of dates and adding an integer to a date gives another date. In a sense it is nonsense adding numbers and dates, but it is intuitively easy to understand. This kind of math exist in more places. Eg in finance an yieldcurve which offers prices at all times could be multiplied to a cashflow (a set of future payments at certain dates). Basically, this is the simple price times amount formula hidding the date matching behind. In statistics, all sorts of regression outputs are stochastic variables. Often we eg subtract these variables to get the effect. Could it make sense to define subtraction of two fractional polynomials? I know that for some of this we have lincom etc, but that is for Stata. And I don't think that it is flexible enough for what is comming
5. The final Pythonic suggestion is that in Python you have __main__, so if Python code in a file is called as a main program one can set up a set of commands to be done. Often the structure in larger analyses is to have a master do-file running a set of minor do-files. These minor files needs testing, which could be run in a slightly different environment (using eg only a subset of data).

That said, I think Stata and Mata are fantastic tools to work with
So thank you to Stata Corp and all contributors in the Stata environment

[Alex Weckenman]

I would love to have more functionality in putdocx, especially around posting summary statistics and other types of tables. Similarly, it would great to augment putexcel so it can post tables and other outputs as they appear within Stata without having to recreate them via matrix operations and alignment (e.g., for tab results, having to do matrix operations to get column/row percentages, having to loop through a matrix to post the variable levels).

[Sebastian Kripfganz]

I just discovered that there is no possibility to tell the regress postestimation command estat ovtest for Ramsey's RESET test the order of the powers of the fitted values I want to use. The command uses by default powers 2 to 4 of the fitted values and there is no option to change that. It should be easy to add an option that allows specifying that I only want powers, say, up to order 3.

[Jen Walker]

Merging and appending frames

[Clyde Schechter]

Re #68: merging frames is accomplished easily using the -frlink- command and then the -frget- command or -frval()- function. If you need to save the results of a merge you can then do that. As for appending frames, that has been discussed earlier in this thread and there is already a user-written command to do that, but I agree it would be nice for Stata to include it as part of the installation.

[Friedrich Hula]

I would like to see a function that creates treemaps like in Excel, but in Stata beauty.

[Nicholas Winter]

Small tweak to -marginsplot- : an easy-to-use option for relabelling the legend keys based on the logical plot number, rather than the actual plot number of the underlying call to -graph-. Marginsplot plots first the confidence intervals, then the point estimates, which means that the legend key for the n'th plot is actually k+n, where k is the total number of plots. (see, e.g., post #6 on this thread: https://www.statalist.org/forums/for...mbomarginsplot ).

[Vivek Gupta]

Two Wishlist items
1. Ability to switch working directory to the directory where the do file is located. It would help in situation where the entire folder with the DO and DATA files is shared with someone else. No need to cd into different directories in different computers. In other word, the DO wil executes based on path relative to the location of the do file
2. Ability to embed graphs in the SMCL file. This way the SMCL file upon opening can directly show the graph and makes it so much easier for someone who is just reading the results.

Thanks
Vivek

[JanDitzen]

Two Wishlist items
1. Ability to switch working directory to the directory where the do file is located. It would help in situation where the entire folder with the DO and DATA files is shared with someone else. No need to cd into different directories in different computers. In other word, the DO wil executes based on path relative to the location of the do file

This would be great and helpful, even for programmers. In particular to know where a certain do file is located. I think it was already mentioned and discussed.

An easy workaround with limitations for this (if the paths are know) is to create a local for each user and use capture when loading data. I combine this with the local c(username) when I have different usernames for different PCs I am working on, but the folder structure is the same. For example, say two researchers work on the same do file which uses contents from a specified ado file and one of the researchers works on different machines with the same folder structure (like a shared folder like dropbox etc.). Then this works well:

local path1 "C:\Users\\`c(username)'\Dropbox\My Resarch Folder\"
local path2 "C:\Research2\Random Research Folder\Subfolder Shared\"

cap adopath + "`path1'\ado"
cap adopath + "`path2'\ado"

cap cd "`path1'"
cap cd "`path2'"

This works fairly well, of course only within its limitations.

Two Wishlist items
2. Ability to embed graphs in the SMCL file. This way the SMCL file upon opening can directly show the graph and makes it so much easier for someone who is just reading the results.

I really like this idea. In particular if it would be extended to sthlp files as well. Also, it might be nice to have the Greek alphabet or symbols and sub and superscripts in sthlp. This would make any mathematical equations much easier to read and understand.

[Leonardo Guizzetti]

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

[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.)