> > 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. > > But what if you *do* want to compare the subgroups (as Chris does). When > I ask "How many apples in my basket?" to Sage I don't want an answer > like "red bikes are nicer than blue ones" because it is faster to do so. > The problem here is definitely *not* to discuss whether equality of > subgroups is decidable or fast but what "==" should be. >
So we have moved from bikeshedding to bikecoloring? :P However, that is not the correct analogy. I would say a better analogy with the apple basket is "are the trees these apples came from the same." IMO, these two issues are coupled (in part due to limitations of Python not allowing an Unknown return). One option on the table is to allow == to check a potential undecidable or very slow test. 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.
