Re: Bignum support
Hrvoje Niksic <hniksic(a)arsdigita.com> writes:
> 1. Do pepole want bignum support?
How are you planning to add it? Is (* 1000000 1000000) just going to
work?
Yes.
Most importantly, how much of a slowdown to you expect? Every XINT
will need to be reviewed and changed into one of:
* XINT_FIXNUM: convert fixnum to integer, argument must be fixnum.
Caller should have run CHECK_FIXNUM.
* XINT_COERCE_FIXNUM: convert fixnum or bignum to integer, but throw
an error if the bignum is not representable as integer. Caller
should have run CHECK_INT.
* XINT_ANY: convert fixnum or bignum to a C object that represents
bignums.
Not really. If index ((point) etc.) is not allowed to have
bignum representable as integer, XINT_COERCE_FIXNUM is not
necessary. That's why I asked in previous post. I don't
think people want to do something like (make-string (* 2
most-positive-fixnum) ?a) If people really want to have 2GB
buffer, it's possible to implement it but they must accept
some slow down.
I cannot be sure about performance because obviously I did
no benchmark. However, my guess is that slow down will not
be severe. Every XINT will need to have one more check to
signal better error when argument is bignum. This won't be
a big issue since additional check is called only when
XINT's argument is not a fixnum.
Every XINT in numeric functions will be converted to
something similar to XINT_ANY. But my sample implementation
doesn't convert everything into bignum. If arguments are
all fixnum and the result fits in fixnum range, all
operations are performed as fixnum. I think fixnum
operations won't slow down much except a few more check for
bignum and a few more function call (you won't be able to
call just + in C).
--
Yoshiki Hayashi