Regarding Q. 14-5

[Mark McIntyre]

I would say that in cases
where a suitable definition of epsilon, is zero,
that the use of epsilon isn't required.

zero is certainly one possible definition of epsilon. You're pretty
much making my point.

 

[Eric Sosman]

zero is certainly one possible definition of epsilon. You're pretty
much making my point.

Your point was that the test `f <= 1.0' is "dangerous."
As far as I can tell, everyone else on the thread rejects
this point as invalid. You yourself reject it when you
accept a zero epsilon as suitable.

 

[Joe Wright]

I would say that in cases
where a suitable definition of epsilon, is zero,
that the use of epsilon isn't required.

I may be slightly off-point here in which case, I apologize.

I calculate cos(pi/2) and get 6.1232339957367660e-17 which if very
nearly zero. But not quite. How can I use DBL_EPSILON to determine that
it is, for practical purposes, zero.

 

[Mark McIntyre]

Your point was that the test `f <= 1.0' is "dangerous."

Clearly you missed my point. Which was that you erroneously stated
that you can't meaningfully use an epsilon. This is, as I'm sure
you're aware, garbage.

As far as I can tell, everyone else on the thread rejects
this point as invalid. You yourself reject it when you
accept a zero epsilon as suitable.

Seemingly you aren't actually reading what I'm writing, you're just
responding to my criticism of you by attacking me. Your problem, not
mine.

 

[Mark McIntyre]

I calculate cos(pi/2) and get 6.1232339957367660e-17 which if very
nearly zero. But not quite. How can I use DBL_EPSILON to determine that
it is, for practical purposes, zero.

You could just say that if the result was less than DBL_EPSILON, then
it was zero. DBL_EPSILON isn't really designed for this though.

 

[Eric Sosman]

Clearly you missed my point. Which was that you erroneously stated
that you can't meaningfully use an epsilon. This is, as I'm sure
you're aware, garbage.




Seemingly you aren't actually reading what I'm writing, you're just
responding to my criticism of you by attacking me. Your problem, not
mine.

A thousand apologies: Indeed, I misread what you wrote.
Searching up-thread I see that it was not you but Malcolm
who claimed that `f <= 1.0' is "dangerous," and it's that
rash claim I've been disputing.

Once again, sorry for my mistake.

 

[Mark McIntyre]

Once again, sorry for my mistake.

Equally sorry if I was rude in my last posting.

 

[Dik T. Winter]

> #define EPS -1e-12
>
> if ( f <= 1.0+EPS )
> angle = asin(f);
> else
> {
> puts("f ->1");
> f = asin(1.0);
> }

And how do you explain to the user of this fragment that a domain error
is encountered in asin?

 

[Mark McIntyre]

And how do you explain to the user of this fragment that a domain error
is encountered in asin?

And when does it do that? Read what I wrote more carefully.

 

[Malcolm]

This is different. We want to compare with 1.0, and add epsilon toe
avoid false negatives. But in this case we get a true negative.
On the other hand, if f is mathematially greater than 1+epsilon,
but slightly smaller due to floating point errors we get a false
positive...

But indeed, comparing to 1.0 + epsilon is just as silly as comparing
to plain 1.0. The bottom line is that when you want to use
floating-point you better know what you are doing so that you can
judge how you wish to compare. (In all my years of programming in
numerical mathematics I rarely, if at all, coded a line like
f <= 1.0 + epsilon, but many lines like f <= 1.0.)

If you compare to 1.0 + epsilon you exclude the false negatives (since the
real value we are interested in is 1.0, not 1.0 + epsilon). If you compare
to 1.0 - epsilon you exclude the false positives.
When f is in the range 1 +/- epsilon we have a problem. It depends what you
expect f to be th result of, and why you are making the comparison.

Let's say that you are writng some sort of lighting algorithm that requires
vetors to be either normalised or scaled to be under 1. If you want to
exclude / trap any unnormalised vectors, you probably expect most of the
vectors to be the result of dividing by a square root, and thus
mathematically unity. You probably want to accept any a whisker over 1.0 in
length.

On the other hand if f is a probability, you probably wnat to compare to a
hard 1.0 - p might easily be exactly 1.0, but if it is a whisker over that
probably represents something bad elsewhere.

Unfortunately there aren't any hard or fast rules.

 

[Malcolm]

A thousand apologies: Indeed, I misread what you wrote.
Searching up-thread I see that it was not you but Malcolm
who claimed that `f <= 1.0' is "dangerous," and it's that
rash claim I've been disputing.

Once again, sorry for my mistake.

Gas heaters are also dangerous. People die of carbon monoxide poisoning
every year.

Unfortunately there's not much you can do about it - no one has yet built a
practical CO monitor. Banning gas would mean the loss of an entire fuel
source. "Dangerous" and "unusable" are two different things.

As for your point that, if we test against 1 + epislon it doesn't do any
good unless we also test agaisnt 1 + epsilon * 2, I hope you can see the
fallacy of this.
We are interested in numbers mathematically equal to or less than unity.
Testing against 1.0 + episilon gets rid of all the false rejections, at the
price of risking more false acceptances. That may be good or bad, depending
on which is worse for your particular program.