Float comparison

[Dik T. Winter]

> "Dik T. Winter" wrote: ....
>
> I would have the same results except for the last entry. It
> certainly eases some calculations, but fouls the statistics.

So you clearly do not follow the rules as set down in the IEEE standard from
1985. That the last rounds down rather than up gives better statistics.

 

[Dik T. Winter]

> I was thinking about that last night, and I think I have a strong
> argument for using the simpler (is the bit 1) criterion for
> rounding. Consider the value:
> 1110.1000
> Now we say it is exactly halfway between the two possible rounded
> values, because there are no more 1 bits in the value. However,
> that value represents a real, and the reals outnumber the rationals
> by an order of infinities. Therefore there almost MUST be another
> 1 bit somewhere to the right, and therefore we should round up.

Apparently you know better than an excellent numerical mathematician as Kahan,
who basicly designed the IEEE system and was involved in the design of the
8087 (which implemented a preliminary form of the standard).

> That article, when I read it, is discussing forward and backward
> error analysis. It is applicable to the maths involved. What I
> have been discussing here has to do with the meaning of the stored
> float.

And that whole error analysis falls apart if you do consider the stored
values as ranges.

 

[Dik T. Winter]

O, and this is *not* what the C standard states about xxx_EPSILON. If your
processor is set to round to infinity, FLT_EPSILON remains the same, but
your EPSILON becomes the smallest representable float. So clearly your
EPSILON is not xxx_EPSILON.

 

[Keith Thompson]

<snip note that you have read the Goldberg paper>

