René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"SymmetricalLogLocator adds extra erroneous major ticks due to floating-point precision error","articleBody":"**Bug summary:**\r\n\r\n`SymmetricalLogLocator` appears to suffer a floating-point precision error in calculating the boundaries of the log regions of a `symlog` plot, which results in the addition of extra major ticks in the linear region of the plot.\r\n\r\n\u003cbr\u003e\r\n\r\n**Code reproducing the issue:**\r\n\r\n```python\r\nimport numpy as np\r\nimport matplotlib.pyplot as plt  # v3.2.2\r\n\r\nx = y = np.linspace(-1e5,1e5,100)\r\nplt.plot(x,y)\r\nplt.xscale('symlog', linthreshx=1e3, subsx=[2,3,4,5,6,7,8,9])\r\n```\r\n(OS=Windows 10, Python=3.8.3, Anaconda=2020.07)\r\n\r\n\u003cbr\u003e\r\n\r\n**Output (with error highlighted in red):**\r\n\u003cimg src=\"https://user-images.githubusercontent.com/2179825/96325527-2312cd80-0fee-11eb-8bd7-6de7d4837966.png\" width=\"300\" height=\"250\"\u003e\r\n\r\n\u003cbr\u003e\r\n\r\n**Discussion:**\r\n\r\nMajor ticks generated by `SymmetricalLogLocator` sometimes include an extra tick in the linear region:\r\n```python\r\n\u003e\u003e\u003e locator = mpl.ticker.SymmetricalLogLocator(linthresh=1e3, base=10)\r\n\u003e\u003e\u003e locator.tick_values(vmin=0, vmax=1e6)\r\n\r\n# array([0.e+00, 1.e+02, 1.e+03, 1.e+04, 1.e+05, 1.e+06])    \u003c-- 1.e+02 is in the linear region\r\n```\r\n\r\n`SymmetricalLogLocator` [calculates the inner (towards zero) boundaries of the log regions via the following base-agnostic logarithm](https://github.com/matplotlib/matplotlib/blob/v3.2.2/lib/matplotlib/ticker.py#L2596):\r\n```python\r\nlo = np.floor(np.log(linthresh) / np.log(base))\r\n```\r\n\r\nHowever, when `base=10`, some power-of-ten thresholds cause floating-point precision problems:\r\n```python\r\n\u003e\u003e\u003e base=10\r\n\u003e\u003e\u003e [np.log(linthresh)/np.log(base) for linthresh in base**np.arange(10)]\r\n\r\n# [0.0, 1.0, 2.0, 2.9999999999999996, 4.0, 5.0, 5.999999999999999, 7.0, 8.0, 8.999999999999998]\r\n```\r\nWith the `np.floor()` calculation, this introduces an additional erroneous innermost major tick.\r\n\r\n\u003cbr\u003e\r\n\r\n@dstansby proposed a possible fix to a related issue in https://github.com/matplotlib/matplotlib/pull/14309, which changes `np.floor()` to `np.ceil()`. This looks like it would work with the precision errors I identified above, which all err towards zero, but it would fail with bases that err away from zero, e.g., `base=5`:\r\n```python\r\n\u003e\u003e\u003e base=5\r\n\u003e\u003e\u003e [np.log(linthresh)/np.log(base) for linthresh in base**np.arange(10)]\r\n\r\n# [0.0, 1.0, 2.0, 3.0000000000000004, 4.0, 5.0, 6.000000000000001, 7.0, 8.0, 9.0]\r\n```\r\n\r\nOther possible solutions I can think of: (1) rounding to `base` within a certain proximity, or (2) adding a special case when `base=10` wherein `np.log10()` is used instead of `np.log()/np.log(base)`.","author":{"url":"https://github.com/JS3xton","@type":"Person","name":"JS3xton"},"datePublished":"2020-10-17T02:44:12.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":2},"url":"https://github.com/18757/matplotlib/issues/18757"}