[Tiaga Falcao]

Maarten Buis Let's put Social Network Analysis as a field of research aside, one can look at this as a continuum of research data and how econometric models have been shaped around them. Just consider these data types (not in particular order) : point data > cross-sections > panel (temporal) > spatial > and network or matched data (Link1, Link2) I believe that in the coming years many researchers would be interested to explore the relationship of entities or at least re-examine the existing theories in their fields with matched/network data. Anyways, I agree that it is going to take at least 2 or 3 years for StataCorp to come up with a reliable set of functions/features for network data and econometrics.

[Marcos Almeida]

Still in my wishlist for Stata 18, since it didn't come in Stata 17: it would be great if we could save the graphics (such as tiff and jpeg) with higher quality, say, 300 or 500 dpi. This is something demanded by several journals. Nowadays, we need to use a graphical editor after dealing with Stata. But this is already avaliable in other statistical packages. In short, it would be great to work with this sort of "resizing" operations without having to exit Stata and delve with graphical edition softwares.

[Leonardo Guizzetti]

DPI (dots per inch) is an arbitrary concept. You can control dpi by dictating the height and width elements. For example, specifying -height(6000) width(6000)- creates a 10 inch square image with 600 dpi resolution, or a 6 inch square image with 1000 dpi resolution. The physical size (in inches or centimetres) is either enforced or at least chosen by default in the downstream application, like Word. But submission to journals shouldn't give you any grief so long as there are enough pixels in the image. A complementary approach is export as EPS or SVG files as these are vector-based and can be scaled to arbitrary size with no loss of fidelity.

Still in my wishlist for Stata 18, since it didn't come in Stata 17: it would be great if we could save the graphics (such as tiff and jpeg) with higher quality, say, 300 or 500 dpi. This is something demanded by several journals. Nowadays, we need to use a graphical editor after dealing with Stata. But this is already avaliable in other statistical packages. In short, it would be great to work with this sort of "resizing" operations without having to exit Stata and delve with graphical edition softwares.

[Marcos Almeida]

Leonardo Guizzetti Thank you for the reply. I agree that we can customize height and width to produce the desired dpi. I am also aware of the pros related to svg and eps extensions. But I keep finding (at least, in my field) several high-impact journals that demand tiff or jpeg ‘beyond 300 dpi’. I understand that many fellows don’t mind if this facility is lacking in Stata. But it is sometimes so handy elsewhere. In my case, since Stata is my favorite package, I decided to learn how to use graphical editors just for that matter. That said, using a heavy software just to select, say, a 400 dpi graph seems somewhat cumbersome in my point of view. Thanks again for your comments.

[Jeff Wooldridge]

Here are a few things I would like, if they are statistically justifiable. I have seen that there is work being done in these areas, but I don't know how good it is.

Add an fe (fixed effects) option to xtologit. The new xtmlogit has an fe option, which is nice.

Alternatives to BIC and AIC that can be used with svyset data. For that matter, alternatives for a lot of things when data are svyset, e.g. various diagnostic tests.

Add an memlogit command. Many xt commands have an me counterpart, so I am mildly surprised xtmlogit doesn't.

Whenever Stata does not have something I would like or expect, I figure it is usually because (a) it is statistically inappropriate, or at least an appropriate means has not been worked out yet, or (b) nobody has gotten around to programming it yet. xtmlogit seems to have been in the latter category until yesterday, so perhaps some of these other things do too.

Rich: I'm going to have to review, but I'm not sure that ordered logit has a conditional MLE version that eliminates the heterogeneity. Both binary and multinomial logit do. As you know, these "fixed effects" estimators are not obtained by including unit-specific dummies. The conditioning arguments are actually pretty fragile. I know there are some solutions for ordered logit, but it's nothing as clean as the binary and multinomial cases, and I don't think there's much agreement.

[Jeff Wooldridge]

In teffects with the ipwra option, it would be much better to compute the estimates using the simple, multi-step procedures: estimate the propensity score, using the inverses for the treated and control groups in whatever regression adjustment (linear, probit, fracprobit, poisson, and so on), and then compute ATE or ATET. Then, to get standard errors. insert those estimates into the first order condition for both problems and apply the usual GMM formula. Currently, Stata seems to use the FOCs to actually get the estimates and it doesn't always converge. It's weird to see a problem which is, say, logit followed by weighted linear regression not converge. It's frustrating and misleading. When logit or probit is used for the propensity score and linear, logit, poisson are used for the outcome, the problems are concave in the objective functions. I've never had it not work when done in two stages. But I've seen it fail more than once when using teffects. We recently had a Twitter discussion about this. I really like teffects because of its flexibility, but it could be a bit better.

