Hello and thanks for the feedback,

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. Up to now, I have not felt concerned by this issue and have little idea on the best way to solve it, but my first feeling from the guts is that some kind of bigger-integer with fixed dynamic, 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 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.

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.

Then also note that the Lisp code which I submitted actually contains both types of implementation: that using builtin support, and that not using it. The former is selected when the presence of builtin implementation is detected, 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 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.

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.

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. Then there was this lisp only implementation (that is still in the submitted code), 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, 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.
>
>

---

Nouveau Windows 7 : Simplifiez votre PC ! Trouvez le PC qui vous convient.