[multiprecision] Are these types suitable as numeric types for unit tests?

Daryle Walker

8 Jun 2013 8 Jun '13

6:57 a.m.

I'm writing new numeric types, and my unit tests use MPL lists of numeric types. I usually use stuff like int, unsigned, and double, but now I'm adding cpp_int and cpp_dec_float_50. Those types were OK when I was just doing type equalities and sizeof checks. Now I'm doing tests that use objects of those types and I'm getting problems. //==== typedef boost::mpl::list test_integer_types; typedef boost::mpl::list test_floating_types; //... BOOST_AUTO_TEST_CASE_TEMPLATE( test_complex_component_access1, T, test_integer_types ) { typedef complex_it real_type; typedef complex_it complex_type; real_type a; real_type const & aa = a; complex_type b; complex_type const & bb = b; a[ 0 ] = 6; BOOST_CHECK_EQUAL( a[0], T(6) ); BOOST_CHECK_EQUAL( T(6), aa[0] ); b[ 0 ] = 5; b[ 1 ] = 7; BOOST_CHECK_EQUAL( b[0], T(5) ); BOOST_CHECK_EQUAL( T(5), bb[0] ); BOOST_CHECK_EQUAL( b[1], T(7) ); BOOST_CHECK_EQUAL( T(7), bb[1] ); } //==== I'm getting warnings about integer overflow. The problem is at Line 59 of boost/test/tools/detail/print_helper.hpp. It sets an output stream's precision based on the digits given by std::numeric_limits. //==== BOOST_AUTO_TEST_CASE_TEMPLATE( test_complex_component_access2, T, test_floating_types ) { typedef complex_it real_type; typedef complex_it complex_type; real_type a; real_type const & aa = a; complex_type b; complex_type const & bb = b; a[ 0 ] = 6.0; BOOST_CHECK_CLOSE( a[0], T(6.0), 0.1 ); BOOST_CHECK_CLOSE( T(6.0), aa[0], 0.1 ); b[ 0 ] = 5.5; b[ 1 ] = -7.0; BOOST_CHECK_CLOSE( b[0], T(5.5), 0.1 ); BOOST_CHECK_CLOSE( T(5.5), bb[0], 0.1 ); BOOST_CHECK_CLOSE( b[1], T(-7.0), 0.1 ); BOOST_CHECK_CLOSE( T(-7.0), bb[1], 0.1 ); } //==== This time it's an error, at Line 59 of boost/test/tools/floating_point_comparison.hpp. There no (close enough) matching function for "fpt_abs" from some "boost::multiprecision::detail::expression<..." type. (It was truncated by the display. I don't know how to get a clean print-out of errors from Code::Blocks.) I'm guessing the expression template setup is screwing things up. Daryle W.

Show replies by date

Christopher Kormanyos

8 Jun 8 Jun

8:35 a.m.

New subject: [multiprecision] Are these types suitable as numeric types for unit tests?

...

I'm writing new numeric types, and my unit tests use MPL lists of numeric types.

<snip>

...

This time it's an error, at Line 59 of boost/test/tools/floating_point_comparison.hpp.

Hi Daryle, Maybe it's the same phenomenon I am tracing right now.

...

