input a
88888888
99999999
end
export excel a.xlsx, replace
Then, if I open the excel file, the numbers are shown as 8.89e+07 and 1.00e+08. How can I restore these to the original numbers. Do I have to do this in Excel? Is there any way to prevent Stata from converting those numbers to the "scientific" format?
The effect of your input command is to read those numbers into variables of float type. But there aren't enough bits in a float to hold 99999999 exactly. This is well documented.
See e.g. the help for data types:
"floats have about 7 digits of accuracy; the magnitude of the number does not matter. Thus, 1234567 can be stored perfectly as a float, as can 1234567e+20. The number 123456789, however, would be rounded to 123456792. In general, this rounding does not matter.
If you are storing identification numbers, the rounding could matter. If the
identification numbers are integers and take 9 digits or less, store them as longs;
otherwise, store them as doubles. doubles have 16 digits of accuracy."
So you degraded your data by using an inappropriate data type. That is the issue, not export excel.
Related
When I try to convert Large number (ex: 8996609817110286118) from General to Number, the result becomes: 8.99661E+18 ( 8996609817110280000), It forces this approximation, which I don't want)
Before Changing
After Changing to Number
There's no exact number representation in excel for numbers this big. You can either use strings instead of numbers (see this post), or live with the reduced accuracy. You did not specify what these numbers represent, but there are almost no applications that require physical quantities to be that accurate.
Regarding Excel 2007 (though it may pertain to other versions):
I want to apply Excel Data Validation to manually inputted data. In this particular case, the input is of the form NN.nnnnh, where the digit "h" is a "half-digit". That is, it can either be 0 or 5.
The spread-sheet converts land-surveying that is manually entered in the form of Feet, Inches, and 16ths of an inch, into decimal feet
The function of the half-digit is to allow the optional higher-precision to 1/32nd of an inch.
For example:
43.0913 is the raw entry for 43 feet, nine inches, and 13/16ths of an inch.
Now, by adding the half-digit in the fifth decimal place, a precision of 1/32" can be expressed.
For example:
27.08135 is the manual entry for 27 feet, 08 inches, and (13.5/16=) 27/32nds of an inch.
The raw input NN.nnnnh is decomposed and converted into feet as a decimal number, using Excel TRUNC function. This manner of conversion is analogous to the more familiar conversion of angles entered as D˚M'S", into DD.dddddd).
I want to assure that the 5th decimal place, manually entered, is ONLY Zero or 5.
I can separately apply logical tests to determine if the fifth-decimal entry is Zero, or 5.
But, when I combine those separate logical tests using the =IF(OR( structure, I get inconsistent results IFF the manually-entered data has an integer value (i.e., in the NN.nnnnh format, any length of just one foot or greater, manually entered as >= 1.00000). Unless I undertake the surveying of table-top architectural scale models, this has serious limitations !!!
I have attached an example spreadsheet to illustrate the formulae used and the results. If anybody can shed some light on this, it would be appreciated.
(If there is a way to simply Attach a *.xlsx example....please let me know. I had intended to do this, and then discovered that it seems to be impossible!)
Use MROUND to test if the number is the same:
=A1=MROUND(A1,0.00005)
How does excel determine what to number to display? specifically the number of decimal places
for example:
50.98, when stored as a single-precision float is 50.979999542236328125
50.979999 is also stored as the exact same single-precision float
(binary rep. 01000010010010111110101110000101, taken from here: https://www.h-schmidt.net/FloatConverter/IEEE754.html)
when i type 50.98 & 50.979999 into 2 cells, change format to number, and extend out the decimal places using the formatting button
it represents them exactly as 50.98 & 50.979999, as i originally typed.
how is that working? is excel storing the exact text i typed and not (directly) storing the float data type at all?
if it stores it as a double, how does it preserve the exact precision i originally typed in that case?
i can't find documentation outlining how this works.
Note its not causing me any problems, i just need an explanation for differences in how excel displays vs calculations based on those values.
it represents them exactly as 50.98 & 50.979999, as i originally typed.
Excel is padding with zeros after 15 significant decimal digits.
The internal number is encoded with a high enough binary precision such that limiting output to 15 deimcal places, the original typed in decimal values appear to be exactly that.
=2/3 is an informative example showing this limit and exposing the binary internals by carefully extracting out a bit at a time.
As displayed in one cell, decimal output rounds to 15 places, padding with zero after that.
0.66666666666666700000000
The below does a binary conversion of =2/3 and forms 0.101010101010101010101010101010101010101010101010101012, exactly what is expected if Excel used a binary64. (Below)
OP's observations are consistent with using binary64 and rounding output as decimal text to 15 significant digits.
Cell A3: =FLOOR(B2*A$1,1), Cell B3 = =B2*A$1 - A3
Hypothesis: When displaying a number, Excel first converts a number to a decimal numeral with at most 15 significant digits even if more are requested. If additional digits are requested, they are filled in as zeros. (In addition, Excel may apply other alterations depending on context.)
In Microsoft Excel 2008 for Mac, I entered =1+22*POWER(2,-52) in A1 and =1+23*POWER(2,-52) in A2. Using IEEE-754 binary64, these should generate the numbers 1.000000000000004884981308350688777863979339599609375 and 1.0000000000000051070259132757200859487056732177734375. Entering =A1-1 and =A2-1 in B1 and B2 and setting these to Number format with 30 decimal places shows “0.000000000000004884981308350690” and “0.000000000000005107025913275720”, which is consistent with IEEE-754 binary64. So we have some assurance the numbers above were indeed generated and stored in Excel.
Setting A1 and A2 to Number format with 20 decimal places shows “1.00000000000000000000” and “1.00000000000001000000”.
Clearly, if Excel were displaying the actual numbers with 20 decimal places, it would show “1.000000000000004885” and “1.000000000000005107”. It does not. The display we see is consistent with converting the numbers using 15 decimal digits (significant digits, not just those after the decimal point) and then padding with zeros.
Converting 50.98 to the IEEE-754 binary64 format yields 50.97999999999999687361196265555918216705322265625. Displaying this with 15 decimal digits yields 50.9800000000000.
I have an array of decimal values like 0.0047, -45.34 etc. Is there a way I can add this in verilog and automatically view it's 16 bit converted value?
You can use 'real' but you can not synthesize it. You have to find a binary representation for your numbers either floating point or fixed point. You have to define a range for your numbers and also a precision as binary representation of real number is often an approximation.
I did some calculations. You have a positive and negative number so you need a sign bit. Leaves 15 bits for the values. You want to have at least 45, that requires 6 bits. leaves 9 bits for the fraction. The closest you can get to 0.0047 is then 0.0046875. Your range is then -63.998 .... +63.998
I know how to isolate the decimal using the TRUNC() function, as well as taking the original value and subtracting this truncated part.
And I can then multiply to get whole number.
But that only works if all my decimals are the same place. I want something that will get me the amount after the decimal point as a whole number, regardless of how many places.
eg: 12.2 would return 2
12.21 would return 21
With data in A1, consider:
=IF(ISERROR(FIND(".",A1)),A1,--MID(A1,(FIND(".",A1)+1),9999))
Naturally leading zeros in the output are dropped: