Float comparison

[CBFalconer]

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

Of course. But there are infinitely many other reals that are not
equal to y, and will be expressed as y. I used 'represented by' to
express this fact.

 

[CBFalconer]

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

Somewhere, sometime, I specified 'the usual rounding', or similar.

 

[CBFalconer]

.... snip ...

I asked about your machine, not my machine. I SPECIFICALLY asked
about yours because you have access to it.

Here is the corrected program...

#include <math.h>
int main(void)
{
double valone = 1.0;
double valoneandabit = nextafter(valone, 100.0);
/* rest of program irrelevant to discussion */
return 0;
}

Now please tell me on YOUR computer, on YOUR C implementation, the
EXACT numeric ranges. You can't claim you don't have the
information for this, since I'm not asking you to look at anything
other that your own implementation.

I don't see the point in that. I hope to write a demonstration
program sometime when this has calmed down. Right now I have no
time for it. I have given the values expressed in terms of the
appropriate EPSILON values in float.h, which are portable TO
SIMILAR fp-systems. Most are similar.

Actually, I can't even do it because my library is not a C99
library, and it doesn't include nextafter. I don't have any c99
library, and I am not going to bother to write a nextafter. I have
shown how you can get the same result from the appropriate EPSILON.

 

[Ike Naar]

ROTFLM!!!!!!!!!!!!!!!!!!!!!!

Rolling On The Floor Laughing My Exclamation Marks?

 

[CBFalconer]

.... snip ...

And here you're making a false distinction between "the value to
be stored" and "the value actually stored". There is no such
distinction. The value to be stored *is* the value actually
stored, and it's the value yielded by the "/" operator. And
that value is an approximation to one-third. The real value
one-third does not exist in the program, and cannot even be
expressed in C (at least not in this kind of context; of
course you can build a rational number package, but that's
irrelevant to the point).

No, the point is that I expressed the exact real value 1/3 by
specifying the integers 1 and 3. So the program knew what I
wanted. The exact point at which it made the approximation doesn't
really matter, and can be moved about in various ways. A rational
package is not irrelevant, because it shows that we can handle the
concept in C, and get exact results, for many values that the
fp-system cannot handle (at least exactly).

This thrashing about is actually worthwhile, because it exposes the
errors made by each of us. I have certainly contributed my share,
and have learned to keep some things clear in the process.

 

[CBFalconer]

No, it used an algorithm designed to compute a value close to
one third.

People do not seem to appreciate my attempt to inject a touch of
humor/humour.

 

[CBFalconer]

.... snip ...

When you wrote "EPSILON defines the minimum increment to x ...",
I took that to mean that "EPSILON *is* the minimum increment to
x". After going back and forth a number of times, I think what
you actually meant is that the minimum increment to x *can be
computed* from EPSILON.

Do I now correctly understand what you mean by EPSILON? (And
do you see how your original statement could have been
misleading?)

I think so. However that does not prevent both statements from
being true. Equally, it doesn't insist on both being true.

 

[CBFalconer]

Really? Why don't you try it and get back to us. I'd be
astonished if a released library had bugs like the ones you say
you expect.

Because I have discovered that I don't have a nextafter in my
library. From which I conclude it is a C99 function.

 

[Ben Bacarisse]

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.

