Dear Luis,
I think the points you raise are valid ones. Perhaps the following
would be a sensible solution?
Implement gcd and lcm for general field elements just as you suggest.
(So gcd(x,y) is 1 unless (x,y) is (0,0), in which case it is 0.) It
should be just fine for inexact fields, too, so long as 0 and 1 are
exactly representable. (See John Cremona's message.) However, it's
important to emphasize (in the documentation of that new code) that
the methods gcd and lcm might be overwritten to implement any
mathematical correct answer.
I don't think this change in code should be used as a band-aid to make
things work in one of the trac tickets you mentioned earlier.
On to the next points... your examples do show that lcm isn't as well
set up as gcd with respect to the coercion system. If you're
implementing gcd/ lcm for field elements already, could you change
this, too? (I unfortunately can't claim to understand the coercion
system well enough to "just do this quickly".)
There seems to be another problem suggested by your examples. Of
course, if a user does
sage: x.gcd(y)
then I would think the user wants y to be interpreted as an element of
the parent of x, if possible. That is, the operation x.gcd(y) is
*not* necessarily symmetric. On the other hand, if a user types
sage: gcd(x, y)
one might (mistakenly) expect it to be symmetric. Of course, in
principle this problems might have come up with many other operations
which a mathematician would expect to be commutative. Perhaps a
solution to this way has been discussed somewhere else already?
Otherwise, looking at the implementation of addition should give some
guidelines.
Best wishes,
Sebastian
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
