
Interesting. I just realized, double isn't as precise as I thought :D It only stores 16 decimal places of PI anyways, while I know 30+.
But strangely, the last decimal place is rounded down incorrectly... it stores
3.1415926535897931 instead of
3.1415926535897932, where the real number is
3.14159265358979323.
Regardless of whether it is rounded or truncated, shouldn't the last digit be 2 instead of 1? (acos(1.) gives the same result)

Well... It is double precision in that it is twice the storage space (at least on machines that I've worked on; I know of no other requirement in the standard other than sizeof(float) <= sizeof(double)), but remember that the number is stored in binary format. Do a google search on the IEEE standard for storing floating point numbers, and you will likely get more indepth answers to your questions.

Wow, just read an article about it. But I still don't have a solid answer for my question  I sort of get the impression that it's because of the fact that there may be no true binary representation for the correctly rounded (or base 10 truncated) value. Am I correct?



Just make PI 3.14 and run with it :)
No, in all seriousness this is a very interesting thread and will be of great use to me (and others) in the future.