Mailman 3 August 2005 - NumPy-Discussion

Numeric Python EM Project
by Rob 11 Aug '05

11 Aug '05

Hi all, I will be putting this site back up, somewhere, I don't know. It needs to be updated to whatever people think is the best Python numeric type package. I've been out of this for a couple of years. I'm off to buy a second laptop today. Something relatively inexpensive that will just have Windoze on it. This pricey Dell is my *nix laptop. Currently it has OpenBSD only. The motivation of all of this is the dismay of "high tech" EE jobs here in Hillsboro, OR, and a renewed interest in Astrophysics and all of the wonderful philosophic and spiritual questions that naturally come from it. haha. Sincerely, Rob N3FT

1 0

Sourceforge pserver CVS access acting strange -> don't get Numeric3 that way.
by Travis Oliphant 10 Aug '05

10 Aug '05

Anyone contemplating trying out the new scipy.base should not try to use the pserver CVS service from sourceforge for a while. It is not reflecting the current state of the developer CVS tree. I know they recently upgraded developer CVS hardware and perhaps the pserver system is still getting information from the old CVS tree rather than the new developer tree. So, if you get errors on building scipy.base after checking it out from pserver Sourceforge, wait a day or two. I suspect that sourceforge will fix this annoying problem soon. -Travis O.

1 0

Checking out scipy.base (Numeric3)
by Travis Oliphant 10 Aug '05

10 Aug '05

You can check out scipy.base using: cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/numpy login (press Enter when asked for login) cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/numpy co -P /Numeric3\ -Travis /

1 0

scipy.base (Numeric3) ready for alpha use
by Travis Oliphant 10 Aug '05

10 Aug '05

For anybody interested in the development of scipy.base. The repository is in a state that can be tested and played with. I'm sure there are bugs, but I've removed the ones I've found. I'd be interested in help in tracking down others. Over the next few weeks, we will be attempting to build scipy using the new scipy.base. This should also help iron out some problems. Some of the notable features that came out of the ufunc adapting process are 1) reductions can now take place over a type different than the array type. Thus, if B is a byte array you can reduce over a long type to avoid modular arithmetic (overflow). 2) reduceat now takes an axis argument 3) copies are not made of large arrays but a buffering-scheme is used for casting and mis-behaved arrays. 4) the size of buffers used and what is meant by "large array" can be adjusted on a per function / module / global basis by setting the variable UFUNC_BUFSIZE in the local / module / global (builtin) scope 5) how errors in ufuncs are handled can be set and over-ridden on a function / module / global basis through the variable UFUNC_ERRMASK 6) you have another option besides ignore, warn, or raise. You can specify a Python function to call when an error occurs through the variable UFUNC_ERRFUNC (right now all errors go to this same function and a string is based indiciating which error has occurred). I should explain this idea of using variables to set information for the ufuncs. It comes out of an idea that Guido mentioned while Perry, Paul, and I met with him back in March. When he was informed of numarray's stack approach to error handling he questioned that design decision. He wondered if the error handling could not be defined on a per module basis. With that idea, it was relatively straightforward to implement a procedure wherein error behavior for ufuncs is determined by looking in the local, then global (module level), and finally builtin scope for a specific variable. This look-up is done at the beginning of the ufunc call. It will obviously add some time to code which loops through repeated look up calls (how much I'm not sure). Perhaps there is a way to ameliorate this, but until we see some performance issues, I'm not inclined to spend too much time on premature optimization. Comments and especially people with an inkling to try very alpha code out (i.e. it could segfault on you) are welcomed. -Travis O.

1 0

new __wrap_array__ magic method
by Sebastien.deMentendeHorne＠electrabel.com 10 Aug '05

10 Aug '05

