[SERVER-37450] Value::toString() string conversion for input double needs improvement Created: 03/Oct/18 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Aggregation Framework |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Patrick Meredith | Assignee: | Backlog - Query Execution |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Query Execution
|
| Participants: |
| Description |
|
Currently, converting doubles to strings produces strings no longer than 6 characters, and drops anything after the decimal place that would require going above 6 characters. At 6 decimal places it automatically converts to scientific notation. This is an issue resulting from
which can be seen here: The easiest way to improve this is to change the operator << definition for bson docs here: Since this appears to be a problem even using std::setprecision (it sets the number of characters in the string instead of the actual precision), I would suggest using std::sprintf and std::snprintf like the following:
If we decide we want to use 10 decimal places. |
| Comments |
| Comment by Bruce Lucas (Inactive) [ 26/Nov/18 ] | |||||
|
It seems reasonable that the conversion should round-trip, i.e. the conversion to string and back to double should give you back the same number. There's a constant maxdigits10 that defines the number of digits of precision required to do this (it's 17 for double). That page also implies that setprecision(maxdigits10) should cause the << operator to behave this way. | |||||
| Comment by Asya Kamsky [ 26/Nov/18 ] | |||||
|
Here is the actual original ticket that I knew I filed in 2014 | |||||
| Comment by Asya Kamsky [ 26/Nov/18 ] | |||||
|
david.storch that's only the case for some inputs
| |||||
| Comment by Asya Kamsky [ 15/Nov/18 ] | |||||
|
This looks like duplicate of | |||||
| Comment by Charlie Swanson [ 26/Oct/18 ] | |||||
|
asya to investigate if there is a duplicate ticket. Please put it back into Needs Triage with your findings. | |||||
| Comment by David Storch [ 03/Oct/18 ] | |||||
|
Gotcha. As a concrete example:
results in the output string "500000" rather than "500000.1". | |||||
| Comment by Patrick Meredith [ 03/Oct/18 ] | |||||
|
david.storch Yes, it has user-facing impact when issuing `$convert` from a double value to a string. | |||||
| Comment by David Storch [ 03/Oct/18 ] | |||||
|
patrick.meredith, do I understand correctly that you are specifically talking about the implementation of Value::toString(), when the Value represents a NumberDouble? Does this have any user-facing impact? | |||||
| Comment by Patrick Meredith [ 03/Oct/18 ] | |||||
|
Another option is to forgo the first snprintf that figures out the size and just use some max length like 100 (and use snprintf for format). Alloca'ing 100 bytes takes the same time as alloca'ing n bytes, so this might end up being faster.:
|