[FernandoRios]

Dear Jeff Wooldridge ,
I actually talked about this with someone at Stata. Yes, the problem seems to be related to how GMM is processing the information. Based on their and my assessment, there seems to be a problem associated with scales (of the outcome variable and not well-balanced covariates).
Right now the suggested solution (or patch), is to rescale the outcome first, estimate the treatment, and re-scale it back. I have been working on it for the Example I ve been posting on twitter, and works like a charm.
Fernando

[Richard Williams]

Rich: I'm going to have to review, but I'm not sure that ordered logit has a conditional MLE version that eliminates the heterogeneity. Both binary and multinomial logit do. As you know, these "fixed effects" estimators are not obtained by including unit-specific dummies. The conditioning arguments are actually pretty fragile. I know there are some solutions for ordered logit, but it's nothing as clean as the binary and multinomial cases, and I don't think there's much agreement.

Thanks Jeff. I just noticed that Stata has the user-written feologit command. Any thoughts on whether it is "clean" enough? The SJ article on it is at

https://journals.sagepub.com/doi/abs...36867X20930984

[Enrique Pinzon (StataCorp)]

Thanks Fernando and Jeff,

We are looking into the example in which -teffects ipwra- does not converge. Rescaling the dependent variable in this instance helps and I would suggest people do this if they are having convergence issues with -teffects ipwra-. This is one of the instances in which the scale of the variables may affect convergence. Also, in this case, rescaling does not affect the interpretation, the -ra- part of -ipwra- is linear (you just scale back to get it in the units you want).

With regard to the -teffects- algorithms they are using -gmm- only as an engine to compute standard errors. We get the point estimates from the different parametric estimators in Stata and use them as starting values in -gmm-. The -gmm- moment conditions are score equations. This is why in most cases you see -teffects- estimators converge after one iteration.

[Nicholas Winter]

Ability to transfer settings from Stata 17 to Stata 18. That is, move a preference set (or preference sets) that I save in Edit-Preferences-Save Preferences to the new version.

[Clyde Schechter]

Make reference to a non-existent value label a syntax error that causes execution to break. Here's an example of the kind of problem this recommendation is intended to solve.

label define mylabel 0 "This" 1 "That" 2 "The Other"
label values myvar mylabel
....
drop if myvar == "The Other":mylabl // NOTE TYPO IN LABEL NAME

... // CODE USING myvar PRODUCING INCORRECT RESULTS BECAUSE THE -drop- COMMAND DID NOTHING

If the reference to the non-existent mylabl caused the code to break, the incorrect results would not be produced. As it stands, the incorrect results are produced and the user is not warned that anything has gone wrong. In a small enough do-file, the message that 0 results were dropped will be a clue, but in a large do-file where the drop command and its output have scrolled out of sight, the user is unaware.

[daniel klein]

[...]

label define mylabel 0 "This" 1 "That" 2 "The Other"
label values myvar mylabel
....
drop if myvar == "The Other":mylabl // NOTE TYPO IN LABEL NAME

... // CODE USING myvar PRODUCING INCORRECT RESULTS BECAUSE THE -drop- COMMAND DID NOTHING

Note that when used in an expression

"The Other":mylabl

evaluates to a (system) missing value. Thus, the drop command will drop observations for which myvar == .

This is actually consistent with Mata's st_vlmap()

. mata : st_vlsearch("mylbl", "The Other")
  .

The behavior is also documented in [U] 13.11 Label Values.

I do get why the behavior might not be desirable. I also find that this it is similar to dereferencing a non-existing macro.

[Clyde Schechter]

I also find that this it is similar to dereferencing a non-existing macro.

It is similar. And in the past I have requested that that be made a syntax error as well. (I have no problem with explicitly creating an empty macro -local mymacro- and then dereferencing that; I dislike having a never-created macro being treated as if it were an existing macro containing an empty string. And for similar reasons.)

[Nicholas Winter]

Line wrapping in graph titles, notes, etc. I'd love to be able to specify a long note, for example, and have it wrap automatically (perhaps triggered by an option) onto multiple lines when the text is too long to fit on one line. E.g.,

graph .... , note("This is my very long note ... blah blah blah", wrap)

[Kseniya Levykina]

Would be great to be able either to see visually which step of the code Stata is currently working on and/or see a status (as a % or left time estimation) to get a feeling how far the code was run already.