MaxNLocator 'steps' validation; and documentation. Closes #7578. #7586
Conversation
| # Make an extended staircase within which the needed | ||
| # step will be found. This is probably much larger | ||
| # than necessary. | ||
| flights = (0.1 * steps[:-1], steps, 10 * steps[1]) |
There was a problem hiding this comment.
OK, I never noticed this on the previous PR, but why is the third entry ten times the second step, and not ten times the second-to-the-last steps in the same way as the first element?
There was a problem hiding this comment.
If steps is [1, 2, 5, 10], then we want extended steps to be [0.1, 0.2, 0.5, 1, 2, 5, 10, 20].
There was a problem hiding this comment.
Right, so I was wondering why 20 and not all the way to 100? Is it just redundant?
There was a problem hiding this comment.
The strategy is to start with the largest step and work down to smaller ones, finding the smallest step that doesn't lead to too many intervals. Everything is first scaled by a power of 10 based on an initial estimate. Normally, this means that starting at the 10 would be adequate, but occasionally one step larger is needed, hence the inclusion of the next step past 10. I couldn't see any circumstance that would require starting with a larger step than that, so I stopped there.
| steps = np.asarray(steps) | ||
| if np.any(np.diff(steps) <= 0): | ||
| raise ValueError('steps argument must be uniformly increasing') | ||
| if np.any((steps > 10) | (steps < 1)): |
There was a problem hiding this comment.
Since you've already checked that it's increasing, you only need to check the first/last elements, I think.
This adds validation of the "steps" kwarg, fixes a bug in the implementation of the "integer" kwarg, and adds a note to dflt_style_changes.rst regarding the algorithm change in MaxNLocator.