Re: Code for converting between Elisp and Calc floats

[Stefan Monnier]

> 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