bug#21000: coreutils 8.24 sort -h gets ordering wrong

[Pádraig Brady]

On 07/07/15 16:27, Paul Eggert wrote:
> Christopher Samuel wrote:
>> it appears that this ordering is derived purely on
>> an ordering of the suffixes rather than doing any form of conversion.
> 
> It's not purely the suffixes; it looks at suffixes first, and looks at the 
> numbers if the suffixes are equal.
> 
> Looking at both would require arbitrary-precision arithmetic, something that 
> 'sort' doesn't do (it does only arbitrary-precision comparison).  It would 
> also 
> require knowing whether the base was 1000 or 1024.  Bit of a hassle, that.
> 
> numfmt is a workaround, but has rounding problems.

numfmt should use a less naïve method to convert to floating point.
It could and probably should use something like mpfr
to improve precision and rounding.
In saying that though, it should be usuable for a very
large range of inputs.

$ numfmt 0.000000000000000001
0.000000000000000001
$ numfmt 9999999999999999999
9999999999999999999
$ numfmt 9999999999999999999 --to=si
10E