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

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}
(55) 
_{Oct}
(59) 
_{Nov}
(3) 
_{Dec}
(30) 

2008 
_{Jan}
(59) 
_{Feb}
(22) 
_{Mar}
(55) 
_{Apr}
(4) 
_{May}
(15) 
_{Jun}
(29) 
_{Jul}
(6) 
_{Aug}
(17) 
_{Sep}

_{Oct}
(27) 
_{Nov}
(8) 
_{Dec}
(14) 
2009 
_{Jan}
(6) 
_{Feb}
(26) 
_{Mar}
(48) 
_{Apr}
(11) 
_{May}
(3) 
_{Jun}
(20) 
_{Jul}
(28) 
_{Aug}
(48) 
_{Sep}
(85) 
_{Oct}
(34) 
_{Nov}
(23) 
_{Dec}
(65) 
2010 
_{Jan}
(68) 
_{Feb}
(46) 
_{Mar}
(105) 
_{Apr}
(74) 
_{May}
(185) 
_{Jun}
(118) 
_{Jul}
(179) 
_{Aug}
(170) 
_{Sep}
(513) 
_{Oct}
(113) 
_{Nov}
(41) 
_{Dec}
(52) 
2011 
_{Jan}
(59) 
_{Feb}
(102) 
_{Mar}
(110) 
_{Apr}
(197) 
_{May}
(123) 
_{Jun}
(91) 
_{Jul}
(195) 
_{Aug}
(209) 
_{Sep}
(233) 
_{Oct}
(112) 
_{Nov}
(241) 
_{Dec}
(86) 
2012 
_{Jan}
(138) 
_{Feb}
(151) 
_{Mar}
(326) 
_{Apr}
(154) 
_{May}
(278) 
_{Jun}
(230) 
_{Jul}
(311) 
_{Aug}
(327) 
_{Sep}
(194) 
_{Oct}
(139) 
_{Nov}
(243) 
_{Dec}
(141) 
2013 
_{Jan}
(169) 
_{Feb}
(90) 
_{Mar}
(187) 
_{Apr}
(228) 
_{May}
(150) 
_{Jun}
(328) 
_{Jul}
(287) 
_{Aug}
(199) 
_{Sep}
(288) 
_{Oct}
(199) 
_{Nov}
(310) 
_{Dec}
(214) 
2014 
_{Jan}
(166) 
_{Feb}
(66) 
_{Mar}
(90) 
_{Apr}
(166) 
_{May}
(166) 
_{Jun}
(99) 
_{Jul}
(120) 
_{Aug}
(139) 
_{Sep}
(107) 
_{Oct}
(142) 
_{Nov}
(171) 
_{Dec}
(170) 
2015 
_{Jan}
(138) 
_{Feb}
(100) 
_{Mar}
(101) 
_{Apr}
(83) 
_{May}
(143) 
_{Jun}
(148) 
_{Jul}
(139) 
_{Aug}
(174) 
_{Sep}
(60) 
_{Oct}
(52) 
_{Nov}
(41) 
_{Dec}
(59) 
2016 
_{Jan}
(40) 
_{Feb}
(86) 
_{Mar}
(121) 
_{Apr}
(154) 
_{May}
(78) 
_{Jun}
(46) 
_{Jul}
(71) 
_{Aug}
(191) 
_{Sep}
(96) 
_{Oct}
(44) 
_{Nov}
(85) 
_{Dec}
(52) 
2017 
_{Jan}
(80) 
_{Feb}
(65) 
_{Mar}
(85) 
_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



1
(5) 
2

3
(2) 
4

5
(6) 
6

7
(7) 
8
(3) 
9
(3) 
10
(4) 
11
(4) 
12
(7) 
13

14
(5) 
15

16
(2) 
17
(6) 
18

19

20
(1) 
21
(4) 
22
(4) 
23
(13) 
24
(6) 
25
(8) 
26
(4) 
27

28
(6) 
29
(3) 
30
(6) 
31
(1) 


From: Kai Tietz <ktietz70@go...>  20110307 19:09:02

