bignums

[Jon L White <edsel!jonl@labrea.stanford.edu>]

re:  I'd also advocate further specifying that "bignums" really
    should have range limited only my memory space and that using a fixed 
    bit-field size is NOT an appropriate implementation of "bignums".

Have you considered the possibility that for even moderately small 
"fixed bit-field" sizes, the range of bignums specified is larger 
than any reasonable amount of virtual memory that your operating 
system will allow you to have (and garbage collect)?

Seriously, I have advocated a minimum size for most-positive-fixnum as
about 2â??24-1, which I think is defensible in terms of hardware to do
"efficient" arithmetic.  Do you feel like proposing (and defending) a 
minimum size for most-positive-bignum?

Two interesing stories (really true!):

 (1) During the days that Bill Gosper was computing larger and larger 
     decimal expansions of pi, he happened upon a huge bignum on the 3600 
     that caused it to "die of constipation".  It seems that sufficient
     space had been allocated for it, but at the time of a GC flip, there
     wasn't sufficient space to copy it.  [This was about 1984 I think.]

 (2) A similar thing actually happened to me later, on a 3600.  Suspecting
     that I knew about a "bit-field size", I was intending to compute 
     log2(most-positive-bignum); but unfortunately a typo put in some extra
     shifting steps, so that I actually computed something close to 
     most-positive-bignum.  As in RWG's case, I finally got caught by the 
     GC-flip, and fell into some sort of debugger loop.  I intercepted it 
     a couple days later in a state of catatonia -- apparently it was trying
     to print out the arguments in the frame that had caused the death, and 
     printing most-positive-bignum in base 10 appeared to be taking some time
     . . . 


-- JonL --