in reply to Re^7: Introspection into floats/NV
in thread Introspection into floats/NV

I'm not a C programmer,

So let me restate my question, provided perl is compiled with other settings. (FP32,FP64,FP80,FP128, etc?)

Will F return another bitlength? ¹

Citing the docs

f  A single-precision float in native format.
d  A double-precision float in native format.

F  A Perl internal floating-point value (NV) in native format
D  A float of long-double precision in native format.
     (Long doubles are available only if your system supports
      long double values. Raises an exception otherwise.              
+(* WRONG see demo)
      Note that there are different long double formats.)

[download]

What I read - and can't test² - is that F will produce f,d or D according to the setting.

D will fail* if not internally available, but f and d will coerce° accordingly.

Unfortunately, there is no mention of the FP80³ format you mentioned in another thread.

If I'm wrong, don't you think perldocs of packtut and pack should clarify this?

update 1

1)

From our previous discussion:

> > > There's no way to know if F is an IEEE double or not.

> > I'm confused, I'm expecting F to return 32, 64, 80 or 128 bits (at least)

IEEE double means FP64, if F returns different bit length it's possible to tell that it's not a FP64.

It might be much trickier to tell if its according to IEEE though (i.e. position and format of sign and exponent)

update 2

²) well lets try

*) wrong °)seems to be true

main::(-e:1):    0
  DB<1> say unpack "B*", pack "f", 1/3
10101011101010101010101000111110

  DB<2> say unpack "B*", pack "d", 1/3
0101010101010101010101010101010101010101010101011101010100111111

  DB<3> say unpack "B*", pack "F", 1/3
0101010101010101010101010101010101010101010101011101010100111111

  DB<4> say unpack "B*", pack "D", 1/3
0000000010101000101010101010101010101010101010101010101010101010111111
+0100111111000000000000000000000000000000000000000000000000

  DB<5> use warnings; say unpack "B*", pack "D", 1/3         # NO EXCE
+PTION RAISED
0000000010101000101010101010101010101010101010101010101010101010111111
+0100111111000000000000000000000000000000000000000000000000

[download]

Cheers Rolf
(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery

³) According to Wikipedia is "64-extended" only loosely defined as having 79+ bits

Replies are listed 'Best First'.
Re^9: Introspection into floats/NV
by ikegami (Patriarch) on Jun 05, 2025 at 14:35 UTC

    I'm not a C programmer

    C doesn't mandate the size or format of float, double or long double. Some or all of these might even be optional to implement.

    Unfortunately, there is no mention of the FP80 format you mentioned in another thread.

    Wikipedia's Extended_precision#x86_extended-precision_format says

    "The x86 extended-precision format is an 80-bit format first implemented in the Intel 8087 math coprocessor and is supported by all processors that are based on the x86 design that incorporate a floating-point unit (FPU)."

    gcc makes these available as __float80 on x86-64 machines.

    F will produce f,d or D according to the setting.

    NV (F) is user-defined, and it isn't limited to be one of float (f), double (d) or long double (D).

    For example, someone using gcc on a modern x86-64 (i.e. nearly everyone) could build a Perl with the following types:
    pack formatC typeWhat it is
    ffloatIEEE single
    ddoubleIEEE double
    Dlong doubleIEEE quad
    FNV = __float80Intel 80-bit extended precision

    It would be an unusual choice since __float80 is padded to 16 bytes, the same size as the also-supported IEEE quad.

    Will F return another bitlength?

    It can.

    In that setup described, it would return the same byte length as D since __float80 is padded to 16 bytes, but it would be a different format that D.

    if F returns different bit length it's possible to tell that it's not a FP64. It might be much trickier to tell if its according to IEEE though (i.e. position and format of sign and exponent)

    Exactly. It's easy to tell that a (say) 10-byte format isn't an one of the IEEE formats, but distinguishing a __float80 from an IEEE quad is harder.

    Updated based on new knowledge of about the 80-bit floats.

[reply]
[d/l]
[select]
      Thanks.

      > It would be an unusual choice since __float80 is padded to 16 bytes, the same size as the also-supported IEEE quad.

      Ouch! What a waste.

      OTOH FP80 with a mantissa of 64bit would solve syphilis perceived "weirdness" that rounding errors are suddenly 11 bits when the number range ob 64b integers is exceeded and numbers are coerced into FP64.

      FWIW: JavaScripts solution is to only express integers in FP64 doubles. (at least officially)

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      see Wikisyntax for the Monastery

[reply]

In Section Seekers of Perl Wisdom