|
Boost Users : |
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:17:04
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"
> 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 list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net