Coercion naming question
Robert Bradshaw
implemented, and used by other people. Before it gets to popular, I
would like to propose an api change.
Currently, if A has an action on B (where B is not an A-module) one
implements either a._l_action_ or b._r_action_. This is because
sometimes it makes sense to put the method on the actor (e.g. Galois
groups acting on field elements) and sometimes on the acted on (e.g.
matrices acting on quadratic forms). However, the _x_action_ is hard
to remember and doesn't always correspond to right/left actions. This
may be why they're hardly used up to this point.
The proposal is to make the methods a._act_on_(b, self_on_left) and
b._acted_upon_(a, self_on_left). In other words, a*b would try
"a._act_on_(b, True)" and "b._acted_upon_(a, False)". This wouldn't
be a fundamental change on how things work, just mainly a naming
change, but I though it would be a good idea to run it by here.
- Robert
Jason Grout
So if I'm being confusing (or wrong!) here, tell me. Right now, a
vector*matrix is thought of as a matrix acting on the vector, right?
(This might be where I'm confused because I'm too used to matrix*vector
constructs.) But then the above would force that this would be
contained in the vector._act_on_ or the matrix._acted_upon_ methods,
right? This seems backwards...
Thanks,
Jason
Robert Bradshaw
> Robert Bradshaw wrote:
>> I'm glad the coercion model is starting to get discussed,
>> implemented, and used by other people. Before it gets to popular, I
>> would like to propose an api change.
>>
>> Currently, if A has an action on B (where B is not an A-module) one
>> implements either a._l_action_ or b._r_action_. This is because
>> sometimes it makes sense to put the method on the actor (e.g. Galois
>> groups acting on field elements) and sometimes on the acted on (e.g.
>> matrices acting on quadratic forms). However, the _x_action_ is hard
>> to remember and doesn't always correspond to right/left actions. This
>> may be why they're hardly used up to this point.
>>
>> The proposal is to make the methods a._act_on_(b, self_on_left) and
>> b._acted_upon_(a, self_on_left). In other words, a*b would try
>> "a._act_on_(b, True)" and "b._acted_upon_(a, False)". This wouldn't
>> be a fundamental change on how things work, just mainly a naming
>> change, but I though it would be a good idea to run it by here.
>
>
> So if I'm being confusing (or wrong!) here, tell me. Right now, a
> vector*matrix is thought of as a matrix acting on the vector, right?
> (This might be where I'm confused because I'm too used to
> matrix*vector
> constructs.)
Yes.
> But then the above would force that this would be
> contained in the vector._act_on_ or the matrix._acted_upon_ methods,
> right? This seems backwards...
It would be implemented in the matrix._act_on_ or vector._acted_upon_
methods. (Though in this case there is an actual "Action" object
defined in http://hg.sagemath.org/sage-main/file/b0aa7ef45b3c/sage/
matrix/action.pyx that is used, and MatrixSpace implements
_get_action_).
- Robert
Georg S. Weber
On 12 Mrz., 21:09, Robert Bradshaw <rober...@math.washington.edu>
wrote:
Cheers,
gsw
>
> - Robert
Craig Citro
> b._acted_upon_(a, self_on_left). In other words, a*b would try
> "a._act_on_(b, True)" and "b._acted_upon_(a, False)". This wouldn't
> be a fundamental change on how things work, just mainly a naming
> change, but I though it would be a good idea to run it by here.
>
+1.
-cc
Nick Alexander
> b._acted_upon_(a, self_on_left). In other words, a*b would try
> "a._act_on_(b, True)" and "b._acted_upon_(a, False)". This wouldn't
> be a fundamental change on how things work, just mainly a naming
> change, but I though it would be a good idea to run it by here.
+1 -- I would very much like to implement the action of Frobenius on
finite field elements and have no idea how to do it at the moment :)
I also want to have matrices act on Siegel upper half space and theta
characteristics, etc. I could hang the action code on the point of
Siegel upper half space, implementing _acted_upon_, and not need to
touch matrices, right? That would be good.
Nick
Robert Bradshaw
>> The proposal is to make the methods a._act_on_(b, self_on_left) and
>> b._acted_upon_(a, self_on_left). In other words, a*b would try
>> "a._act_on_(b, True)" and "b._acted_upon_(a, False)". This wouldn't
>> be a fundamental change on how things work, just mainly a naming
>> change, but I though it would be a good idea to run it by here.
>
> +1 -- I would very much like to implement the action of Frobenius on
> finite field elements and have no idea how to do it at the moment :)
Hopefully the documentation will improve to the point that it's
really obvious.
> I also want to have matrices act on Siegel upper half space and theta
> characteristics, etc. I could hang the action code on the point of
> Siegel upper half space, implementing _acted_upon_, and not need to
> touch matrices, right? That would be good.
That's exactly the point.
- Robert