#10963: More functorial constructions
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_info
Priority: major | Milestone: sage-6.2
Component: categories | Resolution:
Keywords: days54 | Merged in:
Authors: Nicolas M. Thiéry | Reviewers: Simon King, Frédéric
Report Upstream: N/A | Chapoton
Branch: | Work issues:
public/ticket/10963-doc- | Commit:
distributive | 1cdc128a85851dd007b3b77ec53a4853a10e1de4
Dependencies: #11224, #8327, | Stopgaps:
#10193, #12895, #14516, #14722, |
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506, |
#15757, #15759 |
-------------------------------------+-------------------------------------
Comment (by SimonKing):
Replying to [comment:569 nthiery]:
> > What promise does `semigroup_generators` fulfill? Why should a
semigroup always come with such a method? Isn't `__contains__` more of a
necessity?
>
> It's a finite semigroup (the "finite" was missing above; I just added
> it and will push later on). So implementing the product and the
> semigroup generators is one of the ways to define everything. Another
> way would indeed be to provide `__contains__`.
`__contains__` is implemented by `sage.structure.parent.Parent`. Hence,
provided that we all want to derive our parent classes from Parent so that
we also inherit the coercion system, `__contains__` isn't a problem.
> It's appropriate to check that they are indeed in `self`, typically
> using `self.is_parent_of(a)`, and raise a value error otherwise.
Ahaha. So, this is all not connected with Sage's coercion system? Bad.
First of all, why do you write `self.is_parent_of(a)`? Shouldn't it be
`a.parent() is self`? If `.is_parent_of()` is implemented in a Python
fail, then the latter idiom should also be faster.
And secondly, why would it ''not'' send all arguments to the given parent
first? That's what we do in the default `__call__` method of morphisms,
too.
> I know of no computer algebra system that has a good solution for
> this, and any great idea to tackle this is more than welcome.
That's something that I brought up before. We have categories with axiom,
but we should also have "category with structure" (that's a bad wording):
Some categories merely define operators. E.g., Sets() defines the `in`
operator, (multiplicative) Magmas() defines `*`, and `AdditiveMagmas()`
defines `+`. Each axiom is formulated in terms of these operators, and in
particular, each axiom requires some operators being present. E.g.,
`Distributive` requires that we are in a sub-category of
`Magmas()&AdditiveMagmas()`.
So, in the example you mention ("code duplication of
`Magmas().Associative()` and `AdditiveMagmas().Associative()`"), one could
make it so that
- we have `Magmas(operator.mul)` and `Magmas(operator.add)` (the latter
replacing `AdditiveMagmas`), and
- the `Associative` axiom by default applies to ''the'' operator of a
category (provided there is only one), respectively has an optional
argument naming the operator in question. Say, we would have
`(Magmas(operator.mul)&Magmas(operator.add)).Associative(operator.add)`
being the same as
`Magmas(operator.mul)&Magmas(operator.add).Associative()`.
And since the choice of an operator is arbitrary/generic, we could avoid
some code duplication.
Best regards,
Simon
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:573>
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 http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
