You can subscribe to this list here.
2000 
_{Jan}
(16) 
_{Feb}
(21) 
_{Mar}
(49) 
_{Apr}
(35) 
_{May}
(25) 
_{Jun}
(15) 
_{Jul}
(17) 
_{Aug}
(15) 
_{Sep}
(12) 
_{Oct}
(18) 
_{Nov}
(42) 
_{Dec}
(31) 

2001 
_{Jan}
(35) 
_{Feb}
(24) 
_{Mar}
(53) 
_{Apr}
(59) 
_{May}
(124) 
_{Jun}
(134) 
_{Jul}
(92) 
_{Aug}
(74) 
_{Sep}
(75) 
_{Oct}
(95) 
_{Nov}
(47) 
_{Dec}
(32) 
2002 
_{Jan}
(191) 
_{Feb}
(143) 
_{Mar}
(279) 
_{Apr}
(287) 
_{May}
(106) 
_{Jun}
(96) 
_{Jul}
(95) 
_{Aug}
(126) 
_{Sep}
(184) 
_{Oct}
(152) 
_{Nov}
(84) 
_{Dec}
(136) 
2003 
_{Jan}
(170) 
_{Feb}
(64) 
_{Mar}
(202) 
_{Apr}
(142) 
_{May}
(103) 
_{Jun}
(145) 
_{Jul}
(56) 
_{Aug}
(204) 
_{Sep}
(130) 
_{Oct}
(91) 
_{Nov}
(32) 
_{Dec}
(130) 
2004 
_{Jan}
(89) 
_{Feb}
(208) 
_{Mar}
(190) 
_{Apr}
(61) 
_{May}
(111) 
_{Jun}
(126) 
_{Jul}
(121) 
_{Aug}
(90) 
_{Sep}
(65) 
_{Oct}
(80) 
_{Nov}
(90) 
_{Dec}
(95) 
2005 
_{Jan}
(63) 
_{Feb}
(106) 
_{Mar}
(105) 
_{Apr}
(90) 
_{May}
(99) 
_{Jun}
(96) 
_{Jul}
(197) 
_{Aug}
(144) 
_{Sep}
(128) 
_{Oct}
(123) 
_{Nov}
(232) 
_{Dec}
(153) 
2006 
_{Jan}
(210) 
_{Feb}
(69) 
_{Mar}
(37) 
_{Apr}
(74) 
_{May}
(123) 
_{Jun}
(51) 
_{Jul}
(91) 
_{Aug}
(25) 
_{Sep}
(98) 
_{Oct}
(98) 
_{Nov}
(87) 
_{Dec}
(33) 
2007 
_{Jan}
(43) 
_{Feb}
(41) 
_{Mar}
(27) 
_{Apr}
(18) 
_{May}
(20) 
_{Jun}
(18) 
_{Jul}
(35) 
_{Aug}
(35) 
_{Sep}
(21) 
_{Oct}
(75) 
_{Nov}
(41) 
_{Dec}
(28) 
2008 
_{Jan}
(34) 
_{Feb}
(28) 
_{Mar}
(33) 
_{Apr}
(26) 
_{May}
(45) 
_{Jun}
(35) 
_{Jul}
(36) 
_{Aug}
(32) 
_{Sep}
(87) 
_{Oct}
(70) 
_{Nov}
(98) 
_{Dec}
(96) 
2009 
_{Jan}
(94) 
_{Feb}
(79) 
_{Mar}
(9) 
_{Apr}
(10) 
_{May}
(5) 
_{Jun}
(54) 
_{Jul}
(49) 
_{Aug}
(65) 
_{Sep}
(61) 
_{Oct}
(16) 
_{Nov}
(61) 
_{Dec}
(70) 
2010 
_{Jan}
(2) 
_{Feb}
(67) 
_{Mar}
(8) 
_{Apr}
(30) 
_{May}
(19) 
_{Jun}
(2) 
_{Jul}
(17) 
_{Aug}
(30) 
_{Sep}
(23) 
_{Oct}
(20) 
_{Nov}
(47) 
_{Dec}
(12) 
2011 
_{Jan}
(44) 
_{Feb}
(46) 
_{Mar}
(20) 
_{Apr}
(74) 
_{May}
(35) 
_{Jun}
(37) 
_{Jul}
(5) 
_{Aug}
(14) 
_{Sep}

_{Oct}
(8) 
_{Nov}
(6) 
_{Dec}
(1) 
2012 
_{Jan}
(18) 
_{Feb}
(12) 
_{Mar}
(22) 
_{Apr}
(6) 
_{May}
(16) 
_{Jun}
(17) 
_{Jul}
(10) 
_{Aug}
(13) 
_{Sep}
(2) 
_{Oct}
(8) 
_{Nov}
(10) 
_{Dec}
(1) 
2013 
_{Jan}
(19) 
_{Feb}
(14) 
_{Mar}
(12) 
_{Apr}
(3) 
_{May}
(33) 
_{Jun}
(12) 
_{Jul}
(20) 
_{Aug}
(5) 
_{Sep}
(5) 
_{Oct}
(17) 
_{Nov}
(15) 
_{Dec}
(4) 
2014 
_{Jan}
(8) 
_{Feb}
(4) 
_{Mar}
(17) 
_{Apr}

_{May}
(16) 
_{Jun}
(10) 
_{Jul}
(7) 
_{Aug}

_{Sep}
(1) 
_{Oct}
(17) 
_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1
(3) 
2

3
(2) 
4
(3) 
5
(7) 
6
(15) 
7
(9) 
8
(14) 
9
(2) 
10
(2) 
11
(6) 
12
(16) 
13
(3) 
14
(9) 
15
(2) 
16
(3) 
17
(2) 
18
(4) 
19
(4) 
20
(1) 
21
(9) 
22
(14) 
23
(7) 
24
(4) 
25
(11) 
26
(23) 
27
(6) 
28
(4) 
29
(5) 
30
(3) 
31
(4) 






From: Bruce Nagel <nagelbh@sd...>  20050724 20:40:38

I seem to be having problems with readline (no command history or completion) after compiling 2.34 from source. The Clisp Debian package however still works fine. Running Debian Testing: Linux Bast 2.4.18bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i686 GNU/Linux Any ideas? Bruce  nagelbh@... http://www.notart.org SDF Public Access UNIX System  http://sdf.lonestar.org The Mouser felt a compulsive urge to take out his dagger and stab himself in the heart. A man had to die when he saw something like that. (Fritz Leiber) 
From: Devon Sean McCullough <LispHacker@Jovi.Net>  20050724 16:53:41

From: michal kabata <michal@...> Date: Sun, 24 Jul 2005 10:02:00 +0200 ... clisp is _making an error_ ... For the record, it is no error. Lisp offers access to the bare floating point hardware and CLISP keeps that promise. Peace Devon PS: Rationals are there, the choice is yours. PPS: Yes, I repeat up front what PJB said in the middle of a long message. PPPS: I am curious, does anyone have a numeric "measurement" datatype which preserves error information, e.g., value with accuracy, increasing and decreasing precision as needed? I've been expecting it in calculators since the HP35 but these days I calculate rarely. PPPPS: More elaborately, one might represent a measurement as a Gaussian whose shape would likely become quite nightmarish after only a few computations but we have the cycles! Perhaps such a proposal is best documented on the first of April? 
From: Pascal Bourguignon <pjb@in...>  20050724 09:13:33

