Re: [Edu-sig] Re: rationals
But it would look like this:
a = 3/2r b = 1/2r a * b (3/2r)
That won't do at all. (3/2)(1/2)==(3/4). I got terribly confused going from here to the decimal representation. (And I suppose I'll never be able to get implied division without a '*', while people are whining about ninny things).
float(a*b) 0.75
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?
The biggest difference is that some floating-point calculations that will converge (disappear at 0 or converge on a fixed value) will not terminate in rational computation. Since this sort of thing is not a very good way to use floats either, it should provoke more-appropriate numerical techniques. -- Dennis -----Original Message----- From: edu-sig-admin@python.org [mailto:edu-sig-admin@python.org]On Behalf Of Lloyd Hugh Allen Sent: Friday, October 11, 2002 17:52 To: edu-sig@python.org Subject: Re: [Edu-sig] Re: rationals [ ... ] 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? _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
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
participants (3)
-
Dennis E. Hamilton -
Kirby Urner -
Lloyd Hugh Allen