Float comparison

[Keith Thompson]

I maintain that your example is using 'other facts, such as overall
program structure'.
Yes.

I am talking about what the user can get by
examining the contents of the object x.

There are (at least) two things that the contents could mean. They
could mean the exact value 1.0, or they could mean a range of values
including 1.0. You are choosing one of these meanings over the other,
and I maintain that you have no valid basis for doing so.

 

[Keith Thompson]

Phil Carmody wrote: [...]

What's four divided by three?

In what representation? Several possible C answers are:

1
1.3
1.33
...
1.3333333
4/3

Note that none of those are equal to another.

[...]

Correction: 1 is equal to 4/3.

 

[CBFalconer]

.... snip ...


There are (at least) two things that the contents could mean.
They could mean the exact value 1.0, or they could mean a range
of values including 1.0. You are choosing one of these meanings
over the other, and I maintain that you have no valid basis for
doing so.

Not quite. The 'exact' assumption is subsidiary to the 'range'
assumption, since it is included. Also, as far as C is concerned,
the language gives us specific ways of determining the range for
any value. And, if you take the 'exact' assumption, you have no
way of storing 1/3.0.

If you make an assumption it has to apply to the whole floating
point class. Without reference to other code etc. you can't say
this item has characteristic one, and that has characteristic two.

 

[Keith Thompson]

Not quite. The 'exact' assumption is subsidiary to the 'range'
assumption, since it is included.

No. The exact value is included in the range, but your conclusion
that one assumption is subsidiary to the other does not follow.

There are two *mutually exclusive* interpretations. One is that a
stored floating-point value means a single exact value. The other is
that is means a range of values. Either interpretation could be valid
in a particular context for a particular application.

Also, as far as C is concerned,
the language gives us specific ways of determining the range for
any value.

I suppose so, though I'm not quite sure what you mean.

And, if you take the 'exact' assumption, you have no
way of storing 1/3.0.

