Float comparison

[Dik T. Winter]

> On Wed, 29 Apr 2009 10:21:36 GMT, "Dik T. Winter"

>
> I'm sorry, but it seems to me that you are castigating cbf (in
> itself quite the rage these days) quite unfairly. I know what he
> is doing; he is deriving the extent of the bounds of the range of
> x*y and showing that it is the same as the extent of the bounds
> of x+y.

No, you misunderstand. Cbf is stating that a value represents a range.
So when you calculate (in float) z = x * y, z represents a range, bounded
by eps(z). I asked him how it was possible that a possible value for the
ranges represented by x and y could not be in the range represented by z.
He still has not given an answer.

 

[Dik T. Winter]

>
> I don't know why you are changing the nomenclature, and ignoring
> the statement. It has an error factor of "(1 - ex - ey - ex*ey)".
> Note the sum and the product. The product is neglible.

Yes, so it is bounded by eps(x + y), as I did state.

> That is
> not centered on xmy, but is the range on one side. Change the -
> signs to + signs to get the opposite side.
>
> Are we speaking the same language?

Apparently not. You stated that a floating point value in a variable
represented a range. So given z = x * y, z would represent a range,
bounded by eps(z) (where eps(z) is shorthand for an appropriate expression).
I asked you how it is possible that given that x and y represent a range
that the values possible in the (mathematical) result of x * y did *not*
fit in the range represented by z. You avoided this by stating that the
difference was negligible. It is *not*. The bounds for the range of z
are eps(x * y), which can be small compared to eps(x + y) (or large).

 

[Dik T. Winter]

>
> I didn't even do that. I just showed that the range bounds of x*y
> could ignore the product of the individual range errors, and that
> the sum of those errors was the important value.

Which is not in the range represented by z (according to you) after z = x * y.

 

[Richard Tobin]

I asked you how it is possible that given that x and y represent a range
that the values possible in the (mathematical) result of x * y did *not*
fit in the range represented by z.

Simple: a floating point value represents a range, but * does not
represent range multiplication. Of course, this is not a very useful
way of looking at it...

-- Richard

 

[Keith Thompson]

Falconer is treating range as {x-x*eps(x),x+x*eps(x)}, i.e., the
epsilon is proportional error.

[...]

Quibble: I think he's acknowledged that the range is not necessarily
symmetric.

For example, in a typical binary floating-point representation,
the range of values for which the double value 1.0 is the closest
representation goes from 1.0-DBL_EPSILON/2 to 1.0+DBL_EPSILON.
(I won't get into the question of whether the range includes the
end points).

This doesn't significantly affect the underlying points.

 

[Phil Carmody]

No, you misunderstand. Cbf

