#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:13 darij]:
> Replying to [comment:12 tscrim]:
> > 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.
Why should it? They are completely different implementations. This isn't
even ducktyping, it is just about having a common API because all it is
really about is just overloading `*`. However, after thinking about it a
bit, there is some benefit for having a common base class for
`Representation` and `TrivialRepresentation`, but there is no strong
reason to force common base classes. (Ideally, this would be handled with
a category, but I think we need more discussion and examples to see what
the best way to do this will be.)
> 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).
`self._module` will always exist because `TrivialRepresentation` will not
inherit from `Representation`. `Representation` is a slight variant of
what is sometimes called a
[https://en.wikipedia.org/wiki/Decorator_pattern decorator pattern],
whereas `TrivialRepresentation` is a direct subclass of CFM. As they have
very different implementations, there should not be a subclass
relationship `Representation` to `TrivialRepresentation`.
> S2. Please document in the docstring that the trivial representation is
both left and right.
Will do.
> 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?
If anything, this should be a method, not an (hidden) attribute. However,
I do agree we need something. Althought AFAIK this is the first time we
have a left but not necessarily a right module.
> S4. In the `_acted_upon_` of `TrivialRepresentation`, does
`_from_dict(d)` do the right thing when `d == 0` ?
This will never happen as `monomial_coefficients` returns a `dict`.
However, I do see a potential when acting on the zero element. I will
check/doctest this.
(I'm waiting for `7.1.beta1` to come out before I make any changes. You
know as soon as I bump my Sage to beta0, beta1 will be released...)
--
Ticket URL: <http://trac.sagemath.org/ticket/19613#comment:14>
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.
