surf() confuses x and y

[GoogleCodeExporter]

surf(), and therefore grid(), confuses the x and y coordinates when converting 
from indices of z to vertex coordinates.  This isn't a problem when the ranges 
are identical, but if they differ, the results are ... interesting.  If z is 
square, the surface will be placed in the wrong place.  If not, the resultant 
mesh will be very confused.

The attached script creates 100 random points on the unit square, sloping 
upwards with x, and then uses griddata to make a surface that should go through 
or near these points.  It takes four arguments: the number of points in the x 
and y directions and the offsets in the x and y directions.  It plots both the 
points and the surface that should go through them.  For arguments not of the 
form (n n 0 0), you can observe problems.

As a tag-along issue: surf() should accept x and y coordinates with the same 
shape as z, in addition to 1D arrays.  Right now, it tries to accept these 
arrays if they are changed to be long 1D arrays, but it screws up the 
calculation of the number of vertices.

Original issue reported on code.google.com by rschr...@gmail.com on 28 Sep 2012 at 1:24

Attachments:

• surftest.py

[GoogleCodeExporter]

I have a proposed fix over in a clone: 
http://code.google.com/r/rschroll-surf/source/list?name=surf

I haven't pushed this to the trunk because this will produce some slight 
changes to the behavior of surf() and grid():
- They no longer accept a C that is the right size but the the wrong shape.
- X and Y must be numpy arrays; lists were previously accepted.
- X and Y may now be 2D arrays of the same shape as Z.  This is new behavior, 
mimicking matplotlib and Matlab.
I think it's worth these changes, but I wanted to check with you before pushing 
them for real.  If you're worried about the second point, I can add a coercion 
to Numpy arrays.

Original comment by rschr...@gmail.com on 28 Sep 2012 at 3:14

• Added labels: Type-Review
• Removed labels: Type-Defect

[GoogleCodeExporter]

Thanks for taking this on Robert. Pleas commit the fix.

I'm all for compatibility with MPL and Matlab.

Yes, I think it would be nice if we check the inputs and convert them if 
necessary, not only for backward compatibility, but also because it makes it 
very easy to create a small surface.

> They no longer accept a C that is the right size but the the wrong shape.

Was this a feature or a bug? I assume the latter since you use the word 
"wrong". I suppose the chance that this breaks someones code is slim...

Original comment by almar.klein@gmail.com on 28 Sep 2012 at 9:24

[GoogleCodeExporter]

>> They no longer accept a C that is the right size but the the wrong shape.
> 
> Was this a feature or a bug? I assume the latter since you use the word 
> "wrong". I suppose the chance that this breaks someones code is slim...

I would rate it as a misfeature.  I expect most people would stumble into it by 
accident, and then be confused as to why it was doing what it was doing.  If 
someone was using it on purpose, they can just use reshape explicitly now.

Original comment by rschr...@gmail.com on 28 Sep 2012 at 1:41

• Changed state: Fixed