2011/3/7 K Shen <kishshen@...>: > Hi Kai, > >  On Mon, 7/3/11, Kai Tietz <ktietz70@...> wrote: > >> >> I meant y without decimal place and x without decimal >> place, which >> have for x ^ y always integer result. For x with decimal >> place and y >> without decimal place we can use here powi instead, which >> should do >> more exact rounding. >> > > By decimal place, do you mean a integer type, or do you mean an > integral value (e.g. 3.0)? In our actual code, both arguments passed > to pow() are doubles, i.e. we are effectively calling > > pow(2.0,3.0) > > You comments about using ipow() for more precision raises a question > about the precision of the general pow() for double values. The result > for the general pow(2.0, 3.0) suggest it may not achieve the precision we are assuming. > > As I said, we have a "bounded real" type that is designed to deal with > the finite precision of any floating types. The idea is that we have upper and lower bounds that are supposed to enclose the exact (inifinite precision) value of a real number. For the Windows implementation, > we perform the rounding using MS's _controlfp: > > _controlfp(_RC_UP, _MCW_RC) to round up, for example. > > The assumption is that the double value returned by a function is the closest double to the exact answer, so that the rounded up and rounded down double values will enclose the exact value. > > For the case of pow(2.0,3.0), the exact value of 8.0 can be represented > (and appears to be the value returned on other platforms). The returned result of 7.9999999999999982 suggest that the general pow() is not returning answers with the precision we are assuming, because the rounded bounds are: > > lower: 7.9999999999999973 > upper: 7.9999999999999991 > > which does not enclose 8.0. > > Do you know if the routines in the 1.0 runtime achieve this precision for the general pow() function? > > Thanks and cheers, > > Kish > I fixed issue on trunk with rev. 4067. So my tests for x ^ integer provide now good results. Btw I mean the digits after the decimalpoint. Regards, Kai 
From: K Shen <kishshen@ya...>  20110307 17:45:20

Hi Kai, How do I download this? I took a look at the download directories, and everything seems to be labelled with 1.0, but I assume not all of them have this 1.0 runtime? Thanks and cheers, Kish  On Mon, 7/3/11, Kai Tietz <ktietz70@...> wrote: > > There are no compiletime flags for this. You would need to > fallback > to 1.0 runtime. > 
From: K Shen <kishshen@ya...>  20110307 17:27:03

