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: hetland@...345..., 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: hetland@...345..., w: http://pong.tamu.edu
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
···
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!
Rob Hetland, Assistant Professor
Dept of Oceanography, Texas A&M University
p: 979-458-0096, f: 979-845-6331
e: hetland@…345…, w: http://pong.tamu.edu
Robert Hetland 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,
Sounds to me like something you might want to put on one of the wikis.
I have tended not to think of the x,y order in terms of storage order; I just naturally think of coordinates as x,y,z, and indices as i,j,k, and so it seems natural for x to correspond to i, etc. This is math notation, not computer science. I suspect this is the same thing that trips up other people encountering the x-is-column-number convention in pcolor, hence the need for documentation, and possibly a friendly option for specifying the intended order. I also suspect that the reason Matlab uses its present convention has nothing to do with storage order--Matlab started out in Fortran, and uses Fortran conventions--but rather with the way a matrix is written, with the second index increasing across the page from left to right.
Eric
···
On May 15, 2006, at 2:32 PM, Eric Firing wrote: