Quadruple-precision floating-point support?

[Shaobo He]

Hello everyone,

I'm in need of quad-precision floating-point type/operations in Racket (the bigfloat module doesn't work for me). It appears there's none, am I right?

If so, I think I will try to write one myself, which is going to be a wrapper to libquadmath. Any suggestions about how I should approach it? The first issue seems to be marshalling the C `__float128` type into a Racket type.

Thanks,

Shaobo

[Josh Rubin]

I'm not sure exactly what you have in mind, and I am a total ignoramus
about Racket numerics, but it is possible to implement quad precision
floating point arithmetic using only double precision floating point,
while maintaining rigorous error bounds.
(... and so on, doubling precision precision at each step.)

These sources might be useful.

Design and Implementation of a High Precision Arithmetic with Rigorous
Error Bounds
Alexander WittigMSUHEP-081126December 2008
https://pdfs.semanticscholar.org/8450/3383403eca34dd7e92a12261a3ed7ea2340a.pdf

The Great Internet Mersenne Prime Search (GIMPS) project carries this to
extremes.
They use Fourier multiplication on integers with millions of bits - and
must have exact results.
https://www.mersenne.org/

Good luck with your project. I am interested in seeing the result!

--

Josh Rubin
jlr...@gmail.com

[Shaobo He]

Hi Josh,

Thank you for the pointers. Although I'm also interested in implementing quad-floats using doubles, such a correct implementation would take much more time than the FFI approach as well as what I can afford given my time constraints.

Shaobo

Josh Rubin <jlr...@gmail.com> 于2019年8月23日周五 下午7:08写道：

[George Neuner]

On 8/23/2019 8:39 PM, Shaobo He wrote:

> Hello everyone,
>
> I'm in need of quad-precision floating-point type/operations in Racket
> (the bigfloat module doesn't work for me). It appears there's none, am
> I right?

The only hardware I am aware of with IEEE compatible quad precision is
POWER9  (Vaxen had quad precision, but not IEEE compatible).  So on most
platforms any implementation necessarily will be software: either an
emulation of quad or double-double.

Just out of curiosity, may I ask why bigfloat doesn't work for your
purpose?  I know the range will be different between a quad and a
bigfloat having the same precision, but that seems like it ought to be
relatively easy to work around.

George

[Shaobo He]

Hello George,

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.

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.

Shaobo

George Neuner <gneu...@comcast.net> 于2019年8月25日周日 上午10:28写道：

[George Neuner]

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