Thank you for your answers. I guess I will stick to an explicitly defined action then. Not sure if I am the right person to do a clean up. But I guess I can document some functions.
On Saturday, November 25, 2017 at 11:22:50 PM UTC+1, Travis Scrimshaw wrote: > > You do have some flexibility on how you want to implement actions. Some of > this might be more complicated due to the classes you are inheriting from, > including some older code. The easier (but can be more cumbersome and > restrictive) way is to implement either _rmul_ / _lmul_ or _acted_upon_ > (recommended). However, I do not know if that takes precedence over an > explicitly defined action. > > There's a few examples of implementations of actions scattered around Sage > (such as in matrix/action.pyx) if that can help providing what you need > too. As you may have surmised, there is some old code floating around that > could use some cleanup and documentation. > > On Saturday, November 25, 2017 at 3:42:03 AM UTC-6, Simon Brandhorst wrote: >> >> Dear sagers, >> >> I am implementing a matrix group action on a submodule of ZZ^n. >> element*matrix does work but the result lies in the ambient space and >> instead I want the >> elements parent to be the invariant subspace we started with. >> >> This can be done with sage.categories.action.Action >> >> However, that file was created in 2007, and it is almost not documented >> at all. >> Is it the way to go anyways? >> >> Best >> Simon >> > -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
