[Sergiy Radyakin]

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

• source line numbers in error messages;
• Intellisense in do-editor;
• strip comments tool in do-editor;
• default numeric type double instead of float;
• ability to compile Mata targeting earlier versions;
• some more flexibility with Mata functions/libraries (difficult to explain, communicated to StataCorp earlier).

I'd also agree to same convenience as Richard has requested above:

• Switch more on/off with a toolbar button or hot-key.
• Switch trace on/off with a toolbar button or hot-key.

[Joseph Coveney]

David Airey already mentioned one of my my two perennials, menl. The other is strUnicode.

Like Sergiy, I also have a few for Mata, the two highest on the list being namespace and an enhanced development environment (debugging now is pretty much limited to sprinkling the old printf("#2 Got this far!\n") or printf("Iteration = %3.0f, my_variable = %14.7f\n", i, my_variable) into the code). Bill Gould already mentioned StataCorp's plans for byte, int and long, so that's covered. I've encountered circumstances where the ability to confidently declare const would have been helpful, too. enum is pretty standard now, and it would be sweet to see it in Mata. But among this list, the most acute need I feel is for namespace.

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

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

[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 Stanley]

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

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

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

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

[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

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

[Rich Goldstein]

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

[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

[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

[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