[spirit] real_p fails on negative exponent

Jan Boehme

8 Dec 2008 8 Dec '08

11:29 a.m.

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' 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.

Attachments:

attachment.html (text/html — 940 bytes)

Show replies by date

Joel de Guzman

8 Dec 8 Dec

1:07 p.m.

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' 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

1:09 p.m.

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' 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

Jan Boehme

1:55 p.m.

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' 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.

Jeroen N. Witmond

4 p.m.

New subject: Where is documented? Was: [spirit] real_p fails on negative exponent

Jan Boehme 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.

John Maddock

4:58 p.m.

New subject: Where is documented? Was: [spirit] real_p fails on negative exponent

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.

Joel de Guzman

11:52 p.m.

New subject: Where is documented? Was: [spirit] real_p fails on negative exponent

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 which is sufficient for me. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net

Joel de Guzman

11:55 p.m.

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' 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

Jan Boehme

11 Dec 11 Dec

10:24 a.m.

Hi Joel, On Tue, Dec 9, 2008 at 12:55 AM, Joel de Guzman 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' 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.

Joel de Guzman

12:23 p.m.

Jan Boehme wrote:

...

Hi Joel,

On Tue, Dec 9, 2008 at 12:55 AM, Joel de Guzman 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' 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

5918

Age (days ago)

5921

Last active (days ago)

List overview

Download

9 comments

4 participants

participants (4)

Jan Boehme
Jeroen N. Witmond
Joel de Guzman
John Maddock