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