Double precision problem

[Christian Thöni]

Dear all

I am using comparisons with variables in double precision and the problem is that extracting cell values to local macros changes precision. Here is an illustration of the problem:

clear
set obs 1
gen double a = 2093.1234567891899
local A=a in 1
assert `A'>a
noi di %20.18g `A'
noi di %20.18g a

The command assert should report an error, but it does not, because the value of `A' is different from the value of variable (this changes if one replaces the last digit of the number of line three by a digit below 5). For float variables I would use

assert float(`A')>float(a)

, but there does not seem to be an equivalent function for double precision, such as

 assert double(`A')>double(a)

.
Any help appreciated.

[Daniel Feenberg]

If you display using the %21x format:

 di %21x `A'
+1.05a3f35ba7015X+00b

. di %21x a
+1.05a3f35ba7014X+00b

you can see that the internal representations differ in the last bit, suggesting Stata uses different rounding conventions in the two cases. See

https://blog.stata.com/2012/04/02/th...sion/#section5.

I have no suggestions, sorry.

[Nick Cox]

The local macro can at best hold a string version of a decimal representation of what is held in your variable in binary. Nothing is changed; your variable A is exactly as you defined it, to the best of Stata's ability; it's just that the local macro isn't guaranteed to do exactly what you want. The keyword here is precision.

Incidentally

local a = A in 1

shouldn't even work but in 1 is seemingly ignored by Stata as trailing garbage.

local a = A[1]

is closer in spirit but as it happens the result is the same.

As what you've done is loosely similar to putting something in a box, and then trying to check that it's there as you put it in, what is the real problem here?

Scalars hold more precision than locals, if that helps.

[daniel klein]

but there does not seem to be an equivalent function for double precision, such as

 assert double(`A')>double(a)

.

That is because there does not need to be. The equivalent is

assert `A' > a

By default, Stata compares in double (and sometimes calculates in quad-) precision.

It should be obvious that Stata cannot magically increase precision after the fact. Once precision is lost by using local macros, not scalars, there is no way of getting back the precision.

Possible solutions (without details about the underlying problem) have been suggested:

scalar A = a[1]

or

local A : display %21x a[1]

will preserve double precision.

[Christian Thöni]

Thank you for your answers. The use of scalars instead of locals and the "display %21x" version do solve the problem.

BTW: I think "local A=a in #" and "local A=a[#]" are equivalent.

[Nick Cox]

You evidently do think that but nothing documented about local
macros shows support of if or in qualifiers.

Experiment shows that at best such qualifiers are ignored, not understood.

[Christian Thöni]

sysuse auto, clear
list price in 1/3
local p=price in 3
di `p'

[Nick Cox]

You're correct. My best line here is that this wasn't allowed that I can recall in earlier versions of Stata. If that's wrong, then I am just wrong. Sorry about that.

It is still a little risky to rely on something not documented.

[daniel klein]

According to syntax diagram

local lmname =exp in #

should not be allowed.

I think this is a bug as becomes more obvious in this example:

. sysuse auto
(1978 automobile data)

. local x = price in 1/3

. display `x'
4099

I do not believe that anyone could have predicted this outcome based on what is documented.

[Christian Thöni]

The syntax with a range of observations still works, just returns the first hit.

sysuse auto, clear
list price in 1/3
local p=price in 2/3
di `p'

I think this can be handy. I would even appreciate if Stata would allow for something like

sysuse auto, clear
list price in 1/3
local p=price if  foreign==1

which would return the first value found for which the condition is satisfied.

[daniel klein]

The syntax with a range of observations still works, just returns the first hit.

You could argue that this really is the worst-case scenario for software: return a seemingly valid result for invalid (undocumented) input and not even do so consistently.

Edit:

OK, you could make the case that

local lmname = varname

is equivalent to

local lmname = varname in 1/L

or, more generally

local lmname = varname in #/#

which always returns the first observation. However, it should be documented that local accepts in ranges then.