Hartmut Kaiser wrote:
John,
I'll look into this later tonight.
Thanks Harmut: if you need a simple user-defined number type to experiment with then try boost::math::concepts::real_concept in boost/math/concepts/real_concept.hpp.
Ok, I tried that and fixed the pow() issue first (it's in SVN now). After this change the code compiled, but as you pointed out the actual parsing fails. The reason is that std::numeric_limits<boost::math::concepts::real_concept>::max() always returns zero, which triggers the overflow detection in the spirit real_parser, making the overall parse fail.
I didn't investigate the numeric_limits::max issue, though. Do you have any ideas?
Ah, numeric_limits is deliberately not specialised for the real_concept type, because I wanted to work with types that vary precision at runtime, and numeric_limits just can't cope with that :-( I don't really know what to suggest, options seem to be: * Require numeric_limits support, and static assert if numeric_limits<>::is_specialized is false. This would probably preclude use with types like NTL::RR whose precision varies at runtime, unless the user basically "lies" by specializing numeric_limits on an ad-hock basis just to make the code compile. * Don't perform overflow checking if numeric_limits<>::is_specialized is false. * Use a runtime API to get the max value: the new math lib code has some API's for this, but you probably don't want to introduce the dependency :-( I guess the important thing is to pick a concept and stick with it (and document it for that matter), if can agree on a common concept even better, but it may not be possible to use the same concept for everything sadly. HTH, John.