[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: |
Wed, 7 Jan 2009 01:01:54 +0000 |
User-agent: |
Thunderbird 2.0.0.6 (X11/20071008) |
Vitali Lovich wrote:
> On Tue, Jan 6, 2009 at 12:26 PM, Pádraig Brady <address@hidden> wrote:
>> 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.
> Perhaps - but for sort, at least from my thinking of how I would
> implement this, the additional logic (at least to behave correctly on
> all inputs) would be somewhat complicated.
I thought it would be easy just to ignore a trailing i?B?
> Can you please explain why
> you believe this belongs in sort
because I think it's a common enough format and getting
more common since it's an IEC defined standard.
> and wouldn't be better served by
> pre-processing the text before sort & post-processing it after as
> necessary?
that's a little awkward and inefficient.
> Supporting all the various ways the human_readable can be output is
> just not practical or even useful
just ignore an optional trailing iB is all I'm suggesting.
If it's difficult or inefficient then don't worry about it.
>> 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.
> That's definitely not an acceptable solution because the behavior
> would be incorrect if you had something like 2Klingongs.
lol good example. Yes you're right.
>>>> Yep if you're not supporting overlapping number ranges then
>>>> you can skip the number comparison totally if the suffixes don't match.
> Debatable. You'd still have to scan the string to find the end of the
> number to find the suffix. And if you get a miss (i.e. same
> suffix-level), then you'll have to scan the strings again, performing
> the comparison.
don't worry about this for the moment.
thanks,
Pádraig.
- Re: Support in sort for human-readable numbers, (continued)
Re: Support in sort for human-readable numbers, Vitali Lovich, 2009/01/04
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, 2009/01/06
- 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/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