## numpy-discussion — Discussion list for all users of Numerical Python

You can subscribe to this list here.

 2000 2001 2002 2003 2004 2005 2006 Jan (8) Feb (49) Mar (48) Apr (28) May (37) Jun (28) Jul (16) Aug (16) Sep (44) Oct (61) Nov (31) Dec (24) Jan (56) Feb (54) Mar (41) Apr (71) May (48) Jun (32) Jul (53) Aug (91) Sep (56) Oct (33) Nov (81) Dec (54) Jan (72) Feb (37) Mar (126) Apr (62) May (34) Jun (124) Jul (36) Aug (34) Sep (60) Oct (37) Nov (23) Dec (104) Jan (110) Feb (73) Mar (42) Apr (8) May (76) Jun (14) Jul (52) Aug (26) Sep (108) Oct (82) Nov (89) Dec (94) Jan (117) Feb (86) Mar (75) Apr (55) May (75) Jun (160) Jul (152) Aug (86) Sep (75) Oct (134) Nov (62) Dec (60) Jan (187) Feb (318) Mar (296) Apr (205) May (84) Jun (63) Jul (122) Aug (59) Sep (66) Oct (148) Nov (120) Dec (70) Jan (460) Feb (683) Mar (589) Apr (559) May (445) Jun (712) Jul (815) Aug (663) Sep (559) Oct (930) Nov (373) Dec
S M T W T F S

1
(1)
2
(1)
3
(1)
4

5
(2)
6
(2)
7
(2)
8
(1)
9
(5)
10

11
(1)
12
(1)
13

14
(4)
15
(1)
16
(3)
17
(2)
18
(2)
19

20
(3)
21

22
(7)
23
(7)
24
(1)
25
(3)
26
(10)
27
(3)
28
(2)
29

30
(1)

