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

Subject: Re: [Boost-users] [spirit][karma] multiprecision modf
From: John Maddock (jz.maddock_at_[hidden])
Date: 2016-08-03 13:14:05

> 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_category<detail::expression<function, 
> log10_funct<mpfr_float_backend<0, allocate_dynamic> >, 
> number<mpfr_float_backend<0,
>       allocate_dynamic>, 
> boost::multiprecision::expression_template_option::et_on>, void, void> 
> >::value == number_kind_floating_point,
>       detail::expression<detail::function, 
> detail::floor_funct<typename 
> detail::backend_type<detail::expression<function,
>       log10_funct<mpfr_float_backend<0, allocate_dynamic> >, 
> number<mpfr_float_backend<0, allocate_dynamic>,
> boost::multiprecision::expression_template_option::et_on>, void, void> 
> >::type>, detail::expression<function, log10_funct<mpfr_float_backend<0,
>       allocate_dynamic> >, number<mpfr_float_backend<0, 
> allocate_dynamic>, 
> boost::multiprecision::expression_template_option::et_on>, void, void> >
>       >::type' (aka 
> 'boost::multiprecision::detail::expression<boost::multiprecision::detail::function,
> boost::multiprecision::detail::floor_funct<boost::multiprecision::backends::mpfr_float_backend<0, 
> allocate_dynamic> >,
> boost::multiprecision::detail::expression<boost::multiprecision::detail::function,
> boost::multiprecision::detail::log10_funct<boost::multiprecision::backends::mpfr_float_backend<0, 
> allocate_dynamic> >,
> boost::multiprecision::number<boost::multiprecision::backends::mpfr_float_backend<0, 
> allocate_dynamic>,
> 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<mpfr_float>, 
> 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.