|
From: | Cornelis de Gier |
Subject: | Re: sort human readable suffixes |
Date: | Sun, 30 May 2004 10:41:12 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |