On 30 May 2018 at 07:14, Travis Scrimshaw <tsc...@ucdavis.edu> wrote:
> > > On Tuesday, May 29, 2018 at 9:01:51 PM UTC+10, chris wuthrich wrote: >> >> >> As a simple-minded user I stumbled over exactly this last week. I don't >> understand much of what this thread is discussing, but I know what a >> simple-minded user wants. >> >> sage: G = GL(2,13) >> sage: G = G.as_matrix_group() >> sage: H = G.subgroup([ matrix(GF(13),[[1,0],[1,1]]) ]) >> sage: H2 = G.subgroup([ matrix(GF(13),[[1,1],[0,1]]) ]) >> sage: H3 = G.subgroup([ matrix(GF(13),[[1,0],[2,1]]) ]) >> >> I expect H == H3 to say True as they are the same subgroup. >> I expect H = H2 to say False, since they are not the same subgroup, even >> though they are isomorphic. >> Instead >> >> sage: H == H3 >> False >> sage: matrix(GF(13),[[1,0],[1,1]]) in H3 >> True >> sage: matrix(GF(13),[[1,0],[2,1]]) in H >> True >> sage: H.is_isomorphic(H3) >> True >> sage: H.is_isomorphic(H2) >> True >> sage: matrix(GF(13),[[1,0],[1,1]]) in H2 >> False >> >> I though of working around it by checking if they are the same as sets, >> but to my surprise: >> >> sage: Set( h for h in H ) == Set( h for h in H3 ) >> False >> sage: Set( h.matrix() for h in H ) == Set( h.matrix() for h in H3 ) >> True >> >> In short: I consider this a bug. No matter how this is done at the back, >> the user expects == to mean mathematical equality, here equality of >> subgroups. Otherwise the function should be called >> subgroups_with_given_generators. >> >> I think it is a bad thing in this case for == to be equality as sets. > Imagine if these are two really big, equal, but differently constructed > subgroups. This would be a really long and expensive check, whereas in most > cases, checking the defining objects are sufficient. I believe we have > other places in Sage where == is not strict mathematical equality for > similar reasons. -1 on changing the == semantics here. > We should then admit that users will regularly be surprised. Perhaps this is similar to the situation for evaluating boolean expressions, where (I seem to remember) False is returned in case of "don't know". Any subgroup constructor (e.g. from generators) which results in a subgroup for which testing membership is impossible (or worse, silently returns False for every element of the ambient group) is surely not going to be very useful; and if there is a membership test then testing two subgroups for equality is easy (though of course possibly slow). In summary, if we implement subgroups in such a way that testing equality is not implemented then it is very misleading to return False every time. > > Now I would say the equality as sets (which really comes down to equality > of elements) is a bug. Two matrix group elements should compare by their > matrices and not have the coercion system involved otherwise. My guess is > the coercion system tries to convert the elements of H into H3 and vice > versa, which is cannot do, and hence, results in a False for equality. This > probably requires a reimplementation of the comparison method of matrix > group elements. > +1 to that. > > Best, > Travis > > -- > 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 post to this group, send email to sage-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. > -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
