Float comparison

[Spiros Bousbouras]

Where "very early" means "at the beginning of a
serious undergraduate study, and probably not
even then.

I interpret "at the beginning" to mean in the 1st year if not
1st semester. I don't imagine even top universities cover
Lebesgue measure and integration in the first year.

(Many undergraduate courses are happy
to deal with the Riemann integral only, leaving
Lebesgue measure as an option for the interested).

This can be interpreted in more than one ways so I don't know if
I agree with you or not. I would expect every half decent
undergraduate mathematics course to offer Lebesgue measure and
integration as an option but not necessarily amongst their
compulsory modules.

 

[Spiros Bousbouras]

The Lebesgue measure, mu, of a finite
union of distinct intervals is the sum of their lengths.

s/distinct/disjoint/

 

[Spiros Bousbouras]

What property exactly is Richard trying to describe, then?

For everyone's convenience the discussion is about the message

The phrase "vanishingly small" is pretty ambiguous, and I
interpret it to mean "having measure zero". If you
can attribute some other meaning to the phrase, then
please do so.

If one is determined to assign a precise mathematical meaning to
the phrase ``Vanishingly few in comparison to the total number
of reals'' then it is ambiguous but I think Richard's point is
clear without assigning any precise mathematical meaning to his
phrase. Hence I consider it pointless to try and assign such
meaning. But if we're playing this game it could just as well
mean finite instead of having Lebesgue measure 0.

 

[CBFalconer]

CBFalconer wrote:
.... snip ...


As previously demonstrated, the minimum error measure is zero,
just as it is for the integer types.

I am always dealing with what you can extract from the fp-object,
ignoring the controlling software.

 

[CBFalconer]

.... snip ...

Because there's no way that software can put "significand" into
the C standard unless it modifies the file. Is you a bit fick?

Here is the first two places in the C99 standard that the word
'significand' occurs:

5.2.4.2.2 Characteristics of floating types <float.h>

