Marc:
This _num.scm does a few things:
1. It uses the ##fixnum.+? and ##fixnum.-? functions in ##+, ##-, and ##negate. Together with my changes to gambit.h yesterday, this should allow you to remove -fwrapv from the command line. (But don't add more code that assumes that signed arithmetic wraps!)
2. It uses a new fft algorithm for bignum multiplication that is provably correct. (The mathematics behind it is correct, I obviously didn't prove that the code as implemented is correct.) The code is faster on some machines (my PowerPC Macs) and slower on others (my opteron box). It's also shorter and clearer than the old code. (There are many more comments, and I included alternate simple implementations of the fft's for which gsc does not generate any code.) The new code uses a number of tables, total size about 24KB, to calculate dynamically the table of sines and cosines needed for the fft. (BTW, can you write some code to cache the result of making the table? If one has already computed a bigger table of sines and cosines, you can use it where one would otherwise calculate a smaller table.) The .o file is about 7KB bigger, so I got rid of about 17KB of code while adding 24KB of data. I checked that all this machinery is omitted if (use-fast-bignum-algorithms) is defined to be #f at the head of _num.scm.
Please look it over. It passes "make check" and I checked the fft bignum multiplication more thoroughly.
Brad
Afficher les réponses par date
The new fft routine is a complex fft rather than a real fft, and so a bigger intermediate f64 array is used for a multiplication of a bigger size, so we need
(define ##bignum.fft-mul-max-width (if (##fixnum? -1073741824) ; to avoid creating f64vectors that are too long 536870912 2097152)) (set! ##bignum.fft-mul-max-width ##bignum.fft-mul-max-width)
instead of
(define ##bignum.fft-mul-max-width (if (##fixnum? -1073741824) ; to avoid creating f64vectors that are too long 536870912 4194304)) (set! ##bignum.fft-mul-max-width ##bignum.fft-mul-max-width)
Brad