Repository navigation
Remove a copy in pcolormesh. - #6677
tacaswell merged 1 commit into
Conversation
Sorry, something went wrong.
This slightly increases the size of the maximum pcolormesh before
hitting a MemoryError. Test with
N = 6000; x, y = mgrid[:N, :N]; z = sin(x + y); pcolormesh(x, y, z)
The patch raises the maximum N to ~8000 on my system (depending on the
load).
OTOH, this probably(?) makes pcolormesh sensitive to later changes in
the input array.
|
At least when this is instantiated via pcolormesh, which I suspect is almost always the case, the coordinates array is generated within pcolormesh, so there is no danger--no need to copy it. |
Sorry, something went wrong.
|
On coordinates or on the data as well? |
Sorry, something went wrong.
|
Yes, it seems to me that double precision is overkill for coordinates and for data, in almost all plotting situations. The question then is whether it is worth the trouble--and if so, when--to convert to single precision. |
Sorry, something went wrong.
|
Merging this as it makes things better. There are still open questions about only using 32 bits (probably should do something like we did in imshow/colormappable to handle float128). Which probably needs means that we need to pull that into cbook. |
Sorry, something went wrong.
This slightly increases the size of the maximum pcolormesh before
hitting a MemoryError. Test with
The patch raises the maximum N to ~8000 on my system (depending on the
load).
OTOH, this probably(?) makes pcolormesh sensitive to later changes in
the input array.
Thoughts?