[Chen Samulsion]

Thank you Nick Cox. For users who is forbidden by sagepub, Nick's article is: dm0116 Speaking Stata: Nine notes on dealing with dates and times, DOI: 10.1177/1536867X251341416

[Raymond Guiteras]

Thank you Nick Cox. For users who is forbidden by sagepub, Nick's article is: dm0116 Speaking Stata: Nine notes on dealing with dates and times, DOI: 10.1177/1536867X251341416

For me, the paper is gated on the SJ site but appears to be open access on Sagepub:

https://journals.sagepub.com/doi/10....6867X251341416

[Nick Cox]

It should be open access to all. https://journals.sagepub.com/doi/pdf...6867X251341416 is what I also recommend as a link.

[Chen Samulsion]

Why inlist(z,a,b,...) restricts the number of arguments between 2 and 10 for strings?

[Ryan Sandler]

I'd request an increase to the name length limit for stored estimates (currently required to be a valid variable name at 32 characters). While I'm sympathetic to the view that 32 characters is plenty for an actual variable name (but also see #56 and #58 in this thread for an alternate view), that logic doesn't really apply for stored estimates, which are infrequently used directly in code, and have names that are often constructed via macro loops when running several related estimations.

With -estimates store- insisting on tacking "_est_" onto the front of the name for internal naming purposes, all it takes to blow the 32-character limit is a name based on a modestly-long human-readable outcome variable name, and a couple of reasonably short suffixes for alternate specifications. A 16-character variable name, two 5-character suffixes for different specifications, plus underscores separating them, plus the 5-character "_est_" prefix and you're at 33 characters.

The amount of time I've wasted over the years re-running programs with regressions stored in a loop because I missed a place where the resulting estimate name hits 35 characters is not worth thinking about. Yes, there are any number of hacks one can do to fix the issue, abbreviating suffixes, removing underscores, renaming variables etc., generally at the cost of readability, but to me the point is that there doesn't seem to be a good reason to have to do any of this. Even an 80 character limit for estimation names paired with keeping the 32-character limit on variable names would probably resolve most issues.

[George Hoffman]

this has been brought up in various threads, but some way to save gtraph customizations and apply them when wrting a commadn to produce a graph. possible options:
1. in graph editor, a tab which would trasnlate customizations into the options to be appended to the grapgh statement. this would update in real time as the graph was customized. then moving to the 'options' tab would show the list of customization options to be copied.
2 - a commadn line tool to extract these customizations from an existing .gph file and copy to the clipboard?

i understand that the .gph file can be opened to disclose these details, but these steps are cumbersome especially when working in a differnt workspace environment (like Jupyterlab) that calls Stata in the background.
if this already exists i apologize for the request and waste of people's time.
thx

[John Mullahy]

Regarding point 2 in #171:

The undocumented command gs_fileinfo

help gs_fileinfo

returns among other things the command that produced a saved .gph graph.

It suspect that it would be straightforward to extract as a substring everything in this string that sits to the right of the comma (i.e. the options).

sysuse auto

tw scatter price mpg, msy(o) mco(blue) plotreg(marg(zero))

graph save agraph.gph, replace

gs_fileinfo agraph.gph

di r(command)

Returns:

. sysuse auto
(1978 automobile data)

. 
. tw scatter price mpg, msy(o) mco(blue) plotreg(marg(zero))

. 
. graph save agraph.gph, replace
file agraph.gph saved

. 
. gs_fileinfo agraph.gph

. 
. di r(command)
twoway scatter price mpg, msy(o) mco(blue) plotreg(marg(zero))

[Nicholas Winter]

Ability to render fonts' programming ligatures in the Stata windows.

Programing ligatures are a font feature that allows multi-character programming symbols, such as '<=', to be displayed as a single glyph (e.g., ≥).

I use Sublime Text rather than the Stata editor, and I've created a bespoke version of Fira Code with ligatures to display Stata's compound double-quotation marks distinctly. Unfortunately, Stata doesn't have a way to turn on this font feature in its own windows, but if it did these sorts of ligatures might be really helpful for folks. Note the `" and "' in the sample below (rendered in red). Also note the >= rendered on the third line--this is the default Fira Code ligature for this symbol.

[Nigel Moore]

This is coming from a non-statistician working in the biological sciences. So, beware numptiness!

It is a reality of my work that most of the people I interact with, including regulators, are not statisticians. But we have certain ways of doing things, and expectations; and unbalanced datasets are a fact of life. That said, my wishlist pretty much concentrates on parametric and nonparametric postestimation methods:

• PARAMETRIC
  • Dunnett's test to cover unbalanced data sets out of pwcompare (apologies if this has been added, I've seen no reason to upgrade from 14...yet)
  • Williams' test
