[Numpy-discussion] ANN: DistArray 0.5 release

=== DistArray 0.5 release === **Mailing list:** distar...@googlegroups.com **Documentation:** http://distarray.readthedocs.org **License:** Three-clause BSD **Python versions:** 2.7, 3.3, and 3.4 **OS suppo

[Numpy-discussion] ANN: DistArray 0.2 -- first public development release

GitHub repo: https://github.com/enthought/distarray Documentation: http://distarray.readthedocs.org License: Three-clause BSD Python versions: 2.7 and 3.3 OS support: *nix and Mac OS X DistArray aims to bring the strengths of NumPy to data-parallel high-performance computing. It provides dist

Re: [Numpy-discussion] aligned / unaligned structured dtype behavior

, 2013 at 1:06 PM, Francesc Alted wrote: >> On 3/7/13 6:47 PM, Francesc Alted wrote: >>> On 3/6/13 7:42 PM, Kurt Smith wrote: >>>> And regarding performance, doing simple timings shows a 30%-ish >>>> slowdown for unaligned operations: >>>> >>

Re: [Numpy-discussion] aligned / unaligned structured dtype behavior (was: GSOC 2013)

On Thu, Mar 7, 2013 at 11:47 AM, Francesc Alted wrote: > On 3/6/13 7:42 PM, Kurt Smith wrote: > > Hmm, that clearly depends on the architecture. On my machine: > ... > That is, the unaligned column is 4x slower (!). numexpr allows somewhat > better results: > ... >

[Numpy-discussion] aligned / unaligned structured dtype behavior (was: GSOC 2013)

On Wed, Mar 6, 2013 at 12:12 PM, Kurt Smith wrote: > On Wed, Mar 6, 2013 at 4:29 AM, Francesc Alted wrote: >> >> I would not run too much. The example above takes 9 bytes to host the >> structure, while a `aligned=True` will take 16 bytes. I'd rather let >> t

Re: [Numpy-discussion] GSOC 2013

On Wed, Mar 6, 2013 at 4:29 AM, Francesc Alted wrote: > On 3/5/13 7:14 PM, Kurt Smith wrote: >> On Tue, Mar 5, 2013 at 1:45 AM, Eric Firing wrote: >>> On 2013/03/04 9:01 PM, Nicolas Rougier wrote: >>>>>> This made me think of a serious performance limita

Re: [Numpy-discussion] GSOC 2013

On Tue, Mar 5, 2013 at 1:45 AM, Eric Firing wrote: > On 2013/03/04 9:01 PM, Nicolas Rougier wrote: >>> >This made me think of a serious performance limitation of structured >>> >dtypes: a >>> >structured dtype is always "packed", which may lead to terrible byte >>> >alignment >>> >for common typ

Re: [Numpy-discussion] GSOC 2013

On Mon, Mar 4, 2013 at 4:29 PM, Todd wrote: > > 3. Structured arrays are accessed in a manner similar to python dictionaries, > using a key. However, they don't support the normal python dictionary > methods like keys, values, items, iterkeys, itervalues, iteritems, etc. This > project would be

Re: [Numpy-discussion] Determining the 'viewness' of an array, and flags.owndata confusion

f I test to see if 'arr.base' is not None, it may or or may not be a view. Is this correct? > > > > > On Feb 28, 2012, at 4:01 PM, Kurt Smith wrote: > > For an arbitrary numpy array 'a', what does 'a.flags.owndata' indicate? > > I originall

[Numpy-discussion] Determining the 'viewness' of an array, and flags.owndata confusion

For an arbitrary numpy array 'a', what does 'a.flags.owndata' indicate? I originally thought that owndata is False iff 'a' is a view. But that is incorrect. Consider the following: In [119]: a = np.zeros((3,3)) In [120]: a.flags.owndata # should be True; zeros() creates and returns a non-view

Re: [Numpy-discussion] Bento question: Fortran 90 & Cython support

On Thu, Aug 12, 2010 at 8:51 PM, David wrote: > Hi Kurt, > > On 08/13/2010 03:40 AM, Kurt Smith wrote: >> Hi, >> >> I'm very interested in Bento and think it will be a killer project. >> >> My question: do you anticipate supporting Fortran 90 with

Re: [Numpy-discussion] ndarray.copy does not accept keyword argument

On Thu, Aug 12, 2010 at 8:26 PM, Lutz Maibaum wrote: > According to the docstring, ndarray.copy should accept a keyword argument > "order". This doesn't seem to work for me: > np.array([[1,2],[3,4]]).copy(order='C') > Traceback (most recent call last): >  File "", line 1, in > TypeError: co

