@rjf: > I don't know exactly how this came up, but if 2/1 is in a different domain > (rational) from 2, (integer), then gcd should probably be 1, since any > non-zero rational number divides any other, and one commonly uses the > positive "unit" 1 for such a case.
One also commonly uses the content, as it provides information and is likely to be useful, whereas setting the "gcd" to 1 doesn't, really: I could simply use 1 directly instead. In practice: Mma and Pari both have my preferred behaviour, gcd(2/1, 4) = 2, gcd(2/3, 4/3) = 2/3, lcm(2/1, 4) = 4, lcm(2/3, 4/3) = 4/3. Maple gives instead gcd(2/1, 4) = 2, gcd(2/3, 4/3) = 1, lcm(2/1, 4) = 4, lcm(2/3, 4/3) = 8/9, which I'd also be okay with. Let a thousand flowers bloom! I don't know if Maxima has an lcm function, but at least gcd(2/1,4) = 2 and gcd(2/3, 4/3) = 2/3. Magma barfs at rational input, which is defensible. (Maybe there's another gcd which doesn't, not sure.) This would frustrate me, but at least avoids errors such as the one that got me started on this subject in the first place. Sage, by comparison, gives 1, 1, error (or 4 if you use 4/1), 4/3, which doesn't seem nearly as useful as either the Mma/Pari or Maple behaviour. They choose different conventions, but both make sense to me, and convince me that I'm not crazy. :^) It's worth emphasizing that Sage __already gives the Pari answers__ for the cases of (rational, rational) and (integer, rational) argument to lcm (and has a Rational.content implementation); I'd be interested in understanding why gcd should be different. > Really, the issue is much broader. for example, do you also want to treat the > complex number > 1+0*i the same as 1? do you want to treat the floating point number 1.0 the > same as 1? As the use cases seem far less common, I have no issues requiring explicit coercions for symbolic complex numbers. I certainly don't have problems requiring explicit coercions for finite-precision types, and have no opinions about any of the thousand other possibilities. @Simon King: as you note, there are multiple ways to extend the concept of gcds and lcms to the rationals. In such a situation, it would seem that two minimal things you would like would be (1) to reduce to the integer case for integer values, and (2) to maintain some nice properties so that the names "gcd" and "lcm" still fit. Given some definition satisfying (1), coercing down to integers from rationals isn't much of a problem, because the values will be the same. Pari, Mma, and Maple all do this in a way which makes sense, and Sage already halfway does it (with lcm). Choosing any definition which doesn't reduce to the integer one, as is currently done, seems problematic to me as a design decision, given that it's far more likely to be used that way in error than it is that someone decided to obfuscate "1" by writing it as gcd(some rational, some integer). > So, is QQ reasonably covered by "Wherever possible"?? I doubt. > Note that currently we have > sage: gcd(-2,1) > 1 > sage: lcm(-2,1) > 2 > So, gcd(x,y)*lcm(x,y) == x*y doesn't even hold in ZZ. Why should it hold in > QQ? I'd return different signatures, myself, but even if you don't agree, the property can easily hold as-is for Z+ and Q+. Why is "for positive integers and rationals" not an acceptable content for "wherever possible"? (I'm a physicist, not a mathematician, so I'm sometimes physics-sloppy when writing: what should I have written instead of "wherever possible" as shorthand for something like "on the largest region containing the regime of interest while preserving the relationships under discussion"?) Doug -- Department of Earth Sciences University of Hong Kong -- 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
