[wbuchanan]

Thank you, Sergiy Radyakin, for establishing a "Wishlist for Stata" in the General section. Maybe some wishes may be solved in future updates of version 14 instead of having to wait until version 15.

I'd like to add a few points of my own:

Very simple, but also important:

-putexcel- to include output with three decimals (i.e. nformat("number_sep_d3") in addition to the current nformat("number_sep_d2").
Maybe in Stata 14.01?

More ambitious:

- substantial speed improvement in -sem- and -gsem-. For me, sem and gsem cannot be used in the current version of Stata, due to being extremely slow.
- Graphics in -sem- as output. (Currently, one can use graphical input, which helps learning SEM, but is also a slow way of input. For the many who use code: A graphical output will sometimes help inspect more complex models developed.
- Bayes to include sem/gsem, including multilevel SEM.

Apart from that? Continue developing this wonderful software... Thanks!

Guest

I think the graphical output request for SEM is quite a bit more ambitious. Just thinking quickly about the number of decision rules that StataCorp would need to create to produce comparable graphics to any other form of graphical output they currently support is dizzying (e.g., which direction should measurement models be specified, how would it generalize to cases with multiple factors, what about cases when there are more manifest items than would fit on the screen with the default size observed graph objects, etc...). One possible way of doing something like that would be to use a separate graphics engine like GraphViz where it could handle all of the decision rules/spacing algorithms in a way that might be familiar to more users (this could potentially be something that could be done as a user written program as well).

With regards to the last request, a recent blog post on the Stata website shows that there is support for multilevel SEM in the Bayesian statistics commands (e.g., the IRT models are parameterized as items nested within subjects and both the item parameters and theta are estimated). If, however, you're interested in performance issues you may want to consider using the StataStan package developed by Robert Grant and can read a bit more about some of the performance benchmarking posted to Andrew Gelman's blog recently.

[wbuchanan]

I assume this has bit several user programmers more than once, but it would be outstanding to provide a bit more detail with the r(197) error:

invalid syntax
r(197);

Sometimes it is obvious after the first pass where things went wrong, but other times is is fairly difficult to figure out what is causing the issue. Perhaps something that would point to the last parameter/option that was correctly parsed by the syntax command could help a bit or possibly exposing a bit of the internals of the syntax command to the traceback (e.g., even after -set tracedepth 32- the same error is issued in the same manner with no additional information made available).

[David Radwin]

Another suggestion: quantile (percentile) estimation including standard errors with svy data, like epctile from Stas Kolenikov (findit epctile).

[wbuchanan]

Add an option to append that is the analog to the role of the keep option in merge. The keep option in merge basically allows users to specify LEFT JOIN, RIGHT JOIN, FULL INNER JOIN, and FULL OUTER JOINs through one or more of the numeric values. The append command, however, is like using UNION ALL, but there are definitely use cases for UNION as well. Having an option that would allow users to switch to the equivalent of a UNION statement (e.g., keep the union all type behavior as the default) would definitely be a nice feature and could help with some data management tasks.

Multigroup GSEM. This is especially relevant for assessment and measurement applications to test measurement invariance from the Classical Test Theory perspective across groups/time.

GSEM/IRT goodness of fit statistics. It seems to come up in user questions with some regularity. On the IRT side, having some of the person and item fit statistics (e.g., infit, outfit, standardized infit/outfit) are important for decisions about item inclusion/exclusion in scaling and test form creation.

IRT parameter constraints. Allow users to specify either a single constraint for a given parameter on all items (e.g., constraint discrimination to 1 when fitting the 1PL to get the Rasch model) or specify a numlist of constraints for individual items (e.g., might specify difficulty parameters for items that have been previously calibrated for linking/equating, testing for parameter drift, etc...).

An analog to the CUBE function in SQL. Right now some of the functionality can be obtained using one or more calls to collapse/contract/table, but it'd be nice to have a command that would provide the aggregates for all permutations of the values specified in the by option along with "sub-totals" and "grand totals". This would be especially awesome if the program returned results in an r- or e-class set of matrices/macros (so it could be used with user written commands for reporting purposes).

[Alexander Wuttke]

My wish for Stata 15:

An Update of the Do-File editor.

That includes autosave and rubrics / headlines. May be similar to MS Word so that
1) a glimpse at the navigation would tell you at which section you are currently looking
2) you would have a hierarchy of sections and subsections
3) you could navigate to subsection by clicking.

[wbuchanan]

Alexander Wuttke are there other IDEs that have this functionality? There are significant differences under the hood between an MS Word file and any type of plain text document (e.g., all of the markup and formatting that is abstracted away from the user). You can achieve some of this functionality already if you delimit sections of your code with curly braces (which then allows you to fold the section) and placing different style comments before these sections. It doesn't provide a hierarchy in any specific way, but gives you some of the functionality you mentioned.

