Re: Code for converting between Elisp and Calc floats

[Stefan Monnier]

>> 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).

> I did it this way because it allowed a simpler algorithm: in the
> conversion algorithm the integer size step is based on the number of
> decimal digits that Calc uses in representing big integers. The Calc
> big integers are not composed of 16bits integers (and actually there
> is not an integral number of bits, because these components are in
> radix 10). From that perspective it was easier if the number of bits
> of each component integer is passed along with the component integer
> in the interface.

I understand the code is simpler on the Lisp side, but I'm more
concerned about the C side.  Of course, if the Lisp side becomes
unmanageable it's also relevant.

>> 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.

> OK, this can be improved. Actually, my intention was not that these
> builtin functions were kind-of part of Calc library API, these are
> really internal things that the user developing above Calc should
> not need.

I understand they're not Calc-specific althought they'd currently only
be used by Calc.  That's good.  Still, Calc is the best sample-use we
have, so it's what we have to guess at what a good API should look like.

>> Also, how is math-lisp-float-binary-ieee754-conformance used?

> This is the switch between the two types of implementations: the one
> using builtin support, and the one not needing builtin support.

So (fboundp 'construct-float) would work as well?

> Note that I can imagine that it is possible to implement the
> construct/deconstruct builtin functions just using Lisp, this is after
> all just a matter of generating clean powers of 2.  But, since this
> code would be so machine/system dependant, and since Lisp would be so
> more uselessly complex than C code,I thought that it was a better
> choice to make it in C.

I think it fits better in C.  Basically, it would be the equivalent to
C's frexp.


        Stefan