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

[Linda Walsh]

Paul Eggert wrote:
> Linda Walsh wrote:
> > > I didn't understand the code snippet you sent, but it appears to have 
> > > rounding
> > > errors.  'sort' doesn't have rounding errors when doing the 
> > > comparison in
> > > question.  Let's not introduce them now.
> > ---
> > It has to.  It's rounding to 2-3 digits.
>
> Sorry, I don't understand that comment.  'sort -h' does not round.  It 
> doesn't have to.  Your code *does* round, and I suppose in some sense it 
> "has to", but that's a bug compared to what 'sort' does now.
---
Perhaps, but what it does now is fail on the type of input
presented by the OP.  

vs.

the code you are saying has a 'bug' is the code that correctly
sorts the OP's test input -- but the rounding bit is in the
output routine.  Your needs may be different than mine, but
I think you were just talking about the expectation of using
"normalized-metric" numbers -- thus my consideration of it being
fair to produce rounded, "normalized-metric output.

vs. the existing product "sort -h" doesn't sort the input -- which
pretty much is a "fail" as far as handling non-normalized binary
input.  You can say, well it wasn't designed to do that...  but it
could up to 64-bits which would provide utility for the output of
coreutil's other tools.  I'd also add an "--si" to make it clear
it is tied to the same units used elsewhere.

The C++ code has similar output constraints -- in that it needs to put
out a 2-3 digit number.  But sort doesn't need a summary number -- it
just needs to sort the input -- where it fails.  

My sorting code loses no precision up to the Exabyte range (fits
in a 64-bit unsigned. The OP's input only used numbers up to the
low Gigabyte range.  To actually convert each number to a suffix
free 64-bit unsigned, and sort that, then print the original numbers
out in the sorted order would be well within sort's perview.  The
issue of bin or dec prefixes could be solved with a --si switch
paralleling the output of 'du'.

Please don't be offended by my suggestion that sort *could*
handle the OP's case w/o rounding.  I get that, right now,
this is an academic discussion.  However, if one offered such
sorting, wouldn't it follow that summation ability might be
asked for?  What to choose for output?  Isn't default
to choose #digits of your fewest-digits input (least
precision?)  Anyway, I just was disappointed at how 
quickly the OP's expectation for sort was shot down.