User-defined double output precision

[pah]

Writing a double to an OutputStream current prints at most 6 significant
digits (according to the C standard).

The functions Set/GetDoublePrecision(), added to the Writer classes
can be used to fluently set the precision, i.e. the number of significant
digits to use for writing the double:

  Writer<...> writer(...);
  d.Accept(writer.SetDoublePrecision(12)); // print up to 12 significant digits

Additionally, a new Double(double,int) overload is added to the Writer classes,
allowing to programmatically write a single double value with a custom output precision:

writer.StartArray()
    .Double(1.2345) // == Double(..., writer.GetDoublePrecision())
    .Double(1.2345678,9) // explicit precision
    .EndArray();

An additional unit test Writer.DoublePrecision is added as well.
See upstream issues

• http://code.google.com/p/rapidjson/issues/detail?id=67
• http://code.google.com/p/rapidjson/issues/detail?id=68

(resubmitted #15 against master)

[drewnoakes]

I cannot find the code form c9c2d06 in current master. Writer<>::Double does not appear to be overloaded, nor is there a SetDoublePrecision function. Am I missing something?

[pah]

This feature has been superseded by the new dtoa implementation in #97, which always provides the shortest, exact output. Therefore, the need for a "limited precision" has been considered obsolete.

Still, in this comment, this question has popped up before.

[drewnoakes]

@pah, thanks for the update. Shame, as I would really like to have your commit in the lib. I know for a fact that my my code should never be sending more than 3dp, but I'm seeing cumulative rounding errors. Is this truly obsolete? For example, starting with the number 1.23 then repeatedly adding 0.01 to it will eventually result in numbers with long sequences of recurring digits. I'm happy to have this imprecision in my application's state so long as it disappears at the edges -- i.e. where I serialise data to JSON or otherwise.

What would you recommend as a viable alternative using the current master?

[pah]

Yes, some 3-decimal digit numbers cannot be represented exactly as double values, consequently the output will have trailing decimal digits. So for now, you may be out of luck with the current master, if you need to limit the output precision. Unfortunately, there have been quite some fixes in the current master since the merge of #97. see here. So it may not be acceptable to stick with 34dd0fd (last commit before the merge).

I sketched a solution to readd something like this in this comment. The main challenge is to properly define the output semantics for the different cases in Prettify).

I would suggest that you open a new issue and include a proposal how to handle the different cases based on a given "precision limit" from the user. Of course, you're welcome to submit a pull-request as well. 😄