There no (close enough) matching function for "fpt_abs" from some "boost::multiprecision::detail::expression<..." type. (It was truncated by the display. I don't know how to get a clean print-out of errors from Code::Blocks.) I'm guessing the expression template setup is screwing things up. Daryle W.

I believe I encountered the same phenomenon while writing up some multiprecision tests for a new math function yesterday. I can't yet resolve if it's in multiprecision, test, or the interaction of the two. I am in the process of creating a simple two-liner exhibiting this behavior. Somehow it seems familiar to me and I thought John and I had looked into it a while back. But I forgot. I encountered it with BOOST_TEST_CLOSE_FRACTION. Give me a chance to work up a test case exhibiting the error. Sincerely, Chris.

Christopher Kormanyos

7:08 p.m.

New subject: [multiprecision] Are these types suitable as numeric types for unit tests?

...

...
This time it's an error, at Line 59 of

...

...
boost/test/tools/floating_point_comparison.hpp.

...

Maybe it's the same phenomenon I am tracing right now.

...

I encountered it with BOOST_TEST_CLOSE_FRACTION.

Oh, that's my forgetfullness. Disabling expression templates does the trick. Here is another weird one: When using BOOST_TEST_CLOSE_FRACTION with cpp_dec_float and et_off, I get a lot of ambiguous name errors for enable_if and disable_if in multiprecision. It seems as though the same symbols enable_if and disable_if reside in both the namespace boost as well as deeper in the boost::test namespaces. Is this a known problem? Am I doing something wrong? Sincerely, Chris.

John Maddock

9 Jun 9 Jun

7:46 a.m.

New subject: [multiprecision] Are these types suitable as numerictypes for unit tests?

...

When using BOOST_TEST_CLOSE_FRACTION with cpp_dec_float and et_off, I get a lot of ambiguous name errors for enable_if and disable_if in multiprecision. It seems as though the same symbols enable_if and disable_if reside in both the namespace boost as well as deeper in the boost::test namespaces.

Is this a known problem? Am I doing something wrong?

No. Do you have a reduced test case? Thanks, John.

Christopher Kormanyos

9:52 a.m.

New subject: [multiprecision] Are these types suitable as numerictypes for unit tests?

...

...
When using BOOST_TEST_CLOSE_FRACTION with cpp_dec_float and et_off, I get a lot of ambiguous name errors for enable_if and disable_if in multiprecision. It seems as though the same symbols enable_if and disable_if reside in both the namespace boost as well as deeper in the boost::test namespaces.

Is this a known problem? Am I doing something wrong?

...

No. Do you have a reduced test case? Thanks, John.

Yes. The test case below tests cyl_bessel_j for cpp_dec_float_50 with et_off. In my trunk with VC11 (Visual Studio 2012) with the test case below, I find numerous errors here due to ambiguous names in . Note that the test uses the *header-only* version of unit_test from Boost.Test. The ambiguity does not arise with the non-header-only version. The names "enable_if" and "disable_if" are ambiguous because they are present in the namespace "boost" as well as in "boost::unit_test::decorator". In addition, there is symbol-injection via a using directive in Boost.Test which, although needed by Boost.Test, seems to cause the ambiguity. Modifying by replacing enable_if with boost::enable_if, etc. resolves the ambiguity. I don't know the best way to go here. There could be a variety of code-based solutions. We could also make a simple work-around stating to avoid using the header-only test in combination with multiprecision until the issue can be properly resolved. Thank you. Sincerely, Chris. ------------------------------------------------------------------------------ #define BOOST_TEST_MODULE my_test #include #include #define BOOST_TEST_MAIN #include // Note: header-only Boost.Test #include BOOST_AUTO_TEST_CASE(my_test) { typedef boost::multiprecision::number, boost::multiprecision::et_off> mp_type; static const mp_type tolerance = std::numeric_limits::epsilon() * 1.0e12; static const mp_type test_value (boost::math::cyl_bessel_j(mp_type(1) / 3, mp_type(12) / 7)); static const mp_type control_value("0.563386078529485398523077867872975885570767812499129930878677"); BOOST_CHECK_CLOSE_FRACTION(test_value, control_value, tolerance); } //'enable_if' : ambiguous symbol // could be 'C:\boost_trunk\boost/utility/enable_if.hpp(36) : boost::enable_if' // or 'C:\boost_trunk\boost/test/tree/decorator.hpp(184) : boost::unit_test::decorator::enable_if'

John Maddock

12:09 p.m.

New subject: [multiprecision] Are these types suitable asnumerictypes for unit tests?

...

The names "enable_if" and "disable_if" are ambiguous because they are present in the namespace "boost" as well as in "boost::unit_test::decorator". In addition, there is symbol-injection via a using directive in Boost.Test which, although needed by Boost.Test, seems to cause the ambiguity.

Oh *&^%^&*!

...

Modifying by replacing enable_if with boost::enable_if, etc. resolves the ambiguity.

I realise that fix is only a search and replace away... but the code is obfuscated enough already by all the enable_if stuff without having to use fully::qualified::names everywhere. I've filed a bug report: https://svn.boost.org/trac/boost/ticket/8679 Can we just use the separately compiled boost.test in the mean time? John.

Christopher Kormanyos

12:42 p.m.

New subject: [multiprecision] Are these types suitable asnumerictypes for unit tests?

...

...
The names "enable_if" and "disable_if" are ambiguous because they are present in the namespace "boost" as well as in "boost::unit_test::decorator".

...

Oh *&^%^&*!

...

...
Modifying by replacing enable_if with boost::enable_if, etc. resolves the ambiguity.

...

I realise that fix is only a search and replace away... but the code is obfuscated enough already by all the enable_if stuff without having to use fully::qualified::names everywhere.

...

I've filed a bug report: https://svn.boost.org/trac/boost/ticket/8679

...

Can we just use the separately compiled boost.test in the mean time? John.

Yes, of course. I agree. Let's pace ourselves, you know, get 1.54 out. When the dust settles later on, we can search-and-replace away in trunk. I will disseminate this information to our GSoC student who is active in this area. Thank you again. Sincerely, Chris.

Christopher Kormanyos

10 Jun 10 Jun

8:55 p.m.

New subject: [multiprecision] Are these types suitable asnumerictypes for unit tests?

...

...
Modifying by replacing enable_if with boost::enable_if, etc. resolves the ambiguity.

...

I realise that fix is only a search and replace away... but the code is obfuscated enough already by all the enable_if stuff without having to use fully::qualified::names everywhere.

...

I've filed a bug report: https://svn.boost.org/trac/boost/ticket/8679 Can we just use the separately compiled boost.test in the mean time? John.

Hi John, I did a local edit of my multiprecision directory in trunk. I qualified both enable_if and disable_if with the boost namespace. I still need to run all tests and the like. But it's looking good so far. After things quiet down after 1.54, I can can commit the changes with your approval if you like. Or if you've got a batch of other things to do, you may prefer to do the search and replace? Anyway, it is a simple modification however and whenever we end up doing it. Sincerely, Chris.

Christopher Kormanyos

8:59 p.m.

New subject: [multiprecision] Are these types suitable asnumerictypes for unit tests?

...

...
I've filed a bug report: https://svn.boost.org/trac/boost/ticket/8679

...

...
Can we just use the separately compiled boost.test in the mean time? John.

...

Hi John,

...

I did a local edit of my multiprecision directory in trunk. I qualified both enable_if and disable_if with the boost namespace. I still need to run all tests and the like. But it's looking good so far.

...

After things quiet down after 1.54, I can can commit the changes with your approval if you like. Or if you've got a batch of other things to do, you may prefer to do the search and replace?

...

Anyway, it is a simple modification however and whenever we end up doing it. Sincerely, Chris.

Or are you trying to say we should play the long game and get the *using* directives out of Boost.Test? Sorry if I missed that one (clear in your bug report, but I glossed over it). Sincerely, Chris.

legalize+jeeves＠mail.xmission.com

11 Jun 11 Jun

4:24 a.m.

New subject: [multiprecision] Are these types suitable as numerictypes for unit tests?

[Please do not mail me a copy of your followup] boost@lists.boost.org spake the secret code <1370771537.69686.YahooMailNeo@web172406.mail.ir2.yahoo.com> thusly:

...

The names "enable_if" and "disable_if" are ambiguous because they are present in the namespace "boost" as well as in "boost::unit_test::decorator". In addition, there is symbol-injection via a using directive in Boost.Test which, although needed by Boost.Test, seems to cause the ambiguity.

I couldn't find any code in Boost.Test that uses the decorators enable_if and disable_if. They are undocumented anywhere, so I find it unlikely that any clients of Boost.Test are depending on them from the outside. They look like dead code to me. -- "The Direct3D Graphics Pipeline" free book http://tinyurl.com/d3d-pipeline The Computer Graphics Museum http://computergraphicsmuseum.org The Terminals Wiki http://terminals.classiccmp.org Legalize Adulthood! (my blog) http://legalizeadulthood.wordpress.com

Gennadiy Rozental

6:29 a.m.

New subject: [boost] [multiprecision] Are these types suitable as numerictypes for unit tests?

Richard writes:

...

...
The names "enable_if" and "disable_if" are ambiguous because they are present in the namespace "boost" as well as in "boost::unit_test::decorator". In addition, there is symbol-injection via a using directive in Boost.Test which, although needed by Boost.Test, seems to cause the ambiguity.

I believe these were removed. Where do you see these?

...

I couldn't find any code in Boost.Test that uses the decorators enable_if and disable_if.

They are undocumented anywhere, so I find it unlikely that any clients of Boost.Test are depending on them from the outside.

They look like dead code to me.

They are not dead. They are brand new features I am in progress of documenting. Gennadiy

legalize+jeeves＠mail.xmission.com

4:29 a.m.

New subject: [multiprecision] Are these types suitable as numerictypes for unit tests?

[Please do not mail me a copy of your followup] boost@lists.boost.org spake the secret code <1370771537.69686.YahooMailNeo@web172406.mail.ir2.yahoo.com> thusly:

...

[...] In addition, there is symbol-injection via a using directive in Boost.Test which, although needed by Boost.Test, seems to cause the ambiguity.

Looking at trunk, the using directive brings the symbols into namespace ::boost::unit_test, not ::boost. In the bottom of decorator.hpp: using decorator::label; using decorator::expected_failures; using decorator::timeout; using decorator::description; using decorator::depends_on; using decorator::enable_if; using decorator::disable_if; using decorator::fixture; } // namespace unit_test } // namespace boost -- "The Direct3D Graphics Pipeline" free book http://tinyurl.com/d3d-pipeline The Computer Graphics Museum http://computergraphicsmuseum.org The Terminals Wiki http://terminals.classiccmp.org Legalize Adulthood! (my blog) http://legalizeadulthood.wordpress.com

