The calculation of positions doesn't always return the right amount. For a graph with a height set to 100 (with Y values ranging from 1 to 100), this results in the ticks/labels being all bunched up too close to each other.
This seems to be related to the Plot.decentPositions function. Testing it out in the REPL, I get:
Based on the implementation of decentPositions, I'd expect to get 5 positions back, not 10. Digging further, I found that decentPositions calls out to niceInterval with the number of desired positions as an argument.
In my case, decentPositions correctly asks niceInterval to calculate an interval for 5 positions but niceInterval incorrectly returns an interval that results in 10 positions. By removing the magMsdFinal coercion, I was able to make it work with my particular data set but there are a bunch of edge cases it still can't handle.
I think the algorithm of niceInterval needs to be tweeked such that range / interval equals the desired total passed in +/- 1. It might be worth adding a fuzz test around this?
I'm opening this issue in case someone else has run into the same issue and to get help from the community improving the niceInterval algorithm. If I find a good implementation, I will open a PR.
The calculation of positions doesn't always return the right amount. For a graph with a height set to 100 (with Y values ranging from 1 to 100), this results in the ticks/labels being all bunched up too close to each other.
This seems to be related to the
Plot.decentPositions
function. Testing it out in the REPL, I get:Based on the implementation of
decentPositions
, I'd expect to get 5 positions back, not 10. Digging further, I found thatdecentPositions
calls out toniceInterval
with the number of desired positions as an argument.In my case,
decentPositions
correctly asksniceInterval
to calculate an interval for 5 positions butniceInterval
incorrectly returns an interval that results in 10 positions. By removing themagMsdFinal
coercion, I was able to make it work with my particular data set but there are a bunch of edge cases it still can't handle.I think the algorithm of
niceInterval
needs to be tweeked such thatrange / interval
equals the desiredtotal
passed in +/- 1. It might be worth adding a fuzz test around this?I'm opening this issue in case someone else has run into the same issue and to get help from the community improving the
niceInterval
algorithm. If I find a good implementation, I will open a PR.Let me know if there's anything else I can do 😃