[#1] The characteristics of floating types are defined in
terms of a model that describes a representation of
floating-point numbers and values that provide information
about an implementation's floating-point arithmetic.14) The
following parameters are used to define the model for each
floating-point type:

s sign (_1)
b base or radix of exponent representation (integer > 1)
e exponent (integer between a min emin and a max emax)
p precision (number of base-b digits in the significand)
fk nonnegative integers less than b (significand digits)

 

[CBFalconer]

.... snip ...

Please cite where Goldberg says that a floating-point number
represents a range of real numbers.

Just a quick note - I haven't read all of Goldberg, and I don't
know. But I am going to stop answering things in this thread for
now and, hopefully, take some time out to write a summary of the
discussions. Unlike this thread, such an article will not be
confused by corrections and evolution of the discussion.

One reason is that this is taking up all of my time, and most of it
is spent reiterating things I said a long time ago.

 

[CBFalconer]

.... snip ...

There, i have asked the question I originally asked, except with
exact numbers for a hypothetical tinyfloat, and the only term I
have introduced is "your range" by which I mean whatever it is
you mean by the range. This is a separate question to the one
I've asked else-thread.

I am going to stop answering things in this thread for now and,
hopefully, take some time out to write a summary of the
discussions. Unlike this thread, such an article will not be
confused by corrections and evolution of the discussion.

One reason is that this is taking up all of my time, and most of it
is spent reiterating things I said a long time ago.

 

[CBFalconer]

.... snip ...

In this thread, you have written:

Think about WHY EPSILON changes at the power of two.

and

The practical EPSILON, which causes a minimum visible difference
in fp-object values, changes when x becomes an exact power of two.

The EPSILONs in the C standard are defined only for the x value of
1. The 'changes' I mentioned extend its use to other values.

 

[CBFalconer]

.... snip ...

No, it doesn't. DBL_EPSILON is the value of the LSB of the
significand of 1.0, not half the value.

In the representation of 1.0, the LSB is 0. Changing the LSB to
1 changes the value from 1.0 to the next representable number
above 1.0. That is, by definition, 1.0+DBL_EPSILON.

So you want to be able to add a value that should alter the
'accumulator' (so-called), but won't? One-half of YOUR EPSILON
will do that. Don't you think that action is apt to be fatal to
the fp-system accuracy?

That's why EPSILON has to have one-half the weight of the least
significant bit in the significand for 1.0.

 

[CBFalconer]

CBFalconer wrote:
.... snip ...


Why do you present things you know to be wrong? The Standard
defines the value of EPSILON exactly. b^1-p is not an
approximation.

I find x*(1+E) == x+E is fine for x == 1.0 but not for x == 1.5.

If E is the weight of the LS significand bit, the addend when x is
1.5 is x(1+E) == 1.5+1.5E. That last 1.5E will round up to 2 E,
and the x value of 1.5 will be advanced by 2E. THAT IS WRONG.

 

[CBFalconer]

CBFalconer wrote:
.... snip ...


So d is identical to x except for the significand being 0? Really?
And you have a bit to the right of the significand? And the sign
bit is where? What color is the sky on your planet?

I said "when that is normalized". Sheesh.

 

[CBFalconer]

CBFalconer wrote:
.... snip ...

OK, I'll pick up on it. You have not addressed all the maths and
proofs in the paper. They explain why the proposed (and these days
normally used) method is better than the alternatives.

A simpler reason for your argument not being valid is that given
that the number is produced by either approximating a real value
to store it as a floating point number, or by calculations based
on such numbers, there is as much chance that the number is
actually fractionally below the half-way point (and that last bit
(or even all bits in extreme cases) you have calculated is wrong
as that the number is actually slightly larger (i.e. that there
is another 1 somewhere).

Now you are taking the appeal to god path too, instead of
discussing facts. You can dismiss your theory of a dropped 1 bit
far to the right, since any such would have caused a herd of 1 bits
to its left. So you are arguing that no 1 bit will appear in an
infinity of successively less significant bits? In other words
that we are really dealing with a rational fraction. This ignores
the fact that the real spectrum contains an infinity of real values
between each rational value pair.

 

[CBFalconer]

I did.


I gave what I thought was a reasonable response to it.


I agree, though I am not sure it is the size alone that makes it so.

Is there any reasonable chance you will be able to give the ranges of
the five example numbers for your simple 3-bit system?

It has 4 significant bits. Don't forget the normalized left hand 1
bit, replaced by a sign bit.

The formulas for xmax and xmin work for all values other than 1.0.
The ranges are from <xmax to >xmin, remembering that xmax and xmin
are real values whose only purpose is to be inserted into the fp
system to see what fp-object-value they generate.

For that system the value of EPSILON is 1/16, i.e. 1/2 the weight
of the LSB. xmax is x*(1+EPSILON). xmin is x*(1-EPSILON).

I am going to stop answering things in this thread for now and,
hopefully, take some time out to write a summary of the
discussions. Unlike this thread, such an article will not be
confused by corrections and evolution of the discussion.

One reason is that this is taking up all of my time, and most of it
is spent reiterating things I said a long time ago.

 

[CBFalconer]

Your reason was based only on the misguided idea that a floating-
point number represents a range rather than a specific (rational)
number. There are very good reasons *not* to do that, as an
example I posted some time ago an article where I did show some
basic blocks used to double the precision of floating-pointrequire
arithmetic, and those building blocks that you assume a precise
value in a floating-point variable, and not some range or other.
For a complete article about it see:

Dekker, T. J. 1971, A Floating-point Technique for Extending the
Available Precision, Numberische Mathematik 18(3), pp 224-242.

You can't extend the precision without adding bits, or removing the
influence of other bits. This is elementary. I have posted
reasons for the decisions I took. I didn't start this discussion
with an organized system, but developed it as the ranting grew.

I am going to stop answering things in this thread for now and,
hopefully, take some time out to write a summary of the
discussions. Unlike this thread, such an article will not be
confused by corrections and evolution of the discussion.

One reason is that this is taking up all of my time, and most of it
is spent reiterating things I said a long time ago.

 

[CBFalconer]

You cite yourself in such a manner by talking about the floating
point systems you have implemented. Surely the ubiquity of the
IEEE system, and Kahan having a PhD (Maths, University of Toronto,
1958), and him being, Professor Emeritus of Mathematics, and of
E.E. & Computer Science, suggests he might know just a *little*
more about the subject than you and that his works should be taken
seriously until proved to be in error?

I'm not criticizing them, at least not without reading and studying
what he says. I have given reasons for my decisions, which have
been developed during this discussion. My references to my own
experiences are just that - they are not claims of infallibility.
I even said where you could find and examine them, if you are
lucky. They got better as time progressed.

Mathematical things are peculiar. They don't depend on
reputations. They do depend on accuracy.

I am going to stop answering things in this thread for now and,
hopefully, take some time out to write a summary of the
discussions. Unlike this thread, such an article will not be
confused by corrections and evolution of the discussion.

One reason is that this is taking up all of my time, and most of it
is spent reiterating things I said a long time ago.

 

[Keith Thompson]

Here is the first two places in the C99 standard that the word
'significand' occurs:

[snip]

The message in which Phil raised this point included the following
header line:

X-Planation: The standard is released in forms where the two
consecutive letter\ s 'fi' have been replaced by a single
ligature symbol.

He strongly hinted at this:

Amusingly, in modern versions of the C standard, there's no
use of "significand" either. But perhaps that statement should
be redirected to rec.puzzles ;-) (No point dragging that bit
of silliness out, puzzle for no more than 20s then read my
headers for the explanation.)

 

[Keith Thompson]

Keith Thompson wrote:
... snip ...

So you want to be able to add a value that should alter the
'accumulator' (so-called), but won't?

What? No, why would I want to do that?

One-half of YOUR EPSILON
will do that. Don't you think that action is apt to be fatal to
the fp-system accuracy?

That's why EPSILON has to have one-half the weight of the least
significant bit in the significand for 1.0.

I can only assume that you've misunderstood the standard's definition
of DBL_EPSILON.

Take a look at the value on your system, and at the value of the LSB
of the significand for 1.0.

 

[David Thompson]

Not true. Integer objects with trap representations need not follow
the associativity law when added, even if the range were unlimited.

Trap reps are not values and (thus) not elements of the claimed group,
so failure to close or associate over them is not a problem.
(Or commute, since the would-be group would also be Abelian.)

Infinities are values, but I'm pretty sure they're sticky enough not
to fail associativity, at least under the IEEE option or something
similar. Quiet NaNs definitely are (both: values and sticky).

 

[Richard Bos]

OK, then Wikipedia was wrong. It happens.

It happens all too often, but even so it's quite possible that this has
changed since 19foo. But I don't think I have the latest Pascal
Standard.

Richard

 

[Flash Gordon]

I am always dealing with what you can extract from the fp-object,
ignoring the controlling software.

No, you are ignoring the software when convenient to you and invoking it
when you want. You have stated in this thread that the real value of one
third can be represented in C by using a struct and that you can write
an implementation of rational arithmetic. That is NOT ignoring the
controlling software. So you should either retract your claim that the
real value of one third can be represented (since you relied on the
controlling software) or accept that floating point numbers can be used
to store exact values.

In any case, even ignoring any surrounding software you can extract the
exact value of 1.0 from a floating point object, you can do this because
the standard says you can. There are a lot of numbers you cannot extract
at all, of course, and defining the mapping from non-representable
numbers to floating point objects REQUIRES analysing the code, since the
code could CHANGE that mapping by selecting a different rounding mode..