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 On Sunday, December 27, 2020 at 9:01:59 PM UTC+10 enriqu...@gmail.com wrote: > 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. > > El domingo, 27 de diciembre de 2020 a las 2:49:11 UTC+1, Travis Scrimshaw > escribió: > >> 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 >> >> On Thursday, December 24, 2020 at 7:37:10 PM UTC+10 enriqu...@gmail.com >> wrote: >> >>> 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. >>> >>> >>> El jueves, 24 de diciembre de 2020 a las 0:41:10 UTC+1, Travis Scrimshaw >>> escribió: >>> >>>> 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 >>>> >>>> >>>> On Thursday, December 24, 2020 at 2:07:35 AM UTC+10 enriqu...@gmail.com >>>> wrote: >>>> >>>>> 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. >>>>> >>>> -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/63e9891c-d216-420d-8746-5a329cb2d229n%40googlegroups.com.
