No; this is backward. It's the argument that is problematic, not the
result.
The possible length of the value label, i.e. a string, is not biting
here. It is the fact that you are dealing with a large integer, on which
more is said elsewhere.
The refusal of -tostring- to produce a string variable in your example
is easy to explain. -tostring- is a wrapper for -string(<real argument>,
"<format>")- with several safety checks and constraints. The format
defaults to %12.0g. Some experiments show that you need a different
format for the conversion of 9...9 (12 digits) to be reversible.
. di string(999999999999, "%12.0g")
1.00000e+12
. di string(999999999999, "%13.0g")
1.000000e+12
. di string(999999999999, "%14.0g")
999999999999
So, -tostring- will work as desired here so long as a suitable
-format()- is specified.
Nick
[email protected]
Caleb Southworth
That's right. You cannot have a label that long. So:
. tostring var, g(var2)
var cannot be converted reversibly; no generate
. tostring var, g(var2) force
var2 generated as str11
var2 was forced to string; some loss of information
Perhaps -mvdecode- would be the way to go. So:
mvdecode var, mv(999999999999)
then, to use codebook or whatever,
mvencode var, mv(999999999999)
*
* For searches and help try:
* http://www.stata.com/help.cgi?search
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
