matplotlib-devel Mailing List for matplotlib

On May 15, 2006, at 2:32 PM, Eric Firing wrote:

> there is a lengthy chunk of docstring explaining that if you expect  
> x,y to be row,column, you are wrong!

I think that most people who have used matlab, netcdf, etc. expect  
things to be 'backwards,' like C instead 'forwards' like fortran.  I  
always use a convention like var[time, z, y, x] which seems to work  
nicely with things like sum and mean (which operate on the first axis  
by default for time integrals and averages), with broadcast arrays  
(for multiplying by dx and dy, which for me are typically only  
functions of x and y), and, of course, with pcolor!

Should this way of thinking be put into an example?  Into the MPL  
documentation?  Or, just let people figure it out naturally?

-Rob

-----
Rob Hetland, Assistant Professor
Dept of Oceanography, Texas A&M University
p: 979-458-0096, f: 979-845-6331
e: he...@ta..., w: http://pong.tamu.edu

Rob,

I agree, what you propose is logical and desirable.  I think the 
implementation would be essentially a matter of using meshgrid 
internally when needed, or a piece of meshgrid for your single-vector 
case.  I don't think there will be any more efficient way to do it at 
present.  In the future, when we have only numpy to deal with, and when 
we are doing a grand unification of pcolor-like plotting methods, then 
perhaps things can be arranged so that even internally the x and y don't 
have to be expanded out.

In the meantime, I can try to make a simple version of this, while 
factoring common functionality out of pcolor and pcolormesh.

A related idea that I might want to try at the same time is a kwarg to 
control the orientation, so that x,y can correspond to row, column; as 
it is, there is a lengthy chunk of docstring explaining that if you 
expect x,y to be row,column, you are wrong!

John,

Can we simply remove pcolor_classic now?  Or are there circumstances 
under which it is still needed?

Eric

Robert Hetland wrote:
> 
> 
> I would like to propose expanding the inputs of pcolor to take  
> vectors.  Often, you have x and y independent (seperable), and you  
> don't want to go on constructing an x array of redundant values.   
> Actually, in NumPy it is not straightforward to do this with resize  if 
> your variable is in the first dimension like time.  This is  because 
> NumPy makes heavy use of array broadcasting, so that you  don't need to 
> drag around all that redundant data.
> 
> I realize that there is meshgrid, but I only use it for plotting  
> (because of array broadcasting), and only with two vectors (see the  
> second example below).  I think MPL would benifit from following the  
> spirit of array broadcasting, and make it such that:
> 
> x = arange(10)
> y = arange(30)
> z = rand(30,10)
> pcolor (x, y, z)
> 
> will work as expected.  Perhaps, we could require a NewAxis in the  
> right places, but it would also make sense without. We could also  
> consider the case of just one vector.  Consider
> 
> x,y = meshgrid(arange(10), arange(30))
> y = y + random.normal(size=y.shape)
> z = random.random(y.shape)
> pcolor (x, y, z)
> # but x is still essentially just arange(10), so it would be nice if  
> this worked, too.
> pcolor(arange(10), y, z)
> 
> What do you all think?
> 
> -Rob.
> 
> -----
> Rob Hetland, Assistant Professor
> Dept of Oceanography, Texas A&M University
> p: 979-458-0096, f: 979-845-6331
> e: he...@ta..., w: http://pong.tamu.edu
> 

I would like to propose expanding the inputs of pcolor to take  
vectors.  Often, you have x and y independent (seperable), and you  
don't want to go on constructing an x array of redundant values.   
Actually, in NumPy it is not straightforward to do this with resize  
if your variable is in the first dimension like time.  This is  
because NumPy makes heavy use of array broadcasting, so that you  
don't need to drag around all that redundant data.

I realize that there is meshgrid, but I only use it for plotting  
(because of array broadcasting), and only with two vectors (see the  
second example below).  I think MPL would benifit from following the  
spirit of array broadcasting, and make it such that:

x = arange(10)
y = arange(30)
z = rand(30,10)
pcolor (x, y, z)

will work as expected.  Perhaps, we could require a NewAxis in the  
right places, but it would also make sense without. We could also  
consider the case of just one vector.  Consider

