Enviado desde mi HTC

----- Reply message -----
De: mingw-users-request@lists.sourceforge.net
Para: <mingw-users@lists.sourceforge.net>
Asunto: MinGW-users Digest, Vol 60, Issue 5
Fecha: lun., may. 2, 2011 19:17


Send MinGW-users mailing list submissions to
mingw-users@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/mingw-users
or, via email, send a message with subject or body 'help' to
mingw-users-request@lists.sourceforge.net

You can reach the person managing the list at
mingw-users-owner@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of MinGW-users digest..."


Today's Topics:

  1. Re: [Mingw-w64-public] Math library discrepancies that
     surprised me. (Keith Marshall)
  2. Re: [Mingw-w64-public] Math library discrepancies that
     surprised me. (Charles Wilson)
  3. Re: [Mingw-w64-public] Math library discrepancies that
     surprised me. (Keith Marshall)
  4. Re: [Mingw-w64-public] Math library discrepancies that
     surprised me. (K. Frank)


----------------------------------------------------------------------

Message: 1
Date: Mon, 02 May 2011 07:34:20 +0100
From: Keith Marshall <keithmarshall@users.sourceforge.net>
Subject: Re: [Mingw-users] [Mingw-w64-public] Math library
discrepancies that surprised me.
To: mingw-users@lists.sourceforge.net
Message-ID: <4DBE506C.4070803@users.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1

On 01/05/11 14:36, K. Frank wrote:
> Hello Keith!
>
> On Sun, May 1, 2011 at 3:43 AM, Keith Marshall
> <keithmarshall@users.sourceforge.net> wrote:
>> On 30/04/11 23:14, Kai Tietz wrote:
>>> long double (80-bit):
>>>  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 floating-point 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 floating-point 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 non-zero 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
37-bit 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@users.sourceforge.net>
Subject: Re: [Mingw-users] [Mingw-w64-public] Math library
discrepancies that surprised me.
To: MinGW Users List <mingw-users@lists.sourceforge.net>
Message-ID: <4DBECE2C.1050603@users.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1

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 floating-point 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 [value-ulps/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 floating-point 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 non-zero 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 base-10 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
> 37-bit 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
> compile-time and run-time evaluations to agree.  We would like
> cross-compilers 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@users.sourceforge.net>
Subject: Re: [Mingw-users] [Mingw-w64-public] Math library
discrepancies that surprised me.
To: mingw-users@lists.sourceforge.net
Message-ID: <4DBED520.6080804@users.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1

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 compile-time and run-time evaluations to agree.  We would like
>> cross-compilers 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@gmail.com>
Subject: Re: [Mingw-users] [Mingw-w64-public] Math library
discrepancies that surprised me.
To: MinGW Users List <mingw-users@lists.sourceforge.net>
Message-ID: <BANLkTi=aMb+QqnLAG_FGPm-0J8t6Zp3gcw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

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 floating-point 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 floating-point 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 floating-point 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 [value-ulps/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 floating-point 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 floating-point 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
floating-point numbers.  But, to reiterate my point, there are use cases
where floating-point numbers are used to exactly represent a special
subset of the real numbers.  These floating-point 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 floating-point numbers and FPU's in situations where the
correctness of the calculations depended upon the floating-point 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
floating-point 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 cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd

------------------------------

_______________________________________________
MinGW-users mailing list
MinGW-users@lists.sourceforge.net

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users


End of MinGW-users Digest, Vol 60, Issue 5
******************************************

!DSPAM:4dbeecd4181865675626326!