Re: sort human readable suffixes

[Cornelis de Gier]

Paul Eggert wrote:
> Cornelis de Gier <address@hidden> writes:

> But strtod is way overkill, and it introduces errors and is slower.
> Wouldn't it be better to use the -n option as a model?  (Or perhaps
> combine with either -n or -g.)

You are right about speed, I tested to sort ls -lRh output (via a saved 
file to ignore differences in ls) of a linux kernel source tree:

sort -k5 -h takes twice the time on ls -lRh than sort -k5 -g on ls -lR.
sort -k5 -g takes about 60 % more time than sort -k5 -n.

Can you explain why strtod introduces errors?

The -n algorithm is fairly complicated (for me). I don't see a way to 
introduce the multiplication factors.

> > The E doesn't create a problem in this example:...
> > Does it give problems in other situations?
>
> Sure: e.g., "0xEE" is ambiguous (assuming C99 strtod, which parses
> hexadecimals).  But perhaps we can say we don't support that....

Like in 0xE times exa or 0xEE? The question related to problems with the 
 exponent E as used in scientific notation. Does it give problems there?

The goal in my opinion is to be able to sort the -h output from df, du 
and ls. They do not emit either hexadecimals or exponential numbers, so 
it seems an option not to support them.

Cornelis