Re^8: Introspection into floats/NV

[LanX]

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.)

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

[ikegami]

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 format	C type	What it is
f	float	IEEE single
d	double	IEEE double
D	long double	IEEE quad
F	NV = __float80	Intel 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.

[LanX]

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)