Hello, 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. Catch: 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_none /// '-' , 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; https://developers.google.com/protocol-buffers/docs/reference/proto2-spec#fl... https://developers.google.com/protocol-buffers/docs/reference/proto2-spec#co... https://www.boost.org/doc/libs/1_68_0/libs/spirit/doc/html/spirit/qi/referen... Cheers, Michael Powell