[Gcl-devel] more on evenp bug

[Lou Glassy]

Some more information:

I'm running gcl-2.5.0 (cvs date 2002-0219).  The actual binaries
come from the gcl_2.5.0.cvs20020219-1_i386.deb Debian binary
package in the Debian unstable release.

My host is a Debian GNU/Linux 2.2 system (Intel Celeron cpu).

Here is some test output:
>(load "evenp-bug.cl")

Loading evenp-bug.cl

(BITS 0) 
(BITS 1)
[...uninteresting iterations deleted...]
(BITS 28) 
(BITS 29) 
(BITS 30) 
(BITS 31) 
(BITS 32) 
(RANDOM-VALUE 2229626773 EVENP-SAYS T REM-SAYS NIL) 
(RANDOM-VALUE 2718637453 EVENP-SAYS T REM-SAYS NIL) 
(RANDOM-VALUE 3444675521 EVENP-SAYS T REM-SAYS NIL) 
(RANDOM-VALUE 3893063129 EVENP-SAYS T REM-SAYS NIL) 
Finished loading evenp-bug.cl
T

>

Here is the lisp code that generated the preceding output:

(setf state-object (make-random-state t))

(dotimes (number-of-bits 33)
  (print (list 'bits number-of-bits))
  (dotimes (n 10)
    (setf random-value (1+ (random (expt 2 number-of-bits)
                               state-object)))
    (setf evenp-says (evenp random-value))
    (setf rem-says (if (= 0 (rem random-value 2)) 
                       't
                     nil))
    (when (not (equal evenp-says rem-says))
      (print (list 'random-value random-value 
                   'evenp-says evenp-says
                   'rem-says rem-says)))))


Looking through the source code, it looks like something
is happening in gcl/o/num_pred.c, in the function number_evenp().
Somehow when we exceed 32 bits in size (is this when we switch from 
using fixnums to bignums?), something goes berzerk.

Thanks kindly,

Lou Glassy (cs.montana.edu)