Skip to content
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.

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

'rounding' of x coordinates in plt.plot with large 64-bit numbers #2866

Closed
tunnell opened this issue Mar 5, 2014 · 7 comments
Closed

'rounding' of x coordinates in plt.plot with large 64-bit numbers #2866

tunnell opened this issue Mar 5, 2014 · 7 comments

Comments

@tunnell
Copy link

tunnell commented Mar 5, 2014

I've having a problem with 64 bit integers and pyplot.plot (or scatter). Each x value is unique, but they are plotted such that the (x1, y1) is directly above the (x0, x1). It seems to combine every 10 or so x coordinates into one or is doing some sort of rounding. Has anybody seen this before?

It looks like it is binning in x?

import matplotlib.pyplot as plt
import numpy as np

x = np.arange(136897843038780956, 136897843038780956 + 1000, dtype=np.int64)
#x = np.arange(0,1000, dtype=np.int64) # works                                                                                                                     
y = np.arange(0,1000, dtype=np.int64)
plt.plot(x, y)
plt.show()
@tunnell
Copy link
Author

tunnell commented Mar 5, 2014

P.S. 136897843038780956 is representable by 64 bits... so it's not that.

@tunnell
Copy link
Author

tunnell commented Mar 5, 2014

Update: is it casting to float?

@WeatherGod
Copy link
Member

That is quite possible

@tacaswell tacaswell added this to the v1.4.x milestone Mar 5, 2014
@tacaswell
Copy link
Member

Interesting.....

I have tagged this as 1.4.x as I suspect that is is something subtle/nasty to fix.

Naive guess is that there is a loss of precision (via a cast to a float) some place in the transform stack.

@efiring
Copy link
Member

efiring commented Mar 5, 2014

All plotting is done using floating point. This is not going to change. You need to subtract a sufficiently large offset manually, while you are still dealing with integers, before passing your array into mpl. This is not a bug, it is just an inherent limitation based on the way mpl works. I can't imagine that we would rework every nook and cranny of mpl to work with 64-bit integers.

@tacaswell tacaswell removed this from the v1.4.x milestone Mar 5, 2014
@efiring
Copy link
Member

efiring commented Mar 5, 2014

Unfortunately, I think it would be very cumbersome to try to trap such cases and issue a warning. The case you describe is quite unusual. Notice that tick labeling also would require special care; I really think that recognizing and handling this type of situation has to be the responsibility of the user, who knows what the inputs are and what the desired plot should look like. The software can't anticipate and automatically deal with every possible extreme case.

@tunnell
Copy link
Author

tunnell commented Mar 5, 2014

Thanks for feedback. I agree that for most cases, the user should know: it makes perfect sense if somebody starts thinking about how it would need to be coded on your end. However, at least in scientific settings, I think it's a somewhat less extreme case. People use matplotlib and numpy for 'data exploration' (i.e. making plots to understanding aspects of the data) that can involve 64 bit numbers since, for example, there are instruments with that level of information. However, now that this issue exists in the issue tracker, at least people can find this edge case. Thanks again for the great tool.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants