4
$\begingroup$

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$

$\endgroup$
2
  • $\begingroup$ You might want to check this ... math.stackexchange.com/questions/1623917/… $\endgroup$
    – SchrodingersCat
    Commented Apr 27, 2016 at 4:35
  • 1
    $\begingroup$ If you obtain an imprecise result with $13$E$11$ too then it's probably because the mantissa has only $24$ significative binary digits (IEE 32bits simple precision) since the first $30$ bits are significative here. But this should return less nines than indicated so that I would rather bet on $10^{11}$ being computed as $\;10^{11}=\exp(11\ln(10))\;$ before the multiplication by $13$. As explained by others this is unrelated to the $0.99\cdots=1$ identity. $\endgroup$
    – Raymond Manzoni
    Commented Apr 27, 2016 at 7:20

3 Answers 3

Reset to default
6
$\begingroup$

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)$.

$\endgroup$
5
  • $\begingroup$ For your last sentence, it is probably because rounding $99π$ to machine precision gives a larger error than rounding $100π$. To confirm that, try $\sin(198π)$ and $\sin(200π)$. If it has the same behaviour, then this reason is likely correct. If it does not, then it is likely due to the algorithm used. $\endgroup$
    – user21820
    Commented Apr 27, 2016 at 8:51
  • $\begingroup$ @user21820 That makes sense. It seems like many multiples of $\pi$ produce values near $10^{-12}$, except for the powers of 10 and some spare multiples of 10. $\endgroup$
    – zahbaz
    Commented Apr 27, 2016 at 9:09
  • $\begingroup$ It's not about powers of $10$ but powers of $2$. Internally it should be stored in binary, so multiplying by $2$ would not change the fractional error. To confirm my hypothesis you should try powers of $2$ multiplied by $99$ or $100$. If you want even more confirmation you should try to find your calculator's machine precision and check the fractional error of rounding to that. $\endgroup$
    – user21820
    Commented Apr 27, 2016 at 9:17
  • $\begingroup$ @user21820 Powers of two don't seem to fit the pattern. I'm thinking perhaps that $\pi\times10^p$ is stored nicely since the mantissa never changes, just the bits storing the exponent. The "value" of $\pi$ is preserved in a sense, and $\sin$ evaluates to zero. This is making for a nice black box puzzle. $\endgroup$
    – zahbaz
    Commented Apr 27, 2016 at 9:44
  • 1
    $\begingroup$ Interesting. I prefer not to waste time reverse engineering when there is google around though! merthsoft.com/linkguide/ti83+/vars.html says that TI-83 uses 14-digit BCD rather than binary contrary to what I thought, which means powers of 10 should fit the pattern, and explains why $\sin(10^k π) = 0$. However, rounding or truncating $99π$ to 14-digit precision does not give the error you observe so I don't know how it gave the error you observe. $\endgroup$
    – user21820
    Commented Apr 27, 2016 at 9:59
3
$\begingroup$

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.

$\endgroup$
5
  • $\begingroup$ Most modern CPUs don't support base-10 floating point arithmetic. Also, everything is much simpler with base-2, which is the major reason it is used almost everywhere. Compilers for languages that do support base-10 floats have to implement it themselves, using the native FPU instructions, which is not a trivial task. $\endgroup$
    – user21820
    Commented Apr 27, 2016 at 8:36
  • $\begingroup$ I remember writing a floating point package for the IBM 1401. Decimal everything. $\endgroup$
    – marty cohen
    Commented Apr 27, 2016 at 21:29
  • 1
    $\begingroup$ Yup that's why I said "modern". Though as I noted in another comment the TI-83 calculator (quite recent) still uses BCD. When I wrote my own arbitrary precision library I used base $10^9$, which is sort of decimal haha, but of course I used the internal binary integer and floating point to manipulate the digits. $\endgroup$
    – user21820
    Commented Apr 28, 2016 at 0:38
  • $\begingroup$ Yep. Many years ago, I wrote an arbitrary precision integer library in fortran. The base was a parameter, with the only restriction being that base$^2$ had to fit in a single integer word. I implemented Knuth's +, -, x, / routines. The ability to set the base meant that I could try his edge cases. I also did an $\lfloor \sqrt \rfloor$ using Newton's iteration, approximately doubling the precision at each iteration. Fun times. $\endgroup$
    – marty cohen
    Commented Apr 28, 2016 at 0:48
  • $\begingroup$ Yup! I did the same, though I didn't refer to any books so I derived all the hard bounds myself, for guaranteeing both the desired precision and the quadratic convergence for Newton-inversion (there could be errors but I didn't find any in my testing haha). I chose $10^9$ since addition can be done with a 32-bit int and multiplication can be done with a 64-bit int. Incidentally, I recently used it to check a programming assignment and together with my student found that GMP gave wrong output... He submitted a bug report and it got fixed! $\endgroup$
    – user21820
    Commented Apr 28, 2016 at 1:07
1
$\begingroup$

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

$\endgroup$
2
  • $\begingroup$ Where did I mention there are finite $9$ $\endgroup$
    – Archis Welankar
    Commented Apr 27, 2016 at 4:42
  • 1
    $\begingroup$ I meant that in the number 1299999999999.999 there are not infinite number of 9s like there is in 0.99... in which the nines repeat to infinity. $\endgroup$
    – KKZiomek
    Commented Apr 27, 2016 at 4:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .