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
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 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
[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] 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 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
Re: [Numpy-discussion] Testsuite fails with Python 2.7.3rc1 and 3.2.3rc1 (Debian)
Hi Ralf sorry for the late reply. On Tue, Mar 27, 2012 at 22:29, Ralf Gommers wrote: > > > On Wed, Mar 21, 2012 at 12:28 AM, Sandro Tosi wrote: >> >> Hello, >> I've reported http://projects.scipy.org/numpy/ticket/2085 and Ralf >> asked for bringing that up here: is anyone able to replicate the >> problem described in that ticket? >> >> The debian bug tracking the problem is: >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664672 > > > We do have an Ubuntu buildbot that runs fine with 2.7.2 (see > buildbot.scipy.org). ubuntu python and build stack tends to be different than Debian ones, so they are not exactly comparable. > Is that failure seen on unusual hardware or with a > specific compiler only? well, I don't think so. You can check all our archs build log at https://buildd.debian.org/status/package.php?p=python-numpy&suite=experimental but I saw that on my laptop (amd64) an on those logs too. There you can find all the references to the versions of the tools used for the build. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
