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

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
>> 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?

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
>> modifications...?
>
> 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
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.

Bruno