Joel de Guzman

You are hitting the limits of the precision of double that is the underlying computation data type used by, double_. There were attempts to extract the last bit of precision,...

> I heard of the issue and was actually looking into a reproducer. > > > In general, you need an accumulator that can provide more precision than a type...

> I cannot agree with that. AFAIK IEEE 754 was developed to achieve exact and consistent results. `93083996033856359` just does not have an exact mapping in `double` type, and Spirit...

Just to be clear: I am not dismissing this issue... It is looking like it is a bug. It would be good to tighten up the test cases for numbers...

> > IIRC, the accumulator has the same type (i.e. double in this case). > > No, Qi uses integer accumulator since [6832dc2](https://github.com/boostorg/spirit/commit/6832dc229872d7f9573a506cfe1ed640dc79871e) Ah, thanks for reminding me! > >...

> Here > > https://github.com/boostorg/spirit/blob/56b4a5b99c4b55d30b72c8e6969b88f406bc7576/include/boost/spirit/home/qi/numeric/detail/real_impl.hpp#L95 Right. And this is kinda what I was saying. Spirit is using the underlying type for the computation (except that I forgot about the accumulator...

> We can use a promoted data type in this case (which is already a special case with the if-else, so might not impact the speed too much), i.e. float->double...

I welcome any PR for improving the docs.

The fundamental rules for parsing are as follows (https://www.boost.org/doc/libs/1_67_0/libs/spirit/doc/html/spirit/advanced/indepth/parsers_indepth.html): Here are the basic rules for parsing: - The parser returns true if successful, false otherwise. - If successful, first is...

> This is clearly violated by container parsers (hello backtracking #703!). Agreed. It's a good chance to refine the rules then. Those are excellent observations.