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}
(91) 
_{Apr}
(61) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






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

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

18
(6) 
19
(4) 
20
(1) 
21
(2) 
22
(15) 
23
(1) 
24

25
(2) 
26
(2) 
27
(16) 
28
(12) 
29
(22) 
30
(9) 
From: K. Frank <kfrank29.c@gm...>  20110430 22:13:15

Hello Bob and Kai! On Sat, Apr 30, 2011 at 5:41 PM, Kai Tietz <ktietz70@...> wrote: > 2011/4/30 Bob Delaney <delaneyrm@...>: >> >> On Apr 30, 2011, at 10:15 AM, K. Frank wrote: >> >>> I get: >>> >>> C:\>gcc o pow_test pow_test.c >>> >>> C:\>pow_test >>> 2.20000000000000017764^3.10000000000000008882 = 11.52153412678571875460 >> >> >> Victor Shoup's NTL and my own fp, to 22 digit accuracy, give: >> >> 2.20000000000000017764^3.10000000000000008882 = 11.52153412678571783832 >> >> so your result is accurate to only 16 digits. Your This is exactly what I would expect (short of looking at the actual binary representation). An IEEE double is 64 bits, with a 52bit mantissa, which, with the "implicit" bit, gives 53 bits of precision. This gives just under 16 decimal digits of precision, which is what you see. >> >> 2.20000000000000000004^3.09999999999999999991 = 11.52153412678571414718 >> >> should be: >> >> 2.20000000000000000004^3.09999999999999999991 = 11.52153412678571414732 >> >> so your result is accurate to about 20 digits. As I understand it, gcc defines long double as the x87 80bit floating point number. This has a 64bit mantissa, and I believe that it does not use an implicit bit, so this gives slightly more than 19 decimal digits of precision, again consistent with your result. >> >> Bob > > Well, what is to be expected as we used here in test application an > %.20F. By specifying here a %.40F its calculated result is > 11.5215341267857141471786519559827866032720 and it is has binary > identity for what gmp calculates for 80bit IEEE 754 floating point. > Which means for our purposes in gcc, it has right accuracy. (Kai's comment seems to confirm that gcc's long double is, indeed, the 80bit floatingpoint number.) > Kai Thanks to all for the insight. K. Frank 
From: Kai Tietz <ktietz70@go...>  20110430 15:48:06

2011/4/30 Kai Tietz <ktietz70@...>: > 2011/4/30 K. Frank <kfrank29.c@...>: >> Hello Kai! >> >> On Sat, Apr 30, 2011 at 5:51 AM, Kai Tietz <ktietz70@...> wrote: >>> 2011/4/30 Kai Tietz <ktietz70@...>: >>>> 2011/4/30 Greg Chicares <gchicares@...>: >>>>> On 20110429 19:55Z, K. Frank wrote: >>>>>> >>>>>> By the way, could someone confirm that mingw does use msvcrt for >>>>>> sqrt and pow? >>>>> >>>>> http://cygwin.com/cgibin/cvsweb.cgi/src/winsup/mingw/mingwex/math/?cvsroot=src >>>>> >>>>> Looks to me like sqrt(double) calls into msvcrt. But pow() is a >>>>> different story. Danny implemented it in libmingwex because of >>>>> some qualityofimplementation problem with msvcrt; then people >>>>> complained that the libmingwex version was slower, and I can't >>>>> remember where it wound up, but it's all in the archives. >>>>> >>>>>> sqrt (x) and pow (x, 0.5) ought to give the same result (even if not required >>>>>> to by IEEE754). >>>>> ... >>>>> Not so many years ago (perhaps when msvcrt was written), it was >>>>> thought that correctlyrounded transcendental functions weren't >>>>> feasible in practice, so library authors had a looser attitude >>>>> toward exactness. If you have an ideal implementation of sqrt() >>>>> but a pow() that's only approximate, should you specialcase >>>>> the power of exactly 0.5? If you do, then pow() and sqrt() will >>>>> be consistent, but then the powers >>>>> x^(0.5*(1epsilon)) >>>>> x^(0.5 ) >>>>> x^(0.5*(1+epsilon)) >>>>> might not be monotone. Some would call that a bad tradeoff. >>>> >>>> Well, I spent some efforts into log, exp, and pow implementation. Also >>>> some other basemath functions I improved in mingww64's math library >>>> in two terms. a) Make those functions behave as ISOC99 specification >>>> tells in cornercases. and b) Improve accuracy in terms of gcc's >>>> internal used gmp. As we noticed here result differences. >>>> >>>> The following example illustrates the issues pretty well: >>>> >>>> #include <stdio.h> >>>> #include <math.h> >>>> >>>> double abc[3][2] = { { 2.2, 3.1 }, { 2.0, 3.0 }, { 4.0, 0.5 } }; >>>> long double ab[3][2] = { { 2.2L, 3.1L }, { 2.0L, 3.0L }, { 4.0L, 0.5L } }; >>>> int main() >>>> { >>>> double r[3]; >>>> long double rl[3]; >>>> int i; >>>> for (i = 0; i < 3; i++) >>>> __mingw_printf ("%.20F^%.20F = %.20F\n", abc[i][0], abc[i][1], >>>> (r[i] = pow (abc[i][0], abc[i][1]))); >>>> __mingw_printf ("%.20F %.20F %.20F\n", pow (2.2, 3.1), pow (2.0, >>>> 3.0), pow (4.0, 0.5)); >>>> r[0] = pow (2.2, 3.1); >>>> r[1] = pow (2.0, 3.0); >>>> r[2] = pow (4.0, 0.5); >>>> __mingw_printf ("%.20F %.20F %.20F\n", r[0], r[1], r[2]); >>>> >>>> for (i = 0; i < 3; i++) >>>> __mingw_printf ("%.20LF^%.20LF = %.20LF\n", ab[i][0], ab[i][1], >>>> (rl[i] = powl (ab[i][0], ab[i][1]))); >>>> __mingw_printf ("%.20LF %.20LF %.20LF\n", >>>> powl (2.2L, 3.1L), powl (2.0L, 3.0L) , powl >>>> (4.0L, 0.5L)); >>>> rl[0] = powl (2.2L, 3.1L); >>>> rl[1] = powl (2.0L, 3.0L); >>>> rl[2] = powl (4.0L, 0.5L); >>>> __mingw_printf ("%.20LF %.20LF %.20LF\n", rl[0], rl[1], rl[2]); >>>> return 1; >>>> } >> >> Do I understand your point correctly that you are comparing gcc's >> compiletime and runtime values for pow? >> >> For the record, when I run this on a mingw64 build: >> >> gcc (GCC) 4.5.2 20101002 (prerelease) [svn/rev.164902  mingww64/oz] >> >> I get: >> >> C:\>gcc o pow_test pow_test.c >> >> C:\>pow_test >> 2.20000000000000017764^3.10000000000000008882 = 11.52153412678571875460 >> 2.00000000000000000000^3.00000000000000000000 = 8.00000000000000000000 >> 4.00000000000000000000^0.50000000000000000000 = 2.00000000000000000000 >> 11.52153412678571697825 8.00000000000000000000 2.00000000000000000000 >> 0.00000000000000177636 0.00000000000000000000 0.00000000000000000000 >> 2.20000000000000000004^3.09999999999999999991 = 11.52153412678571414718 >> 2.00000000000000000000^3.00000000000000000000 = 8.00000000000000000000 >> 4.00000000000000000000^0.50000000000000000000 = 2.00000000000000000000 >> 11.52153412678571414718 8.00000000000000000000 2.00000000000000000000 >> 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 >> >> As I understand it, this means I am seeing a small difference between >> compile and runtime evaluation only for powl (2.2, 3.1), i.e., the >> longdouble case. >> >>>> The interesting issue is here that gcc uses for constant >>>> mathcalculations gmplibrary to get result. For more complex >>>> variants, it uses crt's math. By this it is important for a gcc based >>>> runtime to be in the IEEE 754 floating point compatible to gmp's >>>> results. >> >> Yes, that's a good point. I hadn't considered the issue of compiletime >> evaluation, and, ideally, it should agree with runtime evaluation, adding >> yet another constraint to our wish list. >> >> Furthermore, if we take the idea of a crosscompiler seriously, we >> would also like the compiletime evaluations of a crosscompiler and >> native compiler to agree. >> >> Hmm... >> >> So, we would like sqrt (x) and pow (x, 0.5) to agree. We would like >> compiletime and runtime evaluations to agree. We would like >> crosscompilers and native compilers to agree. >> >> Taken at face value, this would seem to preclude using the platform >> library and platform hardware to compute things like sqrt and pow >> (unless we know they comply with some agreedupon standard, >> such as IEEE754). >> >> Just to make the reasoning explicit, if I perform my runtime evaluation >> on platform A, e.g., using platform A's FPU, then a B>A crosscompiler >> running on platform B won't have platform A's FPU available to perform >> consistent compiletime evaluations. >> >> So you either give up some of the abovewishedfor consistency, you >> forgo the potential performance benefits of using the platform's library >> and / or hardware, or you get everybody to use a common standard. >> >>>> ... >>>> I admit that this might be not that obvious to users, why results here >>>> are different, but for a gcc based toolchain we need to play nice with >>>> gcc's internal assumptions. >>>> >>>> Regards, >>>> Kai >>> >>> On closer look for long double, we can have rouding issues for long >>> double precission. I see that powl (0.01L, 0.5L) we have a rounding >>> difference to sqrtl (0.01L). Interestingly not for float or double >>> types. So we we might need to specialcase in pow the case for y == >>> 0.5 to solve this. >> >> Be, however, cognizant of Greg's concern. Forcing pow to agree with >> sqrt just for y = 0.5 has the potential to make pow, in a sense, internally >> inconsistent, It's a tricky tradeoff. (Ideally, both pow and sqrt would >> be "exact" and therefore agree with one another automatically.) >> >> By the way, I also see a problem with runtime powl for powl (2.2L, 0.5L). >> It disagrees slightly from sqrtl (2.2L) and from the compiletime value >> for powl (2.2L, 0.5L). >> >> I modified your test program to compare sqrt with pow (x, 0.5) (and sqrtl >> with powl). For the record: >> >> C:\>gcc version >> gcc (GCC) 4.5.2 20101002 (prerelease) [svn/rev.164902  mingww64/oz] >> >> C:\>gcc o sqrt_pow sqrt_pow.c >> >> C:\>sqrt_pow >> 1.04880884817015163080, 1.04880884817015163080, 0.00000000000000000000 >> 1.48323969741913264109, 1.48323969741913264109, 0.00000000000000000000 >> 1.81659021245849494619, 1.81659021245849494619, 0.00000000000000000000 >> 1.04880884817015163080 1.04880884817015163080 >> 1.48323969741913264109 1.48323969741913264109 >> 1.81659021245849494619 1.81659021245849494619 >> 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 >> 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 >> 1.04880884817015154699, 1.04880884817015154699, 0.00000000000000000000 >> 1.48323969741913258980, 1.48323969741913258970, 0.00000000000000000011 >> 1.81659021245849499921, 1.81659021245849499921, 0.00000000000000000000 >> 1.04880884817015154699 1.04880884817015154699 >> 1.48323969741913258980 1.48323969741913258980 >> 1.81659021245849499921 1.81659021245849499921 >> 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 >> 0.00000000000000000000 0.00000000000000000011 0.00000000000000000000 >> >> where sqrt_pow.c is: >> >> #include <stdio.h> >> #include <math.h> >> >> double abc[3] = { 1.1, 2.2, 3.3 }; >> long double abcl[3] = { 1.1L, 2.2L, 3.3L }; >> int main() >> { >> double r1[3], r2[3], r3[3]; >> long double rl1[3], rl2[3], rl3[3]; >> int i; >> for (i = 0; i < 3; i++) >> __mingw_printf ("%.20F, %.20F, %.20F\n", >> (r1[i] = sqrt (abc[i])), >> (r2[i] = pow (abc[i], 0.5)), >> (r3[i] = pow (abc[i], 0.5)  sqrt (abc[i]))); >> __mingw_printf ("%.20F %.20F\n", sqrt (1.1), pow (1.1, 0.5)); >> __mingw_printf ("%.20F %.20F\n", sqrt (2.2), pow (2.2, 0.5)); >> __mingw_printf ("%.20F %.20F\n", sqrt (3.3), pow (3.3, 0.5)); >> r1[0] = sqrt (1.1); >> r1[1] = sqrt (2.2); >> r1[2] = sqrt (3.3); >> __mingw_printf ("%.20F %.20F %.20F\n", r1[0], r1[1], r1[2]); >> r2[0] = pow (1.1, 0.5); >> r2[1] = pow (2.2, 0.5); >> r2[2] = pow (3.3, 0.5); >> __mingw_printf ("%.20F %.20F %.20F\n", r2[0], r2[1], r2[2]); >> >> for (i = 0; i < 3; i++) >> __mingw_printf ("%.20LF, %.20LF, %.20LF\n", >> (rl1[i] = sqrtl (abcl[i])), >> (rl2[i] = powl (abcl[i], 0.5L)), >> (rl3[i] = powl (abcl[i], 0.5L)  sqrtl (abcl[i]))); >> __mingw_printf ("%.20LF %.20LF\n", sqrtl (1.1L), powl (1.1L, 0.5L)); >> __mingw_printf ("%.20LF %.20LF\n", sqrtl (2.2L), powl (2.2L, 0.5L)); >> __mingw_printf ("%.20LF %.20LF\n", sqrtl (3.3L), powl (3.3L, 0.5L)); >> rl1[0] = sqrtl (1.1L); >> rl1[1] = sqrtl (2.2L); >> rl1[2] = sqrtl (3.3L); >> __mingw_printf ("%.20LF %.20LF %.20LF\n", rl1[0], rl1[1], rl1[2]); >> rl2[0] = powl (1.1L, 0.5L); >> rl2[1] = powl (2.2L, 0.5L); >> rl2[2] = powl (3.3L, 0.5L); >> __mingw_printf ("%.20LF %.20LF %.20LF\n", rl2[0], rl2[1], rl2[2]); >> >> return 1; >> } >> >>> >>> Kai >> >> Thanks, Kai, for your insight and explanations. >> >> >> K. Frank > > I add a special case to mingww64's pow(fl) function about y=0.5 and > get now for your adjusted testcase the following results, which are > looking much better IMHO. > > $ ./tst.exe > 1.04880884817015163080, 1.04880884817015163080, 0.00000000000000004142 > 1.48323969741913264109, 1.48323969741913264109, 0.00000000000000000857 > 1.81659021245849494619, 1.81659021245849494619, 0.00000000000000000412 > 1.04880884817015163080 1.04880884817015163080 > 1.48323969741913264109 1.48323969741913264109 > 1.81659021245849494619 1.81659021245849494619 > 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 > 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 > 1.04880884817015154699, 1.04880884817015154699, 0.00000000000000000000 > 1.48323969741913258980, 1.48323969741913258980, 0.00000000000000000000 > 1.81659021245849499921, 1.81659021245849499921, 0.00000000000000000000 > 1.04880884817015154699 1.04880884817015154699 > 1.48323969741913258980 1.48323969741913258980 > 1.81659021245849499921 1.81659021245849499921 > 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 > 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 > > I used for this a 32bit variant and 64bit variant, which made no > differences in output. > The issue here is that 1.0 branch still uses the inaccurate variant > from Danny, but nowaday's trunk uses for pow, sqrt, log, and exp > functions new implementations, which are treating rounding and > shortpath calculation in an ISOC variant (as gcc expects internally > such a math). Also complexmath part is completely rewritten on > mingww64's trunk version. > > IMHO it might be a good idea to replace step by step the classical > runtime functions, so that they are not using here msvcrt in first > place. Of course the importsymbols of msvcrt (for compatibility with > VC generated objects need to remain in .def exports, but the actual > functions should come directly from mingwex. > PS: The differences shown in results for 32bit aren't caused by inaccuarcy of used math directly. Instead it is caused by the fact that 32bit use FPU registers (which are 80bit always). By this the inline difference without using store, have for double small differences. By first storing values and then printing those stored values you see also for 32bit a delta of zero. Interesting this behavior is on 64bit x86_64 different, as it uses always precise accuracy to store results in registers. By this you have really just a 64bit result for double type, and not indirecty 80bit (as shown in first case). I altered your testcase a bit in following lines ... for (i = 0; i < 3; i++) { r1[i] = sqrt (abc[i]); r2[i] = pow (abc[i], 0.5); r3[i] = pow (abc[i], 0.5)  sqrt (abc[i]); __mingw_printf ("%.20F, %.20F, %.20F\n", r1[i], r2[i], r3[i]); } ... and get now $ ./tst.exe 1.04880884817015163080, 1.04880884817015163080, 0.00000000000000000000 1.48323969741913264109, 1.48323969741913264109, 0.00000000000000000000 1.81659021245849494619, 1.81659021245849494619, 0.00000000000000000000 1.04880884817015163080 1.04880884817015163080 1.48323969741913264109 1.48323969741913264109 1.81659021245849494619 1.81659021245849494619 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 1.04880884817015154699, 1.04880884817015154699, 0.00000000000000000000 1.48323969741913258980, 1.48323969741913258980, 0.00000000000000000000 1.81659021245849499921, 1.81659021245849499921, 0.00000000000000000000 1.04880884817015154699 1.04880884817015154699 1.48323969741913258980 1.48323969741913258980 1.81659021245849499921 1.81659021245849499921 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 as result. it is an interesting fact that this happens. Regards, Kai 
From: Kai Tietz <ktietz70@go...>  20110430 15:33:59

