Re: [boost] [Spirit] Using real_parser with user-definednumerictypes

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.