You can subscribe to this list here.
2000 
_{Jan}
(81) 
_{Feb}
(55) 
_{Mar}
(459) 
_{Apr}
(159) 
_{May}
(126) 
_{Jun}
(69) 
_{Jul}
(48) 
_{Aug}
(29) 
_{Sep}
(106) 
_{Oct}
(76) 
_{Nov}
(155) 
_{Dec}
(161) 

2001 
_{Jan}
(122) 
_{Feb}
(150) 
_{Mar}
(294) 
_{Apr}
(124) 
_{May}
(197) 
_{Jun}
(266) 
_{Jul}
(111) 
_{Aug}
(259) 
_{Sep}
(163) 
_{Oct}
(142) 
_{Nov}
(101) 
_{Dec}
(86) 
2002 
_{Jan}
(187) 
_{Feb}
(108) 
_{Mar}
(274) 
_{Apr}
(157) 
_{May}
(346) 
_{Jun}
(242) 
_{Jul}
(345) 
_{Aug}
(187) 
_{Sep}
(263) 
_{Oct}
(69) 
_{Nov}
(30) 
_{Dec}
(76) 
2003 
_{Jan}
(125) 
_{Feb}
(191) 
_{Mar}
(87) 
_{Apr}
(69) 
_{May}
(107) 
_{Jun}
(66) 
_{Jul}
(112) 
_{Aug}
(161) 
_{Sep}
(184) 
_{Oct}
(137) 
_{Nov}
(28) 
_{Dec}
(61) 
2004 
_{Jan}
(148) 
_{Feb}
(99) 
_{Mar}
(365) 
_{Apr}
(225) 
_{May}
(311) 
_{Jun}
(204) 
_{Jul}
(95) 
_{Aug}
(214) 
_{Sep}
(256) 
_{Oct}
(290) 
_{Nov}
(239) 
_{Dec}
(152) 
2005 
_{Jan}
(253) 
_{Feb}
(183) 
_{Mar}
(178) 
_{Apr}
(88) 
_{May}
(175) 
_{Jun}
(195) 
_{Jul}
(122) 
_{Aug}
(81) 
_{Sep}
(119) 
_{Oct}
(200) 
_{Nov}
(110) 
_{Dec}
(179) 
2006 
_{Jan}
(154) 
_{Feb}
(64) 
_{Mar}
(55) 
_{Apr}
(69) 
_{May}
(66) 
_{Jun}
(64) 
_{Jul}
(80) 
_{Aug}
(59) 
_{Sep}
(62) 
_{Oct}
(90) 
_{Nov}
(132) 
_{Dec}
(106) 
2007 
_{Jan}
(58) 
_{Feb}
(51) 
_{Mar}
(59) 
_{Apr}
(19) 
_{May}
(33) 
_{Jun}
(52) 
_{Jul}
(15) 
_{Aug}
(50) 
_{Sep}
(41) 
_{Oct}
(259) 
_{Nov}
(323) 
_{Dec}
(136) 
2008 
_{Jan}
(205) 
_{Feb}
(128) 
_{Mar}
(203) 
_{Apr}
(126) 
_{May}
(307) 
_{Jun}
(166) 
_{Jul}
(259) 
_{Aug}
(181) 
_{Sep}
(217) 
_{Oct}
(265) 
_{Nov}
(256) 
_{Dec}
(132) 
2009 
_{Jan}
(104) 
_{Feb}
(81) 
_{Mar}
(27) 
_{Apr}
(21) 
_{May}
(85) 
_{Jun}
(237) 
_{Jul}
(243) 
_{Aug}
(199) 
_{Sep}
(178) 
_{Oct}
(151) 
_{Nov}
(64) 
_{Dec}
(39) 
2010 
_{Jan}
(33) 
_{Feb}
(146) 
_{Mar}
(125) 
_{Apr}
(109) 
_{May}
(52) 
_{Jun}
(135) 
_{Jul}
(103) 
_{Aug}
(68) 
_{Sep}
(99) 
_{Oct}
(88) 
_{Nov}
(45) 
_{Dec}
(56) 
2011 
_{Jan}
(19) 
_{Feb}
(32) 
_{Mar}
(50) 
_{Apr}
(105) 
_{May}
(46) 
_{Jun}
(22) 
_{Jul}
(101) 
_{Aug}
(80) 
_{Sep}
(52) 
_{Oct}
(16) 
_{Nov}
(10) 
_{Dec}
(29) 
2012 
_{Jan}
(8) 
_{Feb}
(22) 
_{Mar}
(17) 
_{Apr}
(68) 
_{May}
(19) 
_{Jun}
(19) 
_{Jul}
(12) 
_{Aug}
(6) 
_{Sep}
(13) 
_{Oct}
(5) 
_{Nov}
(5) 
_{Dec}
(5) 
2013 
_{Jan}
(6) 
_{Feb}
(4) 
_{Mar}
(3) 
_{Apr}
(5) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(6) 
_{Dec}

2014 
_{Jan}

_{Feb}

