in reply to Re^2: Large floating point literals
in thread Large floating point literals

Indeed. You are correct. I chose the wrong reference:

printf "%.20g\n", unpack 'd', scalar reverse pack 'NN', 0x7fefffff, 0x +ffffffff;; 1.7976931348623157e+308 printf "%.20g\n", unpack 'd', scalar reverse pack 'NN', 0x7fffffff, 0x +ffffffff;; 1.#QNAN printf "%.20g\n", unpack 'd', scalar reverse pack 'NN', 0xffefffff, 0x +ffffffff;; -1.7976931348623157e+308 printf "%.20g\n", unpack 'd', scalar reverse pack 'NN', 0xffffffff, 0x +ffffffff;; -1.#QNAN

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^4: Large floating point literals
by ig (Vicar) on May 21, 2009 at 00:53 UTC

      It's cool if you need the precision and can live with the performance of infinite precision--which is generally abysmal.

      But don't forget that on modern x86 and x64 hardware, the FPU uses 80-bit floats internally even when the calling code is using 64-bit floats. That greatly reduces the loss of precision of intermediate calculations provided that the math libraries are well written. Ie. They don't move intermediate values out of the FPU to ram and back again.

      How effective Perl's math routines are at keeping intermediate values in the FPU registers I have no idea.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.