Sage: Ticket #15381: Comparison of morphisms assumes that a Morphism is determined by its action on gens()
https://trac.sagemath.org/ticket/15381
<p>
Counterexamples:
</p>
<pre class="wiki">sage: from sage.categories.morphism import SetMorphism
sage: f = SetMorphism(Hom(QQ, QQ, Sets()), numerator)
sage: f.is_identity()
True
</pre><p>
and
</p>
<pre class="wiki">sage: D3 = GroupAlgebra(DihedralGroup(3), QQ)
sage: from sage.categories.modules_with_basis import *
sage: g = ModuleMorphismByLinearity(domain=D3, codomain=D3, on_basis=lambda x: (D3.zero() if list(x) == [] else D3.basis()[x]))
sage: g.is_identity()
True
</pre><p>
Of course, <code>g</code> is not the identity. The culprit is here:
</p>
<pre class="wiki"> gens = domain.gens()
for x in gens:
if self(x) != x:
return False
return True
</pre><p>
This is part of the <code>is_identity</code> method in <code>sage/categories/morphism.pyx</code>. The assumption is that the <code>gens</code> method and the morphism refer to the same category, but here they don't: the morphism is a module morphism, while <code>D3.gens()</code> refers to the generators as algebra.
</p>
<p>
Note that the equality check takes the other extreme and seems to only return <code>True</code> if the <code>on_basis</code> lambda functions of both morphisms are identical (i. e., I can add zero to each image and it doesn't return <code>True</code> anymore, even if they are identical).
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/15381
Trac 1.1.6darijFri, 08 Nov 2013 02:07:30 GMT
https://trac.sagemath.org/ticket/15381#comment:1
https://trac.sagemath.org/ticket/15381#comment:1
<p>
Thinking about it, I'm not sure if <code>gens</code> can be trusted at all, particularly in the case of algebras over different ground rings. Radical suggestion: deprecate it in favor of <code>group_gens(self)</code>, <code>module_gens(self, base_ring)</code>, <code>ring_gens(self)</code> and <code>algebra_gens(self, base_ring)</code>?
</p>
TicketdarijMon, 11 Nov 2013 03:12:36 GMTcc changed; dependencies set
https://trac.sagemath.org/ticket/15381#comment:2
https://trac.sagemath.org/ticket/15381#comment:2
<ul>
<li><strong>cc</strong>
<em>SimonKing</em> <em>nthiery</em> added
</li>
<li><strong>dependencies</strong>
set to <em>#10963</em>
</li>
</ul>
<p>
Battle plan:
</p>
<ul><li>Wait for <a class="closed ticket" href="https://trac.sagemath.org/ticket/10963" title="enhancement: Axioms and more functorial constructions (closed: fixed)">#10963</a> to be merged.
</li></ul><ul><li>Define <code>monoid_gens(self)</code>, <code>group_gens(self)</code>, <code>module_gens(self, base_ring)</code>, <code>ring_gens(self)</code> and <code>algebra_gens(self, base_ring)</code>.
</li></ul><ul><li>For every (relevant) category <code>C</code>, define a category-level method <code>C.object_gens(object)</code> that calls <code>object.[whatever]_gens()</code> where <code>[whatever]</code> is the name of the category.
</li></ul><ul><li>Redefine <code>gens(self)</code> to only work in the case when <code>self</code> is DEFINED by generators and relations: for example, if <code>self</code> is defined as a polynomial ring (or a quotient thereof), then <code>gens(self)</code> should be the (projections of the) indeterminates; but when <code>self</code> is (say) a group algebra, <code>gens(self)</code> shouldn't be defined at all. For the sake of deprecation, don't actually throw errors but rather return the old result with a deprecation warning.
</li></ul><p>
What do you think?
</p>
Ticketvbraun_spamThu, 30 Jan 2014 21:20:52 GMTmilestone changed
https://trac.sagemath.org/ticket/15381#comment:3
https://trac.sagemath.org/ticket/15381#comment:3
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.1</em> to <em>sage-6.2</em>
</li>
</ul>
TicketmmezzarobbaTue, 11 Feb 2014 08:05:56 GMTcc changed
https://trac.sagemath.org/ticket/15381#comment:4
https://trac.sagemath.org/ticket/15381#comment:4
<ul>
<li><strong>cc</strong>
<em>mmezzarobba</em> added
</li>
</ul>
TicketdarijFri, 25 Apr 2014 12:14:22 GMT
https://trac.sagemath.org/ticket/15381#comment:5
https://trac.sagemath.org/ticket/15381#comment:5
<p>
From emails between Nicolas and me:
</p>
<p>
[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".
</p>
<p>
[Darij]
"hom" (as in "<a class="missing wiki">PolynomialRing?</a>(QQ, 'x').hom" or "<a class="missing wiki">SymmetricGroup?</a>(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.
</p>
<p>
[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 :-)
</p>
<p>
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:
</p>
<blockquote>
<p>
<a class="ext-link" href="http://trac.sagemath.org/ticket/10668#comment:17"><span class="icon"></span>http://trac.sagemath.org/ticket/10668#comment:17</a>
</p>
</blockquote>
<p>
[Darij]
</p>
<blockquote class="citation">
<p>
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 :-)
</p>
</blockquote>
<p>
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.
</p>
TicketnthieryFri, 25 Apr 2014 13:44:07 GMT
https://trac.sagemath.org/ticket/15381#comment:6
https://trac.sagemath.org/ticket/15381#comment:6
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15381#comment:2" title="Comment 2">darij</a>:
</p>
<blockquote class="citation">
<p>
Battle plan:
</p>
<ul><li>Wait for <a class="closed ticket" href="https://trac.sagemath.org/ticket/10963" title="enhancement: Axioms and more functorial constructions (closed: fixed)">#10963</a> to be merged.
</li></ul><ul><li>Define <code>monoid_gens(self)</code>, <code>group_gens(self)</code>, <code>module_gens(self, base_ring)</code>, <code>ring_gens(self)</code> and <code>algebra_gens(self, base_ring)</code>.
</li></ul></blockquote>
<p>
For the record: we already have <code>semigroup_generators</code>,
<code>monoid_generators</code>, <code>group_generators</code>, <code>algebra_generators</code>,
<code>basis</code>, etc. What we need is a more systematical use and
advertisement of them. In particular it should be made clear that gens
is nothing but a short hand for casual interactive use, and should
*not* be used in code.
</p>
<p>
<code>module_generators</code>, <code>algebra_generators</code> and the like need not take a
base ring, since they are relative to the distinguished choice of base
ring in the parent.
</p>
<blockquote class="citation">
<ul><li>For every (relevant) category <code>C</code>, define a category-level method <code>C.object_gens(object)</code> that calls <code>object.[whatever]_gens()</code> where <code>[whatever]</code> is the name of the category.
</li></ul><ul><li>Redefine <code>gens(self)</code> to only work in the case when <code>self</code> is DEFINED by generators and relations: for example, if <code>self</code> is defined as a polynomial ring (or a quotient thereof), then <code>gens(self)</code> should be the (projections of the) indeterminates; but when <code>self</code> is (say) a group algebra, <code>gens(self)</code> shouldn't be defined at all. For the sake of deprecation, don't actually throw errors but rather return the old result with a deprecation warning.
</li></ul></blockquote>
<p>
A weaker step would be to just define <code>gens</code> in each category as an
alias to the generators for this category. With that, gens would refer
to the most specific one. Nothing super robust, but sufficient for
interactive use.
</p>
<p>
By the way: it's best if all the '*_generators' methods would return
families.
</p>
<p>
Cheers,
</p>
<blockquote>
<p>
Nicolas
</p>
</blockquote>
Ticketvbraun_spamTue, 06 May 2014 15:20:58 GMTmilestone changed
https://trac.sagemath.org/ticket/15381#comment:7
https://trac.sagemath.org/ticket/15381#comment:7
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.2</em> to <em>sage-6.3</em>
</li>
</ul>
Ticketvbraun_spamSun, 10 Aug 2014 16:51:03 GMTmilestone changed
https://trac.sagemath.org/ticket/15381#comment:8
https://trac.sagemath.org/ticket/15381#comment:8
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.3</em> to <em>sage-6.4</em>
</li>
</ul>
TicketmmezzarobbaWed, 11 Feb 2015 17:42:02 GMT
https://trac.sagemath.org/ticket/15381#comment:9
https://trac.sagemath.org/ticket/15381#comment:9
<p>
Related (duplicate?): <a class="closed ticket" href="https://trac.sagemath.org/ticket/17768" title="defect: Morphism.is_identity() assumes a Morphism is determined by its action ... (closed: duplicate)">#17768</a>
</p>
TickettscrimWed, 11 Feb 2015 18:46:11 GMT
https://trac.sagemath.org/ticket/15381#comment:10
https://trac.sagemath.org/ticket/15381#comment:10
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15381#comment:9" title="Comment 9">mmezzarobba</a>:
</p>
<blockquote class="citation">
<p>
Related (duplicate?): <a class="closed ticket" href="https://trac.sagemath.org/ticket/17768" title="defect: Morphism.is_identity() assumes a Morphism is determined by its action ... (closed: duplicate)">#17768</a>
</p>
</blockquote>
<p>
Strongly related, but not a duplicate as this could potentially be an issue in other parts of Sage.
</p>
TicketjakobkroekerSun, 26 Feb 2017 01:05:56 GMTstopgaps set
https://trac.sagemath.org/ticket/15381#comment:11
https://trac.sagemath.org/ticket/15381#comment:11
<ul>
<li><strong>stopgaps</strong>
set to <em>wrongAnswerMarker</em>
</li>
</ul>
TicketjdemeyerTue, 28 Nov 2017 09:21:09 GMTdescription, summary changed
https://trac.sagemath.org/ticket/15381#comment:12
https://trac.sagemath.org/ticket/15381#comment:12
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/15381?action=diff&version=12">diff</a>)
</li>
<li><strong>summary</strong>
changed from <em>gens() can mean both module and algebra generators, confusing morphism.pyx</em> to <em>Comparison of morphisms assumes that a Morphism is determined by its action on gens()</em>
</li>
</ul>
Ticket