Re: Float comparison

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

.... 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. Then examine when and how it
fails. 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. One point
is that taking a value and writing it down does NOT convert it from
an approximation to something exact.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.


.

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)