Re: Converting an Integer into Human Readable String

[Pascal J. Bourguignon]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Pascal J. Bourguignon" <pjb@informatimago.com>
>> 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__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.