[Sergio Correia]

for Stata it is not worth the hassle if i cannot directly run the code and see the results...

I think you can actually do it, through Stata automation. Are you on Windows or OSX? (I know it can be done on those, not sure about Linux)

[Jesse Wursten]

Sergio Correia I do not expect Stata to match all the features of an external editor but suggesting that it is not worthwhile for StataCorp to continue improving the built-in editor does not sound right. I have tried (1) and in fact i use VSC for programming in other languages, but for Stata it is not worth the hassle if i cannot directly run the code and see the results. It is simply not practical. I agree with (2) but this only works for simple do files and not more complex programs in ado files.

At the risk of derailing this thread, one solution I have found is to place my code in if-blocks. Say I have a dofile that does a lot of side analyses, then I'll put each one in a if-block - at the top of the dofile I have a list of "parameters" determining which section to execute. This has two advantages - I can easily set which part of the dofile is executed (I don't like selecting code) and I can close any sections I'm not interested in.

** Parameters
global prepData "0"
global combineData "1"

[...]

** Prep data
if "$prepData" == "1" {
[..]
}

** Combine data
if "$combineData" == "1" {
[..]
}

[Belinda Foster]

Sergio Correia I do not expect Stata to match all the features of an external editor but suggesting that it is not worthwhile for StataCorp to continue improving the built-in editor does not sound right. I have tried (1) and in fact i use VSC for programming in other languages, but for Stata it is not worth the hassle if i cannot directly run the code and see the results. It is simply not practical. I agree with (2) but this only works for simple do files and not more complex programs in ado files.

[Sergio Correia]

A problem that i face more and more is managing large chunks of code in the do file editor. It can literally be a nightmare navigating through different parts of a program which consists of hundreds lines of code, or a do file containing multiple programs.

I suggested in a previous post of mine implementing permanent bookmarks but i am now convinced that some sort of section folding solution similar to that implemented in RStudio is required. Not sure if this has already been suggested.

FWIW, I address this in two ways:

1. I edit my code on an external editor (Sublime Text, but probably Atom, Visual Studio Code, or any free editor would work). This gives me a lot of things out of the table, including permanent bookmarks. And to be honest, I don't expect Stata to be able to match all the features of standalone code editors.
2. I split my code in smallish chunks. Huge files are unwieldy and play poorly with git and version control. Instead, I have a master.do file that calls a bunch of smaller do-files

[Belinda Foster]

A problem that i face more and more is managing large chunks of code in the do file editor. It can literally be a nightmare navigating through different parts of a program which consists of hundreds lines of code, or a do file containing multiple programs.

I suggested in a previous post of mine implementing permanent bookmarks but i am now convinced that some sort of section folding solution similar to that implemented in RStudio is required. Not sure if this has already been suggested.

[Chris Larkin]

Inclusion of standard errors in the coeflegend option to regress. Currently it only displays betas

[Bruce Weaver]

I suggest adding an option to margins to make it compute the prediction interval for an individual Y at a given value of X. Here are a couple of relevant threads.

• https://www.statalist.org/forums/for...te-and-predict
• https://www.statalist.org/forums/for...-command/page2

Cheers,
Bruce

[Weiwen Ng]

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

I see that I failed to supply the paper where the boostrapped LR test for latent class models was discussed. This paper discusses the issue, plus it describes some stopping rules that Mplus uses (if you keep getting -2LL differences in favor of the k-class model vs the k-1 class model, you can presumably stop short of doing 1000 bootstraps to prove your point). However, as it turns out, the bootstrap LR test is simple to perform. You would simply bootstrap latent class/profile models for k classes and k-1 classes, then calculate the value of -2 * the difference in log likelihoods. In fact, you could do this in Stata 15, but for the fact that the program prohibits the bootstrap prefix from accepting GSEM with categorical latent variables.

On one hand, this is for good reason. There are numerous convergence issues, and the order in which the latent classes are identified will not be the same from model to model. This rationale makes sense for why we don't get to use bootstrap to estimate parameter standard errors here.

On the other hand, it really does seem like the BLRT is a very well-accepted test for the correct number of classes, to the point where people in the know might question why a paper produced by a Stata user didn't include BLRT statistics. I feel like the BLRT probably provides information that is complementary to the various information criteria. And with this test, you don't care what order the classes get assigned, all you want is the empirical distribution of -2LL. And you can feed the boostrapped datasets the parameters from your validated model (perhaps with some random noise added), and/or each observation's predicted class probabilities from the k- and k-1 class models to ensure convergence.

[Robert Picard]

It would be great if the hard-coded limit of 10,000 results for the Mata function dir() was lifted (see this post that mentions that unicode translate is affected by the limit). The issue also affects filelist (SSC); see this recent thread about a user with 2,000,000 text files split into 20 (annual) directories.

[Belinda Foster]

Clyde Schechter it can be a bit restrictive yes, but fairly easy to implement if you have some experience in other languages. In the simplest case you just run the scripts sequentially, either in a standalone computer or in a virtual machine. Using text files is not always the best option. It depends on what you want to do i guess. I think, more generally, Stata needs to interface better with the operating system for more elaborate programs.

[Clyde Schechter]

Well, but I don't get it. A do-file is running automatically. At some point you get it to pop some result into the clipboard. Now you have some other program running, say in Python or C++, and it, too, is running automatically. So either you've got to program in a delay that makes that other program sleep until the clipboard has something to offer it, or you're going to have a mess. Also, if you have several programs in operation that also use the clipboard (I sometimes, for example, do word processing while I am waiting for a long Stata program to finish running), you need to program some way for the receiving program to figure out which clipboard it's supposed to capture data from. I don't know enough Python or C++ to say for sure these things can't be done--probably they can with some relatively obscure functions--but I certainly don't know how to do it.

So the synchronization of these programs sounds like a nightmare to me, and my instinct would be to pass the result between programs using, say, a text file as a go-between: it's very easy for the receiving program to test for the existence of the anticipated file and, if necessary, wait for it to appear. The file-open functions themselves would provide the needed information.

[Belinda Foster]

Belinda Foster I understand what you are saying you want Stata to do. But I can't envision a situation where one would want to do this (in either direction). Can you provide an example where this would come in handy?

This is a no-brainer when you want to quickly use results from other programming languages in Stata. And vice versa of course.

Richard Williams This is overkill but A+ for creative thinking!

[Richard Williams]

If you check the programming manual, you see that dialog boxes have functions where you can copy to or from the clipboard. It is for when you construct commands using dialogues rather than just typing the command yourself. I suspect this is not what Belinda wants -- it seems like a lot of work to construct a dialogue box when you can do the same thing with a few clicks. But maybe you could make it work.

[Clyde Schechter]

Belinda Foster I understand what you are saying you want Stata to do. But I can't envision a situation where one would want to do this (in either direction). Can you provide an example where this would come in handy?

[Belinda Foster]

Can you clarify or give an example of what you mean? I can interactively copy and paste from a do file, but you seem to have some sort of function in mind that would do it for you.

Richard Williams Suppose when you run a do file that you obtain the results of a calculation or a string in a local named foo (e.g. foo = 14354 or foo = "string"). Is there a way to export this result directly to the clipboard?

I am currently unaware of anything of the kind clipboard("foo", "copy"). Or the reverse, placing the clipboard contents in a local foo: clipboard("foo", "paste").