[Cem Payaslioglu]

Wish list for next Stata:

1. Linear Feedback for Poisson /NegBin Panel. (Limdep 10 has it now).
2. Latent class for every cross-section and panel model type.
3. Hierarchical Ordered Probit Models (Hopit) .
4. Bayesian Dynamic Panel Models.

[Chris Larkin]

a , sort option on generate. So instead of writing:

generate binary = mod(_n, 2)
sort binary

You could write:

generate binary = mod(_n, 2), sort

For example

[Marcos Almeida]

One extra item from my (increasing) wishlist: it would be great if Stata 15 presents power and sample size estimations related to Bayesian analysis.

[Clyde Schechter]

It would be a minor convenience if the -encode- command had a -zero(string)- option that would cause the numeric values created to begin with zero rather than one, and assign that 0 value to the string value specified. This would be easier than having to define (or at least partially define) a label before running -encode-. This approach would be particularly useful to obtain 0/1 variables from No/Yes variables (as opposed to the current 1/2 variables which are not nearly as useful), and it might also be helpful for encoding variables that define subsets of the data where one distinguished value is a "natural" zero, such as the placebo group in a multi-treatment study.

[Evidently it is easy enough to write a wrapper for -encode- that does this. In fact, I have, and I use it frequently. But when writing code that will be shared with others, it is best to avoid user-written commands unless they are ones that nearly all Stata users have, or can easily get, say from SJ or SSC.]

[Nick Cox]

Clyde: I don't really understand the problem with

label define whatever  0 "disagree" 1 "agree" 
encode something, gen(whatever) label(whatever)

[Clyde Schechter]

There's no problem with it It's just less convenient than

encode something, gen(whatever) zero("disagree")

would be.

Added: Actually, my main interest in is just disliking the fact that by default -encode- begins assigning numerical values at 1 rather than 0, while 0-based variables are more useful for me most of the time. So I end up defining by hand a bunch of labels that Stata could do for me if -encode- started from zero. As I say, there's an easy workaround, but it would be convenient to just have it as part of a built-in command.

[Alexander Wuttke]

Wish list
Exploratory Structural Equation Modelling
Latent Class Analysis

[Roman Mostazir]

Not sure if this has already been wished. It would be great to see SEM/GSEM model builder to allow '*.stsem' models to be saved with Stata's official graph format *.gph. Currently it allows PNG, TIFF, jpg, pdf, eps and some other formats. But *.gph format will allow to use 'graphcombine' commands to combine several `*stsem' models.

[Chris Larkin]

A plural of subinstr(). When working with messy strings, there is more likely than not more than one element of the string that I want to change. Having a subinstrs() command would be immensely useful, and would just be an extension of subinstr() as it stands.

For example, usage could be something like

//Where now, i'm writing:

replace oldstring = subinstr(oldstring, ",","",.)
replace oldstring = subinstr(oldstring, ".","",.)
replace oldstring = subinstr(oldstring, "-","",.)

//With a hypothetical subinstrs(), i could write:

replace oldstring = subinstrs(oldstring, ",", ".", "-", "", "", "",.)

[daniel klein]

I find the idea in #159 appealing. I also find the suggested syntax hard to read (and therefore to use) and note that it would be confusing because Mata's subinstr() has similar syntax, that does something entirely different.

I guess the underlying problem would better be handled by a (suit of) command(s) than by a function - and not necessarily written by StataCorp.

[Attaullah Shah]

I don't know whether this has been previously pointed out or not. I have been thinking about the slow processing of reshape program. It would be a great addition in Stata 15 if the reshape program is written in Mata language and enhance its speed.

[Chris Larkin]

daniel klein, I do not use nor am particularly familiar with Mata. As I was putting down my thoughts though it struck me that egen newvar = sieve(oldvar) (SSC egenmore) could provide a nice framework for something like this. Extending it so that it can not only keep or omit (as are it's current options), but also replace could be a relatively simple task. This is caveated with the fact I have not actually looked at the egenmore/sieve ado file

[Cynthia Inglesias]

I agree with previous posters about re-writing certain data manipulation commands in Mata (merge, reshape, open etc.). We are increasingly working with large datasets and it is frustrating to say the least to have to rely on hacks to speed up things.

Perhaps StataCorp could introduce less new features in the next release and work more on commands that many users rely on to complete 90% of their work? I would bet that a much higher percentage of users use these commands than Bayesian analysis!

[Sergio Correia]

I agree with previous posters about re-writing certain data manipulation commands in Mata (merge, reshape, open etc.). We are increasingly working with large datasets and it is frustrating to say the least to have to rely on hacks to speed up things.

Mata is not necessarily the answer but that's the approach I did with ftools: https://github.com/sergiocorreia/ftools/

It has plug-in alternatives to collapse, egen, merge, etc. that should give you a 3-10x performance boost on datasets with millions of obs. (and I suspect that if Statacorp rewrites the core function of ftools in C, that would mean another 4x speedup)

[jpsanders]

Will repost under correct account...