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   Joe Canner <[email protected]>
To   "[email protected]" <[email protected]>
Subject   RE: st: -confirm variable- does not accept varlist (wildcards)
Date   Fri, 6 Sep 2013 14:00:54 +0000

Bearing in mind Maarten's previous comments about the inadvisability of using wildcards with -confirm- (especially given that it is meant to be used in programs), I don't think it is fair to say that it "makes no sense".  If you wanted to know whether there were any variables in a data set that started with "m" (perhaps for the purpose of adding some new variables that start with "m"), -confirm variable m*- seems like it would be at least one sensible (albeit overly conservative) way to proceed.  It might make even more sense to use -confirm [type] variable m*- to see if a group of variables had the type you expected.

Granted, this might be a little contrived and probably not appropriate for a generalized program, but perhaps it might be appropriate for a personal do-file where you had some control over the incoming data and didn't want to write a generalized program.

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Robert Picard
Sent: Friday, September 06, 2013 9:41 AM
To: [email protected]
Subject: Re: st: -confirm variable- does not accept varlist (wildcards)

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/

*
*   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