[spirit] real_p fails on negative exponent
Hi, on my system (RHEL3, libc 2.3.2, gcc 3.2.3, Intel 10.1 which is used to compile and link) real_p fails to parse real numbers like 1.0E-001 and it is most likely the negative exponent as 1.0E001 works as expected. Our investigations brought us to numerics.hpp line 162 where the int parser which is used by real_p is declared as 'int_parser<T, 10, 1, -1>' with T=double. I don't see the reason for this yet and the 'out of the box' int parser 'int_p' itself is declared using 'int_parser<int>'. Here my questions: Do I have to expect any problems using int instead double for the real_p exp_n parser? Is this a kind of a mistake as even int_p is declared using 'int'? Thank you very much for your support, Jan. p.s.: Yes, I know gcc 3.2.3 isn't officially supported by boost but please consider helping me even so, thanks.
Jan Boehme wrote:
Hi,
on my system (RHEL3, libc 2.3.2, gcc 3.2.3, Intel 10.1 which is used to compile and link) real_p fails to parse real numbers like 1.0E-001 and it is most likely the negative exponent as 1.0E001 works as expected. Our investigations brought us to numerics.hpp line 162 where the int parser which is used by real_p is declared as 'int_parser<T, 10, 1, -1>' with T=double. I don't see the reason for this yet and the 'out of the box' int parser 'int_p' itself is declared using 'int_parser<int>'.
Here my questions: Do I have to expect any problems using int instead double for the real_p exp_n parser? Is this a kind of a mistake as even int_p is declared using 'int'?
Please post a minimal test case. I'd venture a guess that the problem is elsewhere. We do have real_p tests with negative exponents. And all is fine, as expected. I did test your case and it works fine: added this in numeric_tests.cpp: BOOST_TEST(parse("1.0E-001", real_p).full); // Good. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Joel de Guzman wrote:
Jan Boehme wrote:
Hi,
on my system (RHEL3, libc 2.3.2, gcc 3.2.3, Intel 10.1 which is used to compile and link) real_p fails to parse real numbers like 1.0E-001 and it is most likely the negative exponent as 1.0E001 works as expected. Our investigations brought us to numerics.hpp line 162 where the int parser which is used by real_p is declared as 'int_parser<T, 10, 1, -1>' with T=double. I don't see the reason for this yet and the 'out of the box' int parser 'int_p' itself is declared using 'int_parser<int>'.
Here my questions: Do I have to expect any problems using int instead double for the real_p exp_n parser? Is this a kind of a mistake as even int_p is declared using 'int'?
Please post a minimal test case. I'd venture a guess that the problem is elsewhere. We do have real_p tests with negative exponents. And all is fine, as expected. I did test your case and it works fine:
added this in numeric_tests.cpp:
BOOST_TEST(parse("1.0E-001", real_p).full); // Good.
Oh and BTW, there's a Spirit mailing list: https://lists.sourceforge.net/lists/listinfo/spirit-general Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Hi Joel, On Mon, Dec 8, 2008 at 2:07 PM, Joel de Guzman wrote:
Jan Boehme wrote:
Hi,
on my system (RHEL3, libc 2.3.2, gcc 3.2.3, Intel 10.1 which is used to compile and link) real_p fails to parse real numbers like 1.0E-001 and it is most likely the negative exponent as 1.0E001 works as expected. Our investigations brought us to numerics.hpp line 162 where the int parser which is used by real_p is declared as 'int_parser<T, 10, 1, -1>' with T=double. I don't see the reason for this yet and the 'out of the box' int parser 'int_p' itself is declared using 'int_parser<int>'.
Here my questions: Do I have to expect any problems using int instead double for the real_p exp_n parser? Is this a kind of a mistake as even int_p is declared using 'int'?
Please post a minimal test case. I'd venture a guess that the problem is elsewhere. We do have real_p tests with negative exponents. And all is fine, as expected. I did test your case and it works fine:
added this in numeric_tests.cpp:
BOOST_TEST(parse("1.0E-001", real_p).full); // Good.
please have a look on my system specs. Maybe I should say that I haven't any problems using a modern c++ compiler like gcc 4.2.4 plus intel 10.1. You did provide a minimal test case yourself: this test runs fail on my system using boost 1.37 and only my 'workaround' let this rule run sucessfully on this machine. It consumes all chars including 'E' and then '-' doesn't match. Did you try it on a gcc3.2.x too? Thanks, Jan.
Jan Boehme <jan.boehme <at> googlemail.com> writes:
Hi Joel,
On Mon, Dec 8, 2008 at 2:07 PM, Joel de Guzman wrote:
I did test your case and it works fine:
added this in numeric_tests.cpp:
BOOST_TEST(parse("1.0E-001", real_p).full); // Good.
I'm new to boost and I would like to know more about BOOT_TEST. I tried the search option on the Boost home page, but it didn't return any useful results. Were can I find the documentation for BOOST_TEST? Regards, Jeroen.
Jeroen N. Witmond wrote:
I did test your case and it works fine:
added this in numeric_tests.cpp:
BOOST_TEST(parse("1.0E-001", real_p).full); // Good.
I'm new to boost and I would like to know more about BOOT_TEST. I tried the search option on the Boost home page, but it didn't return any useful results.
Were can I find the documentation for BOOST_TEST?
Ah, it's been deprecated in favour of BOOST_CHECK. Full list of Unit test macros here: http://www.boost.org/doc/libs/1_37_0/libs/test/doc/html/utf/testing-tools/re... HTH, John.
John Maddock wrote:
Jeroen N. Witmond wrote:
I did test your case and it works fine:
added this in numeric_tests.cpp:
BOOST_TEST(parse("1.0E-001", real_p).full); // Good.
I'm new to boost and I would like to know more about BOOT_TEST. I tried the search option on the Boost home page, but it didn't return any useful results.
Were can I find the documentation for BOOST_TEST?
Ah, it's been deprecated in favour of BOOST_CHECK.
Full list of Unit test macros here: http://www.boost.org/doc/libs/1_37_0/libs/test/doc/html/utf/testing-tools/re...
No, I'm not using the test system. I am using #include <boost/detail/lightweight_test.hpp> which is sufficient for me. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Jan Boehme wrote:
Hi Joel,
On Mon, Dec 8, 2008 at 2:07 PM, Joel de Guzman wrote:
Jan Boehme wrote:
Hi,
on my system (RHEL3, libc 2.3.2, gcc 3.2.3, Intel 10.1 which is used to compile and link) real_p fails to parse real numbers like 1.0E-001 and it is most likely the negative exponent as 1.0E001 works as expected. Our investigations brought us to numerics.hpp line 162 where the int parser which is used by real_p is declared as 'int_parser<T, 10, 1, -1>' with T=double. I don't see the reason for this yet and the 'out of the box' int parser 'int_p' itself is declared using 'int_parser<int>'.
Here my questions: Do I have to expect any problems using int instead double for the real_p exp_n parser? Is this a kind of a mistake as even int_p is declared using 'int'? Please post a minimal test case. I'd venture a guess that the problem is elsewhere. We do have real_p tests with negative exponents. And all is fine, as expected. I did test your case and it works fine:
added this in numeric_tests.cpp:
BOOST_TEST(parse("1.0E-001", real_p).full); // Good.
please have a look on my system specs. Maybe I should say that I haven't any problems using a modern c++ compiler like gcc 4.2.4 plus intel 10.1.
You did provide a minimal test case yourself: this test runs fail on my system using boost 1.37 and only my 'workaround' let this rule run sucessfully on this machine. It consumes all chars including 'E' and then '-' doesn't match. Did you try it on a gcc3.2.x too?
I've been using 3.2 until last month. All of Spirit's tests are running fine. I'll take another look. BTW, int_parser<double> is perfectly fine. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Hi Joel, On Tue, Dec 9, 2008 at 12:55 AM, Joel de Guzman <joel@boost-consulting.com> wrote:
Jan Boehme wrote:
Hi Joel,
On Mon, Dec 8, 2008 at 2:07 PM, Joel de Guzman wrote:
Jan Boehme wrote:
Hi,
on my system (RHEL3, libc 2.3.2, gcc 3.2.3, Intel 10.1 which is used to compile and link) real_p fails to parse real numbers like 1.0E-001 and it is most likely the negative exponent as 1.0E001 works as expected. Our investigations brought us to numerics.hpp line 162 where the int parser which is used by real_p is declared as 'int_parser<T, 10, 1, -1>' with T=double. I don't see the reason for this yet and the 'out of the box' int parser 'int_p' itself is declared using 'int_parser<int>'.
Here my questions: Do I have to expect any problems using int instead double for the real_p exp_n parser? Is this a kind of a mistake as even int_p is declared using 'int'?
Please post a minimal test case. I'd venture a guess that the problem is elsewhere. We do have real_p tests with negative exponents. And all is fine, as expected. I did test your case and it works fine:
added this in numeric_tests.cpp:
BOOST_TEST(parse("1.0E-001", real_p).full); // Good.
please have a look on my system specs. Maybe I should say that I haven't any problems using a modern c++ compiler like gcc 4.2.4 plus intel 10.1.
You did provide a minimal test case yourself: this test runs fail on my system using boost 1.37 and only my 'workaround' let this rule run successfully on this machine. It consumes all chars including 'E' and then '-' doesn't match. Did you try it on a gcc3.2.x too?
I've been using 3.2 until last month. All of Spirit's tests are running fine. I'll take another look.
BTW, int_parser<double> is perfectly fine.
if that's perfectly fine why the standard int parser isn't parametrized using double? The problem isn't a gcc issue. I compiled your sample using icpc previously and checked the plain gcc 3.2.3 now which did a nice job. After that I installed a couple of Intel c++ compilers for Linux and the test did fail on each of them. I would like confront the Intel support with this issue if you encourage me to do so. Regards, Jan.
Jan Boehme wrote:
Hi Joel,
On Tue, Dec 9, 2008 at 12:55 AM, Joel de Guzman <joel@boost-consulting.com> wrote:
Jan Boehme wrote:
Hi Joel,
Jan Boehme wrote:
Hi,
on my system (RHEL3, libc 2.3.2, gcc 3.2.3, Intel 10.1 which is used to compile and link) real_p fails to parse real numbers like 1.0E-001 and it is most likely the negative exponent as 1.0E001 works as expected. Our investigations brought us to numerics.hpp line 162 where the int parser which is used by real_p is declared as 'int_parser<T, 10, 1, -1>' with T=double. I don't see the reason for this yet and the 'out of the box' int parser 'int_p' itself is declared using 'int_parser<int>'.
Here my questions: Do I have to expect any problems using int instead double for the real_p exp_n parser? Is this a kind of a mistake as even int_p is declared using 'int'? Please post a minimal test case. I'd venture a guess that the problem is elsewhere. We do have real_p tests with negative exponents. And all is fine, as expected. I did test your case and it works fine:
added this in numeric_tests.cpp:
BOOST_TEST(parse("1.0E-001", real_p).full); // Good.
On Mon, Dec 8, 2008 at 2:07 PM, Joel de Guzman wrote: please have a look on my system specs. Maybe I should say that I haven't any problems using a modern c++ compiler like gcc 4.2.4 plus intel 10.1.
You did provide a minimal test case yourself: this test runs fail on my system using boost 1.37 and only my 'workaround' let this rule run successfully on this machine. It consumes all chars including 'E' and then '-' doesn't match. Did you try it on a gcc3.2.x too? I've been using 3.2 until last month. All of Spirit's tests are running fine. I'll take another look.
BTW, int_parser<double> is perfectly fine.
if that's perfectly fine why the standard int parser isn't parametrized using double?
Why should it? T==int is all the int parser needs. Depending on your needs, you can use T==double if you want, or a big_int, if you will. It's just that the real parser uses its T type (which defaults to double) for the exponent.
The problem isn't a gcc issue. I compiled your sample using icpc previously and checked the plain gcc 3.2.3 now which did a nice job. After that I installed a couple of Intel c++ compilers for Linux and the test did fail on each of them. I would like confront the Intel support with this issue if you encourage me to do so.
I think it's best to first isolate the problem into some minimal code not using spirit. That means pinpointing what the real problem is. You gave a hint that the '-' doesn't match. That part of the code is actually very simple and can be isolated into a test code. Stepping through the code in the debugger should reveal the problem. Alas, I do not have the intel compiler :( Best, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
participants (4)
-
Jan Boehme -
Jeroen N. Witmond -
Joel de Guzman -
John Maddock