[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Converting an Integer into Human Readable String

From: Pascal J. Bourguignon
Subject: Re: Converting an Integer into Human Readable String
Date: Sat, 09 Apr 2011 11:33:29 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: "Pascal J. Bourguignon" <address@hidden>
>> Date: Fri, 08 Apr 2011 13:41:30 +0200
>> Instead, you could have had some fun, and implement yourself the
>> required function.   Well, now you've got only what you merit, here I
>> had all the fun, you can have the function:
>>     (format-human-readable-big-number 123456789012
>>                                       *normal-format*
>>                                       *exceptional-format*
>>                                        "B" t :binary)
>>     --> "  114.978 GiB"
> That's very impressive, but at closer look, I found the following
> problems with this implementation:
>  . It cannot be evaluated in Emacs Lisp without commenting out the
>    part between "#|" and "|#".
>  . It cannot be evaluated on a 32-bit machine without commenting out
>    some parts of the integer test values in the test harness, due to
>    integer overflows.
>  . When the last argument is :binary, it produces wrong results for
>    numbers between 1000*2^N and 1023*2^N.  E.g.,
>     (format-human-readable-big-number 1023  "%.1f" "%13.3e" "B" t :binary)
>       => "   1.023e+003 B"
>    whereas I'd expect "1023 B" instead.
>  . It always produces results with a fixed number of digits after the
>    decimal, determined by the value of *normal-format*.  Thus, with a
>    format of "%.1f" it will always produce 1 digit after the decimal,
>    even if that digit is zero:
>     (format-human-readable-big-number 900  "%.1f" "%13.3e" "B" t :binary)
>       => "900.0 B"
>    which is IMO ugly; "ls -lh" produces just "900" in this case.  This
>    cannot be remedied by using "%.0f" as the normal format, because
>    then it will always round to the nearest integral value, and the
>    fractions will never be shown; again, this is different from "ls -lh".

Thanks for the bug report.
Contributions are welcome.

__Pascal Bourguignon__           
A bad day in () is better than a good day in {}.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]