[Numpy-discussion] ndarray sub-classing and append function
Hi, I am sub-classing numpy.ndarry for vector array representation. The append function is like this: def append(self, other): self = numpy.append(self, [other], axis=0) Example: vary = VectorArray([v1, v2]) #vary = numpy.append(vary, [v1], axis=0) vary.append(v1) The commented syntax (numpy syntax) is working but vary.append(v1) is not working. Any help? Cheers Prashant___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ndarray sub-classing and append function
It doesn't work because numpy.append(a, ...) doesn't modify the array a in-place: it returns a copy. Then in your append method, doing self = numpy.append(...) won't have any effect: in Python such a syntax means the self local variable will now point to the result of numpy.append, but it won't modify the object that self previously pointed to. I didn't try it, but it should work with def append(self, other): numpy.ndarray.append(self, other) which will call the append method of the parent class numpy.ndarray, modifying self in-place. -=- Olivier Le 31 mars 2012 02:25, Prashant Saxena animator...@yahoo.com a écrit : Hi, I am sub-classing numpy.ndarry for vector array representation. The append function is like this: def append(self, other): self = numpy.append(self, [other], axis=0) Example: vary = VectorArray([v1, v2]) #vary = numpy.append(vary, [v1], axis=0) vary.append(v1) The commented syntax (numpy syntax) is working but vary.append(v1) is not working. Any help? Cheers Prashant ___ 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] Trac configuration tweak
Hi, I moved projects.scipy.org Tracs to run on mod_python (instead of CGI), in order to try to combat the present performance issues. Let's see if this helps with the database is locked problem. Please drop me a message if something stops working. Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] YouTrack testbed
The idea is to allow people to test-out YouTrack for a few weeks and get to know it while we migrate bugs to it. it looks like it is straightforward to export the data out of YouTrack should we eventually decide to use something else. The idea is to host it on an external server (Rackspace or AWS that multiple people are able to admin). So far, I like the keyboard interface and the searchable widget on top.We will continue to work on moving tickets into the system. Please give it a try if you have an interest in the Issue Tracker. Best, -Travis On Mar 30, 2012, at 7:33 PM, Charles R Harris wrote: On Fri, Mar 30, 2012 at 4:08 PM, Maggie Mari maggie.m...@continuum.io wrote: Hello, everyone. I work with Travis at Continuum, and he asked me to setup a YouTrack server that everyone is welcome to play around with. There is a test project currently set up, with some fake tickets. Here is the address: http://ec2-107-21-65-210.compute-1.amazonaws.com:8011/issues It's running on an AWS micro instance, so it might be slow at the moment. Any feedback or comments would be welcome. Looks nice, although it will take a little getting used to. It's hard to tell with these things until you have actually made some use of them. Is it configurable? I was wondering what sort of feedback you were looking for. Who will have access to these issues? Is this going to be hosted at Continuum? Chuck ___ 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] Style for pad implementation in 'pad' namespace or functions under np.lib
1) The use of string constants to identify NumPy processes. It would seem better to use library defined constants (ufuncs?) for better future-proofing, maintenance, etc. I don't see how this would help with future-proofing or maintenance -- can you elaborate? If this were C, I'd agree; using an enum would have a number of benefits: -- easier to work with than strings (== and switch work, no memory management hassles) -- compiler will notice if you accidentally misspell the enum name -- since you always in effect 'import *', getting access to additional constants doesn't require any extra effort But in Python none of these advantages apply, so I find it more convenient to just use strings. Using constants provides for tab-completion and associated help text. The help text can be particularly useful if the choice of constant affects which extra keyword arguments can be specified. And on a minor note, and far more subjectively (time for another bike-shedding reference!), there's the cleanliness of API. (e.g. Strings don't feel a good match. There are an infinite number of strings, but only a small number are valid. There's nothing machine-readable you can interrogate to find valid values.) Under the hood you'll have to use the string to do a lookup, but the constant can *be* the result of the lookup. Why re-invent the wheel when the language gives it to you for free? Note also that we couldn't use ufuncs here, because we're specifying a rather unusual sort of operation -- there is no ufunc for padding with a linear ramp etc. Using mean as the example is misleading in this respect -- it's not really the same as np.mean. 2) Why does only pad use this style of interface? If it's a good idea for pad, perhaps it should be applied more generally? numpy.aggregate(MEAN, ...), numpy.group(MEAN, ...), etc. anyone? The mode=foo interface style is actually used in other places, e.g., np.linalg.qr. My mistake - I misinterpreted the API earlier, so we're talking at cross-purposes. My comment/question isn't really about pad mode, but about numpy more generally. But it still stands - albeit somewhat hypothetically, since it's hard to imagine such a change taking place. Richard ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
