confirm scalar, number, numeric

[Alfonso Sánchez-Peñalver]

I have just realized something when developing a program to do a likelihood ratio test on the boundary. I wanted to check whether the arguments passed (log-likelihoods of the restricted --nested-- model and of the unrestricted --containing-- model) were numbers. When I checked help confirm I saw that you had the following options that deals with numbers:

1. confirm [numeric | string | date] format string
2. confirm [integer] number string
3. confirm scalar string

Here is what I've found. If I store the log-likelihoods as scalars after estimations (e.g. scalar llu = e(ll)) then option 2 throws an error, and you have to use option 3. If I store the log-likelihoods as local macros (e.g. local llu `e(ll)') then option 3 throws an error and option 2 is the way to go. Option 1 throws an error either way I store the log-likelihood. So I've had to check for both nesting them thus

capture confirm scalar `llr'
if _rc {
    capture confirm number `llr'
    if _rc {
        di as error "llr has to be a number"
        error 198
    }
}

I'm sure that there are reasons for both options. Can someone tell me if there's an easier way to check if an argument passed into a program is a number independent of how it's stored by the user?

[Nick Cox]

These are good questions as it takes some thought to work out exactly what is happening.

A number cannot be a legal display format, so #1 is a non-starter. In other words, the syntax here for confirm is whether a string offered defines a (legal) display format e.g. %3.1f, %12s do specify legal formats. The first is a legal numeric format, and so on. The test is not whether a number is of a specified format, a question which is essentially confused so far as Stata is concerned. Numbers are not defined by any display formats you happen to use to display them! This is one of the most common confusions in Stata, even among experienced users, and the fault lies largely in the overloading the word "format" receives among computer and data people and the inconsistency between software in what is and is not a format. (In Stata format does not mean dataset structure, and it does not mean variable (storage) type, for example.)

A local macro is not a Stata scalar; the test for being a scalar is syntactic, not mathematical. That is #3. Actually, the test is not of the local macro, as confirm never sees it, as the quotation marks force an evaluation; in this case it just sees the numeric value, which is not a scalar.

As far as #2 is concerned. the problem is that you are presenting a name and expecting Stata to evaluate it and say whether the value is numeric. But confirm doesn't do that. Stata does explain this (at least it thinks it does). Forcing an evaluation is the way to go.

. scalar foo = 42

. confirm number foo
'foo' found where number expected
r(7);

. confirm number `= foo'

Although it's a not good answer, sometimes an arbitrary test such as whether you can add 1 without error is good enough in practice.

[Alfonso Sánchez-Peñalver]

Hi Nick,

thanks for your suggestion it works as a charm. I do understand why there ought to be the three different options, but it is somewhat confusing when you're trying to check an argument and the user can pass it more than one way. I guess what confuses me is what you can write within the `' set of quotes, which I wasn't really aware. I normally use them to just refer to local macros (tempnames as well), I didn't know you could write more in them. Where in the reference can I go to learn more about this?

I actually thought to "convert" the argument into a scalar with capture scalar foo = `foo' and check there. If the argument is numeric it should set it, but if it's not it should give the error. But I'm glad I asked, because now I know that I can force an evaluation within the `' quotes.

[Nick Cox]

Explained at

help macro

[...] `expansion_optr' [...]


where expansion_optr is

lclname
++lclname
lclname++
--lclname
lclname--
=exp

It follows that `= exp' is allowed syntax in command lines whenever an expression exp returns a constant result.

[Alfonso Sánchez-Peñalver]

Thanks Nick!