Float comparison

[Flash Gordon]

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.

So you are saying the standards definition of of xxx_EPSILON is wrong?
The last time I checked standards were allowed to define terms, and
language standards were allowed to define constants to be part of the
language. So I would say that the standards definition of what
xxx_EPSILON is correct by *definition* and if you want to talk about
something that does not meet that definition you need to use a different
term for which you provide an accurate definition which you stick to.

 

[Flash Gordon]

Now you are taking the appeal to god path too,

No, I referred you to a paper which you have looked at which contained a
lot of maths showing why it is a good idea. Maths you have yet to deal
with. The point would have been the same if I have copied the entire
text in to the post. I then went on to suggest in simple English some
other reasons.

instead of
discussing facts.

The paper I referred to discusses the facts. Do I really have to copy a
large amount of maths in to my post rather than referring you to a paper
by someone who knows the topic better than me?

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.

I can't even make sense of that.

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.

No, that is NOT what I said. Not even close.

This ignores
the fact that the real spectrum contains an infinity of real values
between each rational value pair.

Well, since that is nothing to do with what I said it is irrelevant.



Imagine you get a number from some real source, such as measuring the
length of a pencil. This happens to have been measured as 11.5mm. You
want to round this to an exact number of mm. Now, this is the real word,
so you know the chances of 11.5 being exact is sod-all-of-nothing. With
no further information there is an "infinitesimal" chance it was exactly
11.5mm, a 50% chance it was a little shorter, and a 50% chance it was a
little longer. Therefor, if you are then going to be adding up the
length of 1000 pencils in mm, you will probably get a more accurate
answer if for those which were measured as exactly x.5mm you round half
up and half down.

The maths is explained in the paper I referenced and you have not dealt
with it and failed to understand my first attempt to explain it in English.

 

[Flash Gordon]

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.

In any case, I withdraw the claim. It is not well enough supported and
is under dispute, so it is not suitable as a supporting argument.

I don't have copies of the Pascal standard, nor access to my books on
Pascal today, and I'm not about to buy the standard or remember to did
out the text books.

 

[Dik T. Winter]

>
> You can't extend the precision without adding bits, or removing the
> influence of other bits.

Who says you can do that? What is the relevance of that remark?

 

[Flash Gordon]

You spipped matterial AGAIN without marking fact. This time it looks
like an attempt to distort my post, since the portion snipped without
marking included links to references which I explicitly stated looked
reasonable.

Now you are taking the appeal to god path too, instead of
discussing facts. You can dismiss your theory of a dropped 1 bit

<snip>

No, I am posting links to references which explain my my position. I am
also pointing out that your much quoted (by you) experience in floating
point is NOT a reason for us to take your statements as fact when the
sources everyone else quotes have far more experience and training and
are internationally accepted as experts.

Now, please apologise for your repeated snipping of relevant material
without marking the deletions. I think you also owe Keith an apology for
deleting parts of his posts without marking it.

Oh, and I deny permission for partial quotes of this message without the
deletions being clearly marked.

 

[Flash Gordon]

Flash Gordon wrote:
.... snip ...

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.

Sumarise YOUR position with clear definitions of the terms you use and
references to specific parts of the C standard. Remember to allow for
the FACT that the rounding mode CAN be changed during the execution of
the program, and remember to handle the limit cases.

Please do not attempt to sumarise the position of anyone else, since you
seem not to have understood the points raised.

 

[Flash Gordon]

I'm not criticizing them, at least not without reading and studying
what he says.

You are claiming to know better, and you have put up your implementation
of a floating-point system, the prize you won for it, and it being
published as reasons why we should take not of it (otherwise why mention
them?). So pointing out the background of people being referenced by
others is surely reasonable.

I have given reasons for my decisions, which have
been developed during this discussion.

You have been given links to papers explaining the reasons for the
decisions. You have even acknowledged reading part of one of the papers.
Here, again, is one of the other links, this one a paper by Kahan
http://www.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF

My references to my own
experiences are just that - they are not claims of infallibility.

