On Tue, Mar 6, 2012 at 03:53, David Cournapeau courn...@gmail.com wrote:
Hi,
This is following the discussion on bug
http://projects.scipy.org/numpy/ticket/2017
Essentially, there is a discrepency between the actual type of the
flags member in the dtype C structure (char) and how it is
Hello everyone,
does anyone know of an efficient implementation (maybe using
numpy.where statement) of the next code for data cube (3d array)
combining ?
import numpy as np
def combine( )
cube = np.random.rand(32,2048,2048)
result = np.zeros([2048,2048], np.float32)
for ii in
Hello,
On Tue, 2012-03-06 at 13:00 +0100, Jose Miguel Ibáñez wrote:
Hello everyone,
does anyone know of an efficient implementation (maybe using
numpy.where statement) of the next code for data cube (3d array)
combining ?
You use the axis keyword/argument to sum, at which point you want
Hi,
this should work:
import numpy as np
ndim = 20
cube = np.random.rand(32,ndim, ndim)
result = np.zeros([ndim, ndim], np.float32)
def combine(cube, result):
for ii in range(ndim):
for jj in range(ndim):
result[ii, jj] = np.sqrt((cube[:,ii, jj])).sum()
Hi Mark,
I went through the NA NEP a few days ago, but only too quickly so that
my question is probably a rather dumb one. It's about the usability of
bitpatter-based NAs, based on your recent post :
Le 03/03/2012 22:46, Mark Wiebe a écrit :
Also, here's a thought for the usability of
On Tue, Mar 6, 2012 at 6:20 AM, Robert Kern robert.k...@gmail.com wrote:
On Tue, Mar 6, 2012 at 03:53, David Cournapeau courn...@gmail.com wrote:
Hi,
This is following the discussion on bug
http://projects.scipy.org/numpy/ticket/2017
Essentially, there is a discrepency between the actual
Hi Pierre,
On Tue, Mar 6, 2012 at 5:48 AM, Pierre Haessig pierre.haes...@crans.orgwrote:
Hi Mark,
I went through the NA NEP a few days ago, but only too quickly so that
my question is probably a rather dumb one. It's about the usability of
bitpatter-based NAs, based on your recent post :
Why do we want to return a single string char instead of an int?
There is a need for more flags on the dtype object. Using an actual attribute
call seems like the way to go. This could even merge the contents of two
struct members so that we can add more flags but preserve ABI compatibility.
On Tue, Mar 6, 2012 at 18:25, Travis Oliphant tra...@continuum.io wrote:
Why do we want to return a single string char instead of an int?
I suspect just to ensure that any provided value fits in the range
0..255. But that's easily done explicitly.
--
Robert Kern
On Tue, Mar 6, 2012 at 1:25 PM, Travis Oliphant tra...@continuum.io wrote:
Why do we want to return a single string char instead of an int?
There is a need for more flags on the dtype object. Using an actual
attribute call seems like the way to go. This could even merge the contents
of
On Sat, Mar 3, 2012 at 8:30 PM, Travis Oliphant tra...@continuum.io wrote:
Hi all,
Hi Travis,
Thanks for bringing this back up.
Have you looked at the summary from the last thread?
https://github.com/njsmith/numpy/wiki/NA-discussion-status
The goal was to try and at least work out what
On Tue, Mar 6, 2012 at 2:57 PM, Sturla Molden stu...@molden.no wrote:
On 05.03.2012 14:26, V. Armando Solé wrote:
In 2009 there was a thread in this mailing list concerning the access to
BLAS from C extension modules.
If I have properly understood the thread:
On 03.03.2012 17:07, Luis Pedro Coelho wrote:
I sort of missed the big C++ discussion, but I'd like to give some examples of
how writing code can become much simpler if you are based on C++. This is from
my mahotas package, which has a thin C++ wrapper around numpy's C API
Here you are using
Using either for
numerical programming usually a mistake.
This is your opinion, but there are a lot of numerical code now in C++ and
they are far more maintainable than in Fortran. And they are faster for
exactly this reason.
Matthieu
--
Information System Engineer, Ph.D.
Blog:
On 06.03.2012 21:45, Matthieu Brucher wrote:
This is your opinion, but there are a lot of numerical code now in C++
and they are far more maintainable than in Fortran. And they are faster
for exactly this reason.
That is mostly because C++ makes tasks that are non-numerical easier.
But that
2012/3/6 Sturla Molden stu...@molden.no
On 06.03.2012 21:45, Matthieu Brucher wrote:
This is your opinion, but there are a lot of numerical code now in C++
and they are far more maintainable than in Fortran. And they are faster
for exactly this reason.
That is mostly because C++ makes
On 06.03.2012 21:33, David Cournapeau wrote:
Of course it does make his life easier. This way he does not have to
distribute his own BLAS/LAPACK/etc...
Please stop presenting as truth things which are at best highly
opiniated. You already made such statements many times, and it is not
On Tue, Mar 6, 2012 at 4:38 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Tue, Mar 6, 2012 at 5:48 AM, Pierre Haessig pierre.haes...@crans.org
wrote:
From a potential user perspective, I feel it would be nice to have NA
and non-NA cases look as similar as possible. Your code example is
Hi,
np.__version__
'1.7.0.dev-7c07089'
p = np.poly1d([1,1])
p + 1.0
poly1d([ 1., 2.])
p + np.float64(1)
poly1d([ 1., 2.])
np.float64(1.0) + p
array([ 2., 2.])
np.int64(1) + p
array([2, 2])
np.int(1) + p
poly1d([1, 2])
On Tue, Mar 6, 2012 at 9:25 PM, Nathaniel Smith n...@pobox.com wrote:
On Sat, Mar 3, 2012 at 8:30 PM, Travis Oliphant tra...@continuum.io
wrote:
Hi all,
Hi Travis,
Thanks for bringing this back up.
Have you looked at the summary from the last thread?
On Tue, Mar 6, 2012 at 2:03 PM, Denis Laxalde denis.laxa...@mcgill.cawrote:
Hi,
np.__version__
'1.7.0.dev-7c07089'
p = np.poly1d([1,1])
p + 1.0
poly1d([ 1., 2.])
p + np.float64(1)
poly1d([ 1., 2.])
np.float64(1.0) + p
array([ 2., 2.])
np.int64(1)
On Tue, Mar 6, 2012 at 9:14 PM, Ralf Gommers
ralf.gomm...@googlemail.com wrote:
On Tue, Mar 6, 2012 at 9:25 PM, Nathaniel Smith n...@pobox.com wrote:
On Sat, Mar 3, 2012 at 8:30 PM, Travis Oliphant tra...@continuum.io
wrote:
Hi all,
Hi Travis,
Thanks for bringing this back up.
Have you
On Tue, Mar 6, 2012 at 6:53 AM, Matthew Brett matthew.br...@gmail.comwrote:
Hi,
On Mon, Mar 5, 2012 at 8:04 PM, Mark Wiebe mwwi...@gmail.com wrote:
I've pushed a bugfix to github, can you confirm that the crash goes away
on
your test box? Thanks for tracking that down, the stack trace was
On Sun, Mar 4, 2012 at 2:18 PM, Luis Pedro Coelho l...@cmu.edu wrote:
At least last time I read up on it, cython was not able to do multi-type code,
i.e., have code that works on arrays of multiple types. Does it support it
now?
The Bottleneck project used some sort of template system to
Upcoming Cython releases will have a generics system called fused types.
Sturla
Sendt fra min iPad
Den 6. mars 2012 kl. 23:26 skrev Chris Barker chris.bar...@noaa.gov:
On Sun, Mar 4, 2012 at 2:18 PM, Luis Pedro Coelho l...@cmu.edu wrote:
At least last time I read up on it, cython was not
On Tue, Mar 6, 2012 at 4:03 PM, Sturla Molden stu...@molden.no wrote:
Upcoming Cython releases will have a generics system called fused types.
Sturla
Sendt fra min iPad
Den 6. mars 2012 kl. 23:26 skrev Chris Barker chris.bar...@noaa.gov:
On Sun, Mar 4, 2012 at 2:18 PM, Luis Pedro Coelho
On 03/06/2012 12:54 PM, Sturla Molden wrote:
On 06.03.2012 21:45, Matthieu Brucher wrote:
This is your opinion, but there are a lot of numerical code now in C++
and they are far more maintainable than in Fortran. And they are faster
for exactly this reason.
That is mostly because C++ makes
Den 7. mars 2012 kl. 00:43 skrev Charles R Harris charlesr.har...@gmail.com:
I don't see generics as the main selling point of C++ for Numpy. What I
expect to be really useful is exception handling, smart pointers, and RIAA.
And maybe some carefule uses of classes and inheritance.
On Tue, Mar 6, 2012 at 5:39 PM, Sturla Molden stu...@molden.no wrote:
Den 7. mars 2012 kl. 00:43 skrev Charles R Harris
charlesr.har...@gmail.com:
I don't see generics as the main selling point of C++ for Numpy. What I
expect to be really useful is exception handling, smart pointers,
Hi,
I found this test caused a bus error on current trunk:
pre
import numpy as np
from StringIO import StringIO as BytesIO
from numpy.testing import assert_array_equal
def test_2d_buf():
dtt = np.complex64
arr = np.arange(10, dtype=dtt)
# 2D array
arr2 = np.reshape(arr, (2,
30 matches
Mail list logo