[Andrew Lover]

One note, when you fold sections, they reappear when re-opening the file (at least on OSX). This is perhaps good practice for archiving scripts, but frustrating when developing an analysis.

[wbuchanan]

Andrew Lover I think it likely does the same on non-*nix based systems as well. I'm not sure how much work it would be, but perhaps the .do file editor/project manager could be integrated with the electron framework. It is basically a cross-platform framework for building a browser, but it is what RStudio used to build their IDE and has been used by other teams/companies/organizations (e.g., MapBox) to build other desktop applications. The downside is that it handles the communications between the browser and backend with Python, but the upside is that this development would also make it a bit easier to integrate Stata with project Jupyter/iPython Notebook - which on its own makes it fairly easy to integrate Stata with other languages used for data science, machine learning, and analytic applications.

[Alexander Wuttke]

@wbuchanan
I am a novice who doesn´t even now the meaning of "IDE". Anyways, as a user of Stata this is just something I am missing again and again everytime I scroll through the editor.
Thanks for the hint to the curled brackets. I didn´t know that.

[Clyde Schechter]

Well, for my style of programming, in which most of my do-files are short, and a project is broken down into many do-files that run serially, or call each other, the need for this kind of indexing simply never arises. In effect, the directory containing the do-files is my index. Even the collapsing of blocks of code within braces is only seldom useful for me. In fact, probably it has done me more harm than good, as I am far more likely to click on one of those little minus-boxes by mistake (when trying to position the cursor at the beginning of that line) than on purpose.

And I find it enormously convenient that do-files are text files that I can share with people who don't have Stata, or who do but prefer to edit the code in other applications. So from my personal perspective, it ain't broke and I hope they don't fix it.

[Richard Williams]

I wish there was an easier way to write help files. I find writing the help file worse than writing the program. Maybe there could be some sort of easy to use templates.

[Sergio Correia]

I wish there was an easier way to write help files. I find writing the help file worse than writing the program. Maybe there could be some sort of easy to use templates.

I think something on the line of https://github.com/michaelstepner/pandoc-smcl/ could be very useful. Basically, write markdown, which is then translated into smcl. The key things (syntax tables, etc.) get translated into the respective SMCL directives, and for the others, you can just run the directives directly "{help xyz}"

[wbuchanan]

Richard Williams if you have Maven installed on your system, you could always use the Stata Archetype to generate a shell for the help file. It was kind of my way of making a small short cut for Java plugins where it will generate an ado file and helpfile with a lot of generic material (so I would only need to copy/paste and/or delete things) from within it. For Mata, George Vega and James Fiedler worked on something that uses doxygen style comments to generate help documentation https://github.com/gvegayon/devtools. Personally, I think something analogous to JavaDoc would be an awesome edition (e.g., add specifically formatted comments that generate help documentation and also will check to make sure all parameters and return values are documented). I just recently started messing around with a way of tokenizing SMCL with the hopes of being able to interchange other forms of markup/markdown with SMCL tags without loss of information (e.g., underlining specific text when using {cmdab:some:thing}).

Alexander Wuttke IDE = Interactive Development Environment. It's a type of program and is basically what the .do file editor is. You are able to interact directly with the programming environment and there are some enhancements (e.g., syntax highlighting) that make it a bit nicer to work in compared to a plain text editor. The curly braces thing isn't bad, but like Clyde Schechter mentioned, you need to be careful to make sure you don't miss things that are collapsed. I would typically use a block of 3+ lines that looked ilke:

/******************************************************************************
* This is the start of the comment before curly braces being used to hide a   *
* chunk of code from sight.  The comment is a bit longer than normal to make  *
* sure it would catch my eye if scrolling through the file quickly.           *
******************************************************************************/

[wbuchanan]

An option added to the -levelsof- command to return an unsorted list (e.g., use the order of the values from the variable as they appear in the dataset or retain the sort order of the data set). Basically if there is a reason why the values of a given variable need to be unsorted (e.g., sorted based on values of one or more other variables) it'd be really nice to be able to get the values in that order. If there was any way to use expressions inside data indexes (e.g., rep78[4 if foreign == 1] where this would return the 4th record with the value of foreign set to 1) that would be helpful as well.

[Bill Magee]

Documentation: Extending Examples
The examples in the documentation are very helpful, but some note of common analogies to the examples given would be very helpful.
For example, under meglm gives an example for students nested in schools. Some not about whether/ how this applies to individuals observed over time would seem useful and appropriate, given that in many areas a VERY common use of multilevel models is for longitudinal analyses (e.g. of panel data). I realize it is not possible to consider all possible examples but I think even a brief comment enumerating some highly common variants or uses would be helpful.