Correct. I never said otherwise. All I can do is store a close
approximation of 1/3.0. (Unless FLT_RADIX is a multiple of 3, but
that's unlikely.)

If you make an assumption it has to apply to the whole floating
point class.

First, why? Second, I'm *not* making an assumption; you are. I'm
presenting two models for the meaning of a floating-point value;
you're asserting that only one of them can be correct. I have yet to
see a convincing argument that you're right.

Without reference to other code etc. you can't say
this item has characteristic one, and that has characteristic two.

But with reference to other code, you can.

 

[Phil Carmody]

I think it does. A decimal constant must be converted to the nearest
representable value (6.4.4.2 p3), and FLT_RADIX must be an integer
constant (5.2.4.2.2 p1). When the floating point radix is integral,
1.0 is always representable.

I didn't notice a lower bound on e_min. So just 5.2.4.2.2p1,p2 on
their own don't guarantee that 1.0 is expressible exactly as a FP
type. If e_min>p, then it isn't.

However, p9 seems to provides the ability, as 1.0 can be represented
with 1 decimal digit, and 1<=6.

Phil

 

[Phil Carmody]

Well, since you seem happy processing gibberish, I will restore the
missing quote for the benefit of other readers.

What is the difference between the "real value" of a FP variable,
and simply its value?

Your argument appears to be about whether the angels on the
pinhead can dance in pairs or not?

Phil

 

[Phil Carmody]

Phil Carmody wrote:

[...]

May I restore:
"""

Are C integers exact?
Yes.
"""

In what representation? Several possible C answers are:

1
1.3
1.33
...
1.3333333
4/3

Note that none of those are equal to another.

[...]

Correction: 1 is equal to 4/3.

Thank you Keith, I was considering what reply to make, but I think
you've found the place where the most leverage can be exerted.

1 is equal to 4/3 only in the "exact" C integers.

I'm hoping this might trigger a realisation that operations and values
are distinct things.

Phil

 

[Guest]

I maintain that your example is using 'other facts, such as overall
program structure'.  I am talking about what the user can get by
examining the contents of the object x.

I'd say you had this exactly backwards. It is a fact that a floating
point "cell" (what's the word for thingy-that-holds-a-floating-point-
value?)
holds an exact value. It's a certain pattern of bits that doesn't
change. In a certain context you may choose to interprate this in one
of
(at least) two ways. It can be an exact value (1.0 is exactly 1 [1])
or
a range of values. Without knowing how the program is using the
floating
point variables you can't tell if it is meant to be exact or not.

[1] I am assuming (unwisely?) that the C standard doesn't allow
floating point systems that are so insane this isn't true.

 

[Guest]

May I restore:
"""


Yes.
"""

Whilst I think Chuck is wrong headed in his beliefs about floating
point. I've no idea what point Phil Carmody and Keith Thompson are
actually trying to make.


or the conventional mathematical 4/3

Thank you Keith, I was considering what reply to make, but I think
you've found the place where the most leverage can be exerted.

1 is equal to 4/3 only in the "exact" C integers.

I'm hoping this might trigger a realisation that operations and values
are distinct things.

nope. No idea what you are on about. Why would *anyone* need it
explained to them that operations and values are distict. An operation
is a mapping value->value it plainly isn't a value. Well I suppose
it might be in a functional language. Hmm. Try again. "Values and
operations
on those values are distinct". Ok. So what?

 

[Keith Thompson]

I'd say you had this exactly backwards. It is a fact that a floating
point "cell" (what's the word for thingy-that-holds-a-floating-point-
value?)

Object. (Or "variable" if you want to be a bit less formal.)

holds an exact value.

[...]

 

[BartC]

I don't think anyone has said that there are not numbers that can
be stored exactly in a floating point object. What has been said
is that a number in a floating point object never represents an
exact number, rather it represents a range of numbers.

Let's take a floating pointing system with 1-bit precision. It should be
able to represent the set:

.... 1/4 1/2 1 2 4 8 16 ....

What you're saying is that the value 8 really represents the range of values
from 6 to 12 (or perhaps 5.6 to 11.3, or even 8 to 15.999..) and therefore
you can't just assume that 8 is 8. (And so 8==8 is meaningless because
you're really comparing (6...12)==(6...12).)

What I'm saying is that 8 in this representation can be considered just 8.
And that 8==8 is well-defined (as in fact it is). Any higher interpretation
is up to the programmer.

 

[Guest]

(e-mail address removed) writes:

[...] It is a fact that a floating point "cell"
(what's the word for thingy-that-holds-a-floating-point-
value?)

Object. (Or "variable" if you want to be a bit less formal.)

the word the standard uses. Nowadays it seems to have acquired some
baggage from being associated with OOP. Are constants "variables"?
Are literals "variables"?

How about "Storage Location" (I'm having flash backs to a course
on programming languages which involved inventing a whole meta-
language.
Must dig the notes out.)

<snip>

 

[Dik T. Winter]

> Not quite. The 'exact' assumption is subsidiary to the 'range'
> assumption, since it is included. Also, as far as C is concerned,
> the language gives us specific ways of determining the range for
> any value. And, if you take the 'exact' assumption, you have no
> way of storing 1/3.0.

I do not think the C standard does anything of that. On the other hand,
if you look at the IEEE standard, you will find that all operations are
defined with exact values of the operands in mind.

 

[TonyMc]

Correction: 1 is equal to 4/3.

Nit picking here, but the full stop at the end of that sentence makes
the correction false.

Best,
Tony

 

[Keith Thompson]

[...] It is a fact that a floating point "cell"
(what's the word for thingy-that-holds-a-floating-point-
value?)

Object. (Or "variable" if you want to be a bit less formal.)

the word the standard uses. Nowadays it seems to have acquired some
baggage from being associated with OOP. Are constants "variables"?
Are literals "variables"?

I don't think it's a problem. If you use the phrase "floating-point
object", nobody is going to misunderstand.

BTW, the C++ standard does define the word "variable" (and the
definition includes things that aren't actually able to vary),
but C doesn't. Nevertheless, given something like:

double x = 1.0;

it's safe to say x is a variable.

[...]

 

[CBFalconer]

.... snip ...


I suppose so, though I'm not quite sure what you mean.

The existence of the x_EPSILON values in float.h. Multiplied by
the actual stored value, they give the range.

.... snip about exact versus range ...

First, why? Second, I'm *not* making an assumption; you are. I'm
presenting two models for the meaning of a floating-point value;
you're asserting that only one of them can be correct. I have yet
to see a convincing argument that you're right.

I maintain that all you can see, without bringing in the usage
(i.e. the external coding) is the stored value. That doesn't
guarantee exactness. Yes, if you are very careful you can write a
system that guarantees exactness, but you will have to be extremely
careful about what values you allow in what expressions
everywhere. This doesn't seem practical.

 

[CBFalconer]

I do not think the C standard does anything of that. On the other
hand, if you look at the IEEE standard, you will find that all
operations are defined with exact values of the operands in mind.

It doesn't specify it because it is obvious. Please describe how
you would store the exact value of 1.0/3.0 in a floating point
format. Do you deny the usefulness of that quantity?

 

[CBFalconer]

.... snip ...

I maintain that your example is using 'other facts, such as
overall program structure'. I am talking about what the user
can get by examining the contents of the object x.

I'd say you had this exactly backwards. It is a fact that a
floating point "cell" (what's the word for thingy-that-holds-a-
floating-point-value?) holds an exact value. It's a certain
pattern of bits that doesn't change. In a certain context you
may choose to interprate this in one of (at least) two ways. It
can be an exact value (1.0 is exactly 1 [1]) or a range of
values. Without knowing how the program is using the floating
point variables you can't tell if it is meant to be exact or
not.

The point is that you don't KNOW what has been stored in that
object by simply examining the object. You do KNOW the range of
values it can represent. Any further knowledge requires analyzing
the entire program that uses the object. That is probably a
hideously complicated project.

For exactness, use integers, stored in integral objects.

 

[CBFalconer]

CBFalconer said:
.... snip ...


upthread from here, you replied to my statement, "More precisely,
most numbers cannot be represented exactly by floating point
values. Some numbers, however, can be so represented - for example,
low-magnitude integers are no problem at all. It is perfectly
simple to represent these numbers exactly, using floating point",
with the words "You are wrong."

If when you said "You are wrong" you didn't mean I was wrong, what
did you mean?

I don't have that message in front of me, and I am not going to go
to extensive efforts to dig it out.

I see no support in the Standard for the position that a floating
point value is actually several values. Chapter and verse, please.

Search for the chunk "EPSILON" in things dealing with float.h.

Again, chapter and verse.

I won't dignify this foolishness with a reply.

 

[CBFalconer]

What is the difference between the "real value" of a FP variable,
and simply its value?

#include <float.h>
double a, b;

...
a = 1.0;
b = a + (DBL_EPSILON / 2)
...

Now a and b display identical values. They did not have identical
values stored in them.

5.2.4.2.2 Characteristics of floating types <float.h>

....

[#10] The values given in the following list shall be
replaced by implementation-defined constant expressions with
(positive) values that are less than or equal to those
shown:

-- the difference between 1 and the least value greater
than 1 that is representable in the given floating
point type, b1-p

FLT_EPSILON 1E-5
DBL_EPSILON 1E-9
LDBL_EPSILON 1E-9