[Numpy-discussion] Bento question: Fortran 90 & Cython support

Hi, I'm very interested in Bento and think it will be a killer project. My question: do you anticipate supporting Fortran 90 within Bento, or will that be delegated to an external build tool? There are some intricacies with Fortran 90 that make it difficult to use with the usual configure-then-b

[Numpy-discussion] ANN fwrap v0.1.0

Fwrap v0.1.0 I am pleased to announce the first release of Fwrap v0.1.0, a utility for wrapping Fortran code in C, Cython and Python. Fwrap focuses on supporting the features of Fortran 90/95, but will work with most well-behaved Fortran 77 code, too. Fwrap is BSD licensed. Fwrap i

Re: [Numpy-discussion] np.asfortranarray: unnecessary copying?

he memory layout; what it does is define > the logical arrangement of elements used while reshaping the array. > The array returned will be in C order if a copy must be made, or in > whatever arbitrarily-strided order is necessary if the reshape can be > done without a copy. As it happen

[Numpy-discussion] np.asfortranarray: unnecessary copying?

What are the rules for when 'np.asarray' and 'np.asfortranarray' make a copy? This makes sense to me: In [3]: carr = np.arange(3) In [6]: carr2 = np.asarray(carr) In [8]: carr2[0] = 1 In [9]: carr Out[9]: array([1, 1, 2]) No copy is made. But doing the same with a fortran array makes a copy:

Re: [Numpy-discussion] size_t or npy_intp?

On Tue, Jul 27, 2010 at 10:17 AM, Dag Sverre Seljebotn wrote: >  From PEP 353: > > >    Why not size_t56 > > An initial attempt to implement this feature tried to use size_t. It > quickly turned out that this cannot work: Python uses negative indices

Re: [Numpy-discussion] size_t or npy_intp?

On Tue, Jul 27, 2010 at 9:45 AM, Francesc Alted wrote: > A Tuesday 27 July 2010 15:20:47 Charles R Harris escrigué: >> On Tue, Jul 27, 2010 at 7:08 AM, Francesc Alted wrote: >> > Hi, >> > >> > I'm a bit confused on which datatype should I use when referring to NumPy >> > ndarray lengths.  In one

Re: [Numpy-discussion] 1.5 release schedule proposal

>> Basically the 'wrap' mode for handling out-of-bounds indexing in >> ndimage functions is completely broken.  The test suite tests for the >> wrong behavior. >> > > Ah, we are talking about numpy 1.5, not scipy. You should raise this issue > over on the scipy-dev list. My bad. Sorry for the noi

Re: [Numpy-discussion] 1.5 release schedule proposal

On Mon, Jul 26, 2010 at 10:58 AM, Ralf Gommers wrote: > Hi all, > > For numpy 1.5.0 no one has yet said they have urgent changes that need to go > in. If you do, please reply with the what and why. If nothing big has to go > in, I propose the following release schedule: > > Aug 1 : beta 1 > Aug 15

Re: [Numpy-discussion] Difference between shape=() and shape=(1,)

