On Mar 12, 2009, at 7:26 AM, Bill Page wrote: > On Thu, Mar 12, 2009 at 12:35 AM, Robert Bradshaw wrote: >> >> OK, my last post on this tread for a while, I promise :). > > I hope no one is asking you to not post on this subject (priorities > and time constraints notwithstanding)... :-(
No...it just always feels a bit odd when the last 4 replies to a thread are by the same person. >> On Mar 11, 2009, at 7:19 PM, Bill Page wrote: >> >>> On Wed, Mar 11, 2009 at 10:13 PM, David Roe wrote: >>>> On Wed, Mar 11, 2009 at 9:53 PM, Bill Page wrote: >>>>> >>>>> On Wed, Mar 11, 2009 at 9:08 PM, Carl Witty wrote: >>>>>> ... >>>>>> Does this mean you want GF(5)(3)*2 and RR(pi)*2 to fail? These >>>>>> currently work due to coercions that would be unsafe according >>>>>> to my >>>>>> definition. >>>>>> >>>>> >>>>> The __mul__ method exported by GF(5) could accept integers as >>>>> well as >>>>> elements of GF(5), i.e. rely on operator polymorphism rather than >>>>> non-strict coercion in such cases. >>>> >>>> The reason we have coercion is so that we don't have to do this. >> >> +10. Otherwise every element has huge if-else lists in every >> __add__, __sub__, __mul__, etc. corresponding to the fixed list >> various possibilities that the programer original programmer thought >> of at the time, and then those who've added to it. > > I do not understand this claim. As mentioned, everything can be seen as a Z-module. This would mean that every time I implement _mul_ I would have to handle this case. It's much simpler to let _mul_ only worry about the ring (or group, or field...) multiplication. One can define _rmul_, _lmul_, ... for actions. So, to rephrase the question, does this mean that GF(5)(3) + 1 and RR (pi) + 1 should fail? > As Ralf pointed out, there are good > (i.e. "mathematical") reasons why it makes sense to multiply elements > of GF(5) directly by integers. This has nothing to do with coercions > or any other kind of type conversion per se. It makes sense to have > this property of GF implemented locally. It would be inconvenient to > have a symbol other than * to denote this operation. Because Python is > dynamically typed, there is no alternative but to test some condition > to determine what operation to perform. Using the coercion system to > implement this kind of polymorphism moves some properties of GF into > the coercion system instead of keeping it local. To clarify, the coercion system doesn't know anything about GF, it queries parents about their properties and then does reasoning based on that. >> Much better to have a central system that one can reason with. Then >> the author of _mul_ only has to worry about how to actually >> multiply two >> elements of the same kind. > > I have nothing against the concept of a centralized system of > coercions and I certainly would not advocate replacing it with > exclusive use of operator polymorphism. > >> And it makes it much messier to handle stuff like ZZ['x'] + 1/2. > > As others have pointed out here, coercions from ZZ['x'] -> QQ['x'] > should be considered safe. Sorry, what I meant it would be messy to implement this in the _add_ operator. >>> I presume that you do not mean to imply that this is the only reason >>> to have coercion. Could it be said that this is the reason why you >>> want non-strict (unsafe) coercions? >> >> I see this as one of the primary motivations to have coercion at all, >> "safe" (injective?) or not. BTW > > This does not make sense to me. Surely the main reason for coercions > is for the convenience of the user. Yes, it's all about convenience. I was saying that arithmetic is one of the main conveniences coercion provides to the user and programer. > We want to make it easy to write > in a notation that makes sense to the mathematician and which behaves > in a simple and predictable (i.e. "correct") manner. What Carl called > "safe" coercions are guaranteed to satisfy this criterior. Non-safe > coercions might only be necessary for more technical reasons, such as > avoiding the use of operator polymorphism as discussed above. I guess "safe" is a matter of personal taste. I find sage: GF(5)(0) == 0 True sage: GF(5)(1) == 1 True sage: GF(5)(-1) == -1 True to be "safe," but it seems some people are really bothered by this idea and would rather have to write "a == a.parent().coerce(1)" - 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 -~----------~----~----~----~------~----~------~--~---
