Assert – why is false returned for values that appear equal after matrix conversion?

[Anselm Schulz]

version 15

set obs 3

local a = 3.1415927

matrix A = (1\2\3.1415927)

matrix B = A[3,1]

svmat A

svmat B

di `a'

di A[3,1]

di B[1,1]

di A1[3]

di B1[1]

assert `a' == A[3,1]

assert `a' == B[1,1]

Everything is fine so far.

assert `a' == A1[3]

assert `a' == B1[1]

I am confused, why does assert return false for the last two statements? Could anyone explain it to me? Thanks!

[Joro Kolev]

This is because of the type of variables you are generating with -svmat-. If you do the following, the puzzle does not arise:

. svmat double A
number of observations will be reset to 3
Press any key to continue, or Break to abort
number of observations (_N) was 0, now 3

. svmat double B

. assert `a' == A1[3]

. assert `a' == B1[1]

[Anselm Schulz]

Thank you for the explanation!

[Nick Cox]

Some pitfalls in this territory:

1. svmat by default produces float variables. To preserve maximum precision, insist on double to store result variables.

2. Locals hold fewer digits accurately than scalars. (Locals are always strings in essence, even when the string includes only numeric characters.)

3. display can be helpful here, but it can be an untrustworthy reporter on exact contents if you let it choose the (default) format.

To compare constants and (what should be) the same constants held in variables, holding constants in scalars and variables as double is the best strategy.

[Anselm Schulz]

Thank you Nick for your deeper elaboration of the topic. Do I understand you correct - all numbers should be stored as scalars if possible?

[Nick Cox]

If you care about maximum precision and reproducibility you will use scalars. But most uses of locals are fine, as when you use locals for smallish integers. Your example is an 8 digit approximation to pi, which itself is transcendental and can only be held approximately, but it's rare that real data and real results require indefinite precision. The main reason in my experience for high-digit displays with Stata is to check that programs give identical results when they should, not to meet any empirical or theoretical need.

[Anselm Schulz]

Thank you for further clarification!

[Joro Kolev]

On top of what Nick explained in #4 and #6 above, there is another pitfall with the scalars: Scalars share the same name space as variables, and this causes all types of headache. Even if you are aware of the issue, you always need to be watching over your shoulder.

See this Stata Tip I wrote: Kolev, G. I. (2006). Stata tip 31: Scalar or variable? The problem of ambiguous names. The Stata Journal, 6(2), 279-280.

If you are still new to Stata and still are forming your habits, I would recommend that you learn how to use locals, and avoid scalars whenever possible.