Hi Kai,  On Mon, 7/3/11, Kai Tietz <ktietz70@...> wrote: > > I meant y without decimal place and x without decimal > place, which > have for x ^ y always integer result. For x with decimal > place and y > without decimal place we can use here powi instead, which > should do > more exact rounding. > By decimal place, do you mean a integer type, or do you mean an integral value (e.g. 3.0)? In our actual code, both arguments passed to pow() are doubles, i.e. we are effectively calling pow(2.0,3.0) You comments about using ipow() for more precision raises a question about the precision of the general pow() for double values. The result for the general pow(2.0, 3.0) suggest it may not achieve the precision we are assuming. As I said, we have a "bounded real" type that is designed to deal with the finite precision of any floating types. The idea is that we have upper and lower bounds that are supposed to enclose the exact (inifinite precision) value of a real number. For the Windows implementation, we perform the rounding using MS's _controlfp: _controlfp(_RC_UP, _MCW_RC) to round up, for example. The assumption is that the double value returned by a function is the closest double to the exact answer, so that the rounded up and rounded down double values will enclose the exact value. For the case of pow(2.0,3.0), the exact value of 8.0 can be represented (and appears to be the value returned on other platforms). The returned result of 7.9999999999999982 suggest that the general pow() is not returning answers with the precision we are assuming, because the rounded bounds are: lower: 7.9999999999999973 upper: 7.9999999999999991 which does not enclose 8.0. Do you know if the routines in the 1.0 runtime achieve this precision for the general pow() function? Thanks and cheers, Kish > >> > >> I found this precision problem because in our > system > >> (ECLiPSe consraint logic programming language), we > have a > >> number type "bounded reals", which has an upper > and lower > >> bound, and the bounds are supposed to enclose the > exact > >> value of the real number (which might not be > representable > >> with finite precision). We obtain this from a > double value > >> by rounding it up and down, and using these as the > bounds. > >> In the case of the result of > >> power(2.0, 3), the upper bound is still less than > 8.0 after > >> rounding up. > >> [and is the same value as the lower bound on > other > >> platforms, which is why I knew it was about two > times off > >> the expected precision] > >> > >> > >> > Yes, we changed some mathroutines to > statisfy ISOC > >> > standard here. > >> > The MS routines aren't suiteable in all cases > here. > >> There > >> > is for > >> > example still an outstanding issue about the > >> > besselfunctions, which > >> > aren't satisfying ISOC in all cases. Those > routines > >> are > >> > implemented > >> > in older runtime via gdtoa implementation, > which sadly > >> has > >> > proven as > >> > pretty slow for IEEE operations and > additional had > >> shown > >> > some issues > >> > about ISOC standard, too. > >> > > >> > >> Thanks for the explanation. Are there anything > else done > >> by > >> MinGWw64 other than the floating point > functions? > >> > >> > > >> > Well, first you can fallback to 1.0 > branchmath. This > >> > implementation > >> > is slower, but in those cases more accurate. > But also > >> > doesn't satisfy > >> > ISOC standard well. > >> > Second way to fix that (and IMHO the better > one) spent > >> some > >> > effort in > >> > current implementation to improve it. > >> > > >> > >> Do I need to compile w64MinGW in order to get > this, or can > >> I specify this with a flag (for the compiler or > linker?)? > > There are no compiletime flags for this. You would need to > fallback > to 1.0 runtime. > > >> Thanks and cheers, > >> > >> Kish > >> > >> > >> > >> > > > > Regards, > Kai > 
From: Kai Tietz <ktietz70@go...>  20110307 16:36:22

2011/3/7 K Shen <kishshen@...>: > > (I don't think I cc'ed this to the list, so I am forwarding this. Apologies if this appear twice) > >  On Mon, 7/3/11, K Shen <kishshen@...> wrote: > >> From: K Shen <kishshen@...> >> Subject: Re: [Mingww64public] problem with pow() and log() >> To: "Kai Tietz" <ktietz70@...> >> Date: Monday, 7 March, 2011, 16:15 >> Hi Kai, >> >> Thank you very much for your quick reply! >> >>  On Mon, 7/3/11, Kai Tietz <ktietz70@...> >> wrote: >> >> >> > > 2) pow(2.0, 3) now returns 7.9999999999999982 >> instead >> > of 8.0. While this >> > > is close to 8.0, on all other platforms we get >> 8.0 >> > (and also from the previous version of MinGWw64), and >> the >> > difference from 8.0 (1.8e15) seems to be about twice >> as >> > large the expected precision. >> > >> > Hmm, here is rounding missing. This is a special case >> for >> > noneodd x >> > and noneodd y >= 0. So we need to extend here our >> > routine. I will >> > think about that, but of course are patches for fixing >> it >> > welcome, too >> > :) >> > >> >> Do you mean odd y >= 0? [y = 3 in my example] I meant y without decimal place and x without decimal place, which have for x ^ y always integer result. For x with decimal place and y without decimal place we can use here powi instead, which should do more exact rounding. >> I have now tried more values with the power function, and >> it seems that for even x, then I seem to get a nonintegral >> values for any integeral values of y >= 2 (I did not try >> y = 1). >> >> I found this precision problem because in our system >> (ECLiPSe consraint logic programming language), we have a >> number type "bounded reals", which has an upper and lower >> bound, and the bounds are supposed to enclose the exact >> value of the real number (which might not be representable >> with finite precision). We obtain this from a double value >> by rounding it up and down, and using these as the bounds. >> In the case of the result of >> power(2.0, 3), the upper bound is still less than 8.0 after >> rounding up. >> [and is the same value as the lower bound on other >> platforms, which is why I knew it was about two times off >> the expected precision] >> >> >> > Yes, we changed some mathroutines to statisfy ISOC >> > standard here. >> > The MS routines aren't suiteable in all cases here. >> There >> > is for >> > example still an outstanding issue about the >> > besselfunctions, which >> > aren't satisfying ISOC in all cases. Those routines >> are >> > implemented >> > in older runtime via gdtoa implementation, which sadly >> has >> > proven as >> > pretty slow for IEEE operations and additional had >> shown >> > some issues >> > about ISOC standard, too. >> > >> >> Thanks for the explanation. Are there anything else done >> by >> MinGWw64 other than the floating point functions? >> >> > >> > Well, first you can fallback to 1.0 branchmath. This >> > implementation >> > is slower, but in those cases more accurate. But also >> > doesn't satisfy >> > ISOC standard well. >> > Second way to fix that (and IMHO the better one) spent >> some >> > effort in >> > current implementation to improve it. >> > >> >> Do I need to compile w64MinGW in order to get this, or can >> I specify this with a flag (for the compiler or linker?)? There are no compiletime flags for this. You would need to fallback to 1.0 runtime. >> Thanks and cheers, >> >> Kish >> >> >> >> > Regards, Kai 
From: K Shen <kishshen@ya...>  20110307 16:19:02

