[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

[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]

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.

[Ali Atia]

That would be a very strange behaviour for the capture command. I would rather have

drop var1 var2, force

as an option in the command. I still think this is not a very good option. If you absolutely need this behaviour you can also program it yourself with something along the lines of:

program define checkvars, rclass
syntax namelist

unab varlist: *
return local newvars: list namelist - varlist
return local vars: list namelist & varlist
end

checkvars var1 var2 var3 var4
drop `r(vars)'

I believe you meant to respond to #371 -- we are in agreement that altering the behavior of capture in this way wouldn't be a good idea.

[Daniel Fernandes]

Seconding #372. Also -- if a captured command "partially" succeeds, what is the return code stored in _rc? Is it 0, because of "partial" success, or is it (in this case) 111, because of "partial" failure? This would likely mess with a lot of the traditional usage of capture to lead in to a conditional argument based on the value of _rc.

That would be a very strange behaviour for the capture command. I would rather have

drop var1 var2, force

as an option in the command. I still think this is not a very good option. If you absolutely need this behaviour you can also program it yourself with something along the lines of:

program define checkvars, rclass
  syntax namelist

  unab varlist: *
  return local newvars: list namelist - varlist
  return local vars: list namelist & varlist
end

checkvars var1 var2 var3 var4
drop `r(vars)'

[Ali Atia]

Seconding #372. Also -- if a captured command "partially" succeeds, what is the return code stored in _rc? Is it 0, because of "partial" success, or is it (in this case) 111, because of "partial" failure? This would likely mess with a lot of the traditional usage of capture to lead in to a conditional argument based on the value of _rc.

[daniel klein]

Veto #371. First, such a change would violate the (implicit) rule of "do it all or do nothing at all", which is implemented pretty much throughout Stata and ensures that you will never have to guess on the current state of the dataset.

More generally, while I see how the behavior can be frustrating in this situation, a change would necessarily lead to inconsistencies. If

capture drop x y z

would drop only existing variables then

drop x y z

would need to do the same. This is because capture does not change the behavior of any other command. If it did, we would need to look up the specific modifications capture did to each specific command. This is clearly way more inconvenient than the current (predictable) behavior.

If instead, we changed the way drop works, we would not even need capture. The problem with that is that whenever a command is referring to a varlist, it refers either to existing variables or to new variables, never to a mixture. Commands that may refer to existing and new variables, e.g., generate, have these groups of variables clearly separated in their syntax diagram.

Changing drop would also be inconsistent with keep because we can obviously not keep variables that do not exist.

[George Ford]

I would like for -capture drop x y z- to work even if one the variables does not exist. Now, if there was no y, then it would not delete x or z. As a result, I have to use multiple lines of code when one should do.

[Leonardo Guizzetti]

I've become quite fond of the -describe using-.

It would be nice when working with large datasets to peek into the first or the last rows.
I suggest options for -use- like -use var1 var2 using "dataset.dta" in 1/100, last- to see the last 100 rows for var1 and var2 in "dataset.dta".

If a min/max/missing report could be saved in the dataset as metadata, that would be nice too. Maybe this should be an option to -save-.

The usual -in- range for the last observations would be as below (not the final character is a lower case L).

mycmd in -100/l

[Niels Henrik Bruun]

I've become quite fond of the -describe using-.

It would be nice when working with large datasets to peek into the first or the last rows.
I suggest options for -use- like -use var1 var2 using "dataset.dta" in 1/100, last- to see the last 100 rows for var1 and var2 in "dataset.dta".

If a min/max/missing report could be saved in the dataset as metadata, that would be nice too. Maybe this should be an option to -save-.

[daniel klein]

It would be nice to have a convenient one-step command to copy value labels from one frame to another. You can accomplish it by copying any variable to which that value is attached (assuming there is one, which isn't always the case) into the second frame, and then apply that label to the desired other variable and then drop the one you brought in. Or you can -label save- the label from the original frame to a tempfile and -run- it in the other.

It could be even simpler than that. To copy a value label to the current frame:

frame other_frame : mata : st_vlload("lblname", values=., labels="")
mata : st_vlmodify("lblname", values, labels)

To copy a value label to another frame:

mata : st_vlload("lblname", values=., labels="")
frame other_frame : mata : st_vlmodify("lblname", values, labels)

I see how a more general and robust approach would be convenient.

[Clyde Schechter]

It would be nice to have a convenient one-step command to copy value labels from one frame to another. You can accomplish it by copying any variable to which that value is attached (assuming there is one, which isn't always the case) into the second frame, and then apply that label to the desired other variable and then drop the one you brought in. Or you can -label save- the label from the original frame to a tempfile and -run- it in the other. But it wold be convenient to be able to do it in a single command.

[Ali Atia]

Seconding #364. At present it is easy enough to record actions in the graph editor and copy paste them into a gr_edit command, but it would be great to have documentation on how to write those commands from scratch.

Better yet, it would be great to be able to do everything that can be done via the graph editor within the original graph or twoway command used to generate a graph, which sometimes seems impossible (recent example here: https://www.statalist.org/forums/for...bol-color-size)

[Clyde Schechter]

`
EDIT: Sorry--no intended post here. Cat walked on the keyboard and somehow that led to a save.

[Lili Bulfone]

It'd be useful to have some documentation on the gr_edit command