Float comparison

[Guest]

His entire argument is fundamentally wrong, resting as it does on a
confusion between mathematics and floating-point hardware.

FP hardware does correspond to some mathematics. Just not the
mathematics
of Reals.

 

[Guest]

Why do you use the phrase "fp-object-value" rather than just
"fp-value"?

I think Chuck's hardware actually does its FP maths with actual Real
numbers. Presumably it has a RN accelerator and stores intermediate
values in RN registers. It's only when it has to stuff the result into
C's measely FP values that it has to down-cast. So an fp-object-value
is what you find in a FP-object as opposed to the real Real value.

A value in C can be the result of evaluating an expression; it needn't
be stored in or retrieved from an object.  We don't need to introduce
FP objects in order to discuss FP values.

No we simply store the Real Number value.

Are you saying that, if you have an FP value, and you store that value
in an FP object and then retrieve the value of that object, the result
can be something different from the FP value you started with?

no no no. If we have a Real value and we store it in a FP object
then retrieve it- you don't get the Real value back again.

He's convinced me.


--

Infinitely many bits doesn't give you "100% accuracy". You will
only be able to represent the algebraic numbers.

Sure, if you use one of those old-fashioned implementations that only
has aleph-null-bit floating-point. Any decent modern implementation
should provide at least aleph-one bits.
(Bill Pursell and Keith Thompson clc)

 

[Dik T. Winter]

> "Dik T. Winter" wrote: ....
>
> I doubt that the average library has thoroughly tested nextafter(),
> and would expect bugs to be likely to show up with second arguments
> of +INF, 0, -INF. Especially the INFs.

You think so? When it is an IEEE required instruction?

 

[Dik T. Winter]

>
> Oh dear. This is a whole new concept.

Indeed. I think the smallest real *that can be expressed in the fp-system*
and that is stored as y, is y itself.

 

[Dik T. Winter]

> Now, what is the EPSILON involved here. Obviously if we add 1/8 to
> 1.0, we get the next value. But that doesn't consider the rounding
> done by the hardware. We only need to add 1/16 to get that
> effect.

Depends. Consider the round to even rule in IEEE arithmetic...

 

[Ben Bacarisse]

Lets see if I can leap over the confusion. Consider a system with
a 4 bit significand, and an 8 bit exponent. The exponent uses the
value 128 to signify times 2 to the 0th power. We suppress the
msbit in the significand and replace it with a sign bit. The
significand can hold 0 through 15. Thus:

Exponent Significand Means
128 0 = 0x0 1.0
128 1 = 0x1 1.0 + 1/8
128 2 = 0x2 1.0 + 1/4
128 4 = 0x4 1.0 + 1/2
128 7 = 0x7 1.0 + 7/8
128 8 = 0x8 -1.0 /* the sign bit appeared */
128 9 = 0x9 -1.0 - 1/8
128 10 = 0xa -1.0 - 1/4
128 12 = 0xc -1.0 - 1/2
128 15 = 0xf -1.0 - 7/8

if we raise the exponent by 1, we double the value in Means. If we
lower it by one, we halve the values in Means. I hope we are
agreed so far.

I would not conflate the sign bit and the significand. I'd describe
this as a 3 bit normalised significand, but that is a detail.

Now, what is the EPSILON involved here. Obviously if we add 1/8 to
1.0, we get the next value. But that doesn't consider the rounding
done by the hardware. We only need to add 1/16 to get that
effect. What is the value 1/16 in that system?

127 0 1/2
126 0 1/4
125 0 1/8
124 0 1/16 /* Aha */

1.0 + 1/16 will round up to 1.0 + 1/8. /* assume usual rounding */

What does this result look like? See above. Only one least
significant bit is changed. So we have found EPSILON to be 1/16,
and the result from nextafter would be 1.0 + 1/8.

