[Jesse Wursten]

A few little things I'd like (or may be unaware that exist):

1. Find-Replace in do-editor tells you how many instances of the find term were replaced.
2. Option to open multiple do-files from explorer window in one editor window rather than one Stata instance per do-file. I don't really want to have to create .stpr files for that purpose.
3. Option to set do file preferences (e.g. font/colors) permanently (this may already be an option--I just haven't seen it if it exists).
4.

inlist()

command that can hold more than 10 string vars directly rather than having to loop or use multiple or statements.

FYI, you can drag dofiles from the explorer window into the editor window and it will add them to the existing dofile editor window.

[Mike Murphy]

I would like built-in support to export tables to Excel & LaTeX.

[Philip Jones]

I would like an iOS version to be able to run Stata 16 on my iPad. Now before you think this is a crazy request, consider most of my work is now done on an iPad pro, which has more computing power than most laptops. In fact, one of the only reasons I use my laptop now is to run Stata. Would love for StataCorp to consider this as I think there would be more users wanting this than would be anticipated at first glance.

[Mike Murphy]

Not splashy, but investing time in making error messages more informative would probably have large returns for most users.

[Mike Zyphur]

Hi Stata team,
On the point of speed-ups in Stata, it is worth considering GPU computing (GPGPU), perhaps using the simple and easy-to-learn ArrayFire library and API: https://arrayfire.com/.

Originally funded by DARPA, it's entirely free and can be automatically compiled for Nvidia's CUDA, OpenCL on AMD and Intel chips, as well as for multi-core CPU computing (as well as FPGA and ARM chips found in many devices today). Conveniently, this approach would not require learning low-level programming in CUDA or OpenCL, which can be tedious, while then being stuck in only one of these approaches and its associated hardware. Instead, using ArrayFire would offer a huge performance boost for anyone with a reasonably fast video card (or cards), allowing Stata to run on Amazon Web Service EC2 instances that are GPU focused, but also automatically reverting to CPU processing whenever this is detected as being faster. Thus, a single version of Stata could be written and distributed to users, which would then automatically take advantage of the user-specific hardware that's detected.

Anyway, something to consider! The ArrayFire library has a wide variety of ways to speed up existing code, even that which is optimized for multi-core CPUs, including by allowing parallel 'gfor' loops. To make Stata 'big data' capable, something like this will be essential.

Cheers,
Mike

[Chen Samulsion]

I would like Stata 16 provide matrices of exp(b), i.e. odds ratios, relative-risk ratios, incidence-rate ratios in ereturn list for logit, mlogit, Poisson and other models as like.

[Jesse Wursten]

I would like Stata 16 provide matrices of exp(b), i.e. odds ratios, relative-risk ratios, incidence-rate ratios in ereturn list for logit, mlogit, Poisson and other models as like.

I think you can do this by specifying eform? See help eform.

[Donovan Pollack]

Export/Write to Microsoft Powerpoint

[Weiwen Ng]

I think you can do this by specifying eform? See help eform.

If Samulsion wants to directly work with the e(b) matrix, then I don't think eform will work, because I don't think the underlying matrix gets transformed. However, two responses are that he could manipulate the e(b) matrix in mata, and also why would you want to manipulate the e(b) matrix yourself? A number of user-written programs will write exponentiated results to Excel or other files (e.g. estout, available on SSC). Furthermore, you can write the r(table) matrix, which has all the transformed coefficients, to Excel with putexcel if you want to.

[Giovanni Colitti]

Because I would like to use Bayesian modeling for prediction, I would appreciate enhancements to -bayesmh- post estimation to make it easier to get the expectation of the posterior predictive distribution. The attached link accomplishes what I'm talking about, but I'm envisioning a simple post estimation command that can effortlessly be applied to different models.

[George Ford]

egen xres = resample(x)

creates a new series xres that is a random sample of x. options would include:
1. with or without replacement (, permute)
2. resample in blocks of integer N (, block(N))
3. includes or exclude missing values (, dropna)
4. weights options
5. a similar command to resample an entire matrix


-summ- for matrices

[Weiwen Ng]

In the absence of Stata buying MPlus, I would like to see some additional postestimation statistics added for latent class/profile methods. Normalized entropy and sample size-adjusted BIC would be convenience features. You can program SSBIC quite easily, discussed more below. There was some recent discussion on how to do entropy as well.

I would particularly like to see an implementation of the Lo-Mendell-Rubin adjusted likelihood ratio test. This compares a model with K classes with a model with K-1 classes; the difference in -2*log likelihood does not follow the usual chi square distribution for reasons I don't understand but the linked article explains. Then, automating the bootstrapped LR test described in the paper linked would be very nice. It appears that the bootstrapped LR test is the current gold standard for model selection.

...

Updating my prior request. I'd like to drop my request for the LMR likelihood ratio test. A simulation study revealed that in cases where classes are poorly separated and some indicators load on multiple classes - which is probably what a lot of real life situations will involve - the LMR LR test had high false positive rates, and it was outperformed by straight up BIC and the boostrapped LR test.

I'd like to reiterate my request for the bootstrapped LR test to be included in Stata 16, and for model entropy to be calculated (perhaps after estat lcprob, or as its own command).

Stata 15 can't currently estimate models with both categorical and continuous latent variables, as far as I know, and I'd like to make that a request. The categorical latent variable is, obviously, a latent class. A continuous latent variable could be something like a random intercept for a group. Do this, and you will enable multilevel latent class analysis, mixture item response theory models, mixture models involving random effects in general, and untold other wonders.

[John Mullahy]

Cross-posting this William Lisowski post on "Promotion Problems" to the Wishlist since it concerns some issues that Stata 16 developers might wish to address.

https://www.statalist.org/forums/for...otion-problems

[Joro Kolev]

egen xres = resample(x)

creates a new series xres that is a random sample of x. options would include:
1. with or without replacement (, permute)
2. resample in blocks of integer N (, block(N))
3. includes or exclude missing values (, dropna)
4. weights options
5. a similar command to resample an entire matrix


-summ- for matrices

Permuting a variable, and "bootstrapping" (sampling with replacement) a variable are super easy, see Ängquist, Lars. "Stata tip 92: Manual implementation of permutations and bootstraps." Stata Journal 10, no. 4 (2010): 686. It is not in the article, and I have not thought it through in detail, but doing it in blocks does not sound hard either.

How do you mean -summ- for matrices? I believe I know how to do with with -matrix accum-, if what I think if what you have on your mind.

[Clyde Schechter]

We frequently get questions on the Forum about unexpected problems arising with string variables that turn out to be due to the presence of non-printing characters. Data imported from spreadsheets or word processing documents frequently contain such characters. They are not visible in -list-ings and other routine ways of viewing the data, but they often trip up the programmer. They are certainly a plague I deal with often. Whlie it is not all that complicated to write a loop over these and use -subinstr()- to remove them one at a time, it would sure be convenient to have a single function call that purges them all in one fell swop. Perhaps that could be accomlished by expanding the scope of "whitespace" removed by ustrtrim(), or perhaps there are Unicode related reasons why that would not be a good idea. But it should be possible for StataCorp to write some function that does this, no?