[Jean-Claude Arbaut]

Many of us are using a wide variety of user written procedures to write to word or excel. To me, the Stata provided procedures to do this look very complex. I wonder if a simpler option might be presented in the documentation.

There is an option: use the new Python integration to either open an Excel file with openpyxl, or connect to Excel with Pywin32 and COM (aka Automation), then use VBA-like commands to control Excel and, for instance, change the formatting or add plots. Here is an example of the latter.

[Clyde Schechter]

I have grown rather fond of frames in Stata 16. It would be convenient to have any command that includes a -saving()- option also support putting the results in a new frame. I imagine that being implemented as a suboption to the -saving()- option, something like -saving(file_or_frame_name[, asframe replace])-. It would be more convenient than writing several lines of code saving the data in a file and then creating a new frame and reading in the file, and it would eliminate some disk thrashing (especially if the command is in a loop that gets a lot of repetition).

[Mike Zyphur]

Stata's MP initiative has made great processing speeds gains, but substantially more can be done. In the previous wishlist thread for Stata 16 I mentioned the value of offering a version of Stata that would allow GPU processing, such as with the convenient, generalizable, and free ArrayFire library for CUDA and OpenCL (it also works for CPU processing). However, the problem can be tackled by allowing users the option of FP32 computing (i.e., single precision floating point). This could drastically speed up processing for various tasks. Indeed, FP16 is being used in a variety of cases where precision is not overly relevant in AI applications. Being able to choose FP32 calculations would probably be easier as a Stata modification, and certainly it would be the least expensive way for users to achieve faster Stata computing.

[Tony Li]

Stata 16 permits the following two frame put syntax:


frame put varlist, into(newframename)
frame put if exp, into(newframename)

I wish we can use the following syntax in Stata 17:


frame put varlist if exp, into(newframename)

[Tony Li]

for frlink, i wish we can use frame link, like frame copy, frame put

[daniel klein]

This is a repost of my earlier request:

Give us an option that forces mi impute chained to continue if one of the conditional models fails to converge in one (or any other specified number of) iteration(s).

What is the problem? Multiple imputations via chained equations (mi impute chained) often fail because one of the models, usually mlogit, fails to converge. This is really annoying if it happens after hours (or even days) in, say, iteration 7 on m=42.

What do I want? I want mi impute chained to skip this one iteration in which the model did not converge, instead of terminating the complete process and throwing away the 41 successfully imputed datasets. Ideally, I want a (model specific) option that allows me to specify the maximum number of unsuccessful iterations that I am willing to skip over if the model does not converge.

Why do I want this? By iteration 7 on m=42, the respective model will have converged about 400 times or more (using the default of 10 iterations * 41 datasets); chances are the model will converge again in the next iteration. While I am not sure whether skipping over unsuccessful iterations yields valid results, I believe that it is still preferable to what is currently the only alternative: modify the predictors in the respective model. Modifying the respective model will (negatively) affect every iteration in every imputed dataset. Skipping over a couple of iterations will (slightly) affect the updating process before the respective dataset is imputed.

Best
Daniel

[jerome falken]

- ipython as python "prompt"
- support ";" as a command separator, support single line foreach (i.e. foreach i in 1/10 { di `i' } ) for more compact code.
- (much) faster contour plot
- tsline must support a _large_ number of observations, not just display an empty graph if the number of obs is significantly large.
- support longer variable names (don't translate/truncate them after 32 chars, instead, make it 128-256 chars or even something larger, maybe user-defined limit), I understand there's some controversy around this; but I have datasets that could use that.

thank you

[jerome falken]

+ the possibility to "browse" different frames simultaneously.

[jerome falken]

+ the possibility to interrupt a running python session, currently the only option is to force quit stata.

[Bryant Be]

Super small request:

Some documentation of the difference in standards among "basic" regex functions

 regexm, regexr, regexs

and the more powerful Unicode regex functions

 ustrregexm, et al

Even noting *that* they are different at all may be quite useful.

Inspired by a question I posed here: https://www.statalist.org/forums/for...question-marks

And a link to the description of the standard (which seems quite a bit more capable!) here: http://userguide.icu-project.org/strings/regexp

[Jan Brogger]

Make summdate unnecessary. summarize and codebook should respect the formats %td and %td.

[Andrea Discacciati]

clear
input str10 date
"2019-08-12"
"2018-05-22"
"2001-01-19"
end
gen date2 = date(date, "YMD")
format date2 %td

summarize date2, format detail

[wbuchanan]

Bryant Be
It might be useful if you could clarify more specifically what you are wanting in terms of difference in standards between the regex functions. The help file for the original regex functions make a reference to "Henry Spencer's NFA Algorithm...that is nearly identical to the POSIX.2 standard" and states explicitly that it is only intended for use with ASCII text. There was a post a few years ago here on Statalist that referenced the underlying library used for the unicode regex work that isn't mentioned in the manuals/help files. Would including that reference in the help files be sufficient for your request?

[Bryant Be]

Sure. I can definitely clarify. The only source I can easily google which explains how the basic (?) regex functions work (e.g., regexm and friends) in Stata is this one:

https://www.stata.com/support/faqs/d...r-expressions/

The set of functions listed at this web page:

http://userguide.icu-project.org/strings/regexp

is much larger.

Just for comparison, if I do:

    gen test1 = regexm(note_text, "\.(?!\d)")
    gen test2 = ustrregexm(note_text,"\.(?!\d)")

The regex in the first command maybe isn't even valid? I get the message:

 regexp: ?+* follows nothing

a few thousand times on my data, and the variable

 test1

is zero for all rows.

The second command w/ the same regex executes without any problem (or: without the maybe-error-message from the prior command) and

 test2

is 1 about 60% of the time (on the same data).

At the very least then it seems to me that the two commands generate different outputs for the same regex. I don't know if the negative lookahead (?!...) construction is valid with

 regexm

or if something else is wrong. This is surely worth explaining. (FWIW: the text I'm using is pure plain text w/ no fancy characters outside the ASCII set AFAIK.)

[Santosh Dash]

I would appreciate it if the following features are added in Stata 17.
1. Panel unit root tests with a structural break
2. Time series unit root tests with two structural breaks such as Narayana and Popp (2010), Lee and Strazicich (2013, 2003)
3. Dynamic panel threshold models such as Bick (2010), Kremer et al. (2009)

Thank you.