Hi,
>> 'Talk is cheap, show me the code' .
>
> Yes, let's.
>
> First we want to initialize memory mapped arrays which will be used for
> the variables. This python script does that:
Ah - no - sorry - I was suggesting you write an implementation of the
object you want, in numpy. I am sure that wa
On Fri, Oct 8, 2010 at 11:47 AM, Andrew P. Mullhaupt
wrote:
> On 10/7/2010 8:21 PM, Robert Kern wrote:
>> On Thu, Oct 7, 2010 at 18:46, Andrew P. Mullhaupt
>> wrote:
>
>> It appears that your answer is YES, we COULD have that, BUT it would be
>> a lot of work.
>> You misread him. The answer is
On 10/7/2010 8:21 PM, Robert Kern wrote:
> On Thu, Oct 7, 2010 at 18:46, Andrew P. Mullhaupt
> wrote:
> It appears that your answer is YES, we COULD have that, BUT it would be
> a lot of work.
> You misread him. The answer is "no." We will not change the memory
> model so incompatibly. There i
On 10/7/2010 6:52 PM, Matthew Brett wrote:
> Hi,
>
> On Thu, Oct 7, 2010 at 3:47 PM, Andrew P. Mullhaupt
> wrote:
>>> Most machines now
>>> and in the future are not going to choke on these issues (for a variety
>>> of reasons).
> 'Talk is cheap, show me the code' .
Yes, let's.
First we want
On 7 October 2010 19:46, Andrew P. Mullhaupt wrote:
> It wouldn't be the first time I suggested rewriting the select and
> choose operations. I spent months trying to get Guido to let anything
> more than slice indexing in arrays. And now, in the technologically
> advanced future, we can index a
On Thu, Oct 7, 2010 at 18:46, Andrew P. Mullhaupt wrote:
> On 10/7/2010 5:14 PM, Pauli Virtanen wrote:
>> to, 2010-10-07 kello 15:38 -0400, Andrew P. Mullhaupt kirjoitti:
>> [clip]
>>> On 10/7/2010 1:01 PM, Pauli Virtanen wrote:
to, 2010-10-07 kello 12:08 -0400, Andrew P. Mullhaupt kirjoitti
On 10/7/2010 5:14 PM, Pauli Virtanen wrote:
> to, 2010-10-07 kello 15:38 -0400, Andrew P. Mullhaupt kirjoitti:
> [clip]
>> On 10/7/2010 1:01 PM, Pauli Virtanen wrote:
>>> to, 2010-10-07 kello 12:08 -0400, Andrew P. Mullhaupt kirjoitti:
>>> [clip]
>>> But to implement this, you'd have to rewrite l
On 10/7/2010 4:50 PM, Christopher Barker wrote:
> Most of the features of numpy were in fact carefully designed for good
> reason
I was around back in those days. I know a bit about the design process
of which you speak.
> In [22]: a = np.array((5,6), dtype=np.int32)
>
> In [26]: a += 1.2
>
> I
Hi,
On Thu, Oct 7, 2010 at 3:47 PM, Andrew P. Mullhaupt
wrote:
> On 10/7/2010 3:48 PM, Anne Archibald wrote:
>>
>> Years ago MATLAB did just this - store real and complex parts of
>> arrays separately (maybe it still does, I haven't used it in a long
>> time). It caused us terrible performance h
On 10/7/2010 3:48 PM, Anne Archibald wrote:
>
> Years ago MATLAB did just this - store real and complex parts of
> arrays separately (maybe it still does, I haven't used it in a long
> time). It caused us terrible performance headaches,
Years ago performance headaches from Matlab are not exactly
Thu, 07 Oct 2010 18:02:43 -0400, Andrew P. Mullhaupt wrote:
> On 10/7/2010 3:45 PM, josef.p...@gmail.com wrote:
>> what's your namespace?from scipy import log
> log(int(-2))
>> (0.69314718055994529+3.1415926535897931j)
>
> This should explain:
> >>> R = ones(2)
> >>> R[0] = R[0] * 1j
> >>> R
>
On 10/7/2010 3:45 PM, josef.p...@gmail.com wrote:
> what's your namespace?from scipy import log
log(int(-2))
> (0.69314718055994529+3.1415926535897931j)
This should explain:
and...@flyer:~$ python
Enthought Python Distribution -- http://www.enthought.com
Version: 6.2-2 (64-bit)
Python 2.6
to, 2010-10-07 kello 15:38 -0400, Andrew P. Mullhaupt kirjoitti:
[clip]
> On 10/7/2010 1:01 PM, Pauli Virtanen wrote:
> > to, 2010-10-07 kello 12:08 -0400, Andrew P. Mullhaupt kirjoitti:
> > [clip]
> > But to implement this, you'd have to rewrite large parts of Numpy since
> > the separated storage
First:
Wow! what a rude post. I'm not a significant contributer to numpy, but
that was really offensive to me.
Most of the features of numpy were in fact carefully designed for good
reason -- they may not match your use case well, but that does not mean
that they are not good design decisions.
On 7 October 2010 13:01, Pauli Virtanen wrote:
> to, 2010-10-07 kello 12:08 -0400, Andrew P. Mullhaupt kirjoitti:
> [clip]
>> No. You can define the arrays as backed by mapped files with real and
>> imaginary parts separated. Then the imaginary part, being initially
>> zero, is a sparse part of th
On Thu, Oct 7, 2010 at 3:38 PM, Andrew P. Mullhaupt
wrote:
> On 10/7/2010 1:01 PM, Pauli Virtanen wrote:
>> to, 2010-10-07 kello 12:08 -0400, Andrew P. Mullhaupt kirjoitti:
>> [clip]
>> But to implement this, you'd have to rewrite large parts of Numpy since
>> the separated storage of re/im confl
On 10/7/2010 1:01 PM, Pauli Virtanen wrote:
> to, 2010-10-07 kello 12:08 -0400, Andrew P. Mullhaupt kirjoitti:
> [clip]
> But to implement this, you'd have to rewrite large parts of Numpy since
> the separated storage of re/im conflicts with its memory model.
You wouldn't want to rewrite any of
to, 2010-10-07 kello 12:08 -0400, Andrew P. Mullhaupt kirjoitti:
[clip]
> No. You can define the arrays as backed by mapped files with real and
> imaginary parts separated. Then the imaginary part, being initially
> zero, is a sparse part of the file, takes only a fraction of the
> space (and, o
On 10/7/2010 1:31 AM, Charles R Harris wrote:
On Wed, Oct 6, 2010 at 11:07 PM, Andrew P. Mullhaupt
mailto:d...@zen-pharaohs.com>> wrote:
I came across this gem yesterday
>>> from numpy import *
>>> R = ones((2))
>>> R[0] = R[0] * 1j
>>> R
On Wed, Oct 6, 2010 at 11:07 PM, Andrew P. Mullhaupt
wrote:
>
> I came across this gem yesterday
> >>> from numpy import *
> >>> R = ones((2))
> >>> R[0] = R[0] * 1j
> >>> R
> ...array([ 0., 1.])
> >>> R = ones((2), 'complex')
> >>> R[0] = R[0] * 1j
> >>> R
> array([ 0.+1.j, 1.+0.j])" and I read t
On 10/7/2010 1:14 AM, sicre wrote:
>
>
> Andrew P. Mullhaupt wrote:
>> (assigning complex value to real array)
> Sorry, but this post is in the wrong topic since it has nothing to do with
> my question.
How did this happen? I created a new subject.
Best regards,
Andrew Mullhaupt
___
Andrew P. Mullhaupt wrote:
>
>
> I came across this gem yesterday
>
>
> > >> from numpy import *
> > >> R = ones((2))
> > >> R[0] = R[0] * 1j
> > >> R
> ...array([ 0., 1.])
> > >> R = ones((2), 'complex')
> > >> R[0] = R[0] * 1j
> > >> R
>
I came across this gem yesterday
> >> from numpy import *
> >> R = ones((2))
> >> R[0] = R[0] * 1j
> >> R
...array([ 0., 1.])
> >> R = ones((2), 'complex')
> >> R[0] = R[0] * 1j
> >> R
array([ 0.+1.j, 1.+0.j])"
and I read that this behavior is actua
23 matches
Mail list logo
