Re: Proposal: Eliminating use of long double

[Erik Auerswald]

Hi Shawn,

On Wed, May 18, 2022 at 04:52:07AM -0700, Shawn Wagner wrote:
> Now that I'm (mostly) caught up on outstanding minor patches (largely
> documentation fixes from Erik) and my own queued up small
> improvements, time to talk about some bigger/higher impact things I
> had in the back of my mind.
> 
> First is switching numbers from the C long double type currently being
> used to plain double. They're already the same thing on most
> architectures. x86 is, I believe, the only common one where long
> double is bigger (80 bits vs 64),

Another one would be POWER (ppc64le), see:
https://lists.gnu.org/archive/html/bug-datamash/2022-03/msg00000.html

> and requires using the old FPU instructions instead of SSE ones. I
> haven't benchmarked, but I strongly suspect that more time is spent in
> converting between strings and C floating point numbers than is spent
> actually doing computations, but there are definitely some loops over
> arrays of numbers that could benefit from SSE/AVX vectorization.
> 
> This will cause a slight loss of precision on CPUs where sizeof(long
> double) > sizeof(double), but I'm 99.9% sure that won't be an issue;
> the default number to string settings don't print out more digits than
> a double can represent.
> 
> If anyone actually depends on those additional bits, I think a better
> (Definitely more portable) option would be to use MPFR'/GMPs arbitrary
> precision types; maybe toggle between double and them with an option
> like gawk's -N/--bignum (Though supporting both would require a major
> refactoring of datamash).
> 
> Thoughts?

I do not really care about the potentially better performance.  I would
not like to find out that some data I try to use with GNU datamash is
incorrectly processed because of reduced floating point size.

I would like the use of arbirary precision types, and would prefer the
default to be precision instead of speed.

Then I do not intend to look into implementing any of this myself….

Just my 2c,
Erik