Re: [boost] [math] pow redux and observations

From: John Maddock (jz.maddock_at_[hidden])
Date: 2008-06-07 04:50:13

Bruno Lalande wrote:
>>> In test_error_handling.cpp, I noticed that not every policies were
>>> tested: ignore_error and errno_on_error were missing. I added some
>>> test for them with undeterminate_result_error, do you want me to do
>>> the same for the other types of error? It's pretty straight-forward
>>> now.
>>
>> Please!
>
> I have troubles testing for nan values. I wanted to use
> boost::math::isnan() but with the real_concept type it doesn't work.
> Is there a generic way to do this or should I just exclude
> real_concept from this test?

real_concept doesn't have NaN's as such (I realise you can initialise it
with a NaN, but the idea is to model a type with a minimum set of
requirements, and that means no NaN's).  Use
std::numeric_limits<T>::has_quiet_NaN to check if the type has a NaN before
testing - there may be some obscure platforms with no NaN support for the
builtin floating point types in any case, likewise when testing infinities.

> Is it normal that raise_evaluation_error returns "val" for
> ignore_error while the documentation specifies infinity? The
> corresponding test fails because of that.

Oops, the docs are just plain wrong :-(

It returns the closest approximation to the result found so far: it
typically gets raised when an iterative method doesn't converge fast enough,
so this is the behaviour that makes the most sense.

I'll fix those docs.

>> It's because ignore_error is the default for indeterminate errors, so
>> make_policy(undeterminate_result_error<ignore_error>() simply returns
>> policy<>() and not policy<undeterminate_result_error<ignore_error>
>> >().  Try it with an error action that's not the default and the
>> test should pass.
>
> OK, I've been able to add indeterminate_error to those tests. With
> this additional error type, the last test (line 110) ends up with a
> make_policy() of 11 arguments so I had to add a new overload. I think
> it's normal since the maximum number of arguments should be the same
> as the total number of types that policy<> can handle, right?

Yep, and it's possible that we may need to add more template arguments to
policy<> now that we're adding more policies, it's just something I've been
putting off - especially as it may bump up compile times :-(

>> What compiler/platform/errors?  There are a small number of fixes to
>> in the Trunk for that test as well that haven't been back-merged to
>> the Sandbox yet: can you see if the Trunk version of that test
>> passes for you?
>
> Indeed, it passes in Trunk so I think a merge to the sandbox would fix
> the problem. I compile with GCC 4.2.3 on a Kubuntu Hardy 32 bits. The
> output is:
>
> ====== BEGIN OUTPUT ======
> Running 1 test case...
> Testing type float
> unknown location(0): fatal error in "test_main_caller( argc, argv )":
> memory access violation at address: 0xbf10dfec: no mapping at fault
> address
> test_tr1.cpp(52): last checkpoint
>
> *** 1 failure detected in test suite "Test Program"
>
> EXIT STATUS: 201
> ====== END OUTPUT ======
>
> The error occurs on the line testing expm1. Commenting it out makes
> the test pass. If you merge your recent fixes back to the sandbox I
> can test again to see if it solves the issue.

OK I think I know what the issue is then: I don't really want to back merge
from Trunk to sandbox until we're ready to synchonise the two - it's so much
easier to keep track of things if the two versions get synchonised in both
directions rather than making add-hock changes to both.