On 24/04/10 02:30, Nelson H. F. Beebe wrote:
[snipped very useful floating point info]
> At present, up to version 8.5, coreutils uses only type double in its
> implementation of the -g sort-ordering option. The result is that it
> is unable to correctly sort files that use the entire number range of
> IEEE 754 binary arithmetic; indeed, the double format covers only
> about 6% of the possible binary range, and 5% of the decimal range.
This should do it.
Using long double has no impact on performance on my pentium-m linux laptop.
Note I tried converting to use xstrtold(), but that added about 25% overhead :(
diff --git a/src/sort.c b/src/sort.c
index 6d47b79..a815244 100644
--- a/src/sort.c
+++ b/src/sort.c
@@ -1855,10 +1855,16 @@ general_numcompare (const char *sa, const char *sb)
/* FIXME: maybe add option to try expensive FP conversion
only if A and B can't be compared more cheaply/accurately. */
+#if HAVE_C99_STRTOLD /* provided by c-strtold module. */
+# define STRTOD strtold
+#else
+# define STRTOD strtod
+#endif
+
char *ea;
char *eb;
- double a = strtod (sa, &ea);
- double b = strtod (sb, &eb);
+ long double a = STRTOD (sa, &ea);
+ long double b = STRTOD (sb, &eb);
/* Put conversion errors at the start of the collating sequence. */
if (sa == ea)
> However, note that some aberrant systems implement "long double" as
> "double" (e.g., DEC Alpha OSF/1 4.x, Minix, and most *BSD
> distributions), and some implement it in doubled-double format, which
> increases the precision, but leaves the range at that of double.
> Examples of the latter include Apple Mac OS X on PowerPC, IBM AIX on
> PowerPC, and SGI IRIX MIPS.
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.
cheers,
Pádraig.
