#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 darij):
Replying to [comment:12 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...)
I think that's already (almost) done, but thank you :)
> 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.)
Wait, what? `TrivialRepresentation` does not inherit from
`Representation`? This I really don't like. Particularly if you don't
expose `self._module`, there should be no reason to keep the trivial one
out of it.
I have thought about these things again and here are my suggestions:
S1. It is fine for `Representation` to treat `self._module` as an
implementation detail that might not get inherited, but please document
this in the `init` sourcecode (just a # comment saying that `self._module`
might not exist).
S2. Please document in the docstring that the trivial representation is
both left and right.
S3. At some point we will need a way to tell if a given representation is
left or right. I think this should be a property (not underscored) which
is a boolean or `None` (for two-sided). Do you agree?
S4. In the `_acted_upon_` of `TrivialRepresentation`, does `_from_dict(d)`
do the right thing when `d == 0` ?
> > 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.
Yes, it should result in an error, just not in an exceeded recursion
limit. Not a bug per se, but hell does it smell fishy. Then again, a quick
look at the implementation of coercion in `parent.pyx` convinced me to be
amazed at the fact that coercion works at all...
> 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.
Agreed -- just wanting it to be explicit.
> 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?
I'm fine with `left_repr` or with anything, as long as it is the same
keyword everywhere.
--
Ticket URL: <http://trac.sagemath.org/ticket/19613#comment:13>
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.