Was it the Goldberg paper he read? There was another paper (or web
page) that, I think, James Kuyper cited, having to do with error
analysis (I don't have the URL handy).

 

[Ben Bacarisse]

Was it the Goldberg paper he read? There was another paper (or web
page) that, I think, James Kuyper cited, having to do with error
analysis (I don't have the URL handy).

I think you are right, but his comment (which I snipped) was in a
reply to may talking about the Goldberg paper. Specifically (if
anyone is interested anymore) it includes a good explanation of exact
round to even. Looking back, the comment did not obviously relate to
Goldberg's work.

 

[Antoninus Twink]

Having scanned your quote, I found one mistake without even trying.

Absolutely vintage Heathfield. As usual, his intellectual dishonesty
shines through.

If you have a criticism to make, make it openly and plainly, Heathfield,
instead of your usual tricks of mud-slinging and insinuation. Your way
is the underhand way - the way of the coward, the guttersnipe and the
snake in the grass.

Full credit to Mr Twink for posting what does appear to be a genuine
attempt to make a sensible reply, but his accuracy record is so poor
in matters I do know about that it would be unwise of me to trust him
in matters I do not know about.

What are these matters that you do know about?

Certainly not C, as Han from China has comprehensively demonstrated.

 

[Richard Bos]

Please DON'T bother.

No, heavens forbid that you actually have to face the fact that you've
been wrong all this time. Don't even bother to tell Mr. Falconer
something that is true, but doesn't fit his idees-fixes.

Richard

 

[Richard Bos]

While nice to see you prodding Chucky, don't be so ridiculous. You know
exactly what was meant.

Oh, of course I know what was _meant_. I also know what an astrologer
means when he says that "the sun was in Aquarius". But what Chuck means
is as wrong as what the astrologer means.

Richard

 

[Richard Bos]

Oh? Are you denying that 1.0 is an integer? Or that 3.0 is an
integer?

Hell, yes I am. They're floating point values. If they were integers,
they'd be 1 and 3, not 1.0 and 3.0.

You're confusing floating point arithmetic (which is part of C) with
real arithmetic (which is very much _not_ part of C) again.

Richard

 

[Phil Carmody]

I'm a little surprised by this response. I had taken
you to be someone who is interested in technical
accuracy and curious about learning new things.
Lebesgue measure is a concept that accurately
captures the view you are trying to represent
with the naive term "vanishingly small",

Complete bollocks. Lebesgue measure is about as unrelated to
the property Richard is attempting to describe as catfood is.
The Cantor dust is measure 0, yet through a very simple
bijection can be used to represent the entire set of reals.
Richard's chosen set cannot, through any bijection, be used
to represent the entire set of reals. Therefore the property
which is important to Richard, and the topic at hand, is
definitely not that of having Lebesgue measure 0.

You're just trying to show off that you know some insider
mathematical jargon. Big deal. Shame you don't know when to
apply it.

Phil

 

[Phil Carmody]

call the above CBF's theorum (CBFT)


I don't follow that bit


so by the CBFT
z_min = x_min * y_min;
and
z_max = x_max * y_max;

Now consider
double z1 = 1.0;
double z2 = 1.0 * 1.0;

z1 and z2 represent different ranges. Are they equal?

It's a jolly good job C doesn't have an exponentiation
operator, or you could have some real fun with 0. ^^ 0. ,
as neither its sign nor its finiteness would be known,
despite the fact that it's clearly 1.

Phil

 

[Phil Carmody]

Yes. 1.0 and 3.0 are of type double, not of any integer type.

Remember, 1.0/3.0 was presented as a C expression.

If this thread is going to continue much longer, can I suggest
that someone introduce some syntax which will clearly distinguish
between expressions intented to be C floats and those which are
actual real numbers. Perhaps change the '.' to ',' in reals, or
prefix them with an 'r', or something.

Phil

 

[Guest]

Remember the range is dealing ONLY with the effect of fp-storage.

what I call CBF's theorum:
"the range represented by z = x * y consists of the extreme range
values of the values calculated by multiplying the extremes of the
ranges x and y"

or

range (x*y) = [x-min*y-min, x-max*y-max)

I derived this from your statement:

So, if the values were not known to be exactly 1.0, they had to be
ranges, because that is all the fp-object value means, without
considering the programming.  The range for the original x and y
values is going to be from 1.0 + EPSILON down to 1.0 - EPSILON/2
(because of the range shift at 1.0).  The largest value possible
for x*y is (1.0 + EPSILON) squared.  The smallest is (1.0 -
EPSILON) squared.

please define floating-point-object value

The range represents only the error introduced by the fp-system
storage.  It is a minimum error for the actual value.  So the range
of z2 is the same as the range for z1.  The possible error is
different - see above.

you have two different definitions of range

so is
1.0 equal to 1.0 * 1.0?

 

[BartC]

A fluid ounce weighs a full gram more than an ounce. 29.6 vs 28.3

A US fluid ounce might do. British (or imperial) ones are about 28.3495 g
(equivalent I believe to the same quantity of ml under certain conditions).

(US pints are 16 US fluid oz, some 470ml; Imperial pints are 20 Imperial
fluid ounces, about 568ml.

 

[Phil Carmody]

CBFalconer said:



You are certainly right about that as of C99. Whether you are right
in C95 I am not sure. But you are wrong in C90.

I disagree. Your use of mantissa is perfectly standard in a whole
range of computational fields. The fact that it's not the term
chosen to represent the concept in certain versions of the C
standard doesn't mean it isn't a perfectly good term to use to
represent the concept.

Your response should perhaps have been just "there is such a
thing as a mantissa, and in recent C standards it's called the
'significand'".

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

Phil

 

[Ben Bacarisse]

Amusingly, in modern versions of the C standard, there's no
use of "significand" either.

You need better software. The text if fine if the software knows what
it is doing.

<snip>

 

[Phil Carmody]

Well, I suppose FLT_ROUNDS could be coded to always be -1, and
fegetround and fesetround could always fail. In any case, by the above
I did not mean what the last call to fesetround was, I meant how the
processor works (which includes whether it is possible to change the
rounding mode, how many bits in a double etc).


Irrelevant. Or at least, not as relevant as you think.


Unless FLT_ROUNDS returns -1 and fesetround and fegetround always fail
the author of the implementation needs to know how to set (if it can
be changed) and determine the rounding mode. However, in this case as
it is indeterminable it can do the rounding as it likes.

There is no difference in this for a cross compiler compared to a
normal compiler.

Did you for one minute think that I would expect a normal compiler
to be any different in this regard? If so, why? Care to point out
a few lines of mine, or even a few words, where I mention any
differences between a normal compiler and a cross compiler?

You (the writer of the implementation) can set the initial mode (if it
is setable, and if not you know what it is) during program
initialisation.

How can an cross compiler either set or know in advance something
which might be configured when the microcode is uploaded to the
processor at boot time?

Then if during compilation/linking you determine that
fesetround is never called you know exactly what rounding mode is in
effect.

I like the way you've combined compiling and linking. You've
not done much programming in the real world, have you?

I'm discussing what is allowed and possible, not the details of a
specific implementation.


Yes, which also gives a lot of opportunities for doing
optimisations. Specifically it can also default to "#pragma
FENV_ACCESS off" and then unless it sees it being set to on it can
assume that the default mode (as defined by the implementation and as
can be set by the implementation during program initialisation) is in
effect thus allowing it to perform the optimisation.

So no, the compiler is not always allowed to do this
optimisation.

I think you'll find that was my point.

However, the standard *does* allow it providing certain
criteria are met, and whether they are met can be determined by the
author of the implementation knowing how the target works together
with some analysis of the source code presented.

A sufficiently hamstrung implementation could justifiably
have such restrictions, yes. However, in most circumstances I'd
consider that to be a poor QoI. Offering the user the ability to
make or not make those assumptions, however, is good QoI.

Phil

 

[Flash Gordon]

Did you for one minute think that I would expect a normal compiler
to be any different in this regard? If so, why? Care to point out
a few lines of mine, or even a few words, where I mention any
differences between a normal compiler and a cross compiler?

The underlined phase above, "Or think of a cross compiler" implies that
it is a special attribute of a cross compiler as opposed to any other
type of compiler. That was not from you, but your response was in reply
to my saying that a cross-compiler can do it when a "normal" compiler
can. I made the natural (to me) assumption that you were disagreeing
with that since it was the point under discussion.

How can an cross compiler either set or know in advance something
which might be configured when the microcode is uploaded to the
processor at boot time?

All of the cross compilers I've used came with startup code which set
the processor in to a known state. If the rounding mode is completely
out of the control of the implementation then FLT_ROUND should yield -1
to indicate the rounding mode is indeterminable and in that state it
does not (as far as I can tell) need to use a consistent rounding mode.

I like the way you've combined compiling and linking. You've
not done much programming in the real world, have you?

I've done over 20 years of it, some for embedded systems, some for
desktops, some for servers. Since some compilers do "whole program
optimisation" they are doing some of what would often be considered part
of the compilation phase (the optimisation) after doing some of what
would normally be considered the linking phase, so yes I did mention
both phases because the distinction is not always as clear cut as one
might expect and such implementations would (in my opinion) find it
easiest to do what I suggested above.

I think you'll find that was my point.

If your point is that for any compiler there are situations when this
optimisation cannot be done your are probably correct.

My point is that there is no difference between a cross compiler and any
other compiler in this respect, and there are situations where it can be
done.

A sufficiently hamstrung implementation could justifiably
have such restrictions, yes.

No need for the implementation to be hamstrung, just to make use of the
pragmas specified in C99 and put the processor in to a defined mode
during startup. That isn't a hamstrung implementation.

However, in most circumstances I'd
consider that to be a poor QoI. Offering the user the ability to
make or not make those assumptions, however, is good QoI.

Which is exactly what the standard pramas I mentioned above are for. It
is up to the implementation what the default state is, so if the user
cares they should specify what they want. No need for compiler options,
just the use of facilities defined by the standard. I'm undecided as to
which the better default would be.

 

[Keith Thompson]

Hell, yes I am. They're floating point values. If they were integers,
they'd be 1 and 3, not 1.0 and 3.0.

You're confusing floating point arithmetic (which is part of C) with
real arithmetic (which is very much _not_ part of C) again.

That kind of confusion has been happening a lot in this thread. I've
probably been guilty of it myself at times. The problem is that,
since C syntax mimics mathematical notation (particularly the subset
of mathematical notation that can be exprssed in ASCII), there's no
easy way to distinguish between the C expression 1.0/3.0 and the
mathematical real expression 1.0/3.0.

Here's my suggestion:

REAL(expr) means that expr is to be interpreted, not as a C
expression, but as a real expression. Henceforth in this thread, if I
write 1.0/3.0, that's a C expression of type double. If I write
REAL(1.0/3.0), that's a real expression whose value is exactly
one-third. 1.0/3.0 and 1/3 are quite different; REAL(1.0/3.0) and
REAL(1/3) are identical.

If I want to emphasize that an expression is to be interpreted in C, I
might write C(expr) (but I won't do this within a C program or
snippet).

Which probably means I'll write REAL(xmin) and REAL(xmax) rather than
just xmin and xmax.

So: REAL(1.0) is an integer, but C(1.0) is not, and there are no
integers in C(1.0/3.0).

(Some mathematicians might say that the integers are merely isomorphic
to a subset of the reals, but I'm going to assume that the integers
*are* a subset of the reals.)

 

[Keith Thompson]

If this thread is going to continue much longer, can I suggest
that someone introduce some syntax which will clearly distinguish
between expressions intented to be C floats and those which are
actual real numbers. Perhaps change the '.' to ',' in reals, or
prefix them with an 'r', or something.

Believe it or not, I hadn't read this before I posted my proposal
about 5 minutes ago. Quick summary: expr is a C expression,
REAL(expr) is a real expression; C(expr) can be used for emphasis.