[Karma] Real generator broken in 1.76

[chambm]

#include <iostream>
#include <string>
#include <limits>
#include <algorithm>
#include <boost/spirit/include/karma.hpp>

int main()
{
    std::cout << BOOST_VERSION << std::endl;
    
    double values[] = { 0.9999, 1.9999, 2.9999, 3.9999, 4.9999, 5.9999, 6.9999, 7.9999, 8.9999, 9.9, 9.9999, 10.99, 10.9999, 11.999, 11.9999 };};
    for (auto value : values)
    {
        std::string s;
        std::back_insert_iterator<std::string> sink(s);
        boost::spirit::karma::generate(sink, boost::spirit::karma::real_generator<>(), value);
        std::cout << s << std::endl;
    }
}

At Coliru as of 6/3/2021, it incorrectly generates:

107600
1.0
2.0
3.0
4.0
5.0
6.0
7.0
8.0
9.0
9.9
1.0
10.99
1.0
11.999
1.0

At rextester it correctly generates:

106501
1.0
2.0
3.0
4.0
5.0
6.0
7.0
8.0
9.0
9.9
10.0
10.99
11.0
11.999
12.0

I'm not sure when it broke, and it's not broken for every input value, but for fairly mundane values it's very wrong. It seems to have something to do with the number of decimals places.

[Kojoley]

Caused by #629. @hkaiser any ideas?

[chambm]

                if (integer_part >= 10.)
                {
                    integer_part /= 10.;
                    ++dim;
                }

Looks very suspect for this bug. :) I can confirm that reverting #629 fixes the issue.

[fiesh]

Oh good, there's already a ticket for this. This hit us pretty hard in production code.

[hkaiser]

Looks very suspect for this bug. :) I can confirm that reverting #629 fixes the issue.

We'll have to find another fix for #628, then :/

[RockinRoel]

My guess is that the code @chambm mentioned misses the 0 == (Policies::fmtflags::fixed & flags) check that is used below to add the exponent.

[Kojoley]

IIRC from my investigation back then: in any mode the value is rounded, for fmtflags:fixed to the number of digits (it is useful, but counterintuitive, because the standard library iostream does round in fixed mode), the issue is that it is not rounded in all the cases and the workaround in #629 just traded one cases for others. I have a fix but it uses pow10(trunc(floor(log10(abs_n)))) which seems to be pretty heavy on performance and I still does not have a way to prove its correctness for all the cases.

[Kojoley]

Ah, I remembered that my fix also introduces 2 ULP error for max cases in scientific mode which might imply there are should be more, and I did not feel it is an acceptable, so I abandoned the whole idea.