From: John Maddock (john_at_[hidden])
Date: 2007-10-29 12:46:45
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.