Re: Floating Point comparisons

From: rogeeff (rogeeff_at_[hidden])
Date: 2001-12-19 03:14:23

--- In boost_at_y..., "Fernando Cacciola" <fcacciola_at_g...> wrote:
> 

[...]

> 
> 1)
> At the beginning, you mentioned "The simple solution like abs(f1-
f2) < e"
> ....
> I recommend that you change '<' for '<=' here.
> The reason is that if anyone reading the document thinks about 
using this
> "simple solution" he/she will find as a surprise that it fails to 
detect
> 'exact equality' when feed with 'e=0'.  (because (2.3-2.3)<0 
happens to be
> false).

OK

> 
> 2)
> Decimal to binary conversions are not required to be exactly 
rounded which
> means that they are not guaranteed to have an upper limit on the 
error bound
> of half ulp.
> There are however, requirements on the number of decimal digits 
required to
> accurately recover its binary representation, but I think this is 
out of the
> scope of the document, so I would put decimal-to-binary conversions 
in the
> 'unpredictable' bag.
> 

OK.

> 3)
> There still seems to be some confusion about the meaning of the 
error bound
> of 1/2ULP.

Yeh, it seems ;-))

> 
> The "1/2ULP" that bounds rounding errors doesn't translate directly 
into
> "1/2*epsilon".
> "relative error" and that 1/2ULP are not exactly interchangeable, 
because
> the relative error introduces a division.
> In other words, when you consider "relative errors", you can't say 
that they
> are bounded by (0.5*epsilon); but rather by (k*epsilon); were k 
depends on
> the operation (k=2, for instance, for subtraction and addition).

I did not get your point here my understanding is ONE arithmetic 
operation inroduces relative rounding error that does not exceed 1/2 
epsilon, for example:

float f1 = 11;
float f2 = 10;
float d  = f1/f2;

Now |d - real(d)| / |d| should not exceed 1/2*epsilon for float

 
> Also, I mentioned that the only true source of errors is 'rounding' 
(w.r.t
> algebraic operations). This is strictly correct because of the 
requirement
> of exactly rounded operations. However, the statement by itself can 
be
> confusing without proper explanation, because in most floating point
> bibliography a user will find statements such as 'the relative 
error of this
> operation is <= 2e'.

What does it mean?

> 
> In conclusion I recommend:
> 
> Rephrase the statement:
> 
>  "The first three operations proved to have a relative rounding 
error that
> does not exceed 1/2 * "machine epsilon value" for the appropriate 
floating
> point type (represented by std::numeric_limits<FPT>::epsilon())."
> 
> with something intentionally weaker such as:
> 
> "The relative error of a floating point conversion or arithmetic 
operation
> is usually around or below 1 (one) "machine epsilon" for the 
appropriate
> floating point type (represented by 
std::numeric_limits<FPT>::epsilon())"
> 
> Remove the first two sentences that start with "All theorems 
about..." and
> "This means that the operation error".
> Start the paragraph directly with "In order for numerical software"
> 
> 4)
> I don't understand the meaning of the statement
> 
>   "The underflow/overflow or division-by-zero errors cause 
unpredictable
> errors."

How about:

The underflow/overflow and division-by-zero errors may cause rounding 
errors with unpredictable upper limits.

> 
> They *are* errors so they can't "cause errors", predictable or not.
> 

They are errors, but they aren't always detected and those cases 
could cause a rounding errors with unpredictable upper limits.

> 5)
> 
> The words "strong" and "weak" used by the argument 
for "close_at_tolerance"
> are not directly related to the referred inequations.
> I suggest using those words also at the beginning of the document to
> establish the relation.

What if I ad folllwing statement into Introduction:

The relationship defined by inequations (1) is stronger that the 
relationship defined by inequations (2) (i.e. (1) => (2) )

> 
> 6)
> I dislike the name 'close_at_tolerance' because the English 
term 'close' has
> many meanings.
> I would rather name it:  'equal_with_tolerance'.

I favor close over equal. But I can consider an other alternatives. 
What terminology is user in numeric world?

> 
> 7)
> You could add the reference I've used.

OK.

> 
> Fernando Cacciola
> Sierra s.r.l.
> fcacciola_at_g...
> www.gosierra.com

Gennadiy.