[William Lisowski]

Regarding #585

It is disconcerting to realize that my intuition on how the cond() function works has been incorrect. I've always casually thought of it as roughly equivalent to if-then-else. Clearly that was poor intuition.

I wonder if

cond(x,a(z),b(z))

evaluates both a(z) and b(z) before evaluating x, rather than using x to choose which one of them to evaluate for the current observation? If this is the case, then if b(z) more difficult to evaluate than a(z), but x is usually true, then Stata will work harder to evaluate

generate y = cond(x,a(z),b(z))

than it would to evaluate

generate y = a(z) if x
replace y = b(z) if !x

It also seems to suggest that nested cond()'s may in some cases extract a performance penalty for the same reason - everything to the right of the first argument of the outermost cond() will be evaluated.

cond( x<100, a(z), cond( x<1000, b(z), c(z) ) )

[Ali Atia]

Further discussion on the cond() issue is available at this thread: Strange behavior by -cond()- and -ustrregexs()- - Statalist

[Leonardo Guizzetti]

In response to #585, I think this is more a problem with setting up the regex object behind the scenes than with cond() per se as I have had similar “off by 1” behaviour using similar functions in the context of loops.

[Bjarte Aagnes]

The cond() function used in generate should behave like expected from a ternary conditional operator. Now the cond() function evaluates the returned values first, before evaluating the condition:

clear
set obs 10
gen v1 = "a" + strofreal(_n, "%2.0f")

gen condfail = cond(ustrregexm(v1, "[^\d](\d)$"), ustrregexs(1), "")

gen wanted = ustrregexs(1) if ustrregexm(v1, "[^\d](\d)$")  

list

. list 

     +-------------------------+
     |  v1   condfail   wanted |
     |-------------------------|
  1. |  a1                   1 |
  2. |  a2          1        2 |
  3. |  a3          2        3 |
  4. |  a4          3        4 |
  5. |  a5          4        5 |
     |-------------------------|
  6. |  a6          5        6 |
  7. |  a7          6        7 |
  8. |  a8          7        8 |
  9. |  a9          8        9 |
 10. | a10                     |
     +-------------------------+

[daniel klein]

#582: Despite the lack of empirical evidence, I guess those undocumented commands are true of little interest to most Stata users; probably not those highly active on Statalist, though. I would not mind those commands being documented. However, given limited time and resources, I would rather see StataCorp implement new features or speed things up (e.g., reshape, graphics, etc.) than spend time writing pdf documentation for commands where help files should suffice for those selected few who use these commands.

Frankly, I am more concerned about the statement that

[u]ndocumented commands may change their syntax or behavior in subsequent releases of Stata

which is really unfortunate for those who rely on these commands in a programming context. If anything, I wish StataCorp would put undocumented commands under version control just like any other command.


Edit:

If you like varclassify, have a look at

help vl

[Cayman Seagraves]

I hope that Stata 18 has code-folding hotkeys. This hotkey could be used to automatically close all sections of a code that are included by curly brackets, which look like this { }.

[John Mullahy]

Over the years there has been occasional discussion of why there are "documented" undocumented commands and options in Stata. (See help undocumented). While Stata presumably has good reasons for this designation I would hope that for v18 its staff might evaluate item-by-item whether any particular item should remain undocumented.

The assertion at the top of the help file is:

An undocumented command is a command of very limited interest, usually interesting only to Stata programmers, and is used by StataCorp in developing Stata.

I do wonder about the evidence base for the "very limited interest" claim.

For what little it's worth some of the undocumented items I've found valuable (sometimes highly valuable) include:

[R] margins, generate()
[FN] rpareto()  
[G-2] gs_fileinfo
[G-2] twoway__histogram_gen
[M-5] rdirichlet()  
[M-5] vech_lower()  
[P] varclassify

Others may have found different undocumented items to be valuable in their work.

[Stephen Jenkins]

#580. Please provide more details about the problems that you perceive; otherwise there is little to discuss. (In my opinion, because Stata's graphics are incredibly flexible, users can create extremely sophisticated graphs, mainly using -twoway-. It's analogous to graphics in R. Basic defaults may not be what you want or like but packages such as ggplot enable users to tailor defaults to meet their needs.)

[Akif Alig]

Please improve the graphs in STATA-18.
Of all the software it competes with, STATA has the worst visuals and graphics.

[Leonardo Guizzetti]

Another question is about legend option. Why order(orderinfo) and label(labelinfo) employ quite different syntax grammar? Could label() employ the same grammar as order(), i.e. label(1 "text" 2 "tetxt" 3 "text" 4 "text"...)?

sysuse auto
gen id=_n
foreach v of varlist price mpg weight length {
egen std_`v'=std(`v')
}

twoway line std_price std_mpg std_weight std_length id, legend(row(1) label(1 "price") label(2 "mpg") label(3 "weight") label(4 "length"))
twoway line std_price std_mpg std_weight std_length id, legend(row(1) order(1 "price" 2 "mpg" 3 "weight" 4 "length"))

Possibly your confusion arises from the apparent duplicate function of order and label, but order can simply be used to indicate a numeric list of the order of elements to display. In this way, you can separate ordering and labeling concerns.

[Chen Samulsion]

Another question is about legend option. Why order(orderinfo) and label(labelinfo) employ quite different syntax grammar? Could label() employ the same grammar as order(), i.e. label(1 "text" 2 "tetxt" 3 "text" 4 "text"...)?

sysuse auto
gen id=_n
foreach v of varlist price mpg weight length {
 egen std_`v'=std(`v')
 }

twoway line std_price std_mpg std_weight std_length id, legend(row(1) label(1 "price") label(2 "mpg") label(3 "weight") label(4 "length"))
twoway line std_price std_mpg std_weight std_length id, legend(row(1) order(1 "price" 2 "mpg" 3 "weight" 4 "length"))

[Chen Samulsion]

Would it be reasonable to optimize lookofbar_option? I mean the bar(#, barlook_options), could Stata allow numlist in #? Say bar(numlist, barlook_options)...

sysuse auto
graph bar price, over(rep78) legend(row(1)) bargap(20) asyvars bar(1, bcolor(%50)) bar(2, bcolor(red%50))...
graph bar price, over(rep78) legend(row(1)) bargap(20) asyvars bar(1/5, bcolor(%50 red%50...))

[Chen Samulsion]

Dear Maarten Buis, thank you for your reply and I couldn't agree with you more. In fact I have found Roger Newson's -xcollapse- and -xcontract- after I post in #565. The two commands allow me to save the collapse or contract output data to a disk file, and to which I can conveniently switch using frame command. I think the idea of this procedure is quite in accord with yours.
And with an integrated frame command that was wrote with some tricks (I don't show it here), the practice of switching to the new created data file will be more easily.

sysuse auto
xcontract rep78 foreign, saving(filename)
frame command ...

[Maarten Buis]

Chen Samulsion for #565 Would instead a syntax like collapse, force frame(new_frame_name) work better? My idea would be that that would make a new frame (new_frame_name) with the collapsed data in it and change to that frame.

[Chen Samulsion]

Will ustrregexm be truncated as uregexm, and ustrregexrf be truncated as uregexrf? The function name with 10 characters is not too long to endure, but the -rr- -e~e- -~x- is too easy to induce typos.