On Tue, Jan 26, 2010 at 10:02 PM, David Cournapeau wrote:
> Charles R Harris wrote:
>
> >
> > Whatever we do, it would be good to figure out some way to avoid this
> > problem in the future. We could hide access to the array, for instance.
> > But again, that would require a lot of other code mods
Charles R Harris wrote:
>
> Whatever we do, it would be good to figure out some way to avoid this
> problem in the future. We could hide access to the array, for instance.
> But again, that would require a lot of other code mods. Hmm...
That's something that we have to do at some point if we c
Charles R Harris wrote:
>
>
> Thinking a bit more, for 1.4.1 I think we should just remove the function.
This was rejected last time I suggested it, though :)
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/ma
On Tue, Jan 26, 2010 at 9:50 PM, Charles R Harris wrote:
>
>
> On Tue, Jan 26, 2010 at 9:24 PM, David Cournapeau
> wrote:
>
>> Hi,
>>
>> I have investigated further the ABI issues reported for numpy 1.4.0. I
>> can confirm that we have broken the ABI for 1.4.0 compared to 1.3.0
>> (besides the "
On Tue, Jan 26, 2010 at 9:24 PM, David Cournapeau wrote:
> Hi,
>
> I have investigated further the ABI issues reported for numpy 1.4.0. I
> can confirm that we have broken the ABI for 1.4.0 compared to 1.3.0
> (besides the "trivial" cython issue). The good new is that I have found
> the issue, the
Hi,
I have investigated further the ABI issues reported for numpy 1.4.0. I
can confirm that we have broken the ABI for 1.4.0 compared to 1.3.0
(besides the "trivial" cython issue). The good new is that I have found
the issue, the bad news is that I don't know how to (cleanly) fix it.
The probl
Can you post a simple example of this not working?
On Jan 26, 2010, at 1:42 AM, Ross Harder wrote:
> I'm struggling with using some of the macros in numpy.i for my own
> typemap.
> The problem is that the arrayobject.h include does not end up in the c
> wrapper code after swig runs.
> numpy.i h
On 1/26/2010 2:00 PM, Alan G Isaac wrote:
> Is this a fair test?
> I expected shuffle to be much faster
> (no array creation).
> Alan Isaac
>
import timeit
setup = """
> ... import numpy as np
> ... prng = np.random.RandomState()
> ... N = 10**5
> ... indexes = np.arange(N)
> ... """
On Tue, Jan 26, 2010 at 2:00 PM, Alan G Isaac wrote:
> Is this a fair test?
> I expected shuffle to be much faster
> (no array creation).
> Alan Isaac
>
import timeit
setup = """
> ... import numpy as np
> ... prng = np.random.RandomState()
> ... N = 10**5
> ... indexes = np.arange(
Is this a fair test?
I expected shuffle to be much faster
(no array creation).
Alan Isaac
>>> import timeit
>>>
>>> setup = """
... import numpy as np
... prng = np.random.RandomState()
... N = 10**5
... indexes = np.arange(N)
... """
>>>
>>> print timeit.timeit('prng.shuffle(indexes)',setup, numb
Hi Neil,
sure...I aeh, knew this...of course...[?]
I'm using shuffle with a list of indices now...
Thanks,
Jan
<<330.gif>>___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On 2010-01-26 10:22 , Jan Strube wrote:
> Dear Josef and Keith,
>
> thank you both for your suggestions. I think intersect would be what I
> want for it makes clean code.
> I have, however, spotted the problem:
> I was mistakenly under the assumption that random_integers returns
> unique entries, w
Dear Josef and Keith,
thank you both for your suggestions. I think intersect would be what I want
for it makes clean code.
I have, however, spotted the problem:
I was mistakenly under the assumption that random_integers returns unique
entries, which is of course not guaranteed, so that the random
26/01/10 @ 08:59 (-0500), thus spake josef.p...@gmail.com:
> 2010/1/26 Ernest Adrogué :
> > Hi,
> >
> > Do you think it is sensible for np.equal to return a NotImplemented
> > object when is given an array of variable length dtype?
> > Consider this code:
> >
> > x = np.array(['xyz','zyx'])
> > np.
2010/1/26 Ernest Adrogué :
> Hi,
>
> Do you think it is sensible for np.equal to return a NotImplemented
> object when is given an array of variable length dtype?
> Consider this code:
>
> x = np.array(['xyz','zyx'])
> np.where(np.equal(x, 'zyx'), [0,0], [1,1])
>
> the last line returns array([0, 0
Hi,
Do you think it is sensible for np.equal to return a NotImplemented
object when is given an array of variable length dtype?
Consider this code:
x = np.array(['xyz','zyx'])
np.where(np.equal(x, 'zyx'), [0,0], [1,1])
the last line returns array([0, 0]) which is wrong. Compare with
np.where(x
Dear All,
I'm trying to use f2py in order to convert a fortan-file fonctions_f90.f90
I apply the following command line
f2py -m fonctions_f90 --fcompiler=pg -c fonctions_f90.f90
Everything seems to be well, until this error appears :
Pgcc: /tmp/tmp7RvKeA/src.linux-x86_64-2.5/fort
17 matches
Mail list logo
