Skip to content

Cursor displays x, y coordinates with too much or too little precision #5726

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
anntzer opened this issue Dec 23, 2015 · 11 comments
Closed

Cursor displays x, y coordinates with too much or too little precision #5726

anntzer opened this issue Dec 23, 2015 · 11 comments
Milestone
v3.3.0

Comments

@anntzer
Copy link
Contributor

anntzer commented Dec 23, 2015

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?
@tacaswell
Copy link
Member

👍 Getting these changes in for 2.0 would be great.

@tacaswell tacaswell added this to the next major release (2.0) milestone Dec 23, 2015
@anntzer
Copy link
Contributor Author

anntzer commented Dec 23, 2015

Is there an approximate timeline?

@tacaswell
Copy link
Member

'soon'. Many dragon inhabited rabbit holes were discovered by @mdboom. Probably first quarter next year.

@mdboom
Copy link
Member

mdboom commented Dec 29, 2015

Many dragon inhabited rabbit holes were discovered by @mdboom

I love that expression. What the hell were dragons doing in the rabbit holes? They should stick to their dragon caves!

@WeatherGod
Copy link
Member

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:

Many dragon inhabited rabbit holes were discovered by @mdboom
https://github.com/mdboom

I love that expression. What the hell were dragons doing in the rabbit
holes? They should stick to their dragon caves!

—
Reply to this email directly or view it on GitHub
#5726 (comment)
.

@mdboom
Copy link
Member

mdboom commented Dec 29, 2015

Yes. The rabbits I've been dealing with definitely had pointy teeth...

@QuLogic
Copy link
Member

QuLogic commented May 29, 2016

We're (approximately) nearing the end now; @anntzer any chance you might make a PR out of your suggestions soon?

@anntzer
Copy link
Contributor Author

anntzer commented 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
Copy link
Member

QuLogic commented 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 tacaswell modified the milestones: 2.1 (next point release), 2.0 (style change major release) May 31, 2016
@tacaswell
Copy link
Member

bumping the issue to 2.1.

@tacaswell tacaswell modified the milestones: 2.1 (next point release), 2.2 (next next feature release) Oct 3, 2017
@timhoffm
Copy link
Member

Fixed by #16776.

@QuLogic QuLogic modified the milestones: needs sorting, v3.3.0 Jul 14, 2020
@anntzer anntzer mentioned this issue Apr 11, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
v3.3.0
Development

No branches or pull requests
6 participants
@mdboom @tacaswell @WeatherGod @QuLogic @anntzer @timhoffm