[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?

[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

[Jan Brogger]

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

[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

[jerome falken]

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

[jerome falken]

+ the possibility to "browse" different frames simultaneously.

[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

[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

[Tony Li]

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

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

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

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

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

[Phil Bromiley]

It might be desirable to extend xtreg to include multiple fixed effects. I know a user written procedure exists for this, but it seems like something that should be included in the base.

Also, see https://www.statalist.org/forums/for...r-if-condition

It appears Stata does some of the prep work before applying the if or in condition so some things can take a long time to run.

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.

[JanDitzen]

I am not sure how much attention this thread gets from officials, but I have a few thoughts which would make life much easier, especially if one works on parallelising commands in Stata:

1. Extend the functions of frames: I really love frames, they are fast and efficient and I can do a lot with them. However what I find frustrating is that there are a few functions missing. I would wish for an easy append, merge and save function. It would also be helpful to be able to save all frames at the same time (see next).
2. A function to save multiple frames in one file. In a sense mata mata matsave is the equivalent in mata. I know that frames are somewhat datasets, but I think you can think of them as matrices as well (like in other programs).
3. Many commands come with a "saving()" function (eg: simulate, bootstrap, jackknife, permutate) but they can only save a new dataset. They cannot append the dataset or save (or append) to a frame.
4. A function to save an entire Stata environment. With environment I mean macros, scalars, matrices (Stata and mata), Stata and mata functions, locals (?), frames and programs, etc. With saving I mean to clone a Stata "state" which can be picked up by another Stata instance. The background of this wish is that I am working on a parallel version of simulate (yes, another one....) and most of the code is trying to save some of the Stata environment.

All of the functions above can be easily written. In particular for step 1 there are already solutions available. I am working on some of the function in 2 and 3, but they are slow, error prone and require lots of coding and time. On the other hand, if someone from outside Stata can do it, it should be easy for Stata Corp. to work on those functions (I think and hope).