From: Vicent Segui Pascual <vseguip@pi...>  20110502 20:20:06

Enviado desde mi HTC  Reply message  De: mingwusersrequest@... Para: <mingwusers@...> Asunto: MinGWusers Digest, Vol 60, Issue 5 Fecha: lun., may. 2, 2011 19:17 Send MinGWusers mailing list submissions to mingwusers@... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/mingwusers or, via email, send a message with subject or body 'help' to mingwusersrequest@... You can reach the person managing the list at mingwusersowner@... When replying, please edit your Subject line so it is more specific than "Re: Contents of MinGWusers digest..." Today's Topics: 1. Re: [Mingww64public] Math library discrepancies that surprised me. (Keith Marshall) 2. Re: [Mingww64public] Math library discrepancies that surprised me. (Charles Wilson) 3. Re: [Mingww64public] Math library discrepancies that surprised me. (Keith Marshall) 4. Re: [Mingww64public] Math library discrepancies that surprised me. (K. Frank)  Message: 1 Date: Mon, 02 May 2011 07:34:20 +0100 From: Keith Marshall <keithmarshall@...> Subject: Re: [Mingwusers] [Mingww64public] Math library discrepancies that surprised me. To: mingwusers@... MessageID: <4DBE506C.4070803@...> ContentType: text/plain; charset=ISO88591 On 01/05/11 14:36, K. Frank wrote: > Hello Keith! > > On Sun, May 1, 2011 at 3:43 AM, Keith Marshall > <keithmarshall@...> wrote: >> On 30/04/11 23:14, Kai Tietz wrote: >>> long double (80bit): >>> digits for mantissa:64 >>> ... >> >> Alas, this sort of mathematical ineptitude seems to be all too common >> amongst the programming fraternity. It isn't helped by a flaw in the >> gdtoa implementation common on BSD and GNU/Linux, (and also adopted by >> Danny into mingwrt); it fails to implement the Steele and White stop >> condition correctly, continuing to spew out garbage beyond the last bit >> of available precision, creating an illusion of better accuracy than is >> really achievable. > > If I understand your point here, your complaint is that gdtoa will happily > generate more that twenty (or nineteen, if you will) decimal digits for a > gcc long double. (I won't speak to the technical correctness of gdtoa; > for all I know, it has bugs.) I think your point is that those "extra" decimal > digits represent false (and misleading) precision. > > (Sorry if I've misinterpreted your comment.) My complaint is that, long after the last bit of precision has been interpreted, gdtoa (which is at the heart of printf()'s floating point output formatting) will continue to spew out extra decimal digits, based solely on the residual remainder from the preceding digit conversion, with an arbitrary number of extra zero bits appended. (Thus, gdtoa makes the unjustified and technically invalid assumption that the known bit precision may be arbitrarily extended to ANY LENGTH AT ALL, simply by appending zero bits in place of the less significant unknowns). > I don't agree with this. Well, you are entitled to your own opinion; we may agree to disagree. > In most cases, it is not helpful to print out a long double to more > than twenty decimal place, but sometimes it is. The point is that it > is not the case that floatingpoint numbers represent all real > numbers inexactly; rather, they represent only a subset of real > numbers exactly. If I happen to be representing a real number exactly > with a long double, I might wish to print it out with lots (more than > twenty) decimal digits. Such a use case is admittedly rare, but not > illegitimate. This may be acceptable, provided you understand that those additional digits are of questionable accuracy. When you attempt to claim an accuracy which simply isn't available, then I would consider that it is most definitely illegitimate. > Let's say that I have a floatingpoint number with ten binary digits, so > it gives about three decimal digits of precision (2^10 == 1024 ~= 10^3). > I can use such a number to represent 1 + 2^10 exactly. Well, yes, you can if we allow you an implied eleventh bit, as most significant, normalised to 1; thus your mantissa bit pattern becomes: 10000000001B > I can print this number out exactly in decimal using ten digits after > the decimal point: 1.0009765625. That's legitimate, and potentially a > good thing. Sorry, but I couldn't disagree more. See, here you are falling into the gdtoa trap. You have an effective bit precision of eleven, which gives you: 11 / log2(10) = 3.311 decimal digits (i.e. 3 full digits) > If I limit myself to three digits after the decimal point I get 1.001 > (rounding up). You can't even claim that. Once again, you are confusing decimal places and significant digits. You may claim AT MOST 3 significant digits, and those are 1.00; (significance begins at the leftmost nonzero digit overall, not just after the radix point). > Sure, this is not a common use case, but I would prefer that the software > let me do this, and leave it up to me to know what I'm doing. I would prefer that software didn't try to claim the indefensible. Your 1.0009765625 example represents 11 significant decimal digits of precision. To represent that in binary, you need a minimum of: 11 * log2(10) = 36.54 bits (which we must round up to 37 bits). While a mantissa of 10000000001B MAY equate exactly to your example value of 1 + 2^10, it is guaranteed to be exact to 11 decimal digits of significance only if its normalised 37bit representation is: 1000000000100000000000000000000000000B Since you have only 11 bits of guaranteed binary precision available, you are making a sweeping assumption about those extra 26 bits; (they must ALL be zero). If you know for certain that this is so, then okay, but since you don't have those bits available, you have no technically defensible basis, in the general case, for making such an assumption; your argument is flawed, and IMO technically invalid.  Regards, Keith.  Message: 2 Date: Mon, 02 May 2011 11:30:52 0400 From: Charles Wilson <cwilso11@...> Subject: Re: [Mingwusers] [Mingww64public] Math library discrepancies that surprised me. To: MinGW Users List <mingwusers@...> MessageID: <4DBECE2C.1050603@...> ContentType: text/plain; charset=ISO88591 On 5/2/2011 2:34 AM, Keith Marshall wrote: > On 01/05/11 14:36, K. Frank wrote: >> [snip] > My complaint is that, long after the last bit of precision has been > interpreted, gdtoa (which is at the heart of printf()'s floating point > output formatting) will continue to spew out extra decimal digits, based > solely on the residual remainder from the preceding digit conversion, > with an arbitrary number of extra zero bits appended. (Thus, gdtoa > makes the unjustified and technically invalid assumption that the known > bit precision may be arbitrarily extended to ANY LENGTH AT ALL, simply > by appending zero bits in place of the less significant unknowns). > >> I don't agree with this. > > Well, you are entitled to your own opinion; we may agree to disagree. > >> In most cases, it is not helpful to print out a long double to more >> than twenty decimal place, but sometimes it is. The point is that it >> is not the case that floatingpoint numbers represent all real >> numbers inexactly; rather, they represent only a subset of real >> numbers exactly. But the problem is, if I send you a floating point number that represents the specific real number which I have in mind, exactly, YOU don't know that. All you have is a particular floating point number that represents the range [valueulps/2, value+ulps/w). You have no idea that I actually INTENDED to communicate EXACTLY "value" to you. Ditto for the results of a long computation. I get back as the output some f.p. rep  I don't *know* that the actual result of the computation is exactly the value of that rep. All I know is the result is not representable with more accuracy by any OTHER f.p. rep with the same precision. >> If I happen to be representing a real number exactly >> with a long double, I might wish to print it out with lots (more than >> twenty) decimal digits. Such a use case is admittedly rare, but not >> illegitimate. No, that's always illegitimate (i.e. misleading). Imagine I wrote a scientific paper concerning an experiment with 17 trials, and my individual measurements had a precision of 3 sig. digits (all of the same order of magnitude). I can't say that the mean result had 20 sig. digits simply because I can't represent the result of dividing by 17 exactly using only 3 sig. digits. It's not accurate to extend the precision of the sum by appending zeros, simply so that I get more digits of "apparent precision" after dividing by 17. My paper would be rejected  and rightly so. > This may be acceptable, provided you understand that those additional > digits are of questionable accuracy. When you attempt to claim an > accuracy which simply isn't available, then I would consider that it is > most definitely illegitimate. > >> Let's say that I have a floatingpoint number with ten binary digits, so >> it gives about three decimal digits of precision (2^10 == 1024 ~= 10^3). >> I can use such a number to represent 1 + 2^10 exactly. > > Well, yes, you can if we allow you an implied eleventh bit, as most > significant, normalised to 1; thus your mantissa bit pattern becomes: > > 10000000001B > >> I can print this number out exactly in decimal using ten digits after >> the decimal point: 1.0009765625. That's legitimate, and potentially a >> good thing. But 10000000001B does NOT mean "1 + 2^10". It means "with the limited precision I have, I can't represent the actual value of real number R more accurately with any other bit pattern than this one". > Sorry, but I couldn't disagree more. See, here you are falling into the > gdtoa trap. You have an effective bit precision of eleven, which gives you: > > 11 / log2(10) = 3.311 decimal digits (i.e. 3 full digits) > >> If I limit myself to three digits after the decimal point I get 1.001 >> (rounding up). > > You can't even claim that. Once again, you are confusing decimal places > and significant digits. You may claim AT MOST 3 significant digits, and > those are 1.00; (significance begins at the leftmost nonzero digit > overall, not just after the radix point). See, here's the problem: 1.0009765625 means: I can distinguish between the following three numbers: a) 1.0009765624 b) 1.0009765625 c) 1.0009765626 and the real number R is closer to (b) than to (a) or (c). But with 10 bits, you CAN'T distinguish between those three numbers: the same 10 bit pattern must be used to represent all three. In fact, the best you can do with 10 bits is distinguish between the following three reps: (a) 0.999 (b) 1.00 (c) 1.01 (Note, because of the normalization shift between (a) and (b/c), the accuracy *appears* to change in magnitude by a factor of 10, but that's simply an artifact of the base10 representation  in base two the normalization shift effect is only a factor of 2, not 10). Once again, the real number R is closer to (b) than to (a) or (c), and that's the best you can do with 10 bits (3 significant decimal digits). >> Sure, this is not a common use case, but I would prefer that the software >> let me do this, and leave it up to me to know what I'm doing. > > I would prefer that software didn't try to claim the indefensible. Your > 1.0009765625 example represents 11 significant decimal digits of > precision. To represent that in binary, you need a minimum of: > > 11 * log2(10) = 36.54 bits > > (which we must round up to 37 bits). While a mantissa of 10000000001B > MAY equate exactly to your example value of 1 + 2^10, it is guaranteed > to be exact to 11 decimal digits of significance only if its normalised > 37bit representation is: > > 1000000000100000000000000000000000000B > > Since you have only 11 bits of guaranteed binary precision available, > you are making a sweeping assumption about those extra 26 bits; (they > must ALL be zero). If you know for certain that this is so, then okay, > but since you don't have those bits available, you have no technically > defensible basis, in the general case, for making such an assumption; > your argument is flawed, and IMO technically invalid. Agree. But this whole discussion is rather beside the point I think, which started with a real discrepancy in the actual bit pattern produced by sqrt(x) and pow(x, 0.5). e.g. > 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. This is a binary bit pattern issue, not a gdtoa base 10 conversion issue.  Chuck  Message: 3 Date: Mon, 02 May 2011 17:00:32 +0100 From: Keith Marshall <keithmarshall@...> Subject: Re: [Mingwusers] [Mingww64public] Math library discrepancies that surprised me. To: mingwusers@... MessageID: <4DBED520.6080804@...> ContentType: text/plain; charset=ISO88591 On 02/05/11 16:30, Charles Wilson wrote: >> 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. > > This is a binary bit pattern issue, not a gdtoa base 10 conversion > issue. Absolutely agree. Others side tracked the issue into the realms of representable precision  a DIFFERENT issue around which confusion appears to abound. This confusion is compounded by the gdtoa stopping anomaly. Just wanted to clarify that. Enough said.  Regards, Keith.  Message: 4 Date: Mon, 2 May 2011 13:17:28 0400 From: "K. Frank" <kfrank29.c@...> Subject: Re: [Mingwusers] [Mingww64public] Math library discrepancies that surprised me. To: MinGW Users List <mingwusers@...> MessageID: <BANLkTi=aMb+QqnLAG_FGPm0J8t6Zp3gcw@...> ContentType: text/plain; charset=ISO88591 Hello Charles and Keith! On Mon, May 2, 2011 at 11:30 AM, Charles Wilson wrote: > On 5/2/2011 2:34 AM, Keith Marshall wrote: >> On 01/05/11 14:36, K. Frank wrote: >>> [snip] >> My complaint is that, long after the last bit of precision has been >> interpreted, gdtoa (which is at the heart of printf()'s floating point >> output formatting) will continue to spew out extra decimal digits, based >> solely on the residual remainder from the preceding digit conversion, >> with an arbitrary number of extra zero bits appended. ?(Thus, gdtoa >> makes the unjustified and technically invalid assumption that the known >> bit precision may be arbitrarily extended to ANY LENGTH AT ALL, simply >> by appending zero bits in place of the less significant unknowns). >> >>> I don't agree with this. >> >> Well, you are entitled to your own opinion; we may agree to disagree. >> >>> In most cases, it is not helpful to print out a long double to more >>> than twenty decimal place, but sometimes it is. The point is that it >>> is not the case that floatingpoint numbers represent all real >>> numbers inexactly; rather, they represent only a subset of real >>> numbers exactly. > > But the problem is, if I send you a floating point number that > represents the specific real number which I have in mind, exactly, YOU > don't know that. True. But this does not apply to all use cases. If I have generated a floatingpoint number, and I happen to know that it was generated in a way that it exactly represents a specific real number, I am fully allowed to make use of this information. (If you send me a floatingpoint number, and don't provide me the guarantee that it is being used to represent a specific real number exactly  and this indeed is the most common, but not the only use case  then your comments are correct.) > All you have is a particular floating point number > that represents the range [valueulps/2, value+ulps/w). You have no idea > that I actually INTENDED to communicate EXACTLY "value" to you. Yes, in your use case you did not intend to communicate an exact value to me. Therefore I should not imagine the floatingpoint number you sent me to be exact. And I shouldn't use gdtoa to print it out to fifty decimal places. > ... >>> If I happen to be representing a real number exactly >>> with a long double, I might wish to print it out with lots (more than >>> twenty) decimal digits. Such a use case is admittedly rare, but not >>> illegitimate. > > No, that's always illegitimate (i.e. misleading). It's the "always" I disagree with. Your comments are correct for the use cases you describe, but you are incorrectly implying other use cases don't exist. > ... >> ... >>> Let's say that I have a floatingpoint number with ten binary digits, so >>> it gives about three decimal digits of precision (2^10 == 1024 ~= 10^3). >>> I can use such a number to represent 1 + 2^10 exactly. >> >> Well, yes, you can if we allow you an implied eleventh bit, as most >> significant, normalised to 1; thus your mantissa bit pattern becomes: >> >> ? 10000000001B >> >>> I can print this number out exactly in decimal using ten digits after >>> the decimal point: 1.0009765625. That's legitimate, and potentially a >>> good thing. > > But 10000000001B does NOT mean "1 + 2^10". In some specialized use cases, it means precisely this. In my program (assuming it's written correctly, etc.) the value means precisely what my program deems it to mean. > It means "with the limited > precision I have, I can't represent the actual value of real number R > more accurately with any other bit pattern than this one". In the common use cases, this is a very good way to understand floatingpoint numbers. But, to reiterate my point, there are use cases where floatingpoint numbers are used to exactly represent a special subset of the real numbers. These floatingpoint numbers mean something exact, and therefore mean something different than your phrase, "with the limited precision I have." > ... >>> Sure, this is not a common use case, but I would prefer that the software >>> let me do this, and leave it up to me to know what I'm doing. >> >> I would prefer that software didn't try to claim the indefensible. >> ... I have use floatingpoint numbers and FPU's in situations where the correctness of the calculations depended upon the floatingpoint numbers representing specific real numbers exactly. I had to be very careful doing this to get it right, but I was careful and the calculations were correct. What more can I say? Such use cases exist. I have found it convenient (although hardly essential) to sometimes print those numbers out in decimal (because decimal representations are more familiar to me), and it was therefore helpful that my formatting routine didn't prevent me from doing this exactly. This is exactly my argument for why the behavior of gdtoa that you object to is good in certain specialized instances. This may be a use case that you have never encountered, but nevertheless, there it is. >> ... >> >> ? 1000000000100000000000000000000000000B >> >> Since you have only 11 bits of guaranteed binary precision available, >> you are making a sweeping assumption about those extra 26 bits; (they >> must ALL be zero). ?If you know for certain that this is so, then okay, That's the point. There are specialized cases where I know with mathematically provable certainty that those extra bits are all zero. Not because they're stored in memory  they're not  but because my calculation was specifically structured so that they had to be. >> but since you don't have those bits available, you have no technically >> defensible basis, in the general case, for making such an assumption; >> your argument is flawed, and IMO technically invalid. On the contrary, even though the bits are not available (i.e. are not stored in memory), it is still possible in my specific case (not your general case) to know (not assume) that these bits are zero. My technically defensible basis for knowing this is that my calculation is structured so that these bits being zero is an invariant of the calculation. Look, I've never argued or implied that this sort of use case is in any way common, and I stated explicitly at the beginning of the discussion that this sort of use case is atypical. Your comments are quite correct for the way floatingpoint numbers are used the vast majority of the time. I'm just pointing out that there are some unusual use cases, and that I think it's good that gdtoa supports them. > ... > Chuck Best 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@... You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingwusers End of MinGWusers Digest, Vol 60, Issue 5 ****************************************** !DSPAM:4dbeecd4181865675626326! 