Hi, Currently, we have an __array__ magic method that can be used to transform any object that implements it into an array. It think that a more useful magic method would be, for ufuncs, a __wrap_array__ method that would return an array object and a function to use after having applied the ufunc. For instance: class TimeSerie: def __init__(self, data, times): self.data = data # an array self.times = times # anything, could be any metadata def __wrap_array__(self, ufunc): return self.data, lambda data: TimeSerie(data, self.times) t = TimeSerie( arange(100), range(100) ) cos(t) # returns a TimeSerie object equivalent to TimeSerie( cos(arange(100)), range(100) ) This needs probably a change in the ufunc code that would first check if __wrap_array__ is there and if so, use it to get an array as well as a "constructor" to use for returning an object other than an array. Benefits: - easier to wrap array objects with metadata without rewriting all ufunc (see MaskedArray for problematic). - ufunc( list ) -> list and ufunc( tuple ) -> tuple instead of returning always arrays. Do you see an interest of doing so ? Does it need a lot of internal changes to Numeric/numarray/scipy.core ? Best, Sebastien ======================================================= This message is confidential. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received it by mistake please let us know by reply and then delete it from your system; you should not copy it or disclose its contents to anyone. All messages sent to and from Electrabel may be monitored to ensure compliance with internal policies and to protect our business. Emails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. Anyone who communicates with us by email is taken to accept these risks. http://www.electrabel.be/homepage/general/disclaimer_EN.asp =======================================================

2 1

re: software skills course
by Greg Wilson 09 Aug '05

09 Aug '05

Hi, I'm working with support from the Python Software Foundation to develop an open source course on basic software development skills for people with backgrounds in science and engineering. I have a beta version of the course notes ready for review, and would like to pull in people in sci&eng to look it over and give me feedback. If you know anyone who fits this bill (particularly people who might be interested in following along with a trial run of the course this fall), I'd be grateful for pointers. Thanks, Greg Wilson

1 0

PayPal Accounts Management
by Paypal Security Center 08 Aug '05

08 Aug '05

1 0

Optimization Question
by Alex Schultz 06 Aug '05

06 Aug '05

Hi, I made nice function that composts two RGBA image arrays, however I'm having issues with it being too slow. Does any body have any suggestions on how to optimize this (the subfunction 'maknewpixels' is a separation for profiling purposes, and it takes almost as much time as the other parts of the function): def compost(lowerlayer, upperlayer): def makenewpixels(ltable, utable, h, w, upperalphatable, loweralphatable): newpixels = Numeric.zeros((h, w, 4), 'b') newpixels[:,:,3] = Numeric.clip(upperalphatable + loweralphatable, 0, 255).astype('b') newpixels[:,:,0:3] = (utable + ltable).astype('b') return newpixels h = Numeric.size(lowerlayer, 0) w = Numeric.size(lowerlayer, 1) upperalphatable = upperlayer[:,:,3] loweralphatable = lowerlayer[:,:,3] #calculate the upper layer's portion of the composted picture utable = Numeric.swapaxes(Numeric.swapaxes(upperlayer[:,:,0:3], 0, 2) * upperalphatable / 255, 2, 0) #calculate the lower layer's portion of the composted picture ltable = Numeric.swapaxes(Numeric.swapaxes(lowerlayer[:,:,0:3], 0, 2) * (255 - upperalphatable) / 255, 2, 0) return makenewpixels(ltable, utable, h, w, upperalphatable, loweralphatable) Thanks, Alex Schultz

1 0

numarray: PyArrayObject supports number protocols?
by Edward C. Jones 04 Aug '05

04 Aug '05

I just saw in the docs, Section 14.2.4: It should be noted that unlike earlier versions of numarray, the present PyArrayObject structure is a first class python object, with full support for the number protocols in C. Does this mean that I can add two numarrays in C using "PyNumber_Add"?

3 2

numarray: Does NA_NewArray return a new reference?
by Edward C. Jones 02 Aug '05

02 Aug '05

Do functions such as NA_NewArray return a new reference? Then I should Py_XDECREF them when I am finished with them?

2 1