First time poster, so brief introduction: planetary astronomer, been
using Sage for years for both science and fun. I'm also one of the
Editors-in-Chief of the OEIS, and have been experimenting with using
Sage for bulk sequence processing and verification. I find writing in
Sage very competitive, but there are a handful of things I'd like to
fix.
For one behaviour which startled me, I thought I followed the right
procedure: asked why it was done that way on IRC, then filed a bug
report on trac. I found the current behaviour irritating enough to
consider posting to sage-devel to complain, but one page recommended
against shouting here as a way of drawing attention to your pet bug,
so I figured before I suggest work for others it's important to show
I'm willing to do some myself. Accordingly I've spent time answering
questions on ask.sagemath.org and worked my way up to fourth, just
passing was. I don't think I'll be catching those above me (hi @niles,
@kcrisman!), as I keep having to vote them up..
Anyway, now it's time to start burning that karma. :^)
The easiest to fix of my pet peeves, each of which I'm willing to
submit patches for if there's someone willing to help navigate.
(1) gcd is broken. http://trac.sagemath.org/sage_trac/ticket/10459
gcd(2/1,4) returns 1 "for simplicity" (!), because 2/1 is a rational.
This is shockingly silly. It's especially so given the existence of
both .content and lcm! I could almost understand raising an
exception, but there's no reason not to use something which reduces to
the integer case. (Using // isn't a good option for me, because that
means surrendering a great sanity check for sequences which should be
made up of integers but aren't.) There's a pending request to
implement a more general gcd, but that's a different problem: I just
want the common case of rationals to do something sensible, and it
could be done in just a few lines given the existing code.
(2) No kwarg constraints in Partitions/Compositions should be mutually
exclusive. (I think there's a ticket for this but I can't find it
now.)
Partitions(15,length=5, parts_in=[1,3,4]) doesn't work, so you have to
do an explicit filter. Optimizing it is a separate issue, but when
there's a trivial way to implement the functionality (simply test that
partitions satisfy the specified criteria before yielding them, in
cases where we don't currently embed the constraints in the
construction process itself), then ISTM we should do so now rather
than wait for a more efficient implementation to appear.
Functionality+speed > functionality, but functionality >>> no
functionality.
Currently, partitions_restricted's docstring says not to use it but to
use RestrictedPartitions instead, which in turn says not to use
RestrictedPartitions but to use Partitions with the "parts_in"
keyword, which in its turn doesn't work.
(3) primes(10, infinity) should work.
Since we're just calling next_prime, there's no reason to require the
upper limit to be an integer. This bites me more than you'd think,
because lots of (often uninteresting, but very error-prone) OEIS
sequences are of the form "function-of (next prime > x s.t.
something-or-other)" and I like functional programming styles.
Wouldn't mind a proof=False option which calls next_probable_prime
instead, either.
(4) Probably this has already been discussed to death and presumably
vetoed for sound reasons, but I don't see the point of complaining
about whitespace issues at the end of a program after every
non-whitespace character when Python doesn't.
Doug
--
Department of Earth Sciences
University of Hong Kong
Dang, I need to post to http://ask.sagemath.org more!
>
> Anyway, now it's time to start burning that karma. :^)
>
>
> The easiest to fix of my pet peeves, each of which I'm willing to
> submit patches for if there's someone willing to help navigate.
>
> (1) gcd is broken. http://trac.sagemath.org/sage_trac/ticket/10459
>
> gcd(2/1,4) returns 1 "for simplicity" (!), because 2/1 is a rational.
> This is shockingly silly. It's especially so given the existence of
> both .content and lcm! I could almost understand raising an
> exception, but there's no reason not to use something which reduces to
> the integer case. (Using // isn't a good option for me, because that
> means surrendering a great sanity check for sequences which should be
> made up of integers but aren't.) There's a pending request to
> implement a more general gcd, but that's a different problem: I just
> want the common case of rationals to do something sensible, and it
> could be done in just a few lines given the existing code.
I'm personally OK either way with this.
>
> (2) No kwarg constraints in Partitions/Compositions should be mutually
> exclusive. (I think there's a ticket for this but I can't find it
> now.)
>
> Partitions(15,length=5, parts_in=[1,3,4]) doesn't work, so you have to
> do an explicit filter. Optimizing it is a separate issue, but when
> there's a trivial way to implement the functionality (simply test that
> partitions satisfy the specified criteria before yielding them, in
> cases where we don't currently embed the constraints in the
> construction process itself), then ISTM we should do so now rather
> than wait for a more efficient implementation to appear.
> Functionality+speed > functionality, but functionality >>> no
> functionality.
>
> Currently, partitions_restricted's docstring says not to use it but to
> use RestrictedPartitions instead, which in turn says not to use
> RestrictedPartitions but to use Partitions with the "parts_in"
> keyword, which in its turn doesn't work.
You should probably email the sage-combinat list about this:
http://groups.google.com/group/sage-combinat-devel/
>
> (3) primes(10, infinity) should work.
>
> Since we're just calling next_prime, there's no reason to require the
> upper limit to be an integer. This bites me more than you'd think,
> because lots of (often uninteresting, but very error-prone) OEIS
> sequences are of the form "function-of (next prime > x s.t.
> something-or-other)" and I like functional programming styles.
> Wouldn't mind a proof=False option which calls next_probable_prime
> instead, either.
+1 to both suggestions. I don't see any reason for somebody not to
implement both of these. Great suggestions.
> (4) Probably this has already been discussed to death and presumably
> vetoed for sound reasons, but I don't see the point of complaining
> about whitespace issues at the end of a program after every
> non-whitespace character when Python doesn't.
I don't remember any discussion about this at all. It sounds like you
might have found a bug in the preparser. Could you post an example to
nail down exactly what you're talking about?
-- William
>
>
> Doug
>
> --
> Department of Earth Sciences
> University of Hong Kong
>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
IMO a*b = gcd(a,b)*lcm(a,b) should be maintained wherever possible.
There are pari codes whose direct Sage equivalent silently breaks for
this reason, and I can't bring myself to admit it to my pari-speaking
friends. :^)
> Could you post an example [re: my whitespace issues --ed] to nail down exactly what you're talking about?
sage: s = 'for i in range(3):\n' + ' '*4 + 'print i\n'
sage: # add extra space, such as can often happen in practice
sage: # when writing code, and I can't see it, because, well,
sage: # it's whitespace..
sage: s = s + '\n' + ' '*4 + '\n'
sage:
sage: fname = 'whitespace_pedantic.sage'
sage: with open(fname,'w') as fp:
....: fp.write(s)
....:
sage: # Python is happy
sage: execfile(fname)
0
1
2
sage: # Sage is not
sage: load(fname)
------------------------------------------------------------
File "<string>", line 5
^
SyntaxError: invalid syntax
>> (1) gcd is broken. http://trac.sagemath.org/sage_trac/ticket/10459[..]
> I'm personally OK either way with this.IMO a*b = gcd(a,b)*lcm(a,b) should be maintained wherever possible.
There are pari codes whose direct Sage equivalent silently breaks for
this reason, and I can't bring myself to admit it to my pari-speaking
friends. :^)
I think this should be fixed by trac ticket #9363 (merged in
sage-4.6.2.alpha1).
-Willem Jan
It is a question of domains. In Axiom you can specify the domains.
2/1 is a Fraction(Integer) aka rational
4 is an Integer
(2/1)::Integer => 2 where 2 is an Integer.
4::Fraction(Integer) is a Fraction(Integer)
So there are several cases:
gcd((2/1),4::Fraction(Integer)) => 1 of type Fraction(Integer)
gcd((2/1)::Integer,4)) => 2 of type PositiveInteger
gcd(2/1,4) => 1 of type Fraction(Integer)
gcd(2,4) => 2 of type PositiveInteger
gcd(2,4::Fraction(Integer)) => 1 of type Fraction(Integer)
Tim Daly
Thanks. The above is _precisely_ what Sage currently does:
sage: a = gcd(2/1,QQ(4)); print a, type(a)
1 <type 'sage.rings.rational.Rational'>
sage: a = gcd(ZZ(2/1), 4); print a, type(a)
2 <type 'sage.rings.integer.Integer'>
sage: a = gcd(2/1, 4); print a, type(a)
1 <type 'sage.rings.rational.Rational'>
sage: a = gcd(2, 4); print a, type(a)
2 <type 'sage.rings.integer.Integer'>
sage: a = gcd(2, QQ(4)); print a, type(a)
1 <type 'sage.rings.rational.Rational'>
I personally see no *harm* in allowing gcd(a,b) to be a different
choice of generator for the ideal (a,b), which is all that the OP is
requesting. PARI does this, and it is definitely very useful there.
Always returning 1 (or 0) in the rationals isn't very useful.
-- William
> 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"?)
> So, a coercion from QQ to ZZ would presumably be a morphism from QQ to
> ZZ in the category of unital rings - which doesn't exist.
Agreed.
> So, I think it is by far better to have a consistent notion than to
> have to *guess* whether a user really means the integer 2 if s/he
> write 4/2 (which in the first place is a rational, not an integer).
> Bugs that are result of guesswork are the most ugly, IMHO.
True. But in the case of Q (and more generally in the case of the
quotient field of a (principal?) ring), we can be consistent with the
ring of integers, without any guess-work.
(*) This is a white lie (see below).
Every rational number has a unique(*) form Product(p^(a_p), p prime)
for some integer powers a_p. The rational is an integer iff all a_p
are non-negative. In that case,
gcd(Product(p^(a_p)), Product(p^(b_p))) = Product(p^(min(a_p,b_p)))
and lcm is defined with max(a_p,b_p). But actually this definition
does not rely at all on the fact that the a_p and b_p are positive. So
we have a definition of the gcd and lcm for free on the quotient field
of any (principal?) ring. Then, gcd(x,y).lcm(x,y)=x.y; the notion
reduces to the one for integers, etc. This definition amounts to the
definition of lcm(x,y) as the smallest integer multiple of x which is
also an integer multiple of y.
(*) In fact, there is the issue of the sign, or more generally units
(elements that are invertible in the ring (here, ZZ) ). For this,
there has to be some arbitrariness on the sign of gcd and lcm of
negative numbers.
Note that for RDF and its colleagues, this does not apply (since they
are not the quotient field of any sensible ring), and we should stick
with the definition gcd(x,y)=1, however much x and y look like
integers.
Regards,
Bruno
Welcome to the Sage community!
On Wed, Feb 09, 2011 at 01:02:10PM +0800, D. S. McNeil wrote:
> (2) No kwarg constraints in Partitions/Compositions should be mutually
> exclusive. (I think there's a ticket for this but I can't find it
> now.)
>
> Partitions(15,length=5, parts_in=[1,3,4]) doesn't work, so you have to
> do an explicit filter. Optimizing it is a separate issue, but when
> there's a trivial way to implement the functionality (simply test that
> partitions satisfy the specified criteria before yielding them, in
> cases where we don't currently embed the constraints in the
> construction process itself), then ISTM we should do so now rather
> than wait for a more efficient implementation to appear.
> Functionality+speed > functionality, but functionality >>> no
> functionality.
Annoying, huh? This has bothered us ever since IntegersListLex was
first implemented in MuPAD 9 years ago :-)
In principle one of the goals of the upcoming Sage Days in Acadia in
May is to reimplement IntegersListLex
(http://trac.sagemath.org/sage_trac/ticket/6538). I can't guarantee
that it will actually happen though. Volunteers are welcome to
implement a temporary fix. However one should be careful: the kwarg
options are *not* mutually exclusive as long as they are consistent
(for some loose definition of consistent), and this feature is used in
many places. So one should be careful not to slow things down in those
situations.
> Currently, partitions_restricted's docstring says not to use it but to
> use RestrictedPartitions instead, which in turn says not to use
> RestrictedPartitions but to use Partitions with the "parts_in"
> keyword, which in its turn doesn't work.
Specific examples welcome!
Best,
Nicolas
--
Nicolas M. Thi�ry "Isil" <nth...@users.sf.net>
http://Nicolas.Thiery.name/
It should switch to the side of Maxima/Pari/Mathematica/etc. in this.
-- William
It seems like nobody explained how the current gcd definition got
included. It's from a patch to rational.pyx from Alex Ghitza (who I
cc'd) that did this:
- d = self.denom()*other.denom()
- self_d = self.numer()*other.denom()
- other_d = other.numer()*self.denom()
- return self_d.gcd(other_d) / d
+ if self == 0 and other == 0:
+ return Rational(0)
+ else:
+ return Rational(1)
This was from trac 3214 "uniformise the behaviour of gcd for rational numbers":
http://trac.sagemath.org/sage_trac/ticket/3214
which was reported by Andrey Novoseltsev.
So if Andrey or Alex cared so much, they may want to pipe up.
This thread is at least:
William
The distinction is between ideals of Q (which are of course only (0)
and (1)) and sub-Z-modules of Q, a.k.a. fractional ideals (since in
the generalization to number fields K we (ab)use the terminology
"ideal of K" to mean "fractional ideal of K" which is the same as
"OK_submodule of K (of maximal rank)".
Every f.g. Z-submodule of Q is cyclic, and instead of the current
behaviour of gcd(x,y) for rationals (which is to give the generator of
the Q-ideal generated by x and y) the old -- and perhaps desired --
behaviour is to give the generator of the Z-module generated by x and
y. The latter is, of course, unique up to sign. It's the same as
Simon's generator of the sum of the Z-submodules generated by x and by
y. And then lcm(x,y) is the genrator of their intersection.
This way, both gcd(x,y) and lcm(x,y) are positive rationals (or 0 but
not when x and y are nonzero). And we have
gcd(x,y)*lcm(x,y) = abs(x*y)
which I think is a better convention for when x and/or y are negative
than deciding to make one of the gcd and the lcm negative.
John
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
Well, I used to use gcd for obtaining the primitive integral vector
with a specified rational direction. My concern on Trac 3214 was that
gcd(a1, ..., ak) depended on the order of arguments and I wanted it to
be fixed. The eventual solution was to agree that gcd as the "greatest
common divisor" does not really make much sense for fields, but
instead of raising an exception it can just return 1. This meant that
I cannot use it for my original purpose (not a big deal - it is easy
to do more directly), but I think that it was quite a sensible
decision:
1) I don't recall seeing gcd of rational numbers in any book or paper
2) there is clearly no natural extension of this notion from ZZ to QQ
3) the name itself indeed is very strange applied to fields.
So I personally think that any kind of gcd/lcm combinations of
numerators/denominators of rational numbers should have some other
more appropriate names, since making up some conventions for gcd is
potentially dangerous and may make code using it harder to understand
if a reader thinks of gcd differently than the original author...
@Simon: You are right to distinguish the two kinds of consistencies.
And I can understand that sometimes it is preferable to have the
algebraic consistency. I tend to care about elements of the objects
more than the objects of the category (i.e. individual rational
numbers rather than the field/PID/quotient field QQ), and thus I tend
towards subring consistency.
> You could have both consistencies. That depends on how you define gcd
> and lcm:
>
> - Quotient fields as described by Bruno.
> - Fields: zero if both elements are zero. A non-zero element
> otherwise (most fields would choose 1 here).
> - PID: a generator of the corresponding ideal.
I don't see how this brings in both consistencies. Algebraic
consistency requires gcd and lcm on QQ to have different outputs
depending on whether QQ is seen a Field, a PID, a Quotient Field... Is
there a clear way for the user to indicate "which QQ" he wants?
Or we could have (I don't really know how this is done ;-) )
lcm(10/21, 14/15, type="PID") = 1
lcm(10/21, 14/15, type="Field") = 1
lcm(10/21, 15/14, type="quotient-of-ZZ") = 30/7
I doubt that the "field" version is useful at all: the lcm is
basically always 1 (except when one of the arguments is zero). lcm and
gcd should only be defined for PIDs, where they are interesting (or
for factorization rings? I can't remember my undergrad).
Interesting read, thanks.
Tim Daly
FWIW, I just noticed that Mathematica treats 2/1 as an integer and not
as a rational.
In[1]:= Head[2]
Out[1]= Integer
In[2]:= Head[1/3]
Out[2]= Rational
In[3]:= Head[2/1]
Out[3]= Integer
Tim Daly
This is version 7.0 - the latest is 8.0
In[2]:= GCD[2/1,4]
Out[2]= 2
You can try this in Wolfram|Alpha too, which uses the latest Mathematica (8.0).
Just go to
and type in "GCD[2/1,4]"
A direct URL is actually:
http://www.wolframalpha.com/input/?i=GCD[2%2F1%2C4]
What is interesting is that Wolfram|Alpha shows an alternate expression too:
8/LCM[2,4]
If I evaluate that in Mathematica, I get:
In[6]:= 8/LCM[2,4]
Out[6]= 2
If you ever want to know the output from Mathematica, you can try typing it in
Wolfram|Alpha. Obviously Wolfram|Alpha does not have the full functionality of
Mathematica exposed, as otherwise nobody would buy Mathematica. But a fair
amount of it seems to be available.
Using Wolfram|Alpha is a lot easier if you know the Mathematica expression.
Using the text a human would type is a lot more tedious, though typing "whats
the greatest common divider of 2 divided by one and 4?" does actually get the
right result.
http://www.wolframalpha.com/input/?i=whats+the+greatess+common+divider+of+2+divided+by+one+and+4%3F
Dave
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
My single most common use involves parts_in, though, and that's what doesn't
work: Partitions(10, min_length=2, max_length=6, parts_in=[1,2,3,5])
is a completely
consistent set of constraints, but it silently drops two of them, as
the docs warn. (I'm telling
you what you already know, of course, but this was the first case
which started to cause
me problems.) There are lots of OEIS sequences which involve
partitions restricted to
some set, so I have to write Partitions(10,
parts_in=[1,2,3,5]).filter(lambda x: 2<= len(x) <= 6)
or some such variant, which it'd be really nice to avoid.. I even
have lots of use cases where
it'd be nice to be able to use min_part and parts_in simultaneously,
cases where it's more natural
to build the parts_in list once.
Doug
--
Department of Earth Sciences
University of Hong Kong
Forgive my being a bear of little brain, but I've yet to grasp why
defining the default gcd rational function to be equal to 1 or (from
Simon) the lcm equal to 1 would be a _useful_ thing to do, independent
of the existence of perspectives from which it's the right
generalization. Who is going to call such a function? Who uses the
current rational gcd behaviour?
(.. I have a sneaking suspicion that the reason the rational lcm
behaviour doesn't currently match the rational gcd behaviour is
because these functions aren't getting a lot of exercise, not even by
people strongly in the gcd(2/1,4)=1 camp.)
The Pari/Mma/(Sage lcm+Maxima gcd) behaviour has pretty much
everything I want. Agrees with integer values when denominator is 1,
and so obeys least-surprise principles; is informative; preserves many
nice properties of positive integer gcd/lcm; is used in many other
places. The current Sage rational gcd behaviour surprised the heck
out of me and did so silently; returns 1 for all arguments and so is
minimally informative; doesn't preserve said nice relationships; and
doesn't match the behaviours of any of Pari, Mma, Maple, Maxima, or
Magma -- it doesn't even match Sage for lcm.
If the above doesn't speak to you in favour of the former I don't know
what else to say; we clearly have very different perspectives on
design!
If we do wind up defining gcd and/or lcm to be l, could we at least
define new short-named functions, say rgcd and rlcm, which do what
(IMHO) they should? Then I can simply explain to people "Oh, in Sage
we use 'rgcd' and 'rlcm' for gcd and lcm" and forget I brought this up
in the first place. :^)
Ah, ok; that's a different story. Structurally, parts_in can't be
treated by the generic IntegerListsLex tool, so the rewrite of the
latter is not going to improve the situation. One instead needs to
treat it specifically, or probably best using species as they could
handle efficiently parts_in together with min_length and
max_length. Patch welcome!
Cheers,
Nicolas
--
Nicolas M. Thi�ry "Isil" <nth...@users.sf.net>
http://Nicolas.Thiery.name/
That was me. I think this has been a great discussion.
I vote for changing the defn of sage rational gcd to match the
"Pari/Mma/(Sage lcm+Maxima gcd) " convention. Since +1 isn't having
the desired effect, I vote with my BDFL powers instead.
Somebody post a patch.
- william
>
> Doug
>
> --
> Department of Earth Sciences
> University of Hong Kong
>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
Simon
--
You received this message because you are subscribed to the Google Groups "sage-nt" group.
To post to this group, send an email to sag...@googlegroups.com.
To unsubscribe from this group, send email to sage-nt+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sage-nt?hl=en-GB.
You can in Sage too. The question is whether 1 is the right answer for
the domain of rational numbers. (That's what it currently does, just
like Axiom, but it's not very useful.)
> 2/1 is a Fraction(Integer) aka rational
> 4 is an Integer
> (2/1)::Integer => 2 where 2 is an Integer.
> 4::Fraction(Integer) is a Fraction(Integer)
>
> So there are several cases:
> gcd((2/1),4::Fraction(Integer)) => 1 of type Fraction(Integer)
> gcd((2/1)::Integer,4)) => 2 of type PositiveInteger
> gcd(2/1,4) => 1 of type Fraction(Integer)
> gcd(2,4) => 2 of type PositiveInteger
> gcd(2,4::Fraction(Integer)) => 1 of type Fraction(Integer)
>
> Tim Daly
>
>
>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>