From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: Converting an Integer into Human Readable String Date: Sat, 09 Apr 2011 11:46:34 +0300 Message-ID: <83bp0fu80l.fsf@gnu.org> References: <4fa1ed35-b35b-4c8d-bfca-d7fae8da913b@glegroupsg2000goo.googlegroups.com> <87vcyphswl.fsf@kuiper.lan.informatimago.com> NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1302338990 16075 80.91.229.12 (9 Apr 2011 08:49:50 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 9 Apr 2011 08:49:50 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Apr 09 10:49:46 2011 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q8TrF-0004hi-V7 for geh-help-gnu-emacs@m.gmane.org; Sat, 09 Apr 2011 10:49:41 +0200 Original-Received: from localhost ([127.0.0.1]:47071 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q8Tqz-0004IU-O8 for geh-help-gnu-emacs@m.gmane.org; Sat, 09 Apr 2011 04:49:13 -0400 Original-Received: from [140.186.70.92] (port=46182 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q8TqX-00046M-Qs for help-gnu-emacs@gnu.org; Sat, 09 Apr 2011 04:48:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q8TqP-0006T6-Cu for help-gnu-emacs@gnu.org; Sat, 09 Apr 2011 04:48:38 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:37073) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q8TqP-0006Sh-4h for help-gnu-emacs@gnu.org; Sat, 09 Apr 2011 04:48:37 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LJD00K00N09YJ00@a-mtaout22.012.net.il> for help-gnu-emacs@gnu.org; Sat, 09 Apr 2011 11:48:35 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.229.239.68]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LJD00KF0N4XIH50@a-mtaout22.012.net.il> for help-gnu-emacs@gnu.org; Sat, 09 Apr 2011 11:48:35 +0300 (IDT) In-reply-to: <87vcyphswl.fsf@kuiper.lan.informatimago.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.172 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:80731 Archived-At: > From: "Pascal J. Bourguignon" > 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".