You can subscribe to this list here.
2000 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}
(371) 
_{Oct}
(167) 
_{Nov}
(412) 
_{Dec}
(208) 

2001 
_{Jan}
(378) 
_{Feb}
(302) 
_{Mar}
(269) 
_{Apr}
(296) 
_{May}
(306) 
_{Jun}
(381) 
_{Jul}
(346) 
_{Aug}
(315) 
_{Sep}
(195) 
_{Oct}
(216) 
_{Nov}
(280) 
_{Dec}
(227) 
2002 
_{Jan}
(309) 
_{Feb}
(333) 
_{Mar}
(328) 
_{Apr}
(407) 
_{May}
(517) 
_{Jun}
(519) 
_{Jul}
(400) 
_{Aug}
(580) 
_{Sep}
(1273) 
_{Oct}
(984) 
_{Nov}
(683) 
_{Dec}
(538) 
2003 
_{Jan}
(578) 
_{Feb}
(454) 
_{Mar}
(312) 
_{Apr}
(366) 
_{May}
(505) 
_{Jun}
(431) 
_{Jul}
(415) 
_{Aug}
(374) 
_{Sep}
(470) 
_{Oct}
(578) 
_{Nov}
(372) 
_{Dec}
(309) 
2004 
_{Jan}
(308) 
_{Feb}
(247) 
_{Mar}
(372) 
_{Apr}
(413) 
_{May}
(333) 
_{Jun}
(323) 
_{Jul}
(269) 
_{Aug}
(239) 
_{Sep}
(469) 
_{Oct}
(383) 
_{Nov}
(400) 
_{Dec}
(332) 
2005 
_{Jan}
(411) 
_{Feb}
(363) 
_{Mar}
(346) 
_{Apr}
(316) 
_{May}
(275) 
_{Jun}
(248) 
_{Jul}
(396) 
_{Aug}
(396) 
_{Sep}
(279) 
_{Oct}
(340) 
_{Nov}
(319) 
_{Dec}
(218) 
2006 
_{Jan}
(317) 
_{Feb}
(263) 
_{Mar}
(304) 
_{Apr}
(296) 
_{May}
(209) 
_{Jun}
(349) 
_{Jul}
(246) 
_{Aug}
(198) 
_{Sep}
(174) 
_{Oct}
(138) 
_{Nov}
(201) 
_{Dec}
(270) 
2007 
_{Jan}
(223) 
_{Feb}
(182) 
_{Mar}
(350) 
_{Apr}
(350) 
_{May}
(259) 
_{Jun}
(221) 
_{Jul}
(299) 
_{Aug}
(465) 
_{Sep}
(356) 
_{Oct}
(265) 
_{Nov}
(417) 
_{Dec}
(225) 
2008 
_{Jan}
(421) 
_{Feb}
(327) 
_{Mar}
(219) 
_{Apr}
(389) 
_{May}
(375) 
_{Jun}
(262) 
_{Jul}
(215) 
_{Aug}
(289) 
_{Sep}
(257) 
_{Oct}
(383) 
_{Nov}
(237) 
_{Dec}
(209) 
2009 
_{Jan}
(232) 
_{Feb}
(327) 
_{Mar}
(306) 
_{Apr}
(251) 
_{May}
(146) 
_{Jun}
(247) 
_{Jul}
(302) 
_{Aug}
(252) 
_{Sep}
(263) 
_{Oct}
(376) 
_{Nov}
(270) 
_{Dec}
(244) 
2010 
_{Jan}
(225) 
_{Feb}
(184) 
_{Mar}
(300) 
_{Apr}
(290) 
_{May}
(275) 
_{Jun}
(535) 
_{Jul}
(192) 
_{Aug}
(237) 
_{Sep}
(304) 
_{Oct}
(142) 
_{Nov}
(384) 
_{Dec}
(186) 
2011 
_{Jan}
(305) 
_{Feb}
(337) 
_{Mar}
(331) 
_{Apr}
(318) 
_{May}
(306) 
_{Jun}
(299) 
_{Jul}
(205) 
_{Aug}
(271) 
_{Sep}
(232) 
_{Oct}
(179) 
_{Nov}
(252) 
_{Dec}
(216) 
2012 
_{Jan}
(195) 
_{Feb}
(268) 
_{Mar}
(142) 
_{Apr}
(226) 
_{May}
(203) 
_{Jun}
(132) 
_{Jul}
(211) 
_{Aug}
(429) 
_{Sep}
(289) 
_{Oct}
(291) 
_{Nov}
(182) 
_{Dec}
(188) 
2013 
_{Jan}
(205) 
_{Feb}
(259) 
_{Mar}
(224) 
_{Apr}
(125) 
_{May}
(295) 
_{Jun}
(181) 
_{Jul}
(209) 
_{Aug}
(167) 
_{Sep}
(330) 
_{Oct}
(212) 
_{Nov}
(95) 
_{Dec}
(114) 
2014 
_{Jan}
(40) 
_{Feb}
(63) 
_{Mar}
(62) 
_{Apr}
(65) 
_{May}
(82) 
_{Jun}
(105) 
_{Jul}
(56) 
_{Aug}
(175) 
_{Sep}
(79) 
_{Oct}
(49) 
_{Nov}
(51) 
_{Dec}
(47) 
2015 
_{Jan}
(26) 
_{Feb}
(69) 
_{Mar}
(74) 
_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

1
(3) 
2
(4) 
3
(9) 
4
(2) 
5
(2) 
6
(8) 
7

8
(4) 
9
(7) 
10
(8) 
11
(13) 
12
(13) 
13
(2) 
14
(6) 
15
(2) 
16
(3) 
17