(whatever that is. In any case, it's not relevant.)

is stating that a value represents a range.

Physics also emphasizes that measurements are inherently inaccurate, [and precising]
measurement
measurement

Heisenburg

measurement
measurement
measurements
measurement
measurement

measurement
measure
measure
measurement
measuring

Sorry, it appears you've mistakenly posted to comp.lang.c,
where we discuss the C programming language. I think you
wanted sci.physics.measuring.things.inaccurately instead.

Phil

 

[Keith Thompson]

(whatever that is. In any case, it's not relevant.)

Cbf is CBFalconer, who's been posting heavily on this thread.

Physics also emphasizes that measurements are inherently inaccurate,
especially when using instruments cheap enough they'll let YOU use
them. Early on you learn that "95.000 inches" implies much greater
measurement accuracy than "95.0 inches", whether you get that
measurement anywhere near a computer or calculator or not.

[snip]

We weren't talking about measurements. We were talking about stored
floating-point values. For example, 95.0 and 95.000 are exactly the
same value in C, and may or may not be the result of any measurement.

A given stored floating-point value might have some error range
associated with it, but the floating-point types themselves are
not capable of representing such an error range.

(Permission to quote my words without proper attribution is denied.
If you don't want to use an ordinary attribution line, quoting
the following is sufficient: I, Keith Thompson <[email protected]>
wrote the above.)

 

[CBFalconer]

.... snip ...

Apparently not. You stated that a floating point value in a
variable represented a range. So given z = x * y, z would
represent a range, bounded by eps(z) (where eps(z) is shorthand
for an appropriate expression). I asked you how it is possible
that given that x and y represent a range that the values possible
in the (mathematical) result of x * y did *not* fit in the range
represented by z. You avoided this by stating that the difference
was negligible. It is *not*. The bounds for the range of z are
eps(x * y), which can be small compared to eps(x + y) (or large).

I used ex and ey for the original errors, and I calculated the
exact error in x*y, which had terms in ex and ey and in ex*ey. I
also stated that ex (and ey) were small compared to x (and y),
which made the error term in ex*ey negligible. You simply ignored
the equations, changed the nomenclature, and, as far as I can see,
ignored the facts.

 

[CBFalconer]

(e-mail address removed) (Gordon Burditt) writes:
.... snip ...

Physics also emphasizes that measurements are inherently inaccurate,
especially when using instruments cheap enough they'll let YOU use
them. Early on you learn that "95.000 inches" implies much greater
measurement accuracy than "95.0 inches", whether you get that
measurement anywhere near a computer or calculator or not.

[snip]

We weren't talking about measurements. We were talking about stored
floating-point values. For example, 95.0 and 95.000 are exactly the
same value in C, and may or may not be the result of any measurement.

A given stored floating-point value might have some error range
associated with it, but the floating-point types themselves are
not capable of representing such an error range.

Right there is our fundamental disagreement. FP objects can only
store discrete values, with defined intervals between the available
values. Thus you can never tell which value in that range was
stored, without detailed knowledge of the associated code. The
ranges are inherent in the storage mechanism, and their sizes are
represented by the various x_EPSILON values.

 

[Keith Thompson]

Keith Thompson wrote: [...]

We weren't talking about measurements. We were talking about stored
floating-point values. For example, 95.0 and 95.000 are exactly the
same value in C, and may or may not be the result of any measurement.

A given stored floating-point value might have some error range
associated with it, but the floating-point types themselves are
not capable of representing such an error range.

Right there is our fundamental disagreement.

I agree with that statement. It's also your fundamental disagreement
with the clear wording of the standard.

FP objects can only
store discrete values, with defined intervals between the available
values.

Correct! Dare I hope that you might be beginning to see my point?

Thus you can never tell which value in that range was
stored, without detailed knowledge of the associated code.

No, you can tell exactly what value was stored. I am frankly
astonished by your persistence in ignoring C99 6.2.4p2:

An object exists, has a constant address, *and retains its
last-stored value* throughout its lifetime.

(Emphasis added.)

For example, given:
double d;
d = 1.0/3.0;
the value stored (on my system) is exactly
0.333333333333333314829616256247390992939472198486328125
No more, no less. How do I know? I printed it with printf().

The mathemetical value 1.0/3.0 was *never stored* in d, because that
value *cannot* be stored in an object of type double (on my system,
and probably on yours).

I think you're claiming that the mathematical value 1.0/3.0 was
somehow stored in d, but that d doesn't retain that value. That is
directly contradicted by 6.2.4p2.

The
ranges are inherent in the storage mechanism, and their sizes are
represented by the various x_EPSILON values.

No, the *storage* mechanism simply stores one of the finitely many
representable values for the type in an object of that type. Errors
(i.e., discrepancies between representable FP values and mathematical
real values) may occur during computations, *not* when a result is
stored. (Even if intermediate expressions are computed in greater
precision, the conversion from the greater precision to the object's
type is just another computation.)

 

[CBFalconer]

Keith Thompson wrote: [...]

We weren't talking about measurements. We were talking about stored
floating-point values. For example, 95.0 and 95.000 are exactly the
same value in C, and may or may not be the result of any measurement.

A given stored floating-point value might have some error range
associated with it, but the floating-point types themselves are
not capable of representing such an error range.

Right there is our fundamental disagreement.

I agree with that statement. It's also your fundamental disagreement
with the clear wording of the standard.

FP objects can only
store discrete values, with defined intervals between the available
values.

Correct! Dare I hope that you might be beginning to see my point?

Thus you can never tell which value in that range was
stored, without detailed knowledge of the associated code.

No, you can tell exactly what value was stored. I am frankly
astonished by your persistence in ignoring C99 6.2.4p2:

I don't think we are ever going to agree, and this has pretty well
reduced itself to reiterating the same arguments. I know I am
right, and you know you are right (but are actually wrong so we
might as well abandon the argument.

 

[Keith Thompson]

Keith Thompson wrote: [...]

No, you can tell exactly what value was stored. I am frankly
astonished by your persistence in ignoring C99 6.2.4p2:

I don't think we are ever going to agree, and this has pretty well
reduced itself to reiterating the same arguments. I know I am
right, and you know you are right (but are actually wrong so we
might as well abandon the argument.

Yes, as long as you ignore my arguments, this is pointless.

 

[Guest]

I am puzzled.  I haven't seen anything in your text that matches
the "I asked him how ..." nor do I see any reason for expecting
that x and y would necessarily be in the range for x*y.  I get
the feeling that you are using the term "range" in some sense
that I am not recognizing.  To reprise:

Falconer is treating range as {x-x*eps(x),x+x*eps(x)}, i.e., the
epsilon is proportional error.  From this definition he goes on
to get eps(x*y) = eps(x) + eps(y) which is correct to the first
order.  It is quite clear that that is what he is doing.  What,
if anything, do you see as error in his analysis, given his
definition?

You seem to be defining range as {x-ex,x+ex} from which one gets
(to the first order) ez = x*ey + y*ex.  This is equivalent to
what Falconer's formula, allowing for the translation from one
definition to the other.

As to your question, perhaps a simple example will clarify
things.  Let range(x) = {990,1010} and range(y) =
{.00099,.00101}.  Falconer would give a range for x*y as
range(x*y) = {.98,1.02}.  You appear to be claiming that the
range should be {.00099,1010} or something similar so that both x
and y are in the range of x*y.

that's how I read it as well (and I read it thrice to be sure).
It confused me.

I Am Not A Numerical Analyst (IANANA) so I confuse easily.

 

[Guest]

On 4 May, 20:22, (e-mail address removed) (Gordon Burditt) wrote:

Physics also emphasizes that measurements are inherently inaccurate,
especially when using instruments cheap enough they'll let YOU use
them.  Early on you learn that "95.000 inches" implies much greater
measurement accuracy than "95.0 inches", whether you get that
measurement anywhere near a computer or calculator or not.

ah, if only most people did learn this...

There's even this guy Heisenburg who says that you can't simultaneously
know the position and momentum of something (typically a particle,
but this also applies to posters and planets) to arbitrary precision.
Perfect precision isn't even possible.

Heisenburg's principle doesn't practically apply to planets
or other macroscopic objects.


<snip>

 

[Guest]

I don't think we are ever going to agree, and this has pretty well
reduced itself to reiterating the same arguments.  I know I am
right, and you know you are right (but are actually wrong so we
might as well abandon the argument.

I draw the analogy with chess. Once the same position has been
repeated
a few times it's a draw. Applying this rule cuts out many more-heat-
than-light
arguments.

 

[TonyMc]

Heisenburg's principle doesn't practically apply to planets
or other macroscopic objects.

I suspect the spelling "Heisenburg" has arisen as a superposition of
states in which the eigenstates are the strings "Heisenberg" and
"Heisenbug". Measuring this spelling in comp.lang.c will probably cause
a collapse to the state |"Heisenbug">. Measuring it in a group devoted
to discussion of the German physicist Werner Heisenberg would probably
have a different outcome. Of course, if you are a Many Worlds devotee
(or subscribe to both newsgroups), both could happen.

Tony

 

[James Kuyper]

On 4 May, 20:22, (e-mail address removed) (Gordon Burditt) wrote: ....

Heisenburg's principle doesn't practically apply to planets
or other macroscopic objects.

He said "arbitrary precision" and "perfect precision". The Heisenberg
principle rules those out just as much for macroscopic objects as for
sub-atomic ones. It's just that the limits it imposes are much less
noticeable for the macroscopic ones.

 

[Kenny McCormack]

Keith Thompson wrote: [...]

No, you can tell exactly what value was stored. I am frankly
astonished by your persistence in ignoring C99 6.2.4p2:

I don't think we are ever going to agree, and this has pretty well
reduced itself to reiterating the same arguments. I know I am
right, and you know you are right (but are actually wrong so we
might as well abandon the argument.

Yes, as long as you ignore my arguments, this is pointless.

I heard about this time, back in 1997, I think, where Keith Thompson
actually let something go in CLC. As hard as it is to believe, he
didn't insist on having the last word.

Dare I hope for a recurrence?

 

[Keith Thompson]

This is one of those occasions where both are right, because the
two of them are viewing the issue from different perspectives.
If we look at floating point numbers (which are not the same
thing as Real numbers) from the perspective of the
implementation, e.g. the formalism of C, they are exact, i.e.,
the value is whatever the bit pattern signifies. If we look at
them from the perspective of the application they are not exact,
i.e., a floating point number can represent any of a range of
values.

[...]

But my argument was made almost entirely in the context of the
formalism of C (you may note with relief my use of the past tense).
I repeatedly acknowledged that a stored floating-point value might
indicate a range in the context of a particular application.

 

[jameskuyper]

Richard Harter wrote:
....

This is one of those occasions where both are right, because the
two of them are viewing the issue from different perspectives.
If we look at floating point numbers (which are not the same
thing as Real numbers) from the perspective of the
implementation, e.g. the formalism of C, they are exact, i.e.,
the value is whatever the bit pattern signifies. If we look at
them from the perspective of the application they are not exact,
i.e., a floating point number can represent any of a range of
values.

I don't think that's an accurate description of the disagreement.

I'm not entirely sure what CBFalconer is saying, but he's given me the
strong impression that he believes that floating point numbers, "from
the perspective of the implementation, e.g. the formalism of C" do not
represent represent exact values, but ranges.

I think I do understand what Keith is saying, and as I understand it,
what he means is that "from the perspective of the application", a
given floating point number can be treated either as representing a
range of value, or as representing only a single discrete value. It's
a matter of how the application is designed, not a matter of the
underlying hardware, nor the requirements of either the C or IEEE/IEC
standards, how they are to be interpreted. Exactly the same thing can
be said of integer types - the main difference is that the spacing of
representable integers is constant, whereas the spacing of
representable floating point numbers is not.