Gennadiy Rozental

6:31 a.m.

New subject: [boost] [multiprecision] Are these types suitable as numerictypes for unit tests?

Richard writes:

...

[Please do not mail me a copy of your followup]

boost <at> lists.boost.org spake the secret code <1370771537.69686.YahooMailNeo <at> web172406.mail.ir2.yahoo.com> thusly:

...
[...] In addition, there is symbol-injection via a using directive in Boost.Test which, although needed by Boost.Test, seems to cause the ambiguity.

Looking at trunk, the using directive brings the symbols into namespace ::boost::unit_test, not ::boost.

Exactly. There was one or two places where unit_test was injected into boost, but these are cleared for some time now. Gennadiy

John Maddock

7:13 a.m.

New subject: [multiprecision] Are these types suitable as numerictypes for unit tests?

...

...
...
there is symbol-injection via a using directive in Boost.Test which, although needed by Boost.Test, seems to cause the ambiguity.

Looking at trunk, the using directive brings the symbols into namespace ::boost::unit_test, not ::boost.

Exactly. There was one or two places where unit_test was injected into boost, but these are cleared for some time now.

I've no idea frankly *why* the compiler finds those types, but it certainly does do so - please take a look at the reduced test case in the bug report. I forget the namespace lookup rules now, but could your enable_if be in an associated namespace (the namespace of the base class of the unit test case) that gets searched during name lookup? Either way I believe in the long run we won't be the only ones hit by this, so I think it should be fixed in Boost.Test. Renaming those types seems like the easiest option? Thanks, John.