18
(3) 
19
(5) 
20
(5) 
21

22

23
(2) 
24
(2) 
25

26

27
(2) 
28
(1) 
29
(4) 
30
(1) 
31
(3) 




From: Peter Rockett <p.rockett@sh...>  20131213 10:39:39

On 12/12/13 16:49, Keith Marshall wrote: > On 12/12/13 01:15, sisyphus1@... wrote: >> Interestingly, this one is similar to 95e20 in that it can correctly be >> represented in 54 bits, and the problem is in the rounding to 53 bits. >> I don't know if mingw is affected by any of these  they all seem to involve >> a mantissa of more that 15 significant decimal digits. (One wonders how they >> might be greeted if presented to *this* list.) > The 64bit IEEE 754 format provides: > > 1 sign bit; > 11 exponent bits; > 53 mantissa bits; (52 stored, 1 implied). > > The maximum number of significant decimal digits which that 53bit > mantissa can *reliably* represent is given by: > > 53 log10( 2 ) = 15.95 > > While this is close to 16, you cannot really claim a fraction of a > decimal digit, so only 15 are actually available; (what the fraction > means is that, over part of the range of representable values, there may > be 16 significant digits available, but over the entire range, you can > claim only 15). > > The example which you cite: > >> And then there's >> http://www.exploringbinary.com/incorrectlyroundedconversionsingccandglibc/ >> >> which contains this example: >> [quote] >> 0.500000000000000166533453693773481063544750213623046875, >> which equals 2^1 + 2^53 + 2^54, converts to this binary number: >> 0.100000000000000000000000000000000000000000000000000011 >> >> It has 54 significant bits, with bits 53 and 54 equal to 1. The correctly >> rounded value — in binary scientific notation — is >> 1.000000000000000000000000000000000000000000000000001 x 2^1 >> >> gcc and glibc strtod() both compute the converted value as >> 1.0000000000000000000000000000000000000000000000000001 x 2^1 >> which is one ULP below the correctly rounded value. >> [end quote] > offers a sample number with 54 significant decimal digits; this requires > a minimum of: > > 54 / log10( 2 ) = 179.38 binary digits > > (which we *must* round away from zero, to 180 bits), to represent it > exactly. To claim that it can be represented in fewer, (e.g. the 54 > suggested), is mathematically bogus; such a claim relies on a grossly > unsafe assumption  that you know precisely what the state of the 126 > unrepresented bits must be. Obviously, this is sheer balderdash. > > Clearly, on input you may continue to generate mantissa bits beyond the > 53 which you can fit in the IEEE 754 64bit representation, and then > round to 53. If you generate only 54, (as your example suggests), then > if the 54th bit is a zero, rounding entails simply discarding it. OTOH, > if it is a one, (again as in your example), you may round either away > from zero, or toward zero, and either could be regarded as round to > nearest, as both are equally near, (if you actually believe the accuracy > of you data to this extreme precision, in the first place). To break > such a tie, mathematicians normally advocate rounding away from zero, > (which is reasonable, since there is likely to be another one bit > somewhere in the following unrepresented bits, which would tend to bias > the rounding toward the next representable value away from zero. > However, there are some, (such as Donald Knuth), who advocate rounding > the tie to the nearest *even* representable value, on the grounds that, > statistically, around 50% of values will round toward zero, while the > remaining 50% round away from zero, and the resulting rounding errors > will tend to cancel, in calculations. FWIW: Section 4.3.3 of IEEE754 mandates the use of rounding ties to even for binary representations as the default. (Sadly, I have copy of this august document!) > Depending on which of these rounding rules a particular implementation > adopts, (round to nearest, with ties away from zero, or round to nearest > even value), you may see differences in the least significant bit; to > say that one method is definitively wrong, and the other correct, is > something of a stretch. Alternatively, it may be that the OP is somehow accessing two different implementations of strtod in his tests. Depending on exactly how they are written may determine how/where the rounding errors build up. I recall a number of years ago, a colleague trying to calculate the singular value decomposition (SVD) of some truculent matrices. (SVD is a complicated algorithm, for those who don't know it!) Only one SVD implementation, written by G. W. (Pete) Stewart [http://www.cs.umd.edu/~stewart/] gave consistently sensible results. My explanation is that, because he is a master of computational linear algebra, Stewart's implementation kept the rounding errors as good as they could be, whereas other implementers with a lesser grasp failed to do this . So we might be taking about seemingly minor differences in what/how intermediate results are calculated in the strtod implementations. > The reality is that you are arguing about a > miniscule difference in an arena where approximations prevail, and for > most uses, both approximations are equally good. So true! If you do any serious floatingpoint calculations and endup with errors in the 1 ulp range you should be punching the air with hysterical delight! P. ...snip 
From: George Koehler <xkernigh@ne...>  20131213 05:07:19

Months ago, I had a similar problem. First, emails to mingwusers arrived in my Spam folder. Second, these emails stopped arriving. So I went to edit my options [1]. I learned that mailman disabled my mail delivery because too many mails bounced. [1] https://lists.sourceforge.net/lists/listinfo/mingwusers Here is how I corrected this: 1. Told mailman to enable delivery again. 2. Waited for more mail to mingwusers. They came in my Spam folder. 3. Moved them out of my Spam folder. This marked them as not spam. 4. Checked my options frequently. Had to enable delivery a few more times. 5. Continued to move mails out of my Spam folder. In recent months, mailman no longer disables my delivery, and fewer mails arrive in my Spam folder. Just today, I had to move more than 20 mails out of my Spam folder. My current bounce score is 1.0 out of 5.0, so I might have missed one. George Koehler 