Re: reader musings

[Stefan Israelsson Tampe <stefan.itampe@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1774 bytes --]

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 <maximedevos@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.
>

[-- Attachment #2: Type: text/html, Size: 2503 bytes --]