As Ike Naar has already pointed out, EPSILON is 1/8 in this system.
I'll skip your x*(1-EPSILON) to x*(1+EPSILON) description of the
ranges since it seems to be based on a misconception and consider the
other definition using xmax and ymin.

With x = 1, y = 1+1/8. What is the smallest real that will get stored
as 1+1/8? Note that this is a theoretical question. The FP system
never sees real numbers to convert, but we can extend what we expect
from it to answer the question. With at least one rounding model, any
real >= to 1+1/16 will convert to y so xmax might well be 1+1/16.

What about ymin? For any e > 0, 1+1/16-e will convert to x so what is
the largest such value? The limit is xmax and the simplest shorthand
is to say that ymin == xmax and describe the "ranges" as open or
(better) half-open intervals.

A different rounding model will make ymin = 1+1/6 and xmax the limit
of 1+1/16+e as e -> 0. Because the reals are closed under such limit
operations, your definitions defined a unique single value at the
boundary between the "ranges" represented by FP values.

<snip>

 

[Keith Thompson]

FP hardware does correspond to some mathematics. Just not the
mathematics
of Reals.

Well, sort of. It corresponds (in a manner defined by C99 5.2.4.2.2)
to a particular subset of the mathematical reals.

 

[Guest]

Well, sort of.  It corresponds (in a manner defined by C99 5.2.4.2.2)
to a particular subset of the mathematical reals.

10.0 / 3.0 * 3.0

doesn't give the answer (on most computers) that I'd expect for reals

 

[Keith Thompson]

10.0 / 3.0 * 3.0

doesn't give the answer (on most computers) that I'd expect for reals

Of course not; "/" and "*" in that expression are floating-point
operators, not real operators. But each operand, each intermediate
result, and the final result of the expression are all floating-point
numbers and therefore real numbers.

