Re: Float comparison

CBFalconer wrote:
Flash Gordon wrote:
CBFalconer wrote:
Flash Gordon wrote:
Keith Thompson wrote:
CBFalconer <cbfalconer@xxxxxxxxx> writes:

... snip ...

So what? doubles are used to store reals, more or less. ints
are used to store integers. 1.0+DBL_EPSILON/2.0 is a real[1].
1.5 is NOT an integer.

[1] but not a storable real, in a double.
It's that "more or less" that bites you, isn't it? Your model
makes some sense if you ignore those pesky details where it
falls apart.
<snip>

In addition doubles *are* used to store exact integral values
and integer types *are* used to store approximations. Any claim
that you have stored a range when you have in fact stored the
exact value that you intended to store is clearly wrong and would
make error analysis impossible.
So what? You are referring to the programming that is using that
object. I am talking about what you can deduce from the object in
isolation.
That value is. The point is, that taken in isolation you do NOT know
that it is a range. Taken in isolation you only know what the actual
stored value is. is a single exact value specified by a well-defined
model which may represent either an exact quantity or a range which
could be (and ofen is) far larger than the ranges you are talking about.

The standard actually talks about values that "can be represented
exactly" in section 6.3.1.5 (paragraph 2).

Yes, but that is simply a number.

Yes, which is all that is actually stored.

You do know what the 'range'
is. The number does not express the range of numbers that will be
stored with that identical value, and simply cannot be told apart. In isolation what you know is the range of values that can have
been represented thusly.

In isolation you know exactly what value *has* been stored, you just can't tell whether the programmer intended to store a value that cannot be represented.

... snip ...
So various pieces of wording in the C standard are inconsistent with
your claim that the values stored are always approximations. They are,
however, entirely consistent with the branch of mathematics known as
set theory which allows you do have whatever sets you want.

Go forth and implement a FP system.

I've implemented FP arithmetic (sufficient to solve my problem, not a full system) in assembler already thanks. The data fed in to it was exact values, the data extracted from it and finally converted to integers was exact values. The intervening calculations were approximations which gave a known acceptable limit on the error of the settings given to the hardware when compared to the theoretical mathematical values the algorithm I had to implement an approximation of.

Now address the point that your claim is in direct contradiction to the wording of the standard.

You have yet to address how float can be a subset of double if the items in the two sets are fundamentally different (i.e. if the range about 1.0 for the closest approximation to 1.0 is different in the two sets).

Then examine when and how it
fails.

It did not fail because I understood exactly what was needed and carefully worked through it to ensure that the errors and approximations stayed within acceptable limits.

You will soon appreciate the fundamental truths about such
a system. You will soon see how all values (apart from zero, NaNs,
Infs) are approximations, and how they cannot overlap.

If you think that zero is exact then you are being inconsistent. Calculations (including the conversion of a floating point number in the source code) can yield 0 when the "correct" value is non-zero but smaller than the smallest number representable in the floating point system.

One point
is that taking a value and writing it down does NOT convert it from
an approximation to something exact.

No, nor does it convert something exact in to an approximation.

Note that no one has claimed that any type in C can store exactly all rationals within any given range.
--
Flash Gordon
.

Relevant Pages

  • Re: Float comparison
    ... In addition doubles *are* used to store exact integral values ... that taken in isolation you do NOT know that it is a range. ... The standard actually talks about values that "can be represented exactly" in section 6.3.1.5. ...
    (comp.lang.c)
  • Re: Float comparison
    ... In addition doubles *are* used to store exact integral values ... that taken in isolation you do NOT know ... your claim that the values stored are always approximations. ...
    (comp.lang.c)
  • Re: Float comparison
    ... In addition doubles *are* used to store exact integral values ... that taken in isolation you do NOT know ... your claim that the values stored are always approximations. ...
    (comp.lang.c)
  • Re: Float comparison
    ... Oh, it exists, but not in that floating representation. ... Keith has already mentioned the need to do an error analysis if you want to know what the possible error. ... I know of code which carefully uses doubles to do integer arithmetic, staying within the range where integers can be represented exactly, in order to use the greater range of exact integral values that a double can represent on that specific implementation than an int. ... So either integer types cannot store exact values and you need to do a full error analysis to determine the range of values they might represent or floating point variables can store exact values which are exactly the mathematically correct values the program is intended to store. ...
    (comp.lang.c)
  • Re: approximations for exponential, normal and gamma cdf
    ... This was with reference to Koopman's suggestion and my response ... RF> spell it -- it's the same Cheby) approximations. ... but those are for exact computations rather than for SIMPLE ... The postscript interpreter has to do all the work when displaying the ...
    (sci.stat.math)