2011/4/30 K. Frank <kfrank29.c@...>: > Hello Kai! > > On Sat, Apr 30, 2011 at 5:51 AM, Kai Tietz <ktietz70@...> wrote: >> 2011/4/30 Kai Tietz <ktietz70@...>: >>> 2011/4/30 Greg Chicares <gchicares@...>: >>>> On 20110429 19:55Z, K. Frank wrote: >>>>> >>>>> By the way, could someone confirm that mingw does use msvcrt for >>>>> sqrt and pow? >>>> >>>> http://cygwin.com/cgibin/cvsweb.cgi/src/winsup/mingw/mingwex/math/?cvsroot=src >>>> >>>> Looks to me like sqrt(double) calls into msvcrt. But pow() is a >>>> different story. Danny implemented it in libmingwex because of >>>> some qualityofimplementation problem with msvcrt; then people >>>> complained that the libmingwex version was slower, and I can't >>>> remember where it wound up, but it's all in the archives. >>>> >>>>> sqrt (x) and pow (x, 0.5) ought to give the same result (even if not required >>>>> to by IEEE754). >>>> ... >>>> Not so many years ago (perhaps when msvcrt was written), it was >>>> thought that correctlyrounded transcendental functions weren't >>>> feasible in practice, so library authors had a looser attitude >>>> toward exactness. If you have an ideal implementation of sqrt() >>>> but a pow() that's only approximate, should you specialcase >>>> the power of exactly 0.5? If you do, then pow() and sqrt() will >>>> be consistent, but then the powers >>>> x^(0.5*(1epsilon)) >>>> x^(0.5 ) >>>> x^(0.5*(1+epsilon)) >>>> might not be monotone. Some would call that a bad tradeoff. >>> >>> Well, I spent some efforts into log, exp, and pow implementation. Also >>> some other basemath functions I improved in mingww64's math library >>> in two terms. a) Make those functions behave as ISOC99 specification >>> tells in cornercases. and b) Improve accuracy in terms of gcc's >>> internal used gmp. As we noticed here result differences. >>> >>> The following example illustrates the issues pretty well: >>> >>> #include <stdio.h> >>> #include <math.h> >>> >>> double abc[3][2] = { { 2.2, 3.1 }, { 2.0, 3.0 }, { 4.0, 0.5 } }; >>> long double ab[3][2] = { { 2.2L, 3.1L }, { 2.0L, 3.0L }, { 4.0L, 0.5L } }; >>> int main() >>> { >>> double r[3]; >>> long double rl[3]; >>> int i; >>> for (i = 0; i < 3; i++) >>> __mingw_printf ("%.20F^%.20F = %.20F\n", abc[i][0], abc[i][1], >>> (r[i] = pow (abc[i][0], abc[i][1]))); >>> __mingw_printf ("%.20F %.20F %.20F\n", pow (2.2, 3.1), pow (2.0, >>> 3.0), pow (4.0, 0.5)); >>> r[0] = pow (2.2, 3.1); >>> r[1] = pow (2.0, 3.0); >>> r[2] = pow (4.0, 0.5); >>> __mingw_printf ("%.20F %.20F %.20F\n", r[0], r[1], r[2]); >>> >>> for (i = 0; i < 3; i++) >>> __mingw_printf ("%.20LF^%.20LF = %.20LF\n", ab[i][0], ab[i][1], >>> (rl[i] = powl (ab[i][0], ab[i][1]))); >>> __mingw_printf ("%.20LF %.20LF %.20LF\n", >>> powl (2.2L, 3.1L), powl (2.0L, 3.0L) , powl >>> (4.0L, 0.5L)); >>> rl[0] = powl (2.2L, 3.1L); >>> rl[1] = powl (2.0L, 3.0L); >>> rl[2] = powl (4.0L, 0.5L); >>> __mingw_printf ("%.20LF %.20LF %.20LF\n", rl[0], rl[1], rl[2]); >>> return 1; >>> } > > Do I understand your point correctly that you are comparing gcc's > compiletime and runtime values for pow? > > For the record, when I run this on a mingw64 build: > > gcc (GCC) 4.5.2 20101002 (prerelease) [svn/rev.164902  mingww64/oz] > > I get: > > C:\>gcc o pow_test pow_test.c > > C:\>pow_test > 2.20000000000000017764^3.10000000000000008882 = 11.52153412678571875460 > 2.00000000000000000000^3.00000000000000000000 = 8.00000000000000000000 > 4.00000000000000000000^0.50000000000000000000 = 2.00000000000000000000 > 11.52153412678571697825 8.00000000000000000000 2.00000000000000000000 > 0.00000000000000177636 0.00000000000000000000 0.00000000000000000000 > 2.20000000000000000004^3.09999999999999999991 = 11.52153412678571414718 > 2.00000000000000000000^3.00000000000000000000 = 8.00000000000000000000 > 4.00000000000000000000^0.50000000000000000000 = 2.00000000000000000000 > 11.52153412678571414718 8.00000000000000000000 2.00000000000000000000 > 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 > > As I understand it, this means I am seeing a small difference between > compile and runtime evaluation only for powl (2.2, 3.1), i.e., the > longdouble case. > >>> The interesting issue is here that gcc uses for constant >>> mathcalculations gmplibrary to get result. For more complex >>> variants, it uses crt's math. By this it is important for a gcc based >>> runtime to be in the IEEE 754 floating point compatible to gmp's >>> results. > > Yes, that's a good point. I hadn't considered the issue of compiletime > evaluation, and, ideally, it should agree with runtime evaluation, adding > yet another constraint to our wish list. > > Furthermore, if we take the idea of a crosscompiler seriously, we > would also like the compiletime evaluations of a crosscompiler and > native compiler to agree. > > Hmm... > > So, we would like sqrt (x) and pow (x, 0.5) to agree. We would like > compiletime and runtime evaluations to agree. We would like > crosscompilers and native compilers to agree. > > Taken at face value, this would seem to preclude using the platform > library and platform hardware to compute things like sqrt and pow > (unless we know they comply with some agreedupon standard, > such as IEEE754). > > Just to make the reasoning explicit, if I perform my runtime evaluation > on platform A, e.g., using platform A's FPU, then a B>A crosscompiler > running on platform B won't have platform A's FPU available to perform > consistent compiletime evaluations. > > So you either give up some of the abovewishedfor consistency, you > forgo the potential performance benefits of using the platform's library > and / or hardware, or you get everybody to use a common standard. > >>> ... >>> I admit that this might be not that obvious to users, why results here >>> are different, but for a gcc based toolchain we need to play nice with >>> gcc's internal assumptions. >>> >>> Regards, >>> Kai >> >> On closer look for long double, we can have rouding issues for long >> double precission. I see that powl (0.01L, 0.5L) we have a rounding >> difference to sqrtl (0.01L). Interestingly not for float or double >> types. So we we might need to specialcase in pow the case for y == >> 0.5 to solve this. > > Be, however, cognizant of Greg's concern. Forcing pow to agree with > sqrt just for y = 0.5 has the potential to make pow, in a sense, internally > inconsistent, It's a tricky tradeoff. (Ideally, both pow and sqrt would > be "exact" and therefore agree with one another automatically.) > > By the way, I also see a problem with runtime powl for powl (2.2L, 0.5L). > It disagrees slightly from sqrtl (2.2L) and from the compiletime value > for powl (2.2L, 0.5L). > > I modified your test program to compare sqrt with pow (x, 0.5) (and sqrtl > with powl). For the record: > > C:\>gcc version > gcc (GCC) 4.5.2 20101002 (prerelease) [svn/rev.164902  mingww64/oz] > > C:\>gcc o sqrt_pow sqrt_pow.c > > C:\>sqrt_pow > 1.04880884817015163080, 1.04880884817015163080, 0.00000000000000000000 > 1.48323969741913264109, 1.48323969741913264109, 0.00000000000000000000 > 1.81659021245849494619, 1.81659021245849494619, 0.00000000000000000000 > 1.04880884817015163080 1.04880884817015163080 > 1.48323969741913264109 1.48323969741913264109 > 1.81659021245849494619 1.81659021245849494619 > 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 > 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 > 1.04880884817015154699, 1.04880884817015154699, 0.00000000000000000000 > 1.48323969741913258980, 1.48323969741913258970, 0.00000000000000000011 > 1.81659021245849499921, 1.81659021245849499921, 0.00000000000000000000 > 1.04880884817015154699 1.04880884817015154699 > 1.48323969741913258980 1.48323969741913258980 > 1.81659021245849499921 1.81659021245849499921 > 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 > 0.00000000000000000000 0.00000000000000000011 0.00000000000000000000 > > where sqrt_pow.c is: > > #include <stdio.h> > #include <math.h> > > double abc[3] = { 1.1, 2.2, 3.3 }; > long double abcl[3] = { 1.1L, 2.2L, 3.3L }; > int main() > { > double r1[3], r2[3], r3[3]; > long double rl1[3], rl2[3], rl3[3]; > int i; > for (i = 0; i < 3; i++) > __mingw_printf ("%.20F, %.20F, %.20F\n", > (r1[i] = sqrt (abc[i])), > (r2[i] = pow (abc[i], 0.5)), > (r3[i] = pow (abc[i], 0.5)  sqrt (abc[i]))); > __mingw_printf ("%.20F %.20F\n", sqrt (1.1), pow (1.1, 0.5)); > __mingw_printf ("%.20F %.20F\n", sqrt (2.2), pow (2.2, 0.5)); > __mingw_printf ("%.20F %.20F\n", sqrt (3.3), pow (3.3, 0.5)); > r1[0] = sqrt (1.1); > r1[1] = sqrt (2.2); > r1[2] = sqrt (3.3); > __mingw_printf ("%.20F %.20F %.20F\n", r1[0], r1[1], r1[2]); > r2[0] = pow (1.1, 0.5); > r2[1] = pow (2.2, 0.5); > r2[2] = pow (3.3, 0.5); > __mingw_printf ("%.20F %.20F %.20F\n", r2[0], r2[1], r2[2]); > > for (i = 0; i < 3; i++) > __mingw_printf ("%.20LF, %.20LF, %.20LF\n", > (rl1[i] = sqrtl (abcl[i])), > (rl2[i] = powl (abcl[i], 0.5L)), > (rl3[i] = powl (abcl[i], 0.5L)  sqrtl (abcl[i]))); > __mingw_printf ("%.20LF %.20LF\n", sqrtl (1.1L), powl (1.1L, 0.5L)); > __mingw_printf ("%.20LF %.20LF\n", sqrtl (2.2L), powl (2.2L, 0.5L)); > __mingw_printf ("%.20LF %.20LF\n", sqrtl (3.3L), powl (3.3L, 0.5L)); > rl1[0] = sqrtl (1.1L); > rl1[1] = sqrtl (2.2L); > rl1[2] = sqrtl (3.3L); > __mingw_printf ("%.20LF %.20LF %.20LF\n", rl1[0], rl1[1], rl1[2]); > rl2[0] = powl (1.1L, 0.5L); > rl2[1] = powl (2.2L, 0.5L); > rl2[2] = powl (3.3L, 0.5L); > __mingw_printf ("%.20LF %.20LF %.20LF\n", rl2[0], rl2[1], rl2[2]); > > return 1; > } > >> >> Kai > > Thanks, Kai, for your insight and explanations. > > > K. Frank I add a special case to mingww64's pow(fl) function about y=0.5 and get now for your adjusted testcase the following results, which are looking much better IMHO. $ ./tst.exe 1.04880884817015163080, 1.04880884817015163080, 0.00000000000000004142 1.48323969741913264109, 1.48323969741913264109, 0.00000000000000000857 1.81659021245849494619, 1.81659021245849494619, 0.00000000000000000412 1.04880884817015163080 1.04880884817015163080 1.48323969741913264109 1.48323969741913264109 1.81659021245849494619 1.81659021245849494619 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 1.04880884817015154699, 1.04880884817015154699, 0.00000000000000000000 1.48323969741913258980, 1.48323969741913258980, 0.00000000000000000000 1.81659021245849499921, 1.81659021245849499921, 0.00000000000000000000 1.04880884817015154699 1.04880884817015154699 1.48323969741913258980 1.48323969741913258980 1.81659021245849499921 1.81659021245849499921 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 I used for this a 32bit variant and 64bit variant, which made no differences in output. The issue here is that 1.0 branch still uses the inaccurate variant from Danny, but nowaday's trunk uses for pow, sqrt, log, and exp functions new implementations, which are treating rounding and shortpath calculation in an ISOC variant (as gcc expects internally such a math). Also complexmath part is completely rewritten on mingww64's trunk version. IMHO it might be a good idea to replace step by step the classical runtime functions, so that they are not using here msvcrt in first place. Of course the importsymbols of msvcrt (for compatibility with VC generated objects need to remain in .def exports, but the actual functions should come directly from mingwex. 
From: K. Frank <kfrank29.c@gm...>  20110430 15:15:19

