When I create camp object and call on torch.tensor, it output result with first element be all 0. But if I call tensor.numpy() explicity, everything went well. I do not know this is a problem of matplotlib or problem of pytorch.
Presumably PyTorch objects are not interchangeable with floats. We are not going to start accepting PyTorch objects to all our function calls, so I'm going to close this.
Actually, lets reconsider this. I don't want to install PyTorch, but does np.asarray(X) work on a PyTorch object? We could consider adding this at the beginning of the colormap call to try and catch more types...
Thanks @jklymak , np.asarray(X) works on a PyTorch object.
I understand matplotlib dose not have to accept all kinds of objects. I just wondering why torch.tensor object meet this bug. Note that only first element of the tensor are all 0, no matter the shape is. This is quite annoying for some people like me has bad habbit that is too lazy to explicity transfrom the data type... (cus torch tensor object is compatible with nearly all numpy function..). Anyway, I've learned the lesson that I‘d best always explicitly deal with the right data type.
Maybe the np.isnan(torch_array) is the issue? That returns a uint8 dtype, whereas torch_array.isnan() returns bools. So I wonder if some indexing is going on because the lookup array is not bool, but uint8.
We are expecting mask_bad to be an array of bools which goes through numpy's fancy bool slicing and setting only the elements identified. Instead is doing the numpy's fancy index based slicing and getting a view of the first slice (which) we are then setting to the bad value. I think we can either do what @jklymak suggests and move the casting to numpy earlier or add
Activity
jklymak commented on May 25, 2022
Presumably PyTorch objects are not interchangeable with floats. We are not going to start accepting PyTorch objects to all our function calls, so I'm going to close this.
jklymak commented on May 25, 2022
Actually, lets reconsider this. I don't want to install PyTorch, but does np.asarray(X) work on a PyTorch object? We could consider adding this at the beginning of the colormap call to try and catch more types...
yugeng-tju commented on May 25, 2022
Thanks @jklymak , np.asarray(X) works on a PyTorch object.
I understand matplotlib dose not have to accept all kinds of objects. I just wondering why torch.tensor object meet this bug. Note that only first element of the tensor are all 0, no matter the shape is. This is quite annoying for some people like me has bad habbit that is too lazy to explicity transfrom the data type... (cus torch tensor object is compatible with nearly all numpy function..). Anyway, I've learned the lesson that I‘d best always explicitly deal with the right data type.
greglucas commented on May 25, 2022
We do force to array very early on already.
matplotlib/lib/matplotlib/colors.py
Lines 710 to 711 in e49d6b6
Maybe the np.isnan(torch_array) is the issue? That returns a uint8 dtype, whereas torch_array.isnan() returns bools. So I wonder if some indexing is going on because the lookup array is not bool, but uint8.
jklymak commented on May 25, 2022
If np.asarray(X) doesn't destroy masked arrays, then I guess we should do mask_bad after this.
tacaswell commented on May 25, 2022
The problem is
matplotlib/lib/matplotlib/colors.py
Line 729 in e49d6b6
We are expecting mask_bad to be an array of bools which goes through numpy's fancy bool slicing and setting only the elements identified. Instead is doing the numpy's fancy index based slicing and getting a view of the first slice (which) we are then setting to the bad value. I think we can either do what @jklymak suggests and move the casting to numpy earlier or add
after L710 to ensure that we really have bools.
QuLogic commented on May 25, 2022
So that's a bug in pytorch, isn't it? It seems like we can work around it, but it's definitely their problem?
oscargus commented on May 27, 2022
It should be possible to replace isnan(X) with X != X which also would solve issues with e.g. dtype=object inputs.
Fix evaluating colormaps on non-numpy arrays
Fix evaluating colormaps on non-numpy arrays
Fix evaluating colormaps on non-numpy arrays
Fix evaluating colormaps on non-numpy arrays