[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Pádraig Brady
Subject: bug#6020: coreutils-8.x: a simple feature enhancement, and how to do it
Date: Thu, 29 Apr 2010 00:39:46 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100227 Thunderbird/3.0.3

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.


Attachment: sort-long-double.diff
Description: Text Data

reply via email to

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