On Mar 10, 2009, at 4:49 PM, Nicolas M. Thiery wrote: >> Because it's really inconvenient to always have to manually cast to >> the same parent. Imagine I have a loop. >> >> while a < 1: >> [do stuff to a to make it smaller] >> >> Would this fail if a was not an integer. What if it started out as an >> integer but then I divided it by something and it became a rational. >> It's much cleaner to write the above than >> >> while a < a.parent()(1): >> [...] >> >> There is are natural morphisms (in Sage called coercion morphism) Z - >>> Q, Z -> Z[x], and Z -> Z/nZ that are used to equate objects across >> parents. > > As you can guess, I am a lot for the new coercion system. And having > the very basic embeddings done automatically is definitely useful (say > int into rationals). But there is a tight balance to maintain, and my > feeling is that Sage is really going too far currently. And I am quite > worried about this in the long run. This leads to slower membership > and equality testing, subtle errors, more complicated code to handle > all sorts of possible cases, ...
Currently the rule is that if you can do arithmetic between two elements, you can compare them. Membership code is something entirely different. > I typically write things like: > > class MyParent > def bla(self, x) > assert x in self > ... > > I really mean that x should be an element of self; not something that > could be converted into it. Membership is much more lenient than coercion, for example, I would be more worried if the following returned False sage: 4/2 in ZZ True > Just yesterday, I lost 1 hour around this because membership testing > for a Weyl group ultimately led to listing all the elements of the > group. Which is problematic for an infinite group. And it was not easy > to straighten this up cleanly. I'm not sure how a more stringent default "in" or comparison operator would have helped here. > In short: for < = in, if it was just me, I would only use the most > absolutely trivial coercions. And in particular avoid there all the > coercions that involve projections and not embedding (like Z -> Z/nZ) > > Just my own feeling ... I would like to avoid having a whole hierarchy of coercions, some of which are used in some cases, others in other cases. People have enough trouble understanding the system as it is. - Robert --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
