Bookmark and Share

Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: st: -confirm variable- does not accept varlist (wildcards)


From   Nick Cox <[email protected]>
To   "[email protected]" <[email protected]>
Subject   Re: st: -confirm variable- does not accept varlist (wildcards)
Date   Fri, 6 Sep 2013 09:39:20 +0100

I agree with Maarten's stance here, but (away from -confirm-) there
are situations in which temporary variables can be wildcarded.

Some commands require a stub to be specified and then they -generate-
(or generate) new variables <stub>1, <stub>2, and so forth. -separate-
and -tabulate- are examples.

If you need these new variables within a program, and only
temporarily, then a natural device is something like

tempname foo
separate myvar, ... gen(`foo')

I often do this within graphics programs. How are subsets to be
represented differently? By putting them in different (and new)
variables.

In this case -separate- returns r(varlist) but a wildcard `foo'* would
also work as a temporary name will be just 8 characters long
underneath the hood, and will be something like __000007 with a
licence to hold data. So the variables will be created as __0000071,
__0000072, and so forth.

This is living a little dangerously, as I believe that StataCorp have
_nowhere_ promised that the real names underlying temporary names will
remain 8 characters long. In fact, I doubt that they want to promise
anything except that temporary names will remain temporary. Should
StataCorp ever make temporary names as long as the maximum name length
allowed, then adding suffixes like this will no longer work (although
it would be nice if it were protected by version control).

Nick
[email protected]


On 6 September 2013 08:37, Maarten Buis <[email protected]> wrote:
> On Thu, Sep 5, 2013 at 5:29 PM, Joe Canner wrote:
>> I'm intrigued by your last sentence in #2.  Are you've saying you've never had occasion to use wildcards in varlists, or that there are alternatives?  For example, suppose you wanted to do something with all system-generated variables _*, knowing that these might be scattered around the dataset and not contiguous.  How would you do that without wildcards?
>
> Nick, already stated that he did not use wildcards in combination with
> -confirm-. Let me speculate why that is the case. When programming you
> typically allow varlist including wildcards to be specified by the
> user, but that input is parsed at the very beginning by the -syntax-
> command. One of the things that the -syntax- command does is that it
> unabreviates varlist and passes that on to a local macro that the
> programmer uses in the rest of the program. So, after the -syntax-
> command there are no longer any wildcards in the user input. It may
> happen that the program creates (temporary) variables. There again I
> would never use wildcards to refer to those variables, because it may
> happen that there are already variables in the dataset that conform to
> that pattern with wildcards, and thus break your program. Typically,
> you create the variables and store their names in a local macro and
> refer to that local macro further on in the program. So when
> programming in Stata wildcards almost never appear after the -syntax-
> command, which is usually one of the very first commands inside a
> program.
>
>> You said " I am not sure how confirm *should* work with wildcards".  According to the -confirm- documentation, not only should -confirm var- work with a varlist, but they even give an example of using it with multiple variables.
>
> An example with multiple variables does not indicate whether or not
> wildcards should be allowed. What is relevant is the statement in the
> helpfile that it refers to a varlist, and it provides a link to the
> help-file that defines what a varlist means in Stata: -help varlist-.
> This definition includes wildcards. So it sounds to me that the
> helpfile is somewhat unclear about this point and the error message
> could be improved.
>

*
*   For searches and help try:
*   http://www.stata.com/help.cgi?search
*   http://www.stata.com/support/faqs/resources/statalist-faq/
*   http://www.ats.ucla.edu/stat/stata/


© Copyright 1996–2018 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   Site index