Flatten To JSON Function changes the DBL digits length incorrectly [Bug?]

[drjdpowell]

I have a vague memory that they increased the number of digits at some point to ensure all DBL values are flattened/unflattened to exactly the same binary value.  I think 14 digits was not quite enough, so they increased it.

JSONtext, in contrast, tries to preserve typical decimal values, like 222.2, when they are converted to/from a temporary floating-point approximation.  This limits it to about 13 significant digits.

[altenbach]

---

@drjdpowell wrote:

(though it has a known bug in treating EXT as if it were SGL). 

---

Curiously, if we actually change this code to all SGL, we get again all these extra digits, so it is not quite the same. 😄

[drjdpowell]

EXT is treated as SGL should be, but SGL is treated as if it were DBL.  A strange bug.

[rolfk]

In normal LabVIEW, EXT support has been removed since a long time except for Win 32-bit which uses a 80-bit floating point value. It automatically uses DBL on all other platforms since. The only place weer it still has some sort of meaning is in flattened form. Here LabVIEW flattens an EXT to a 16 byte floating point value, independent of the platform.

But on transfer from a flattened EXT, it is converted back to a DBL and calculated with as such. On Win-32bit the Intel 80-bit extended format is used instead, but that is the only platform left over that still has some minimal form of EXT support. And it offers a little bit more accuracy but not as much than what a true long double would do.

And developments like MMX and SIMD go exactly into the other direction. Not increasing floating point precision but doing as much as possible in much faster integer arithmetic

And SIMD/MMX and FP calculation are in fact almost excluding each other in the same process since their registers overlap. So it's a lot of extra overhead to save and restore these registers not only on thread and task switches but even between doing one or the other in the same code.