[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Support in sort for human-readable numbers
From: |
Pádraig Brady |
Subject: |
Re: Support in sort for human-readable numbers |
Date: |
Tue, 6 Jan 2009 17:26:29 +0000 |
User-agent: |
Thunderbird 2.0.0.6 (X11/20071008) |
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.
Re: Support in sort for human-readable numbers, Pádraig Brady, 2009/01/06
Message not available
- Re: Support in sort for human-readable numbers, Vitali Lovich, 2009/01/06
- Re: Support in sort for human-readable numbers,
Pádraig Brady <=
- Re: Support in sort for human-readable numbers, Vitali Lovich, 2009/01/06
- Re: Support in sort for human-readable numbers, Pádraig Brady, 2009/01/06
- Re: Support in sort for human-readable numbers, Vitali Lovich, 2009/01/07
- Re: Support in sort for human-readable numbers, Jim Meyering, 2009/01/07
- Re: Support in sort for human-readable numbers, Vitali Lovich, 2009/01/07
Re: Support in sort for human-readable numbers, Matthew Woehlke, 2009/01/13
Re: Support in sort for human-readable numbers, Vitali Lovich, 2009/01/13
Re: Support in sort for human-readable numbers, Paul Eggert, 2009/01/07