No, but you claim your experience as reason we should believe you. In
the same vain people are claiming that the vastly larger experience of
people who have written formal papers on the subject is reason why you
should consider carefully what their position is instead of just
assuming that you are correct.

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.

True, but papers by experts which include detailed reasoning including
the maths behind it are still more likely to be accurate than the
unreviewed posts of someone who does not have training in the subject.
After all, since the papers have been reviewed by experts (and in the
case of the papers by Kahan caused HW developers to spend significant
sums of money developing new FP units) any errors are more likely to
have been found and corrected (as well as less likely to have been made
in the first place).

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.

Please do NOT try to summarise the position of anyone other than you,
since you do not seem to have understood the positions of other people.

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.

Well, if you tried to address the points people raised instead...

 

[Flash Gordon]

Keith Thompson wrote:
.... snip ...

Just a quick note - I haven't read all of Goldberg, and I don't
know.

A small hint. I just searched the document for the word "range" and
amongst the 41 hits could not find anything saying that a floating-point
number represents a range.

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.

Perhaps because you have been doing that and changing definitions
instead of addressing the points raised. Had you addressed the points
raised progress could have been made much faster.

 

[Ben Bacarisse]

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

Yes, I got tired of writing 3-bit (4-bit normalised). There is no
confusion about the precision. b=2 and p=4 so as far as C is
concerned TINY_EPSILON is b**(1-p) = 2**-3 = 1/8.

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

