On Wed, Jun 26, 2019 at 3:56 AM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi Ralf,
>
> On Tue, Jun 25, 2019 at 6:31 PM Ralf Gommers
> wrote:
>
>>
>>
>> On Tue, Jun 25, 2019 at 11:02 PM Marten van Kerkwijk <
>> m.h.vankerkw...@gmail.com> wrote:
>>
>>>
>>> For the names, my suggesti
Hi Ralf,
On Tue, Jun 25, 2019 at 6:31 PM Ralf Gommers wrote:
>
>
> On Tue, Jun 25, 2019 at 11:02 PM Marten van Kerkwijk <
> m.h.vankerkw...@gmail.com> wrote:
>
>>
>> For the names, my suggestion of lower-casing the M in the initial one,
>> i.e., `.mT` and `.mH`, so far seemed most supported (and
On Tue, Jun 25, 2019 at 11:02 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
>
> For the names, my suggestion of lower-casing the M in the initial one,
> i.e., `.mT` and `.mH`, so far seemed most supported (and I think we should
> discuss *assuming* those would eventually involve not c
One other approach here that perhaps treads a little too close to np.matrix:
class MatrixOpWrapper:
def __init__(self, arr): # todo: accept axis arguments here?
self._array = arr # todo: assert that arr.ndim >= 2 / call atleast1d
@property
def T(self):
return linalg.t
On Tue, 2019-06-25 at 17:00 -0400, Marten van Kerkwijk wrote:
> Hi Kirill, others,
>
> Indeed, it is becoming long! That said, while initially I was quite
> charmed by Eric's suggestion of deprecating and then changing `.T`, I
> think the well-argued opposition to it has changed my opinion.
> Perh
Hi Kirill, others,
Indeed, it is becoming long! That said, while initially I was quite charmed
by Eric's suggestion of deprecating and then changing `.T`, I think the
well-argued opposition to it has changed my opinion. Perhaps most
persuasive to me was Matthew's point just now that code (or a cod
On Tue, Jun 25, 2019 at 10:17 PM Kirill Balunov
wrote:
>
> вт, 25 июн. 2019 г. в 21:20, Cameron Blocker :
>
>> It seems to me that the general consensus is that we shouldn't be
>> changing .T to do what we've termed matrix transpose or conjugate
>> transpose.
>>
>
> Reading through this thread, I
вт, 25 июн. 2019 г. в 21:20, Cameron Blocker :
> It seems to me that the general consensus is that we shouldn't be changing
> .T to do what we've termed matrix transpose or conjugate transpose.
>
Reading through this thread, I can not say that I have the same opinion -
at first, many looked posit
Hi,
On Tue, Jun 25, 2019 at 10:57 AM Stephan Hoyer
[snip]
...
> I also agree with Alan that probably it's too late to change the behavior of
> .T for arrays with more than 2-dimensions. NumPy could certainly use a more
> comprehensive policy around backwards compatibility, but we certainly need
On Tue, 2019-06-25 at 14:18 -0400, Cameron Blocker wrote:
> It seems to me that the general consensus is that we shouldn't be
> changing .T to do what we've termed matrix transpose or conjugate
> transpose. As such, the discussion of whether .T should be changed to
> throw errors or warnings on 1D
It seems to me that the general consensus is that we shouldn't be changing
.T to do what we've termed matrix transpose or conjugate transpose. As
such, the discussion of whether .T should be changed to throw errors or
warnings on 1D arrays seems a bit off topic (not that it shouldn't be
discussed).
On Tue, Jun 25, 2019 at 10:14 AM Todd wrote:
> On Tue, Jun 25, 2019 at 11:47 AM Alan Isaac wrote:
>
>> On 6/25/2019 11:03 AM, Todd wrote:
>> > Fair enough. But although there are valid reasons to do a divide by
>> zero, it still causes a warning because it is a problem often enough that
>> peop
I was saying we shouldn't change the default transpose operation to be
conjugate transpose. We don't currently have a conjugate transpose so it
isn't an issue. I think having a conjugate transpose is a great idea, I
just don't think it should be the default.
On Tue, Jun 25, 2019 at 12:12 PM Ilha
On Tue, Jun 25, 2019 at 11:47 AM Alan Isaac wrote:
> On 6/25/2019 11:03 AM, Todd wrote:
> > Fair enough. But although there are valid reasons to do a divide by
> zero, it still causes a warning because it is a problem often enough that
> people should be made aware of it. I
> > think this is a
I think we would have seen a lot of evidence in the last four decades if
this was that problematic.
You are the second person to memtion these bugs. Care to show me some
examples of these bugs?
Maybe I am missing the point here. I haven't seen any bugs because somebody
thought they are just trans
On 6/25/2019 11:03 AM, Todd wrote:
Fair enough. But although there are valid reasons to do a divide by zero, it still causes a warning because it is a problem often enough that people should be made aware of it. I
think this is a similar scenario.
I side with Stephan on this, but when there
On Tue, Jun 25, 2019 at 10:42 AM Stephan Hoyer wrote:
> On Tue, Jun 25, 2019 at 7:20 AM Todd wrote:
>
>> On Tue, Jun 25, 2019 at 9:35 AM Juan Nunez-Iglesias
>> wrote:
>>
>>> On Mon, 24 Jun 2019, at 11:25 PM, Marten van Kerkwijk wrote:
>>>
>>> Just to be sure: for a 1-d array, you'd both conside
I wish this discussion would be clearer that a.T is not going anywhere,
should not change, and in any case should match a.transpose().
Anything else threatens to break existing code for no good payoff.
How many people in this discussion are proposing that a widely used
library like numpy should m
On Tue, Jun 25, 2019 at 7:20 AM Todd wrote:
> On Tue, Jun 25, 2019 at 9:35 AM Juan Nunez-Iglesias
> wrote:
>
>> On Mon, 24 Jun 2019, at 11:25 PM, Marten van Kerkwijk wrote:
>>
>> Just to be sure: for a 1-d array, you'd both consider `.T` giving a shape
>> of `(n, 1)` the right behaviour? I.e., i
On Tue, Jun 25, 2019 at 9:35 AM Juan Nunez-Iglesias
wrote:
> On Mon, 24 Jun 2019, at 11:25 PM, Marten van Kerkwijk wrote:
>
> Just to be sure: for a 1-d array, you'd both consider `.T` giving a shape
> of `(n, 1)` the right behaviour? I.e., it should still change from what it
> is now - which is
That is how it is in your field, but not mine. For us we only use the
conventional transpose, even for complex numbers. And I routinely see bugs
in MATLAB because of its choice of defaults, and there are probably many
more that don't get caught because they happen silently.
I think the principle
Hi Juan,
On Tue, Jun 25, 2019 at 9:35 AM Juan Nunez-Iglesias
wrote:
> On Mon, 24 Jun 2019, at 11:25 PM, Marten van Kerkwijk wrote:
>
> Just to be sure: for a 1-d array, you'd both consider `.T` giving a shape
> of `(n, 1)` the right behaviour? I.e., it should still change from what it
> is now -
On Mon, 24 Jun 2019, at 11:25 PM, Marten van Kerkwijk wrote:
> Just to be sure: for a 1-d array, you'd both consider `.T` giving a shape of
> `(n, 1)` the right behaviour? I.e., it should still change from what it is
> now - which is to leave the shape at `(n,)`.
Just to chime in as a user: v.T
Hi All,
The examples with different notation brought back memory of another
solution: define
`m.ᵀ` and m.ᴴ`. This is possible, since python3 allows any unicode for
names, nicely readable, but admittedly a bit annoying to enter (in emacs,
set-input-method to TeX and then ^T, ^H).
More seriously, s
On Tue, Jun 25, 2019 at 1:03 PM Ilhan Polat wrote:
>
> I have to disagree, I hardly ever saw such bugs
I know the exact behaviour of MATLAB isn't very relevant for this
discussion, but anyway the reason I think this is a problem in MATLAB
is that there are a bunch of confused questions on Stack
I have to disagree, I hardly ever saw such bugs and moreover is
not compatible if you don't also transpose it but expected in almost all
contexts of matrices, vectors and scalars. Elementwise conjugation is well
inline with other elementwise operations starting with a dot in matlab
hence still con
On Tue, Jun 25, 2019 at 4:29 AM Cameron Blocker
wrote:
>
> In my opinion, the matrix transpose operator and the conjugate transpose
> operator should be one and the same. Something nice about both Julia and
> MATLAB is that it takes more keystrokes to do a regular transpose instead of
> a conju
27 matches
Mail list logo