michal kabata writes: > Pascal Bourguignon wrote: > > michal kabata writes: > > > >>I keep wondering why I never saw it before... > > > > > > Perhaps because you're not a "Computer Scientist"? ;) This is a smiley>^^^ > Guess again. Anyway, I ment lisp, and possibly correct guess should be > that I have too little experience with lisp and too high opinion about > those who write it. > > > I should have mentionned: > > "What Every Computer Scientist Should Know About FloatingPoint Arithmetic" > > http://docs.sun.com/source/8063568/ncg_goldberg.html > > too. > > > Oh please... > > Anyway, I ment to end this discussion and I hope this is the last try. > Thanks for all workaround ideas. I wrote the first email with silly > hope that you just might be interested in a fact that clisp is _making > an error_ (like most other langs, ok  but is that excause?). I guess > OpenSource on one side and pride on the other. I can understand your way > of thinking, someone who reports such trivial bug must be an idiot who > you can insult all the way. I would be very happy to report any more > serious bugs inf future, but so happened that I encounter this one, and > in my opinion _in lisp_ this is a bug. Remember all those fantastic > words in most books about lisp that "lisp is always doing the right > thing with numbers"? Well it does not in this case. > > BTW: >  mathematically 1.10.9 is not greater or less then 0.2, just equal, so > don't say that such computation is correct mathematically. And if > something is behaving not like mathematical number then how could it be > mathematically correct? You don't understand what I mean because you don't take into account the notation. In maths, when you write 1.1 you may mean one of two things. Either the element of Q=Z/Z*, or the element of R. Happily, there are isomorphisms betweeb Z/Z* and a subset of R, in which happily 1.1 belong, and therefore people often forget which one they refer to when they write 1.1. Now, in IEEE754 arithmetic, there is no 1.1 number. This is the reason why ( 1.1 0.9) doesn't give the result you want. This is due to the fact that the set of numbers in floating points data types are generated from base two, and you've noted a number in base ten. (Keep in mind when reading the following sums that only the left hand side of ~= is exact mathematics. What's on the right hand side is an aproximation in base ten. The last value of the right hand side is computed from the rational on the left hand side, not as the sum of the above numbers for these above numbers are truncated by the lack of precision of doublefloat!) [48]> (computebinfloat "1.00011001100110011001101") 1.00011001100110011001101 = 1 + 0 * 2^ 1 = 0 ~= 0.00000000000000000 + 0 * 2^ 2 = 0 ~= 0.00000000000000000 + 0 * 2^ 3 = 0 ~= 0.00000000000000000 + 1 * 2^ 4 = 1/16 ~= 0.06250000000000000 + 1 * 2^ 5 = 1/32 ~= 0.03125000000000000 + 0 * 2^ 6 = 0 ~= 0.00000000000000000 + 0 * 2^ 7 = 0 ~= 0.00000000000000000 + 1 * 2^ 8 = 1/256 ~= 0.00390625000000000 + 1 * 2^ 9 = 1/512 ~= 0.00195312500000000 + 0 * 2^10 = 0 ~= 0.00000000000000000 + 0 * 2^11 = 0 ~= 0.00000000000000000 + 1 * 2^12 = 1/4096 ~= 0.00024414062500000 + 1 * 2^13 = 1/8192 ~= 0.00012207031250000 + 0 * 2^14 = 0 ~= 0.00000000000000000 + 0 * 2^15 = 0 ~= 0.00000000000000000 + 1 * 2^16 = 1/65536 ~= 0.00001525878906250 + 1 * 2^17 = 1/131072 ~= 0.00000762939453125 + 0 * 2^18 = 0 ~= 0.00000000000000000 + 0 * 2^19 = 0 ~= 0.00000000000000000 + 1 * 2^20 = 1/1048576 ~= 0.00000095367431641 + 1 * 2^21 = 1/2097152 ~= 0.00000047683715820 + 0 * 2^22 = 0 ~= 0.00000000000000000 + 1 * 2^23 = 1/8388608 ~= 0.00000011920928955 = 9227469/8388608 ~= 1.10000002384185800 9227469/8388608 [49]> (computebinfloat "1.00011001100110011001100") 1.00011001100110011001100 = 1 + 0 * 2^ 1 = 0 ~= 0.00000000000000000 + 0 * 2^ 2 = 0 ~= 0.00000000000000000 + 0 * 2^ 3 = 0 ~= 0.00000000000000000 + 1 * 2^ 4 = 1/16 ~= 0.06250000000000000 + 1 * 2^ 5 = 1/32 ~= 0.03125000000000000 + 0 * 2^ 6 = 0 ~= 0.00000000000000000 + 0 * 2^ 7 = 0 ~= 0.00000000000000000 + 1 * 2^ 8 = 1/256 ~= 0.00390625000000000 + 1 * 2^ 9 = 1/512 ~= 0.00195312500000000 + 0 * 2^10 = 0 ~= 0.00000000000000000 + 0 * 2^11 = 0 ~= 0.00000000000000000 + 1 * 2^12 = 1/4096 ~= 0.00024414062500000 + 1 * 2^13 = 1/8192 ~= 0.00012207031250000 + 0 * 2^14 = 0 ~= 0.00000000000000000 + 0 * 2^15 = 0 ~= 0.00000000000000000 + 1 * 2^16 = 1/65536 ~= 0.00001525878906250 + 1 * 2^17 = 1/131072 ~= 0.00000762939453125 + 0 * 2^18 = 0 ~= 0.00000000000000000 + 0 * 2^19 = 0 ~= 0.00000000000000000 + 1 * 2^20 = 1/1048576 ~= 0.00000095367431641 + 1 * 2^21 = 1/2097152 ~= 0.00000047683715820 + 0 * 2^22 = 0 ~= 0.00000000000000000 + 0 * 2^23 = 0 ~= 0.00000000000000000 = 2306867/2097152 ~= 1.09999990463256840 2306867/2097152 [50]> (computebinfloat "0.11100110011001100110011") 0.11100110011001100110011 = 0 + 1 * 2^ 1 = 1/2 ~= 0.50000000000000000 + 1 * 2^ 2 = 1/4 ~= 0.25000000000000000 + 1 * 2^ 3 = 1/8 ~= 0.12500000000000000 + 0 * 2^ 4 = 0 ~= 0.00000000000000000 + 0 * 2^ 5 = 0 ~= 0.00000000000000000 + 1 * 2^ 6 = 1/64 ~= 0.01562500000000000 + 1 * 2^ 7 = 1/128 ~= 0.00781250000000000 + 0 * 2^ 8 = 0 ~= 0.00000000000000000 + 0 * 2^ 9 = 0 ~= 0.00000000000000000 + 1 * 2^10 = 1/1024 ~= 0.00097656250000000 + 1 * 2^11 = 1/2048 ~= 0.00048828125000000 + 0 * 2^12 = 0 ~= 0.00000000000000000 + 0 * 2^13 = 0 ~= 0.00000000000000000 + 1 * 2^14 = 1/16384 ~= 0.00006103515625000 + 1 * 2^15 = 1/32768 ~= 0.00003051757812500 + 0 * 2^16 = 0 ~= 0.00000000000000000 + 0 * 2^17 = 0 ~= 0.00000000000000000 + 1 * 2^18 = 1/262144 ~= 0.00000381469726562 + 1 * 2^19 = 1/524288 ~= 0.00000190734863281 + 0 * 2^20 = 0 ~= 0.00000000000000000 + 0 * 2^21 = 0 ~= 0.00000000000000000 + 1 * 2^22 = 1/4194304 ~= 0.00000023841857910 + 1 * 2^23 = 1/8388608 ~= 0.00000011920928955 = 7549747/8388608 ~= 0.89999997615814210 7549747/8388608 [51]> (computebinfloat "0.11100110011001100110100") 0.11100110011001100110100 = 0 + 1 * 2^ 1 = 1/2 ~= 0.50000000000000000 + 1 * 2^ 2 = 1/4 ~= 0.25000000000000000 + 1 * 2^ 3 = 1/8 ~= 0.12500000000000000 + 0 * 2^ 4 = 0 ~= 0.00000000000000000 + 0 * 2^ 5 = 0 ~= 0.00000000000000000 + 1 * 2^ 6 = 1/64 ~= 0.01562500000000000 + 1 * 2^ 7 = 1/128 ~= 0.00781250000000000 + 0 * 2^ 8 = 0 ~= 0.00000000000000000 + 0 * 2^ 9 = 0 ~= 0.00000000000000000 + 1 * 2^10 = 1/1024 ~= 0.00097656250000000 + 1 * 2^11 = 1/2048 ~= 0.00048828125000000 + 0 * 2^12 = 0 ~= 0.00000000000000000 + 0 * 2^13 = 0 ~= 0.00000000000000000 + 1 * 2^14 = 1/16384 ~= 0.00006103515625000 + 1 * 2^15 = 1/32768 ~= 0.00003051757812500 + 0 * 2^16 = 0 ~= 0.00000000000000000 + 0 * 2^17 = 0 ~= 0.00000000000000000 + 1 * 2^18 = 1/262144 ~= 0.00000381469726562 + 1 * 2^19 = 1/524288 ~= 0.00000190734863281 + 0 * 2^20 = 0 ~= 0.00000000000000000 + 1 * 2^21 = 1/2097152 ~= 0.00000047683715820 + 0 * 2^22 = 0 ~= 0.00000000000000000 + 0 * 2^23 = 0 ~= 0.00000000000000000 = 1887437/2097152 ~= 0.90000009536743160 1887437/2097152 0.89999997615814210 So why don't you ask: [52]> ( 1.10000002384185800L0 0.89999997615814210L0) 0.20000004768371590006L0 [53]> ( 1.09999990463256840L0 0.90000009536743160L0) 0.19999980926513680001L0 instead of ( 1.1 0.9) ? I hear you say that what you want is 1.1, but the problem is that there's no way of representing 1.1 with IEEE754 floating point numbers! The closer you can come are one of these two numbers I represent in base ten: 1.10000002384185800L0 or 1.09999990463256840L0. Since 1.10000002384185800L0 is closer, you should not be surprized that the convertion routine choose this number to represent 1.1L0. And since 0.89999997615814210 is closer to 0.9L0, it's the one choosen. Therefore you get the exact result 0.20000004768371590006L0 (or 0.20000005 when working with signle floats). >  base is very very related to "calculation of the exponent", thats why > I wrote about calculation, not the exponent >  if you are teached in physics not to do it, then why clisp does it? clisp does it because it's what is specified by Common Lisp. Common Lisp does it because the people who designed it constated that implementors did all implement the notation 1.1 to mean the floating point number whose value is closest to the mathematical real 1.1. Implementors all did this because their customers all asked for it. People with serrious budget to do serrious work with computer workstations that costed at the time around $200,000.00 or more. And the reason why computers don't compute as we do, is that it's not efficient to do it as we do. If you need it, you can implement the arithmetic algorithms we use in a computer. But you'll run thousands or millions times slower than a IEEE floating point unit. It may not matter for you, but for these serrious people who did nuclear explosion simulations or who programmed misile autopilot CPU, it was important to get the results fast. > for basics operations (,+,*) I can't see the need to keep garbage after > the digits you expect in result > > So again, for me this is EOT. Since I'm begining to get more insults > that meritoric answers and I don't see anyone interested in fixing this. Feel less insulted and try to learn more. (defmacro wsiosbp (&body body) (let ((vpack (gensym))) `(let ((,vpack *package*)) (withstandardiosyntax (let ((*package* ,vpack)) ,@body))))) (defmacro genieeeencoding (name type exponentbits mantissabits) ;; Thanks to ivan4th (~ivan_iv@...) for correcting an offby1 (wsiosbp `(progn (defun ,(intern (format nil "~ATOIEEE754" name)) (float) (multiplevaluebind (mantissa exponent sign) (integerdecodefloat float) (dpb (if (minusp sign) 1 0) (byte 1 ,(1 (+ exponentbits mantissabits))) (dpb (+ ,(+ ( (expt 2 (1 exponentbits)) 2) mantissabits) exponent) (byte ,exponentbits ,(1 mantissabits)) (ldb (byte ,(1 mantissabits) 0) mantissa))))) (defun ,(intern (format nil "IEEE754TO~A" name)) (ieee) (let ((aval (scalefloat (coerce (dpb 1 (byte 1 ,(1 mantissabits)) (ldb (byte ,(1 mantissabits) 0) ieee)) ,type) ( (ldb (byte ,exponentbits ,(1 mantissabits)) ieee) ,(1 (expt 2 (1 exponentbits))) ,(1 mantissabits))))) (if (zerop (ldb (byte 1 ,(1 (+ exponentbits mantissabits))) ieee)) aval ( aval))))))) (genieeeencoding float32 'singlefloat 8 24) (genieeeencoding float64 'doublefloat 11 53) (defun testieeereaddouble () (withopenfile (in "value.ieee754double" :direction :input :elementtype '(unsignedbyte 8)) (loop while (< (fileposition in) (filelength in)) do (loop repeat 8 for i = 1 then (* i 256) for v = (readbyte in) then (+ v (* i (readbyte in))) finally (progn (let ((*printbase* 16)) (princ v)) (princ " ") (princ (IEEE754TOFLOAT64 v)) (terpri)))))) (defun testieeereadsingle () (withopenfile (in "value.ieee754single" :direction :input :elementtype '(unsignedbyte 8)) (loop while (< (fileposition in) (filelength in)) do (loop repeat 4 for i = 1 then (* i 256) for v = (readbyte in) then (+ v (* i (readbyte in))) finally (progn (let ((*printbase* 16)) (princ v)) (princ " ") (princ (IEEE754TOFLOAT32 v)) (terpri)))))) (defun testsingletoieee (&rest args) (dolist (arg args) (format t "~16,8R ~A~%" (float32toieee754 (coerce arg 'singlefloat)) arg))) (defun testdoubletoieee (&rest args) (dolist (arg args) (format t "~16,16R ~A~%" (float64toieee754 (coerce arg 'doublefloat)) arg))) (defun converttobinary (number significantdigits) (multiplevaluebind (int dec) (truncate number) (format nil "~2R.~{~:[0~;1~]~}" int (loop with digits = '() repeat significantdigits do (multiplevaluebind (digit rest) (truncate (* 2 dec)) (push (oddp digit) digits) (setf dec rest)) finally (return (nreverse digits)))))) (defun computebinfloat (value) "1.00011001100110011001101" (flet ((rattobin (n) (/ (coerce (NUMERATOR n) 'DOUBLEfloat) (coerce (DENOMINATOR n) 'DOUBLEfloat)))) (let ((dot (position (character ".") value))) (if dot (loop with integerpart = (parseinteger value :radix 2 :end dot :junkallowed nil) with decimalpart = 0 initially (format t "~A ~%= ~A~%" value integerpart) for exponent from 1 by 1 for digit across (subseq value (1+ dot)) for weight = (/ (digitcharp digit) (expt 2 ( exponent))) do (format t "+ ~1A * 2^~3D = ~30A ~~= ~24,17F~%" digit exponent weight (rattobin weight)) (incf decimalpart weight) finally (format t "= ~42A ~~= ~24,17F" (+ integerpart decimalpart) (rattobin (+ integerpart decimalpart))) (return (+ integerpart decimalpart))) (let ((integerpart (parseinteger value :radix 2 :junkallowed nil))) (format t "~A is a binary integer worth ~A" value integerpart) integerpart))))) (converttobinary 9/10) (computebinfloat "1.00011001100110011001101")  __Pascal Bourguignon__ http://www.informatimago.com/ You never feed me. Perhaps I'll sleep on your face. That will sure show you. 
From: michal kabata <michal@sf...>  20050724 08:04:05

Pascal Bourguignon wrote: > michal kabata writes: > >>I keep wondering why I never saw it before... > > > Perhaps because you're not a "Computer Scientist"? ;) > Guess again. Anyway, I ment lisp, and possibly correct guess should be that I have too little experience with lisp and too high opinion about those who write it. > I should have mentionned: > "What Every Computer Scientist Should Know About FloatingPoint Arithmetic" > http://docs.sun.com/source/8063568/ncg_goldberg.html > too. > Oh please... Anyway, I ment to end this discussion and I hope this is the last try. Thanks for all workaround ideas. I wrote the first email with silly hope that you just might be interested in a fact that clisp is _making an error_ (like most other langs, ok  but is that excause?). I guess OpenSource on one side and pride on the other. I can understand your way of thinking, someone who reports such trivial bug must be an idiot who you can insult all the way. I would be very happy to report any more serious bugs inf future, but so happened that I encounter this one, and in my opinion _in lisp_ this is a bug. Remember all those fantastic words in most books about lisp that "lisp is always doing the right thing with numbers"? Well it does not in this case. BTW:  mathematically 1.10.9 is not greater or less then 0.2, just equal, so don't say that such computation is correct mathematically. And if something is behaving not like mathematical number then how could it be mathematically correct?  base is very very related to "calculation of the exponent", thats why I wrote about calculation, not the exponent  if you are teached in physics not to do it, then why clisp does it? for basics operations (,+,*) I can't see the need to keep garbage after the digits you expect in result So again, for me this is EOT. Since I'm begining to get more insults that meritoric answers and I don't see anyone interested in fixing this. Best regards, Mike 