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

Previous Next

Package: coreutils;

Reported by: "Nelson H. F. Beebe" <beebe <at> math.utah.edu>

Date: Sat, 24 Apr 2010 01:31:01 UTC

Severity: normal

Fixed in version 8.6

Done: Pádraig Brady <P <at> draigBrady.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: "Nelson H. F. Beebe" <beebe <at> math.utah.edu>
To: Paul Eggert <eggert <at> CS.UCLA.EDU>, =utf-8QP=C3=A1draig=Brady <P <at> draigBrady.com>, 6020 <at> debbugs.gnu.org
Cc: beebe <at> math.utah.edu
Subject: bug#6020: coreutils-8.x: a simple feature enhancement, and how to do it
Date: Fri, 30 Apr 2010 16:11:53 -0600 (MDT)
>> If all we have is strtod, there's no point doing a long-double compare.

True, UNLESS sscanf("%lg", &x) works: I've had to use that alternative
in the past.

>> ...
>> Even better, just compare the numbers as text, without converting them
>> to internal format.  This is already done for -n, and would be much
>> faster than any of the above approaches.  If done right it would be just
>> as accurate as gmp.  (It wouldn't be trivial, though.)
>> ...

Yes, that would work, but care needs to be taken to handle the formats
that strtold() supports (decimal 1.2345e+678 and C99 hexadecimal
0x1.f3dp-2047), and that essentially mentions having to convert from
hexadecimal to decimal, and effectively deal with many of the same
problems that strtold() handles.  The code also must deal with issues
of leading and trailing zeros in significand and exponent.

Quick: how are these ordered?

	1.00000000000000000000000000000000000000000000000000e-50
	0.00000000000000000000000000000000000000000000000001e+00

Answer: they are equal.

And these:

	+0.00000000000000000000000000000000000000000000000000e-50
	-0.00000000000000000000000000000000000000000000000000e+00

Answer: both are zero, but the negative one should precede the
positive one in sort (on the grounds that negative zero really means
tiny negative that was too small to represent).

So, indeed, a string-based comparison is not trivial.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe <at> math.utah.edu  -
- 155 S 1400 E RM 233                       beebe <at> acm.org  beebe <at> computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------




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.