[Spirit] Using real_parser with user-defined numeric types
I'm having a problem using real_parser, I define the parser as: real_parser<some-type> const rr_p; Then use it as: str_p("range")[assign_a(started, false)] && rr_p[assign_a(a)] && rr_p[assign_a(b)] Followed by a list of other alternative commands. When some-type is float/double/long double it all works OK, but as soon as I change some-type to boost::math::ntl::RR then I have two problems: 1) The code doesn't compile: spirit looks for std::pow rather than relying on ADL to find the right overload, I can work around this one for now by importing boost::math::ntl::pow into namespace std. 2) The parser doesn't work, any simple command like "range 0 1" is rejected as invalid. Is there something else I need to do here to enable support for UDT's? Thanks, John.
John, I'll look into this later tonight. Regards Hartmut
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Saturday, October 27, 2007 11:58 AM To: Boost mailing list Subject: [boost] [Spirit] Using real_parser with user-defined numeric types
I'm having a problem using real_parser, I define the parser as:
real_parser<some-type> const rr_p;
Then use it as:
str_p("range")[assign_a(started, false)] && rr_p[assign_a(a)] && rr_p[assign_a(b)]
Followed by a list of other alternative commands.
When some-type is float/double/long double it all works OK, but as soon as I change some-type to boost::math::ntl::RR then I have two problems:
1) The code doesn't compile: spirit looks for std::pow rather than relying on ADL to find the right overload, I can work around this one for now by importing boost::math::ntl::pow into namespace std. 2) The parser doesn't work, any simple command like "range 0 1" is rejected as invalid.
Is there something else I need to do here to enable support for UDT's?
Thanks, John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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. HTH, John.
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.
Could you send some minimal code, please? Regards Hartmut
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? Regards Hartmut
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.
John Maddock wrote:
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 :-(
Ok, Hartmut briefed me with this sometime this morning. It *is* indeed a bug with Spirit that's already been addressed in Spirit2. I'll see if I can patch Spirit1 code to follow the Spirit2 behavior. Do you need something immediately? Will a few days wait for a patch ok? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
John Maddock wrote:
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 :-(
Ok, Hartmut briefed me with this sometime this morning. It *is* indeed a bug with Spirit that's already been addressed in Spirit2. I'll see if I can patch Spirit1 code to follow the Spirit2 behavior. Do you need something immediately? Will a few days wait for a patch ok?
Alright, I think I have a fix. Is there a Trac ticket for this? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
participants (3)
-
Hartmut Kaiser -
Joel de Guzman -
John Maddock