On Tue, Jul 13, 2010 at 11:54 AM, John Reid wrote: > Hi, > > I have some arrays of various shapes in which I need to set any NaNs to > 0. I have been doing the following: > > a[numpy.where(numpy.isnan(a)] = 0. > > > > as you can see here: > > In [20]: a=numpy.ones(2) > > In [21]: a[1]=numpy.log(-1

Re: [Numpy-discussion] arr.copy(order='F') doesn't agree with docstring: what is intended behavior?

On Sun, Jun 27, 2010 at 1:03 PM, David Goldsmith wrote: > On Sun, Jun 27, 2010 at 10:38 AM, Kurt Smith wrote: >> >> On Sat, Jun 26, 2010 at 7:34 PM, Warren Weckesser >> wrote: >> > Kurt Smith wrote: >> >> I'd really like arr.copy(order='F&#

Re: [Numpy-discussion] arr.copy(order='F') doesn't agree with docstring: what is intended behavior?

On Sat, Jun 26, 2010 at 7:34 PM, Warren Weckesser wrote: > Kurt Smith wrote: >> I'd really like arr.copy(order='F') to work -- is it supposed to as >> its docstring says, or is it supposed to raise a TypeError as it does >> now? >> > > It w

[Numpy-discussion] arr.copy(order='F') doesn't agree with docstring: what is intended behavior?

I'd really like arr.copy(order='F') to work -- is it supposed to as its docstring says, or is it supposed to raise a TypeError as it does now? This is on numpy 1.4 >>> import numpy as np >>> a = np.arange(10).reshape(5,2) >>> a array([[0, 1], [2, 3], [4, 5], [6, 7], [8

Re: [Numpy-discussion] numpy build system questions for use in another project (fwrap)

On Sun, Apr 11, 2010 at 12:54 PM, Dag Sverre Seljebotn wrote: > Kurt Smith wrote: ... >> >> So you could do something like the following to get the compiler flags: >> >> $ fwrap --get-cflags --fcompiler=intelem >> >> And it would spit out the flags nec

Re: [Numpy-discussion] numpy build system questions for use in another project (fwrap)

On Sat, Apr 10, 2010 at 9:53 AM, Dag Sverre Seljebotn wrote: > Kurt Smith wrote: >> On Fri, Apr 9, 2010 at 2:25 AM, David wrote: >>> On 04/07/2010 11:52 AM, Kurt Smith wrote: >> Fortran's .mod files are essentially compiler-generated header files; >> fwrap

Re: [Numpy-discussion] numpy build system questions for use in another project (fwrap)

On Fri, Apr 9, 2010 at 2:25 AM, David wrote: > On 04/07/2010 11:52 AM, Kurt Smith wrote: >> Briefly, I'm encountering difficulties getting things working in numpy >> distutils for fwrap's build system. >> >> Here are the steps I want the build system to accomp

[Numpy-discussion] numpy build system questions for use in another project (fwrap)

Briefly, I'm encountering difficulties getting things working in numpy distutils for fwrap's build system. Here are the steps I want the build system to accomplish: 1) Compile a directory of Fortran 90 source code -- this works. - The .mod files generated by this compilation step are put in t

Re: [Numpy-discussion] How to test f2py?

On Fri, Feb 26, 2010 at 4:42 AM, David Cournapeau wrote: > Dag Sverre Seljebotn wrote: > >> (I'd think one basically has to make the same blatant assumptions that >> f2py makes about type conversion, name mangling etc., but that is also >> much less dangerous/error-prone for Fortran 77.) > > Every

Re: [Numpy-discussion] How to test f2py?

On Fri, Feb 26, 2010 at 2:44 AM, Dag Sverre Seljebotn wrote: > David Cournapeau wrote: >> Kurt Smith wrote: >> >> >>> I'm the developer of fwrap.  It is coming along, but will be at least >>> a month, likely two before the first release.  (The main

Re: [Numpy-discussion] How to test f2py?

On Thu, Feb 25, 2010 at 7:18 PM, David Cournapeau wrote: > Kurt Smith wrote: > >> I'm the developer of fwrap.  It is coming along, but will be at least >> a month, likely two before the first release.  (The main areas that >> need some TLC are the fortran parser an

Re: [Numpy-discussion] How to test f2py?

On Thu, Feb 25, 2010 at 8:39 AM, Charles R Harris wrote: > > > On Thu, Feb 25, 2010 at 1:07 AM, David Cournapeau > wrote: >> >> Charles R Harris wrote: >> > >> > >> > On Wed, Feb 24, 2010 at 1:15 AM, David Cournapeau > > > wrote: >> > >> >     On Wed, Feb 24, 2010 at 1:

Re: [Numpy-discussion] Waf or scons/numscons for a C/Fortran/Cython/Python project -- what's your recommendation?

On Sat, Jan 16, 2010 at 10:04 PM, David Cournapeau wrote: > On Sun, Jan 17, 2010 at 4:12 AM, Kurt Smith wrote: >> My questions here concern those familiar with configure/build/install >> systems such as distutils, setuptools, scons/numscons or waf >> (particularly David C

Re: [Numpy-discussion] Waf or scons/numscons for a C/Fortran/Cython/Python project -- what's your recommendation?

On Sat, Jan 16, 2010 at 2:38 PM, Dag Sverre Seljebotn wrote: > Not that I really know anything about it, but note that one of the > purposes of David's toydist is to handle the install stage independently > of the build system used. That is, it is able to create e.g. Python eggs > without using s

[Numpy-discussion] Waf or scons/numscons for a C/Fortran/Cython/Python project -- what's your recommendation?

My questions here concern those familiar with configure/build/install systems such as distutils, setuptools, scons/numscons or waf (particularly David Cournapeau). I'm creating a tool known as 'fwrap' that has a component that needs to do essentially what f2py does now -- take fortran source code

Re: [Numpy-discussion] Cython BOF

On Fri, Aug 14, 2009 at 8:04 AM, Dag Sverre Seljebotn wrote: > There's been some discussion earlier about how starting to write bigger > parts of the NumPy/SciPy codebase in Cython could potentially lower the > barrier of entry. > > Some topics: >  * Move towards PEP3118 as the primary scientific "

Re: [Numpy-discussion] transform an array of points efficiently?

On Thu, Jul 9, 2009 at 9:36 PM, Chris Colbert wrote: > no, because dot(x,y) != dot(y,x) > Try this, then: In [24]: x = np.random.rand(10,4) In [25]: y = np.random.rand(4,4) In [26]: result = np.dot(y,x.T).T In [39]: for i, res in enumerate(result): : assert np.allclose(res, np.dot(y

Re: [Numpy-discussion] numpy/numexpr performance (particle simulation)

On Mon, Jun 29, 2009 at 8:20 AM, Prashant Saxena wrote: > Hi, > > I am doing a little test using numpy and numexpr to do a particle > simulation. I never used either of them much and this is the first time I > have to go deeper. Here is the code: > > import numpy as np > import numexpr as nexpr > >

Re: [Numpy-discussion] Help using numpy.distutils.fcompiler for my GSoC project

On Wed, Jun 24, 2009 at 9:05 AM, David Cournapeau wrote: > Kurt Smith wrote: >> On Tue, Jun 23, 2009 at 10:17 PM, David Cournapeau wrote: >> >> >>> If possible, you should not build executables, it is not portable. >>> Compiling and linking is Ok, running

Re: [Numpy-discussion] Help using numpy.distutils.fcompiler for my GSoC project

On Tue, Jun 23, 2009 at 10:17 PM, David Cournapeau wrote: > If possible, you should not build executables, it is not portable. > Compiling and linking is Ok, running is not. For a tool which is aimed > a general use, I think this is important. Knowing the exact tests > needed by the OP would help

Re: [Numpy-discussion] Help using numpy.distutils.fcompiler for my GSoC project

On Tue, Jun 23, 2009 at 1:41 PM, Lisandro Dalcin wrote: > On Mon, Jun 22, 2009 at 11:53 PM, Kurt Smith wrote: >> Hello, >> >> Is there a way for numpy.distutils to compile a fortran source file >> into an executable? > > If the whole point of building the ex

[Numpy-discussion] Help using numpy.distutils.fcompiler for my GSoC project

7;genconfig.f95' into an object file, but we then need to compile it to an executable. Is there a way for numpy.distutils to compile a fortran source file into an executable? I'm not well-versed in the black arts of distutils or numpy.distutils. I know the ba

Re: [Numpy-discussion] state of G3F2PY?

r compilers. 2) The GSoC project is distributed with Cython. 3) Python version >= 2.5. 4) Hopefully you're not on windows -- we certainly plan on supporting Windows at some point in the future, but we don't have access to it for testing right now. Hope this helps, Kurt Smith _

Re: [Numpy-discussion] PyArray_EMPTY and Cython

On Tue, Dec 2, 2008 at 9:57 PM, Gabriel Gellner <[EMAIL PROTECTED]>wrote: > After some discussion on the Cython lists I thought I would try my hand at > writing some Cython accelerators for empty and zeros. This will involve > using > PyArray_EMPTY, I have a simple prototype I would like to get wo

Re: [Numpy-discussion] Optimization of loops

On Thu, Oct 23, 2008 at 5:55 PM, Pierre Yger <[EMAIL PROTECTED]> wrote: > > import bisect > my_list.sort() > time, ind = zip(*my_list) > for i in id_list : > beg = bisect.bisect_left(ind,i) >end = bisect.bisect_right(ind,i) >mylist.append(tim[beg:end]) > I've always found itertools.gr

Re: [Numpy-discussion] Loading a > GB file into array

On Nov 30, 2007 2:47 AM, Martin Spacek <[EMAIL PROTECTED]> wrote: > I need to load a 1.3GB binary file entirely into a single numpy.uint8 > array. I've been using numpy.fromfile(), but for files > 1.2GB on my > win32 machine, I get a memory error. Actually, since I have several > other python modul

Re: [Numpy-discussion] Memory leak in ndarray, more info

On 10/26/07, Robert Crida <[EMAIL PROTECTED]> wrote: > Hi all > > I recently posted about a memory leak in numpy and failed to mention the > version. The leak manifests itself in numpy-1.0.3.1 but is not present in > numpy-1.0.2 > > The following code reproduces the bug: > > import numpy as np > >

[Numpy-discussion] Possible bug -- importing numpy before f2py compiled module gives seg fault

Hello - I've come up with the following test case to illustrate my problem: file empty.f: subroutine empty(arr, nx,ny ) implicit none integer, intent(in) :: nx,ny real, dimension(nx,ny), intent(out) :: arr print *, "in empty." arr = 1.0e