Re: [Edu-sig] Rational Division
This is from a response to a question about rational division on the Edu-SIG list. On Sat, 5 Feb 2000, Ka-Ping Yee wrote:
In E, there are two operators for division:
2 / 3 yields 0.666666
2 _/ 3 yields 0
Read "_/" as "floor-divide". (See http://www.eright.org/elang/grammar/expr.html.)
Note that in the current Python, if a and b are integers and f is the floating-point result of dividing a by b, then a/b is *not* equal to int(f). It's equal to math.floor(f).
Then i realized that math.floor returns a float. So, really, in order to replace the old /, a / b becomes import math int(math.floor(a / b)) As long as we're going to push forward into the realm of sanity (and i'm in support of this change!) do we need an easier way to spell this to help folks convert? I rather like E's "_/" operator, but that may be harder to swallow here since "_" goes in Python identifiers. E allows "_" in identifiers too, but you can use spaces to avoid ambiguity, e.g.: a _/ b # parses as 'a' floor-divide 'b' a_/b # parses as 'a_' float-divide 'b' But perhaps that is just too arcane for Python. "//" was also considered for a floor-divide operator for a while, but Java-style comments won out. So do we go for a new operator, or put a 'div()' in __builtins__, or what?
int() truncates, always rounding towards zero (an abomination in my opinion!), while floor() rounds down.
This is also possibly an Edu-SIG question, but don't you think it would be nice to have a round() built-in? I can see it being invaluable for classroom and scientific work. Something like: def round(x): return int(math.floor(x + 0.5)) or even: def round(x, unit=1): return int(math.floor(x / unit + 0.5))*unit -- ?!ng "If I have not seen as far as others, it is because giants were standing on my shoulders." -- Hal Abelson
[Ping]
... Then i realized that math.floor returns a float. So, really, in order to replace the old /,
a / b
becomes
import math int(math.floor(a / b))
Defining this in terms of math.floor is a mistake, because long ints can easily exceed the precision of a C double.
As long as we're going to push forward into the realm of sanity (and i'm in support of this change!) do we need an easier way to spell this to help folks convert?
We need an easier way to spell this just so that it works.
I rather like E's "_/" operator, but that may be harder to swallow here since "_" goes in Python identifiers. E allows "_" in identifiers too, but you can use spaces to avoid ambiguity, e.g.:
a _/ b # parses as 'a' floor-divide 'b'
a_/b # parses as 'a_' float-divide 'b'
But perhaps that is just too arcane for Python.
Python uses "maximal munch" lexing, so it would naturally do these same things; but Guido has avoided *relying* on MM so far as possible (e.g., it's relied on to parse """a""" as a single (triple-quoted) string instead of as the catenation of 3 single-quoted strings).
"//" was also considered for a floor-divide operator for a while, but Java-style comments won out.
Looks natural for Python! I'm not sure what "/" should *do* in the Brave New World, though. Floating-point has been the conventional answer so far, but I'd like to take another look at what Scheme does (not sure what the std sez, but every Scheme I've ever used treated integer division as returning a rational). The *prime* motivation here seems to be that "7/3" not lose catastrophic amounts of information silently; other clear choices are "lose none" (rationals) and "maybe lose a little in a way that's very hard to explain" (floating point).
.. This is also possibly an Edu-SIG question, but don't you think it would be nice to have a round() built-in?
Guido hopped in his time machine and added this to Python 1.0 <wink>:
round <built-in function round> print round.__doc__ round(number[, ndigits]) -> floating point number
Round a number to a given precision in decimal digits (default 0 digits). This always returns a floating point number. Precision may be negative.
I can see it being invaluable for classroom and scientific work.
Indeed <wink>.
Tim Peters
Looks natural for Python! I'm not sure what "/" should *do* in the Brave New World, though. Floating-point has been the conventional answer so far, but I'd like to take another look at what Scheme does (not sure what the std sez, but every Scheme I've ever used treated integer division as returning a rational). The *prime* motivation here seems to be that "7/3" not lose catastrophic amounts of information silently; other clear choices are "lose none" (rationals) and "maybe lose a little in a way that's very hard to explain" (floating point).
I agree with you in preferring the "let's do rationals" answer. Seems to me I recall one of the other points in the Alice presentation was that non-techies find floating point obscure and think of simple fractions as atoms. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> The saddest life is that of a political aspirant under democracy. His failure is ignominious and his success is disgraceful. -- H.L. Mencken
[posted & mailed] [Tim, on integer division]
... I'd like to take another look at what Scheme does ...
I have since been reminded that the Scheme std isn't helpful: may return a rational, may return a float, may return darn near anything at all -- and may even vary depending on the specific arguments. There's no language std I know of more carefully crafted to ensure programs will be unportable except for Fortran's <1/4 wink>.
The *prime* motivation here seems to be that "7/3" not lose catastrophic amounts of information silently; other clear choices are "lose none" (rationals) and "maybe lose a little in a way that's very hard to explain" (floating point).
[Eric S. Raymond]
I agree with you in preferring the "let's do rationals" answer. Seems to me I recall one of the other points in the Alice presentation was that non-techies find floating point obscure and think of simple fractions as atoms.
I didn't say what I preferred <wink>. Seriously, Guido & I corresponded about Python's numerics when the language was being designed, and agreed that ABC's default use of rationals didn't work out well: "simple little" numeric programs suffered wildly unpredictable space and time use (rationals can "blow up" very quickly). Have to say that hasn't been my experience in other languages, though -- so I want to go back & see if there was something else about ABC that conspired to produce this unhappy outcome. Offhand, I seem to recall that fp in ABC had a "tacked on" look & feel that made it clumsy to get at; or maybe the docs just sucked; or maybe ... The horrid thing about fp is that it gets *more* obscure the more you learn about it -- until reaching "fp expert" level, which is a journey that takes years, deliberate study, and lots of numeric scars. REXX's decimal fp is also an idea (it's my impression that most newbie problems with fp are due to the "accidental complexity" introduced by using bounded binary fractions to represent bounded decimal fractions: this loses info for reasons that "make no sense" in a world of decimal hand calculators and paper arithmetic). we-can't-win-but-we-can-choose-how-to-lose<wink>-ly y'rs - tim
participants (3)
-
Eric S. Raymond -
Ka-Ping Yee -
Tim Peters