From: Bruno Lalande (bruno.lalande_at_[hidden])
Date: 2008-06-06 20:04:30
> Just one thing: "undeterminate" should be spelt "indeterminate" throughout.
> No one said English was going to be logical :-)
Oops :-) OK, fixed it.
>> 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
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?
Is it normal that raise_evaluation_error returns "val" for
ignore_error while the documentation specifies infinity? The
corresponding test fails because of that.
I added all the tests but commented out the problematic ones for now.
> 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?
> Also one small point, in pow_test you check for a special return value:
> "return T(123.456)", but since that's not exactly representable as a binary
> floating point number it may be susceptible to spurious failures due to
> rounding issues etc. Probably better to return an exact binary value like
> 123.25 or something just in case.
OK, I made those values representable in single precision.
>> Also, test_tr1 doesn't pass for me but I guess it's not related to my
> Oh :-(
> 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
====== 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk