Re: [Numpy-discussion] [PATCH] gfortran under macports

Mabe I am wrong somehow, but in my experience the easiest install of scipy is 'port install py26-scipy'. For new users, I do not see why one would recommend to build manually from source? Macports can do it for you, automagically... Paul 4. des.. 2010 15.04 "Ralf Gommers" : On Sat, Dec 4, 2010

Re: [Numpy-discussion] Refactor fork uses the ./configure, make, make install process.

On Sat, Dec 4, 2010 at 12:45 PM, Pauli Virtanen wrote: > > Technically, the move could be done like this, so that merge tracking > still works: > > refactor--- new-refactor > // > /libndarray--x >/

Re: [Numpy-discussion] Refactor fork uses the ./configure, make, make install process.

On Sat, Dec 4, 2010 at 1:45 PM, Pauli Virtanen wrote: > On Sat, 04 Dec 2010 14:24:49 -0600, Ilan Schnell wrote: > > I'm not sure how reasonable it would be to move only libndarray into the > > master, because I've been working on EPD for the last couple of week. > > But Jason will know how comple

Re: [Numpy-discussion] Refactor fork uses the ./configure, make, make install process.

On 12/04/2010 09:11 PM, Charles R Harris wrote: On Sat, Dec 4, 2010 at 12:59 PM, Ilan Schnell > wrote: Yes, numpy-refactor builds of top of libndarray. The whole point was that the libndarray is independent of the interface, i.e. the CPython or the

Re: [Numpy-discussion] Refactor fork uses the ./configure, make, make install process.

On Sat, 04 Dec 2010 14:24:49 -0600, Ilan Schnell wrote: > I'm not sure how reasonable it would be to move only libndarray into the > master, because I've been working on EPD for the last couple of week. > But Jason will know how complete libndarray is. The main question is whether moving it will

Re: [Numpy-discussion] Refactor fork uses the ./configure, make, make install process.

I'm not sure how reasonable it would be to move only libndarray into the master, because I've been working on EPD for the last couple of week. But Jason will know how complete libndarray is. - Ilan On Sat, Dec 4, 2010 at 2:19 PM, Charles R Harris wrote: > Would it unreasonable to move the libnd

Re: [Numpy-discussion] Refactor fork uses the ./configure, make, make install process.

On Sat, Dec 4, 2010 at 12:52 PM, Pauli Virtanen wrote: > On Sat, 04 Dec 2010 12:21:15 -0700, Charles R Harris wrote: > [clip] > > So does numpy currently build on top of libndarray or is that something > > for the future also? > [clip] > > It does. If you look how it works, most of the heavy lift

Re: [Numpy-discussion] Refactor fork uses the ./configure, make, make install process.

On Sat, Dec 4, 2010 at 12:59 PM, Ilan Schnell wrote: > Yes, numpy-refactor builds of top of libndarray. The whole point > was that the libndarray is independent of the interface, i.e. the > CPython or the IronPython interface, and possibly other (Jython) > in the future. > Looking at different bu

Re: [Numpy-discussion] Faster than ndindex?

This is beautiful! Thank you Pauli. On Sat, Dec 4, 2010 at 7:16 PM, Pauli Virtanen wrote: > On Sat, 04 Dec 2010 19:00:43 +, Eleftherios Garyfallidis wrote: > [clip] > > I am using ndindex and then a for loop. Is there a better/faster way? > > Yes: > > import numpy as np > from numpy import n

Re: [Numpy-discussion] Refactor fork uses the ./configure, make, make install process.

Yes, numpy-refactor builds of top of libndarray. The whole point was that the libndarray is independent of the interface, i.e. the CPython or the IronPython interface, and possibly other (Jython) in the future. Looking at different building/packaging solutions for libndarray, autoconf make things

Re: [Numpy-discussion] Refactor fork uses the ./configure, make, make install process.

