FWD: Lore about Division

[kirby.urner at gmail.com]

Alan:  2^(1/2)

Kirby: Also pow(2, 0.5) in Python.

Alan: Gee, I wonder if pow(2, (1/2)) also works in Python?

Kirby:

It does if you remember integer division in earlier
versions, such that one needed:

from __future__ import division

or, simply made it 1./2 or 1/2. or something, to force
a floating point answer.

In 3.x, division is natively floating, with // to force
an integer output.

[ EDITOR'S NOTE:  not quite right, may be floating type output with
integer value ]


This is Python 3.1, right out of the box:

>>> pow(2, 1/2)
1.4142135623730951

Alan:

That reminds me of FORTRAN
http://en.wikipedia.org/wiki/Fortran_language_features#Implicit_and_explicit_typing

"Unless specified otherwise, all variables starting with letters I, J,
K, L, M
and N are default INTEGER, and all others are default REAL; other data
types
must be explicitly declared. This is known as implicit typing and is a
heritage
of early FORTRAN days."

Kirby:

I think the original intent was something like "closure" i.e.
int / int should give int, whereas float / float or float / int
or int / float should coerce float answer, and that is how it
was done.

However it was later realized, by Guido and others, that in
source code, when you see a / b, you really have no way of
knowing what's going through there, i.e. a and b might name
anything, so it gets hard to debug if the behavior is so
dependent on 1 versus 3 use cases. Better to just have a
consistent float output, no matter what. Then use // if you
want to force an integer value output, even if you input floats
to get floats back:

>>> 1.//2.
0.0
>>> 1/2
0.5
>>> 3.//2.
1.0

It's quite basic to a language, how it deals with division, so
Guido had to devise a scheme that would let the snake "shed its
skin". Already, the brand name (Python) was in his favor, as
that's what Pythons do (shed skin). A lot of basic changes piled
up, including a more complete move to a Unicode basis for source
files. If you're going to break backward compatibility, might as
well do a lot of breaking all at once.

As of this writing, we're on the other end of it, having made the
leap from 2.x to 3.x. The backward incompatibility gap has been
crossed. However, a number of important libraries and other assets
still need to bring up the rear, so a new PEP (Python Enhancement
Proposal) has been accepted, to freeze Python for awhile, in terms
of its core syntax and semantics. Give the library people some
breathing room. This seems a good plan.

[ original context:  http://groups.yahoo.com/group/synergeo/ ]