(I don't think I cc'ed this to the list, so I am forwarding this. Apologies if this appear twice)  On Mon, 7/3/11, K Shen <kishshen@...> wrote: > From: K Shen <kishshen@...> > Subject: Re: [Mingww64public] problem with pow() and log() > To: "Kai Tietz" <ktietz70@...> > Date: Monday, 7 March, 2011, 16:15 > Hi Kai, > > Thank you very much for your quick reply! > >  On Mon, 7/3/11, Kai Tietz <ktietz70@...> > wrote: > > > > > 2) pow(2.0, 3) now returns 7.9999999999999982 > instead > > of 8.0. While this > > > is close to 8.0, on all other platforms we get > 8.0 > > (and also from the previous version of MinGWw64), and > the > > difference from 8.0 (1.8e15) seems to be about twice > as > > large the expected precision. > > > > Hmm, here is rounding missing. This is a special case > for > > noneodd x > > and noneodd y >= 0. So we need to extend here our > > routine. I will > > think about that, but of course are patches for fixing > it > > welcome, too > > :) > > > > Do you mean odd y >= 0? [y = 3 in my example] > > I have now tried more values with the power function, and > it seems that for even x, then I seem to get a nonintegral > values for any integeral values of y >= 2 (I did not try > y = 1). > > I found this precision problem because in our system > (ECLiPSe consraint logic programming language), we have a > number type "bounded reals", which has an upper and lower > bound, and the bounds are supposed to enclose the exact > value of the real number (which might not be representable > with finite precision). We obtain this from a double value > by rounding it up and down, and using these as the bounds. > In the case of the result of > power(2.0, 3), the upper bound is still less than 8.0 after > rounding up. > [and is the same value as the lower bound on other > platforms, which is why I knew it was about two times off > the expected precision] > > > > Yes, we changed some mathroutines to statisfy ISOC > > standard here. > > The MS routines aren't suiteable in all cases here. > There > > is for > > example still an outstanding issue about the > > besselfunctions, which > > aren't satisfying ISOC in all cases. Those routines > are > > implemented > > in older runtime via gdtoa implementation, which sadly > has > > proven as > > pretty slow for IEEE operations and additional had > shown > > some issues > > about ISOC standard, too. > > > > Thanks for the explanation. Are there anything else done > by > MinGWw64 other than the floating point functions? > > > > > Well, first you can fallback to 1.0 branchmath. This > > implementation > > is slower, but in those cases more accurate. But also > > doesn't satisfy > > ISOC standard well. > > Second way to fix that (and IMHO the better one) spent > some > > effort in > > current implementation to improve it. > > > > Do I need to compile w64MinGW in order to get this, or can > I specify this with a flag (for the compiler or linker?)? > > Thanks and cheers, > > Kish > > > > 
From: Kai Tietz <ktietz70@go...>  20110307 08:09:12

