On Tue, Oct 30, 2018 at 12:49 AM Eric Wieser <wieser.eric+numpy@gmail.com> wrote:

The latter - changing the behavior of multiplication breaks the principle.

But this is not the main reason for deprecating matrix - almost all of the problems I’ve seen have been caused by the way that matrices behave when sliced. The way that m[i][j] and m[i,j] are different is just one example of this, the fact that they must be 2d is another.

Matrices behaving differently on multiplication isn’t super different in my mind to how string arrays fail to multiply at all.

The difference is that string arrays are not numeric. This is an issue since people want to pass a matrix Into places that want to multiple element wise but that then breaks that code unless special provisions are taken. Numerical codes don’t work on string arrays anyway.

Eric

Eric

On Mon, 29 Oct 2018 at 20:54 Ralf Gommers <ralf.gommers@gmail.com> wrote:

On Mon, Oct 29, 2018 at 4:31 PM Chris Barker <chris.barker@noaa.gov> wrote:
On Fri, Oct 26, 2018 at 7:12 PM, Travis Oliphant <teoliphant@gmail.com> wrote:

agree that we can stop bashing subclasses in general. The problem with numpy subclasses is that they were made without adherence to SOLID: https://en.wikipedia.org/wiki/SOLID. In particular the Liskov substitution principle: https://en.wikipedia.org/wiki/Liskov_substitution_principle .

...

did not properly apply them in creating np.matrix which clearly violates the substitution principle.

So -- could a matrix subclass be made "properly"? or is that an example of something that should not have been a subclass?

The latter - changing the behavior of multiplication breaks the principle.

Ralf

_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion