[George Ford]

egen xres = resample(x)

creates a new series xres that is a random sample of x. options would include:
1. with or without replacement (, permute)
2. resample in blocks of integer N (, block(N))
3. includes or exclude missing values (, dropna)
4. weights options
5. a similar command to resample an entire matrix


-summ- for matrices

[Giovanni Colitti]

Because I would like to use Bayesian modeling for prediction, I would appreciate enhancements to -bayesmh- post estimation to make it easier to get the expectation of the posterior predictive distribution. The attached link accomplishes what I'm talking about, but I'm envisioning a simple post estimation command that can effortlessly be applied to different models.

[Weiwen Ng]

I think you can do this by specifying eform? See help eform.

If Samulsion wants to directly work with the e(b) matrix, then I don't think eform will work, because I don't think the underlying matrix gets transformed. However, two responses are that he could manipulate the e(b) matrix in mata, and also why would you want to manipulate the e(b) matrix yourself? A number of user-written programs will write exponentiated results to Excel or other files (e.g. estout, available on SSC). Furthermore, you can write the r(table) matrix, which has all the transformed coefficients, to Excel with putexcel if you want to.

[Donovan Pollack]

Export/Write to Microsoft Powerpoint

[Jesse Wursten]

I would like Stata 16 provide matrices of exp(b), i.e. odds ratios, relative-risk ratios, incidence-rate ratios in ereturn list for logit, mlogit, Poisson and other models as like.

I think you can do this by specifying eform? See help eform.

[Chen Samulsion]

I would like Stata 16 provide matrices of exp(b), i.e. odds ratios, relative-risk ratios, incidence-rate ratios in ereturn list for logit, mlogit, Poisson and other models as like.

[Mike Zyphur]

Hi Stata team,
On the point of speed-ups in Stata, it is worth considering GPU computing (GPGPU), perhaps using the simple and easy-to-learn ArrayFire library and API: https://arrayfire.com/.

Originally funded by DARPA, it's entirely free and can be automatically compiled for Nvidia's CUDA, OpenCL on AMD and Intel chips, as well as for multi-core CPU computing (as well as FPGA and ARM chips found in many devices today). Conveniently, this approach would not require learning low-level programming in CUDA or OpenCL, which can be tedious, while then being stuck in only one of these approaches and its associated hardware. Instead, using ArrayFire would offer a huge performance boost for anyone with a reasonably fast video card (or cards), allowing Stata to run on Amazon Web Service EC2 instances that are GPU focused, but also automatically reverting to CPU processing whenever this is detected as being faster. Thus, a single version of Stata could be written and distributed to users, which would then automatically take advantage of the user-specific hardware that's detected.

Anyway, something to consider! The ArrayFire library has a wide variety of ways to speed up existing code, even that which is optimized for multi-core CPUs, including by allowing parallel 'gfor' loops. To make Stata 'big data' capable, something like this will be essential.

Cheers,
Mike

[Mike Murphy]

Not splashy, but investing time in making error messages more informative would probably have large returns for most users.

[Philip Jones]

I would like an iOS version to be able to run Stata 16 on my iPad. Now before you think this is a crazy request, consider most of my work is now done on an iPad pro, which has more computing power than most laptops. In fact, one of the only reasons I use my laptop now is to run Stata. Would love for StataCorp to consider this as I think there would be more users wanting this than would be anticipated at first glance.

[Mike Murphy]

I would like built-in support to export tables to Excel & LaTeX.

[Jesse Wursten]

A few little things I'd like (or may be unaware that exist):

1. Find-Replace in do-editor tells you how many instances of the find term were replaced.
2. Option to open multiple do-files from explorer window in one editor window rather than one Stata instance per do-file. I don't really want to have to create .stpr files for that purpose.
3. Option to set do file preferences (e.g. font/colors) permanently (this may already be an option--I just haven't seen it if it exists).
4.

inlist()

command that can hold more than 10 string vars directly rather than having to loop or use multiple or statements.

FYI, you can drag dofiles from the explorer window into the editor window and it will add them to the existing dofile editor window.

[Anders Alexandersson]

Clyde, thank you for sharing. Daniel, yes good question. This is Julia's implementation:
https://docs.julialang.org/en/v1/man...ng-Operators-1

[Clyde Schechter]

daniel klein Good question. I don't have a great answer for it. Certainly -if- conditions in Stata are inherently dichotomous. The command will either apply to the observation or it won't and there is no middle ground. The convention that . means not false has the virtue of consistency, and we are all on notice that in this context we have to sometimes make explicit provisions to include or exclude observations where the condition's truth value is unknown. And I don't see any why to modify that.

FWIW, if you have time to read a digression, back around the same time that Bill Gould was inventing Stata, I toyed with the idea of developing a statistical package myself. I developed a prototype that I used for a few years in my research. In that prototype, logical expressions evaluated to true/false/unknown, and logical variables were a separate data storage type from numbers. My equivalent of the -if- qualifier was called -where- (and it preceded the command instead of following it), and, it caused commands to be applied only to those observations where the condition evaluated as true. But I also had a structure that syntactically resembled Stata's -if- command, but with different semantics. That one allowed for indeterminate outcomes. The syntax of the structure was

if condition {
    do this
}
[ifnot {
    do that
}]
[unknown {
    do the other thing
}]
Note:  Square brackets denote optional components of the syntax, as in Stata reference manuals' syntax diagrams.​​​​

It's not all that different in principle from an -if ... else if ... else ...- structure (which my program also supported, and the parser treated them more or less the same way). But it was a convenient shorthand. You only had to state the condition once. When true, the first branch was taken, when false the second, and when unknown (missing value), the third. The semantics differed also in that this -if- structure could be used both to skip or execute commands on the entire data set (like Stata's -if- comman), and also to select observations to which the command would apply (like Stata's -if- condition.)

Ultimately, I decided I didn't have the entrepreneurial spirit it would take to try to really develop the package and bring it to market. When I first encountered Stata, back at version 4, I was delighted and surprised to see that its programming language was strongly similar to what I had designed. (Mine was consciously modeled on C, though with differences, and I suspect Stata's was as well.) And, where they differed, mostly I thought Stata was better.

[daniel klein]

In general, I like Clyde's idea. However, I also see a potential for confusion. For example, the logical expression in

if (.) ...

evaluates to true (better: not false) and the code following the condition will be executed. What would we expect for

if (1&&.) ...

Best
Daniel

[Anders Alexandersson]

[...] why not define new logical operators && and || that would behave this way?

I like it. In Julia and in Java (and perhaps in some other languages), && is known as "short-circuiting boolean AND"
and || is "short-circuiting boolean OR". Short-circuiting means stopping evaluation once you know that the answer can no longer change. For example, in Julia: https://docs.julialang.org/en/v1/base/math/#&&