Hello Kish, 2011/3/7 K Shen <kishshen@...>: > Hi, > > I recently download a recent version of MinGWw64 crosscompiler (compile for 64 bit Windows on Linux), to replace a old version I have been using > for about two years. > > I have found two problems that didn't occur with the old version of MinGWw64: > > 1) log(0.0) now returns NaN, instead of infinity (log(0.0) does return infinity). > > I think the standard behaviour is to return infinity. Our code (which runs on many platforms) seems to rely on this. In most man pages, the exact behaviour for 0.0 is not always specified, but it is for Mac OS X, and there it is specified to return inifity. Yes, thanks for noticing that. Sepcification says (ISO/IEC 9899:TC3) F.9.3.7 The log functions 1 — log(±0) returns oo and raises the ‘‘dividebyzero’’ floatingpoint exception. — log(1) returns +0. — log(x) returns a NaN and raises the ‘‘invalid’’ floatingpoint exception for x < 0. — log(+oo) returns +oo We had here in our code checked for sign befor zerocheck. I fixed that at rev 4066. > 2) pow(2.0, 3) now returns 7.9999999999999982 instead of 8.0. While this > is close to 8.0, on all other platforms we get 8.0 (and also from the previous version of MinGWw64), and the difference from 8.0 (1.8e15) seems to be about twice as large the expected precision. Hmm, here is rounding missing. This is a special case for noneodd x and noneodd y >= 0. So we need to extend here our routine. I will think about that, but of course are patches for fixing it welcome, too :) > I was also surprised that the bheaviour is different between the old > and recent versions of MinGWw64  these functions are in the math library (libm), and I thought in crosscompiled MinGW, all standard > C functions are supplied by the native Microsoft libraries, so there should not be any difference in behaviours between different versions of MinGWw64 Yes, we changed some mathroutines to statisfy ISOC standard here. The MS routines aren't suiteable in all cases here. There is for example still an outstanding issue about the besselfunctions, which aren't satisfying ISOC in all cases. Those routines are implemented in older runtime via gdtoa implementation, which sadly has proven as pretty slow for IEEE operations and additional had shown some issues about ISOC standard, too. > Any suggestion on how the problems can be fixed, and are these functions defined in MinGW or are the Microsoft versions used? If the Microsoft versions are used, why is there this difference? Well, first you can fallback to 1.0 branchmath. This implementation is slower, but in those cases more accurate. But also doesn't satisfy ISOC standard well. Second way to fix that (and IMHO the better one) spent some effort in current implementation to improve it. > Thanks in advance for any information and help! > > Kish Shen Regards, Kai 
From: K Shen <kishshen@ya...>  20110307 01:22:32

Hi, I recently download a recent version of MinGWw64 crosscompiler (compile for 64 bit Windows on Linux), to replace a old version I have been using for about two years. I have found two problems that didn't occur with the old version of MinGWw64: 1) log(0.0) now returns NaN, instead of infinity (log(0.0) does return infinity). I think the standard behaviour is to return infinity. Our code (which runs on many platforms) seems to rely on this. In most man pages, the exact behaviour for 0.0 is not always specified, but it is for Mac OS X, and there it is specified to return inifity. 2) pow(2.0, 3) now returns 7.9999999999999982 instead of 8.0. While this is close to 8.0, on all other platforms we get 8.0 (and also from the previous version of MinGWw64), and the difference from 8.0 (1.8e15) seems to be about twice as large the expected precision. I was also surprised that the bheaviour is different between the old and recent versions of MinGWw64  these functions are in the math library (libm), and I thought in crosscompiled MinGW, all standard C functions are supplied by the native Microsoft libraries, so there should not be any difference in behaviours between different versions of MinGWw64 Any suggestion on how the problems can be fixed, and are these functions defined in MinGW or are the Microsoft versions used? If the Microsoft versions are used, why is there this difference? Thanks in advance for any information and help! Kish Shen 