x,y = meshgrid(arange(10), arange(30))
y = y + random.normal(size=y.shape)
z = random.random(y.shape)
pcolor (x, y, z)
# but x is still essentially just arange(10), so it would be nice if  
this worked, too.
pcolor(arange(10), y, z)

What do you all think?

-Rob.

-----
Rob Hetland, Assistant Professor
Dept of Oceanography, Texas A&M University
p: 979-458-0096, f: 979-845-6331
e: he...@ta..., w: http://pong.tamu.edu

Eric Firing wrote:
> Jeff,
>
>
>> Playing around with it a bit with I found that using a format string 
>> in the format keyword causes an exception:
> ...
>>
>> Changing 'FormatStringFormatter' to 'FormatStrFormatter' in 
>> colorbar.py seems to fix it.
>
> Fixed, thanks.  I thought I had tested that, but...
>
>>
>> Also, the docs suggest that the ticks keyword can be a list, but if I 
>> use for example
>>
>> colorbar(ticks=[-1.0,0,1.0])
>>
>> I don't get what I expect.  In fact, it seems to use the default tick 
>> locations no matter what assign to ticks (a list or a ticker object, 
>> such as MultipleLocator(4)).  Am I mis-interpreting the docstrings?
>
> It was working as you expected for images but not for contours.  Now 
> that is fixed also.
>
> Eric
Excellent, thanks Eric!

-Jeff

-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

Jeff,


> Playing around with it a bit with I found that using a format string in 
> the format keyword causes an exception:
...
> 
> Changing 'FormatStringFormatter' to 'FormatStrFormatter' in colorbar.py 
> seems to fix it.

Fixed, thanks.  I thought I had tested that, but...

> 
> Also, the docs suggest that the ticks keyword can be a list, but if I 
> use for example
> 
> colorbar(ticks=[-1.0,0,1.0])
> 
> I don't get what I expect.  In fact, it seems to use the default tick 
> locations no matter what assign to ticks (a list or a ticker object, 
> such as MultipleLocator(4)).  Am I mis-interpreting the docstrings?

It was working as you expected for images but not for contours.  Now 
that is fixed also.

Eric

Eric Firing wrote:
> I made a few modifications to the new colorbar, so part of my previous 
> message no longer applies.  If the new colorbar finds kwargs from 
> colorbar_classic, it issues a warning and then proceeds to call 
> colorbar_classic.  This should keep most old code working as before.
>
> Eric
>

Eric:  Thanks for all your hard work!  Looks like it should make 
colorbar much more flexible (and useful). 

Playing around with it a bit with I found that using a format string in 
the format keyword causes an exception:

Traceback (most recent call last):
  File "colorbar_test.py", line 10, in ?
    colorbar(format='%5.2f')
  File "/Users/jsw/lib/python/matplotlib/pylab.py", line 341, in colorbar
    ret = gcf().colorbar(mappable, cax = cax, **kw)
  File "/Users/jsw/lib/python/matplotlib/figure.py", line 676, in colorbar
    cb = cbar.Colorbar(cax, mappable, **kw)
  File "/Users/jsw/lib/python/matplotlib/colorbar.py", line 419, in __init__
    ColorbarBase.__init__(self, ax, **kw)
  File "/Users/jsw/lib/python/matplotlib/colorbar.py", line 125, in __init__
    self.formatter = ticker.FormatStringFormatter(format)
AttributeError: 'module' object has no attribute 'FormatStringFormatter


Changing 'FormatStringFormatter' to 'FormatStrFormatter' in colorbar.py 
seems to fix it.

Also, the docs suggest that the ticks keyword can be a list, but if I 
use for example

colorbar(ticks=[-1.0,0,1.0])

I don't get what I expect.  In fact, it seems to use the default tick 
locations no matter what assign to ticks (a list or a ticker object, 
such as MultipleLocator(4)).  Am I mis-interpreting the docstrings?

-Jeff


-- 
Jeffrey S. Whitaker         Phone : (303)497-6313
NOAA/OAR/CDC  R/PSD1        FAX   : (303)497-6449
325 Broadway                Boulder, CO, USA 80305-3328

I made a few modifications to the new colorbar, so part of my previous 
message no longer applies.  If the new colorbar finds kwargs from 
colorbar_classic, it issues a warning and then proceeds to call 
colorbar_classic.  This should keep most old code working as before.

Eric