bug#6020: coreutils-8.x: a simple feature enhancement, and how to do it

[Pádraig Brady]

On 28/04/10 21:01, Nelson H. F. Beebe wrote:
>>> ...
>>> I was wondering about a test for this:
>>>
>>> $ printf "3.64e-4951\n3.63e-4950\n" | ./sort -g
>>> 3.64e-4951
>>> 3.63e-4950
>>>
>>> However I'm worried that will fail because of what you mention above.
>>> I probably need to add LDBL_{MIN,MAX} to getlimits.
>>> ...
> 
> Here is what I see with the version that I patched some time ago
> according to the proposal posted last week:
> 
>       % printf "3.64e-4951\n3.63e-4950\n" | sort-8.4 -g
>       3.64e-4951
>       3.63e-4950
> 
> Why should getlimits() even be used?  Surely it is enough to ask
> strtold() to just return its best answer for the conversion of a
> human-readable number string to (we hope the nearest) machine number.

getlimits is just used in our tests.
Because of the implicit rounding in strtold I'd need something
independent of `sort` to output LDBL_MIN and LDBL_MAX to verify that
sort is actually using long double if available on the platform.

> You should not worry about execution time; there is a current huge
> hole in the coverage of floating-point numbers with coreutil's "sort
> -g" option that badly needs repair.  Getting the right answer a bit
> more slowly is much more important than getting the wrong answer fast.

I'm always wary of performance.
I was just pointing out that there is no slow down on my system.

I'll push the attached sometime tomorrow.

cheers,
Pádraig

sort-long-double.diff
Description: Text Data