Re: Code for converting between Elisp and Calc floats

[David Kastrup]

Stefan Monnier <address@hidden> writes:

>>> As for the feature itself, I'm not sure whether I like it.
>>> Could someone explain exactly what's the rationale behind this
>>> (e.g. a typical use case), what alternatives were considered, etc...?
>> Vincent explained this to me, but I expect he'll come along and do a
>> better job explaining than I can.
>
> Is he reading this thread?
>
>>> E.g. an "obvious" alternative would be to add builtin "big floats" via
>>> libgmp or some such.
>> Using libgmp in Emacs has been discussed in the past, but as I recall
>> hasn't had much support.
>
> It hasn't had much support indeed, mostly for lack of interest
> in bignums.  But if we decide bignums deserve some C code, then maybe
> libgmp would be a good idea.  Then again, without knowing the whys and
> hows, it's hard to tell.

There are few areas of importance.  One would be buffer_size.  Putting
them transparently in there would imply having them all over the place
in overlay positions, point and so on.  I am also not sure that bignums
of equal value compare as eq (floats don't) and there is likely code
around relying on it.  The buffer size problem would likely be less
radically addressed by adding another bit of tagging, and then use half
of the possible values for integers, giving a range of -2^30 .. 2^30-1.
That's what XEmacs does, and it goes a far way of extending the point of
nuisance.

Of course calc could profit if one ripped out all of its
multiple-precision list-based code (does not even use floats).  But
that would not require a transparent bignum type.  An on-demand type
would suffice.

-- 
David Kastrup