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

Subject: Re: [Boost-users] [Spirit Qi] Failed to parse the following fixed format double
From: Michael Powell (mwpowellhtx_at_[hidden])
Date: 2019-01-19 22:28:06

On Sat, Jan 19, 2019 at 5:17 PM Michael Powell <mwpowellhtx_at_[hidden]> wrote:
>
> On Sat, Jan 19, 2019 at 5:05 PM Michael Powell <mwpowellhtx_at_[hidden]> 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