Gennadiy Rozental

12 Jun 12 Jun

6:58 a.m.

New subject: [boost] [multiprecision] Are these types suitable as numerictypes for unit tests?

John Maddock writes:

...

I've no idea frankly *why* the compiler finds those types, but it certainly does do so - please take a look at the reduced test case in the bug report.

Your example builds fine with gcc 4.7.2 and VS 10 on my windows box. Gennadiy

Christopher Kormanyos

8:48 p.m.

New subject: [test] enable_if, etc. : was : ...multiprecision types ... for unit tests?

...

...
I've no idea frankly *why* the compiler finds those types, but it certainly does do so - please take a look at the reduced test case in the bug report.

...

Your example builds fine with gcc 4.7.2 and VS 10 on my windows box. Gennadiy

Hi folks, I looked into this one more deeply, and quite honestly, it's got me really confused. I can confirm Gennadiy's result for GCC. But there's more... Let me please try to provide you with additional hard data. My environment: I am building with respect to trunk. My compilers: I am using GCC, and two versions of VC. There is a test case below. The compile and execution results are: * OK for GCC 4.7.2 * Errors for VC10 (ambiguous symbols), AKA VisualStudio 2010 * Errors for VC11 (ambiguous symbols), AKA VisualStudio 2012 Gennadiy, could you please try to reproduce these compilation results in the *trunk* with *the test case below*? Sincerely, Chris. -------------------------------------------------------------------------- #include #define BOOST_TEST_MAIN #include // Boost.Test #include typedef boost::multiprecision::number, boost::multiprecision::et_off> cpp_dec_float_50_noet; BOOST_AUTO_TEST_CASE(sqrt_test) { static const cpp_dec_float_50_noet tolerance = std::numeric_limits::epsilon() * 100; BOOST_CHECK_CLOSE_FRACTION(sqrt(cpp_dec_float_50_noet(2)), cpp_dec_float_50_noet("1.41421356237309504880168872420969807856967187537694807317668"), tolerance); }

