8000 Ensure image scale factors are scalars by ngoldbaum · Pull Request #10289 · matplotlib/matplotlib · GitHub
[go: up one dir, main page]

Skip to content

Ensure image scale factors are scalars #10289

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

Merged
merged 1 commit into from
Jan 23, 2018

Conversation

ngoldbaum
Copy link
Contributor

This avoids errors that get triggered by passing an ndarray subclass to imshow.

For example:

import numpy as np
from yt.units import km
from matplotlib import pyplot as plt

data = np.random.random((100, 100))*km
plt.imshow(data)
plt.show()

Or similarly with astropy:

import numpy as np
from astropy.units import km
from matplotlib import pyplot as plt

data = np.random.random((100, 100))*km
plt.imshow(data)
plt.show()

Before this patch, both of these commands raise an error because a_min and
a_max have units attached. By explicitly converting these to scalars we
avoid this failure mode.

PR Checklist

  • Has Pytest style unit tests
  • Code is PEP 8 compliant

@@ -394,8 +394,8 @@ def _make_image(self, A, in_bbox, out_bbox, clip_bbox, magnification=1.0,
A_scaled = np.empty(A.shape, dtype=scaled_dtype)
A_scaled[:] = A
A_scaled -= a_min
a_min = a_min.astype(scaled_dtype)
a_max = a_max.astype(scaled_dtype)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It took me a bit to understand why this was necessary (because ytarray inherits nparray). Can you add a comment that makes it clear why this extra call is needed? Otherwise looks fine to me!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added the comment

This avoids errors that get triggered by passing an ndarray subclass to
i
8000
mshow.

For example:

```python
import numpy as np
from yt.units import km
from matplotlib import pyplot as plt

data = np.random.random((100, 100))*km
plt.imshow(data)
plt.show()
```

Or similarly with `astropy`:

```python
import numpy as np
from astropy.units import km
from matplotlib import pyplot as plt

data = np.random.random((100, 100))*km
plt.imshow(data)
plt.show()
```

Before this patch, both of these commands raise an error because `a_min` and
`a_max` have units attached. By explicitly converting these to scalars we
avoid this failure mode.
Copy link
Contributor
@dopplershift dopplershift left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yay to more unit whack-a-mole!

Copy link
Member
@jklymak jklymak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@jklymak jklymak merged commit c281ccf into matplotlib:master Jan 23, 2018
@tacaswell tacaswell added this to the v2.2 milestone Jan 23, 2018
@tacaswell
Copy link
Member

The problem with duck typing is you have to agree on what a duck is.

@dopplershift
Copy link
Contributor

The real problem we have with numpy though is that it's too easy to take any duck and force it to be a mallard. (Have I taken the metaphor too far yet?)

@QuLogic QuLogic modified the milestones: needs sorting, v2.2.0 Feb 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants
0