[Numpy-discussion] reshape and ravel methods of arrays now return views or raise error

[Zachary Pincus]

Let me give a more concrete example, pulled from some code I was  
actually using.

The code is obviously a bit flawed, but it worked fine with numpy up  
until today. Now it breaks when a and b aren't both c-strided:
def distance_squared(a, b):
     return numpy.sum( (a.ravel() - b.ravel())**2 )

It appears that to be safe, a function like this must be rewritten as:
def distance_squared(a, b):
     return numpy.sum( (numpy.ravel(a) - numpy.ravel(b))**2 )

At the very least, it seems surprising (to a novice especially, but  
to me too, and I don't consider myself a total newb at this) that for  
something as simple as this, that the ravel method might not work in  
some cases, especially since one of the exciting new features of  
numpy is (finally!) having useful array methods (makes life in  
ipython with tab completion much easier).

Zach

PS. I know that the "proper" solution would look more like the below.  
I guess the question is how tolerant should numpy be of code that  
deviates from "proper".
def distance_squared(a, b):
   return ((a - b)**2).sum()


On Mar 28, 2006, at 5:35 PM, Zachary Pincus wrote:

> Uh oh,
>
> Just updated to new numpy so that dot() wouldn't be broken. What  
> fun to play with the new order/ravel/reshape stuff.
>
> Unfortunately, the ravel/reshape methods seem to not be quite  
> worked out properly yet. Basically (and as expected) the ravel  
> method doesn't work anymore on fortran-strided arrays. But since  
> fortran-strided arrays happen *all-the-time* (e.g. after a  
> transpose operation), things get confusing fast.
>
> In fact, absolutely no reshape operation (other than the identity  
> reshape) will work on fortran-strided arrays (see below). Also, the  
> errors could be more helpful, and anyway ravel shouldn't fail with  
> an error about reshape fortran-strided.
>
> This can't be the optimal situation, since it makes the method  
> interface next-to-useless (because exceptions might be thrown at  
> any moment) unless a *lot* of care is taken to properly sanitize  
> the arrays that are used (in which case any speed gains are  
> probably lost).
>
> In [1]: import numpy
> In [2]: numpy.__version__
> Out[2]: '0.9.7.2291'
> In [3]: a = numpy.array([[1,2],[3,4],[5,6]])
> In [4]: b = a.transpose()
> In [5]: a.ravel()
> Out[5]: array([1, 2, 3, 4, 5, 6])
> In [6]: b.ravel()
> ValueError: cannot return a view from reshape.
> In [7]: b.shape
> Out[7]: (2, 3)
> In [8]: b.reshape((1,6))
> ValueError: cannot return a view from reshape.
> In [9]: b.reshape((6,1))
> ValueError: cannot return a view from reshape.
> In [10]: b.reshape((3,2))
> ValueError: cannot return a view from reshape.
>
> This state of affairs seems pretty hostile to both advanced users  
> and basic ones. Now I need to go through all of my code and  
> eliminate the use of array methods, since about half of the time  
> I'll be calling things like ravel on arrays that have been  
> transposed. What a waste -- is there something better I can do or  
> something better numpy can do?
>
> At the very least, a strong convention really needs to be  
> established and made clear about what the methods do (never return  
> copies) and what the functions do (sometimes return copies? hardly  
> a strong convention), and when to choose one or the other.
>
> Zach
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the  
> live webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion