Fix linear scale tick format precision for non-fixed-point formats #1574
Conversation
|
Thanks for this pull request. I agree with the gist of your fix. Here are two related issues:
The second issue is why the replacer function looks at the variable j—that’s the type of the specified format (used currently to check for the "%" format type). I think you’ll need to move the code into the replacer so that you can use this parsed type format, and leave the code outside the replacer to only handle the default ",." + precision + "f" format. |
Add a unit test case for it.
…essary. Add unit test cases for % format.
|
Thanks for the tips. Function d3_scale_linearTickFormat now parses the format specifier and I put most of the precision computation in a helper function which won't be called in the default case. Format types "r" and "p" are correctly handled now, I think (added a couple more unit tests). |
There was a problem hiding this comment.
This doesn’t need to be enclosed inside d3_scale_linearTickFormat, and so could be moved out to a global d3_scale_linearPrecision function.
|
I made some formatting changes and merged this into a new pull request, #1590. If you want to make any further changes, please submit them to the fix-tick-format-precision branch. Thank you for your contribution! |
Function d3.scale.linear.tickFormat() computes the precision for formatting tick values, but assumed that the format was "f" (fixed point). For other formats such as "s" and "e" ticks might have the wrong precision (e.g., not be uniquely labeled) because the "precision" value used in those format specifiers has a different meaning. This fixes that issue, and includes some unit tests which pass only with the fix.