Bug in hom

[enriqu...@gmail.com]

I have posted a bug in hom method for vector spaces in https://groups.google.com/g/sage-support/c/1VDRFjZePCo/m/sFimwoV2BgAJ 

If one defines linear mappings using hom, distinct morphisms may be told to be equal and viceversa

Following a colleague advice (Miguel Marco) I looked at the method _richcmp_ and it seems that it checks if the matrices of the morphisms are equal. Since the same vector space can be defined in Sage with distinct associated bases, this is the reason of the error. 

I guess that equality of domains (and maybe codomains) is the first condition to be checked and then the equality of the images of self.

Best, Enrique.

[Travis Scrimshaw]

What you're asking for is checking if two matrices defining the linear transformations are similar, which involves computing the Smith normal forms of the matrices. This is computationally expensive. Instead, what we do is == becomes a weaker form of equality that is fast (equivalently has stronger conditions). This is something we do for graphs where we have a separate method is_isomorphic(). Therefore, I think that equal linear maps not being == is okay if they are given by different matrices.

That being said, there is a definite issue with the false equality a == c, which because

sage: a.parent()(c)
Vector space morphism represented by the matrix:
[1 0]
[0 1]
Domain: Vector space of dimension 2 over Finite Field of size 2
Codomain: Vector space of dimension 2 over Finite Field of size 2

which is not the correct map. This is a result of the fact the __call__ does not check that the the (co)domains match and compose with the corresponding coercion maps.

Best,

Travis

[enriqu...@gmail.com]

Not exactly, when one asks if two linear maps are equal it is not the same thing to ask if they are similar, I mean equal as maps. In my example, if you enter:

K=GF(2)

V=K^2

B=V.basis()

B1=[vector(K,[i,j]) for i,j in [(1,0),(1,1)]] 

V1=V.subspace_with_basis(B1)

and you ask V==V1 the answer is True despite they are distinct objects in Sage as their associated bases are not the same. In my opinion the option is correct because as mathematical objects they are the same.

When one defines morphisms with domains V or V1, and same codomain, the method keeps the matrix as comparison object. As you say computing the Smith form (or Jordan form in case of endomorphisms) is expensive. I am not sure if computing the images of the basis elements of either V or V1 is so expensive. If it is so, it would be better to avoid an answer for the equality, to avoid wrong answers.

This is the source of a._richcmp_??

def _richcmp_(self, other, op):

if not isinstance(other, MatrixMorphism) or op not in (op_EQ, op_NE): # Generic comparison 

    return sage.categories.morphism.Morphism._richcmp_(self, other, op) 

return richcmp(self.matrix(), other.matrix(), op) 

File: /usr/local/sage/local/lib/python3.8/site-packages/sage/modules/matrix_morphism.py 

Type: method

Best, Enrique.

[Travis Scrimshaw]

We need to be very careful here about what "same" means, and the category we want to work in is vector spaces with a distinguished basis. By similar I really meant up to a change-of-basis, and I should have been more precise. Although perhaps it is a more simple problem than I was thinking because we know explicitly how to link different bases together (not just some abstract isomorphism). Thus, the comparison as matrices is the correct thing to do, provided the two bases are the same. Hence, we just need to make sure each linear map set up from basis B to basis B'. Therefore, the bug is in the __call__, which handles the coercion between the elements of the (distinct) Hom spaces before the _richcmp_ sees the objects.

Again, let me reiterate that Python == should not always be taken as equality as you might think of it. However, in this case, if we fix the aforementioned bug, everything should behave how you expect it to.

Best,

Travis

[enriqu...@gmail.com]

Dear Travis,

I basically agree with you, in the sense to fix that what equality means. At this time, equality of vector spaces does not imply equality of associated vectors. I think both choices have good reasons. I am not sure how to collaborate with these issues but I am ready to. Best, Enrique.

[Travis Scrimshaw]

If we just fix the bug in the corresponding Homspace's __call__method to make sure the domains match by pre/postcomposing using the appropriate coercion maps when the objects are equal-but-not-identical, then it will fix the problem because things would be described in terms of the same basis.

Best,

Travis