Incidentally, have you tried it? It yields exactly 10.0 on my system
(though it's not required to).

 

[Phil Carmody]

CBFalconer said:

*NO* real values can be handled by the floating-point system except
by the most laughable of coincidences.

Contrived, yes, but not particularly laughable.

Phil

 

[CBFalconer]

.... snip ...

If I understand you correctly, the range for the FP value 1.0 (x)
extends from 1.0 up to (but perhaps not including) 1.0+DBL_EPSILON.

Definitely NOT including.

And the range for the FP value 1.0+DBL_EPSILON (y) extends from
1.0+DBL_EPSILON down to (but perhaps not including)

Definitely NOT including. Also the upper value for y (ymax) is
slightly more than DBL_EPSILON from the fp-object-value of y.

1.0+DBL_EPSILON*(1.0-DBL_EPSILON). This means that most of the

No. The real number 1.0+DBL_EPSILON is not a fp-object-value. It
is a number that will, when stored in a fp-object, cause that
object to be the adjacent one to x and larger than x. I.e. y. Now
remember that y is > x. Thus the reduction in y via
y*(1-DBL_EPSILON) (=ymin) is greater than the earlier increase in x
(which generated y). Here I am using real numbers. Thus ymin <
xmax. There is NO overlap. I got this part straight a few days
ago.

numbers between 1.0 and 1.0+DBL_EPSILON are in both ranges. It also
means that there's a very small range of numbers just above 1.0 that
are within the range of x, but not within the range of y.

Is that really what you meant?

No. See above. Don't forget that the only use for xmax, xmin,
ymin, ymax are to be stored (or attempted) into an fp-object to
form fp-object-values adjacent above 1.0 (y) or adjacent below y
(x).

You're insisting in extending the meaning of DBL_EPSILON far beyond
what the standard says about it, in a manner that yields inconsistent
results.

Yes. I am maintaining what the standard says about it. The rest
is based on my knowledge of the construction of fp systems. That's
why using the value 1.0 causes difficulties, because the EPSILON
value changes as the value gets below 1.0 (by a factor of 2, in
most systems).

 

[CBFalconer]

Flash Gordon wrote:

... snip ...

Give me a link to the paper, and I will _try_ to get around to
reading it. I seem to spend ALL my spare time answering questions
here lately.

I keep seeing some responses to my messages from Richard noname.
He is PLONKED as a troll, and thus the actual messages are not
transmitted to me.

 

[CBFalconer]

CBFalconer said:
.... snip ...


C doesn't know it's approximating. C doesn't understand the
concept of real numbers. You're trying to wedge knowledge into
the floating-point system that it simply doesn't have (and
can't have).

Of coarse it doesn't understand. That's why it has a fp-system, to
present approximations to the real number system that can make
sense to the more knowledgeable human beings. Now those humans
need to know what effects those approximations have on their
calculations.

....

 

[CBFalconer]

All those real values exist in mathematics. They do not exist in
C. If this were sci.math, we might be having a very different
conversation.

They certainly do exist in C. All I have to do is build a rational
arithmetic system to process 1/3. If I feed it the integers 1 and
3 in the appropriate slots, I can do anything I want with the value
1/3.

They don't exist in the fp-system. That's different.

 

[CBFalconer]

.... snip ...


No, the inputs are the int value 1 and the int value 3.

No. I can put them in a structure:

typedef struct rational {int numer, int denom} rational;

const rational onethird = {1, 3}; /* <--- this thing */

/* convert a rational to an fp representation */
float formfloat(const rational r) {
return (float)r.numer / r.denom;
}

 

[CBFalconer]

.... snip ...

Are you saying that, if you have an FP value, and you store that
value in an FP object and then retrieve the value of that object,
the result can be something different from the FP value you
started with?

Replace fp-value with real value, and the answer is YES.

 

[CBFalconer]

.... snip ...


no no no. If we have a Real value and we store it in a FP object
then retrieve it- you don't get the Real value back again.

^
^- necessarily

He's convinced me.

Whew. Thanks. At last. I trust this indicates the beginning of a
rush to convert.

As this goes on I am getting more consistent, and gradually
appreciating the prevalent mental blockages.

 

[CBFalconer]

.... snip ...

That definition of EPSILON is not in line with the definition in
the C standard. You yourself even mentioned the standard definition
elsethread:


The least value >1 that is representable in your floatingpoint
system is 1 + 1/8 (1.125); it's the number with exponent=128 and
significand=1. Subtracting 1 from that value yields EPSILON = 1/8
(0.125) .

It would be less confusing if you stick to the standard terminology,
and use a name other than "EPSILON" for the value 1 + 1/16 .

I haven't gone over things exactly, but I think if you consider
that EPSILON is a real value rather than a fp-object-value, things
work out as I said.

 

[CBFalconer]

.... snip ...

As Ike Naar has already pointed out, EPSILON is 1/8 in this system.
I'll skip your x*(1-EPSILON) to x*(1+EPSILON) description of the
ranges since it seems to be based on a misconception and consider
the other definition using xmax and ymin.

With x = 1, y = 1+1/8. What is the smallest real that will get
stored as 1+1/8? Note that this is a theoretical question. The
FP system never sees real numbers to convert, but we can extend
what we expect from it to answer the question. With at least one
rounding model, any real >= to 1+1/16 will convert to y so xmax
might well be 1+1/16.

What about ymin? For any e > 0, 1+1/16-e will convert to x so
what is the largest such value? The limit is xmax and the
simplest shorthand is to say that ymin == xmax and describe the
"ranges" as open or (better) half-open intervals.

I disagree. ymin is calculated from y, which is >x. Thus the
epsilon is greater, where (y-epsilon)==(y*(1-EPSILON)); But ymin
comes from x, and is X+EPSILON. This makes ymin < xmax. These are
reals, not fp-object values.

 

[CBFalconer]

He's asking you to do the calculation *for your implementation*.

Don't see what good that does. If this ever calms down maybe I
will get a chance to write something that illustrates the points,
and is portable.