Re: bignum arithmetics

[hjstein@bfr.co.il (Harvey J. Stein)]

Keith Wright <kwright@tiac.net> writes:

 > Did you try it?  I used the following program.
 > (define (fact n)
 >   (let mul ((k 1)(p 1))
 >     (if (> k n) p (mul (+ k 1)(* k p)))))
 > after testing with (fact 4) and (fact 5), I tried
 > (fact 10000) and got something ending in
 > 000000000000000000000000000000000000000004617333575079170156
 > guile> (version)
 > "1.3a"
 > ~/downloads$ls -l `which guile`   
 > -rwxr-xr-x   1 root     root        14412 Jul 14 21:25 /usr/local/bin/guile
 > So I am using a rather old version.
 > 
 > I remember a discussion of exactly this bug a year or two ago,
 > with embarassingly long thread devoted to the question of
 > whether the result _should_ end in zeroes (trust me, it should).
 > I think somebody had claimed to have fixed it, and that I
 > believed them at the time.  The problem had to do with an out
 > of storage condition that was ignored, so if you have too
 > much RAM maybe it doesn't happen until the number gets
 > even bigger.  (I have 16M)

I have 64mb & guile reports that it's version 1.3a.

Test 1: (fact 10000)

returns a number ending in zeros.

Test 2: (fact 100000)

   ERROR: In procedure * in expression (* k p):
   ERROR: Memory allocation error
   ABORT: (memory-allocation-error)

   Type "(backtrace)" to get more information.

Test 3: (fact 20000)

   Last line of output is:

   0000000000000000000000000000000000000004616913888054776363

So, the bug still exists, at least in 1.3a.  But this isn't much newer
than the one you were testing.  So, I updated from anon cvs & ran the
same tests.  This time (fact 10000) & (fact 20000) ended in zeros &
(fact 100000) gave a memory allocation error.

So, it seems like it's been fixed.

-- 
Harvey J. Stein
BFM Financial Research
hjstein@bfr.co.il