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 -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/ea09776e-7d49-de88-4012-532162d73cf0%40comcast.net.