Hello Kai! On Sat, Apr 30, 2011 at 5:51 AM, Kai Tietz <ktietz70@...> wrote: > 2011/4/30 Kai Tietz <ktietz70@...>: >> 2011/4/30 Greg Chicares <gchicares@...>: >>> On 20110429 19:55Z, K. Frank wrote: >>>> >>>> By the way, could someone confirm that mingw does use msvcrt for >>>> sqrt and pow? >>> >>> http://cygwin.com/cgibin/cvsweb.cgi/src/winsup/mingw/mingwex/math/?cvsroot=src >>> >>> Looks to me like sqrt(double) calls into msvcrt. But pow() is a >>> different story. Danny implemented it in libmingwex because of >>> some qualityofimplementation problem with msvcrt; then people >>> complained that the libmingwex version was slower, and I can't >>> remember where it wound up, but it's all in the archives. >>> >>>> sqrt (x) and pow (x, 0.5) ought to give the same result (even if not required >>>> to by IEEE754). >>> ... >>> Not so many years ago (perhaps when msvcrt was written), it was >>> thought that correctlyrounded transcendental functions weren't >>> feasible in practice, so library authors had a looser attitude >>> toward exactness. If you have an ideal implementation of sqrt() >>> but a pow() that's only approximate, should you specialcase >>> the power of exactly 0.5? If you do, then pow() and sqrt() will >>> be consistent, but then the powers >>> x^(0.5*(1epsilon)) >>> x^(0.5 ) >>> x^(0.5*(1+epsilon)) >>> might not be monotone. Some would call that a bad tradeoff. >> >> Well, I spent some efforts into log, exp, and pow implementation. Also >> some other basemath functions I improved in mingww64's math library >> in two terms. a) Make those functions behave as ISOC99 specification >> tells in cornercases. and b) Improve accuracy in terms of gcc's >> internal used gmp. As we noticed here result differences. >> >> The following example illustrates the issues pretty well: >> >> #include <stdio.h> >> #include <math.h> >> >> double abc[3][2] = { { 2.2, 3.1 }, { 2.0, 3.0 }, { 4.0, 0.5 } }; >> long double ab[3][2] = { { 2.2L, 3.1L }, { 2.0L, 3.0L }, { 4.0L, 0.5L } }; >> int main() >> { >> double r[3]; >> long double rl[3]; >> int i; >> for (i = 0; i < 3; i++) >> __mingw_printf ("%.20F^%.20F = %.20F\n", abc[i][0], abc[i][1], >> (r[i] = pow (abc[i][0], abc[i][1]))); >> __mingw_printf ("%.20F %.20F %.20F\n", pow (2.2, 3.1), pow (2.0, >> 3.0), pow (4.0, 0.5)); >> r[0] = pow (2.2, 3.1); >> r[1] = pow (2.0, 3.0); >> r[2] = pow (4.0, 0.5); >> __mingw_printf ("%.20F %.20F %.20F\n", r[0], r[1], r[2]); >> >> for (i = 0; i < 3; i++) >> __mingw_printf ("%.20LF^%.20LF = %.20LF\n", ab[i][0], ab[i][1], >> (rl[i] = powl (ab[i][0], ab[i][1]))); >> __mingw_printf ("%.20LF %.20LF %.20LF\n", >> powl (2.2L, 3.1L), powl (2.0L, 3.0L) , powl >> (4.0L, 0.5L)); >> rl[0] = powl (2.2L, 3.1L); >> rl[1] = powl (2.0L, 3.0L); >> rl[2] = powl (4.0L, 0.5L); >> __mingw_printf ("%.20LF %.20LF %.20LF\n", rl[0], rl[1], rl[2]); >> return 1; >> } Do I understand your point correctly that you are comparing gcc's compiletime and runtime values for pow? For the record, when I run this on a mingw64 build: gcc (GCC) 4.5.2 20101002 (prerelease) [svn/rev.164902  mingww64/oz] I get: C:\>gcc o pow_test pow_test.c C:\>pow_test 2.20000000000000017764^3.10000000000000008882 = 11.52153412678571875460 2.00000000000000000000^3.00000000000000000000 = 8.00000000000000000000 4.00000000000000000000^0.50000000000000000000 = 2.00000000000000000000 11.52153412678571697825 8.00000000000000000000 2.00000000000000000000 0.00000000000000177636 0.00000000000000000000 0.00000000000000000000 2.20000000000000000004^3.09999999999999999991 = 11.52153412678571414718 2.00000000000000000000^3.00000000000000000000 = 8.00000000000000000000 4.00000000000000000000^0.50000000000000000000 = 2.00000000000000000000 11.52153412678571414718 8.00000000000000000000 2.00000000000000000000 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 As I understand it, this means I am seeing a small difference between compile and runtime evaluation only for powl (2.2, 3.1), i.e., the longdouble case. >> The interesting issue is here that gcc uses for constant >> mathcalculations gmplibrary to get result. For more complex >> variants, it uses crt's math. By this it is important for a gcc based >> runtime to be in the IEEE 754 floating point compatible to gmp's >> results. Yes, that's a good point. I hadn't considered the issue of compiletime evaluation, and, ideally, it should agree with runtime evaluation, adding yet another constraint to our wish list. Furthermore, if we take the idea of a crosscompiler seriously, we would also like the compiletime evaluations of a crosscompiler and native compiler to agree. Hmm... So, we would like sqrt (x) and pow (x, 0.5) to agree. We would like compiletime and runtime evaluations to agree. We would like crosscompilers and native compilers to agree. Taken at face value, this would seem to preclude using the platform library and platform hardware to compute things like sqrt and pow (unless we know they comply with some agreedupon standard, such as IEEE754). Just to make the reasoning explicit, if I perform my runtime evaluation on platform A, e.g., using platform A's FPU, then a B>A crosscompiler running on platform B won't have platform A's FPU available to perform consistent compiletime evaluations. So you either give up some of the abovewishedfor consistency, you forgo the potential performance benefits of using the platform's library and / or hardware, or you get everybody to use a common standard. >> ... >> I admit that this might be not that obvious to users, why results here >> are different, but for a gcc based toolchain we need to play nice with >> gcc's internal assumptions. >> >> Regards, >> Kai > > On closer look for long double, we can have rouding issues for long > double precission. I see that powl (0.01L, 0.5L) we have a rounding > difference to sqrtl (0.01L). Interestingly not for float or double > types. So we we might need to specialcase in pow the case for y == > 0.5 to solve this. Be, however, cognizant of Greg's concern. Forcing pow to agree with sqrt just for y = 0.5 has the potential to make pow, in a sense, internally inconsistent, It's a tricky tradeoff. (Ideally, both pow and sqrt would be "exact" and therefore agree with one another automatically.) By the way, I also see a problem with runtime powl for powl (2.2L, 0.5L). It disagrees slightly from sqrtl (2.2L) and from the compiletime value for powl (2.2L, 0.5L). I modified your test program to compare sqrt with pow (x, 0.5) (and sqrtl with powl). For the record: C:\>gcc version gcc (GCC) 4.5.2 20101002 (prerelease) [svn/rev.164902  mingww64/oz] C:\>gcc o sqrt_pow sqrt_pow.c C:\>sqrt_pow 1.04880884817015163080, 1.04880884817015163080, 0.00000000000000000000 1.48323969741913264109, 1.48323969741913264109, 0.00000000000000000000 1.81659021245849494619, 1.81659021245849494619, 0.00000000000000000000 1.04880884817015163080 1.04880884817015163080 1.48323969741913264109 1.48323969741913264109 1.81659021245849494619 1.81659021245849494619 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 1.04880884817015154699, 1.04880884817015154699, 0.00000000000000000000 1.48323969741913258980, 1.48323969741913258970, 0.00000000000000000011 1.81659021245849499921, 1.81659021245849499921, 0.00000000000000000000 1.04880884817015154699 1.04880884817015154699 1.48323969741913258980 1.48323969741913258980 1.81659021245849499921 1.81659021245849499921 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 0.00000000000000000000 0.00000000000000000011 0.00000000000000000000 where sqrt_pow.c is: #include <stdio.h> #include <math.h> double abc[3] = { 1.1, 2.2, 3.3 }; long double abcl[3] = { 1.1L, 2.2L, 3.3L }; int main() { double r1[3], r2[3], r3[3]; long double rl1[3], rl2[3], rl3[3]; int i; for (i = 0; i < 3; i++) __mingw_printf ("%.20F, %.20F, %.20F\n", (r1[i] = sqrt (abc[i])), (r2[i] = pow (abc[i], 0.5)), (r3[i] = pow (abc[i], 0.5)  sqrt (abc[i]))); __mingw_printf ("%.20F %.20F\n", sqrt (1.1), pow (1.1, 0.5)); __mingw_printf ("%.20F %.20F\n", sqrt (2.2), pow (2.2, 0.5)); __mingw_printf ("%.20F %.20F\n", sqrt (3.3), pow (3.3, 0.5)); r1[0] = sqrt (1.1); r1[1] = sqrt (2.2); r1[2] = sqrt (3.3); __mingw_printf ("%.20F %.20F %.20F\n", r1[0], r1[1], r1[2]); r2[0] = pow (1.1, 0.5); r2[1] = pow (2.2, 0.5); r2[2] = pow (3.3, 0.5); __mingw_printf ("%.20F %.20F %.20F\n", r2[0], r2[1], r2[2]); for (i = 0; i < 3; i++) __mingw_printf ("%.20LF, %.20LF, %.20LF\n", (rl1[i] = sqrtl (abcl[i])), (rl2[i] = powl (abcl[i], 0.5L)), (rl3[i] = powl (abcl[i], 0.5L)  sqrtl (abcl[i]))); __mingw_printf ("%.20LF %.20LF\n", sqrtl (1.1L), powl (1.1L, 0.5L)); __mingw_printf ("%.20LF %.20LF\n", sqrtl (2.2L), powl (2.2L, 0.5L)); __mingw_printf ("%.20LF %.20LF\n", sqrtl (3.3L), powl (3.3L, 0.5L)); rl1[0] = sqrtl (1.1L); rl1[1] = sqrtl (2.2L); rl1[2] = sqrtl (3.3L); __mingw_printf ("%.20LF %.20LF %.20LF\n", rl1[0], rl1[1], rl1[2]); rl2[0] = powl (1.1L, 0.5L); rl2[1] = powl (2.2L, 0.5L); rl2[2] = powl (3.3L, 0.5L); __mingw_printf ("%.20LF %.20LF %.20LF\n", rl2[0], rl2[1], rl2[2]); return 1; } > > Kai Thanks, Kai, for your insight and explanations. K. Frank 
From: James K Beard <beardjamesk@ve...>  20110430 13:36:33

My comments don't seem to be making it into the thread this week, possibly because of a switch between my replyto email address and another. So, if it gets lost, perhaps nightstrike can intervene, or echo the information. Perhaps not. The sqrt() function can be implemented with excellent speed to within a bit of full mantissa accuracy using iterations of Newton's method, as is classically done in libraries. Not so with ln() or exp(), which are classically done by extracting the exponent and using the reducedrange mantissa in a modified Chebychev approximation. Arithmetic coprocessors do sqrt(), ln(), and exp() internally with 80bit floating point, then store in 32, 64, or 80 bit floating point format. So, the coprocessors can get full mantissa accuracy with 32bit and 64bit sqrt() and pow(x,0.5). So, the problem is nonexistent for Intel/PPC and most other common workstation processors. Yet we are looking at software transcendental function libraries. James K Beard Original Message From: Greg Chicares [mailto:gchicares@...] Sent: Friday, April 29, 2011 7:38 PM To: MinGW Users List Cc: mingw64 Subject: Re: [Mingww64public] [Mingwusers] Math library discrepancies that surprised me. On 20110429 19:55Z, K. Frank wrote: > > By the way, could someone confirm that mingw does use msvcrt for > sqrt and pow? http://cygwin.com/cgibin/cvsweb.cgi/src/winsup/mingw/mingwex/math/?cvsroot= src Looks to me like sqrt(double) calls into msvcrt. But pow() is a different story. Danny implemented it in libmingwex because of some qualityofimplementation problem with msvcrt; then people complained that the libmingwex version was slower, and I can't remember where it wound up, but it's all in the archives. > sqrt (x) and pow (x, 0.5) ought to give the same result (even if not required > to by IEEE754). If they should give exactly the same result always, then the first thing that needs to be fixed is any standard that allows them to differ. The language standards are so much looser than the numerical standard, even now, that I'd rather see C and C++ catch up to IEEE7541985 before asking them to go beyond. > Browsing some gcc lists, I did see some comments that suggest that > gcc (on linux) does try to transform pow (x, 0.5) to sqrt (x). This would > make sqrt and pow consistent (whether or not technically correct). Not so many years ago (perhaps when msvcrt was written), it was thought that correctlyrounded transcendental functions weren't feasible in practice, so library authors had a looser attitude toward exactness. If you have an ideal implementation of sqrt() but a pow() that's only approximate, should you specialcase the power of exactly 0.5? If you do, then pow() and sqrt() will be consistent, but then the powers x^(0.5*(1epsilon)) x^(0.5 ) x^(0.5*(1+epsilon)) might not be monotone. Some would call that a bad tradeoff.   WhatsUp Gold  Download Free Network Management Software The most intuitive, comprehensive, and costeffective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgoldsd _______________________________________________ Mingww64public mailing list Mingww64public@... https://lists.sourceforge.net/lists/listinfo/mingww64public 
From: Kai Tietz <ktietz70@go...>  20110430 09:51:39

2011/4/30 Kai Tietz <ktietz70@...>: > 2011/4/30 Greg Chicares <gchicares@...>: >> On 20110429 19:55Z, K. Frank wrote: >>> >>> By the way, could someone confirm that mingw does use msvcrt for >>> sqrt and pow? >> >> http://cygwin.com/cgibin/cvsweb.cgi/src/winsup/mingw/mingwex/math/?cvsroot=src >> >> Looks to me like sqrt(double) calls into msvcrt. But pow() is a >> different story. Danny implemented it in libmingwex because of >> some qualityofimplementation problem with msvcrt; then people >> complained that the libmingwex version was slower, and I can't >> remember where it wound up, but it's all in the archives. >> >>> sqrt (x) and pow (x, 0.5) ought to give the same result (even if not required >>> to by IEEE754). >> >> If they should give exactly the same result always, then the >> first thing that needs to be fixed is any standard that allows >> them to differ. The language standards are so much looser than >> the numerical standard, even now, that I'd rather see C and C++ >> catch up to IEEE7541985 before asking them to go beyond. >> >>> Browsing some gcc lists, I did see some comments that suggest that >>> gcc (on linux) does try to transform pow (x, 0.5) to sqrt (x). This would >>> make sqrt and pow consistent (whether or not technically correct). >> >> Not so many years ago (perhaps when msvcrt was written), it was >> thought that correctlyrounded transcendental functions weren't >> feasible in practice, so library authors had a looser attitude >> toward exactness. If you have an ideal implementation of sqrt() >> but a pow() that's only approximate, should you specialcase >> the power of exactly 0.5? If you do, then pow() and sqrt() will >> be consistent, but then the powers >> x^(0.5*(1epsilon)) >> x^(0.5 ) >> x^(0.5*(1+epsilon)) >> might not be monotone. Some would call that a bad tradeoff. > > Well, I spent some efforts into log, exp, and pow implementation. Also > some other basemath functions I improved in mingww64's math library > in two terms. a) Make those functions behave as ISOC99 specification > tells in cornercases. and b) Improve accuracy in terms of gcc's > internal used gmp. As we noticed here result differences. > > The following example illustrates the issues pretty well: > > #include <stdio.h> > #include <math.h> > > double abc[3][2] = { { 2.2, 3.1 }, { 2.0, 3.0 }, { 4.0, 0.5 } }; > long double ab[3][2] = { { 2.2L, 3.1L }, { 2.0L, 3.0L }, { 4.0L, 0.5L } }; > int main() > { > double r[3]; > long double rl[3]; > int i; > for (i = 0; i < 3; i++) > __mingw_printf ("%.20F^%.20F = %.20F\n", abc[i][0], abc[i][1], > (r[i] = pow (abc[i][0], abc[i][1]))); > __mingw_printf ("%.20F %.20F %.20F\n", pow (2.2, 3.1), pow (2.0, > 3.0), pow (4.0, 0.5)); > r[0] = pow (2.2, 3.1); > r[1] = pow (2.0, 3.0); > r[2] = pow (4.0, 0.5); > __mingw_printf ("%.20F %.20F %.20F\n", r[0], r[1], r[2]); > > for (i = 0; i < 3; i++) > __mingw_printf ("%.20LF^%.20LF = %.20LF\n", ab[i][0], ab[i][1], > (rl[i] = powl (ab[i][0], ab[i][1]))); > __mingw_printf ("%.20LF %.20LF %.20LF\n", > powl (2.2L, 3.1L), powl (2.0L, 3.0L) , powl > (4.0L, 0.5L)); > rl[0] = powl (2.2L, 3.1L); > rl[1] = powl (2.0L, 3.0L); > rl[2] = powl (4.0L, 0.5L); > __mingw_printf ("%.20LF %.20LF %.20LF\n", rl[0], rl[1], rl[2]); > return 1; > } > > The interesting issue is here that gcc uses for constant > mathcalculations gmplibrary to get result. For more complex > variants, it uses crt's math. By this it is important for a gcc based > runtime to be in the IEEE 754 floating point compatible to gmp's > results. > > Btw new pow, log, and exp variant are slightly faster then variant in > msvcrt, but this is more or less just a sideeffect. > > I admit that this might be not that obvious to users, why results here > are different, but for a gcc based toolchain we need to play nice with > gcc's internal assumptions. > > Regards, > Kai > On closer look for long double, we can have rouding issues for long double precission. I see that powl (0.01L, 0.5L) we have a rounding difference to sqrtl (0.01L). Interestingly not for float or double types. So we we might need to specialcase in pow the case for y == 0.5 to solve this. Kai 
From: Kai Tietz <ktietz70@go...>  20110430 08:42:15

2011/4/30 Greg Chicares <gchicares@...>: > On 20110429 19:55Z, K. Frank wrote: >> >> By the way, could someone confirm that mingw does use msvcrt for >> sqrt and pow? > > http://cygwin.com/cgibin/cvsweb.cgi/src/winsup/mingw/mingwex/math/?cvsroot=src > > Looks to me like sqrt(double) calls into msvcrt. But pow() is a > different story. Danny implemented it in libmingwex because of > some qualityofimplementation problem with msvcrt; then people > complained that the libmingwex version was slower, and I can't > remember where it wound up, but it's all in the archives. > >> sqrt (x) and pow (x, 0.5) ought to give the same result (even if not required >> to by IEEE754). > > If they should give exactly the same result always, then the > first thing that needs to be fixed is any standard that allows > them to differ. The language standards are so much looser than > the numerical standard, even now, that I'd rather see C and C++ > catch up to IEEE7541985 before asking them to go beyond. > >> Browsing some gcc lists, I did see some comments that suggest that >> gcc (on linux) does try to transform pow (x, 0.5) to sqrt (x). This would >> make sqrt and pow consistent (whether or not technically correct). > > Not so many years ago (perhaps when msvcrt was written), it was > thought that correctlyrounded transcendental functions weren't > feasible in practice, so library authors had a looser attitude > toward exactness. If you have an ideal implementation of sqrt() > but a pow() that's only approximate, should you specialcase > the power of exactly 0.5? If you do, then pow() and sqrt() will > be consistent, but then the powers > x^(0.5*(1epsilon)) > x^(0.5 ) > x^(0.5*(1+epsilon)) > might not be monotone. Some would call that a bad tradeoff. Well, I spent some efforts into log, exp, and pow implementation. Also some other basemath functions I improved in mingww64's math library in two terms. a) Make those functions behave as ISOC99 specification tells in cornercases. and b) Improve accuracy in terms of gcc's internal used gmp. As we noticed here result differences. The following example illustrates the issues pretty well: #include <stdio.h> #include <math.h> double abc[3][2] = { { 2.2, 3.1 }, { 2.0, 3.0 }, { 4.0, 0.5 } }; long double ab[3][2] = { { 2.2L, 3.1L }, { 2.0L, 3.0L }, { 4.0L, 0.5L } }; int main() { double r[3]; long double rl[3]; int i; for (i = 0; i < 3; i++) __mingw_printf ("%.20F^%.20F = %.20F\n", abc[i][0], abc[i][1], (r[i] = pow (abc[i][0], abc[i][1]))); __mingw_printf ("%.20F %.20F %.20F\n", pow (2.2, 3.1), pow (2.0, 3.0), pow (4.0, 0.5)); r[0] = pow (2.2, 3.1); r[1] = pow (2.0, 3.0); r[2] = pow (4.0, 0.5); __mingw_printf ("%.20F %.20F %.20F\n", r[0], r[1], r[2]); for (i = 0; i < 3; i++) __mingw_printf ("%.20LF^%.20LF = %.20LF\n", ab[i][0], ab[i][1], (rl[i] = powl (ab[i][0], ab[i][1]))); __mingw_printf ("%.20LF %.20LF %.20LF\n", powl (2.2L, 3.1L), powl (2.0L, 3.0L) , powl (4.0L, 0.5L)); rl[0] = powl (2.2L, 3.1L); rl[1] = powl (2.0L, 3.0L); rl[2] = powl (4.0L, 0.5L); __mingw_printf ("%.20LF %.20LF %.20LF\n", rl[0], rl[1], rl[2]); return 1; } The interesting issue is here that gcc uses for constant mathcalculations gmplibrary to get result. For more complex variants, it uses crt's math. By this it is important for a gcc based runtime to be in the IEEE 754 floating point compatible to gmp's results. Btw new pow, log, and exp variant are slightly faster then variant in msvcrt, but this is more or less just a sideeffect. I admit that this might be not that obvious to users, why results here are different, but for a gcc based toolchain we need to play nice with gcc's internal assumptions. Regards, Kai 
From: James K Beard <beardjamesk@ve...>  20110430 01:38:21

The standard process for computation of sqrt(x) has been the use of Newton's method. This means that an approximation to SQRT(x) is found by whatever means (but important to get good accuracy) and the iteration result = (result_old^2+x)/(2*result_old) Repeated until result = result_old. A check for equality isn't necessary because a maximum iteration count can be obtained from the worstcase accuracy of the initial approximation. Thus there isn't any reason that the libraries should vary in their results. A bit or so may result from the nonalgebraicallyreduced form of the iteration, result = result_old + (x  result_old^2)/(2*result_old) which some of little faith use because the second term can be tested for zero  or near zero. Don't go there. This form is less accurate than the shorter form. All this works for complex numbers, too. Watch out for the sign convention for complex numbers, though. Regarding the log and exponentiation algorithm approach, x^a = exp(a*log(x)), you have rounding error in two operations, as well as inherent accuracy limits, meaning that if you don't have a few guard bits you aren't going to get full mantissa accuracy. The Newton's method will get you within a count or two on the LSB, and with any guard bits at all will get you full mantissa accuracy every time. Why? K digits/bits/whatever in X define about 2K digits/bits/whatever in sqrt(x), while this isn't true for log(*) and exp(*). James K Beard Original Message From: K. Frank [mailto:kfrank29.c@...] Sent: Friday, April 29, 2011 8:51 PM To: mingw64; MinGW Users List Subject: Re: [Mingww64public] [Mingwusers] Math library discrepancies that surprised me. Hi Greg! On Fri, Apr 29, 2011 at 7:38 PM, Greg Chicares <gchicares@...> wrote: > On 20110429 19:55Z, K. Frank wrote: >> >> By the way, could someone confirm that mingw does use msvcrt for >> sqrt and pow? > > http://cygwin.com/cgibin/cvsweb.cgi/src/winsup/mingw/mingwex/math/?cvsroot= src > > Looks to me like sqrt(double) calls into msvcrt. But pow() is a > different story. Danny implemented it in libmingwex because of > some qualityofimplementation problem with msvcrt; then people > complained that the libmingwex version was slower, and I can't > remember where it wound up, but it's all in the archives. Thanks for that  good to know. From the source link you gave: http://cygwin.com/cgibin/cvsweb.cgi/src/winsup/mingw/mingwex/math/pow.c?ann otate=1.1.10.1&cvsroot=src the code for pow (the regular double pow (double, double)) has these comments about accuracy. 28: * ACCURACY: 29: * 30: * Relative error: 31: * arithmetic domain # trials peak rms 32: * IEEE 26,26 30000 4.2e16 7.7e17 33: * DEC 26,26 60000 4.8e17 9.1e18 34: * 1/26 < x < 26, with log(x) uniformly distributed. 35: * 26 < y < 26, y uniformly distributed. 36: * IEEE 0,8700 30000 1.5e14 2.1e15 37: * 0.99 < x < 1.01, 0 < y < 8700, uniformly distributed. This commentary suggest that pow is not "exact." This would reasonably explain Arthur seeing pow not match sqrt. But it still leaves the puzzle of why the different mingw versions don't behave the same. One minor puzzle: I don't see anything in the pow code that would let the compiler / library take advantage of hardware support for pow, which I think has been available in the x86 architecture for quite some time now. > >> sqrt (x) and pow (x, 0.5) ought to give the same result (even if not required >> to by IEEE754). > > If they should give exactly the same result always, then the > first thing that needs to be fixed is any standard that allows > them to differ. Well, it's a question of engineering compromise whether they should always agree. In an ideal world, it would be nice if pow were "exact" (in the sense of closet floatingpoint number). Then if pow were "exact," pow and sqrt should agree. But there is expense in getting pow to be "exact," so it's arguable that the language / IEEE standards should give implementers some flexibility. (And, as you point out below, if pow isn't exact, then forcing pow and sqrt to agree could actually cause other problems.) > The language standards are so much looser than > the numerical standard, even now, that I'd rather see C and C++ > catch up to IEEE7541985 before asking them to go beyond. > >> Browsing some gcc lists, I did see some comments that suggest that >> gcc (on linux) does try to transform pow (x, 0.5) to sqrt (x). This would >> make sqrt and pow consistent (whether or not technically correct). > > Not so many years ago (perhaps when msvcrt was written), it was > thought that correctlyrounded transcendental functions weren't > feasible in practice, so library authors had a looser attitude > toward exactness. If you have an ideal implementation of sqrt() > but a pow() that's only approximate, should you specialcase > the power of exactly 0.5? If you do, then pow() and sqrt() will > be consistent, but then the powers > x^(0.5*(1epsilon)) > x^(0.5 ) > x^(0.5*(1+epsilon)) > might not be monotone. Some would call that a bad tradeoff. I actually agree with your concern. The transformation of pow (x, 0.5) to sqrt (x) that it sounded like gcc / linux was doing sounds like a bad idea if it's being done this simply and naively. Any speculation on why Arthur gets different results with different mingw's? Thanks for your perspective. K. Frank   WhatsUp Gold  Download Free Network Management Software The most intuitive, comprehensive, and costeffective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgoldsd _______________________________________________ Mingww64public mailing list Mingww64public@... https://lists.sourceforge.net/lists/listinfo/mingww64public 
From: K. Frank <kfrank29.c@gm...>  20110430 00:51:07

