From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Code for converting between Elisp and Calc floats Date: Sun, 25 Oct 2009 22:30:40 -0400 Message-ID: References: <200910082047.n98KlkAB020482@godzilla.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1256524260 31213 80.91.229.12 (26 Oct 2009 02:31:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 26 Oct 2009 02:31:00 +0000 (UTC) Cc: cyd@stupidchicken.com, emacs-devel To: Vincent =?iso-8859-1?Q?Bela=EFche?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 26 03:30:53 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1N2FMC-0000Na-8Q for ged-emacs-devel@m.gmane.org; Mon, 26 Oct 2009 03:30:52 +0100 Original-Received: from localhost ([127.0.0.1]:45869 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N2FMB-0007Qs-Dh for ged-emacs-devel@m.gmane.org; Sun, 25 Oct 2009 22:30:51 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N2FM6-0007Pb-4d for emacs-devel@gnu.org; Sun, 25 Oct 2009 22:30:46 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N2FM1-0007Og-Lx for emacs-devel@gnu.org; Sun, 25 Oct 2009 22:30:45 -0400 Original-Received: from [199.232.76.173] (port=38519 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N2FM1-0007Od-GS for emacs-devel@gnu.org; Sun, 25 Oct 2009 22:30:41 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:39351 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N2FM1-0008Gd-40 for emacs-devel@gnu.org; Sun, 25 Oct 2009 22:30:41 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFADun5EpLd/xb/2dsb2JhbACBT9QchD8EgV6GVg X-IronPort-AV: E=Sophos;i="4.44,623,1249272000"; d="scan'208";a="48147915" Original-Received: from 75-119-252-91.dsl.teksavvy.com (HELO ceviche.home) ([75.119.252.91]) by ironport2-out.pppoe.ca with ESMTP; 25 Oct 2009 22:30:40 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 1D214B44C9; Sun, 25 Oct 2009 22:30:40 -0400 (EDT) In-Reply-To: ("Vincent =?iso-8859-1?Q?Bela=EFche=22's?= message of "Sun, 25 Oct 2009 20:29:45 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:116407 Archived-At: > First, I would like to clarify that I was not aware of the issue of > buffer size and pointer representation and that this was not my > intent. Indeed it has nothing to do with the discussion at hand. > Then concerning the need for built-in support (point raised by > cyd(string 64)stupidchicken.com), I fully agree that it is possible to > do without it but as far as I made it, it was at the cost of > some accuracy. That's interesting, so the main purpose is accuracy. > First notes that the code that I submitted use built-in support only > for a tiny part of the job that is kind-of bitwise access to IEEE754 > floats, the main part of the job (the computation from radix 10 to > radix 2) is entirely done in Lisp. So the built-in function are quite > generic ones and could be used by other libraries needing to generate > specific IEEE754 floats. I didn't see this code, then (the code I saw only included C code). Could someone describe the general skeleton of the whole code (plus which part is in C, and what are the entry points)? > The reason why builtin support is needed is that without it there are > losts of cases when some number that should convert without any loss > of information, will suffer from some rounding error. This is error is > in the magnitude of the quantization accuracy of the number, so it > should not be too harmful: however I felt that it is a pity when you > can get something better not to have it. If you take (calc-in "3.5") as input rather than 3.5, then there is no such issue, right? > The reason for this issue may be simply that the Lisp-only code which > I wrote is not good enough, I have no formal proof that to that extent > using builtin is a must. So if you can take this code and achieve to > make it all Lisp, please feel free to do that. For instance if you > could write Lisp only function doing exactly the same job as the > builtin functions, then this would be quite an acceptable way to > me. I did not try that, because I felt that it was so considerably > more simple to do this in C than in Lisp, that I did not think that it > would be an issue if this part is done in C, once people agree on the > need for the contribution, and on the algorithm used to make the > conversion, along with the split between the Lisp only part and the > C code. I think I see what your two functions are doing, but I think their naming and interface is a bit more complex than needed. I'd suggest to drop the reference to ieee754 from the name and doc (they should just work for whatever floats are used internally, which in practice is just what `double' uses in the C compiler used to compile Emacs). Also, the mantissa should probably be represented as either a single integer or a list of integers where each integer provides 16bits of data (that's a format already used elsewhere in Emacs to represent "large integers" such as for time). You could rename them to something like construct-float and deconstruct-float. I'd also rename the mantissa and exponent size info, or maybe even consider providing it differently (in case its use is always linked to calls to one of the previous 2 functions, maybe those functions could return the relevant info. E.g. make-float could return the part of the mantissa it ignored). Since you're using those constants, you clearly know better how they're used, so I'll let you figure out whether there's a better way to ptovide the same info. Also, how is math-lisp-float-binary-ieee754-conformance used? > Note that it took to me some time to make this work, the first attempt > was a very simple Calc format to a string, followed by string to > number, or vice versa. What was the problem with this simple solution? Stefan