On Sat, 04 Dec 2010 12:21:15 -0700, Charles R Harris wrote: [clip] > So does numpy currently build on top of libndarray or is that something > for the future also? [clip] It does. If you look how it works, most of the heavy lifting has been moved there, leaving the multiarray module mostly as Pyt

Re: [Numpy-discussion] Refactor fork uses the ./configure, make, make install process.

On Sat, Dec 4, 2010 at 12:07 PM, Ilan Schnell wrote: > Hello Charles, > > it was indeed the intention to change the build process of the core > libndarray to use autoconf. I've tested it on Linux, Mac, Solaris, and > it works very well. libndarray is really a separate project, which only > resid

Re: [Numpy-discussion] Faster than ndindex?

On Sat, 04 Dec 2010 19:00:43 +, Eleftherios Garyfallidis wrote: [clip] > I am using ndindex and then a for loop. Is there a better/faster way? Yes: import numpy as np from numpy import newaxis x = np.zeros((200, 200, 200, 3)) x[...,0] = np.arange(200)[:,newaxis,newaxis] x[...,1] = np.arange(

Re: [Numpy-discussion] Refactor fork uses the ./configure, make, make install process.

Hello Charles, it was indeed the intention to change the build process of the core libndarray to use autoconf. I've tested it on Linux, Mac, Solaris, and it works very well. libndarray is really a separate project, which only resides for current development inside the numpy project. The point i

[Numpy-discussion] Faster than ndindex?

Hi guys, I would like to know if there is any way to make the following operation faster. def test(): shape=(200,200,200,3) refinds = np.ndindex(shape[:3]) reftmp=np.zeros(shape) for ijk_t in refinds: i,j,k = ijk_t reftmp[i,j,k,0]=i reftmp[i,j,k,1]=j

[Numpy-discussion] Refactor fork uses the ./configure, make, make install process.

Hi Jason, Just wondering if this is temporary or the intention is to change the build process? I also note that the *.h files in libndarray are not complete and a *lot* of trailing whitespace has crept into the files. Chuck ___ NumPy-Discussion mailing

Re: [Numpy-discussion] [PATCH] gfortran under macports

On Sat, Dec 4, 2010 at 9:47 PM, Fabian Pedregosa wrote: > On Sat, Dec 4, 2010 at 10:29 AM, Gael Varoquaux > wrote: > > On Sat, Dec 04, 2010 at 10:25:52AM +0100, Fabian Pedregosa wrote: > >> The correct command is "sudo gcc_select mp-gcc45" which effectively > >> does all the symbolic links for yo

Re: [Numpy-discussion] [PATCH] gfortran under macports

On Sat, Dec 4, 2010 at 10:29 AM, Gael Varoquaux wrote: > On Sat, Dec 04, 2010 at 10:25:52AM +0100, Fabian Pedregosa wrote: >> The correct command is "sudo gcc_select mp-gcc45" which effectively >> does all the symbolic links for you and works like a charm, so please >> ignore my previous patch. >

Re: [Numpy-discussion] [PATCH] gfortran under macports

On Sat, Dec 04, 2010 at 10:25:52AM +0100, Fabian Pedregosa wrote: > The correct command is "sudo gcc_select mp-gcc45" which effectively > does all the symbolic links for you and works like a charm, so please > ignore my previous patch. I am not a mac user, so I guess that my opinion is not very ed

Re: [Numpy-discussion] [PATCH] gfortran under macports

> > Correct me if I am wrong here: If you run "(sudo) gcc_select gfortran-mp-XY", > where XY are the version numbers (e.g. 45 for gfortran 4.5), you should get > symbolic links for the selected gcc/gfortran version. I believe that macports > should probably make this clearer, and perhaps automat

Re: [Numpy-discussion] [PATCH] gfortran under macports

On 3. des. 2010, at 16.24, Fabian Pedregosa wrote: > Hi all. > > Macports installs gfortran as part of the gcc package, but names it > gfortran-mp-$version, without providing a symbolic link to a default > gcfortran executable, and thus numpy.distutils is unable to find the > right executable. >