Gennadiy Rozental

13 Jun 13 Jun

2:29 a.m.

New subject: [test]enable_if, etc. : was : ...multiprecision types ... for unit tests?

Christopher Kormanyos writes:

...

* OK for GCC 4.7.2 * Errors for VC10 (ambiguous symbols), AKA VisualStudio 2010 * Errors for VC11 (ambiguous symbols), AKA VisualStudio 2012

Sorry. I've misinterpreted MSVC output. I do see the error now. And... this is really weird one. I did not see something like this in a long time. What it comes to can be illustrated in this example: #include namespace boost { struct A{}; namespace inner1 { struct enable_if {}; } // inner namespace inner2 { using namespace ::boost::inner1; template<typename T> void f1( A& ) {} void f2() { f1<int>( A() ); // <=== !!!!!! Offending line } } // inner2 } // boost void foo() { typedef boost::multiprecision::number, boost::multiprecision::et_off> mp_type; const mp_type test_value = mp_type(12) / 7; } I'm sure it can be simplified further by removing specifics of multiprecision library. And the offending line is ... the template instantiation, in unrelated namespace HAS NOTHING TO DO with enable_if at all. Good job MS - I am still trying to figure out how you manage to achieve this "result". Any hints are welcome. Gennadiy

Christopher Kormanyos

6:37 p.m.

New subject: [test]enable_if, etc. : was : ...multiprecision types ... for unit tests?

...

Christopher Kormanyos writes:

...

...
* OK for GCC 4.7.2 * Errors for VC10 (ambiguous symbols), AKA VisualStudio 2010 * Errors for VC11 (ambiguous symbols), AKA VisualStudio 2012

...

Sorry. I've misinterpreted MSVC output. I do see the error now. And... this is really weird one. I did not see something like this in a long time. What it comes to can be illustrated in this example:

...

I'm sure it can be simplified further by removing specifics of multiprecision library. And the offending line is ... the template instantiation, in unrelated namespace HAS NOTHING TO DO with enable_if at all.

So if I understand, we are actually dealing with a compiler issue here regarding the proper resolution of namespaces. Is that what you are saying? <snip>

...

Any hints are welcome. Gennadiy

