Re: [Boost-users] [spirit][karma] multiprecision modf

Here's the new error message:

In file included from test/generating/mpfr_float.cpp:27: In file included from ./include/bertini2/io/generators.hpp:44: In file included from /usr/local/include/boost/spirit/include/karma.hpp:16: In file included from /usr/local/include/boost/spirit/home/karma.hpp:15: In file included from /usr/local/include/boost/spirit/home/karma/numeric.hpp:16: In file included from /usr/local/include/boost/spirit/home/karma/numeric/real.hpp:32: /usr/local/include/boost/spirit/home/karma/numeric/real_policies.hpp:263:39: error: incompatible operand types ('int' and 'typename enable_if_c >, number, boost::multiprecision::expression_template_option::et_on>, void, void>

...

::value == number_kind_floating_point, detail::expression >, number, boost::multiprecision::expression_template_option::et_on>, void, void> ::type>, detail::expression >, number, boost::multiprecision::expression_template_option::et_on>, void, void> > >::type' (aka 'boost::multiprecision::detail::expression >, boost::multiprecision::detail::expression >, boost::multiprecision::number, boost::multiprecision::expression_template_option::et_on>, void, void>, void, void>')) (traits::test_zero(n) ? 0 : floor(log10(n))) + 1;

I'm afraid that code is incompatible with expression templates: the two halves of the conditional expression have different/unrelated types which aren't convertible to each other. An explicit cast is needed here to make the code expression-template compatible. Or else use a number type with expression templates turned off. Suggest you contact the spirit developers (they have their own mailing list I believe) and see what their intent is here.

As a last question, I am unsure about the use of the a function parameter in my specialization BertiniNumPolicy, particularly the precision(mpfr_float) function. In the documentation and examples I have seen for specializations, this function doesn't use the argument. Is it ok that it does, that it checks the actual precision of x??? See above code. An alternate method for me might be to just use the str() method provided by the number<...> from Multiprecision, but it seems like since this type is numeric, I'd like to be able to generate using the numeric generators from Karma.

That looks to be the intent yes. Note however, that it's a conceptual requirement of karma that the number have numeric_limits specialized - that's not true for type mpfr_float since most of the fields would have to vary at runtime which isn't possible for numeric_limits. Technically we could provide a specialization that defines the members that are constant and leaves the others as undefined/zero/infinity, but it's not clear what's the right thing to do here - numeric_limits wasn't designed for this kind of type it seems :( I'm changing the subject line to include spirit/karma in hopes that their developers will see this and chip in.... we should really find a way to make the libraries work better together. HTH, John.