for / while else doesn't make sense

[Jon Ribbens]

On 2016-05-24, Steven D'Aprano <steve at pearwood.info> wrote:
> On Tue, 24 May 2016 03:09 am, Jon Ribbens wrote:
>> On 2016-05-23, Steven D'Aprano <steve at pearwood.info> wrote:
>>> 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.
>> 
>> Making it return floats is also a bug magnet, just for more subtle
>> bugs that are harder to diagnose.
>
> Floating point arithmetic does contain traps for the unwary, sometimes very
> subtle ones. But they aren't *bugs* -- they're inherent in the nature of
> floating point arithmetic.

You seem to be repeatedly changing your mind as to which behaviours are
"bugs" and which are not. I didn't say that floating point is buggy
(whatever that would even mean), I said that using it attracts bugs
due to people misunderstanding how it works.

> In Australia, we have an 11% consumption tax, the GST. I cannot tell you how
> many times I've needed to add a 1 cent "Rounding" amount on invoices to get
> the results to work out correctly.

Indeed. Using floats for currency calculations is one of the many
traps they present, and an excellent example of why their use should
not be encouraged.

> E.g. if an item costs $17 including tax, then you have a choice in
> rounding the tax-free cost down to $15.31 or up to $15.32,

I very much doubt that you have any such choice - it will usually
be specified by the tax regulations. The correct way to do currency
stuff is either integers or Decimal.

> Using integers in this case is not only *harder* than using floats, but it's
> more likely to go wrong. Because integer division always rounds down,
> errors accumulate faster than with floats, where calculations will be
> correctly rounded to minimize the error.

You are falling into the float trap again. This is not how you do
accounting.