_{Mar}
(16) 
_{Apr}
(1) 
_{May}
(8) 
_{Jun}

_{Jul}
(1) 
_{Aug}
(1) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

2015 
_{Jan}

_{Feb}
(8) 
_{Mar}
(23) 
_{Apr}
(5) 
_{May}

_{Jun}

_{Jul}

_{Aug}
(7) 
_{Sep}
(1) 
_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 


1

2
(4) 
3
(1) 
4

5

6

7

8
(6) 
9
(15) 
10
(1) 
11
(16) 
12
(14) 
13
(3) 
14

15
(11) 
16
(3) 
17
(9) 
18
(1) 
19
(2) 
20

21

22
(7) 
23
(2) 
24
(2) 
25
(14) 
26
(6) 
27
(1) 
28

29
(2) 
30
(6) 
31




From: Bruno Haible <haible@il...>  20000502 18:47:59

Raymond Toy writes: > Bruno> Computing 1+doublefloatepsilon gives 1+2^(53)+2^(105), > Bruno> which takes more than 52 bits to represent. With default > Bruno> IEEE rounding, this rounds to 1+2^(52). > > So, does this mean that IEEE requires 2*53 bits to store the result so > it can properly round the result? Or do they peek at the operands > first to see how to round the result? Either way, that seems like a > lot of hardware. I assumed relatively simple HW with only a few extra > bits stored. 3 extra bits suffice. Think about it: roundtoeven means that all "extra" bits from the second one on must be zero. Otherwise the rounding direction is given by the first extra bit. Thus you can OR all these bits together into one. > I note that with CMUCL (sparc), CLISP, and LWW, 1+doublefloatepsilon IS > different from 1. With CMUCL on x86, this isn't true. On FreeBSD or Linux? I remember that at some time, the default FPU mode, set in a process' startup code, was different in FreeBSD and Linux. Bruno 
From: Raymond Toy <toy@rt...>  20000502 18:29:29

>>>>> "Bruno" == Bruno Haible <haible@...> writes: Bruno> Raymond Toy writes: >> >> On my 20000306 (March 2000) Solaris build of clisp, >> doublefloatepsilon is 2^(53) and singlefloatepsilon is 2^(24). Bruno> The values are slightly larger than you think: My mistake. I just took the log to see. >> A IEEE double has a mantissa of the form 1.xxx...xxx, with 52 >> x's so the LSB is 2^(52). Computing 1+doublefloatepsilon gives >> 1+2^(53), which takes more than 52 bits to represent. With default >> IEEE rounding, we should round to nearest (even), which is 1, not >> 1+2^(52). Bruno> Computing 1+doublefloatepsilon gives 1+2^(53)+2^(105), Bruno> which takes more than 52 bits to represent. With default Bruno> IEEE rounding, this rounds to 1+2^(52). So, does this mean that IEEE requires 2*53 bits to store the result so it can properly round the result? Or do they peek at the operands first to see how to round the result? Either way, that seems like a lot of hardware. I assumed relatively simple HW with only a few extra bits stored. I note that with CMUCL (sparc), CLISP, and LWW, 1+doublefloatepsilon IS different from 1. With CMUCL on x86, this isn't true. I'm thoroughly confused now. :) Ray 
From: Bruno Haible <haible@il...>  20000502 18:15:58

Raymond Toy writes: > > On my 20000306 (March 2000) Solaris build of clisp, > doublefloatepsilon is 2^(53) and singlefloatepsilon is 2^(24). The values are slightly larger than you think: [1]> doublefloatepsilon 1.1102230246251568d16 [2]> singlefloatepsilon 5.960465E8 [3]> (fmakunbound 'sys::writefloatdecimal) SYSTEM::WRITEFLOATDECIMAL [4]> doublefloatepsilon .10000000000000000000000000000000000000000000000000001d52 [5]> singlefloatepsilon .100000000000000000000001f23 > A IEEE double has a mantissa of the form 1.xxx...xxx, with 52 > x's so the LSB is 2^(52). Computing 1+doublefloatepsilon gives > 1+2^(53), which takes more than 52 bits to represent. With default > IEEE rounding, we should round to nearest (even), which is 1, not > 1+2^(52). Computing 1+doublefloatepsilon gives 1+2^(53)+2^(105), which takes more than 52 bits to represent. With default IEEE rounding, this rounds to 1+2^(52). Bruno 
From: Raymond Toy <toy@rt...>  20000502 17:51:48

On my 20000306 (March 2000) Solaris build of clisp, doublefloatepsilon is 2^(53) and singlefloatepsilon is 2^(24). I think these are wrong. They should be 2^(52) and 2^(23), respectively. Why? A IEEE double has a mantissa of the form 1.xxx...xxx, with 52 x's so the LSB is 2^(52). Computing 1+doublefloatepsilon gives 1+2^(53), which takes more than 52 bits to represent. With default IEEE rounding, we should round to nearest (even), which is 1, not 1+2^(52). To get the correctly rounded value, we need to add 2^(52), and hence, this should be the value of doublefloatepsilon. Is there a flaw in my reasoning here? Ray 