Re: [Matplotlib-users] contourf question

2007-10-05 Thread Eric Firing
[EMAIL PROTECTED] wrote:
 Thanks again Eric,
 
 Your examples are exactly what I was after.

Glad to hear it!

 My colleague was hypothesizing that there's probably a less-than instead of a 
 less-than-or-equal somewhere, if it is a bug.
 

That was part of it, but it was a little more subtle. I have tweaked the 
automatic level generation routine so that it now does what one might 
reasonably expect.  Specifying levels explicitly is still better when 
you can do it; the number-of-levels method is really only for quick and 
dirty exploratory work, when you don't care too much which levels are 
chosen and you don't know in advance what the data interval will be.

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


Re: [Matplotlib-users] contourf question

2007-10-04 Thread [EMAIL PROTECTED]
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?

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.

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


Re: [Matplotlib-users] contourf question

2007-10-04 Thread Eric Firing
[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


Re: [Matplotlib-users] contourf question

2007-10-04 Thread [EMAIL PROTECTED]
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