GNU bug report logs - #66256
sorting NAN values with "general-numeric’

Previous Next

Full log

View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: Jorge Stolfi <stolfi <at> ic.unicamp.br>, 66256 <at> debbugs.gnu.org
Subject: bug#66256: sorting NAN values with "general-numeric’
Date: Thu, 28 Sep 2023 12:52:47 +0100

On 28/09/2023 11:43, Jorge Stolfi wrote:
> 
> The full documentation of the "--general-numeric-sort" option of
> {sort} says that NaN values are sorted "in a consistent but
> machine-dependent order".
> 
> This is not good. The point of the IEEE floating-point standard was to
> make the results of floating-point computations be independent of the
> platform or implementation.
> 
> Please consider extending that goal to the handling of NaNs by {sort}.
>    That it, all flavors of NaN (determined by their char tails, as
> parsed by {strtod}) should be treated as equal.
> 
> The fact that different flavors of NaN have distinct binary
> representation is not an excuse to sort them as distinct, since the
> same is true of +0 and -0, which "general-numeric" sort already treats
> as equal.
> 
> As a separate suggestion, please consider having {sort} abort with an
> error message if any field that is supposed to be sorted with
> "general-numeric" is not a valid {double} value, or has some leftover
> chars that are not parsed by {strtod}.
> 
> Whether these solutions are accepted or not, please change the manpage
> explanation of "-g"/"--general-numeric-sort" to say, at least, "the
> field is parsed as a double-precision (64-bit) floating-point number
> and sorted by its numeric value".
> 
> Thanks, and all the best,

No comment on the actual ordering of NaNs, but
note NaN ordering changed recently in coreutils 9.2,
as discussed at https://bugs.gnu.org/55212

cheers,
Pádraig

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.