[Scm-discuss] 5f2 regression: r4rstest.scm fails on 32-bit

[Steve VanDevender]

Steve VanDevender writes:
 > Steve VanDevender writes:
 >  > This has been bugging me for a while too.  Here are some even more
 >  > precise cases down to successive integers that, when converted to real
 >  > numbers, print or do not (I also enabled one of the debugging printfs in
 >  > pdbl2str):
 >  > 
 >  > > (- (expt 2 49) 1)
 >  > 562949953421311
 >  > > 562949953421311.
 >  > mantissa = 1 -> #x1ffffffffffff0; e2 = 49 -> -4; point = -1; ndig = 53 -> 
 > 53
 >  > 5.62949953421311e14
 >  > > (expt 2 49)
 >  > 562949953421312
 >  > > 562949953421312.
 >  > mantissa = 0.5 -> #x10000000000000; e2 = 50 -> -3; point = 0; ndig = 53 
 > -> 53
 >  > 
 >  > ;ERROR: "/home/stevev/scm/Transcen.scm": round-quotient: Wrong type in 
 > arg1 (0 . 0)
 >  > ; in scope:
 >  > ;   (z1 z2)  procedure expt
 >  > ; defined by load: "/home/stevev/scm/Transcen.scm"
 > 
 > I've narrowed this down a bit further.  When SCM attempts to print
 > 562949953421312. it calls scm_round_quotient at line 182 of scl.c:
 > 
 > 179      /* try first with starved precision */
 > 180      {
 > 181        SCM den = scm_ash(MAKINUM(1L), MAKINUM(point - e2));
 > 182        num = product(mant, VELTS(pows5)[- (long) point]);
 > 183        bigrecy(mant);
 > 184        quo = scm_round_quotient(num, den);
 > 185        if (pmantexp2dbl(quo, point) != f) {
 > 
 > And then in scm_round_quotient it fails the assert at line 322:
 > 
 > 319  #ifdef BIGDIG
 > 320    if (NINUMP(num)) {
 > 321      long w;
 > 322      ASRTER(NIMP(num) && BIGP(num), num, ARG1, s_rquotient);
 > 323      if (NINUMP(den)) {
 > 324        ASRTGO(NIMP(den) && BIGP(den), badden);
 > 325        return divbigbig(BDIGITS(num), NUMDIGS(num), BDIGITS(den), 
 > NUMDIGS(den),
 > 326                         BIGSIGN(num) ^ BIGSIGN(den), 3);
 > 327      }
 > 
 > I can't say I can really follow what the code is doing here, but from
 > the error SCM throws:
 > 
 > ;ERROR: "/home/stevev/scm/Init5f2.scm": round-quotient: Wrong type in arg1 
 > (0 . 0)
 > 
 > This suggests that the parameter "num" now refers to a recycled bignum.
 > Unfortunately I don't really understand *how* it got into that state
 > from reading the code.

OK, if I'm reading the code for product() correctly, if one of the
arguments is 1, then it just returns the other argument.  This isn't a
problem on 64-bit systems where things like mant and num have values
that fit in INUMs which bigrecy() doesn't alter.  But on 32-bit systems,
there are cases where:

* mant is a bignum
* num becomes an alias for mant if the second argument to product() is 1
* bigrecy(mant) therefore wipes out both mant and num
* num gets used later after being wiped out
* kaboom

It seems as if this needs some attention from someone who better
understands the new code in pdbl2str and more about SCM internals as
even after I try commenting out calls to bigrecy() in this code path I
still keep getting errors.