I found a better way to find the mantissa and exponent e.g. frexp and when constructing the double/float ldexp is great. That makes the code more portable. These functions are really fast and the call overhead is not terrible.
On Wed, Jun 8, 2022 at 9:49 AM Maxime Devos <maximede...@telenet.be> wrote: > Stefan Israelsson Tampe schreef op wo 08-06-2022 om 01:07 [+0200]: > > https://gitlab.com/tampe/guile-persist/-/tree/master/ice-9 > > https://gitlab.com/tampe/guile-persist/-/tree/master/src/write > > > > I'm wondering if I should make a C library for other projects to take > > advantage of this work. > > Could they be integrated in Guile itself? That would reach the most > people I think. > > > int exp = (((*((uint64_t *) &d)) >> 52) & ((1L<<11)-1)) - 1023L; > uint64_t man = ((*((uint64_t *) &d)) & ((1L<<52)-1L)) + (1L << 52); > > double's aren't uint64_t, so maybe a strict aliasing vilation and hence > undefined behaviour. If so, maybe use -fno-strict-aliasing, or use > type punning through an union? > > Also, this assumes IEEE doubles, so maybe do some checks whether things > are actually IEEE (see m4/fpieee.m4, and maybe some checks like > sizeof(double)=sizeof(uint64_t) and alignof(double)=sizeof(uint64_t) > and check DBL_DIG, DBL_MANT_DIG, DBL_MAX_EXP, ...)? > > That line also assumes 'long' = 'uint64_t' (or at least, that they have > the same size), which to me seems a bold assumption to make in the > general case. > > Also, more generally, there was some paper on subtle errors that can > easily happen when printing floating point numbers and how to test for > them and avoid them, though I cannot find it anymore, and the > implementation isn't documented and doesn't seem to have automatic > tests. > > Greetings, > Maxime. >
