#19613: Implement basic representations of semigroups
-------------------------------------+-------------------------------------
Reporter: tscrim | Owner: sage-combinat
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-7.1
Component: group theory | Resolution:
Keywords: representation, | Merged in:
semigroups, | Reviewers:
Authors: Travis Scrimshaw | Work issues:
Report Upstream: N/A | Commit:
Branch: | 38529351ae5581559a6a33a6fc6fe825b974ef81
public/representations/basic_implementation-19613| Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by tscrim):
Replying to [comment:11 darij]:
> I've reviewed the ticket up to `TrivialRepresentation`.
Thank you for doing the review. (I guess I should review your face
semigroup ticket...)
> However, exposing `self._module` the way I've done it is incompatible
with your implementation of `TrivialRepresentation`, and this is a design
question I feel is in need of discussion. What do you think is the right
way?
>
> 1. Unexpose `self._module`, since any method that uses linear algebra on
`self._module` can just as well use it on `self`.
>
> 2. Set `self._module = self` for a `TrivialRepresentation`.
>
> 3. Implement `TrivialRepresentation` using the general `Representation`
constructor.
I would go with 1. I did not expose it because the representation behaves
like a module (you better not say something about ducktyping here) and it
is there only for internal use. You're getting to one of the reasons why
`TrivialRepresentation` is not a subclass of `Representation`. If you
really feel that it should be exposed, then I would have `module()` return
`self` so there is a consistent API. (Unfortunately I don't think we have
the infrastructure in place to setup the necessary coercions.)
> Speaking of endless loops, do you have an idea why this gives one?
> {{{
> sage: G = groups.permutation.Dihedral(4)
> sage: R = G.regular_representation(left=False)
> sage: x = R.an_element()
> sage: x*x
> }}}
No, and from the code, there does not seem to be a reason why this should
happen. (This should result in an error though.) I will investigate this.
> Oh, and one more thing. I think `TrivialRepresentation` might need a
`left` option. Even if the action itself doesn't care, future code might
(e.g., taking the direct sum of two representations might start off by
checking whether both have the same left-right-ness, and tada you've got a
pointless error when you try to add a right representation to the trivial
one).
If future code cares, then the future code can deal with creating the
error/extra complexity. However, we can consider it as simultaneously a
right and left representation, so I don't think this would be an issue.
Actually, given these recent changes, it reminded me why I had
`left_repr`. I actually think `left_repr` is more descriptive, and so we
should change all of the `left` to `left_repr`. Your thoughts?
--
Ticket URL: <http://trac.sagemath.org/ticket/19613#comment:12>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
