[Edu-sig] Re: rationals

[Kirby Urner]

At 08:52 PM 10/11/2002 -0400, Lloyd Hugh Allen wrote:

>Here's a question from someone who hasn't used rationals outside of
>Mathematica, TI-89/92, some sort of weird Casio, and the like, mostly in
>an interactive basis, on an issue that people had later in the thread:
>besides the representation given by the "print" command, how would code
>be affected if the programmer expected a float and the engine had been
>upgraded to return a rational instead? What would break?

It's not just a question of what would break, either.  It's also a
question of whether I want the extra overhead of CPython internally
managing numerators and denominators when inverting a matrix (say).

If I start with a matrix of integers and invert it, it'll take a
lot longer to return rational results.

   >>> matrix  # some object
1 _2  3
5  7 _1
2  9  8

Floating point inverse:

   >>> matrix.inverse()

  0.268595   0.177686 _0.0785124
_0.173554 0.00826446  0.0661157
  0.128099  _0.053719  0.0702479

Rational inverse:

   >>> matrix.inverse()
  65/242r  43/242r -19/242r
-21/121r   1/121r   8/121r
  31/242r -13/242r  17/242r

Internally, these two are vastly different, in terms of both
CPU cycles and algorithms.

Presumably if I start with all elements in a matrix rational,
I want a rational inverse (2nd form).  But what if just one
element is rational and the rest are integers?  I think we're
going to get floating point answers, because a lot of the
divisions won't "know" there's a rational in the picture
(and int/int-->float).

With the regime currently under consideration in this thread,
I think there'll be a bias for complicated multi-variable calcs
to "decay" into floats, unless they start with rats and only
rats.  Alternatively, you can write a matrix routine that
starts by converting everything it gets to rats, e.g. running
matrix.rinverse(), even on ints, would get a rational output
(but on floats?).

Kirby