Boost logo

Boost Users :

Subject: [Boost-users] [Spirit] parsing double precision issues
From: Michael Powell (mwpowellhtx_at_[hidden])
Date: 2018-11-14 18:58:23


I am continuing to work through my Protobuf parsing with
Constant/Floating-Point tests. Double precision is rearing its ugly
head and I am curious what's the best way to handle potentially
determining a healthy epsilon given the expected parsed value. For the
most part, I think it's going to work, but for the precision issues.

  REQUIRE( actual == expected )
with expansion:
  struct my::protobuf::ast::floating_point_t { 'val': 1.16624e+306,
'opt_sign': null }
  struct my::protobuf::ast::floating_point_t { 'val': 1.16624e+306,
'opt_sign': null }
with messages:
  Source: syntax = 'proto2';option L = 1.16624e+306;
  Delta was: 2.35309e+300

There was clearly a delta involved, most like a precision issue
encountered during the parse. Without going into a great deal of
depth, if possible:

namespace my { namespace protobuf { namespace ast {
using float_t = double;
enum num_sign_t {
    /// '-'
    , sign_minus
    /// '+'
    , sign_plus

// Which includes
struct floating_point_t : numeric_t<float_t> { /* ... */ };
} } }

// Without sign, dot required.
// >>> TODO: TBD: Precision issue? Or an actual double parsing issue? <<<
float_lit %= real_parser<ast::float_t, strict_ureal_policies<ast::float_t>>{};
floating_point_lit %= -num_lit_sign >> float_lit;

qi::rule<It, ast::num_sign_t()> num_lit_sign;

qi::rule<It, ast::float_t()> float_lit;
qi::rule<It, ast::floating_point_t()> floating_point_lit;


Michael Powell

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at