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.
---- Eric Firing <efiring@...> wrote:
> gruben@... 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')
> 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.
> > thanks again,
> > Gary
> > ---- Eric Firing <efiring@...> 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