Wishlist for Stata 17

[Philip Jones]

In the spirit of previous threads serving the same purpose, please use this thread to add your desired features for the next major version of Stata.

I’ll start: given that iOS has now been forked into a “phone” OS and iPad OS, and given the changes to iPad OS allowing for better file management and sharing, and given the incredible computing horsepower of the iPad Pros in particular, can we please get an iPad OS version of Stata? For some people, Stata is the primary (and last) reason they still need a laptop!

Looking forward to reading other people’s wishlists!

[Richard Williams]

I'm disappointed more was not done with sem's speed and reliability in version 16. Mplus still runs circles around it, and even R's lavaan runs about twice as fast with the models I have run. New features are fine, but I'd like to see more effort put into improving old ones, especially sem.

[Joseph Coveney]

I'm pleased with the new release, and congratulate the company on it.

A few suggestions lingering from the last wishlist:

1. Make -merge m:m- an error; the error message should at least suggest that -joinby- might be what is intended; do not restore old behavior under version control

2. I doubt that StataCorp is going to get rid of it, but at least emphasize somewhere that

xtset panelvar timevar
xtreg . . . , re/fe

does not make for including timevar anywhere in the model

3. -set datetimeformat iso1601 | iso1601T [, permanently]- (for -display c(current_date)-, -update query-, -query born- and the like, but especially for -format %td- & -format %tc-)

[Leonardo Guizzetti]

It would be nice if Stata would include LZW compression for producing TIFF files (it's a lossless compression scheme) so that the result images are not massive files. As of now, I must use an additional program simply to open and resave my TIFF graphics.

[Bruce Weaver]

I'd like to suggest that this thread be made "sticky" until Stata 17 is released. This might help prevent creation of parallel wish list threads.

Cheers,
Bruce

[John Mullahy]

The Frames Manager available on the v16.0 Data dropdown is quite handy. Might there be a way in v17 (or perhaps v16.1) to make it available as a toolbar customization so it can be activated by a single click like Do-file Editor, Viewer, etc.?

(Reposted, with slight edits, from https://www.statalist.org/forums/for...ar#post1507021)

[Daniel Feenberg]

I notice that Stata improvements seem to come in big projects, and that small enhancement don't get the attention they deserve. For example, adding variable lists and an -if- qualifier to the save statement would be very helpful to us, but seems never to get done. Too small a project to attract attention from the top and therefore never getting priority? I have an email from Stata support a couple of years ago saying this was planned for the near future but it seems to have been pushed aside in favor of sexier facilities..

A slightly bigger project would be to read and write Parquet files, the looming standard for big data and a way to introduce column storage to Stata. There is a Github project for this, but as yet it has limited portability.

A much bigger project would be to address the need to address requests from data sources to maintain "differential privacy" in published results. This has the potential to make whatever package achieves this ability a requirement for essentially all users of confidential data..

.

[Dave Airey]

Don't forget that Stata 16.1 is to come.

[Joseph Coveney]

adding variable lists and an -if- qualifier to the save statement would be very helpful to us

I don't doubt that there are similar user-written commands already up on SSC towards that need, but with the new release's frames you don't need to go through the effort of caching to a temporary file.

I'm still getting the hang of the new feature, but a wrapper as artless as the following four-liner could do in a pinch.

*! mysave.ado
program define mysave
    version 16.0
    syntax [varlist] [if] [in] using/, [replace]

    tempname tosave
    frame put `in' `if', into(`tosave')

    frame `tosave' {
        keep `varlist'
        save "`using'", `replace'
    }
end

Unlike the official, built-in save, you need to be explicit when you go to accidentally overwrite your current dataset file.

A use case:

sysuse auto
sort make

mysave make price if foreign in 1/25 using F:\Test
describe
describe using F:\Test

mysave length turn if foreign in 1/25 using F:\Test, replace
describe
describe using F:\Test

A much bigger project would be to address the need to address requests from data sources to maintain "differential privacy" in published results. This has the potential to make whatever package achieves this ability a requirement for essentially all users of confidential data.

Sounds interesting, but I imagine that corporate counsel has enough ulcers over potential liability issues.

[Joseph Coveney]

Add one to #3.

4. Make the default numeric datatype double. At least have -set type- apply to -replace-, too, so that potential program-busting inconsistencies like the following are avoided.

.ÿquietlyÿsysuseÿauto,ÿclear

.ÿgenerateÿdoubleÿPriceÿ=ÿpriceÿ/ÿ10000

.ÿsetÿtypeÿdouble

.ÿreplaceÿpriceÿ=ÿpriceÿ/ÿ10000
variableÿpriceÿwasÿintÿnowÿfloat
(74ÿrealÿchangesÿmade)

.ÿassertÿpriceÿ==ÿPrice
74ÿcontradictionsÿinÿ74ÿobservations
assertionÿisÿfalse
r(9);

.

[Joseph Coveney]

Add another one.

5. From the user's manual entry for -generate-, its Example 3: "generate informs us whenever it produces missing values."

Make that true.

.ÿclearÿ*

.ÿquietlyÿsetÿobsÿ127

.ÿgenerateÿbyteÿpidÿ=ÿ_n

.ÿlistÿinÿl,ÿnoobs

ÿÿ+-----+
ÿÿ|ÿpidÿ|
ÿÿ|-----|
ÿÿ|ÿÿÿ.ÿ|
ÿÿ+-----+

.

[Leonardo Guizzetti]

Add another one.

5. From the user's manual entry for -generate-, its Example 3: "generate informs us whenever it produces missing values."

Make that true.

This is a good point. Based on your example, generate must only be evaluating the right-hand side for missing values, and not a corresponding check of the left-hand side following assignment. I wonder if this was intended as a caveat emptor for those who wish to explicitly typecast their variables, but it does seem like a bug.

[Leonardo Guizzetti]

This one adds friction to working with external datasets that are imported from other statistical software. I find that the display formatting of strings are often limited to 9 characters, regardless of content. I have written a quick macro to adjust the display format to the maximum length of the contents for each sting variable, reproduced below. It would be nice if the data viewer/editor had an option to ignore string formats or expand the format to show the entire contents of a string.

capture program drop autostringfmt
program define autostringfmt
  version 15.1
  quietly {
    ds , has(type string)
    foreach v of varlist `r(varlist)' {
      tempvar xlen
      gen `xlen' = strlen(`v')
      summ `xlen'
      local maxlen = max(1, `r(max)')
      format `v' %-`maxlen's
    }
  }
end

[Jean-Claude Arbaut]

Leonardo Guizzetti
You can change column width in the data viewer, the width is stored as a characteristic (conversely, you can change this characteristic to change the width). Do a -char dir- after changing the width to see how it's stored.

[Leonardo Guizzetti]

Leonardo Guizzetti
You can change column width in the data viewer, the width is stored as a characteristic (conversely, you can change this characteristic to change the width). Do a -char dir- after changing the width to see how it's stored.

Thanks for the tip on -characterstics-, Jean-Claude. It is indeed useful if one wishes to modify a small number of columns. My particular use case is accessing read-only datasets for further manipulation, and clinical datasets tend to have many columns per dataset. Setting column width manually each time quickly becomes tedious. I suppose this is a rare situation for most users, but it seems an easy addition to make.

I did notice that th data editor/viewer in Stata 16 adds a "reset column width" in the Tools menu, but that simply resets the width to match the display format.