a *= b not equivalent to a = a*b

Jussi Piitulainen jussi.piitulainen at helsinki.fi
Fri Aug 26 06:38:16 EDT 2016


mlz writes:

> It's true that a*(b/c) yields fractions which would probably accrue
> accuracy errors depending on how those values are implemented. For
> example, it is possible to represent 1/3 internally as two numbers,
> numerator and denominator, thus avoiding the repeating decimal (or
> binimal, or whatever it's called). I believe there are languages that
> preserve exact accuracy in this way for rational fractions. I don't
> know if Python is one of them.

Python doesn't and isn't. Exact fractions are available in the standard
library, but the notation 1/3 gives a floating point approximation.

Floating point arithmetic is usually supported directly in the hardware
in bounded space (64 bits per number). Exact rationals can acquire huge
numerators and denominators surprisingly fast, slowing the computations
down. It's a tradeoff. It's good to know about both.

> On the other hand, (a*b)/c is safer since in this case (for the
> binomial coefficient) it always yields an integer.

When you compute them in that specific way, walking the numerator down
and denominator up.



More information about the Python-list mailing list