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 whybigfloat or double-double don't work for me. The program I've beenworking 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-pointvalues. Therefore, bigfloat is generally too slow just for my use casesince I don't need so much precision and it doesn't provide functionsto access the bit representations. Double-double is good enough toemulate the floating-point arithmetic but I think it's also nottrivial to access the bit representations of the floating-pointformats 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 sufficientlyprecise to emulate all the floating-point formats I'm interested inand obtaining the bit representations of these formats based on thebit 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.