[Edu-sig] computer algebra

Guido van Rossum guido at python.org
Mon Dec 15 00:39:18 CET 2008


But fractions *can* eat fractions. Instead of Fraction(f1, f2) you
just write f1/f2. In general you should just stick to the latter, and
leave the Fraction() constructor for when the / operator would pick a
different type (as in 1/2, which becomes a float). You can also write
it as Fraction(1) / Fraction(2).

--Guido van Rossum (home page: http://www.python.org/~guido/)



On Sun, Dec 14, 2008 at 3:05 PM, kirby urner <kirby.urner at gmail.com> wrote:
> On Wed, Dec 10, 2008 at 6:47 PM, kirby urner <kirby.urner at gmail.com> wrote:
>
> << SNIP >>
>
>> fractions.Fraction, on the other hand, barfs on anything but integers,
>> isn't trying to be all divisions to all possible types, isn't
>> pretending this is Mathematica or a generic CAS.
>>
>> Note that I'm not criticizing fractions.py in any way, am so far quite
>> happy with it.  I'm simply drawing attention to some fine points.
>>
>
> OK, now I'm going to criticize a little.
>
> I think the more natural and useful choice would be to continue
> threads right here on edu-sig, regarding a Rational Number type, not
> just this Fraction type.
>
> The problem with Fraction is it's not actually much more than the
> notion of Ratio (how many times one fits in the other), whereas the
> Rational Number concept fits neatly in the sequence:  N < W < Z < Q <
> R < C, where < could be replaced with the "subset" symbol.  Those be
> Natural, Whole (Natural + 0), Integers, Rationals, Reals, and Complex
> respectively, except the Real type is quite problematic, is treated
> with Floats, Decimals and generators (iterable).
>
> The thing about Rationals is they're a field, closed under + and *,
> and therefore - and / (because of field properties).  So a Rational is
> able to eat other Rationals for breakfast i.e. (1/3) / (3/1) makes
> plenty of sense, and all integers are really just rationals in
> disguise i.e. 0 = 0/1, 1 = 1/1 etc.
>
> If Fraction could eat Fraction type objects, then we could have
> continued fractions more easily, have other fun.
>
> The silver lining here is fractions.py was actual named that, and not
> rationals.py, which means we still have a hole to fill, a more generic
> class, yet not too generic, not open to complex or matrix arguments,
> just to rationals, integers a subtype.
>
> Kirby
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>


More information about the Edu-sig mailing list