[Bruce Weaver]

Hi Abdullah Algarni. Your 1st request in #647 reminded me of this FAQ on problems with stepwise (and related) selection methods. I'm sharing it in case you had not seen it before.

• https://www.stata.com/support/faqs/s...sion-problems/

I do agree that making -coefplot- an official Stata command would be nice.

Cheers,
Bruce

[Abdullah Algarni]

I hope to see the following in Stata 18:

1. Stepwise regression with multilevel regression commands, specifically melogit
2. Improvement in tab1/2 command. For example, I can't change format of numbers and decimals
3. Adopt community coefplot command as default command, with further improvement (e.g., have interactive graphic control window)

[Maarten Buis]

Felix Kaysers #645 you can assign commands to F keys, see chapter 10 of the Users Manual.

[Felix Kaysers]

List of all shortcuts (including do file editor) + an option to reprogram them.

[Felix Kaysers]

List of all shortcuts + reprogrammable.

[Leonardo Guizzetti]

Re #641: Isn't that what -egen, rownonmiss()- does? Am I misunderstanding?

You are quite right with the suggestion. I am asking for a built-in function though, which might be used directly in an -if-statement, for example. I know there are at least couple of ways to this with intermediate steps, as you have proposed, but this is sometimes more convenient.

[Clyde Schechter]

Re #641: Isn't that what -egen, rownonmiss()- does? Am I misunderstanding?

[Leonardo Guizzetti]

A minor convenience function: -nmissing()- (or -nmi()-) as an analogue of missing() that return the number of missing values rather than just presence/absence of missing values.

[wbuchanan]

For -by- graphs, in particular, add an option to omit graphs for by groups that contain no data (and excludes data that could be passed to -ylines()- and -xlines()- if that is the only "data" that would be displayed for a by group). It would prevent a lot of wasted page real estate if there is sparsity in the by groups and would also reduce the compute effort to generate the graph itself.

[Philip Peters]

Add stochastic volatility to UCM. Currently, it only allows for iid errors. This is especially useful for inflation models (e.g. Stock and Watson, 2007).

[Jesse Wursten]

Would there be a way to rewrite all the IO commands such that you can cancel them while they're running? I often have to load very large files over network drives and it's very frustrating to have to wait for the long loading operation to finish before being able to cancel execution ("the red X") because e.g. I noticed a coding mistake.

[George Hoffman]

nbstata is being actively developed. i think it's great and Statacorp may wish to take a peek if not already -
see https://github.com/hugetim/nbstata

[FernandoRios]

#634
Hi Christpher
I m not sure if you are aware of it, but, currently there is a user written kernel named nbstata that allows you to write Stata notebooks on jupyter, and, i have been trying it out in Quarto. It works quite well.
Perhaps the only disadvantage is that there is no official support on it, and that you need Stata17 for it to work.
F

[Clyde Schechter]

I recommend adding a new option, perhaps one might call it -lopok-, to -destring-. Currently -destring- will refuse to convert strings representing valid decimal numbers that will lose precision when converted to binary. While I think this is the right default behavior for the command, it also offers a -force- option to which naive users then rush unthinkingly to use. In fact, in the majority of cases, at least in my experience, the precision losses in question are trivial and can be ignored for practical purposes. So it would be nice to override the refusal to lose precision. But the -force- option goes too far because it also overrides the refusal to convert when things that aren't valid numbers at all are encountered. The latter may be short strings like N/A that can be dealt with by the -ignore()- option, or, often, are data errors. In the latter case, -force- results in these being "converted" to numeric missing value, when, in fact, they should legitimately block conversion altogether and require the user to deal with them instead of blundering on with erroneous data.

So I recommend adding an -lopok- (short for loss of precision is OK) option that will allow -destring- to proceed when the only concerns are loss of precision, but still have it halt with an error message when strings representing invalid numbers are encountered.

Yes, I know, that one can get around this by using the -real()- function, but then one either has to use -real()- in an -assert- to guard the -destring- command, or you have to forgo some of the other nice features of -destring-, like simple treatment of short strings with -ignore()- or -dpcomma- and hand-code those yourself. It's a nuisance, and it's a real trap for novice users, who can't or won't come up with these workarounds, and who sometimes get completely flummoxed and then make the far more serious error of using -encode-!

[Christopher Bratt]

On #631, Gorkem Aksaray

This comment focuses on using do-files: I would prefer if StataCorp didn't try to re-invent the wheel, but instead allowed for integration of Stata coding with the probably best notebook system available for literate programming. So my strongest wish for Stata is a true integration with Quarto. Quarto is said not to focus on specific languages (contrary to its predecessor R Markdown), but currently highlights Python, R, Julia, and Observable. The developers of Quarto (posit.co) are unlikely to do work on Stata integration themselves (since Stata is proprietary software), but StataCorp might if StataCorp sees it as benefitial.

Quarto can be run not only from RStudio (developed by posit.co), but also from the equally free Visual Studio Code (VS Code) by Microsoft. (VS Code has excellent Stata-integration and makes coding of do-files much easier than Stata's own do-file editor; I do all my Stata coding in VS Code).