From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?iso-8859-1?B?VmluY2VudCBCZWxh72NoZQ==?= Newsgroups: gmane.emacs.devel Subject: RE: Code for converting between Elisp and Calc floats Date: Sun, 25 Oct 2009 20:29:45 +0100 Message-ID: References: <200910082047.n98KlkAB020482@godzilla.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Content-Type: multipart/alternative; boundary="_d9bf2dcc-74aa-4f35-97ab-ec5b3bf5991d_" X-Trace: ger.gmane.org 1256499027 18982 80.91.229.12 (25 Oct 2009 19:30:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 25 Oct 2009 19:30:27 +0000 (UTC) Cc: emacs-devel To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 25 20:30:20 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 1N28nC-0001ii-Kq for ged-emacs-devel@m.gmane.org; Sun, 25 Oct 2009 20:30:20 +0100 Original-Received: from localhost ([127.0.0.1]:38628 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N28nC-0005xa-5m for ged-emacs-devel@m.gmane.org; Sun, 25 Oct 2009 15:30:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N28mm-0005mS-HC for emacs-devel@gnu.org; Sun, 25 Oct 2009 15:29:52 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N28mh-0005j3-H6 for emacs-devel@gnu.org; Sun, 25 Oct 2009 15:29:51 -0400 Original-Received: from [199.232.76.173] (port=58884 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N28mh-0005iy-1P for emacs-devel@gnu.org; Sun, 25 Oct 2009 15:29:47 -0400 Original-Received: from blu0-omc1-s19.blu0.hotmail.com ([65.55.116.30]:29618) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N28mg-0004oq-MG for emacs-devel@gnu.org; Sun, 25 Oct 2009 15:29:46 -0400 Original-Received: from BLU104-W16 ([65.55.116.8]) by blu0-omc1-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Oct 2009 12:29:46 -0700 X-Originating-IP: [92.135.119.98] Importance: Normal In-Reply-To: <87d44bef7f.fsf@stupidchicken.com> X-OriginalArrivalTime: 25 Oct 2009 19:29:46.0235 (UTC) FILETIME=[82988CB0:01CA55A9] X-detected-operating-system: by monty-python.gnu.org: Windows 2000 SP4, XP SP1+ 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:116398 Archived-At: <87d44bef7f.fsf@stupidchicken.com> MIME-Version: 1.0 --_d9bf2dcc-74aa-4f35-97ab-ec5b3bf5991d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello and thanks for the feedback=2C First=2C I would like to clarify that I was not aware of the issue of buffe= r size and pointer representation and that this was not my intent. Up to no= w=2C I have not felt concerned by this issue and have little idea on the be= st way to solve it=2C but my first feeling from the guts is that some kind = of bigger-integer with fixed dynamic=2C e.g. 64bit integer would be a bette= r option than arbitrary dynamic true bignums. Bignums should be really rese= rved for some math or financial things were you need no limitation. Then concerning the need for built-in support (point raised by cyd(string 6= 4)stupidchicken.com)=2C I fully agree that it is possible to do without it = but as far as I made it=2C it was at the cost of some accuracy.=20 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=2C t= he main part of the job (the computation from radix 10 to radix 2) is entir= ely 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. Then also note that the Lisp code which I submitted actually contains both = types of implementation: that using builtin support=2C and that not using i= t. The former is selected when the presence of builtin implementation is de= tected=2C while the other one should be selected otherwise (well I have not= fully checked whether that switch works well). 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 informat= ion=2C will suffer from some rounding error. This is error is in the magnit= ude of the quantization accuracy of the number=2C so it should not be too h= armful: however I felt that it is a pity when you can get something better = not to have it.=20 The reason for this issue may be simply that the Lisp-only code which I wro= te is not good enough=2C I have no formal proof that to that extent using b= uiltin is a must. So if you can take this code and achieve to make it all L= isp=2C please feel free to do that. For instance if you could write Lisp on= ly function doing exactly the same job as the builtin functions=2C then thi= s would be quite an acceptable way to me. I did not try that=2C because I f= elt that it was so considerably more simple to do this in C than in Lisp=2C= that I did not think that it would be an issue if this part is done in C= =2C once people agree on the need for the contribution=2C and on the algori= thm used to make the conversion=2C along with the split between the Lisp on= ly part and the C code. Note that it took to me some time to make this work=2C the first attempt wa= s a very simple Calc format to a string=2C followed by string to number=2C = or vice versa. Then there was this lisp only implementation (that is still = in the submitted code)=2C and then only I made a novel implementation with = the use of two builtin primitives. Vincent. > From: cyd@stupidchicken.com > To: vincent.b.1@hotmail.fr > Date: Sun=2C 25 Oct 2009 10:11:16 -0400 > CC: emacs-devel@gnu.org > Subject: Re: Code for converting between Elisp and Calc floats > [SNIP] > Could you discuss why this needs built-in support? It should be > possible to write a Lisp function or macro that automatically converts > Lisp expressions based on Lisp floats into Lisp expressions based on > calc floats. >=20 >=20 =20 _________________________________________________________________ Nouveau Windows 7 : Simplifiez votre PC ! Trouvez le PC qui vous convient. http://clk.atdmt.com/FRM/go/181574580/direct/01/= --_d9bf2dcc-74aa-4f35-97ab-ec5b3bf5991d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello and thanks for the feedback=2C

First=2C I would like to clarif= y that I was not aware of the issue of buffer size and pointer representati= on and that this was not my intent. Up to now=2C I have not felt concerned = by this issue and have little idea on the best way to solve it=2C but my fi= rst feeling from the guts is that some kind of bigger-integer with fixed dy= namic=2C e.g. 64bit integer would be a better option than arbitrary dynamic= true bignums. Bignums should be really reserved for some math or financial= things were you need no limitation.

Then concerning the need for bu= ilt-in support (point raised by cyd(string 64)stupidchicken.com)=2C I fully= agree that it is possible to do without it but as far as I made it=2C it w= as at the cost of some accuracy.

First notes that the code that I s= ubmitted use built-in support only for a tiny part of the job that is kind-= of bitwise access to IEEE754 floats=2C the main part of the job (the compu= tation 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 needin= g to generate specific IEEE754 floats.

Then also note that the Lisp = code which I submitted actually contains both types of implementation: that= using builtin support=2C and that not using it. The former is selected whe= n the presence of builtin implementation is detected=2C while the other one= should be selected otherwise (well I have not fully checked whether that s= witch works well).

The reason why builtin support is needed is that = without it there are losts of cases when some number that should convert wi= thout any loss of information=2C will suffer from some rounding error. This= is error is in the magnitude of the quantization accuracy of the number=2C= 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.

The reason for this issue= may be simply that the Lisp-only code which I wrote is not good enough=2C = I have no formal proof that to that extent using builtin is a must. So if y= ou can take this code and achieve to make it all Lisp=2C please feel free t= o do that. For instance if you could write Lisp only function doing exactly= the same job as the builtin functions=2C then this would be quite an accep= table way to me. I did not try that=2C because I felt that it was so consid= erably more simple to do this in C than in Lisp=2C that I did not think tha= t it would be an issue if this part is done in C=2C once people agree on th= e need for the contribution=2C and on the algorithm used to make the conver= sion=2C along with the split between the Lisp only part and the C code.
=
Note that it took to me some time to make this work=2C the first attemp= t was a very simple Calc format to a string=2C followed by string to number= =2C or vice versa. Then there was this lisp only implementation (that is st= ill in the submitted code)=2C and then only I made a novel implementation w= ith the use of two builtin primitives.

=A0 =A0Vincent.


>=3B From: cyd@stupidchicken.com
>=3B To: vincent.b.1@hotmail.fr>=3B Date: Sun=2C 25 Oct 2009 10:11:16 -0400
>=3B CC: emacs-devel@= gnu.org
>=3B Subject: Re: Code for converting between Elisp and Calc f= loats
>=3B
[SNIP]

>=3B Could you discuss why this needs bu= ilt-in support? It should be
>=3B possible to write a Lisp function o= r macro that automatically converts
>=3B Lisp expressions based on Lis= p floats into Lisp expressions based on
>=3B calc floats.
>=3B >=3B

Nouveau Windows 7 : Simplifiez votre P= C ! Trouvez le PC qui vous convient. = --_d9bf2dcc-74aa-4f35-97ab-ec5b3bf5991d_--