Showing 10 results of 10

 Re: [Numpy-discussion] Piecewise functions. From: Travis Oliphant - 2005-09-26 17:43:44 ```Andrea Riciputi wrote: > Hi all, > this is probably an already discussed problem, but I've not been able > to find a solution even after googling a lot. > > I've a piecewise defined function: > > / > | f1(x) if x <= a > f(x) = | > | f2(x) if x > a > \ > > where f1 and f2 are not defined outside the above range. How can I > define such a function in Python in order to apply (map) it to an > array ranging from values smaller to values bigger than a? This is not a trivial problem in current versions of Numeric. What are you using, Numeric, numarray? In new scipy core (which replaces Numeric) and, I think, in numarray, you could say gta = x>a lea = x<=a y = x.copy() y[gta] = f2(x[gta]) y[lea] = f1(x[lea]) I've also just written a piecewise function for the new scipy core so you could write y = piecewise(x, x<=a, [f1,f2]) -Travis Oliphant ```
 Re: [Numpy-discussion] Release of scipy core beta will happen next week. From: Gerard Vermeulen - 2005-09-26 15:52:08 ```On Sun, 25 Sep 2005 19:59:23 -0700 Robert Kern wrote: > > typedef unsigned char bool; > > > > in arrayobject.h, because bool is a predefined type in C++. > > > > I see the offending line is still in SVN (did not try to build it though). > > Will this do the trick? > > #ifndef __cplusplus > typedef unsigned char bool; > #define false 0 > #define true 1 > #endif /* __cplusplus */ > It works for my g++, but it may not be a general solution. See footnote 15 under item 2 of section 5.3.3 of http://www.open-std.org/jtc1/sc22/open/n2356/ (ISO C++ draft) saying that sizeof(bool) is not required to be 1. Gerard ```
 Re: [Numpy-discussion] python-numeric in FC4: good idea? From: Stephen Walton - 2005-09-26 15:39:03 ```Fernando Perez wrote: > Robert Kern wrote: > >> Can you make an RPM of python-numeric compiled against ATLAS and install >> it yourself? > > > You can. In fact, Numeric builds out of the box with > > python bdist_rpm, > > though the package name comes out to be named 'Numeric', but that > should not be a problem, since the setup.cfg file reads: > > [bdist_rpm] > provides=python-numeric, python-numeric-devel > build_script=rpm_build.sh > install_script=rpm_install.sh > > which means that the python-numeric dependency should be satisfied. Yes, it is, and I sort of found that out myself. Yum is much smarter about this than RPM apparently; if I do rpm -U Numeric-23.8-i386.rpm rpm refuses to replace python-numeric-23.7 as distributed with FC4, but "yum install Numeric" when pointed at my local repo works fine. As does "rpm -i --force" of course. There is at least a verbal commitment at bugzilla.redhat.com from Redhat to migrate pygtk2 to the new array object when it comes out. ```
 Re: [Numpy-discussion] python-numeric in FC4: good idea? From: Travis Oliphant - 2005-09-26 15:17:37 ```Robert Kern wrote: >Greg Ewing wrote: > > >>Chris Barker wrote: >> >> >> >>>This is a Darn Good example of why we need the new array protocol. >>> >>> >>I came across another one the other day when working on >>pygui. I wanted to use glReadPixels to read data into a >>buffer belonging to an NSBitmapImageRep, but PyOpenGL's >>glReadPixels can only read data into an existing memory >>block if it's a Numeric array, and PyObjC doesn't know >>anything about Numeric... >> >> > >I've taken the liberty of adding these to a new Wiki page. Let's record >these "Oh I wish everyone used the array protocol" moments when we come >across them. > >http://www.scipy.org/wikis/featurerequests/ArrayInterfaceUseCases/ > > This is a great idea. It will help me sell an array_protocol_in_Python PEP to the Python Powers. -Travis ```
 Re: [Numpy-discussion] python-numeric in FC4: good idea? From: Robert Kern - 2005-09-26 09:43:47 ```Greg Ewing wrote: > Chris Barker wrote: > >> This is a Darn Good example of why we need the new array protocol. > > I came across another one the other day when working on > pygui. I wanted to use glReadPixels to read data into a > buffer belonging to an NSBitmapImageRep, but PyOpenGL's > glReadPixels can only read data into an existing memory > block if it's a Numeric array, and PyObjC doesn't know > anything about Numeric... I've taken the liberty of adding these to a new Wiki page. Let's record these "Oh I wish everyone used the array protocol" moments when we come across them. http://www.scipy.org/wikis/featurerequests/ArrayInterfaceUseCases/ This will probably migrate to the Trac instance for scipy whenever that comes about. -- Robert Kern rkern@... "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter ```
 Re: [Numpy-discussion] python-numeric in FC4: good idea? From: Greg Ewing - 2005-09-26 09:19:40 ```Chris Barker wrote: > This is a Darn Good example of why we need the new array protocol. I came across another one the other day when working on pygui. I wanted to use glReadPixels to read data into a buffer belonging to an NSBitmapImageRep, but PyOpenGL's glReadPixels can only read data into an existing memory block if it's a Numeric array, and PyObjC doesn't know anything about Numeric... Greg ```
 Re: [Numpy-discussion] python-numeric in FC4: good idea? From: Chris Barker - 2005-09-26 06:33:38 ```Robert Kern wrote: > Stephen Walton wrote: >>So, questions are: can someone more familiar with pygtk2 than me tell >>me what parts of it depend on Numeric and why? Can we start a campaign >>to put ATLAS into Fedora Core if Numeric is going to be there too? > > It's for returning a Numeric array from a pixbuf. This is a Darn Good example of why we need the new array protocol. Let's make sure to make sure it gets used as widely as possible. -Chris ```
 Re: [Numpy-discussion] python-numeric in FC4: good idea? From: Fernando Perez - 2005-09-26 05:03:25 ```Robert Kern wrote: > Can you make an RPM of python-numeric compiled against ATLAS and install > it yourself? Or can you install Numeric yourself and make a dummy > package to tell RPM that yes, indeed, Numeric is installed? I'm terribly > unfamiliar with Fedora and RPM; I've always prefered Debian. You can. In fact, Numeric builds out of the box with python bdist_rpm, though the package name comes out to be named 'Numeric', but that should not be a problem, since the setup.cfg file reads: [bdist_rpm] provides=python-numeric, python-numeric-devel build_script=rpm_build.sh install_script=rpm_install.sh which means that the python-numeric dependency should be satisfied. If you really need to have the rpm be named python-numeric, this can be done by either writing out the spec file and fixing it by hand via: python setup.py bdist_rpm --spec-only or by changing the 'name' flag in the setup.py by hand to read 'python-config' instead of 'Numeric'. If changing this name for rpms is a common need, we can patch up setup.py to take an optional argument. Cheers, f ```
 Re: [Numpy-discussion] Release of scipy core beta will happen next week. From: Robert Kern - 2005-09-26 02:59:21 ```Gerard Vermeulen wrote: > On Sat, 24 Sep 2005 22:51:27 -0600 > Travis Oliphant wrote: > >>At the SciPy 2005 conference I announced that I was hoping to get a beta >>of the new scipy (core) (aka Numeric3 aka Numeric Next Generation) >>released by the end of the conference. >> >>This did not happen. Some last minute features were suggested by >>Fernando Perez that I think will be relatively easy to add and make the >>release that much stronger. >> >>Look for the beta announcement next week. >> >>For the impatient, the svn server is always available: >> >>http://svn.scipy.org/svn/scipy_core/branches/newcore > > Hi Travis, > > when I tried a few months ago to compile one of my C++ Python modules with > Numeric3, g++-3.4.3 choked on the line > > typedef unsigned char bool; > > in arrayobject.h, because bool is a predefined type in C++. > > I see the offending line is still in SVN (did not try to build it though). Will this do the trick? #ifndef __cplusplus typedef unsigned char bool; #define false 0 #define true 1 #endif /* __cplusplus */ > Sorry for sitting on the bug so long; the main reason is that at the time > (I suppose it is still the case) Numeric3 does not coexist well with > Numeric in the same Python interpreter (I remember import conflicts). > If a typical Linux user wants to play with Numeric3, he has either to remove > Numeric (and break possible dependencies) or build his own Python for Numeric3. > I think that most Linux users are not going to do this and that it will take more > than a year before distros make the move. Hence, my lack of motivation for > reporting bugs or giving it a real try. scipy_core does not interfere with Numeric anymore. It's installed as scipy (so it *will* interfere with previous versions of scipy). While we're on the subject of bugs (for reference, I'm on OS X 10.4 with Python 2.4.1): * When linking umath.so, distutils is including a bare "-l" that causes the link to fail (gcc can't interpret the argument). I have no idea where it's coming from. Just after the Extension object for umath.so is created, the libraries attribute is empty, just like the other Extension objects. * When linking against Accelerate.framework, it can't find cblas.h . I have a patch in scipy.distutils.system_info for that (and also to remove the -framework arguments for compiling; they're solely linker flags). * setup.py looks for an optimized BLAS through blas_info, but getting lapack_info is commented out. Is this deliberate? * Despite comment lines claiming the contrary, scipy.linalg hasn't been converted yet. basic_lite.py tries to import lapack and flapack. * scipy.base.limits is missing (and is used in basic_lite.py). Feature request: * Bundle the include directory in with the package itself and provide a function somewhere that returns the appropriate directory. People writing setup.py scripts for extension modules that use scipy_core can then do the following: from scipy.distutils import get_scipy_include ... someext = Extension('someext', include_dirs=[get_scipy_include(), ...], ...) This would help people who can't write to sys.prefix+'/include/python2.4' and people like me who are trying to package scipy_core into a PythonEgg (which doesn't yet support installing header files to the canonical location). -- Robert Kern rkern@... "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter ```
 Re: [Numpy-discussion] python-numeric in FC4: good idea? From: Robert Kern - 2005-09-26 02:40:42 ```Stephen Walton wrote: > In my ongoing struggles with FC4, I now find that the Fedora developers > have put Numeric 23.7 into the core as python-numeric and built pygtk2 > against it, so the latter has a dependency on the former. > > I think this is a bad idea unless the core developers are going to > include ATLAS and build Numeric against it. After all, this community > and the Scipy one have gone to great lengths to optimize ATLAS and build > Numeric and numarray (and presumably the new scipy core) against it. > But I'm probably not going to convince the Redhat folks on my own. > > So, questions are: can someone more familiar with pygtk2 than me tell > me what parts of it depend on Numeric and why? Can we start a campaign > to put ATLAS into Fedora Core if Numeric is going to be there too? It's for returning a Numeric array from a pixbuf. Strictly speaking, it's optional, but it looks like the package maintainers decided to compile it in for FC4. Can you make an RPM of python-numeric compiled against ATLAS and install it yourself? Or can you install Numeric yourself and make a dummy package to tell RPM that yes, indeed, Numeric is installed? I'm terribly unfamiliar with Fedora and RPM; I've always prefered Debian. -- Robert Kern rkern@... "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter ```

Showing 10 results of 10