Thank you. I didn't know that it existed. Is there any place where I can get a feeling for a sane priority number compared to what's being done in production? Just to make sure I'm not stepping on any toes.
On Mon, Jun 19, 2017 at 5:36 PM, Stephan Hoyer <sho...@gmail.com> wrote: > 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 <ilhanpo...@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@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 > >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
