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
Robert Picard <[email protected]>
To
"[email protected]" <[email protected]>
Subject
Re: st: -confirm variable- does not accept varlist (wildcards)
Date
Fri, 6 Sep 2013 09:41:20 -0400
I agree that the help on -confirm- is a bit unclear. However, the
following is at the very top of the help file:
"confirm verifies that the arguments following confirm ... are of the
claimed type and issues the appropriate error message and nonzero
return code if they are not."
The word "type" here does not mean storage type (i.e. string or
numeric). It applies to file, matrix, scalar, as well as variable.
Thus -confirm variable- checks that what's in varlist are variables.
Using wildcards to confirm a new varlist makes no sense (e.g. -confirm
new variable m*-). The same is true when checking for the existence of
variables (e.g. confirm variable m*). Adding a specific type just adds
an additional condition to check.
On Fri, Sep 6, 2013 at 4:39 AM, Nick Cox <[email protected]> wrote:
> 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
*
* 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/