Re: Support in sort for human-readable numbers

[Pádraig Brady]

Vitali Lovich wrote:
> On Tue, Jan 6, 2009 at 10:19 AM, Pádraig Brady <address@hidden> wrote:
>> I like the idea.
>>
>> So it doesn't support sorting these correctly for example:
>>
>> 999MB
>> 998MiB
>> 1GiB
>> 1030MiB
>>
>> I.E. a mixture of ^2 and ^10 are not supported,
>> nor overlapping number ranges.

I'm not complaining about the above. Just clarifying.

>> +  /* FIXME: maybe add option to check for longer suffixes (i.e. gigabyte) */
>>
>> You should allow at least G, GiB and GB formats.
>> Probably should print error if more than one of those
>> formats used, since that's not supported.
>
> I dunno if you read my previous post, but I presented the reasoning
> that if the user has some kind of longer format, it's better handled
> by piping the input through a sed script first.  Can you present a
> situation where it would be better for sort itself to try and parse
> longer suffixes?
> 
> On a side note, the XiB format (MiB, GiB) is extremely uncommon in my
> opinion.

It's debatable, but I think we should support the XiB and XB formats
as I've seen them quite often, and certain coreutils like dd for example
take this format as a size specifier. Also look at human_readable() from gnulib.

Alternatively you could allow any string starting with [KMGT..]
to allow things like KB/s KiBuckets, but then it would be
tricky to flag mixtures of KiB and KiBuckets as an error for example.

>> +  /* FIXME:  a_order - b_order || raw_comparison can be used - would that
>> +     be faster? */
>>
>> Yep if you're not supporting overlapping number ranges then
>> you can skip the number comparison totally if the suffixes don't match.
> Actually it has nothing to do that.  I'm was just thinking that the
> equality operation I'm testing for is already essentially doing a
> subtraction and then I'm returning the actual subtraction itself.

Oh right.
Anyway the optimization I mentioned would probably be useful.

cheers,
Pádraig.