Repository navigation
Cursor displays x, y coordinates with too much or too little precision #5726
Description
Currently, the x, y coordinates of the cursor (displayed by the interactive backend) are displayed with 6 significant digits (basically, this is due to ScalarFormatter.format_data_short using the "-12g" format string, which defaults to 6 significant digits). This leads to a few issues.
- The mouse position is typically only known with pixel-level precision (at least for Qt and Tk), so with screen sizes limited to a few thousand pixels, for axes limited to e.g. [0, 1], the cursor position should only be displayed with 4 significant digits.
- On the other hand, if the axes limits are far from the origin (say xlim = [1e5, 1e5+1]), the cursor position readout is useless because all significant digits are taken by the base offset.
Thus, I propose to change format_data_short (which AFAICT is only used for this purpose), so that it displays the coordinates with the same base offset as the axes do (but with the same absolute precision as the additional shift), and the additional shift with 4 significant digits (if we really wanted to do this properly perhaps we can get the axes size in pixels and decide accordingly, but that may be overdoing it).
Thoughts?
Activity
tacaswell commentedon Dec 23, 2015
👍 Getting these changes in for 2.0 would be great.
anntzer commentedon Dec 23, 2015
Is there an approximate timeline?
tacaswell commentedon Dec 23, 2015
'soon'. Many dragon inhabited rabbit holes were discovered by @mdboom. Probably first quarter next year.
mdboom commentedon Dec 29, 2015
I love that expression. What the hell were dragons doing in the rabbit holes? They should stick to their dragon caves!
WeatherGod commentedon Dec 29, 2015
I would worry about some rabbits that inhabit dragon caves...
https://www.youtube.com/watch?v=cCI18qAoKq4
On Tue, Dec 29, 2015 at 3:53 PM, Michael Droettboom <
notifications@github.com> wrote:
mdboom commentedon Dec 29, 2015
Yes. The rabbits I've been dealing with definitely had pointy teeth...
QuLogic commentedon May 29, 2016
We're (approximately) nearing the end now; @anntzer any chance you might make a PR out of your suggestions soon?
anntzer commentedon May 29, 2016
This is handled in my large formatter rewrite PR (https://github.com/matplotlib/matplotlib/pull/5804/files#diff-efde3b8d2ec4015b0fc910f1080cc492R560), but it unfortunately seems unlikely that it'll go into 2.0. To be honest I'd rather try to get that PR in instead of messing up again from scratch with that (nasty) part of the codebase...
QuLogic commentedon May 30, 2016
As you say, that PR is probably too large to go into 2.0; we may have to bump this issue as well, then.
tacaswell commentedon May 31, 2016
bumping the issue to 2.1.
timhoffm commentedon Jul 14, 2020
Fixed by #16776.