On Fri, Oct 29, 2010 at 12:25 PM, Nikolaus Rath <nikol...@rath.org> wrote:
> Benjamin Root <ben.root-grryuj3d...@public.gmane.org> 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?
>
>
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
------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
