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

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

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

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

S  M  T  W  T  F  S 

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




From: Volker Grabsch <vog@no...>  20110503 23:19:10

Bj Raz schrieb: > I am trying to build a cross compiler to build Windows exes on linux, > I have looked for help and found this: > http://gcc.gnu.org/ml/gccbugs/200904/msg01029.html > > this messages gives a document on "mingww64howtobuild" that no > longer exists on sourceforge.net. If 32bit and static linking are okay for you, you might want to give the mingwcrossenv project a try: http://mingwcrossenv.nongnu.org/ Even if the project doesn't suit your needs, its src/gcc.mk source file demonstrates how to build a GCC 4.6.0 cross compiler for MinGW. Also note that you should build a suitable Binutils version before (see src/binutils.mk). Greets, Volker  Volker Grabsch <<(())>> 
From: Keith Marshall <keithmarshall@us...>  20110503 19:43:41

On 03/05/11 18:01, Greg Chicares wrote: > On 20110503 16:23Z, Mcgroder, James wrote: >> >> PKZIP BCLTDC.AL$1 ?CLTDC.* > [...] >> NOTE: The next two line are one line when I run the script... the len is 140 CHRS >> + PKZIP BCLTDC.AL6 BCLTDC.336 BCLTDC.AB6 FCLTDC.1M6 FCLTDC.2J6 FCLTDC.306 >> FCLTDC.766 FCLTDC.7I6 FCLTDC.IM6 FCLTDC.LS6 PCLTDC.306 PCLTDC.7I6 >> ./zip_test: line 3: /c/Windows/system32/PKZIP: Bad file number > > PKZIP is an old MSDOS program, so it probably expects wildcards to > be passed to it unexpanded. Whether it expects it or not, it must be prepared to deal with it, because command.com, like cmd.exe, doesn't expand it. > But bash expands wildcards. And this is a significant difference, especially since the OP states that the expanded command line length is 140 chars  the maximum that any MSDOS program can accept is 126 chars, so... > If you paste the expanded command line into CMD.EXE and it fails > there, then that would clearly rule out MSYS as the problem. ...it would be surprising if this did anything but fail, in one way or another, given the excessive command line length. > If you just want a workaround, try quoting the filename that > contains wildcards. If the OP must use PKZIP, then this isn't just a workaround, but is actually the only viable solution; the command line must be passed exactly as command.com would pass it: no more than 126 chars, with wildcards preserved. Quoting will preserve the wildcards, and bash will remove one level of quotes before passing the arguments; the onus remains on the OP to ensure that there are no more than 126 chars left, after removal of that one level of quoting.  Regards, Keith. 
From: Greg Chicares <gchicares@sb...>  20110503 18:12:03

On 20110503 17:50Z, Wallin, Nicholas J. wrote: > > I have just started trying to compile my application with MinGW. > My application depends on a few other libraries, one of which is > Coin. I am not looking for help in building Coin; I have (I think) > successfully built it already. However, the output was in the form > of .dll.a files and not the .dll files I am used to. Am I doing > something wrong? How do I get .dll files? In general, you get a .dll file by linking with 'shared', whereas .dll.a files are by convention only the corresponding import libs created by passing 'outimplib' to the linker. It would help to show the actual linker invocation in full. > A little info on what I am using. Windows XP. I am usin the MinGW > that comes with the Qt SDK. Then we can't rule out the possibility that that thirdparty distribution is broken; but my guess is that there's a problem in the makefile you're using, or the .dll file is written to a different directory than you expect. 
From: Wallin, Nicholas J. <Nicholas.W<allin@jh...>  20110503 17:51:18

Hello, I have just started trying to compile my application with MinGW. My application depends on a few other libraries, one of which is Coin. I am not looking for help in building Coin; I have (I think) successfully built it already. However, the output was in the form of .dll.a files and not the .dll files I am used to. Am I doing something wrong? How do I get .dll files? A little info on what I am using. Windows XP. I am usin the MinGW that comes with the Qt SDK. I am also using MSYS 1.1 (and mounting the aforementioned MinGW to /mingw) so I can have a shell. Thanks, Nicholas 
From: Greg Chicares <gchicares@sb...>  20110503 17:01:49