I think it would be best to qualify enable_if and disable_if with the boost namespace in multiprecision. John, what is you opinion? But you are right in principle, it seems to be a compiler issue. I apologize for wrongly involving your code in this test case. Gennadiy, do you really want to go the hard road and use symbols inject enable_if, etc. in namespaces in your code. It just seems like playing with fire since this symbol has such a clear meaning in C++11. It's your decision, but it would scare me enough to create my_enable_if, etc. But again, it seems as though your code is right and MSVC is wrong. Just a tough waiting game on a compiler issue like that. Have we cleared this one up now? Should I investigate anything further? John, should we decorate multiprecision? No Hurry here, it's something for 1.55. Sincerely, Chris.

legalize+jeeves＠mail.xmission.com

15 Jun 15 Jun

7:17 p.m.

New subject: [test]enable_if, etc. : was : ...multiprecision types ... for unit tests?

[Please do not mail me a copy of your followup] boost@lists.boost.org spake the secret code <1371148674.45851.YahooMailNeo@web172406.mail.ir2.yahoo.com> thusly:

...

...
Christopher Kormanyos writes:

...
...
* OK for GCC 4.7.2 * Errors for VC10 (ambiguous symbols), AKA VisualStudio 2010 * Errors for VC11 (ambiguous symbols), AKA VisualStudio 2012

...
Sorry. I've misinterpreted MSVC output. I do see the error now. And... this is really weird one. I did not see something like this in a long time. What it comes to can be illustrated in this example:

<snip code sample>

...
I'm sure it can be simplified further by removing specifics of multiprecision library. And the offending line is ... the template instantiation, in unrelated namespace HAS NOTHING TO DO with enable_if at all.

So if I understand, we are actually dealing with a compiler issue here regarding the proper resolution of namespaces. Is that what you are saying?

If that is the case, you need a file a bug on http://connect.microsoft.com, or use the VS 2012 Feedback Tool to report the problem from inside VS 2012: http://visualstudiogallery.msdn.microsoft.com/f8a5aac8-0418-4f88-9d34-bdbe2c... -- "The Direct3D Graphics Pipeline" free book http://tinyurl.com/d3d-pipeline The Computer Graphics Museum http://computergraphicsmuseum.org The Terminals Wiki http://terminals.classiccmp.org Legalize Adulthood! (my blog) http://legalizeadulthood.wordpress.com

Christopher Kormanyos

16 Jun 16 Jun

4:26 p.m.

New subject: [test]enable_if, etc. : was : ...multiprecision types ... for unit tests?

...

...
...
Sorry. I've misinterpreted MSVC output. I do see the error now. And... this

...

...
...
is really weird one. I did not see something like this in a long time. What it comes to can be illustrated in this example:

...

...
So if I understand, we are actually dealing with a compiler issue here regarding the proper resolution of namespaces. Is that what you are saying?

...

If that is the case, you need a file a bug on http://connect.microsoft.com, or use the VS 2012 Feedback Tool to report the problem from inside VS 2012: http://visualstudiogallery.msdn.microsoft.com/f8a5aac8-0418-4f88-9d34-bdbe2c...

OK. I will look into it this week. I will report back with any tangible reproducible bug report that may arise. Sincerely, Chris.

Gennadiy Rozental

17 Jun 17 Jun

5:23 p.m.

New subject: [test]enable_if, etc. : was : ...multiprecision types ... for unit tests?

Christopher Kormanyos writes:

...

Gennadiy, do you really want to go the hard road and use symbols inject enable_if, etc. in namespaces in your code. It just seems like playing with fire since this symbol has such a clear meaning in C++11. It's your decision, but it would scare me enough to create my_enable_if, etc.

Standard uses tons of names - list, vector, exception for example. This does not prevent boost to use the same names in different namespaces. And it shouldn't.

...

But again, it seems as though your code is right and MSVC is wrong. Just a tough waiting game on a compiler issue like that.

I hope we can find a workaround. Compiler's behavior is very strange, but there should be some triggers for it. Maybe we can avoid them. Gennadiy

Christopher Kormanyos

