|
Boost : |
From: rogeeff (rogeeff_at_[hidden])
Date: 2001-12-11 00:04:29
--- In boost_at_y..., "Fernando Cacciola" <fcacciola_at_g...> wrote:
> >
> > 3. It seems that calculation using float numbers sometimes have
> > better precision (less relative error) than double. How could
this be?
>
> AFAIK, this isn't true. How do you inferred it?
More correct statement would include *sometimes* (not rarely). For
example see foo1.
>
> >
> > 4. To calculate a relative error I am using following formula:
> >
> > |v1 - v2| / |v1|. As you can see it involves 2 additional
arithmetic
> > operations. So, should I add 2 to number of arithmetic operation
> > involved when calculating tolerance value?
> >
> Good question.
> Unfortunately, I think it is even more complicated.
> For example, |v1-v2| can cause catastrophic cancellation (all bits
flushed
> out), yielding
> a relative error of 0.
> IMO, the formulas of error bounds are given to be able to
understand the
> behavior of
> a computation, not to actually try to 'compute' the error.
Sorry I did nit get an answer. Given number of operation to calculate
fp1 do I need to add 2 to find expected tolerance to compare against?
>
>
> > 5. Finnaly lab work. Could you check an output from the following
> > program and explain why relative error exceed expected values:
> >
> Unfortunately, I couldn't understand the design of these tests.
> Could you explain it?
Ignore foo0 - seems to be my glitch
foo1 calculate relative difference between 1.1*1.1 and 1.21. Then
divide it by epsilon(). This value should not exeed (1+2)*1/2 (1
arithmetic operation + 2 decimal/binary conversions). For MSVC seems
to be true, though diff for float is 0 while diff for double is not.
foo2 calculate relative difference between 1.1*1.1 - 1.1 and 0.11.
Then divide it by epsilon(). This value should not exeed (2+2)*1/2.
For MSVC values larger than expected.
>
> Fernando Cacciola
> Sierra s.r.l.
> fcacciola_at_g...
> www.gosierra.com
Gennadiy.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk