[Spirit Qi] Failed to parse the following fixed format double

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[Spirit Qi] Failed to parse the following fixed format double

Boost - Users mailing list
Hello,

We've been here before, but it is still a problem. I formatted this
one using Boost.Format, "%1$.20f", especially dealing with 64-bit
floating point values:

"-6454866677007257221799838306103363329054216765979693126687924767750184064408021645577150612734391912932504859271476290909819606665305867922002041825515395649967939044362235953753132737391831714484437364695236622971838510661738713863719312223765488747173369566663518205119012003640541309414736378162701139968.00000000000000000000"

Grammar is defined:

numeric_sign %= (
    ('-' >> attr(numeric_sign_minus))
    | ('+' >> attr(numeric_sign_plus))
    )
    ;
float_lit %= real_parser<float_t, strict_ureal_policies<float_t>>{};
floating_point %= -numeric_sign >> float_lit;

With rules defined as:

qi::rule<iterator_type, numeric_sign_t()> numeric_sign;
qi::rule<iterator_type, float_t()> float_lit;
qi::rule<iterator_type, floating_point_number_t()> floating_point;

Where float_t is a defined part of the AST:

using float_t = double;

And floating_point maps to the floating_point_number_t, basically
mapping the Sign and Value.

Seems like we've been here before with inadequate response, however,
reading the Boost documentation, I do not see any reason any Qi should
be rejecting this value:

https://www.boost.org/doc/libs/1_69_0/libs/spirit/doc/html/spirit/qi/reference/numeric/real.html

Particularly the RealPolicies:

sign
    =   lit('+') | '-'
    ;

nan
    =   -lit("1.0#") >> no_case["nan"]
        >> -('(' >> *(char_ - ')') >> ')')
    ;

inf
    =   no_case[lit("inf") >> -lit("inity")]
    ;

floating_literal
    =   -sign >>
        (       nan
            |   inf
            |   fractional_constant >> -exponent_part
            |  +digit >> exponent_part
        )
    ;

fractional_constant
    =  *digit >> '.' >> +digit
    |  +digit >> -lit('.')
    ;

exponent_part
    =   (lit('e') | 'E') >> -sign >> +digit
    ;

Although the concern I have is that the RealPolicy grammar defined
above is not implemented as Qi Rules, per se, but rather brute force.
In other words, error prone in the ways that a brute force approach is
error prone.

Best regards,

Michael Powell
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [Spirit Qi] Failed to parse the following fixed format double

Boost - Users mailing list
On Sat, Jan 19, 2019 at 5:05 PM Michael Powell <[hidden email]> wrote:
>
> Hello,
>
> We've been here before, but it is still a problem. I formatted this
> one using Boost.Format, "%1$.20f", especially dealing with 64-bit
> floating point values:
>
> "-6454866677007257221799838306103363329054216765979693126687924767750184064408021645577150612734391912932504859271476290909819606665305867922002041825515395649967939044362235953753132737391831714484437364695236622971838510661738713863719312223765488747173369566663518205119012003640541309414736378162701139968.00000000000000000000"

A couple more examples of failing fixed point formatted double
precision floating point values:

"-2933203577849518722807582107921270303789124551628326833223026840288067720552584469718398734780494285760864383284291153435811556533627851666237668018198306411496865670893213895174427232870273854485740801234157498001928584582425137432930105057443647782995234273328228331519807104430353167966879393151302238208.00000000000000000000"

"-5575142993783585741080266667491263474365065567007147941126088591468810775271255177205047484910285258069829661948007476427372671344939243513169304773270960157491924753398062656733759664894978353176430823579581454223501775356229158988642579674006981268033954414994235729789365374969339689104743045516916424704.00000000000000000000"

"-10961106826538223321566456661622697491480936313401307083286539463405800627473400980352364856687771070172100174159400050681199843366266743862457103239362125692763404716870083938982037356857637487843703963982090861987853380143680798438559722884237142834679878087134795785244216620052002403762015568006217728.00000000000000000000"

> Grammar is defined:
>
> numeric_sign %= (
>     ('-' >> attr(numeric_sign_minus))
>     | ('+' >> attr(numeric_sign_plus))
>     )
>     ;
> float_lit %= real_parser<float_t, strict_ureal_policies<float_t>>{};
> floating_point %= -numeric_sign >> float_lit;
>
> With rules defined as:
>
> qi::rule<iterator_type, numeric_sign_t()> numeric_sign;
> qi::rule<iterator_type, float_t()> float_lit;
> qi::rule<iterator_type, floating_point_number_t()> floating_point;
>
> Where float_t is a defined part of the AST:
>
> using float_t = double;
>
> And floating_point maps to the floating_point_number_t, basically
> mapping the Sign and Value.
>
> Seems like we've been here before with inadequate response, however,
> reading the Boost documentation, I do not see any reason any Qi should
> be rejecting this value:
>
> https://www.boost.org/doc/libs/1_69_0/libs/spirit/doc/html/spirit/qi/reference/numeric/real.html
>
> Particularly the RealPolicies:
>
> sign
>     =   lit('+') | '-'
>     ;
>
> nan
>     =   -lit("1.0#") >> no_case["nan"]
>         >> -('(' >> *(char_ - ')') >> ')')
>     ;
>
> inf
>     =   no_case[lit("inf") >> -lit("inity")]
>     ;
>
> floating_literal
>     =   -sign >>
>         (       nan
>             |   inf
>             |   fractional_constant >> -exponent_part
>             |  +digit >> exponent_part
>         )
>     ;
>
> fractional_constant
>     =  *digit >> '.' >> +digit
>     |  +digit >> -lit('.')
>     ;
>
> exponent_part
>     =   (lit('e') | 'E') >> -sign >> +digit
>     ;
>
> Although the concern I have is that the RealPolicy grammar defined
> above is not implemented as Qi Rules, per se, but rather brute force.
> In other words, error prone in the ways that a brute force approach is
> error prone.
>
> Best regards,
>
> Michael Powell
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [Spirit Qi] Failed to parse the following fixed format double

Boost - Users mailing list
On Sat, Jan 19, 2019 at 5:17 PM Michael Powell <[hidden email]> wrote:

>
> On Sat, Jan 19, 2019 at 5:05 PM Michael Powell <[hidden email]> wrote:
> >
> > Hello,
> >
> > We've been here before, but it is still a problem. I formatted this
> > one using Boost.Format, "%1$.20f", especially dealing with 64-bit
> > floating point values:
> >
> > "-6454866677007257221799838306103363329054216765979693126687924767750184064408021645577150612734391912932504859271476290909819606665305867922002041825515395649967939044362235953753132737391831714484437364695236622971838510661738713863719312223765488747173369566663518205119012003640541309414736378162701139968.00000000000000000000"
>
> A couple more examples of failing fixed point formatted double
> precision floating point values:
>
> "-2933203577849518722807582107921270303789124551628326833223026840288067720552584469718398734780494285760864383284291153435811556533627851666237668018198306411496865670893213895174427232870273854485740801234157498001928584582425137432930105057443647782995234273328228331519807104430353167966879393151302238208.00000000000000000000"
>
> "-5575142993783585741080266667491263474365065567007147941126088591468810775271255177205047484910285258069829661948007476427372671344939243513169304773270960157491924753398062656733759664894978353176430823579581454223501775356229158988642579674006981268033954414994235729789365374969339689104743045516916424704.00000000000000000000"
>
> "-10961106826538223321566456661622697491480936313401307083286539463405800627473400980352364856687771070172100174159400050681199843366266743862457103239362125692763404716870083938982037356857637487843703963982090861987853380143680798438559722884237142834679878087134795785244216620052002403762015568006217728.00000000000000000000"

General and scientific formatted double precision floating point
values parse just fine. It's the fixed format that the parser seems to
have a problem with. Not sure whether being 64-bit is also a concern,
i.e. the size of the value itself.

When last I broached this topic, the author seemed to want to squeeze
his consumers for PR's. I'm not willing to do that, I'm definitely not
here to unit test his library(ies). I'm focused on my APPLICATION of
his library in the problem domain, that's it; end of story. However,
if I can better elaborate the report, I'd be happy to do so, caveats
on the constraints to my bandwidth.

Bottom line, if this is the limitation, fair enough, so be it. I'll
communicate that to my end users as such.

> > Grammar is defined:
> >
> > numeric_sign %= (
> >     ('-' >> attr(numeric_sign_minus))
> >     | ('+' >> attr(numeric_sign_plus))
> >     )
> >     ;
> > float_lit %= real_parser<float_t, strict_ureal_policies<float_t>>{};
> > floating_point %= -numeric_sign >> float_lit;
> >
> > With rules defined as:
> >
> > qi::rule<iterator_type, numeric_sign_t()> numeric_sign;
> > qi::rule<iterator_type, float_t()> float_lit;
> > qi::rule<iterator_type, floating_point_number_t()> floating_point;
> >
> > Where float_t is a defined part of the AST:
> >
> > using float_t = double;
> >
> > And floating_point maps to the floating_point_number_t, basically
> > mapping the Sign and Value.
> >
> > Seems like we've been here before with inadequate response, however,
> > reading the Boost documentation, I do not see any reason any Qi should
> > be rejecting this value:
> >
> > https://www.boost.org/doc/libs/1_69_0/libs/spirit/doc/html/spirit/qi/reference/numeric/real.html
> >
> > Particularly the RealPolicies:
> >
> > sign
> >     =   lit('+') | '-'
> >     ;
> >
> > nan
> >     =   -lit("1.0#") >> no_case["nan"]
> >         >> -('(' >> *(char_ - ')') >> ')')
> >     ;
> >
> > inf
> >     =   no_case[lit("inf") >> -lit("inity")]
> >     ;
> >
> > floating_literal
> >     =   -sign >>
> >         (       nan
> >             |   inf
> >             |   fractional_constant >> -exponent_part
> >             |  +digit >> exponent_part
> >         )
> >     ;
> >
> > fractional_constant
> >     =  *digit >> '.' >> +digit
> >     |  +digit >> -lit('.')
> >     ;
> >
> > exponent_part
> >     =   (lit('e') | 'E') >> -sign >> +digit
> >     ;
> >
> > Although the concern I have is that the RealPolicy grammar defined
> > above is not implemented as Qi Rules, per se, but rather brute force.
> > In other words, error prone in the ways that a brute force approach is
> > error prone.
> >
> > Best regards,
> >
> > Michael Powell
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users