[Richard Williams]

This may be more of a request for a FAQ than for changes in Stata 14. Stata has mi, svy, and xt. I get confused over how and how much I can mix and match these things. Rather than scanning through different manuals, it would be nice to have a single FAQ that showed, say, how I can use (or can't use) mi with xt, what mi commands can and cannot be combined with svy, using survey weights with xt data, etc. Just saying that it can't be done may actually be especially helpful, since otherwise you may go scouring the manuals and the web to figure out how it could be done.

[Richard Williams]

Following up on Daniel's comment, I'd like it if the documentation did more to at least warn you about things that may be bad ideas. For example, with MI, various sources say passive imputation is a bad idea. mi impute allows pweights but again, some say you shouldn't use them. Users have to know what their doing, but a little more guidance on whether something is a good or bad idea (perhaps even just one or two sentences with references to learn more) could help.

[daniel klein]

I know this is highly unlikely, as it will break old code, but could we have a force option for many-to-many merges? Or, perhaps we could at least add a reminder message that what you are doing does probably not make sense, or include (parts of) the (excellent) discussion of many-to-many merges in the manual, starting with

m:m specifies a many-to-many merge and is a bad idea.

Especially inexperienced users (e.g. students in an early phase) seem to merge datasets by 'try and error'. Whenever Stata issues no error message, these users think that everything went fine. Unfortunately it is hard enough to teach new users to read the help files, but in my experience almost impossible to get them to read the manuals (which is a pity as they are so much more than simple 'handbooks').

An additional message or extension of the help file in this respect might well reduce errors in data management. And given Bill Gould's blog entries (here and here) on much harder to detect errors, StatCorp. seems to be pretty aware of the potential problems with merging.

Best
Daniel

[Christophe Kolodziejczyk]

About Mata I subscribe to what has been written by the other members, especially the fact that Mata is hard to debug. I find the mata set matalnum command pretty useless and the method of hardcoding messages to find bugs tedious and from another time. I wish I could see the following features : Methods for constrained optimization Possibility of parallelizing code Introduction of true integers (but Bill Gould has already posted on that issue as Joseph points it out) Regarding class programming: overloading of functions and constructors which can take arguments More functions for working with panel-data Christophe

[Bert Lloyd]

Bert, regarding your second comment - are you looking for something other than what -numlabel- currently offers? if so, what?

Dear Rich,

Thank you for the helpful reference to -numlabel-.

I would prefer something that (a) did not alter the dataset, (b) optimized formatting in the displayed table (e.g. column width, perhaps a second column/row for the value labels) and (c) could do the same for variables (i.e. displayed both the variable label and the variable name).

I realize various workarounds are possible, e.g. for (a) preserve; numlabel lab_x lab_y; tab x y; restore;, and that tabnl and fre are useful alternatives.

Best,
BL

[Rich Goldstein]

Bert, regarding your second comment - are you looking for something other than what -numlabel- currently offers? if so, what?

[Bert Lloyd]

Allow inlist() to take more than 10 string arguments.

An option for "tab" that will display both value labels and unlabeled values, similar to user-written -tabnl- and -fre-.

The ability to retain bookmarks in do-files across sessions (perhaps via the Project Manager, since it is useful for do-files to be plain text).

[Sergiy Radyakin]

Do you want something other than -set type double- ?

Hello Mike, set type works fine. But the user has to consciously call this command. Until she does, she is stuck with a float default, which is causing (hard-to-notice) problems with the time variables. All I ask for is double as default. Users that know they don't need that precision, can be more efficient and save some memory by specifying the type directly, but at least everyone is safe.

PS: the documentation for generate has this somewhat confusing paragraph:

Specify default storage type assigned to new variables

set type {float|double} [, permanently]

where type is one of byte|int|long|float|double|str|str1|str2|...|str20 45

I understand the type enumeration is not relevant for the set type but belongs to generate, but this is not at all obvious.


Best,Sergiy

[Mike Lacy]

The list is endless really. Here are some features I wish:

source line numbers in error messages;

Yes!! Lack of this feature makes Mata exceptionally tedious to debug. Stata is nearly as difficult.

[*]default numeric type double instead of float;

Do you want something other than -set type double- ?

[Mike Lacy]

I'd like to see Stata some commands to do social network calculations and graphs. Social network stuff is very in many fields now, not just for social scientists, and I don't think (?) it's available in SPSS or SAS (yes in R, though), so I think this would give Stata an market advantage. While there are a couple of user-written Stata modules (-netsis- and -netplot- in SJ), the time required by some common kinds of network calculations really requires efficient implementation in a low level language, rather than Mata, to be practical for sizeable problems. Having this stuff done by the professionals at Stata, rather than with a user's C plugin, would be preferable.

[Clyde Schechter]

@Sergiy

I agree with most of your suggestions, but why would you want to strip comments from your do files? Even a really well-commented do-file is hard to understand when you have to go back to it months after you've written it (e.g. revising and resubmitting a paper). I think a do file without comments would be so obscure that it would be simpler to start from scratch than try to figure it out or update it!

[Richard Stanley]

+1 for Unicode support for language localization, teaching and analysis in foreign languages, and natural language processing and machine learning

[Daniel Bela]

As discussed in the forum thread "savold in Stata 12 and Stata 13 differ", an option -asversion(<dta version>)- for the -saveold- command (or, alternatively, for the -save- command, making -saveold- obsolete) would be very helpful. It is especially needed when collaborating with users on older Stata versions or other third-party software that is not capable of reading recent Stata data formats, such as IBM SPSS Statistics.

Regards
Bela

[Richard Williams]

I would like to see a -replace- option added to -test-. This would replace the current estimates stored in memory with the constrained estimates. If you use the -coef- option, you can see the constrained estimates, but there is no way that I know of to subsequently use them. This would be handy for commands like -xtreg- that do not let you use the -constraints- option. The constrained estimates could then be used for post-estimation commands like predict and margins. This is basically what the user-written linest command does, but linest is now pretty old so I am not sure if if even works right with newer commands. The -coef- option shows that the constrained parameters are already being estimated so I wouldn't think it would be hard to have them replace the original estimates (or perhaps store them as a separate set of estimation results that the user could name).

[Bert Lloyd]

Developing nice plugins for popular text editors (e.g. Notepad++, WinEdt) -- the user-written ones are nice but official versions (or user-written but with active help from StataCorp) would be a huge improvement.

Allowing shell commands in batch mode.
(See http://www.stata.com/statalist/archi.../msg00537.html )

variable names > 32 characters

pie-in-the-sky: a latex : prefix that would send the command's output to nicely formatted latex. Would be great for simple descriptive documents.