- Original Message -
From: "Gabriel Dos Reis" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Monday, June 30, 2003 12:06 PM
Subject: Re: [boost] Compiler status for GCC 3.3
[...]
> | I'm not sure about this. Paul C. Leopardi and Guillaume Melquiond
already
> | re
"Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Maxim Egorushkin wrote:
> [...]
> > Seems like the issue is undefined behaviour when casting away volatile.
> > Do I get it right?
>
> Yes, UB is the issue ("one of the most obvious tips of the iceberg").
>
> Well,
Fernando Cacciola <[EMAIL PROTECTED]> wrote:
> Gabriel Dos Reis <[EMAIL PROTECTED]> wrote in
>> Yes. It is an incorrect (unfortunately popular)
>> implementation.
>>
> Right. We should say that more often. It is incorrect
> however popular.
>
> Most compilers provide a non standard extension
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
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
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:
> 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 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
--
Fernando Cacciola
fernando_cacciola-at-movi-dot-com-dot-ar
"Guillaume Melquiond" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED]
> On Fri, 4 Jul 2003, Fernando Cacciola wrote:
>
> > Gabriel Dos Reis <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]
> > > "jvd" <
"Joel de Guzman" <[EMAIL PROTECTED]> escribió en el mensaje news:[EMAIL PROTECTED]
> Fernando Cacciola <[EMAIL PROTECTED]> wrote:
> > Gabriel Dos Reis <[EMAIL PROTECTED]> wrote in
>
> >> Yes. It is an incorrect (unfortunately popular)
> >> implementation.
> >>
> > Right. We should say that more of
"Beman Dawes" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> test_fp_comparisons 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_
On Sat, 5 Jul 2003, Fernando Cacciola wrote:
> Thanks to Gabriel we may have an is_nan() right now.
> Is there anything else that the interval library uses which might be better
> packed as a compiler-platform specific routine?
All the hardware rounding mode selection stuff. It's equivalent to th
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
13 matches
Mail list logo
