On Thu, Sep 11, 2014 at 11:09 PM, Nathaniel Smith wrote:
> On Thu, Sep 11, 2014 at 11:18 PM, Charles R Harris
> wrote:
> >
> > On Thu, Sep 11, 2014 at 8:49 PM, Nathaniel Smith wrote:
> >>
> >> On Thu, Sep 11, 2014 at 10:12 PM, Charles R Harris
> >> wrote:
> >> >
> >> > On Thu, Sep 11, 2014 at
On Thu, Sep 11, 2014 at 11:18 PM, Charles R Harris
wrote:
>
> On Thu, Sep 11, 2014 at 8:49 PM, Nathaniel Smith wrote:
>>
>> On Thu, Sep 11, 2014 at 10:12 PM, Charles R Harris
>> wrote:
>> >
>> > On Thu, Sep 11, 2014 at 8:01 PM, Nathaniel Smith wrote:
>> >>
>> >> On Thu, Sep 11, 2014 at 12:10 PM
On Thu, Sep 11, 2014 at 8:49 PM, Nathaniel Smith wrote:
> On Thu, Sep 11, 2014 at 10:12 PM, Charles R Harris
> wrote:
> >
> > On Thu, Sep 11, 2014 at 8:01 PM, Nathaniel Smith wrote:
> >>
> >> On Thu, Sep 11, 2014 at 12:10 PM, Charles R Harris
> >> wrote:
> >> >
> >> > On Wed, Sep 10, 2014 at 1
On Thu, Sep 11, 2014 at 10:12 PM, Charles R Harris
wrote:
>
> On Thu, Sep 11, 2014 at 8:01 PM, Nathaniel Smith wrote:
>>
>> On Thu, Sep 11, 2014 at 12:10 PM, Charles R Harris
>> wrote:
>> >
>> > On Wed, Sep 10, 2014 at 10:08 PM, Nathaniel Smith wrote:
>> >>
>> >> My vote is:
>> >>
>> >> __matmu
On Thu, Sep 11, 2014 at 8:01 PM, Nathaniel Smith wrote:
> On Thu, Sep 11, 2014 at 12:10 PM, Charles R Harris
> wrote:
> >
> > On Wed, Sep 10, 2014 at 10:08 PM, Nathaniel Smith wrote:
> >>
> >> My vote is:
> >>
> >> __matmul__/__rmatmul__ do the standard dispatch stuff that all __op__
> >> metho
On Thu, Sep 11, 2014 at 7:47 PM, Charles R Harris wrote:
>
>
> On Thu, Sep 11, 2014 at 10:10 AM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Wed, Sep 10, 2014 at 10:08 PM, Nathaniel Smith wrote:
>>
>>> On Wed, Sep 10, 2014 at 4:53 PM, Charles R Harris
>>> wrote:
>>> >
>
On Thu, Sep 11, 2014 at 12:10 PM, Charles R Harris
wrote:
>
> On Wed, Sep 10, 2014 at 10:08 PM, Nathaniel Smith wrote:
>>
>> My vote is:
>>
>> __matmul__/__rmatmul__ do the standard dispatch stuff that all __op__
>> methods do (so I guess check __array_priority__ or whatever it is we
>> always do
On Thu, Sep 11, 2014 at 10:10 AM, Charles R Harris <
charlesr.har...@gmail.com> wrote:
>
>
> On Wed, Sep 10, 2014 at 10:08 PM, Nathaniel Smith wrote:
>
>> On Wed, Sep 10, 2014 at 4:53 PM, Charles R Harris
>> wrote:
>> >
>> > On Wed, Sep 10, 2014 at 10:52 AM, Pauli Virtanen wrote:
>> >>
>> >> 09
On Wed, Sep 10, 2014 at 10:08 PM, Nathaniel Smith wrote:
> On Wed, Sep 10, 2014 at 4:53 PM, Charles R Harris
> wrote:
> >
> > On Wed, Sep 10, 2014 at 10:52 AM, Pauli Virtanen wrote:
> >>
> >> 09.09.2014, 22:52, Charles R Harris kirjoitti:
> >> > 1. Should the operator accept array_like for on
On Wed, Sep 10, 2014 at 4:53 PM, Charles R Harris
wrote:
>
> On Wed, Sep 10, 2014 at 10:52 AM, Pauli Virtanen wrote:
>>
>> 09.09.2014, 22:52, Charles R Harris kirjoitti:
>> > 1. Should the operator accept array_like for one of the arguments?
>> > 2. Does it need to handle __numpy_ufunc__, or
Charles R Harris wrote:
> Note also that the dot cblas versions are not generally blocked, so the
> size of the arrays is limited (and not checked).
But it is possible to create a blocked dot function with the current cblas,
even though they use C int for array dimensions. It would just further
On Wed, Sep 10, 2014 at 2:53 PM, Charles R Harris wrote:
>
>
> On Wed, Sep 10, 2014 at 10:52 AM, Pauli Virtanen wrote:
>
>> 09.09.2014, 22:52, Charles R Harris kirjoitti:
>> > 1. Should the operator accept array_like for one of the arguments?
>> > 2. Does it need to handle __numpy_ufunc__, o
On Wed, Sep 10, 2014 at 10:52 AM, Pauli Virtanen wrote:
> 09.09.2014, 22:52, Charles R Harris kirjoitti:
> > 1. Should the operator accept array_like for one of the arguments?
> > 2. Does it need to handle __numpy_ufunc__, or will
> > __array_priority__ serve?
>
> I think the __matmul__ ope
09.09.2014, 22:52, Charles R Harris kirjoitti:
> 1. Should the operator accept array_like for one of the arguments?
> 2. Does it need to handle __numpy_ufunc__, or will
> __array_priority__ serve?
I think the __matmul__ operator implementation should follow that of
__mul__.
[clip]
>3. D
On Di, 2014-09-09 at 13:52 -0600, Charles R Harris wrote:
> Hi All,
>
>
> I'm in the midst of implementing the '@' operator (PEP 465), and there
> are some behaviors that are unspecified by the PEP.
>
> 1. Should the operator accept array_like for one of the
> arguments?
To be in l
On Tue, Sep 9, 2014 at 8:52 PM, Charles R Harris
wrote:
> Hi All,
>
> I'm in the midst of implementing the '@' operator (PEP 465), and there are
> some behaviors that are unspecified by the PEP.
>
> Should the operator accept array_like for one of the arguments?
I would be mildly disappointed if
Hi All,
I'm in the midst of implementing the '@' operator (PEP 465), and there are
some behaviors that are unspecified by the PEP.
1. Should the operator accept array_like for one of the arguments?
2. Does it need to handle __numpy_ufunc__, or will __array_priority__
serve?
3. Do we
On 3/16/11 9:22 AM, Paul Anton Letnes wrote:
>> This comes up for discussion on a fairly regular basis. I tend towards the
>> more warnings side myself, but you aren't going to get the current behavior
>> changed unless you can convince a large bunch of people that it is the right
>> thing to d
>
> This comes up for discussion on a fairly regular basis. I tend towards the
> more warnings side myself, but you aren't going to get the current behavior
> changed unless you can convince a large bunch of people that it is the right
> thing to do, which won't be easy. For one thing, a lot of
On Wed, Mar 16, 2011 at 8:58 AM, Paul Anton Letnes <
paul.anton.let...@gmail.com> wrote:
>
> On 16. mars 2011, at 15.49, Chris Barker wrote:
>
> > On 3/16/11 6:34 AM, Charles R Harris wrote:
> >> On Wed, Mar 16, 2011 at 7:24 AM, Paul Anton Letnes
> >
> >> Yes, it is intentional. Numpy is more C th
On 16. mars 2011, at 15.57, Dag Sverre Seljebotn wrote:
> On 03/16/2011 02:35 PM, Paul Anton Letnes wrote:
>> Heisann!
>
> Hei der,
>
>> On 16. mars 2011, at 14.30, Dag Sverre Seljebotn wrote:
>>
>>> On 03/16/2011 02:24 PM, Paul Anton Letnes wrote:
Hi!
This little snippet of co
On 16. mars 2011, at 15.49, Chris Barker wrote:
> On 3/16/11 6:34 AM, Charles R Harris wrote:
>> On Wed, Mar 16, 2011 at 7:24 AM, Paul Anton Letnes
>
>> Yes, it is intentional. Numpy is more C than Python in this case,
>
> I don't know that C has anything to do with it -- the *= operators were
On 03/16/2011 02:35 PM, Paul Anton Letnes wrote:
> Heisann!
Hei der,
> On 16. mars 2011, at 14.30, Dag Sverre Seljebotn wrote:
>
>> On 03/16/2011 02:24 PM, Paul Anton Letnes wrote:
>>> Hi!
>>>
>>> This little snippet of code tricked me (in a more convoluted form). The *=
>>> operator does not ch
On 3/16/11 6:34 AM, Charles R Harris wrote:
> On Wed, Mar 16, 2011 at 7:24 AM, Paul Anton Letnes
> Yes, it is intentional. Numpy is more C than Python in this case,
I don't know that C has anything to do with it -- the *= operators were
added specifically to be "in-place" operators -- otherwise
On Wed, Mar 16, 2011 at 7:24 AM, Paul Anton Letnes <
paul.anton.let...@gmail.com> wrote:
> Hi!
>
> This little snippet of code tricked me (in a more convoluted form). The *=
> operator does not change the datatype of the left hand side array. Is this
> intentional? It did fool me and throw my resu
Heisann!
On 16. mars 2011, at 14.30, Dag Sverre Seljebotn wrote:
> On 03/16/2011 02:24 PM, Paul Anton Letnes wrote:
>> Hi!
>>
>> This little snippet of code tricked me (in a more convoluted form). The *=
>> operator does not change the datatype of the left hand side array. Is this
>> intention
On 03/16/2011 02:24 PM, Paul Anton Letnes wrote:
> Hi!
>
> This little snippet of code tricked me (in a more convoluted form). The *=
> operator does not change the datatype of the left hand side array. Is this
> intentional? It did fool me and throw my results quite a bit off. I always
> assume
On 16 March 2011 09:24, Paul Anton Letnes wrote:
> Hi!
>
> This little snippet of code tricked me (in a more convoluted form). The *=
> operator does not change the datatype of the left hand side array. Is this
> intentional? It did fool me and throw my results quite a bit off. I always
> assum
Hi!
This little snippet of code tricked me (in a more convoluted form). The *=
operator does not change the datatype of the left hand side array. Is this
intentional? It did fool me and throw my results quite a bit off. I always
assumed that 'a *= b' means exactly the same as 'a = a * b' but th
29 matches
Mail list logo