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!