So, no answer as to what the ranges for the 5 example numbers are. I
can't calculate these formulae since I don't know what EPSILON to use
for 1.0 (you've said 1/16 does not work for 1.0). I did try to
calculate the ranges for the others number based on your formula but
they were wrong apparently. That's why I want the numbers not the
formulae.

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.

Things would more along faster if you stopped doing that. You assume
that people disagree because they have failed to understand something
you've said, but often they disagree because they *have* understood.
You have repeatedly told me things I know about FP systems, yet
pointedly not answered direct question about your particular view of
them.

 

[Kenny McCormack]

He is saying that because of rounding the number in the FP is NOT the
"exact real". And you can not, from the FP ONLY, say what the exact real
was since that discrete value in the FP could have been forged from a
RANGE of reals. WTF is so hard to understand? Why do you keep repeating
it?

It looks like Flashy is helping out brother Kiki. Aka, "ganging on".

The fact that its neither here nor there is not the point : for f*cks
sake drop it.

It was Twink, wasn't it, who observed that Kiki is, literally, a
computer/compiler. And that a compiler will generate the same error
message for the same input, over and over, forever.

 

[CBFalconer]

CBFalconer wrote:
.... snip ...


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.

Not so. The only purpose of those messages is to give examples to
people who deny that we can be supplying a real, or whatever, to
the system. Please read them carefully.

 

[CBFalconer]

CBFalconer wrote:
.... snip ...


So you are saying the standards definition of of xxx_EPSILON is
wrong? The last time I checked standards were allowed to define
terms, and language standards were allowed to define constants to
be part of the language. So I would say that the standards
definition of what xxx_EPSILON is correct by *definition* and if
you want to talk about something that does not meet that
definition you need to use a different term for which you
provide an accurate definition which you stick to.

Why do you insist on twisting what I say into something else? I
didn't say the standard was wrong. I said defining the size of
EPSILON as identical to the weight of the LSB of the significand is
wrong, and that 1/2 that is wanted.

 

[CBFalconer]

Don't shout. You said the relation x*(1+E) == x+E holds for x 1.0 to
2.0. I point out that it does not. You correctly explain what happens at
x == 1.5. It's arithmetic. Why do you say it's wrong?

Because the convention is that the EPSILON is constant until the
size changes, i.e. at the value change to the next power of two.

 

[CBFalconer]

.... snip ...


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.

Search for ISO10206.

 

[CBFalconer]

Who says you can do that? What is the relevance of that remark?

You did. See the first quote above. As I read it.

 

[Flash Gordon]

Why do you insist on twisting what I say into something else? I
didn't say the standard was wrong. I said defining the size of
EPSILON as identical to the weight of the LSB of the significand is
wrong, and that 1/2 that is wanted.

You have said that your EPSILON is the appropriate xxx_EPSILON, now you
are saying it is half the LSB of the significand. Which is it, since it
can't be both. This is part of the problem, you say a term means one
thing then some time later decide it means something else without
bothering to tell anyone that you have stopped using the previous meaning.

 

[Flash Gordon]

Not so. The only purpose of those messages is to give examples to
people who deny that we can be supplying a real, or whatever, to
the system. Please read them carefully.

I DID read carefully. You are claiming that
struct rational { int divisor; int dividend };
struct rational num = { 1, 3 };
is an exact representation of one third in C yet
double othernum = 1.0;
does not assign exactly the real number 1.0 to othernum.

When you look at what num contains it only has the integer values 1 and
3 with no specific meaning applied to them. When you look at othernum it
has the value 1.0 with no specific meaning applied to it. This is a
consistent way of looking at things.

Claiming that the C expression 1.0/3.0 is exactly the real value one
third (which in C will give something slightly different to one third)
but the C expression othernum (after the initialisation above) is NOT
exactly the same value as the real value 1.0 is inconsistent.

So yes, you ARE being inconsistent.

 

[Flash Gordon]

Not so. The only purpose of those messages is to give examples to
people who deny that we can be supplying a real, or whatever, to
the system. Please read them carefully.

I DID read carefully. You are claiming that
struct rational { int divisor; int dividend };
struct rational num = { 1, 3 };
is an exact representation of one third in C yet
double othernum = 1.0;
does not assign exactly the real number 1.0 to othernum.

When you look at what num contains it only has the integer values 1 and
3 with no specific meaning applied to them. When you look at othernum it
has the value 1.0 with no specific meaning applied to it. This is a
consistent way of looking at things.

Claiming that the struct above or the C expression 1.0/3.0 is exactly
the real value one third (when in C it will yield something slightly
different to one third) but the C expression othernum (after the
initialisation above) is NOT exactly the same value as the real value
1.0 (or my real examples of software using doubles to represent exact
integers still has each value representing a range even though it is
careful to never use anything not exactly represented) is inconsistent.

So yes, you ARE being inconsistent.

 

[Flash Gordon]

Not so. The only purpose of those messages is to give examples to
people who deny that we can be supplying a real, or whatever, to
the system. Please read them carefully.

I DID read carefully. You are claiming that
struct rational { int divisor; int dividend };
struct rational num = { 1, 3 };
is an exact representation of one third in C yet
double othernum = 1.0;
does not assign exactly the real number 1.0 to othernum.

When you look at what num contains it only has the integer values 1 and
3 with no specific meaning applied to them. When you look at othernum it
has the value 1.0 with no specific meaning applied to it. This is a
consistent way of looking at things.

Claiming that the struct above or the C expression 1.0/3.0 is exactly
the real value one third (when in C it will yield something slightly
different to one third) but the C expression othernum (after the
initialisation above) is NOT exactly the same value as the real value
1.0 (or my real examples of software using doubles to represent exact
integers still has each value representing a range even though it is
careful to never use anything not exactly represented) is inconsistent.

So yes, you ARE being inconsistent.

 

[Keith Thompson]

Why do you insist on twisting what I say into something else? I
didn't say the standard was wrong. I said defining the size of
EPSILON as identical to the weight of the LSB of the significand is
wrong, and that 1/2 that is wanted.

You didn't say the standard was wrong. You merely made a statement
which is factually inconsistent with what the standard actually says.

DBL_EPSILON is the difference between 1 and the least value
greater than 1 that is representable in type double (paraphrased
from C99 5.2.4.2.2p11). That "least value" can be expressed as
nextafter(1.0, 2.0).

Thus:

DBL_EPSILON == nextafter(1.0, 2.0) - 1.0

Take a look at the values of
DBL_EPSILON
and
nextafter(1.0, 2.0) - 1.0
on your system. Compare them to the value of the LSB of the
significand of 1.0 when represented as a double. (Determining the
value of the LSB is left as an exercise.)