PEP0238 lament

[Tim Peters]

[David Eppstein]
> Well then, float is a very bad choice for what to return, or then how
> do we explain when 3/4 * 4 = 3 (exactly) but 3/10 * 10 != 10? [3
> was intended here]

Using decimal floats, 3/10*10 does equal 3, but a generation raised on
BCD-ish hand calculators wouldn't even blink an eye if 1/3*3 returned
0.999999999999.

> I would be a lot happier with integer / integer = rational (as in
> Mathematica's programming lang),

That view has its fans too; see PEPs 239 and 240; also mounds of prior
discussion on the python-numerics list:

    http://sourceforge.net/mail/?group_id=5470

You're probably new enough to this to have missed that Guido had lots of
experience with rationals in the ABC language and didn't like it there.
Speed and memory consumption were unpredictable for non-experts, and could
vary wildly (factors of 1000s) for a fixed algorithm, depending on the
inputs.  Rationals aren't a cure-all, and the instant you throw a sqrt or
transcendental into the mix you're back to some form of fp anyway.

> but float is just ugly.  It is turning exact values (integers) into
> approximate ones (float) when I didn't tell it to.

If the language defines "/" as returning a float, then you told it to.  You
*almost* may as well complain that math.sqrt(2) turns an exact value into an
approximate one; but, e.g., when I use Macsyma, it doesn't lose information
there either.  Python isn't going to do symbolic computation by default, so
the question isn't whether to compromise, but where.

> It's almost as bad as if integer subtraction always truncated to 16
> bit values -- a lot of the time that would give sort of reasonable
> answers but it's a gratuitous approximation where you didn't expect
> one.

You don't expect an approximation in that context because Python promises
not to make one in that context.  If you expect things a language doesn't
promise, that's not really the language's fault <wink>.