Does slime introduce errors into cmucl?
in [Lisp]
|
Prev: AUTHENTIC DESIGNER HANDBAGS & ACCESSORIES WWW.VOGUELANDE.COM CHANEL LOUIS VUITTON
Next: Re^2: slime errors in cmucl?
From: Lieven Marchand on 30 Mar 2010 17:17 Tim Bradshaw <tfb(a)tfeb.org> writes: > On 2010-03-30 21:00:01 +0100, Peter Keller said: > >> I would think this code is suspect since you don't take into consideration >> numerical analysis techniques for comparing floating point numbers. > > I don't think so. I think it should only fail if the same operations > on bitwise-identical doubles can sometimes produce different answers > (where the operations are multiplication and addition). They still can. Doubles in the FPU registers are 80 bits but are typically stored back to memory as 64 bits. So a computation can have different results depending on how many of the registers are already in use or when and how the compiler decides to store them back.
From: Tim Bradshaw on 30 Mar 2010 17:37 On 2010-03-30 22:17:35 +0100, Lieven Marchand said: > They still can. Doubles in the FPU registers are 80 bits but are > typically stored back to memory as 64 bits. So a computation can have > different results depending on how many of the registers are already in > use or when and how the compiler decides to store them back. This has to be wrong, doesn't it? Are you saying that on x86s the multiplying two doubles produces results which have essentially random bits in them?
From: Raymond Toy on 30 Mar 2010 22:47 On 3/30/10 2:20 PM, Norbert_Paul wrote: > I startet testing some matrix computation routines in slime using rt. > (This was useful: Made me spot a bug) > > But then however I set up a test case using random dimensions and values > and let it run 10000 times and sometimes the tests fails, even when the > resulting matrix was correct. (I stored the fixture in global variables to > inspect). > > All tests run fine in bare cmucl and bare sbcl (on my system sbcl > doesn't work > together with slime). In the slime sbcl-repl (which I took, brother, > but there it didn't serve me well), however, the following sometimes fails: > > (dotimes (i 100000) > (let* ((v1 (list (random 10d0)(random 10d0))) > (v2 (list (random 10d0)(random 10d0))) > (dot1 (reduce #'+ (mapcar #'* v1 v2))) > (dot2 (reduce #'+ (mapcar #'* v1 v2)))) > (if (/= dot1 dot2) > (error "This REPL doesn't serve me well, brother.")))) > > I'm using Debian squeeze with > GNU Emacs 23.1.1 (i486-pc-linux-gnu, GTK+ Version 2.18.2) of > 2009-11-02 on raven, modified by Debian > and > slime version 1:2010022-1. > > Is that a known bug in slime or any other of aforementioned components? What swank:*communication-style* do you use? I think, but I'm not sure, that anything other than :fd-handler is suspect. CMUCL is not interrupt-safe. Ray
From: Raymond Toy on 30 Mar 2010 22:53 On 3/30/10 5:17 PM, Lieven Marchand wrote: > Tim Bradshaw <tfb(a)tfeb.org> writes: > >> On 2010-03-30 21:00:01 +0100, Peter Keller said: >> >>> I would think this code is suspect since you don't take into consideration >>> numerical analysis techniques for comparing floating point numbers. >> >> I don't think so. I think it should only fail if the same operations >> on bitwise-identical doubles can sometimes produce different answers >> (where the operations are multiplication and addition). > > They still can. Doubles in the FPU registers are 80 bits but are > typically stored back to memory as 64 bits. So a computation can have > different results depending on how many of the registers are already in > use or when and how the compiler decides to store them back. But he is using the sse2 version of cmucl (as indicated by the :SSE2 *features*). The 80 bit registers are not used. Ray
From: Norbert_Paul on 31 Mar 2010 01:51
Tim Bradshaw wrote: > On 2010-03-30 22:17:35 +0100, Lieven Marchand said: > >> They still can. Doubles in the FPU registers are 80 bits but are >> typically stored back to memory as 64 bits. So a computation can have >> different results depending on how many of the registers are already in >> use or when and how the compiler decides to store them back. > > This has to be wrong, doesn't it? Of course it has to be. A (standard) computer *has* to be deterministic. |