[Edu-sig] Re: rationals

[Douglas S. Blank]

[Apologies if this rational number issue is a dead horse; I've just 
joined the discussions recently. I've included some possible thoughts 
about perception from novice users. -Doug]

Guido van Rossum wrote:

>>rat() or rational()  ?
> 
> 
> I think rat() is good -- after all I shortened 'dictionary' to 'dict'...

You could also use ratio(), but rat() does seem to go with pythons better.

 >     int   / int   --> float     (float//float --> int)
 >     float / int   --> float     (int//int     --> int)
 >     rat   / int   --> rat   (?) (rat//rat     --> int)
 >     rat   / float --> float
 >     rat   / rat   --> rat

At first glance, this table seemed to create an asymmetry. Before the 
introduction of rationals, it seemed that / was a "float" division 
operator and produced only floats regardless of the operands (a good 
thing). And // was an "int" operator and produced only ints.

There are two ways around the apparent assymetry: 1 - result type is 
based on operator, or 2 - is based on a hierarchy of the operands. I see 
now that the proposal is to do both, with the following assumptions.

Method 1. // is the "integer" division operator. If we define a 
"rational" division operator (maybe represented by ///, or maybe not 
defined syntactically) to return rats and only rats, regardless of input 
types:

 >>> int   /// int => rat
 >>> float /// int => rat
 >>> rat   /// int => rat

Method 2. The result type of "/" is based on a hierarchy of the 
"highest" precision type. The heirarchy (apparently) is:

int -> rational -> float

which does match the original table. (Although the hierarchy seems 
arbitrary since rational seems to have higher precision than float). If 
you define a rational division operator, and state this hierarchy, then 
the asymmetry goes away. (Although, I'm not sure where to put imaginary 
and scientific representations).

Further asymmetries are found in examining other operators. For example, 
a beginner might guess:

float * float --> float
int   * int   --> float
float * int   --> float
rat   * int   --> rat
rat   * float --> float
rat   * rat   --> rat

And even worse:

float ** float -> int

(by making the analogy "if / ==> *, then // ==> **"). I am assuming that 
the other operators will be based on hierarchy only (I assume the one 
above). That is:

rat * float --> float
float * int --> float
rat * int   --> rat

As far as interactively displaying rationals goes, the "r" and parens 
seem unnecessary and could lead to confusion. We humans will parse it 
correctly. Although, if you wanted to be able to cut output and paste it 
as input, then you woud want to keep the input and output formats the same.

-Doug

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

-- 
Douglas S. Blank,         Assistant Professor
dblank@brynmawr.edu,            (610)526-6501
Bryn Mawr College,   Computer Science Program
101 North Merion Ave,       Park Science Bld.
Bryn Mawr, PA 19010  dangermouse.brynmawr.edu