I find the MatrixSpace example interesting: sage: R = MatrixSpace(QQ, 1) sage: P = PolynomialRing(R, names="z") sage: Q = PolynomialRing(QQ, names="z") sage: Q.gen() * P.gen() [z]*z sage: P.gen() * Q.gen() [z]*z sage: coercion_model.analyse(P.gen(), Q.gen(), operator.mul) (['Action discovered.', Right scalar multiplication by Univariate Polynomial Ring in z over Rational Field on Univariate Polynomial Ring in z over Full MatrixSpace of 1 by 1 dense matrices over Rational Field], Univariate Polynomial Ring in z over Full MatrixSpace of 1 by 1 dense matrices over Univariate Polynomial Ring in z over Rational Field)
So, the action of QQ[z] on Mat_n(QQ) [z] returns something in Mat_n(QQ[z]) [z]. Where are these actions are actually coded? I am currently trying to figure out what ModuleAction.__init__ is doing. Martin On Saturday 13 January 2024 at 10:13:03 UTC+1 Martin R wrote: > How can I find out what causes this? How can I find out where this action > is defined? > > I played around a little, but without any insights. It seems that most of > the time, the coercion tries to do the embedding in the base ring, but not > always. The MatrixSpace seems to be another exception. > > I admit, it does look odd to me, because we usually treat variable names > as the distinguishing feature of polynomial rings, don't we? > > Martin > > def test(R): > """ > sage: test(QQ) > z^2 > sage: test(ZZ) > z^2 > sage: test(PolynomialRing(ZZ, "a")) > z^2 > sage: test(PolynomialRing(ZZ, "a, b")) > z^2 > sage: test(SymmetricFunctions(QQ).s()) > s[]*z^2 > > sage: test(MatrixSpace(QQ, 2)) > [z 0] > [0 z]*z > sage: test(PolynomialRing(ZZ, "z")) > z*z > sage: test(InfinitePolynomialRing(QQ, "a")) > z*z > > """ > P = PolynomialRing(R, names="z") > p = P.gen() > Q = PolynomialRing(QQ, names="z") > q = Q.gen() > return p*q > > On Saturday 13 January 2024 at 00:30:02 UTC+1 Nils Bruin wrote: > >> This might be at fault: >> >> sage: coercion_model.analyse(q,e) >> (['Action discovered.', >> Left scalar multiplication by Multivariate Polynomial Ring in z, q over >> Rational Field on Multivariate Polynomial Ring in z, q over Infinite >> polynomial ring in F over Rational Field], >> Multivariate Polynomial Ring in z, q over Infinite polynomial ring in F >> over Multivariate Polynomial Ring in z, q over Rational Field) >> >> it looks like somehow an action is found before "common parent" >> multiplication is used. >> >> >> >> On Friday 12 January 2024 at 17:24:00 UTC-5 Martin R wrote: >> >> I am not quite sure I understand how this works / what is used: >> >> sage: pushout(e.parent(), z.parent()) >> Multivariate Polynomial Ring in z, q over Infinite polynomial ring in F >> over Multivariate Polynomial Ring in z, q over Rational Field >> sage: coercion_model.common_parent(z, e) >> Multivariate Polynomial Ring in z, q over Infinite polynomial ring in F >> over Rational Field >> >> Martin >> On Friday 12 January 2024 at 22:47:49 UTC+1 Martin R wrote: >> >> Hm, that's somewhat unfortunate - I don't see how to work around it. I >> guess I would have to force all elements to be in P (using the notation of >> the example), but this is, I think, not possible. >> >> Do you know where this behaviour is determined? >> >> On Friday 12 January 2024 at 22:09:41 UTC+1 Nils Bruin wrote: >> >> On Friday 12 January 2024 at 14:30:06 UTC-5 Martin R wrote: >> >> I made a tiny bit of progress, and now face the following problem: >> >> sage: I.<F> = InfinitePolynomialRing(QQ) >> sage: P.<z, q> = I[] >> sage: e = z*q >> sage: Q.<z, q> = QQ[] >> sage: z*e >> z*z*q >> >> Is this correct behaviour? >> >> I don't think it's desperately wrong. To sage, these structures look like: >> >> sage: P.construction() >> (MPoly[z,q], Infinite polynomial ring in F over Rational Field) >> sage: Q.construction() >> (MPoly[z,q], Rational Field) >> sage: parent(z*e).construction() >> (MPoly[z,q], >> Infinite polynomial ring in F over Multivariate Polynomial Ring in z, q >> over Rational Field) >> >> Note that an "infinite polynomial ring" is a different object than an >> MPoly, and obviously it has different rules/priorities for finding common >> overstructures. >> >> >> -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/36a823cc-c0b2-48ef-92c1-9e35a58db77an%40googlegroups.com.
