On Thu, Jun 27, 2019 at 4:19 AM Ilhan Polat wrote:
> I've finally gone through the old discussion and finally got the
> counter-argument in one of the Dag Sverre's replies
> http://numpy-discussion.10968.n7.nabble.com/add-H-attribute-tp34474p34668.html
>
> TL; DR
>
> I disagree with [...adding th
I've finally gone through the old discussion and finally got the
counter-argument in one of the Dag Sverre's replies
http://numpy-discussion.10968.n7.nabble.com/add-H-attribute-tp34474p34668.html
TL; DR
I disagree with [...adding the .H attribute...] being forward looking, as
> it explicitly crea
On Wed, Jun 26, 2019 at 2:18 PM Ralf Gommers wrote:
>
>
> On Wed, Jun 26, 2019 at 10:04 PM Kirill Balunov
> wrote:
>
>> Only concerns #4 from Ilhan's list.
>>
>> ср, 26 июн. 2019 г. в 00:01, Ralf Gommers :
>>
>>>
>>> []
>>>
>>> Perhaps not full consensus between the many people with differen
On Wed, Jun 26, 2019 at 11:24 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi Ralf,
>
> I realize you feel strongly that this whole thread is rehashing history,
>
The .H part was. But Cameron volunteered to work on a solution that
satisfies all concerns.
but I think it is worth p
On Wed, 2019-06-26 at 17:22 -0400, Marten van Kerkwijk wrote:
> Hi Ralf,
>
> I realize you feel strongly that this whole thread is rehashing
> history, but I think it is worth pointing out that many seem to
> consider that the criterion for allowing backward incompatible
> changes, i.e., that "exi
Hi Ralf,
I realize you feel strongly that this whole thread is rehashing history,
but I think it is worth pointing out that many seem to consider that the
criterion for allowing backward incompatible changes, i.e., that "existing
code is buggy or is consistently confusing many users", is actually
On Wed, Jun 26, 2019 at 10:24 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
>
> The main motivation for the @ PEP was actually to be able to get rid of
>> objects like np.matrix and scipy.sparse matrices that redefine the meaning
>> of the * operator. Quote: "This PEP proposes the min
> The main motivation for the @ PEP was actually to be able to get rid of
> objects like np.matrix and scipy.sparse matrices that redefine the meaning
> of the * operator. Quote: "This PEP proposes the minimum effective change
> to Python syntax that will allow us to drain this swamp [meaning np.ma
On Wed, Jun 26, 2019 at 10:04 PM Kirill Balunov
wrote:
> Only concerns #4 from Ilhan's list.
>
> ср, 26 июн. 2019 г. в 00:01, Ralf Gommers :
>
>>
>> []
>>
>> Perhaps not full consensus between the many people with different
>> opinions and interests. But for the first one, arr.T change: it's
Only concerns #4 from Ilhan's list.
ср, 26 июн. 2019 г. в 00:01, Ralf Gommers :
>
> []
>
> Perhaps not full consensus between the many people with different opinions
> and interests. But for the first one, arr.T change: it's clear that this
> won't happen.
>
To begin with, I must admit that
On Wed, Jun 26, 2019 at 6:32 PM Cameron Blocker
wrote:
> A previous discussion of adding a .H operator on the mailing list can be
> found here:
> http://numpy-discussion.10968.n7.nabble.com/add-H-attribute-td34474.html
> that thread refers to an earlier discussion at
> http://thread.gmane.org/gma
A previous discussion of adding a .H operator on the mailing list can be
found here:
http://numpy-discussion.10968.n7.nabble.com/add-H-attribute-td34474.html
that thread refers to an earlier discussion at
http://thread.gmane.org/gmane.comp.python.numeric.general/6637
but that link was broken for me
Dear Ilhan,
Thanks for writing these up.
I feel that from a usability standpoint most people would support #3
(.H/.mH), especially considering Marten's very good argument about @.
Having to wrap your transposed matrices in function calls half defeats
the purpose of being able to write stacked matr
Maybe a bit of a grouping would help, because I am also losing track here.
Let's see if I could manage to get something sensible because, just like
Marten mentioned, I am confusing myself even when I am thinking about this
1- Transpose operation on 1D arrays:
This is a well-known confusion poi
14 matches
Mail list logo
