Hi kcrisman, On 15 Feb., 21:12, kcrisman <kcris...@gmail.com> wrote: > Burcin or someone else who understands more about this (I see Mike > responded as well) would have to say. I think the real issue is that > we'd like to have consistency in representation, and in particular > that certain doctests don't fail where things should 'look' right - we > have had issues in the past with minus signs in weird places or things > not fractions in the right spots, for looks.
Right, weird minus signs aren't nice. But actually it seems that we can stop the discussion, because I found what specific property of gcd was responsible for the problem: The current behaviour is that for any elements a,b of a field F different from QQ (weird, I know) but containing ZZ, gcd(a,b) returns the gcd of a and b in ZZ (actually not as an element of F!), or raises an error: sage: N.<i> = NumberField(x^2+1) sage: gcd(N(15),N(25)) 5 sage: parent(_) Integer Ring sage: gcd(N(15),i) Traceback (most recent call last): ... TypeError: unable to find gcd of 15 and i In QQ, the gcd returned 0 or 1. In my patch, I suggested an approach that makes gcd in QQ more interesting, and in any other field makes gcd return 0 or 1. However, it turned out that the property "gcd in F restricts to gcd in ZZ" is decisive for putting the minus sign in a good-looking place. So, the patch for which I am now running doc tests is a little modified: If F contains ZZ as a sub-ring, gcd(a,b) tries to return gcd(ZZ(a),ZZ(b)), and if this fails, it returns 0 or 1. Only difference to the old behaviour: No error is raised. I'll post it at #10771 after finishing the tests. Cheers, Simon -- 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
