"John Maddock" <john@johnmaddock.co.uk> wrote in message news:00a701c81166$b38e8f60$a4f86d51@fuji...

Sohail Somani wrote:

...

Hi,

When is the expected release for the Boost.Math toolkit that was recently accepted?

Code and docs are now basically stable and in mainline SVN. At present I'm working on hammering down as many test-failures as possible so that it's fully functional on as many platforms/compilers as possible, if you ignore the "usual suspects" (Borland, Compaq C++ etc), then it's already doing quite well: http://beta.boost.org/development/tests/trunk/developer/math.html

Hi, John Can you please take a look on failures today. I've enabled additional error detection within Boost.Test with floating point operations on WIN32 platform. Does theses look valid to you? http://mysite.verizon.net/beman/win32-trunk-details.html#math-test_bernoulli... Gennadiy

"John Maddock" <john@johnmaddock.co.uk> wrote in message news:001701c81183$1fd50020$a4f86d51@fuji...

Gennadiy Rozental wrote:

...

Hi, John

Can you please take a look on failures today. I've enabled additional error detection within Boost.Test with floating point operations on WIN32 platform. Does theses look valid to you?

Ahhhh! No, there are quite a lot of tests that are expected to return infinity, or underflow to zero. Enabling floating point hardware exceptions will break those: the tests are predicated on numeric_limits<>::has_infinity etc, but not on the *runtime* value of the hardware exception flags. I assume you're calling __control87 somewhere to turn these exceptions on?

switch_fp_exceptions( bool on_off ) { if( !on_off ) _clearfp(); int cw = ::_controlfp( 0, 0 ); int exceptions_mask = _EM_INVALID|_EM_DENORMAL|_EM_ZERODIVIDE|_EM_OVERFLOW|_EM_UNDERFLOW; if( on_off ) cw &= ~exceptions_mask; // Set the exception masks on, turn exceptions off else cw |= exceptions_mask; // Set the exception masks off, turn exceptions on if( on_off ) _clearfp(); // Set the control word ::_controlfp( cw, _MCW_EM ); }

My gut feeling is that this is the wrong moment to introduce a breaking change like this, especially as you're changing the compiler's default behaviour. Given enough time it's work-aroundable, but it's time I'd rather not spend just at present, and besides I would expect this to break libraries like random and interval as well. If you want to make this an option for Boost.Test that's fine, it's making this the default in the run up to a release that I'm not happy with.

Ok. How about if I make this optional and disabled by default for now. But make it enabled by default after 1.35? Gennadiy

"John Maddock" <john@johnmaddock.co.uk> wrote in message news:004001c81186$63737520$a4f86d51@fuji...

Gennadiy Rozental wrote:

...

...

My gut feeling is that this is the wrong moment to introduce a breaking change like this, especially as you're changing the compiler's default behaviour. Given enough time it's work-aroundable, but it's time I'd rather not spend just at present, and besides I would expect this to break libraries like random and interval as well. If you want to make this an option for Boost.Test that's fine, it's making this the default in the run up to a release that I'm not happy with.

Ok. How about if I make this optional and disabled by default for now. But make it enabled by default after 1.35?

I'd say disabled for now, then ask and see what users want after 1.35 :-)

Ok. I've made it optional and default to false. There a command line argument --detect_fp_exceptions=[yes|no] to manage the behavior. Gennadiy

Markus Schöpflin wrote:

John Maddock wrote:

...

Code and docs are now basically stable and in mainline SVN. At present I'm working on hammering down as many test-failures as possible so that it's fully functional on as many platforms/compilers as possible, if you ignore the "usual suspects" (Borland, Compaq C++ etc), then it's already doing quite well: http://beta.boost.org/development/tests/trunk/developer/math.html

[...]

Tru64/CXX (I think this is what you are referring as Compaq C++) would probably be mostly OK if the possible bug in fusion regarding vector<> is fixed, so you probably shouldn't care about these for now.

Indeed, thanks Markus, John.

Beman Dawes wrote:

As release manager, and given the excellent Win32, Linux and HP-UX test results, I'm fine with shipping the math toolkit in 1.35.0, assuming the other aspects (docs, inspect, etc.) are OK.

I'd also like John to spend some time on TR1 and any of his other libraries showing failures.

:-) Actually I don't think there's anything I can do: TR1 has hardly changed (some gcc configuration changes that would be nice to ship, but that's it), the remianing failures are due to changes in Boost.Fusion. They cause Math lib and I believe other failures as well, Joel is aware of the issue, but evidently it's not trivial to fix :-( John.