On 20110503 16:23Z, Mcgroder, James wrote: > > PKZIP BCLTDC.AL$1 ?CLTDC.* [...] > NOTE: The next two line are one line when I run the script... the len is 140 CHRS > + PKZIP BCLTDC.AL6 BCLTDC.336 BCLTDC.AB6 FCLTDC.1M6 FCLTDC.2J6 FCLTDC.306 > FCLTDC.766 FCLTDC.7I6 FCLTDC.IM6 FCLTDC.LS6 PCLTDC.306 PCLTDC.7I6 > ./zip_test: line 3: /c/Windows/system32/PKZIP: Bad file number PKZIP is an old MSDOS program, so it probably expects wildcards to be passed to it unexpanded. But bash expands wildcards. If you paste the expanded command line into CMD.EXE and it fails there, then that would clearly rule out MSYS as the problem. If you just want a workaround, try quoting the filename that contains wildcards. 
From: James K Beard <beardjamesk@ve...>  20110503 16:37:55

There have been special cases in scientific libraries for quite a long time. The special case for atan(1.0) is used by many programmers to extract the system stored value for pi/4, knowing that that the math library (or coprocessor) wouldnt compute it instead of simply retrieving the known result. The simple fact that a function like pow(*,*) will have an accuracy requirement that allows a bit or two of numerical error while the nature of the special case sqrt(*) allows full mantissa accuracy to within a possible toggle of the last bit, is not the same thing. The arc tangent is computed by libraries by expansion about the argument points 0 and 1, and identities like arctan(x) = pi/2  arctan(1/x) when x>1 and such. But this doesn't apply to pow(*,*) because, other than extraction of the exponents of the two arguments to limit the range of the logarithm and exponential in the identity a^b = exp(b*ln(a)) there is no breaking up of things with a natural boundary at b=0.5, although special cases for b=0 and 1 are often taken, and sometimes checks are made to determine whether or not b is an integer. The usual process is breaking up a into exponent and mantissa, a = (2^ea)*ma then computation of the logarithm of the result, ln(a^b) = lr = b*ln(a) = b*(eb*ln(2)+ln(ma)) = ilr + mlr, mlr<1 and finally exponentiation of the log result, a^b = (e^ilr)*(e^mlr). There is no obvious advantage for checking for any particular value of b other than 0 and 1 and possibly integers. Thus it seems to me, the obvious thing to do is to accept the specified accuracy of pow(*,*) and not do special cases other than 0, 1, and possibly integers. One might stretch things a bit by evaluating what we would call pow(a^2, b/2) but that would not likely survive an analysis of speed and accuracy as compared to pow(a,b). James K Beard Original Message From: K. Frank [mailto:kfrank29.c@...] Sent: Tuesday, May 03, 2011 9:32 AM To: mingw64; MinGW Users List Subject: Re: [Mingwusers] [Mingww64public] Math library discrepancies that surprised me. Hello Kai and Everybody! A couple of comments about whether to use special cases for pow (x, y) for things like y = 0.5 or y = integer... On Tue, May 3, 2011 at 6:58 AM, Kai Tietz wrote: > 2011/5/3 Peter Rockett <p.rockett@...>: >> On 03/05/2011 10:11, Kai Tietz wrote: >> ... >> The reason is not introducing a discontinuity into pow() around 0.5. >> Forcing the two functions to agree may seem like a good idea but in >> reality, you are creating another much more insidious problem. You are >> embedding a potentially disastrous property into pow(). >> >>> It might be that I haven't seen the forbidden >>> thing on the spec. The sqrt specialcase has at least one advantage >>> over the log2/exp2 variant. First it is faster, as just one FPU >>> command is used to calculate sqrt. Secondly, is provides better result >>> and compatible one to gcc's internal used softfloatingpoint library. >>> As I don't see in spec that this special casing shouldn't be done, I >>> think we will keep it on mingww64's side. >> ... > I am aware of this what you are telling me, but there is in pow > function already specialcasing for x^y for y with integer values in > range for y >= INT_MIN and y <= INT_MAX. As here more precise > calculation via powi is used. This makes that results of pow having > already discontinuity. > So pow functions doesn't have the requirement of having continuity. > ... I'm not aware that either the C standard or the IEEE754 standard specifies one behavior or the other. (I think that they don't, but I could be wrong.) I believe that is has been commonplace over the years to use these special cases for pow. (This is just the sense I have from personal recollection and oral tradition.) I think speed optimization has been the reason, rather than improved accuracy or agreement with things like sqrt, but perhaps it's been a mixture of those. Of course, just because there is precedent, doesn't mean it's the right way to go. If I had to choose between pow (x, 0.5) agreeing with sqrt (x) and pow (x, y) being monotone in y, I think I would choose the latter (i.e., choose not to use the special cases). But there are good arguments on both sides. One solution that would be attractive to me would be to implement pow "exactly" (i.e., bankers' rounding to the nearest representable value), and then use all the special cases you want as a speed optimization. Now the special cases won't change the value of pow (assuming sqrt is properly implemented), so the special cases won't introduce any nonmonotonicity or "discontinuities" into pow. What I don't know is how hard or expensive this is. I'm pretty sure it's not too hard to calculate exp "exactly." But I think that calculating log is harder. Perhaps James Beard knows whether it's practical to calculate pow "exactly," and maybe even how to do it. (Another approach, which I very much don't recommend, is to use pow to calculate sqrt. You get reduced speed and reduced accuracy for sqrt, but at least you do get sqrt and pow to agree without introducing nonmonotonicity into pow.) Lastly, I have to believe that this is a wellunderstood and "solved" problem in the numericalanalysis community (of which I am not a part). Perhaps it would make sense to find out how the experts who have doing this for fiftyplus years deal with this issue. > Regards, > Kai And thanks to the mingw and mingw64 teams who have invested the time and effort to actually write the code we're so breezily discussing. My comments are in no way meant to be a criticism of those efforts. I'm just offering up one man's opinion from the user community in the hope that it might be helpful. Bets regards. 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 _______________________________________________ MinGWusers mailing list MinGWusers@... This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingwusers Also: mailto:mingwusersrequest@...?subject=unsubscribe 
From: Mcgroder, James <james.mcgroder@hp...>  20110503 16:24:46

Grr.... same post W/new lines added... I'm attempting to convert a batch file to run as a shell script under MSYS. The first zip command fails and the second one does not. The BAT version works fine under DOS using this wild card scheme so I'm not exceeding the number of files PKZIP can handle. Interestingly, if I try BCLTDC.*, FCLTDC.*, and PCLTDC.* by themselves both lines work. Can't imagine I'm exceeding a command line length limit... Any idea what am I doing wrong? The Code: #!sh x # PKZIP BCLTDC.AL$1 ?CLTDC.* # PKZIP BDCADC.AL$1 ?DCADC.* The execution: $ zip_test 6 NOTE: The next two line are one line when I run the script... the len is 140 CHRS + PKZIP BCLTDC.AL6 BCLTDC.336 BCLTDC.AB6 FCLTDC.1M6 FCLTDC.2J6 FCLTDC.306 FCLTDC.766 FCLTDC.7I6 FCLTDC.IM6 FCLTDC.LS6 PCLTDC.306 PCLTDC.7I6 ./zip_test: line 3: /c/Windows/system32/PKZIP: Bad file number + PKZIP BDCADC.AL6 BDCADC.336 BDCADC.AB6 PKZIP (R) FAST! Create/Update Utility Version 2.04g 020193 Copr. 19891993 PKWARE Inc. All Rights Reserved. Shareware Version PKZIP Reg. U.S. Pat. and Tm. Off. Patent No. 5,051,745 80486 CPU detected. XMS version 2.00 detected. DPMI version 0.90 detected. Using Normal Compression. Creating ZIP: BDCADC.AL6 Adding: BDCADC.336 Deflating ( 2%), done. Adding: BDCADC.AB6 Deflating ( 1%), done. 
From: Bj Raz <whitequill.bj@gm...>  20110503 16:08:48

I am trying to build a cross compiler to build Windows exes on linux, I have looked for help and found this: http://gcc.gnu.org/ml/gccbugs/200904/msg01029.html this messages gives a document on "mingww64howtobuild" that no longer exists on sourceforge.net. This is the error I'm getting: In file included from ../.././gcc/tm.h:11, from ../../../gcc4.3.2/libgcc/../gcc/libgcc2.c:35: ../../../gcc4.3.2/libgcc/../gcc/config/i386/cygming.h:68:19: error: stdio.h: No such file or directory make[2]: *** [_muldi3.o] Error 1 make[2]: Leaving directory `/home/whitequill/Share/build.gcc/x86_64w64mingw32/libgcc' make[1]: *** [alltargetlibgcc] Error 2 make[1]: Leaving directory `/home/whitequill/Share/build.gcc' make: *** [all] Error 2 
From: Mcgroder, James <james.mcgroder@hp...>  20110503 16:04:07

I'm attempting to convert a batch file to run as a shell script under MSYS. The first zip command fails and the second one does not. The BAT version works fine under DOS using this wild card scheme so I'm not exceeding the number of files PKZIP can handle. Interestingly, if I try BCLTDC.*, FCLTDC.*, and PCLTDC.* by themselves both lines work. Can't imagine I'm exceeding a command line length limit... Any idea what am I doing wrong? The Code: #!sh x # PKZIP BCLTDC.AL$1 ?CLTDC.* # PKZIP BDCADC.AL$1 ?DCADC.* The execution: $ zip_test 6 NOTE: The next two line are one line when I run the script... the len is 140 CHRS + PKZIP BCLTDC.AL6 BCLTDC.336 BCLTDC.AB6 FCLTDC.1M6 FCLTDC.2J6 FCLTDC.306 FCLTDC.766 FCLTDC.7I6 FCLTDC.IM6 FCLTDC.LS6 PCLTDC.306 PCLTDC.7I6 ./zip_test: line 3: /c/Windows/system32/PKZIP: Bad file number + PKZIP BDCADC.AL6 BDCADC.336 BDCADC.AB6 PKZIP (R) FAST! Create/Update Utility Version 2.04g 020193 Copr. 19891993 PKWARE Inc. All Rights Reserved. Shareware Version PKZIP Reg. U.S. Pat. and Tm. Off. Patent No. 5,051,745 80486 CPU detected. XMS version 2.00 detected. DPMI version 0.90 detected. Using Normal Compression. Creating ZIP: BDCADC.AL6 Adding: BDCADC.336 Deflating ( 2%), done. Adding: BDCADC.AB6 Deflating ( 1%), done. 
From: K. Frank <kfrank29.c@gm...>  20110503 13:32:30

Hello Kai and Everybody! A couple of comments about whether to use special cases for pow (x, y) for things like y = 0.5 or y = integer... On Tue, May 3, 2011 at 6:58 AM, Kai Tietz wrote: > 2011/5/3 Peter Rockett <p.rockett@...>: >> On 03/05/2011 10:11, Kai Tietz wrote: >> ... >> The reason is not introducing a discontinuity into pow() around 0.5. >> Forcing the two functions to agree may seem like a good idea but in >> reality, you are creating another much more insidious problem. You are >> embedding a potentially disastrous property into pow(). >> >>> It might be that I haven't seen the forbidden >>> thing on the spec. The sqrt specialcase has at least one advantage >>> over the log2/exp2 variant. First it is faster, as just one FPU >>> command is used to calculate sqrt. Secondly, is provides better result >>> and compatible one to gcc's internal used softfloatingpoint library. >>> As I don't see in spec that this special casing shouldn't be done, I >>> think we will keep it on mingww64's side. >> ... > I am aware of this what you are telling me, but there is in pow > function already specialcasing for x^y for y with integer values in > range for y >= INT_MIN and y <= INT_MAX. As here more precise > calculation via powi is used. This makes that results of pow having > already discontinuity. > So pow functions doesn't have the requirement of having continuity. > ... I'm not aware that either the C standard or the IEEE754 standard specifies one behavior or the other. (I think that they don't, but I could be wrong.) I believe that is has been commonplace over the years to use these special cases for pow. (This is just the sense I have from personal recollection and oral tradition.) I think speed optimization has been the reason, rather than improved accuracy or agreement with things like sqrt, but perhaps it's been a mixture of those. Of course, just because there is precedent, doesn't mean it's the right way to go. If I had to choose between pow (x, 0.5) agreeing with sqrt (x) and pow (x, y) being monotone in y, I think I would choose the latter (i.e., choose not to use the special cases). But there are good arguments on both sides. One solution that would be attractive to me would be to implement pow "exactly" (i.e., bankers' rounding to the nearest representable value), and then use all the special cases you want as a speed optimization. Now the special cases won't change the value of pow (assuming sqrt is properly implemented), so the special cases won't introduce any nonmonotonicity or "discontinuities" into pow. What I don't know is how hard or expensive this is. I'm pretty sure it's not too hard to calculate exp "exactly." But I think that calculating log is harder. Perhaps James Beard knows whether it's practical to calculate pow "exactly," and maybe even how to do it. (Another approach, which I very much don't recommend, is to use pow to calculate sqrt. You get reduced speed and reduced accuracy for sqrt, but at least you do get sqrt and pow to agree without introducing nonmonotonicity into pow.) Lastly, I have to believe that this is a wellunderstood and "solved" problem in the numericalanalysis community (of which I am not a part). Perhaps it would make sense to find out how the experts who have doing this for fiftyplus years deal with this issue. > Regards, > Kai And thanks to the mingw and mingw64 teams who have invested the time and effort to actually write the code we're so breezily discussing. My comments are in no way meant to be a criticism of those efforts. I'm just offering up one man's opinion from the user community in the hope that it might be helpful. Bets regards. K. Frank 
From: Peter Rockett <p.rockett@sh...>  20110503 12:10:52

On 03/05/2011 11:58, Kai Tietz wrote: > 2011/5/3 Peter Rockett<p.rockett@...>: >> On 03/05/2011 10:11, Kai Tietz wrote: >>> 2011/5/3 JonY<jon_y@...>: >>>> On 5/3/2011 04:05, Kai Tietz wrote: >>>>> 2011/5/2 Peter Rockett<p.rockett@...>: >>>>>> On 02/05/2011 17:00, Keith Marshall wrote: >>>>>>> On 02/05/11 16:30, Charles Wilson wrote: >>>>>>>>> So, we would like sqrt (x) and pow (x, 0.5) to agree. >>>>>> The point below about offtopic diversions into precision is valid but >>>>>> can I reiterate, there is no good reason why x^(0.5) calculated two >>>>>> different ways should agree since the two different routes will >>>>>> accumulate different rounding errors. Adding a special case to force >>>>>> agreement for x^n when n = 0.5 will introduce a discontinuity into the >>>>>> pow() function and is a very bad idea. The value of returned by pow(x, >>>>>> 0.5) might be less accurate compared to sqrt(x) but that is part of the >>>>>> fundamental issue with using floatingpoint numbers: they are only ever >>>>>> approximations. You have to take that fact on board. >>>>> Correct, the ways of calculation of pow (x, 0.5) and sqrt (x) are different. >>>>> Nevertheless is it an issue in gcc. As if you are writing pow (1.1, >>>>> 0.5) or sqrt (1.1)  which means gcc optimize it via gmp to a >>>>> precalculated result  it has identical values. But by using >>>>> mathlibrary results in a  expectable  difference in result. >>>>> So IMHO pow should special case here to provide same result as pow >>>>> does for y = 0.5. >>>> I would agree with the others that its a horrible hack to treat "0.5" >>>> special, I don't remember reading anything about requiring pow() results >>>> to agree with sqrt(). >>>> >>>> Can we at least follow a standard spec like: >>>> <http://pubs.opengroup.org/onlinepubs/009695399/functions/pow.html>; >>>> >>>> We can remove the special case, right? >>> Well, as some people aren't able to use replyall here, but have wise >>> suggestion about implementation details they don't satisfy themself, I >>> am a bit annoyed. >>> Anyway, I see that this specialcasing is neither explicitly demanded, >>> but also it isn't explicitly forbidden. So I see here not much reason >>> for removing this. >> The reason is not introducing a discontinuity into pow() around 0.5. >> Forcing the two functions to agree may seem like a good idea but in >> reality, you are creating another much more insidious problem. You are >> embedding a potentially disastrous property into pow(). >> >>> It might be that I haven't seen the forbidden >>> thing on the spec. The sqrt specialcase has at least one advantage >>> over the log2/exp2 variant. First it is faster, as just one FPU >>> command is used to calculate sqrt. Secondly, is provides better result >>> and compatible one to gcc's internal used softfloatingpoint library. >>> As I don't see in spec that this special casing shouldn't be done, I >>> think we will keep it on mingww64's side. >> Sorry, but that's a really bad call IMO for the reason stated above. You >> are ignoring the consequences to try to (mistakenly) enforce >> mathematical correctness. Even basic FP ops like addition and >> subtraction deviate from pure mathematical notions of equality. For >> example, 1 + a, where a is less than the machine epsilon will return >> precisely unity! Floating point numbers ain't reals and you can't force >> them to behave exactly like reals... >> >> P. > I am aware of this what you are telling me, but there is in pow > function already specialcasing for x^y for y with integer values in > range for y>= INT_MIN and y<= INT_MAX. As here more precise > calculation via powi is used. This makes that results of pow having > already discontinuity. > So pow functions doesn't have the requirement of having continuity. I can see no mention of thus in the standard. Is this part of the mingw64 implementation? >>> Well, it might be a good idea on mingw.org's side to recheck the exp2, >>> exp2f, exp2l, and expl implementation, as here you can easily prove >>> that the calculated results have a rounding issue, which leads for >>> combined operations  like exp2 (y * log2 (fabs (x))  to >>> miscalculations over two eps. But well, this might be treated as >>> typical inaccuracy ... >>> >>> Regards, >>> Kai > Regards, > Kai > >  > 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 > _______________________________________________ > MinGWusers mailing list > MinGWusers@... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingwusers > Also: mailto:mingwusersrequest@...?subject=unsubscribe 
From: Kai Tietz <ktietz70@go...>  20110503 10:58:19

2011/5/3 Peter Rockett <p.rockett@...>: > On 03/05/2011 10:11, Kai Tietz wrote: >> 2011/5/3 JonY<jon_y@...>: >>> On 5/3/2011 04:05, Kai Tietz wrote: >>>> 2011/5/2 Peter Rockett<p.rockett@...>: >>>>> On 02/05/2011 17:00, Keith Marshall wrote: >>>>>> On 02/05/11 16:30, Charles Wilson wrote: >>>>>>>> So, we would like sqrt (x) and pow (x, 0.5) to agree. >>>>> The point below about offtopic diversions into precision is valid but >>>>> can I reiterate, there is no good reason why x^(0.5) calculated two >>>>> different ways should agree since the two different routes will >>>>> accumulate different rounding errors. Adding a special case to force >>>>> agreement for x^n when n = 0.5 will introduce a discontinuity into the >>>>> pow() function and is a very bad idea. The value of returned by pow(x, >>>>> 0.5) might be less accurate compared to sqrt(x) but that is part of the >>>>> fundamental issue with using floatingpoint numbers: they are only ever >>>>> approximations. You have to take that fact on board. >>>> Correct, the ways of calculation of pow (x, 0.5) and sqrt (x) are different. >>>> Nevertheless is it an issue in gcc. As if you are writing pow (1.1, >>>> 0.5) or sqrt (1.1)  which means gcc optimize it via gmp to a >>>> precalculated result  it has identical values. But by using >>>> mathlibrary results in a  expectable  difference in result. >>>> So IMHO pow should special case here to provide same result as pow >>>> does for y = 0.5. >>> I would agree with the others that its a horrible hack to treat "0.5" >>> special, I don't remember reading anything about requiring pow() results >>> to agree with sqrt(). >>> >>> Can we at least follow a standard spec like: >>> <http://pubs.opengroup.org/onlinepubs/009695399/functions/pow.html>; >>> >>> We can remove the special case, right? >> Well, as some people aren't able to use replyall here, but have wise >> suggestion about implementation details they don't satisfy themself, I >> am a bit annoyed. >> Anyway, I see that this specialcasing is neither explicitly demanded, >> but also it isn't explicitly forbidden. So I see here not much reason >> for removing this. > > The reason is not introducing a discontinuity into pow() around 0.5. > Forcing the two functions to agree may seem like a good idea but in > reality, you are creating another much more insidious problem. You are > embedding a potentially disastrous property into pow(). > >> It might be that I haven't seen the forbidden >> thing on the spec. The sqrt specialcase has at least one advantage >> over the log2/exp2 variant. First it is faster, as just one FPU >> command is used to calculate sqrt. Secondly, is provides better result >> and compatible one to gcc's internal used softfloatingpoint library. >> As I don't see in spec that this special casing shouldn't be done, I >> think we will keep it on mingww64's side. > > Sorry, but that's a really bad call IMO for the reason stated above. You > are ignoring the consequences to try to (mistakenly) enforce > mathematical correctness. Even basic FP ops like addition and > subtraction deviate from pure mathematical notions of equality. For > example, 1 + a, where a is less than the machine epsilon will return > precisely unity! Floating point numbers ain't reals and you can't force > them to behave exactly like reals... > > P. I am aware of this what you are telling me, but there is in pow function already specialcasing for x^y for y with integer values in range for y >= INT_MIN and y <= INT_MAX. As here more precise calculation via powi is used. This makes that results of pow having already discontinuity. So pow functions doesn't have the requirement of having continuity. >> Well, it might be a good idea on mingw.org's side to recheck the exp2, >> exp2f, exp2l, and expl implementation, as here you can easily prove >> that the calculated results have a rounding issue, which leads for >> combined operations  like exp2 (y * log2 (fabs (x))  to >> miscalculations over two eps. But well, this might be treated as >> typical inaccuracy ... >> >> Regards, >> Kai Regards, Kai 
From: Peter Rockett <p.rockett@sh...>  20110503 10:37:14

On 03/05/2011 10:11, Kai Tietz wrote: > 2011/5/3 JonY<jon_y@...>: >> On 5/3/2011 04:05, Kai Tietz wrote: >>> 2011/5/2 Peter Rockett<p.rockett@...>: >>>> On 02/05/2011 17:00, Keith Marshall wrote: >>>>> On 02/05/11 16:30, Charles Wilson wrote: >>>>>>> So, we would like sqrt (x) and pow (x, 0.5) to agree. >>>> The point below about offtopic diversions into precision is valid but >>>> can I reiterate, there is no good reason why x^(0.5) calculated two >>>> different ways should agree since the two different routes will >>>> accumulate different rounding errors. Adding a special case to force >>>> agreement for x^n when n = 0.5 will introduce a discontinuity into the >>>> pow() function and is a very bad idea. The value of returned by pow(x, >>>> 0.5) might be less accurate compared to sqrt(x) but that is part of the >>>> fundamental issue with using floatingpoint numbers: they are only ever >>>> approximations. You have to take that fact on board. >>> Correct, the ways of calculation of pow (x, 0.5) and sqrt (x) are different. >>> Nevertheless is it an issue in gcc. As if you are writing pow (1.1, >>> 0.5) or sqrt (1.1)  which means gcc optimize it via gmp to a >>> precalculated result  it has identical values. But by using >>> mathlibrary results in a  expectable  difference in result. >>> So IMHO pow should special case here to provide same result as pow >>> does for y = 0.5. >> I would agree with the others that its a horrible hack to treat "0.5" >> special, I don't remember reading anything about requiring pow() results >> to agree with sqrt(). >> >> Can we at least follow a standard spec like: >> <http://pubs.opengroup.org/onlinepubs/009695399/functions/pow.html>; >> >> We can remove the special case, right? > Well, as some people aren't able to use replyall here, but have wise > suggestion about implementation details they don't satisfy themself, I > am a bit annoyed. > Anyway, I see that this specialcasing is neither explicitly demanded, > but also it isn't explicitly forbidden. So I see here not much reason > for removing this. The reason is not introducing a discontinuity into pow() around 0.5. Forcing the two functions to agree may seem like a good idea but in reality, you are creating another much more insidious problem. You are embedding a potentially disastrous property into pow(). > It might be that I haven't seen the forbidden > thing on the spec. The sqrt specialcase has at least one advantage > over the log2/exp2 variant. First it is faster, as just one FPU > command is used to calculate sqrt. Secondly, is provides better result > and compatible one to gcc's internal used softfloatingpoint library. > As I don't see in spec that this special casing shouldn't be done, I > think we will keep it on mingww64's side. Sorry, but that's a really bad call IMO for the reason stated above. You are ignoring the consequences to try to (mistakenly) enforce mathematical correctness. Even basic FP ops like addition and subtraction deviate from pure mathematical notions of equality. For example, 1 + a, where a is less than the machine epsilon will return precisely unity! Floating point numbers ain't reals and you can't force them to behave exactly like reals... P. > Well, it might be a good idea on mingw.org's side to recheck the exp2, > exp2f, exp2l, and expl implementation, as here you can easily prove > that the calculated results have a rounding issue, which leads for > combined operations  like exp2 (y * log2 (fabs (x))  to > miscalculations over two eps. But well, this might be treated as > typical inaccuracy ... > > Regards, > Kai 
From: yap munsoon <soonyee@ya...>  20110503 09:18:03

From: Kai Tietz <ktietz70@go...>  20110503 09:12:01

2011/5/3 JonY <jon_y@...>: > On 5/3/2011 04:05, Kai Tietz wrote: >> 2011/5/2 Peter Rockett <p.rockett@...>: >>> On 02/05/2011 17:00, Keith Marshall wrote: >>>> On 02/05/11 16:30, Charles Wilson wrote: >>>>>> So, we would like sqrt (x) and pow (x, 0.5) to agree. >>> >>> The point below about offtopic diversions into precision is valid but >>> can I reiterate, there is no good reason why x^(0.5) calculated two >>> different ways should agree since the two different routes will >>> accumulate different rounding errors. Adding a special case to force >>> agreement for x^n when n = 0.5 will introduce a discontinuity into the >>> pow() function and is a very bad idea. The value of returned by pow(x, >>> 0.5) might be less accurate compared to sqrt(x) but that is part of the >>> fundamental issue with using floatingpoint numbers: they are only ever >>> approximations. You have to take that fact on board. >> >> Correct, the ways of calculation of pow (x, 0.5) and sqrt (x) are different. >> Nevertheless is it an issue in gcc. As if you are writing pow (1.1, >> 0.5) or sqrt (1.1)  which means gcc optimize it via gmp to a >> precalculated result  it has identical values. But by using >> mathlibrary results in a  expectable  difference in result. >> So IMHO pow should special case here to provide same result as pow >> does for y = 0.5. > > I would agree with the others that its a horrible hack to treat "0.5" > special, I don't remember reading anything about requiring pow() results > to agree with sqrt(). > > Can we at least follow a standard spec like: > <http://pubs.opengroup.org/onlinepubs/009695399/functions/pow.html>; > > We can remove the special case, right? Well, as some people aren't able to use replyall here, but have wise suggestion about implementation details they don't satisfy themself, I am a bit annoyed. Anyway, I see that this specialcasing is neither explicitly demanded, but also it isn't explicitly forbidden. So I see here not much reason for removing this. It might be that I haven't seen the forbidden thing on the spec. The sqrt specialcase has at least one advantage over the log2/exp2 variant. First it is faster, as just one FPU command is used to calculate sqrt. Secondly, is provides better result and compatible one to gcc's internal used softfloatingpoint library. As I don't see in spec that this special casing shouldn't be done, I think we will keep it on mingww64's side. Well, it might be a good idea on mingw.org's side to recheck the exp2, exp2f, exp2l, and expl implementation, as here you can easily prove that the calculated results have a rounding issue, which leads for combined operations  like exp2 (y * log2 (fabs (x))  to miscalculations over two eps. But well, this might be treated as typical inaccuracy ... Regards, Kai 
From: Keith Marshall <keithmarshall@us...>  20110503 06:51:11

On 03/05/11 02:24, JonY wrote: > I would agree with the others that its a horrible hack to treat "0.5" > special, I don't remember reading anything about requiring pow() results > to agree with sqrt(). > > Can we at least follow a standard spec like: > <http://pubs.opengroup.org/onlinepubs/009695399/functions/pow.html>; > > We can remove the special case, right? s/can/SHOULD/  Regards, Keith. 
From: JonY <jon_y@us...>  20110503 01:24:31
