From: John Maddock (john_at_[hidden])
Date: 2007-10-29 12:46:45
Hartmut Kaiser wrote:
>>> 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
> 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
* 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk