It has been noted that int/int=int results in more information loss than
int/int=float.  Based on this, it has been proposed that
anything/anything return float.  This got me wondering about long ints.

Given that a long int can have an unlimited number of digits (easily
into the thousands), the result of a long/long could also be an
unlimited number of digits (considering just the integer part).

Given that a float can only represent about a dozen or so digits of
precision, the precision loss due to float conversion could be much
greater than the precision loss due to dropping the fractional part of
the long division.  It's as if you're compressing an unlimited amount of
information into 8 bytes.

Also consider that float can only represent numbers up to about 1e308. 
Any result >  308 digits would result in a float "inf" - total
information loss.

I therefore argue that long int division should not result in a float.

There have been discussions about a unified numeric model for python. 
One suggestion is to automatically promote to long int on int overflow. 
If int/int=float and long/long=long, auto-promoting int to long could
cause strange and unpredictable results.  However, if a/b=float for all
types, this would be unfortunate for the long/long case for the reasons
mentioned.

Are rationals the answer?  They would provide zero information loss for
integer division and consistent behavior between integers, rationals,
and floats.  So, if rationals are coming, is int/int=float just a
stopgap?  Is it worth the pain?

	Brent

_______________________________________________
Edu-sig mailing list
Edu-sig@[...].org
http://mail.python.org/mailman/listinfo/edu-sig