for / while else doesn't make sense

[Steven D'Aprano]

On Tue, 24 May 2016 12:29 am, Ben Bacarisse wrote:

> Ian Kelly <ian.g.kelly at gmail.com> writes:
> 
>> On Mon, May 23, 2016 at 2:09 AM, Steven D'Aprano
>> <steve+comp.lang.python at pearwood.info> wrote:
>>> Are you saying that the Egyptians, Babylonians and Greeks didn't know
>>> how to work with fractions?
>>>
>>> http://mathworld.wolfram.com/EgyptianFraction.html
>>>
>>> http://nrich.maths.org/2515
>>>
>>> Okay, it's not quite 4000 years ago. Sometimes my historical sense of
>>> the distant past is a tad inaccurate. Shall we say 2000 years instead?
>>
>> Those links give dates of 1650 BC and 1800 BC respectively, so I'd say
>> your initial guess was closer.
> 
> Right, but this is to miss the point.  Let's say that 4000 years have
> defined 1/3 to be one third, but Python 3 (as do many programming
> languages) defines 1/3 to be something very very very very close to one
> third, and *that* idea is very very very very new!  It's unfortunate
> that the example in this thread does not illustrate the main problem of
> shifting to binary floating point, because 1/2 happens to be exactly
> representable.

That's not really the point. I acknowledge that floats do not represent all
rational numbers (a/b) exactly. Neither do decimal floats -- most school
children will learn that 0.333333333333 is not 1/3 exactly, and anyone who
has used a calculator will experience calculations that give (say)
0.999999999 or 1.0000000001 instead of 1.

And you know what? *People cope.*

For all the weirdness of floating point, for all the rounding errors and
violations of mathematical properties, floating point maths is *still* the
best way to perform numerical calculations for many purposes.

In fact, even IEEE-754 arithmetic, which is correctly rounded and therefore
introduces the least possible rounding error, is sometimes "too good" --
people often turn to GPUs instead of CPUs for less accurate but faster bulk
calculations.

The point is, most people wouldn't really care that much whether 1/3
returned a binary 0.3333333333, or decimal 0.3333333333, or an exact
rational fraction 1/3. Most people wouldn't care too much if they got
32-bits of precision or 64, or 10 decimal places or 18. When cutting (say)
a sheet of paper into three equal pieces, they are unlikely to be able to
measure and cut with an accuracy better than 1/2 of a millimeter, so 15
decimal places is overkill.

But one thing is certain: very few people, Jon Ribbens being one of them,
expects 1/3 to return 0. And that is why Python changed the meaning of
the / operator: because using it for integer division was deeply unpopular
and a bug magnet.



-- 
Steven