> Above form wouldn't should
> mismatched values and this is most important.
I meant: Above form wouldn't *show* mismatched values and this is most
important.
Gennadiy.
-
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boos
> >What's most of the time needed is relative precision.
> >
> >So, numerical gurus: how can one express "a equals b within
> 0.1%" over >the whole range of floating point numbers? If
> that can be done, it would >be a nice useful routine. >
> >bool approximately_equal(double lhs, double
At 02:22 PM 7/7/2003, Rozental, Gennadiy wrote:
>I could probably prohibit usage of CHECK_CLOSE with number of rounding
>errors provided.
>Is there any other general recommendations how to choose the tolerance to
>FP computation correctness checking?
There has been some recent discussion on com
> Let t be tmp and e? be error values (smaller than ulp/2).
>
> rounded(rounded(t*t) - t)
> = ((t*t) * (1+e1) - t) * (1+e2)
> = t*t - t + t*t * (e1+e2+e1*e2) - t*e2
>
> So how much is the relative error? For example, if e1=ulp/2
> and e2=0, the absolute error reaches t*t*ulp/2 = 0.605*ulp.
On Sat, 5 Jul 2003, Beman Dawes wrote:
> So where does that leave us? There must be some reason Gennadiy's code is
> producing results one or two epsilons greater than expected.
It's just because the testcases are wrong. For example, line 157, there
is:
tmp = 11; tmp /= 10;
BOOST_CHECK_C
At 01:29 PM 7/5/2003, Guillaume Melquiond wrote:
>On Sat, 5 Jul 2003, Beman Dawes wrote:
>
>> fpt_abs may do a unary "-" operation. I'm assuming, perhaps
incorrectly,
>> that is essentially subtraction and subject to a possible rounding
error.
>
>I don't think there is a system where the opposite
On Sat, 5 Jul 2003, Beman Dawes wrote:
> fpt_abs may do a unary "-" operation. I'm assuming, perhaps incorrectly,
> that is essentially subtraction and subject to a possible rounding error.
I don't think there is a system where the opposite of a representable
number would not be a representable n
At 12:18 PM 7/5/2003, Guillaume Melquiond wrote:
>On Sat, 5 Jul 2003, Beman Dawes wrote:
>
>> What is happening here? It seems to me that the error checking code
>> itself that computes the values to be checked (d1 and d2) introduces
one
>> to four possible additional rounding errors. (The error
On Sat, 5 Jul 2003, Beman Dawes wrote:
> test_fp_comparisions has been failing for a long time. The issue has to do
> with how much tolerance to allow for rounding errors.
>
> The close_at_tolerance algorithm calculates tolerance as follows:
>
> n*std::numeric_limits::epsilon()/2
>
> where n i
test_fp_comparisions has been failing for a long time. The issue has to do
with how much tolerance to allow for rounding errors.
The close_at_tolerance algorithm calculates tolerance as follows:
n*std::numeric_limits::epsilon()/2
where n is the number of possible floating-point rounding erro
10 matches
Mail list logo
