> > (4) Modify == to test equality as subobjects/subsets. > > -1, as I tend to think of "==" as a QUICK test. > > If testing equality has a potential to hit decision problems (which > certainly is the case for subgroups), then "==" should give a swift > "True" if the two objects are easily seen to be equal (by equality of > the set of generators, say), and should return "False" otherwise. > > In these cases, there ought to be a special method that the user will only > call if s/he really is prepared to wait for the answer for a couple of > hours. > > Note that in a way it would be nice if "==" had a ternary logic > "True/False/Unknown". But Python isn't there yet (although I do recall > that there used to be a PEP for it). > > I am also generally in favor of having == being a (generally) fast check. However, the symbolics code takes the opposite approach: it has the method is_trivial_equal() for quick checks but == fires up the proof engine. In terms of surprise, the fast == is clearly worse, but using is_trivially_equal() makes the code harder to read and maintain (often because of inconsistent use in regards to speed regressions).
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.
