Thanks again Eric,
Your examples are exactly what I was after.
My colleague was hypothesizing that there's probably a less-than instead of a
less-than-or-equal somewhere, if it is a bug.
regards,
Gary
---- Eric Firing <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Thanks Eric.
> >
> > However, when I specify the same number of levels as suggested, contourf
> > divides this example into three regions, with a diagonal 'stripe' instead
> > of a clean boundary, so I guess I'm asking whether it's possible to trick
> > contourf into generating a single boundary between the two regions such
> > that it matches that found by contour?
> >
> Now I see the problem; this is something of a corner case, but it may be
> pointing to a bug.
>
> Where do you really want the line to fall?
>
> Do you need to specify the number of contours instead of specifying the
> actual levels (boundaries)? Are you actually dealing with zeros and
> ones as in the example? If so, you probably want
>
> contour(a, [0.5])
> contourf(a, [-1, 0.5, 2], colors=('w', 'k'), extend='neither')
>
> or
>
> contourf(a, [0.5, 2], colors=('k',), extend='neither')
> In this case you are saying "color everything between 0.5 and 2, and
> nothing else".
>
> Specifying one contour instead of giving the levels is yielding 0.6;
> this is a consequence of using the MaxNLocator by default to auto-select
> the levels.
>
> > For the moment, a suitable workaround seems to be to do
> >
> > contourf(a,1,colors=('w','k'))
> >
> > where the background colour is white. This generates what I'm after.
> >
> > I notice also that linewidths is mentioned in the docstring under
> > Obsolete:, but it seems to do nothing, so it should probably be removed
> > from the docstring.
>
> I will fix the docstring. Thanks.
>
> Eric
> >
> > thanks again,
> > Gary
> >
> > ---- Eric Firing <[EMAIL PROTECTED]> wrote:
> >> Gary Ruben wrote:
> >>> I'm notice that contourf behaves differently to contour by default in
> >>> where it decides to position contours. For example, using pylab, if you
> >>> try
> >>>
> >>> a=tri(10)
> >>> contourf(a,0)
> >>> contour(a,1)
> >>>
> >>> I'd have expected the contours to line up, but they don't. Is there a
> >>> way to get contourf to place its contours at the same position as contour?
> >> Specify the same number of levels:
> >>
> >> contourf(a,1)
> >> contour(a,1)
> >>
> >>
> >> That takes care of this simple case. There are other cases, however,
> >> where contour and contourf simply don't agree; contouring is ambiguous,
> >> and only part of the algorithm is shared between contour and contourf.
> >> For well-behaved datasets this is normally not a problem, but it becomes
> >> obvious if you contour a random array.
> >>
> >> Eric
> >
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
