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
BUG: master has broken some 3d plots #2808
Comments
is it only the tri family of functions that are broken? |
You can fix this issue by : |
Hey, here's another fix. Basically, what I think is happening is: when The file in question is @@ -720,9 +720,12 @@ class _CollectionWithSizes(Collection):
self._sizes = np.asarray(sizes)
self._transforms = np.zeros((len(self._sizes), 3, 3))
scale = np.sqrt(self._sizes) * dpi / 72.0
- self._transforms[:, 0, 0] = scale
- self._transforms[:, 1, 1] = scale
- self._transforms[:, 2, 2] = 1.0
+ if any(np.isnan(scale)):
+ self._transforms = np.empty((0, 3, 3))
+ else:
+ self._transforms[:, 0, 0] = scale
+ self._transforms[:, 1, 1] = scale
+ self._transforms[:, 2, 2] = 1.0
def draw(self, renderer):
self.set_sizes(self._sizes, self.figure.dpi) |
@WeatherGod does this look reasonable? |
Neither look good to me. The important question to ask is why are NaNs happening at all? Somehow, invalid sizes are getting into Collections. This problem seems to have been introduced with the recent changes to collections. Either mplot3d has been interfacing with PolyCollections incorrectly all these years, or somehow, PolyCollections is allowing invalid values (possibly from defaults?) for |
When I looked at the code, the first impression I had was the same as @limtaesu. I mean, in the I don't know much neither python or matplotlib, so maybe the |
Having *args in the argument list is in case a user passes those arguments as positional arguments. size=None in the PolyCollection constructor is a default argument at that position, so it is both positional and keyword, in a sense. The same is true for the closed=True argument. Put it another way, the following calls are all identical:
|
This is really weird... the only way for that particular code path to be executed is if |
Ah-ha! I think I found the source of the problem. Looks like the refactor of the tri* family of functions didn't properly On Thu, Feb 27, 2014 at 4:34 PM, sohakes notifications@github.com wrote:
|
Now, what is probably a more interesting question is why Travis did not catch this. mplot3d has image tests now, and the baseline images are correct. |
Make sure that the tests are white listed in tests.py |
Ah, that would explain that. PR is forthcoming |
This 3d example from the gallery runs fine in 1.3.1, but on master it produces a warning and a completely broken plot:
Confirmed on linux by me and OSX by @ellisonbg.
The text was updated successfully, but these errors were encountered: