[FernandoRios]

Something that may or may not be simple within Stata graphics. I wonder if in future developments, it would be possible to control more than 15 groups of colors within a graph using "pstyle" options.
For example, if you plot any figure with up to 15 groups, Stata will use different colors for each group. But if more than 15 groups are used, the color list and style recycle. It would be great if that could be expanded.

[wbuchanan]

FernandoRios
I think this might just be an issue with the number of pstyles defined in the scheme. If a scheme defines fewer than 15 styles those values get recycled sooner. I assume with greater than 15 styles it would push things out further.

[FernandoRios]

Hi wbuchanan
That is what I thought, but I ve been playing with changes in the scheme files, and calling for styles 16 or above gives you an error.
"(note: named style p16 not found in class seriesstyle, default attributes used)"
Of course, we rarely use more than a few groups in the data, so this may not be a problem for most applications, but I have been considering visualization tools with range colors, which may require more than 15 groups (although that can be "hacked")
F

[Nils Enevoldsen]

I'd like a native compressed DTA file format.

For my DTAs larger than a couple dozen megabytes, zstd typically compresses by about 90% in a fraction of a second at the standard level. For smaller DTAs, the typical compression I see is about 50%. (This is after gathering the low-hanging fruit of casting variables to appropriate types.) Fancier variations are possible, but it seems pretty straightforward to support a “.zdta” format that is literally just a compressed .dta.

[Molly Jeffery]

This is small, but would be really useful: ability to jitter scatterplot points by different amounts in the x and y directions. When I create stripplots, it would be nice to be able to spread out the points horizontally without distorting the y-value

[Nick Cox]

I've wanted the suggestion in #380 of jitter() in one dimension only.

#380 has specific reference to stripplot from SSC, in which height() width() msize() and msymbol() all offer handles to turn.

jitter() also comes for free as part of standard scatter options, but I don't willingly use it with stripplot. I would rather use the stack option.

stripplot is best for small or modest sample sizes where the principle of each data point being shown by a visible marker symbol not only makes sense but works legibly.

[wbuchanan]

Make the number of elements passed to the -inlist()- function significantly larger. Being able to include only 7 string tokens at a time is a bit odd. I imagine the restriction might be related to some underlying code written in C or something like that, but it would be great to be able to pass lists of arbitrary length to the function that would work regardless of the type of the elements.

[Asjad Naqvi]

Can we have version checks for user-written or SSC programs please especially when programming ados. For example, if a program calls another program, then, it should flag the user if he/she is using an older version of an already installed program and should upgrade it.

I sometimes get queries that packages have broken down. But this is usually because users have not upgraded Ben Jann's palettes package, etc.

"ado update" already does this checking, so the underlying functionality is there.

[Asjad Naqvi]

FernandoRios: the 15 color limit was exactly the reason for writing the Customizing colors schemes guide to push any number of colors onto the graphs. But here they are mostly to show ranking through graduated colors. Otherwise 15 colors are sufficient but the I agree the functionality should be there and left for the users to decide.

wbuchanan: definitely agree! inlist should allow longer lists. It is a weird roadblock.

[Asjad Naqvi]

Please have an option to preserve labels after reshape!

[daniel klein]

Please have an option to preserve labels after reshape!

We cannot be sure to which exact problem you are referring. I suspect it is related to the behavior of Stata 17, losing value label definitions after reshape, which came up in another thread. If so, then this appears to be a bug and it should be fixed before Stata 18.

[Asjad Naqvi]

We cannot be sure to which exact problem you are referring. I suspect it is related to the behavior of Stata 17, losing value label definitions after reshape, which came up in another thread. If so, then this appears to be a bug and it should be fixed before Stata 18.

The feature doesn't exist in Stata 13, Stata15, and Stata 17. I just checked in all of these.

I read your post for Stata 16 suggesting it does preserve the labels. But I don't remember this and I have since upgraded to v17 so I cannot verify. I wrote this article on customized bar graphs for preserving labels after reshape using Stata v16.1 and it didn't have the label option and one had to jump through hoops to pass it on after reshape.

[daniel klein]

The feature doesn't exist in Stata 13, Stata15, and Stata 17. I just checked in all of these.

If you find the time, could you open a new thread and post a reproducible example? This thread (Wishlist) is not the place to discuss such details.

I have re-run my linked example in both Stata 13 and Stata 17, and each time all labels are there. Perhaps the problem is related to the edition of Stata and/or the OS. I do not have a MP editon and I am on Windows 11.

[Asjad Naqvi]

If you find the time, could you open a new thread and post a reproducible example? This thread (Wishlist) is not the place to discuss such details.

I have re-run my linked example in both Stata 13 and Stata 17, and each time all labels are there. Perhaps the problem is related to the edition of Stata and/or the OS. I do not have a MP editon and I am on Windows 11.

I was just responding to your post about your claim that this is a bug. But please free to start a thread on this separately since a lot of people will benefit from this.

[FernandoRios]

FernandoRios: the 15 color limit was exactly the reason for writing the Customizing colors schemes guide to push any number of colors onto the graphs. But here they are mostly to show ranking through graduated colors. Otherwise 15 colors are sufficient but the I agree the functionality should be there and left for the users to decide.

wbuchanan: definitely agree! inlist should allow longer lists. It is a weird roadblock.

Yes, I also have my own solutions on some of my own programs. I do agree 15 colors is more than enough for many applications, which is why this is more of a real wish list, not needed for most users