Hi Greg! On Fri, Apr 29, 2011 at 7:38 PM, Greg Chicares <gchicares@...> wrote: > On 20110429 19:55Z, K. Frank wrote: >> >> By the way, could someone confirm that mingw does use msvcrt for >> sqrt and pow? > > http://cygwin.com/cgibin/cvsweb.cgi/src/winsup/mingw/mingwex/math/?cvsroot=src > > Looks to me like sqrt(double) calls into msvcrt. But pow() is a > different story. Danny implemented it in libmingwex because of > some qualityofimplementation problem with msvcrt; then people > complained that the libmingwex version was slower, and I can't > remember where it wound up, but it's all in the archives. Thanks for that  good to know. From the source link you gave: http://cygwin.com/cgibin/cvsweb.cgi/src/winsup/mingw/mingwex/math/pow.c?annotate=1.1.10.1&cvsroot=src the code for pow (the regular double pow (double, double)) has these comments about accuracy. 28: * ACCURACY: 29: * 30: * Relative error: 31: * arithmetic domain # trials peak rms 32: * IEEE 26,26 30000 4.2e16 7.7e17 33: * DEC 26,26 60000 4.8e17 9.1e18 34: * 1/26 < x < 26, with log(x) uniformly distributed. 35: * 26 < y < 26, y uniformly distributed. 36: * IEEE 0,8700 30000 1.5e14 2.1e15 37: * 0.99 < x < 1.01, 0 < y < 8700, uniformly distributed. This commentary suggest that pow is not "exact." This would reasonably explain Arthur seeing pow not match sqrt. But it still leaves the puzzle of why the different mingw versions don't behave the same. One minor puzzle: I don't see anything in the pow code that would let the compiler / library take advantage of hardware support for pow, which I think has been available in the x86 architecture for quite some time now. > >> sqrt (x) and pow (x, 0.5) ought to give the same result (even if not required >> to by IEEE754). > > If they should give exactly the same result always, then the > first thing that needs to be fixed is any standard that allows > them to differ. Well, it's a question of engineering compromise whether they should always agree. In an ideal world, it would be nice if pow were "exact" (in the sense of closet floatingpoint number). Then if pow were "exact," pow and sqrt should agree. But there is expense in getting pow to be "exact," so it's arguable that the language / IEEE standards should give implementers some flexibility. (And, as you point out below, if pow isn't exact, then forcing pow and sqrt to agree could actually cause other problems.) > The language standards are so much looser than > the numerical standard, even now, that I'd rather see C and C++ > catch up to IEEE7541985 before asking them to go beyond. > >> Browsing some gcc lists, I did see some comments that suggest that >> gcc (on linux) does try to transform pow (x, 0.5) to sqrt (x). This would >> make sqrt and pow consistent (whether or not technically correct). > > Not so many years ago (perhaps when msvcrt was written), it was > thought that correctlyrounded transcendental functions weren't > feasible in practice, so library authors had a looser attitude > toward exactness. If you have an ideal implementation of sqrt() > but a pow() that's only approximate, should you specialcase > the power of exactly 0.5? If you do, then pow() and sqrt() will > be consistent, but then the powers > x^(0.5*(1epsilon)) > x^(0.5 ) > x^(0.5*(1+epsilon)) > might not be monotone. Some would call that a bad tradeoff. I actually agree with your concern. The transformation of pow (x, 0.5) to sqrt (x) that it sounded like gcc / linux was doing sounds like a bad idea if it's being done this simply and naively. Any speculation on why Arthur gets different results with different mingw's? Thanks for your perspective. K. Frank 
From: Greg Chicares <gchicares@sb...>  20110429 23:38:10

On 20110429 19:55Z, K. Frank wrote: > > By the way, could someone confirm that mingw does use msvcrt for > sqrt and pow? http://cygwin.com/cgibin/cvsweb.cgi/src/winsup/mingw/mingwex/math/?cvsroot=src Looks to me like sqrt(double) calls into msvcrt. But pow() is a different story. Danny implemented it in libmingwex because of some qualityofimplementation problem with msvcrt; then people complained that the libmingwex version was slower, and I can't remember where it wound up, but it's all in the archives. > sqrt (x) and pow (x, 0.5) ought to give the same result (even if not required > to by IEEE754). If they should give exactly the same result always, then the first thing that needs to be fixed is any standard that allows them to differ. The language standards are so much looser than the numerical standard, even now, that I'd rather see C and C++ catch up to IEEE7541985 before asking them to go beyond. > Browsing some gcc lists, I did see some comments that suggest that > gcc (on linux) does try to transform pow (x, 0.5) to sqrt (x). This would > make sqrt and pow consistent (whether or not technically correct). Not so many years ago (perhaps when msvcrt was written), it was thought that correctlyrounded transcendental functions weren't feasible in practice, so library authors had a looser attitude toward exactness. If you have an ideal implementation of sqrt() but a pow() that's only approximate, should you specialcase the power of exactly 0.5? If you do, then pow() and sqrt() will be consistent, but then the powers x^(0.5*(1epsilon)) x^(0.5 ) x^(0.5*(1+epsilon)) might not be monotone. Some would call that a bad tradeoff. 
From: James K Beard <beardjamesk@ve...>  20110429 21:58:10

