I'm working with HP Prime emulator (HP Prime Virtual Calculator / Build 2016 12 8. Rev:11226). Trying to calculate Euler's equation (e^(i*pi)+1=0) I've got the strange result: −2.06761537357ᴇ−13 instead of zero. But, what's surprising - other online calculators (as for example Symbolab, Wolfram Alpha etc.) show correctly - zero. It must be, of course problem of internal computational precision - I suppose, but I don't understand why I've got just this number. Could somebody test it or/and explain it for me?

Thanks in advance,

−2.06761537357ᴇ−13 is very close to 0. It's a rounding error. The fact that the exponent is -13 tells you something about how the calculator handles floating-point numbers. If you don't understand that, don't worry: I'm still learning, myself. I'm not completely familiar with your calculator, but I assume it has some kind of rounding function. If you learn how to use that, you can make it display 0.

Edit: Oh. Reading your post again, I see that you understand exactly everything I said, and were curious about what I don't yet understand.
It is indeed due to rounding errors. The exponential is just a sum of some powers, but logically, the amount of terms is not infinite, what it's supposed to be, so there you get the rouding error. Another possibility is, that pi is only stored upto some decimals, it's not a number with infinite decimals, which leads to rounding errors as well.
A similar thing happens in MATLAB:

>> format long
>> exp(pi*i)+1

ans =

      0.000000000000000e+00 + 1.224646799147353e-16i

This problem should be common to all systems not using a CAS.
Welcome to the world of floating point numbers! I'm a little surprised that this would happen on the HP Prime given that it has a CAS in there, but I guess this shows that it is not using it for this particular problem. Errors such as the one you've experienced are inevitable when representing numbers as FPN because you are representing an infinite number of digits with a finite number of bits. In your case, e and pi both have an infinite number of digits and are therefore slightly misrepresented. Usually, the way calculators get around this is by having an extra 1-2 digits that it doesn't show you, so that if there is a small error, it gets rounded off and you only see correct digits. However, if the error piles up, it can sometimes go over into the displayed answer, and there is no way of knowing whether the answer you wanted was 0 or −2.06761537357ᴇ−13. This is why you will sometimes get answers that are slightly off, especially in calculations that have many many steps, like numerical integration for example.
tl;dr, This is perfectly normal and is due to the way the calculator deals with numbers.
Here is a screenshot demonstrating these kinds of errors on the ti-84 plus CE.

Just for fun, in an old program I made to calculate derivatives, these errors would pile up a lot. Here is what it would output as the derivative of sin(x). It should be sin(x+π/2), which is equivalent to cos(x).
... Evil or Very Mad

It's probably rounding error indeed. It could be stored value of pi (interesting observation),
especially that it could speed up calculations. What's strange for me - that the other calculators
show correctly - zero.
Even more!
I've just tried same calculation on my HP50g (predecessor of HP Prime).
Result: 0!
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum