On Sat, Jan 19, 2019 at 5:17 PM Michael Powell wrote:

On Sat, Jan 19, 2019 at 5:05 PM Michael Powell 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>{}; floating_point %= -numeric_sign >> float_lit;

With rules defined as:

qi::rule numeric_sign; qi::rule float_lit; qi::rule 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/referen...

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