Hi,
On 8/28/2019 11:49 AM, Shaobo He wrote:
> Let me describe my use case first so that it's easier to clarify why
> bigfloat or double-double don't work for me. The program I've been
> working on requires emulation of arbitrary-precision *IEEE 754*
> floating-point arithmetic (the maximum precision is double, for now)
> and easy/efficient access to the bit representations of floating-point
> values. Therefore, bigfloat is generally too slow just for my use case
> since I don't need so much precision and it doesn't provide functions
> to access the bit representations. Double-double is good enough to
> emulate the floating-point arithmetic but I think it's also not
> trivial to access the bit representations of the floating-point
> formats I want to emulate.
MPFR does have optimizations for power of 2 mantissa lengths, but it's
easy to see that a dedicated IEEE quad emulation (that most likely uses
CPU SIMD ops) might be faster.
Low level bit access from Racket will not be trivial in any case: Racket
can extract and set bit fields only within exact integers, and integers
larger than platform fixnums will be in GMP bigint format (an array of
longs representing base 10**9 values).
Contiguous foreign data buffers can be made visible to Racket as byte
strings and manipulated that way, but it can be tricky to work with
fields larger that span multiple bytes, and slow to work with fields
that are larger than platform fixnums.
> Quad-precision format fits my purpose nicely because it's sufficiently
> precise to emulate all the floating-point formats I'm interested in
> and obtaining the bit representations of these formats based on the
> bit representations of quad-precision numbers is easy.
More important is how closely you really want to emulate IEEE
functionality. I don't see anywhere that IEEE-754/854 conformance is
documented for libquadmath. There are numerous high and/or arbitrary
precision math libraries, but many use their own ad hoc format
internally rather than IEEE interchange formats, and they don't
faithfully implement IEEE bitwise underflow. Many also don't implement
all the possible IEEE-754 rounding modes ... what constitutes "correct"
rounding behavior depends on the problem, and in any case is a matter of
opinion.
Most people don't think about (or really care much) about IEEE
conformance, but if you are aiming to produce bitwise accurate results
... albeit with arbitrary precision ... then maybe you do need to worry
about these things.
George