Storage type of a new variable

[Gabor Mihala]

. clear all
. set obs 1
. gen var=20190417 // today's date in a custom format
. format var %10.0g // so the full number can be seen in the editor
. list

+----------+
| var |
|----------|
1. | 20190416 |
+----------+


I have fallen into this trap many times until I realised that Stata thinks 20190417 equals to 20190416 ...

These days I use gen long but still, this should not happen.

Any thoughts?

[Joseph Coveney]

Any thoughts?

If you haven't already done so, you'll want to take a look at the help files for working with dates in Stata and for working with different types of data in Stata.

[Gabor Mihala]

Thanks Joseph, I'm familiar with the references you provided. I think Stata should be smart enough not to change the values I prescribe:
. gen var=123456789
. format var %12.0g
. list var
+-----------+
| var |
|-----------|
1. | 123456792 |

[Nick Cox]

Stata's smart enough to change decimal input to binary approximation and show you decimal results. By the same token Stata should be smart enough not to change 1.1 to something else, but it has to.

It's not the answer you want, but a key principle behind Stata is that you are smart enough to read the documentation and to be responsible for your own code, and this particular issue is explained prominently and repeatedly.

In essence you want the syntax you type to be parsed bearing in mind the consequences of an operation. In this case, you want the parser also to look at the result and on the fly change your syntax generate to the equivalent of generate long

That would be a very big deal and ultimately it is impracticable if not impossible. It may seem obvious for big integer output, but your Utopian goal would bite you almost every time you did something a little bit more complicated such as take a square root or a logarithm. Do you want intelligence inside Stata to give you, automatically, a double because otherwise you would not get the maximum precision that is possible?

[Joseph Coveney]

I think Stata should be smart enough not to change the values I prescribe:

It's not able to store the value at full precision using the out-of-the-box default numeric data type for new variables, which is single-precision floating point. As Nick mentions, the issue with precision is described in the documentation in several locations, for example, in the second hyperlink in my post above, you'll see that both of your illustration integers exceed the the maximum that can be stored with the out-of-the-box default of single-precision floating point.

Moreover, as Nick mentions, Stata has limited ability for type coercion. In particular, it seems reluctant to promote single- to double-precision floating point.

.ÿ
.ÿversionÿ15.1

.ÿ
.ÿclearÿ*

.ÿ
.ÿquietlyÿsetÿobsÿ1

.ÿ
.ÿquietlyÿgenerateÿfloatÿxÿ=ÿ.

.ÿquietlyÿgenerateÿbyteÿyÿ=ÿ.

.ÿformatÿxÿyÿ%10.0f

.ÿ
.ÿ//ÿNoÿcoercion
.ÿreplaceÿxÿ=ÿ123456789
(1ÿrealÿchangeÿmade)

.ÿlistÿx,ÿnoobs

ÿÿ+-----------+
ÿÿ|ÿÿÿÿÿÿÿÿÿxÿ|
ÿÿ|-----------|
ÿÿ|ÿ123456792ÿ|
ÿÿ+-----------+

.ÿ
.ÿ//ÿHoweverÿ.ÿ.ÿ.
.ÿreplaceÿyÿ=ÿ123456789
variableÿyÿwasÿbyteÿnowÿlong
(1ÿrealÿchangeÿmade)

.ÿlistÿy,ÿnoobs

ÿÿ+-----------+
ÿÿ|ÿÿÿÿÿÿÿÿÿyÿ|
ÿÿ|-----------|
ÿÿ|ÿ123456789ÿ|
ÿÿ+-----------+

.ÿ
.ÿexit

endÿofÿdo-file


.