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)... :-( > 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 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. > 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. >> 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. 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. > ... Regards, Bill Page. --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
