Re: [Numpy-discussion] Allow == and != to raise errors
Python itself doesn't raise an exception in such cases : (3,4) != (2, 3, 4) True (3,4) == (2, 3, 4) False Should numpy behave differently ? Bruno. 2013/7/12 Frédéric Bastien no...@nouiz.org I also don't like that idea, but I'm not able to come to a good reasoning like Benjamin. I don't see advantage to this change and the reason isn't good enough to justify breaking the interface I think. But I don't think we rely on this, so if the change goes in, it probably won't break stuff or they will be easily seen and repared. Fred On Fri, Jul 12, 2013 at 9:13 AM, Benjamin Root ben.r...@ou.edu wrote: I can see where you are getting at, but I would have to disagree. First of all, when a comparison between two mis-shaped arrays occur, you get back a bone fide python boolean, not a numpy array of bools. So if any action was taken on the result of such a comparison assumed that the result was some sort of an array, it would fail (yes, this does make it a bit difficult to trace back the source of the problem, but not impossible). Second, no semantics are broken with this. Are the arrays equal or not? If they weren't broadcastible, then returning False for == and True for != makes perfect sense to me. At least, that is my take on it. Cheers! Ben Root On Fri, Jul 12, 2013 at 8:38 AM, Sebastian Berg sebast...@sipsolutions.net wrote: Hey, the array comparisons == and != never raise errors but instead simply return False for invalid comparisons. The main example are arrays of non-matching dimensions, and object arrays with invalid element-wise comparisons: In [1]: np.array([1,2,3]) == np.array([1,2]) Out[1]: False In [2]: np.array([1, np.array([2, 3])], dtype=object) == [1, 2] Out[2]: False This seems wrong to me, and I am sure not just me. I doubt any large projects makes use of such comparisons and assume that most would prefer the shape mismatch to raise an error, so I would like to change it. But I am a bit unsure especially about smaller projects. So to keep the transition a bit safer could imagine implementing a FutureWarning for these cases (and that would at least notify new users that what they are doing doesn't seem like the right thing). So the question is: Is such a change safe enough, or is there some good reason for the current behavior that I am missing? Regards, Sebastian (There may be other issues with structured types that would continue returning False I think, because neither side knows how to compare) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Allow == and != to raise errors
Thank-you for your explanations. So, if the operator == applied to np.arrays is a shorthand for the ufunc np.equal, it should definitly behave exactly as np.equal(), and raise an error. One side question about style : In case you would like to protect a x == y test by a try/except clause, wouldn't it feel more natural to write np.equal(x, y) ? Bruno. 2013/7/15 Nathaniel Smith n...@pobox.com On Mon, Jul 15, 2013 at 2:09 PM, bruno Piguet bruno.pig...@gmail.com wrote: Python itself doesn't raise an exception in such cases : (3,4) != (2, 3, 4) True (3,4) == (2, 3, 4) False Should numpy behave differently ? The numpy equivalent to Python's scalar == is called array_equal, and that does indeed behave the same: In [5]: np.array_equal([3, 4], [2, 3, 4]) Out[5]: False But in numpy, the name == is shorthand for the ufunc np.equal, which raises an error: In [8]: np.equal([3, 4], [2, 3, 4]) ValueError: operands could not be broadcast together with shapes (2) (3) -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Allow == and != to raise errors
2013/7/15 Frédéric Bastien no...@nouiz.org Just a question, should == behave like a ufunc or like python == for tuple? That's what I was also wondering. I see the advantage of consistency for newcomers. I'm not experienced enough to see if this is a problem for numerical practitionners Maybe they wouldn't even imagine that == applied to arrays could do anything else than element-wise comparison ? Explicit is better than implicit : to me, np.equal(x, y) is more explicit than x == y. But Beautiful is better than ugly. Is np.equal(x, y) ugly ? Bruno. I think that all ndarray comparision (==, !=, =, ...) should behave the same. If they don't (like it was said), making them consistent is good. What is the minimal change to have them behave the same? From my understanding, it is your proposal to change == and != to behave like real ufunc. But I'm not sure if the minimal change is the best, for new user, what they will expect more? The ufunc of the python behavior? Anyway, I see the advantage to simplify the interface to something more consistent. Anyway, if we make all comparison behave like ufunc, there is array_equal as said to have the python behavior of ==, is it useful to have equivalent function the other comparison? Do they already exist. thanks Fred On Mon, Jul 15, 2013 at 10:20 AM, Nathaniel Smith n...@pobox.com wrote: On Mon, Jul 15, 2013 at 2:09 PM, bruno Piguet bruno.pig...@gmail.com wrote: Python itself doesn't raise an exception in such cases : (3,4) != (2, 3, 4) True (3,4) == (2, 3, 4) False Should numpy behave differently ? The numpy equivalent to Python's scalar == is called array_equal, and that does indeed behave the same: In [5]: np.array_equal([3, 4], [2, 3, 4]) Out[5]: False But in numpy, the name == is shorthand for the ufunc np.equal, which raises an error: In [8]: np.equal([3, 4], [2, 3, 4]) ValueError: operands could not be broadcast together with shapes (2) (3) -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Could numpy.fromfile() work with gzip-compressed files ?
Hi all, I've got some code which basically does : f = open (path, 'rb') header = f.read (some_length) data = np.fromfile (f, dtype= some_type, count=-1) In order to process compressed files, I switched the open sequence to : if (plain): f = open (path, 'rb') else: f = gzip.open (path, 'rb') Then, the header reading is OK, since the gzip.file class has a read method : hdr = f.read (some_length) But I've got problems with np.fromfile, which says : IOError: first argument must be an open file I guess that fromfile() uses methods other than file.read(), while GzipFile does not simulates all the methods of a file object (readinto() and truncate() are listed the doc), so making fromfile() work with compressed file may not be straightforward. I had a try at StringIO() : data = np.fromfile (StringIO.StringIO(f.read()), dtype= some_type, count=-1) but it doesn't work better. So, I've got two questions : - Could numpy.fromfile() work with gzip-compressed files, as some other file functions do ? - I'm thinking of using something like np.array(f.read(), dtype=some_type). Any better solution ? With such a simple solution, maybe my error was to try to use fromfile() at the beginning ? Bruno. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Could numpy.fromfile() work with gzip-compressed files ?
2010/7/26 bruno Piguet bruno.pig...@gmail.com - I'm thinking of using something like np.array(f.read(), dtype=some_type). Actually : data=np.fromstring(f.read(), dtype=some_type, count=-1) Bruno. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Howto vectorise a dot product ?
2009/6/9 Charles R Harris charlesr.har...@gmail.com Well, in this case you can use complex multiplication and either work with just the x,y components or use two complex components, i.e., [x + 1j*y, z]. In the first case you can then do the rotation as V*exp(1j*phi). In the real case, it's a real 3-axes rotation, where M = dot (M1(psi), dot (M2(theta), M3(phi))). The decomposition in 2D-rotations and the use of complex operation is possible, but the matrix notation is more concise. If you want more general rotations, a ufunc for quaternions would do the trick. You mean something like Christoph Gohlke's transformations.py program ? I'll also chek if I really ned vectorisation. After all, Numpy slicing is known to be efficient. I'll do some timing with the pseudo-vectorial function : def rotat_vect(phi, theta, psi, V): for i in xrange(len(phi)): rotat_scal(phi[i,:], theta[i,:], psi[i,:], V[i,:]) Bruno. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Howto vectorise a dot product ?
Dear all, Can someone point me to a doc on dot product vectorisation ? Here is what I try to do : I've got a rotation function which looks like : def rotat_scal(phi, V): s = math.sin(phi) c = math.cos(phi) M = np.zeros((3, 3)) M[2, 2] = M[1, 1] = c M[1, 2] = -s M[2, 1] = s M[0, 0] = 1 return np.dot(M, V) (where phi is a scalar, and V and array of size (3,1)) Now, I want to apply it to a time series of phi and V, in a vectorised way. So, I tried to simply add a first dimension : Phi is now of size(n) and V (n, 3). (I really whish to have this shape, for direct correspondance to file). The corresponding function looks like : def rotat_vect(phi, V): s = np.sin(phi) c = np.cos(phi) M = np.zeros((len(phi), 3, 3)) M[:, 2, 2] = M[:, 1, 1] = c M[:, 1, 2] = -s M[:, 2, 1] = s M[:, 0, 0] = np.ones (len(phi)) return np.dot(M, V) It was not really a surprise to see that it didn't work : [...] return np.dot(M, V) ValueError: objects are not aligned Any hint ? Bruno. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] loadtxt example problem ?
Hello, I'm new to numpy, and considering using loadtxt() to read a data file. As a starter, I tried the example of the doc page ( http://docs.scipy.org/doc/numpy/reference/generated/numpy.loadtxt.html) : from StringIO import StringIO # StringIO behaves like a file object c = StringIO(0 1\n2 3) np.loadtxt(c) I didn't get the expectd answer, but : Traceback (moste recent call last): File(stdin), line 1, in module File C:\Python25\lib\sire-packages\numpy\core\numeric.py, line 725, in loadtxt X = array(X, dtype) ValueError: setting an array element with a sequence. I'm using verison 1.0.4 of numpy). I got the same problem on a Ms-Windows and a Linux Machine. I could run the example by adding a \n at the end of c : c = StringIO(0 1\n2 3\n) Is it the normal and expected behaviour ? Bruno. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
