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.