GNU bug report logs -
#6020
coreutils-8.x: a simple feature enhancement, and how to do it
Previous Next
Full log
Message #11 received at 6020 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 (text/x-patch, attachment)]
This bug report was last modified 15 years and 83 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.