• NONPARAMETRIC
  • Steel's test (NP equivalent of Dunnett)
  • Shirley's test (NP equivalent of Williams)
  • Dwass Steel Critchlow Fligner test

[Dave Airey]

I don't think Stata implements any what you mentioned. An R package PMCMRplus implements many solutions for oneway designs, including all five you mention: dunnettTest, williamsTest, shirleyWilliamsTest, steelTest and dscfAllPairsTest. Given this source, and original papers, it should be possible to have Stata equivalents.

I do sometimes use the ssc command "pwmc" which implements good solutions for oneway designs with unequal variances.

This is coming from a non-statistician working in the biological sciences. So, beware numptiness!

It is a reality of my work that most of the people I interact with, including regulators, are not statisticians. But we have certain ways of doing things, and expectations; and unbalanced datasets are a fact of life. That said, my wishlist pretty much concentrates on parametric and nonparametric postestimation methods:

• PARAMETRIC
  • Dunnett's test to cover unbalanced data sets out of pwcompare (apologies if this has been added, I've seen no reason to upgrade from 14...yet)
  • Williams' test
• NONPARAMETRIC
  • Steel's test (NP equivalent of Dunnett)
  • Shirley's test (NP equivalent of Williams)
  • Dwass Steel Critchlow Fligner test

[Rasool Bux]

I wish to add command running status as % in status bar rather running a circle. I mean how I can see the progress of current running command/group commands/session of a do file. Currently the stat just showing that the command/session is in process as running circle in the status bar. It will be helpful to display the % completed of the current session/command with the running circle.

Thanks & best regards,
Rasool Bux

[Richard Williams]

I wish to add command running status as % in status bar rather running a circle. I mean how I can see the progress of current running command/group commands/session of a do file. Currently the stat just showing that the command/session is in process as running circle in the status bar. It will be helpful to display the % completed of the current session/command with the running circle.

Thanks & best regards,
Rasool Bux

That is an interesting idea and would be great if you could do it, but I wonder if Stata really knows that? Like, how can it know if a command will take 5 iterations to converge, or 50? How can it know how long a command that is still 5 lines away from even being started will take? You can do things like showing the iteration log or setting trace on to see exactly where things are at, but I'm not sure if even Stata can tell that, say, the job is 60% completed.

[Dave Airey]

Coming back to #174, Nigel Moore Claude Code was able to rapidly port those tests from the R package PMCMRplus to Stata+Mata code, create a validation report, and a help file (<10 min). Sometimes when you port a code file, it doesn't validate the method, only the port so we need to be careful. This is why the original source materials and human domain expertise is important. I have found that Claude is quite good at going from R code to Stata code, but relatively less good (but not bad) at de novo coding solutions in Stata vs R.

[Rasool Bux]

That is an interesting idea and would be great if you could do it, but I wonder if Stata really knows that? Like, how can it know if a command will take 5 iterations to converge, or 50? How can it know how long a command that is still 5 lines away from even being started will take? You can do things like showing the iteration log or setting trace on to see exactly where things are at, but I'm not sure if even Stata can tell that, say, the job is 60% completed.

Dear Richard, I agreed and got this idea from the recent update of "14-Oct-2026" of use command for a large dataset. I think the same way if a command takes a long time i.e. loop etc from the do file than if it shows the % complete to get an idea of progress not stuck program/command.

Best regards,
Rasool Bux