Wrong calculation by a calculator Today I was working on some chemistry problems . Many of you might know it involves some big exponents. So today I just entered in one of my calculators (which might not be strong) as it was inbuilt in my mobile $ 13\cdot 10^{11}$(before entering my next calculations part gave me $1299999999999.999..$ . Is this same as considering $0.99.....=1$
 A: Your calculator is a machine with finite capacity. It is indeed imperfect. This is unrelated with why $0.999... =1$. That's a whole other story.
The discrepancy you experienced is likely due to floating point error. Computers store numbers in a finite number of bits, and furthermore, they do not store the numbers in base 10 but rather in base 2. What happens, especially with numbers that are very large or very small in magnitude, is that your calculator cannot address the imprecision in its storage and inadequacy in its conversion from base 10 to binary back to base 10. The end result for the user is, well, an inexact calculation!
To see other examples, consider $10^{1000}$. Your calculator may bark at you, citing an overflow error. The number is too big. Or perhaps try $10^{-1000}$. Your calculator may say this equals $0$! That's an example of underflow. The number is too small to handle, so it is set to zero, hopefully not affecting your desired calculation by too much. More complicated, algorithmic errors can occur as well: my TI-83 thinks that $\sin(99\pi)=2\times10^{-13}$ yet has no trouble with $\sin(100\pi)$.
A: To me, this looks like rounding error 
in the conversion from
internal format to string
or the other way around.
I have seen this in
many fortran programs in the past.
In another case
I encountered,
an Ada program produced
slightly different results
depending on whether
a string was converted to numeric
at compile time
or run time.
Maybe there should be
a hardware option
to have the exponent
in the floating point representation
indicate powers of 10
instead of powers of 2.
A: No, it is not the same. Considering 0.99...=1 involves infinitely repeating 9s after decimal point, which does equal 1. But in the calculation here, there are finite 9s, and it is off by a whole one unit (more accurately 1/1000 of an unit), which is not a big error, but a considerable one. It can be bypassed, but it is definitely not the same thing as 0.99...=1 