I can't parse this at all. Is ymin not the largest real that
(theoretically) converts to x (y's predecessor)? Is EPSILON not 1/8
in your example system? Does "(y-epsilon)==(y*(1-EPSILON))" use real
or floating point operations (i.e. how much does the last "these"
refer to?

I tried to complete your example by you disagree with my result. You
tell us. Give x = 1.0 what are y, xmax and ymin in your 3-bit
floating point example? It sounds as if you think this idea is a
simple one, so show us how simple it is by showing us a what a few
numbers represent (i.e,. what ranges) in your simple example system.

 

[Keith Thompson]

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.

Ok, you can write C code to represent just about anything.

But they don't exist in a C program *unless* you build a rational
arithmetic system or something similar.

For example:

#include <stdio.h>
int main(void)
{
double x = 1.0/3.0;
printf("%a\n", x);
return 0;
}

The real value one-third does not exist anywhere in this C program.
The "/" operator takes two floating-point operands and yields a
floating-point result. The real value one-third is never generated,
not even as an intermediate result.

 

[Keith Thompson]

No. I can put them in a structure:

[snip]

But in the code you posted you didn't put them in a structure, so
what's your point?

You claimed that the inputs (i.e., arguments) to the function that you
posted define the real value 1/3. They do not; they are simply the
int values 1 and 3. You can attach any meaning to them that you like,
but that's not what we're talking about; we're talking about the
meaning defined by the standard.

 

[Keith Thompson]

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

That's nice. Now would you care to answer the question that I
actually asked?

 

[Keith Thompson]

Don't see what good that does.

Please humor us anyway.

If this ever calms down maybe I
will get a chance to write something that illustrates the points,
and is portable.

For now, a concrete example for your implementation will suffice.

 

[Keith Thompson]

No, the point is that I expressed the exact real value 1/3 by
specifying the integers 1 and 3. So the program knew what I
wanted.

Isn't that a bit anthropomorphic? Programs don't *know* anything.

The exact point at which it made the approximation doesn't
really matter, and can be moved about in various ways.

The point at which *the posted code* makes the approximation is very
well defined. The approximation occurs during the evaluation of the
"/" operator.

A rational
package is not irrelevant, because it shows that we can handle the
concept in C, and get exact results, for many values that the
fp-system cannot handle (at least exactly).

I agree, except that a rational package is almost completely
irrelevant. We're talking about the behavior of code that uses
floating-point types.

[snip]

 

[Keith Thompson]

People do not seem to appreciate my attempt to inject a touch of
humor/humour.

I honestly couldn't tell that you were joking.

You've been making numerous technical claims here that are, in my
opinion, not only incorrect but nonsensical. It's difficult to
distinguish between your nonsensical claims that you actually believe
and the ones that are meant to be humorous.

(If it turns out that this whole thing was your idea of a joke, I will
not be happy.)

 

[Keith Thompson]

I think so. However that does not prevent both statements from
being true. Equally, it doesn't insist on both being true.

Are you *trying* to confuse the issue?

So, are both statements true?

 

[Keith Thompson]

Because I have discovered that I don't have a nextafter in my
library. From which I conclude it is a C99 function.

And you concluded from this that actual released implementations are
likely to be buggy how, exactly? Never mind, I probably don't want to
know.

 

[Keith Thompson]

Definitely 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.

Why is it "slightly more"? Are you saying that ymax > 1.0+DBL_EPSILON*2
(as a real, not FP, expression)? By how much?

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.

I think we need to clarify what xmin, xmax, ymin, and ymax actually
mean. I think perhaps you've swapped the intended meanings of xmax
and ymin somehow.

In your model, a floating-point value (let's say it's stored in a
floating-point object) represents a range of real values.

The FP value x (or FP-object-value, if you insist) represents the
range xmin .. xmax. We can leave aside for now the question of
whether the endpoints are included. The FP value y represents the
range ymin .. ymax.

This is how I am defining xmin, xmax, ymin, and ymax.

Can you agree with that? If not, where do you see a problem?

Now, given that x and y are adjacent FP values (i.e.,
nextafter(x, +INFINITY) == y), I believe it follows that xmax == ymin.
Otherwise, there is either an overlap or a gap between the ranges
represented by x and y.

[...]

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).

I think your knowledge of fp systems is flawed, or at least
inconsistent with the C standard.

I've asked you this before but ... if your model is valid, then it is
a set of fundamental facts about floating-point numbers, facts without
which it is difficult or impossible to understand what FP numbers
really mean. Why then does the standard say so little about these
ranges of yours? If you had written C99 5.2.4.2.2, I presume the word
"range" would have appeard many times; why does the standard use the
word "range" only in reference to the full range of a floating-point
type, never to the range represented by a single value?

 

[CBFalconer]

.... snip ...

For example:

#include <stdio.h>
int main(void) {
double x = 1.0/3.0;
printf("%a\n", x);
return 0;
}

The real value one-third does not exist anywhere in this C program.
The "/" operator takes two floating-point operands and yields a
floating-point result. The real value one-third is never generated,
not even as an intermediate result.

Yes it does (usually). That is not a static value. The C system
has generated initialization code, that is executed on the entry to
the function, which reserves the space and initializes it. It MAY
have generated a fp-constant to be jammed in, but it more likely
generates a 1.0 and a 3.0 and tells the system to perform a divide
and store the result. When the 1 and the 3 exist, and not the
fp-value, you have the actual one-third real value indicated.
After the storage, it has been approximated.

C (non-static) initialized objects are quirky. They really consist
of calls to some routine or other to set the value in the object,
and maybe to calculate it. That's why they can be fairly complex.
The code is still there.

 

[CBFalconer]

No. I can put them in a structure:

[snip]

But in the code you posted you didn't put them in a structure, so
what's your point?

But the only purpose of any code was to illustrate ways of
specifying EXACTLY the real 1/3. And thus to illustrate the rough
point at which that specification was converted into an fp-object
approximated value. If you had worked with transcendentals
generating the specification would have been harder.