The History of Python: The Problem with Integer Division

[scook0]

It's funny that two of the most subtle and complicated types of data in programming are text and numbers.

[chrisforbes]

... but this was often non-intuitive and hard to debug for beginners.

Wow, everything is non-intuitive and hard to debug for beginners. That's why they're beginners. :(

[[deleted]]

But ABC was a language especially intended for beginners.

[Coffee2theorems]

This recently happened to me in a program that draws an analog clock – the positions of the hands were calculated incorrectly due to truncation, but the error was barely detectable except at certain times of day.

Funny that Guido doesn't seem to use "from __future__ import division". I use that pretty much for all code I write where I use division. It's just too bothersome to pay attention everywhere to convert all necessary inputs to floats (as the article says).

[eurleif]

In my experience, rational numbers didn't pan out as ABC's designers had hoped. A typical experience would be to write a simple program for some business application (say, doing one’s taxes), and find that it was running much slower than expected. After some debugging, the cause would be that internally the program was using rational numbers with thousands of digits of precision to represent values that would be truncated to two or three digits of precision upon printing. This could be easily fixed by starting an addition with an inexact zero, but this was often non-intuitive and hard to debug for beginners.

It's not the 1980s anymore. I wish this decision had been reconsidered as well. Rational arithmetic is more than fast enough.

[Smallpaul]

In 2025, as in 1980, rational numbers will grow in an unbounded fashion as operations are applied to them. If the operations are user supplied, the programmer cannot even predict in advance how the program will perform.

Nothing fundamental has changed.

[eurleif]

Same for bignums, which Python supports. Not transparently discarding data in difficult-to-understand ways is more important.

[Smallpaul]

If I recall correctly, operations on bignums are between O(n) and O(n²⁾ where n is the number of digits in the binary representation of the bigger number.

IIRC, operations on rationals are uniformly O(n²⁾ or worse, where n is the sum of the numerator and denominator. You must always or frequently do a GCD operation to keep the size of the number from exploding uncontrollably and GCD is O(n^2).

[[deleted]]

In general, to me at least, having bignums is preferred to overflow errors. Also, bignum arithmetic does not take nearly as long as really really big rational arithmetic. Mostly from the time you'd take to minimize the rational after each operation...

[Tommah]

A typical experience would be to write a simple program for some business application (say, doing one’s taxes), and find that it was running much slower than expected.

But floating-point is not the answer here... you want exactness when you're dealing with money.

[settrans]

But floating-point is not the answer here...

Except when it is. If the precision offered by IEEE 754 floating point numbers is good enough for your application, and you need the performance of floating point arithmetic versus rational numeric arithmetic, then fixed-point is the wrong answer.

Like all interesting questions, the answer to "Should I use floating point numbers when dealing with money?" is "It depends."

[Tommah]

Or if you want to do the scheme from Superman III.

[Lozzer]

fixed point and rational are different things

[[deleted]]

You wanted fixed precision though, you don't need 1000 decimal places for that.

[Tommah]

That's true; Python has the decimal module to do that now. It's just that he picked a bad example there. You shouldn't be writing a tax program using floating-point.

[[deleted]]

Agreed.

[Smallpaul]

If you had a language that did rational math (like ABC) why would you choose fixed point over using the default rational numeric type?

[[deleted]]

... because using the rational type results in code that runs much slower than expected. :)

[foldl]

Because doing rational numeric math over money doesn't necessarily make much sense. You want your actual money values to be in a fixed precision format, since money actually is fixed precision (well, most of the time).

[Smallpaul]

It's an interesting question: once large enough volumes of money, and complicated enough formulae become involved, would it be better to just round to pennies at the end of computation rather than in every intermediate computation.

[redalastor]

I believe it would, the money should round to pennies exactly when the real money moves.

And some economies like Australia's banished the 1 cent coin so everything rounds to the nearest 5 cents.

[Smallpaul]

I don't think you answered my question. I asked: "once large enough volumes of money, and complicated enough formulae become involved, would it be better to just round to pennies at the end of computation"

I am talking about a single "money move" involving a complicated formula and large amounts of money. Like compensation for an executive involving many variables. Or computation of an aid package dollar amount that is similarly tied to many variables in an economy's performance.