#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 nthiery):
Replying to [comment:573 SimonKing]:
> `__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.
Right, though the __contains__ from Parent does nothing but delegate
to the constructor. If you want, for example, to test whether a given
matrix belongs to a matrix group, you need to implement that
somewhere.
> > It's appropriate to check that they are indeed in `self`, typically
> > using `self.is_parent_of(a)`, and raise a value error otherwise.
>
> 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.
The main point of is_parent_of is that it can be made to work
uniformly whether self is a facade or not. It certainly should be
Cythonized, advertized, ...
> Ahaha. So, this is all not connected with Sage's coercion system? Bad.
> ...
> 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.
For morphisms, which know explicitly about their domain and codomain,
this can be fine, in particular because the handling of the coercion
is done once for all morphisms. But when implementing a Python method,
I am strongly in favor, from experience with trying both, of not
having coercions:
- It gives more responsibility to the method implementer.
- Mistakes can go unnoticed because the system will have found some
way to do some coercion.
> > 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.
Me too ...
> 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.
The difficulty is that this is not only about a single operator /
method. But a bunch of them: in one case '+,-,zero,sum,...' in the
other '*,/,one,prod,factor,...'. Sharing something between the two
hierarchies of categories is only really useful if you can write
generic code that applies in both situation; for that you need somehow
to plug the right operations in the right spots in the code. That's
kind of what we are doing manually for e.g. cayley_graph, but doing
this systematically is a different beast from what we have been doing
so far with just usual inheritance.
Anyway, discussion to be moved to a different ticket.
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:575>
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.
