Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.
| From | Nick Cox <njcoxstata@gmail.com> |
| To | "statalist@hsphsun2.harvard.edu" <statalist@hsphsun2.harvard.edu> |
| Subject | Re: st: -confirm variable- does not accept varlist (wildcards) |
| Date | Fri, 6 Sep 2013 15:00:16 +0100 |
This is well argued, but it is possible to pick at the details. confirm new variable m* has an interpretation: is it the case that any name beginning with "m" would be acceptable as a new variable name? (The answer would be no if any variable already had such a name.) But it is difficult to see this as a question one might to ask in a program. Interactively, one would be likely to -describe m*- and note the absence. confirm variable m* is, with appropriate modifications to the argument, also a question that makes sense, but not one that I would want to ask (at least using -confirm-). We are in the territory between meaningless in principle and pointless in practice; I think we are a little nearer the second than Robert is arguing. Nick njcoxstata@gmail.com On 6 September 2013 14:41, Robert Picard <picard@netbox.com> wrote: > 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 <njcoxstata@gmail.com> 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 >> njcoxstata@gmail.com >> >> >> On 6 September 2013 08:37, Maarten Buis <maartenlbuis@gmail.com> 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/