Hi,
I found this test caused a bus error on current trunk:
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, 5))
On Tue, Mar 6, 2012 at 5:39 PM, Sturla Molden 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, an
Den 7. mars 2012 kl. 00:43 skrev Charles R Harris :
>
>
> 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. Having a standard
> inli
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
On Tue, Mar 6, 2012 at 6:43 PM, Bryan Van de Ven wrote:
> On 3/6/12 2:39 PM, Sturla Molden wrote:
>> We can augment standard C with syntax suger for
>> generics, or even NumPy arrays and Python types, using a Python script
>> as meta-compiler. We don't need C++ for that.
> I can only speak for mys
On 3/6/12 2:39 PM, Sturla Molden wrote:
> We can augment standard C with syntax suger for
> generics, or even NumPy arrays and Python types, using a Python script
> as meta-compiler. We don't need C++ for that.
I can only speak for myself. I do not want to be in the meta-compiler
business, and I d
On Tue, Mar 6, 2012 at 4:03 PM, Sturla Molden 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 :
>
> > On Sun, Mar 4, 2012 at 2:18 PM, Luis Pedro Coelho wrote:
> >> At least las
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 :
> On Sun, Mar 4, 2012 at 2:18 PM, Luis Pedro Coelho wrote:
>> At least last time I read up on it, cython was not able to do multi-type
>> code,
On Thu, Mar 1, 2012 at 10:58 PM, Jay Bourque wrote:
> 1. Loading text files using loadtxt/genfromtxt need a significant
> performance boost (I think at least an order of magnitude increase in
> performance is very doable based on what I've seen with Erin's recfile code)
> 2. Improved memory usag
On Sun, Mar 4, 2012 at 2:18 PM, Luis Pedro Coelho 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 generate
multip
On Tue, Mar 6, 2012 at 6:53 AM, Matthew Brett wrote:
> Hi,
>
> On Mon, Mar 5, 2012 at 8:04 PM, Mark Wiebe 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 very
> > helpful. Since x86 mach
On Tue, Mar 6, 2012 at 9:14 PM, Ralf Gommers
wrote:
> On Tue, Mar 6, 2012 at 9:25 PM, Nathaniel Smith wrote:
>> On Sat, Mar 3, 2012 at 8:30 PM, Travis Oliphant
>> wrote:
>> > Hi all,
>>
>> Hi Travis,
>>
>> Thanks for bringing this back up.
>>
>> Have you looked at the summary from the last threa
On Tue, Mar 6, 2012 at 2:03 PM, Denis Laxalde wrote:
> 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.in
On Tue, Mar 6, 2012 at 9:25 PM, Nathaniel Smith wrote:
> On Sat, Mar 3, 2012 at 8:30 PM, Travis Oliphant
> 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-statu
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 4:38 PM, Mark Wiebe wrote:
> On Tue, Mar 6, 2012 at 5:48 AM, Pierre Haessig
> 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
>> particularly striking : two different dtyp
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
>
2012/3/6 Sturla Molden
> 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 th
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 tha
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: http://matt.e
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 usin
On Tue, Mar 6, 2012 at 2:57 PM, Sturla Molden 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:
>>
>> http://mail.scipy.org/pipermail
On Sat, Mar 3, 2012 at 8:30 PM, Travis Oliphant 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 points we all *could*
ag
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:
>
> http://mail.scipy.org/pipermail/numpy-discussion/2009-November/046567.html
>
> the answer by t
On Tue, Mar 6, 2012 at 1:25 PM, Travis Oliphant 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 two struct membe
On Tue, Mar 6, 2012 at 18:25, Travis Oliphant 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
___
Nu
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.
Hi Pierre,
On Tue, Mar 6, 2012 at 5:48 AM, Pierre Haessig wrote:
> 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:4
On Tue, Mar 6, 2012 at 6:20 AM, Robert Kern wrote:
> On Tue, Mar 6, 2012 at 03:53, David Cournapeau 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 i
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 NA-float6
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()
return
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 w
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 range(2048
On Tue, Mar 6, 2012 at 03:53, David Cournapeau 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 declared in
> th
34 matches
Mail list logo
