develooper Front page | perl.perl5.porters | Postings from September 2014

Re: new long doubles option: gcc libquadmath

Thread Previous | Thread Next
Jarkko Hietaniemi
September 19, 2014 20:12
Re: new long doubles option: gcc libquadmath
Message ID:
On Friday-201409-19, 14:46, Reini Urban wrote:
> All serializers should support all possible number formats. There are dozens.
>>From the standardized float and double to the varying versions of long double:
> double-double as on ppc, the two intel variants with 10 or 12 extended prec.,

I think the "12 bytes" for the x86 extended precision is an "urban
legend" of misunderstanding: the number of bits is always 80 (64 for 
mantissa, 15 for exponent, 1 for sign, no "implicit bit").  The 12
comes from the ILP32 way of storing the 10-byte thing in three 4-byte 
words.  In LP64 (like x86_64) it's stored in two 8-byte words, hence 16
bytes.  The unused bytes (2 or 6) are unused garbage.  They might be
zero bits, or they might contain your credit card number.

As for the libquadmath: it's not a new format.  It's an implementation
of the perfectly standard IEEE 754.  Of course one may understand as
"standard" only the double precision of 64/53 bits, but there's no
escaping it's the same standard.

> the hw or sw quad math standards, and several more hw specific variants,
> little and big-endian.
> If you transport them as strings you need to do nothing, as blob you need to
> mark the variant in the header and do something like the parrot native_pbc
> translators (fast, but not recommended).

Yeah.  The output/transport/storage is easy: output the tag, output the 
raw bytes, bam, done.  The input is where the pain begins: if you have
different runtime than you are importing from, you obviously will have 
to leave something on the cutting room floor.  Chop? Round? Round how?

One option would be to have a "portable (binary) floating point":
instead of packing the {sign_bit,exponent,implicit_bit,mantissa}
into a single 8/10/16 byte string, one could output as a tuple of
(Just thinking aloud.)  Something needed for the exceptional values
like Inf and NaN, one could follow the IEEE 754 conventions.  The
obvious upside of a portable fp format: always stores faithfully,
and reduces the N x M conversion issue into N + M.  The obvious
downside: speed loss both on write and read.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About