===
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
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
On Thu, Mar 7, 2013 at 11:47 AM, Francesc Alted franc...@continuum.io 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:
...
Yes
:
On 3/6/13 7:42 PM, Kurt Smith wrote:
And regarding performance, doing simple timings shows a 30%-ish
slowdown for unaligned operations:
In [36]: %timeit packed_arr['b']**2
100 loops, best of 3: 2.48 ms per loop
In [37]: %timeit aligned_arr['b']**2
1000 loops, best of 3: 1.9 ms per loop
Hmm
On Wed, Mar 6, 2013 at 4:29 AM, Francesc Alted franc...@continuum.io wrote:
On 3/5/13 7:14 PM, Kurt Smith wrote:
On Tue, Mar 5, 2013 at 1:45 AM, Eric Firing efir...@hawaii.edu wrote:
On 2013/03/04 9:01 PM, Nicolas Rougier wrote:
This made me think of a serious performance limitation
On Wed, Mar 6, 2013 at 12:12 PM, Kurt Smith kwmsm...@gmail.com wrote:
On Wed, Mar 6, 2013 at 4:29 AM, Francesc Alted franc...@continuum.io 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
On Tue, Mar 5, 2013 at 1:45 AM, Eric Firing efir...@hawaii.edu 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 types.
On Mon, Mar 4, 2013 at 4:29 PM, Todd toddr...@gmail.com 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
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
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 originally thought that owndata is False iff 'a' is a view. But
that is incorrect.
Consider
On Thu, Aug 12, 2010 at 8:26 PM, Lutz Maibaum lutz.maib...@gmail.com 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 stdin, line 1, in
On Thu, Aug 12, 2010 at 8:51 PM, David da...@silveregg.co.jp 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 within Bento, or
will that be delegated
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
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
, or in
whatever arbitrarily-strided order is necessary if the reshape can be
done without a copy. As it happens, in your example, the latter case
occurs and works out to Fortran order.
Good catch; I should have done 'arr.reshape(2,5).copy('F')'.
Anne
On 30 July 2010 13:50, Kurt Smith kwmsm
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
On Tue, Jul 27, 2010 at 9:45 AM, Francesc Alted fal...@pytables.org wrote:
A Tuesday 27 July 2010 15:20:47 Charles R Harris escrigué:
On Tue, Jul 27, 2010 at 7:08 AM, Francesc Alted fal...@pytables.org wrote:
Hi,
I'm a bit confused on which datatype should I use when referring to NumPy
On Tue, Jul 27, 2010 at 10:17 AM, Dag Sverre Seljebotn
da...@student.matnat.uio.no wrote:
From PEP 353:
Why not size_t56 http://www.python.org/dev/peps/pep-0353/#id9
An initial attempt to implement this feature tried to use size_t. It
quickly turned out that this cannot work: Python
On Mon, Jul 26, 2010 at 10:58 AM, Ralf Gommers
ralf.gomm...@googlemail.com 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:
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 noise.
Kurt
On Tue, Jul 13, 2010 at 11:54 AM, John Reid j.r...@mail.cryst.bbk.ac.uk 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]:
On Sat, Jun 26, 2010 at 7:34 PM, Warren Weckesser
warren.weckes...@enthought.com 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 works for me if I don't use the keyword
On Sun, Jun 27, 2010 at 1:03 PM, David Goldsmith
d.l.goldsm...@gmail.com wrote:
On Sun, Jun 27, 2010 at 10:38 AM, Kurt Smith kwmsm...@gmail.com wrote:
On Sat, Jun 26, 2010 at 7:34 PM, Warren Weckesser
warren.weckes...@enthought.com wrote:
Kurt Smith wrote:
I'd really like arr.copy(order='F
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, 9]])
On Sun, Apr 11, 2010 at 12:54 PM, Dag Sverre Seljebotn
da...@student.matnat.uio.no 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 necessary to include when
On Sat, Apr 10, 2010 at 9:53 AM, Dag Sverre Seljebotn
da...@student.matnat.uio.no wrote:
Kurt Smith wrote:
On Fri, Apr 9, 2010 at 2:25 AM, David da...@silveregg.co.jp wrote:
On 04/07/2010 11:52 AM, Kurt Smith wrote:
Fortran's .mod files are essentially compiler-generated header files;
fwrap
On Fri, Apr 9, 2010 at 2:25 AM, David da...@silveregg.co.jp 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 accomplish:
1) Compile
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
On Thu, Feb 25, 2010 at 7:18 PM, David Cournapeau da...@silveregg.co.jp 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 and the build system
On Fri, Feb 26, 2010 at 2:44 AM, Dag Sverre Seljebotn
da...@student.matnat.uio.no 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 areas that
need some TLC
On Fri, Feb 26, 2010 at 4:42 AM, David Cournapeau da...@silveregg.co.jp 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
On Thu, Feb 25, 2010 at 8:39 AM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Thu, Feb 25, 2010 at 1:07 AM, David Cournapeau da...@silveregg.co.jp
wrote:
Charles R Harris wrote:
On Wed, Feb 24, 2010 at 1:15 AM, David Cournapeau courn...@gmail.com
mailto:courn...@gmail.com
On Sat, Jan 16, 2010 at 10:04 PM, David Cournapeau courn...@gmail.com wrote:
On Sun, Jan 17, 2010 at 4:12 AM, Kurt Smith kwmsm...@gmail.com wrote:
My questions here concern those familiar with configure/build/install
systems such as distutils, setuptools, scons/numscons or waf
(particularly
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
On Sat, Jan 16, 2010 at 2:38 PM, Dag Sverre Seljebotn
da...@student.matnat.uio.no 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.
On Fri, Aug 14, 2009 at 8:04 AM, Dag Sverre
Seljebotnda...@student.matnat.uio.no 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
On Thu, Jul 9, 2009 at 9:36 PM, Chris Colbertsccolb...@gmail.com 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
On Mon, Jun 29, 2009 at 8:20 AM, Prashant Saxenaanimator...@yahoo.com 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
On Tue, Jun 23, 2009 at 10:17 PM, David Cournapeaucourn...@gmail.com 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
On Wed, Jun 24, 2009 at 9:05 AM, David
Cournapeauda...@ar.media.kyoto-u.ac.jp wrote:
Kurt Smith wrote:
On Tue, Jun 23, 2009 at 10:17 PM, David Cournapeaucourn...@gmail.com wrote:
If possible, you should not build executables, it is not portable.
Compiling and linking is Ok, running
On Tue, Jun 23, 2009 at 1:41 PM, Lisandro Dalcindalc...@gmail.com wrote:
On Mon, Jun 22, 2009 at 11:53 PM, Kurt Smithkwmsm...@gmail.com 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 executable is to
.
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 basics and am quickly
reading up on it -- any pointers would be very appreciated.
Thanks,
Kurt Smith
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
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
a =
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.0e0
45 matches
Mail list logo
