Custom Query (1030 matches)

[From Gilbert Baumann]

I found a bug with coercion of RATIOs to SINGLE-FLOATs, like:

(coerce (- (/ (1+ (expt 2 278)) (expt 2 265))) 'short-float) => 8192.0

Which has the wrong sign. This only happens with the 64 bit version and not with the 32 bit version. I consider that a pretty serious bug.

Here is the patch, it fixes %SHORT-FLOAT-RATIO.

*** l0-float.lisp	Sat Sep 24 00:12:44 2016
--- l0-float-fixed.lisp	Sat Sep 24 00:13:43 2016
***************
*** 528,534 ****
                 (make-short-float-from-fixnums 
                    (ldb (byte IEEE-single-float-digits  (- intlen  IEEE-single-float-digits)) int)
                    new-exp
!                    (if minusp 1 0)))
               ; den > num - exp negative
               (progn  
                 (float-rat-neg-exp num den (if minusp -1 1) nil t)))))))))
--- 528,534 ----
                 (make-short-float-from-fixnums 
                    (ldb (byte IEEE-single-float-digits  (- intlen  IEEE-single-float-digits)) int)
                    new-exp
!                    (if minusp -1 1)))
               ; den > num - exp negative
               (progn  
                 (float-rat-neg-exp num den (if minusp -1 1) nil t)))))))))

    (defparameter *rnd-state* (make-random-state t))

    (dotimes (i 300000)
      (let* ((rand-val (random #.(1- (expt 2 64)) *rnd-state*))
             (read-val (read-from-string (with-output-to-string (o)
                                           (pprint rand-val o)))))
        (assert (= rand-val read-val)
                nil
                "rand-val: ~S, read-val: ~S" rand-val read-val)))

At some point (it may be necessary to try a few times), the assert fails and the message is:

    rand-val: 1037244565857250958, read-val: 1037244565857250958

Inspecting the variables in SLIME debuggers shows this:

#<(INTEGER 536870912) #xE65086FE5202E8E>
--------------------
Value: 1037244565857250958 = #xE65086FE5202E8E = #o71450206774510027216 = #b1110 01100101 00001000 01101111 11100101 00100000 00101110 10001110 = 1.0260616E+19
Integer-length: 64



READ-VAL:

#<(INTEGER 536870912) #xE65086FE5202E8E>
--------------------
Value: 1037244565857250958 = #xE65086FE5202E8E = #o71450206774510027216 = #b1110 01100101 00001000 01101111 11100101 00100000 00101110 10001110 = 1.0372446E+18
Integer-length: 60

I (rme) was able to duplicate this on a 32-bit ARM lisp (I haven't tested an x8632 lisp), where the message was

> Error: rand-val: 1769403817437272421, read-val: 1769403817437272421
1 > :f 0
 (76BA44C8) : 0 (%ASSERTION-FAILURE NIL (= RAND-VAL READ-VAL) "rand-val: ~S, read-val: ~S" 1769403817437272421 1769403817437272421) 452
  (SETF-PLACES-P TEST-FORM STRING &REST CONDITION-ARGS)
   SETF-PLACES-P: NIL
   TEST-FORM: (= RAND-VAL READ-VAL)
   STRING: "rand-val: ~S, read-val: ~S"
   CONDITION-ARGS: (1769403817437272421 1769403817437272421)
1 > :arg 'condition-args 0
(1769403817437272421 1769403817437272421)
1 > (mapcar 'integer-length *)
(64 61)
1 > (mapcar 'uvsize **)
(3 2)

So, that's not right: the first value appears to be a three-digit bignum.

This makes me think that we are somehow allowing non-normalized bignums to escape from the lab. I wonder if there's an error in the guts of the implementation of cl:random.

​https://lists.clozure.com/pipermail/openmcl-devel/2017-January/011456.html

I get the following return values from INTEGER-DECODE-FLOAT. (Version 1.4-r13122 (WindowsX8632))

? (integer-decode-float 0s0)
0
-150
1
? (integer-decode-float 0f0)
0
-150
1
? (integer-decode-float 0d0)
0
-1074
1
? (integer-decode-float 0l0)
0
-1074
1

In contrast:

? (decode-float 0s0)
0.0
0
1.0
? (decode-float 0f0)
0.0
0
1.0
? (decode-float 0d0)
0.0D0
0
1.0D0
? (decode-float 0l0)
0.0D0
0
1.0D0

CLHS states that INTEGER-DECODE-FLOAT returns "the same last two values that are returned by decode-float". Observed behavior seems otherwise.