LabVIEW
error in Pi value
Solved!
@eximo wrote:
This causes issues believe it or not when solving some equations, it took us awhile to find it.
Don't go on a witch hunt here. I am sure the problem here is elsewhere. Can you explain the equations you are trying to solve? I am sure rounding errors due to minor changes in ordering of operations are more severe. Even if something looks identical in symbolic math you can get quite different results by just doing the same operations in a slightly different order, especially for long, iterative procedures.
If you require significantly more digits (and who doesn't), you need to write your own tools or implement something like GMP. (As another example, here's a simple way to calculate all 35660 digits of 10000! (factorial))
NI does not bake their own Pi(e), I am sure these are binary identical to the standard values used anywhere else. You get 15 decimal digits as promised for DBL and at least 15 as promised to EXT (see the context help). The values are rounded to the nearest binary value based on the number of bits in the mantissa, which has very little to do with the decimal representation (e.g. 0.1 cannot be represented in a finite number of bits).
I am still interested in your math problem!
@Mancho00 wrote:
LabVIEW help for pi constant says 3.1415926535897932. If it can't be represented properly at double precision, NI shouldn't be storing it as such. I'd call that a bug.
Pi can never be represented "properly" unless you have an infinite amount of bits (or digits). The constants are rounded to the nearest available binary value for all representations and that is sufficient. All other floating point values in your operations have the exact same limitations, so don't point the finger at pi.
@eximo wrote:Is this expected behavior? If it's precision is only to 6 points, why is it expressing numbers after the 7th decimal at all?
Again the difference is between binary and decimal. It is not "expressing" anything and if you would expect that all decimal digits past the stated resolution are zero you are wrong. The extra digits are random in decimal representation. What you seeing is the decimal formatted value that exactly corresponds to the binary representation. If you would increment or decrement the mantissa by one bit, you'll get a value that is further away from the right PI value, again with seemingly random (but exactly predictable digits) past the valid resolution. It is your responsibility to pick a format that only displays valid digits if it bothers you cosmetically.
@eximo wrote:
According to the math for obtaining decimal points, it would take 31 bits to obtain a precision of 0.0000000004656612 (10 decimal points)
Also please don't confuse "precision" with digits past the decimal point. This value only has 7 significant digits, and that's all that matters. The bits for the exponent define the scaling. (see also)
@eximo wrote:I suppose it's not a bug, but just the architecture of the computer being exposed.
It a side effect of binary representation, independent of any computer. You would get the same result doing the same calculations with paper&pencil 😄
Using the following code, you can see that the SGL value of Pi is closest to the much more precise DBL value compared to it's immediate binary (SGL) neighbors and that's the best possible approximation.
(You can get a similar result comparing DBL with EXT, and casting to U64. Now the quantization steps are on the order of ~5E-16)