The standard process for computation of sqrt(x) has been the use of Newton's method. This means that an approximation to SQRT(x) is found by whatever means and the iteration result = (result_old^2+x)/(2*result_old) Repeated until result = result_old. A check isn't necessary because a maximum iteration count can be obtained from the worstcase accuracy of the initial approximation. Thus there isn't any reason that the librarys should vary in their results. A bit or so may result from the nonalgebraicallyreduced form of the iteration, result = result_old + (x  result_old^2)/(2*result_old) which some of little faith use because the second term can be tested for zero  or near zero. Don't go there. In any case this nonreduced form is less accurate. All this works for complex numbers, too. Watch out for the sign convention for complex numbers, though. James K Beard Original Message From: K. Frank [mailto:kfrank29.c@...] Sent: Friday, April 29, 2011 3:56 PM To: mingw64; MinGW Users List Subject: Re: [Mingww64public] Math library discrepancies that surprised me. Hello Arthur! (I've take the liberty of copying this to the mingw list, as well.) On Fri, Apr 29, 2011 at 9:54 AM, Arthur Norman wrote: > The following short program compares the value of pow(x, 0.5) to that > returned by sqrt(x) for a range of values of x, and prints out any first > case where the two do not agree. Well, this is unfortunate. Ideally they should, and as a qualityofimplementation issue, I think we should be able to expect them to agree. > With the mingw family of compilers I had > expected the Microsoft C library to be in use. > > What I appear to see is > linux (ubuntu 11.04 64bit tested) no output > Mac (snow leopard) no output > gcc (cygwin) no output > gcc3 mnocygwin ) > i686w64mingw32gcc ) all different from each other > x86_64w64mingw32gcc ) but all find discrepancies. Very interesting. > It is a totally fair cop if the Microsoft C library gives different > results in the last bit for floating point elementary functions to gnu > libraries, Well, from the mingw perspective, if the microsoft runtime library is flawed in this way, then it's a legitimate cop for mingw not to fix it. By the way, could someone confirm that mingw does use msvcrt for sqrt and pow? > but is there an obvious reason why the three mingw varients > all give different answers. If I understand your point correctly, if the problem is with msvcrt, then the three mingw variants should all give the same flawed results. > This showed up in regression testing something > much larger across platforms. > > Arthur > ... As I understand it, IEEE754 compliance requires sqrt to be calculated "correctly", i.e., to return the floatingpoint number closest to the exact mathematical value. (The c++ standard, I believe, does not, however, require IEEE754 compliance.) I think, however, the IEEE754 does not require all mathematical functions, and, in particular, pow, to be "correct," in the above sense sense. It would be interesting to print out in binary (or hex) the results for a few of the values that lead to discrepancies with both mingw and a linuxbased gcc, and see whether the problem is in sqrt (for which IEEE754 specifies the result) or in pow (for which I think IEEE754 permits some leeway). In my opinion: mingw / msvcrt should be IEEE754 compliant. Of course, if msvcrt isn't, then it's not mingw's fault. sqrt (x) and pow (x, 0.5) ought to give the same result (even if not required to by IEEE754). Browsing some gcc lists, I did see some comments that suggest that gcc (on linux) does try to transform pow (x, 0.5) to sqrt (x). This would make sqrt and pow consistent (whether or not technically correct). Maybe gcc / linux pow and msvcrt pow are both not quite exact, but this is hidden in your test, because gcc / linux replaces pow (x, 0.5) with sqrt (x), and msvcrt doesn't. (Just speculation.) It is odd, however, that the various mingw's don't agree, and this speaks to a possible bug in mingw. Thanks. K. Frank > ... > ==================== > #include <stdio.h> > #include <math.h> > > int main(int argc, char *argv[]) > { > double a, b, c; > int i; > for (i=0, a=1.0; i<10000000; i++) > { a *= 1.00000001; > b = sqrt(a); c = pow(a, 0.5); > if (b == c) continue; > printf("%.17g %.17g %.17g\n", a, b, c); > return 0; > } > return 0; > } > ==================== > > acn1@... temp > $ gcc expt.c o expt > acn1@... temp > $ ./expt > acn1@... temp > $ gcc3 mnocygwin expt.c o expt > acn1@... temp > $ ./expt > 1.0241210164238141 1.011988644414459 1.0119886444144588 > acn1@... temp > $ i686w64mingw32gcc expt.c o expt > acn1@... temp > $ ./expt > 1.0004603659307831 1.000230156479389 1.0002301564793892 > acn1@... temp > $ x86_64w64mingw32gcc expt.c o expt > acn1@... temp > $ ./expt > 1.0000179101601867 1.0000089550399969 1.0000089550399971 > acn1@... temp > ==============================================================   WhatsUp Gold  Download Free Network Management Software The most intuitive, comprehensive, and costeffective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgoldsd _______________________________________________ Mingww64public mailing list Mingww64public@... https://lists.sourceforge.net/lists/listinfo/mingww64public 
From: Ozkan Sezer <sezeroz@gm...>  20110429 21:13:24

On Fri, Apr 29, 2011 at 11:28 PM, kmx <kmx@...> wrote: > Ozkan, > > after slightly heated *.ladiscussion Meh, that's no problem. The problem is I keep forgetting to update my scripts, maybe I remember doing that next time if I happen to post another build > I just want you to know that I like > your personal builds. > > Thank you for you time and hard work. Please keep up and do not get > discouraged. > >  > kmx Thanks.  O.S. 
From: kmx <kmx@at...>  20110429 20:50:07

Ozkan, after slightly heated *.ladiscussion I just want you to know that I like your personal builds. Thank you for you time and hard work. Please keep up and do not get discouraged.  kmx 
From: Ruben Van Boxem <vanboxem.ruben@gm...>  20110429 20:34:23

2011/4/29 Vincent Torri <vincent.torri@...> > > > On Fri, Apr 29, 2011 at 10:22 PM, Ruben Van Boxem < > vanboxem.ruben@...> wrote: > >> Hi, >> >> Instead of hijacking Ozkan's "thread", I will start a new one! >> >> Some strange things in the autobuilds: >> 1. Stripping all exe's (including the ones in the libexec subdirectories) >> in the autobuild reduces total package size with a factor of 1/2... Seems >> like upload/download time and bandwith usage for everyone could be reduced >> significantly very easily. I have said this before. >> 2. There is a x86_64w64mingw32/lib32 directory full of 32bit mingww64 >> crt libraries, but the gcc itself is configured with "disablemultilib", >> making these completely useless. Either GCC should be buillt with multilib >> support (which would be the best), or the lib32 part shouldn't be built, >> shaves another five minutes off the build time. Is the multilib dll install >> fiasco still unsolved? (I must remember to keep following Clang and see if >> it works all right with mingww64!) >> 3. /include is empty? Why are the C++ headers in the x86_64w64mingw32 >> directory? Is this something new in GCC 4.7 or a bug in the build/install >> process? >> > 4. compiling with 'std=c++0x flto main.cpp o test.exe' makes ld.exe crash with error code 5: > #include <iostream> > #include <set> > > using namespace std; > > int main() > { > set<char> s = { ':', '(' }; > > if( s.find(':') != s.end() ) > cout << "colon checks out.\n"; > > return 0; > } > This is with mingww64bini686mingw_20110429.zip. 5. I have a static library that has various output functionality to std::cerr (=C's STDERR) that was outputting all my debug info in my program (which linked the static library), and now it doesn't anymore. Any ideas? I previously used sezero's 4.5 personal build. Different libraries linked or different default options? Thanks, again, Ruben > > i remarked that there are some differences between some packages: > > mingww64bin_i686linux_20110422.tar.bz2 > mingww641.0bin_i686linux_20110422.tar.bz2 > > do not have the same headers. I don't know the differences between them, > but it seems that the first one has some improvements compared to the second > one (declaration of functions that are only available on Vista and above for > example). > > Vincent Torri > > >> >> Mind you: I appreciate all the work put into these things, I just feel the >> quality can be *easily* improved, making mingww64 *a lot* better. >> >> Thanks! >> >> Ruben >> >> >>  >> WhatsUp Gold  Download Free Network Management Software >> The most intuitive, comprehensive, and costeffective network >> management toolset available today. Delivers lowest initial >> acquisition cost and overall TCO of any competing solution. >> http://p.sf.net/sfu/whatsupgoldsd >> _______________________________________________ >> Mingww64public mailing list >> Mingww64public@... >> https://lists.sourceforge.net/lists/listinfo/mingww64public >> >> > > >  > WhatsUp Gold  Download Free Network Management Software > The most intuitive, comprehensive, and costeffective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgoldsd > _______________________________________________ > Mingww64public mailing list > Mingww64public@... > https://lists.sourceforge.net/lists/listinfo/mingww64public > > 
From: Vincent Torri <vincent.torri@gm...>  20110429 20:28:54

On Fri, Apr 29, 2011 at 10:22 PM, Ruben Van Boxem <vanboxem.ruben@...>wrote: > Hi, > > Instead of hijacking Ozkan's "thread", I will start a new one! > > Some strange things in the autobuilds: > 1. Stripping all exe's (including the ones in the libexec subdirectories) > in the autobuild reduces total package size with a factor of 1/2... Seems > like upload/download time and bandwith usage for everyone could be reduced > significantly very easily. I have said this before. > 2. There is a x86_64w64mingw32/lib32 directory full of 32bit mingww64 > crt libraries, but the gcc itself is configured with "disablemultilib", > making these completely useless. Either GCC should be buillt with multilib > support (which would be the best), or the lib32 part shouldn't be built, > shaves another five minutes off the build time. Is the multilib dll install > fiasco still unsolved? (I must remember to keep following Clang and see if > it works all right with mingww64!) > 3. /include is empty? Why are the C++ headers in the x86_64w64mingw32 > directory? Is this something new in GCC 4.7 or a bug in the build/install > process? > i remarked that there are some differences between some packages: mingww64bin_i686linux_20110422.tar.bz2 mingww641.0bin_i686linux_20110422.tar.bz2 do not have the same headers. I don't know the differences between them, but it seems that the first one has some improvements compared to the second one (declaration of functions that are only available on Vista and above for example). Vincent Torri > > Mind you: I appreciate all the work put into these things, I just feel the > quality can be *easily* improved, making mingww64 *a lot* better. > > Thanks! > > Ruben > > >  > WhatsUp Gold  Download Free Network Management Software > The most intuitive, comprehensive, and costeffective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgoldsd > _______________________________________________ > Mingww64public mailing list > Mingww64public@... > https://lists.sourceforge.net/lists/listinfo/mingww64public > > 
From: Ruben Van Boxem <vanboxem.ruben@gm...>  20110429 20:22:42

Hi, Instead of hijacking Ozkan's "thread", I will start a new one! Some strange things in the autobuilds: 1. Stripping all exe's (including the ones in the libexec subdirectories) in the autobuild reduces total package size with a factor of 1/2... Seems like upload/download time and bandwith usage for everyone could be reduced significantly very easily. I have said this before. 2. There is a x86_64w64mingw32/lib32 directory full of 32bit mingww64 crt libraries, but the gcc itself is configured with "disablemultilib", making these completely useless. Either GCC should be buillt with multilib support (which would be the best), or the lib32 part shouldn't be built, shaves another five minutes off the build time. Is the multilib dll install fiasco still unsolved? (I must remember to keep following Clang and see if it works all right with mingww64!) 3. /include is empty? Why are the C++ headers in the x86_64w64mingw32 directory? Is this something new in GCC 4.7 or a bug in the build/install process? Mind you: I appreciate all the work put into these things, I just feel the quality can be *easily* improved, making mingww64 *a lot* better. Thanks! Ruben 
From: K. Frank <kfrank29.c@gm...>  20110429 19:56:00

Hello Arthur! (I've take the liberty of copying this to the mingw list, as well.) On Fri, Apr 29, 2011 at 9:54 AM, Arthur Norman wrote: > The following short program compares the value of pow(x, 0.5) to that > returned by sqrt(x) for a range of values of x, and prints out any first > case where the two do not agree. Well, this is unfortunate. Ideally they should, and as a qualityofimplementation issue, I think we should be able to expect them to agree. > With the mingw family of compilers I had > expected the Microsoft C library to be in use. > > What I appear to see is > linux (ubuntu 11.04 64bit tested) no output > Mac (snow leopard) no output > gcc (cygwin) no output > gcc3 mnocygwin ) > i686w64mingw32gcc ) all different from each other > x86_64w64mingw32gcc ) but all find discrepancies. Very interesting. > It is a totally fair cop if the Microsoft C library gives different > results in the last bit for floating point elementary functions to gnu > libraries, Well, from the mingw perspective, if the microsoft runtime library is flawed in this way, then it's a legitimate cop for mingw not to fix it. By the way, could someone confirm that mingw does use msvcrt for sqrt and pow? > but is there an obvious reason why the three mingw varients > all give different answers. If I understand your point correctly, if the problem is with msvcrt, then the three mingw variants should all give the same flawed results. > This showed up in regression testing something > much larger across platforms. > > Arthur > ... As I understand it, IEEE754 compliance requires sqrt to be calculated "correctly", i.e., to return the floatingpoint number closest to the exact mathematical value. (The c++ standard, I believe, does not, however, require IEEE754 compliance.) I think, however, the IEEE754 does not require all mathematical functions, and, in particular, pow, to be "correct," in the above sense sense. It would be interesting to print out in binary (or hex) the results for a few of the values that lead to discrepancies with both mingw and a linuxbased gcc, and see whether the problem is in sqrt (for which IEEE754 specifies the result) or in pow (for which I think IEEE754 permits some leeway). In my opinion: mingw / msvcrt should be IEEE754 compliant. Of course, if msvcrt isn't, then it's not mingw's fault. sqrt (x) and pow (x, 0.5) ought to give the same result (even if not required to by IEEE754). Browsing some gcc lists, I did see some comments that suggest that gcc (on linux) does try to transform pow (x, 0.5) to sqrt (x). This would make sqrt and pow consistent (whether or not technically correct). Maybe gcc / linux pow and msvcrt pow are both not quite exact, but this is hidden in your test, because gcc / linux replaces pow (x, 0.5) with sqrt (x), and msvcrt doesn't. (Just speculation.) It is odd, however, that the various mingw's don't agree, and this speaks to a possible bug in mingw. Thanks. K. Frank > ... > ==================== > #include <stdio.h> > #include <math.h> > > int main(int argc, char *argv[]) > { > double a, b, c; > int i; > for (i=0, a=1.0; i<10000000; i++) > { a *= 1.00000001; > b = sqrt(a); c = pow(a, 0.5); > if (b == c) continue; > printf("%.17g %.17g %.17g\n", a, b, c); > return 0; > } > return 0; > } > ==================== > > acn1@... temp > $ gcc expt.c o expt > acn1@... temp > $ ./expt > acn1@... temp > $ gcc3 mnocygwin expt.c o expt > acn1@... temp > $ ./expt > 1.0241210164238141 1.011988644414459 1.0119886444144588 > acn1@... temp > $ i686w64mingw32gcc expt.c o expt > acn1@... temp > $ ./expt > 1.0004603659307831 1.000230156479389 1.0002301564793892 > acn1@... temp > $ x86_64w64mingw32gcc expt.c o expt > acn1@... temp > $ ./expt > 1.0000179101601867 1.0000089550399969 1.0000089550399971 > acn1@... temp > ============================================================== 
From: Ruben Van Boxem <vanboxem.ruben@gm...>  20110429 19:51:40

2011/4/29 Ozkan Sezer <sezeroz@...> > On Fri, Apr 29, 2011 at 10:30 PM, Ruben Van Boxem > <vanboxem.ruben@...> wrote: > > 2011/4/29 NightStrike <nightstrike@...> > >> > >> On Fri, Apr 29, 2011 at 11:03 AM, Earnie <earnie@...> > >> wrote: > >> > Ozkan Sezer wrote: > >> >> On Fri, Apr 29, 2011 at 5:42 PM, Vincent Torri > >> >> <vincent.torri@...> wrote: > >> >>> hey > >> >>> > >> >>> did you remove the .la files ? > >> >>> > >> >> > >> >> Nope, didn't bother. If theyare causing trouble, the developers can > >> >> remove them by themselves. > >> >> > >> > > >> > The .la files are specific to your environment. Therefore they should > >> > not be distributed in binary packages. I find it not very kind for > the > >> > end user to have to worry about the contents of the distributed binary > >> > package because it screws up their environment since the distributor > >> > "didn't bother" and included files that pertain to his unique > >> > environment. > >> > >> Ozkan's builds are the best ones we currently have the capacity to > >> offer to our users. The fact that he builds them at all is a godsend, > >> and I for one certainly won't inspect that gift horse's mouth. He can > >> package them any way he wants (That's why it's a personal build and > >> not an official release). > >> > >> What's really important is that people that make builds stick around > >> to support them. That's way more important than deleting .la files, > >> and he does a fine job of that. > >> > >> Keep up the good work, sezero. > > > > Hear hear. I agree. It's not that he constantly spews unnecessary updates > > that require us to redelete the .la files. And only sucky configury > scripts > > misread them anyways. > > > > If I may be so blunt and rude, Ozkan, are there plans for a 4.6 build? > Your > > 4.5 build is still my main compiler, which works very well. You see, > C++0x > > is much improved yet again, and I'd like to "play" with its awesome > features > > ;) > > Is 4.6.x not provided through the automated builds already?? There > should be no need for me to make such a build (and I am not using it > myself anyway :)) > As some other discussion here on the list already brought up, the autobuilds are all crosscompilers (for x86_64) and in my experience, they run a bit slower on my machine. Don't know why, haven't tested it really, more like a feeling. And I trust you more :P And the autobuilds still are too big (the /mingw directory should/could be removed, and the executables in /libexec/gcc/someversionsandtriplets/*.exe are 5 times too large; I have reported this (maybe even filed bug reports), but it only hit deaf man's ears)... If there's no plans, there's no problem, just asking. I'll try the autobuilds when I find the time/courage/will. Ruben > > > > > Thanks, > > > > Ruben > >  > O.S. > > >  > WhatsUp Gold  Download Free Network Management Software > The most intuitive, comprehensive, and costeffective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgoldsd > _______________________________________________ > Mingww64public mailing list > Mingww64public@... > https://lists.sourceforge.net/lists/listinfo/mingww64public > 
From: Ozkan Sezer <sezeroz@gm...>  20110429 19:34:21

On Fri, Apr 29, 2011 at 10:30 PM, Ruben Van Boxem <vanboxem.ruben@...> wrote: > 2011/4/29 NightStrike <nightstrike@...> >> >> On Fri, Apr 29, 2011 at 11:03 AM, Earnie <earnie@...> >> wrote: >> > Ozkan Sezer wrote: >> >> On Fri, Apr 29, 2011 at 5:42 PM, Vincent Torri >> >> <vincent.torri@...> wrote: >> >>> hey >> >>> >> >>> did you remove the .la files ? >> >>> >> >> >> >> Nope, didn't bother. If theyare causing trouble, the developers can >> >> remove them by themselves. >> >> >> > >> > The .la files are specific to your environment. Therefore they should >> > not be distributed in binary packages. I find it not very kind for the >> > end user to have to worry about the contents of the distributed binary >> > package because it screws up their environment since the distributor >> > "didn't bother" and included files that pertain to his unique >> > environment. >> >> Ozkan's builds are the best ones we currently have the capacity to >> offer to our users. The fact that he builds them at all is a godsend, >> and I for one certainly won't inspect that gift horse's mouth. He can >> package them any way he wants (That's why it's a personal build and >> not an official release). >> >> What's really important is that people that make builds stick around >> to support them. That's way more important than deleting .la files, >> and he does a fine job of that. >> >> Keep up the good work, sezero. > > Hear hear. I agree. It's not that he constantly spews unnecessary updates > that require us to redelete the .la files. And only sucky configury scripts > misread them anyways. > > If I may be so blunt and rude, Ozkan, are there plans for a 4.6 build? Your > 4.5 build is still my main compiler, which works very well. You see, C++0x > is much improved yet again, and I'd like to "play" with its awesome features > ;) Is 4.6.x not provided through the automated builds already?? There should be no need for me to make such a build (and I am not using it myself anyway :)) > > Thanks, > > Ruben  O.S. 
From: Ruben Van Boxem <vanboxem.ruben@gm...>  20110429 19:31:04

2011/4/29 NightStrike <nightstrike@...> > On Fri, Apr 29, 2011 at 11:03 AM, Earnie <earnie@...> > wrote: > > Ozkan Sezer wrote: > >> On Fri, Apr 29, 2011 at 5:42 PM, Vincent Torri > >> <vincent.torri@...> wrote: > >>> hey > >>> > >>> did you remove the .la files ? > >>> > >> > >> Nope, didn't bother. If theyare causing trouble, the developers can > >> remove them by themselves. > >> > > > > The .la files are specific to your environment. Therefore they should > > not be distributed in binary packages. I find it not very kind for the > > end user to have to worry about the contents of the distributed binary > > package because it screws up their environment since the distributor > > "didn't bother" and included files that pertain to his unique > environment. > > Ozkan's builds are the best ones we currently have the capacity to > offer to our users. The fact that he builds them at all is a godsend, > and I for one certainly won't inspect that gift horse's mouth. He can > package them any way he wants (That's why it's a personal build and > not an official release). > > What's really important is that people that make builds stick around > to support them. That's way more important than deleting .la files, > and he does a fine job of that. > > Keep up the good work, sezero. > Hear hear. I agree. It's not that he constantly spews unnecessary updates that require us to redelete the .la files. And only sucky configury scripts misread them anyways. If I may be so blunt and rude, Ozkan, are there plans for a 4.6 build? Your 4.5 build is still my main compiler, which works very well. You see, C++0x is much improved yet again, and I'd like to "play" with its awesome features ;) Thanks, Ruben > > >  > WhatsUp Gold  Download Free Network Management Software > The most intuitive, comprehensive, and costeffective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgoldsd > _______________________________________________ > Mingww64public mailing list > Mingww64public@... > https://lists.sourceforge.net/lists/listinfo/mingww64public > 
From: NightStrike <nightstrike@gm...>  20110429 17:41:12

On Fri, Apr 29, 2011 at 11:03 AM, Earnie <earnie@...> wrote: > Ozkan Sezer wrote: >> On Fri, Apr 29, 2011 at 5:42 PM, Vincent Torri >> <vincent.torri@...> wrote: >>> hey >>> >>> did you remove the .la files ? >>> >> >> Nope, didn't bother. If theyare causing trouble, the developers can >> remove them by themselves. >> > > The .la files are specific to your environment. Therefore they should > not be distributed in binary packages. I find it not very kind for the > end user to have to worry about the contents of the distributed binary > package because it screws up their environment since the distributor > "didn't bother" and included files that pertain to his unique environment. Ozkan's builds are the best ones we currently have the capacity to offer to our users. The fact that he builds them at all is a godsend, and I for one certainly won't inspect that gift horse's mouth. He can package them any way he wants (That's why it's a personal build and not an official release). What's really important is that people that make builds stick around to support them. That's way more important than deleting .la files, and he does a fine job of that. Keep up the good work, sezero. 
From: Jon <jon.forums@gm...>  20110429 17:06:47

> > Self building is not an good option for my scenario. I'm currently folding in support for this toolchain into a larger project https://github.com/oneclick/rubyinstaller/blob/mingw6432/config/compilers/mingw64.rb#L334 in which our build recipe will download your toolchain, combine it with MSYS and other key artifacts, and use the resulting amalgamation to build the project as well be the engine in an easytouse DevKit https://github.com/oneclick/rubyinstaller/wiki/DevelopmentKit. > > > > Than I think of all those users using outdated copies streaming in and > reporting bugs fixed months ago : A truly horrible and irritating thought I agree. > Anyway, by bundling a toolchain, will you be willing to maintain it at > your end? I noticed you are mixing mingw.org components in, be careful > not to mix them when linking, there is no guarantee it'll work out. For the DevKit's we officially support and maintain, that's the idea. Hopefully the only questions you'd get would be from our project lead or contributors. It's the reason that, while we have build recipes that allow one to use multiple toolchains https://github.com/oneclick/rubyinstaller/blob/master/README.txt#L103126 we currently support only one flavor to save our sanity. While our external DevKit is meant to help our users easily build and use native C/C++ based Ruby extensions on Windows, as a project contributor and experimenter, the real value to me is to be able to type something like rake ruby19 dkver=mingw64324.5.3 and have our recipes download and build everything (including an internal DevKit) needed to get a working Ruby environment on Windows. If it's a slow day, I may even build a custom (unsupported) external DevKit and build gvim by doing something like: rake devkit sfx=1 dkver=mingw64324.5.3 c:\DevKit\devkitvars.bat mingw32make f Make_mingw.mak CC=i686w64mingw32gcc WINDRES=i686w64mingw32windres gvim.exe xxd/xxd.exe While most people prefer our binary downloads and installers, being able to rapidly build everything from source is fantastic and makes the project much more maintainable and enjoyable to work on. But I'm _way_ offtopic... Done with the issue...thanks again for your feedback and efforts on the project. Jon  blog: http://jonforums.github.com/ twitter: @jonforums 
From: Jon <jon.forums@gm...>  20110429 16:33:21

> > The .la files are specific to your environment. Therefore they should > > not be distributed in binary packages. I find it not very kind for the > > end user to have to worry about the contents of the distributed binary > > package because it screws up their environment since the distributor > > "didn't bother" and included files that pertain to his unique environment. > > > > Well, these are my "personal" builds which I am sharing with > others, so I have every right to not bother doing something this > trivial that anyone else can do. If there's someone out there > who volunteers to extract the packages, remove those *.la files, > repackage them and reupload the 300+ mb thing, then I'm not > holding anyone's hand. Another perspective is that "ready to go" downloads are great for those of us who are (or are considering) automating the download/use of the personal builds you've graciously taken the time to share. No need to preprocess your binary (potentially having to monitor/change the preprocessing code to use future builds) before using it...simply use your goodies and add value downstream. Hopefully the mods are trivial enough so they don't continually burden you either. Jon  blog: http://jonforums.github.com/ twitter: @jonforums 
From: Ozkan Sezer <sezeroz@gm...>  20110429 15:14:39

On Fri, Apr 29, 2011 at 6:03 PM, Earnie <earnie@...> wrote: > Ozkan Sezer wrote: >> On Fri, Apr 29, 2011 at 5:42 PM, Vincent Torri >> <vincent.torri@...> wrote: >>> hey >>> >>> did you remove the .la files ? >>> >> >> Nope, didn't bother. If theyare causing trouble, the developers can >> remove them by themselves. >> > > The .la files are specific to your environment. Therefore they should > not be distributed in binary packages. I find it not very kind for the > end user to have to worry about the contents of the distributed binary > package because it screws up their environment since the distributor > "didn't bother" and included files that pertain to his unique environment. > Well, these are my "personal" builds which I am sharing with others, so I have every right to not bother doing something this trivial that anyone else can do. If there's someone out there who volunteers to extract the packages, remove those *.la files, repackage them and reupload the 300+ mb thing, then I'm not holding anyone's hand. > Earnie > P.S.: I started not to send this after I wrote it but then decided I > still needed to say it. You can tell tar to exclude the files when you > build the archive or use find to remove them before you build the > archive. It's bothersome more in Windows than in Linux because in Linux > the package is built on the fly or is stored in a common location like > /usr/local. In Windows the drive letter often gets in the way if the > user decides to put the build environment somewhere besides the one the > distributor used.  O.S. 
From: Earnie <earnie@us...>  20110429 15:04:10

Ozkan Sezer wrote: > On Fri, Apr 29, 2011 at 5:42 PM, Vincent Torri > <vincent.torri@...> wrote: >> hey >> >> did you remove the .la files ? >> > > Nope, didn't bother. If theyare causing trouble, the developers can > remove them by themselves. > The .la files are specific to your environment. Therefore they should not be distributed in binary packages. I find it not very kind for the end user to have to worry about the contents of the distributed binary package because it screws up their environment since the distributor "didn't bother" and included files that pertain to his unique environment. Earnie P.S.: I started not to send this after I wrote it but then decided I still needed to say it. You can tell tar to exclude the files when you build the archive or use find to remove them before you build the archive. It's bothersome more in Windows than in Linux because in Linux the package is built on the fly or is stored in a common location like /usr/local. In Windows the drive letter often gets in the way if the user decides to put the build environment somewhere besides the one the distributor used. 