7:06 p.m.

New subject: [test]enable_if, etc. : was : ...multiprecision types ... for unit tests?

...

...
Gennadiy, do you really want to go the hard road and use symbols inject enable_if, etc. in namespaces in your code. It just seems like playing with fire since this symbol has such a clear meaning in C++11. It's your decision, but it would scare me enough to create my_enable_if, etc.

...

Standard uses tons of names - list, vector, exception for example. This does not prevent boost to use the same names in different namespaces. And it shouldn't.

Well, you sound like a hard man, and I can respect that. The heat would be too much for me to stand, but I get your point. You know, if there is a compiler issue and if we can't get it properly resolved, Boost.Test will probably get some serious heat from the community as soon as more and more people use the names in question. I am working on isolating the potential compiler issue in a localized test case, and will report back as soon as I have anything reproducible and terse.

...

...
But again, it seems as though your code is right and MSVC is wrong. Just a tough waiting game on a compiler issue like that.

...

I hope we can find a workaround. Compiler's behavior is very strange, but there should be some triggers for it. Maybe we can avoid them. Gennadiy

Let's see what John thinks of decorating the names in multiprecision. He did not sound too enthused in our preliminary discussions. Sincerely, Chris.

Gennadiy Rozental

9:52 p.m.

New subject: [test]enable_if, etc. : was : ...multiprecision types ... for unit tests?

Christopher Kormanyos writes:

...

...
I hope we can find a workaround. Compiler's behavior is very strange, but there should be some triggers for it. Maybe we can avoid them. Gennadiy

Let's see what John thinks of decorating the names in multiprecision. He did not sound too enthused in our preliminary discussions.

I was talking about workaround in Boost.Test code. The problem really comes from template instantiation in some other unrelated piece of code. If you can figure out what exactly triggers this bug maybe we can find a way to write the code differently. Gennadiy P.S. I suspect simply removing using statements from boost::itest namespace and using fully qualified names for boost::unit_test symbols would do the trick. Unless we can find "nicer" solution I can do the change.

John Maddock

18 Jun 18 Jun

7:09 a.m.

New subject: ???[test]enable_if, etc. : was? : ?...multiprecision types ... for unit? tests?

...

Let's see what John thinks of decorating the names in multiprecision. He did not sound too enthused in our preliminary discussions.

I wasn't, but that's before I knew it was a compiler bug. If the bug's in the compiler then you just have to do what you have to do, so lets get 1.54 out and then search-and-replace-fix the names. John.

John Maddock

8 Jun 8 Jun

8:39 a.m.

New subject: [multiprecision] Are these types suitable as numeric types for unit tests?

...

I'm writing new numeric types, and my unit tests use MPL lists of numeric types. I usually use stuff like int, unsigned, and double, but now I'm adding cpp_int and cpp_dec_float_50. Those types were OK when I was just doing type equalities and sizeof checks. Now I'm doing tests that use objects of those types and I'm getting problems.

//==== typedef boost::mpl::list test_integer_types; typedef boost::mpl::list test_floating_types;

...

I'm getting warnings about integer overflow. The problem is at Line 59 of boost/test/tools/detail/print_helper.hpp. It sets an output stream's precision based on the digits given by std::numeric_limits.

That's harmless but annoying: it's because std::numeric_limits::digits is INT_MAX. The stream precision isn't ever used by integer types anyway...

...

This time it's an error, at Line 59 of boost/test/tools/floating_point_comparison.hpp. There no (close enough) matching function for "fpt_abs" from some "boost::multiprecision::detail::expression<..." type. (It was truncated by the display. I don't know how to get a clean print-out of errors from Code::Blocks.) I'm guessing the expression template setup is screwing things up.

Yes, it's because Boost.Test can't be used with expression template enabled types. It's a known issue, and I've added a patch for this: https://svn.boost.org/trac/boost/ticket/8272, but Genediiy seems to be MIA at present :-( Do you particularly want to test with expression-template enabled types (I reaslise there are cases when you do)? If not then you could use multiprecision types that have expression templates turned off and that should fix things. HTH, John.

