On Thu, Mar 12, 2009 at 3:53 PM, Robert Bradshaw wrote: > ... > But what I'm saying is that > > sage: GF(5)(3) == 3 > True > > Seems just as natural. >
The reason that this seems natural is that it is a rather special case involving a simple "literal". Does the following sage: a = 11 sage: GF(5)(1) == a True seem just as "natural"? I think one might reasonably expect to write: sage: GF(5)(1) == GF(5)(11) True But why doesn't the following constitute a ValueError? sage: a=GF(2)(1); b=GF(5)(1); c==11 True sage: a==c True sage: b==c True sage: a==b False ---- Equality isn't even transitive! This False result could easily mask a simple error in the coding of some algorithm. There is a reasonable solution but it involves some rather deep changes to Sage. Sage decides very early on (in the preparser stage?) that the symbol 3 is going to denote an element of Integer Ring. The reason that GF(5)(3) == 3 seems natural is because in this context a human reader normally reserves judgment about what the 3 stands for until the rest of the sub-expression is understood. 3 is just a "literal". There could be several other forms of literals such as 'F12A', 0777, etc. For any parent, Sage needs a way to denote elements. Interpreting literals like 0 and 1 as GF(5).zero_element() and GF(5).one_element makes sense and this can be extended in a natural manner. Having made the "mistake" of interpreting 3 as an integer, there is little choice but to *convert* it to GF(5)(3) when necessary but this is not a safe coercion in general. Regards, Bill Page. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
