[Numpy-discussion] Controlling NumPy __mul__ method or forcing it to use __rmul__ of the "other"

[Stephan Hoyer]

I answered your question on StackOverflow:
https://stackoverflow.com/questions/40694380/forcing-multiplication-to-use-rmul-instead-of-numpy-array-mul-or-byp/44634634#44634634

In brief, you need to set __array_priority__ or __array_ufunc__ on your
object.

On Mon, Jun 19, 2017 at 5:27 AM, Ilhan Polat <ilhanpolat at gmail.com> wrote:

> I will assume some simple linear systems knowledge but the question can be
> generalized to any operator that implements __mul__ and __rmul__ methods.
>
> Motivation:
>
> I am trying to implement a gain matrix, say 3x3 identity matrix, for time
> being with a single input single output (SISO) system that I have
> implemented as a class modeling a Transfer or a state space representation.
>
> In the typical usecase, suppose you would like to create an n-many
> parallel connections with the same LTI system sitting at each branch.
> MATLAB implements this as an elementwise multiplication and returning a
> multi input multi output(MIMO) system.
>
> G = tf(1,[1,1]);
> eye(3)*G
>
> produces (manually compactified)
>
> ans =
>
>   From input 1 to output...
>    [    1                          ]
>    [  ------    ,   0   ,     0    ]
>    [  s + 1                        ]
>    [                 1             ]
>    [  0        ,   ------ ,   0    ]
>    [               s + 1           ]
>    [                          1    ]
>    [  0        ,   0    ,  ------  ]
>    [                        s + 1  ]
>
> Notice that the result type is of LTI system but, in our context, not a
> NumPy array with "object" dtype.
>
> In order to achieve a similar behavior, I would like to let the __rmul__
> of G take care of the multiplication. In fact, when I do
> G.__rmul__(np.eye(3)) I can control what the behavior should be and I
> receive the exception/result I've put in. However the array never looks for
> this method and carries out the default array __mul__ behavior.
>
> The situation is similar if we go about it as left multiplication G*eye(3)
> has no problems since this uses directly the __mul__ of G. Therefore we get
> a different result depending on the direction of multiplication.
>
> Is there anything I can do about this without forcing users subclassing or
> just letting them know about this particular quirk in the documentation?
>
> What I have in mind is to force the users to create static LTI objects and
> then multiply and reject this possibility. But then I still need to stop
> NumPy returning "object" dtyped array to be able to let the user know about
> this.
>
>
> Relevant links just in case
>
> the library : https://github.com/ilayn/harold/
>
> the issue discussion (monologue actually) : https://github.com/ilayn/
> harold/issues/7
>
> The question I've asked on SO (but with a rather offtopic answer):
> https://stackoverflow.com/q/40694380/4950339
>
>
> ilhan
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20170619/f1c7733f/attachment.html>