[Dirk Enzmann]

Well, whatever the solution: To my mind it is not acceptable that a standard Stata analysis command produces a wrong result as a side-effect (as demonstrated in my examples) or that a genuine Stata command such as recode creates an error message (the programmer of the recode command at StataCorp obviously followed the bad advice to use a temporarily named scalar instead of using the pseudo-function scalar() which is the only safe thing to do as along as the problem I described persists). It would be interesting to know how many .ado-programs and genuine Stata commands are using temporarily named scalars and thus are running the risk to produce wrong results.

[Ariel Karlinsky]

I suggest that stata allows the user to set the default alignment (left or right) of string variables.
See here: http://www.statalist.org/forums/foru...35#post1340735

[Clyde Schechter]

It's a good question why the default is right-alignment. Only StataCorp could tell you why they made that choice. But there is one advantage to right-alignment that I'm aware of: when you create tabular output, and you have a string variable in the stub, it is easier to read across the rows of the table with right aligned strings, because there is no block of whitespace following the shorter stubs tempting your eye to drift to a lower or higher row when it gets to the numbers in the cells.

[Nick Cox]

What's the precise wish here on left alignment? Clearly Stata allows you to specify a format that is left-justified. If you want to make some or all of your string variables left-justified, that sounds like

ds, has(type string) 

foreach v in `r(varlist)' { 
    local fmt : format `v' 
    if substr("`fmt'", 2, 1) != "-" local fmt = "%-" + substr("`fmt'", 2, .) 
    format `v' `fmt' 
}

which could be wrapped up in a program if anyone wanted. No obvious need, therefore, to ask anything of StataCorp.

If "some", then you need to specify which to ds.

[Robert Picard]

Nick, I don't understand your point. I can't imagine that you are arguing that users should be able to come up with the code you posted if all they want is to change the alignment of a few string variables. Of course it can be wrapped into a program and, as you know, that's what leftalign (from SSC) does. So the suggestion in #77 could be interpreted as Stata should have a built-in command to perform the task. However, I think that what Ariel had in mind is something akin to set type that lets the user choose the default storage type assigned to new variables (either float or double). So you could have something like:

set align {left|right}

and all new string variables would have default string format alignment. Of course you would still need a command (built-in or user-written) to change the alignment if the default is not what's needed. Note that the leftalign package also comes with a rightalign command.

[Nick Cox]

Indeed; I was wondering whether that was what someone wants but I want people to say precisely what they want.

If StataCorp provide this set ability for new string variables the point remains that existing string variables would be unaffected, which again makes me wonder whether it is really what people are asking for.

I don't expect people to know how to solve the problem; I just point out that nothing much depends on StataCorp's doing or not doing this.

[Robert Picard]

Clyde, as someone who suffers from reading difficulties, I can assure you that

    make            rep78  
    AMC Concord         3  
    AMC Pacer           3  
    AMC Spirit          .  
    Buick Century       3  
    Buick Electra       4

is easier to read than

              car   rep78  
      AMC Concord       3  
        AMC Pacer       3  
       AMC Spirit       .  
    Buick Century       3  
    Buick Electra       4

I'm also pretty sure that a journal would prefer having the table on top rather than the one on the bottom. Why did StataCorp choose to left align the make variable in the auto dataset?

[Robert Picard]

Nick, it's just a wish, and #77 did say "set the default alignment (left or right) of string variables".

[Nick Cox]

Quite so, and as our conversation showed. that still leaves open how to do it, and whether that means that a set would automatically flip the format of existing variables.

I am naturally happy to believe that this would be a worthwhile addition. As StataCorp can take a decade to do things, it's always germane to stress what can be done now.

[ben earnhart]

Import SAS files. Ideally, it should be possible to import a .sas7bcat file alongside the .sas7bdat to get value labels, but I'd be happy with just importing .sas7bdat files.

[Joseph Coveney]

On the subject of being able to set additional defaults for display, I'll add for the umpteenth time

set datetime_displayformat ISO_8601, permanently // { any valid %tc | ISOT8601 | ISO_8601 }
display c(current_date)
update query
format dob %td
format *_dt %tc

[Aaditya Dar]

Hi, I am not sure if this is feasible (or if this has been noted before) but it would be really helpful if variables had their own attributes/arguments/method. I don't know what the correct technical term is but here's an example of what I have in mind: currently, one has to save results from r() or e() in case one plans to use them later in the .do file but if one could call on, say, the mean as: var.`r(mean)' or var.mean() that would make programming in Stata even more convenient. Thanks for considering this!

[Nick Cox]

Aaditya: You can already save constants as locals or scalars and give them evocative names. What extra are you asking for?

[wbuchanan]

Nick Cox it looks like Aaditya Dar is looking for something analogous to Stata treating variables as independent objects on which methods could be called. So numeric variables might have methods that exist in egen or other commands and could be called directly in other operations like:

replace var1 = var2 + var3.mean()

Instead of first calling summarize on a variable.

[Aaditya Dar]

You are absolutely right, Nick. I was trying to suggest a way to call on these without having to save them, just like William noted in his example. (Thanks William!)