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: Norbert_Paul on 30 Mar 2010 16:30 vanekl wrote: > no worries here, brothuh > > CL-USER> (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.")))) > > NIL > CL-USER> swank::*swank-wire-protocol-version* > "2010-03-29" > CL-USER> (swank-loader::slime-version-string) > "2010-03-29" > CL-USER> (lisp-implementation-version) > "1.0.36.38" > CL-USER> *features* > (:SB-BSD-SOCKETS-ADDRINFO :ASDF :SBCL-HOOKS-REQUIRE :ANSI-CL :COMMON-LISP > :SBCL > :SB-DOC :SB-TEST :SB-LDB :SB-PACKAGE-LOCKS :SB-UNICODE :SB-EVAL > :SB-SOURCE-LOCATIONS :IEEE-FLOATING-POINT :X86 :UNIX :ELF :LINUX :SB-THREAD > :LARGEFILE :GENCGC :STACK-GROWS-DOWNWARD-NOT-UPWARD > :C-STACK-IS-CONTROL-STACK > :COMPARE-AND-SWAP-VOPS :UNWIND-TO-FRAME-AND-CALL-VOP > :RAW-INSTANCE-INIT-VOPS > :STACK-ALLOCATABLE-CLOSURES :STACK-ALLOCATABLE-VECTORS > :STACK-ALLOCATABLE-LISTS :STACK-ALLOCATABLE-FIXED-OBJECTS :ALIEN-CALLBACKS > :CYCLE-COUNTER :INLINE-CONSTANTS :LINKAGE-TABLE :OS-PROVIDES-DLOPEN > :OS-PROVIDES-PUTWC :OS-PROVIDES-SUSECONDS-T) > CL-USER> (SB-SYS:GET-MACHINE-VERSION ) > "Intel(R) Pentium(R) 4 CPU 3.00GHz" > Such a new and shiny environment, you have! And I thought I got the bleeding cutting edge newest by using Debian testing. And all I got is: CL-USER> swank::*swank-wire-protocol-version* "2010-02-20" CL-USER> (swank-loader::slime-version-string) "2010-02-20" CL-USER> (lisp-implementation-version) "CVS 20a 20a-release + minimal debian patches (20A Unicode)" CL-USER> *features* (:ASDF :CLC-OS-DEBIAN :COMMON-LISP-CONTROLLER :GERDS-PCL :PCL-STRUCTURES :PORTABLE-COMMONLOOPS :PCL :CMU20 :CMU20A :PYTHON :CONSERVATIVE-FLOAT-TYPE :MODULAR-ARITH :CMUCL-20A-PATCH-000 :MP :X86 :SSE2 :LINKAGE-TABLE :RELATIVE-PACKAGE-NAMES :EXECUTABLE :ELF :LINUX :GLIBC2 :UNIX :RANDOM-MT19937 :GENCGC :UNICODE :COMPLEX-FP-VOPS :PENTIUM :I486 :HASH-NEW :DOUBLE-DOUBLE :HEAP-OVERFLOW-CHECK :STACK-CHECKING :COMMON :COMMON-LISP :ANSI-CL :IEEE-FLOATING-POINT :CMU) CL-USER> >> emacs-X11.exe --version > GNU Emacs 23.1.1 Yeah! Here we meet! Norbert
From: vanekl on 30 Mar 2010 16:36 Peter Keller wrote: > Norbert_Paul <norbertpauls_spambin(a)yahoo.com> wrote: >> (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 would think this code is suspect since you don't take into > consideration numerical analysis techniques for comparing floating > point numbers. > > I'd suppose the test should be: > > (when (> (abs (- dot1 dot2)) *tolerance*) > (format t "Not equal!~%")) > > and *tolerance* would be something like 10e-8 or so. > > -pete Numerical analysis techniques should not have to be considered when the two equations are identical and executed with identical environments. Computers are not always precise, but they are deterministic. You may have a point if the precision of the calculations were revised upwards/downwards by CL during the calculation, but the numbers are too small to require a change in math operators, and the change in precision should occur identically for both equations. Also, Pete, take into account that Norbert said that this problem does not exist when slime/swank is not an intermediary.
From: Peter Keller on 30 Mar 2010 16:35 Norbert_Paul <norbertpauls_spambin(a)yahoo.com> wrote: > Peter Keller wrote: >> I would think this code is suspect since you don't take into consideration >> numerical analysis techniques for comparing floating point numbers. > No. I know about these errors, but note that the expressions to compute > dot1 and dot2 are absolutely equal. Therefore they /must/ produce the same > results (with the same errors). > My initial version was dot1 = v1 . v2 and dot2 = v2 . v1, but later I > suspected this might introduce such floating-point errors. > Therefore I also tried the above. > Also in my test cases where the error occured for the first time the > differences between both values werde significant and not only by an error. > > These > > (0.0d0 12.230520293356577d0) > (37.202197698216956d0 51.02715433387322d0) > > are some outputs of > > (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)))) > (when (/= dot1 dot2) > (print `(,dot1 ,dot2))))) > > The error occurs extremely seldom. I had to run it several times > to get such output. Hrm. Maybe you should print out the lists too, and once you get the actual numerical inputs which produced the problem, you can test it out by hand to see what happens. -pete
From: Peter Keller on 30 Mar 2010 16:42 vanekl <vanek(a)acd.net> wrote: > equations are identical and executed with identical environments. Computers > are not always precise, but they are deterministic. You may have a point if > the precision of the calculations were revised upwards/downwards by CL > during the calculation, but the numbers are too small to require a change in > math operators, and the change in precision should occur identically for > both equations. > > Also, Pete, take into account that Norbert said that this problem does not > exist when slime/swank is not an intermediary. I agree with your statement. -pete
From: vanekl on 30 Mar 2010 17:01
Norbert_Paul wrote: > Such a new and shiny environment, you have! And I thought I got the > bleeding cutting edge newest by using Debian testing. I shoot up straight from the source, as you can probably tell. I hope you didn't get one of those AMD cpus that allow you to unlock one of the cores. Now might be a good time to run Memtest86+ and check cpu temps. |