Paul A. Bristow

8:45 a.m.

New subject: [multiprecision] Are these types suitable as numeric types for unit tests?

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Daryle Walker Sent: Saturday, June 08, 2013 7:58 AM To: Boost Dev-List Subject: [boost] [multiprecision] Are these types suitable as numeric types for unit tests?

I'm writing new numeric types, and my unit tests use MPL lists of numeric types. I usually use stuff like int, unsigned, and double, but now I'm adding cpp_int and cpp_dec_float_50. Those types were OK when I was just doing type equalities and sizeof checks. Now I'm doing tests that use objects of

those

...

types and I'm getting problems.

//==== typedef boost::mpl::list test_integer_types; typedef boost::mpl::list test_floating_types;

//...

BOOST_AUTO_TEST_CASE_TEMPLATE( test_complex_component_access1, T, test_integer_types ) { typedef complex_it real_type; typedef complex_it complex_type;

real_type a; real_type const & aa = a; complex_type b; complex_type const & bb = b;

a[ 0 ] = 6; BOOST_CHECK_EQUAL( a[0], T(6) ); BOOST_CHECK_EQUAL( T(6), aa[0] );

b[ 0 ] = 5; b[ 1 ] = 7; BOOST_CHECK_EQUAL( b[0], T(5) ); BOOST_CHECK_EQUAL( T(5), bb[0] ); BOOST_CHECK_EQUAL( b[1], T(7) ); BOOST_CHECK_EQUAL( T(7), bb[1] ); } //====

I'm getting warnings about integer overflow. The problem is at Line 59 of boost/test/tools/detail/print_helper.hpp. It sets an output stream's precision based on the digits given by std::numeric_limits.

//==== BOOST_AUTO_TEST_CASE_TEMPLATE( test_complex_component_access2, T, test_floating_types ) { typedef complex_it real_type; typedef complex_it complex_type;

real_type a; real_type const & aa = a; complex_type b; complex_type const & bb = b;

a[ 0 ] = 6.0; BOOST_CHECK_CLOSE( a[0], T(6.0), 0.1 ); BOOST_CHECK_CLOSE( T(6.0), aa[0], 0.1 );

b[ 0 ] = 5.5; b[ 1 ] = -7.0; BOOST_CHECK_CLOSE( b[0], T(5.5), 0.1 ); BOOST_CHECK_CLOSE( T(5.5), bb[0], 0.1 ); BOOST_CHECK_CLOSE( b[1], T(-7.0), 0.1 ); BOOST_CHECK_CLOSE( T(-7.0), bb[1], 0.1 ); } //====

This time it's an error, at Line 59 of boost/test/tools/floating_point_comparison.hpp. There no (close enough) matching function for "fpt_abs" from some "boost::multiprecision::detail::expression<..." type. (It was truncated by the display. I don't know how to get a clean print-out of errors from Code::Blocks.) I'm guessing the expression template setup is screwing things up.

I suspect you are right. I hit what looks like similar difficulties and provided an example https://svn.boost.org/trac/boost/changeset/82914 I added an example \boost-trunk\libs\math\example\test_cpp_float_close_fraction.cpp I suggest you use a type like this with expression templates switched off and see if that 'cures' the problem. This will at least pinpoint the problem? Long term it may be possible to change Boost.Test to make this work but our maintainer is rarely seen in action ;-) Paul PS I found I liked NetBeans much more than CodeBlocks. https://netbeans.org/ PPS Note to self - Boost.Math index does not have an entry for expression template switching, making it difficult to find in the docs. --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com Added example of switching expression templates off and using Boost.Test BOOST_CHECK_CLOSE_FRACTION macros.

4182

Age (days ago)

4192

Last active (days ago)

List overview

Download

25 comments

6 participants

participants (6)

Christopher Kormanyos
Daryle Walker
Gennadiy Rozental
John Maddock
legalize+jeeves＠mail.xmission.com
Paul A. Bristow