#10963: More functorial constructions
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.1
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 | Commit:
Dependencies: #11224, #8327, | eb7b486c6fecac296052f980788e15e2ad1b59e4
#10193, #12895, #14516, #14722, | Stopgaps:
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506 |
-------------------------------------+-------------------------------------
Comment (by pbruin):
Replying to [comment:445 nthiery]:
> Granted, it's not perfect, but it's consistent with the other
> preexisting ``summand_`` methods in the context of cartesian products.
> I'd be happy to change it, but then we should change all of them at
> once for consistency. IMHO This would be best handled in a followup
> ticket since this one is already way too big. I am happy adding a
> warning about the probable name change in the documentation though.
The existing `summand_*` methods I could find are
{{{
CartesianProduct.summand_projection()
Sets.CartesianProduct.ParentMethods.summand_projection()
Sets.CartesianProduct.ElementMethods.summand_projection()
Sets.CartesianProduct.ElementMethods.summand_split()
}}}
Maybe the quickest solution is to insert better-named aliases for these,
rename the method `summands()` introduced here, and later deprecate
`summand_projection()` and `summand_split()` in a different ticket.
My first reflex would be to rename `summand_projection()` to
`projection()` and `summand_split()` to `tuple()`. If this is too
conflict-prone, maybe using the prefix `cartesian_` suggested by Simon
would be a solution?
There are also `summand_embedding()` and `summand_projection()` methods in
`CombinatorialFreeModule_CartesianProduct`. That is OK if and only if
there are only finitely many summands/factors; in that case the product
and sum coincide, since modules form an additive category.
> Also, I would like something different from ``factors'', since we will
> also use it in the context of monoids (like for making cartesian
> products thereof), and `factors` would be ambiguous.
I'm confused; isn't a Cartesian product of monoids just the Cartesian
product of the underlying sets, with the obvious monoid structure? Or do
you mean that a generic monoid will have a `factors()` method that does
something unrelated?
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:450>
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/groups/opt_out.
