[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Accurate reading of floating point numbers
From: |
Bruno Haible |
Subject: |
Re: Accurate reading of floating point numbers |
Date: |
Mon, 26 Aug 2024 19:59:20 +0200 |
Hi Marc,
> > The problem with the glibc code is that they have specialized code for each
> > format:
> > - IEEE 754 single-precision,
> > - IEEE 754 double-precision,
> > - 'long double' with LDBL_MANT_DIG == 106 (a.k.a. "double double"),
> > - 'long double' with LDBL_MANT_DIG == 113 (a.k.a. "quad precision").
> > That makes for a lot of code and a lot of required testing, and is not
> > future-proof (regarding new floating-point types).
> >
>
> > If possible, in Gnulib, we would prefer a single implementation, even if
> > it is a bit slow.
> >
>
> I am not sure whether it makes sense to implement a more generic
> algorithm. When the mantissa width is known (and the range of denormalized
> numbers), the algorithms can avoid big integer arithmetic most of the
> time.
It is OK to have optimizations for specific *_MANT_DIG values. But the
algorithm should be formulated in such a way that it works for other,
yet unknown, *_MANT_DIG values as well. Otherwise it's not future-proof.
> A generic algorithm that does not check special cases would probably
> use big integers in all code paths and could give no upper bound of memory
> usage.
That's acceptable.
> If one is willing to include GNU MPFR, a correct generic
> implementation seems to be already readily available by combining
> mpfr_strtofr and, say, mpfr_get_d.
Packages that use Gnulib would generally not like to have additional
installation dependencies (GMP and MPFR); therefore this approach is a
non-starter.
But it would be OK to pull a few source files from MPFR and combine
them with mini-gmp — assuming that this does not lead to a maintenance
hassle.
> If reusing the glibc code is not too complicated so that procedures like
> (c_)strtoaf, (c_)strtoad, and (c_)strtoald can be provided, it is better
> than nothing.
As I said in the previous mail: If you organize things in such a way that
we have 4 different implementations of the routines, and no way of handling
unknown values of *_MANT_DIG, then it's not better than what we have now, IMO.
Bruno