Benjamin Root <ben.root-GrrYUJ3DTa8@...1455...> writes:
However, it seems to me that this is quite a serious bug. The contour
documentation on
http://matplotlib.sourceforge.net/api/axes_api.html#matplotlib.axes.Axes.contour
does not mention this requirement, and obviously the contour method
itself does not even bother to check if its arguments are monotonically
increasing. Instead, it just *silently* produces garbage that in some
cases even looks like plausible data(!).
Am I missing something here? Otherwise I'll report this on the bug
tracker. I think this should be documented and contour() should check
its input and raise a ValueError if it's not monotonic.
You are right, the documentation is seriously lacking and woefully
out-of-date. It still claims that it can not handle internal regions
correctly with masked arrays (I am pretty sure that is fixed) and it says
nothing of any characteristics of X and Y.
I see. I added this issue to the bug tracker so that it doesn't get
forgotten.
I don't know if there are any strict requirement on monotonicity for X and
Y, or if there are any cases where the plot is still valid even if that
property is violated. If it is a requirement, then I agree that there
should be a check.
How can it not be a requirement if the output is wrong in some cases? It
does not matter if there are also cases where it works - you would never
be able to trust any plot you generate.
P.S. - I find that in many cases, contourf() is the wrong function to use
for such plots, and find pcolor() (or one of its variants) to be better
suited. Don't know what is better for you in your case, but it might be
something to investigate.
Thanks for the hint, looks interesting. I looked at the documentation, but I don't really
understand the difference between pcolor and pcolormesh. Could you
elaborate on that?
Best,
-Nikolaus
···
--
»Time flies like an arrow, fruit flies like a Banana.«
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
The practical difference is how the graphs are rendered. pcolormesh is usually faster, but (I think) it has some restrictions on the specification of X and Y. pcolor() will just about always work as it accepts the most general use-cases, but this does cause it to be slower than pcolormesh() in many cases. Lastly, on some backends, there might be noticeable differences in between the output because they are rendered differently, but this is pretty rare.
And besides the class of pcolor functions, if you ever want just the fastest speed possible, one could get away with using imshow(), but that has a lot of restrictions on the domain handling.
The other points you raised I will leave to others who have been with this project longer than me to weigh in.
Ben Root
···
On Fri, Oct 29, 2010 at 12:25 PM, Nikolaus Rath <Nikolaus@…3105…72…> wrote:
Benjamin Root <ben.root-GrrYUJ3DTa8@…1455…> writes:
However, it seems to me that this is quite a serious bug. The contour
documentation on
http://matplotlib.sourceforge.net/api/axes_api.html#matplotlib.axes.Axes.contour
does not mention this requirement, and obviously the contour method
itself does not even bother to check if its arguments are monotonically
increasing. Instead, it just silently produces garbage that in some
cases even looks like plausible data(!).
Am I missing something here? Otherwise I’ll report this on the bug
tracker. I think this should be documented and contour() should check
its input and raise a ValueError if it’s not monotonic.
You are right, the documentation is seriously lacking and woefully
out-of-date. It still claims that it can not handle internal regions
correctly with masked arrays (I am pretty sure that is fixed) and it says
nothing of any characteristics of X and Y.
I see. I added this issue to the bug tracker so that it doesn’t get
forgotten.
I don’t know if there are any strict requirement on monotonicity for X and
Y, or if there are any cases where the plot is still valid even if that
property is violated. If it is a requirement, then I agree that there
should be a check.
How can it not be a requirement if the output is wrong in some cases? It
does not matter if there are also cases where it works - you would never
be able to trust any plot you generate.
P.S. - I find that in many cases, contourf() is the wrong function to use
for such plots, and find pcolor() (or one of its variants) to be better
suited. Don’t know what is better for you in your case, but it might be
something to investigate.
Thanks for the hint, looks interesting. I looked at the documentation, but I don’t really
understand the difference between pcolor and pcolormesh. Could you
elaborate on that?