bug-gnulib
[Top][All Lists]
Advanced

[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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]