#15381: gens() can mean both module and algebra generators, confusing
morphism.pyx
-------------------------------------------------+-------------------------
Reporter: darij | Owner:
Type: defect | Status: new
Priority: major | Milestone: sage-6.2
Component: categories | Resolution:
Keywords: categories, gens, morphisms, | Merged in:
modules | Reviewers:
Authors: | Work issues:
Report Upstream: N/A | Commit:
Branch: | Stopgaps:
Dependencies: #10963 |
-------------------------------------------------+-------------------------
Comment (by darij):
From emails between Nicolas and me:
[Nicolas]
Do you see other occurrences of this situation? Does it need to be
highlighted further right now? This topic is already touched a bit in
the discussion about "the order of super categories".
[Darij]
"hom" (as in "PolynomialRing(QQ, 'x').hom" or "SymmetricGroup(3).hom")
is likely to lead to similar problems (not surprisingly as it relies
on "gen" -- it should be supplanted at the same time as "gen"). In
contrast, "Hom" (a method to generate the homspace rather than a
single homomorphsim) is implemented semi-reasonably (it takes a
"category" variable, but unfortunately it ducktypes it if it is not
provided, which allows for writing fragile code). Also, this is
precisely the type of issue I saw coming with Quotients -- although it
was mainly a guess since I don't know what infrastructure will
actually come for those. More likely it won't be "Quotients" but
"quotient" (on objects of categories) causing troubles, since the
"quotient of X by I" depends on what category we consider X to be in.
I'm not sure if "extension", "cartesian_product" and the likes will be
problematic (depends on how widely they are used). I would rather like
to have these issues stressed in the documentation.
[Nicolas]
Agreed!!! They should all accept a category argument if they don't
yet, and/or be split in separate methods like for algebra_generators
and friends. And developers should specify the category explicitly
whenever there is an ambiguity (e.g. in generic code). I would not
call "ducktyping" the default category for hom(A,B) though: the
semantic is fully specified from A.category() and B.category(), and
those are set explicitly by A and B. It's just that you'd better know
A and B well to predict the result :-)
Actually, for hom, you need not only a category argument but also an
argument to specify how the morphism should be computed, as the two
things may differ. You typically may want to implement a Hopf algebra
morphism by linearity. For now we have a couple specialized methods
like "module_morphism", but the more systematic plan to tackle this is
briefly stated on:
http://trac.sagemath.org/ticket/10668#comment:17
[Darij]
> Agreed!!! They should all accept a category argument if they don't
> yet, and/or be split in separate methods like for algebra_generators
> and friends. And developers should specify the category explicitly
> whenever there is an ambiguity (e.g. in generic code). I would not
> call "ducktyping" the default category for hom(A,B) though: the
> semantic is fully specified from A.category() and B.category(), and
> those are set explicitly by A and B. It's just that you'd better know
> A and B well to predict the result :-)
Yeah, but some constructors decide on the category of the object they
construct at runtime, based on conditions like whether some parameter
given is invertible or not. The category hierarchy is probably not at
fault here; just saying that things will go wrong every once in a
while.
--
Ticket URL: <http://trac.sagemath.org/ticket/15381#comment:5>
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.
