From: Stephan Frank <defclass@go...> - 2013-11-16 19:09:14
the little benchmark at http://g000001.cddddr.org/3593549708 that some
of you may have seen via Reddit got me thinking about additional hooks
for sb-gmp into SBCL. However, the code for computing integer expt
raises some questions for me that some of you may know the details of or
at least have an opinion about.
Since we only operate on bignums and bignum-rationals the function
intexp is of particular interest. It uses a defparameter
*intexp-maximum-exponent* that is initialised to NIL.
If the absolute value of the requested power is larger than
*intexp-maximum-exponent* then an error is raised.
What is the purpose of the initialisation to NIL? Do we really want to
compute expt for powers larger than most-positive-fixnum (other than for
And even more interestingly:
CL-USER> (expt 2 most-positive-fixnum)
; Evaluation aborted on #<SIMPLE-ERROR "can't represent result of left
CL-USER> (expt 3 most-positive-fixnum)
[compute merrily until memory is exceeded...]
This strikes me as rather inconsistent; any opinions?
From: Paul Khuong <pvk@pv...> - 2013-11-25 20:09:41
Stephan Frank wrote:
> Since we only operate on bignums and bignum-rationals the function
> intexp is of particular interest. It uses a defparameter
> *intexp-maximum-exponent* that is initialised to NIL.
> What is the purpose of the initialisation to NIL? Do we really want to
> compute expt for powers larger than most-positive-fixnum (other than for
> base 1)?
Trawling through the commit logs shows that this variable initially
served to protect against a really bad failure mode (stack overflow?) in
bignum code. Now that it's easy to quickly generate GBs of data,
initialising this value to something large would be a good idea.
However, I'm not sure that the interface is ideal; ISTM that it would be
more useful to instead bound (within a small error) the number of bits
in the return value.
I also noticed that intexp doesn't special case ratio bases and ends up
computing GCDs to normalise ratios that are already simplified.
Anyway. +1 on enabling by default some early check for too-large bignums.