Floating point bug?

[Paul Rubin]

Recheck the context. I was talking about the natural result, not
natural numbers.

The natural result of doing arithmetic with natural numbers is more
natural numbers.

 

[Ross Ridge]

http://en.wikipedia.org/wiki/Natural_number

Recheck the context. I was talking about the natural result, not
natural numbers.

The natural result of doing arithmetic with natural numbers is more
natural numbers.

D'Arcy said nothing about natural numbers, and bringing them up adds
nothing to this discussion.

Ross Ridge

 

[Paul Rubin]

D'Arcy said nothing about natural numbers, and bringing them up adds
nothing to this discussion.

The numbers D'Arcy is proposing to operate on that way are natural
numbers whether he says so or not.

Really, the "natural" division operation on integers, if there is one,
is divmod (which returns a quotient and remainder). The / (now called
//) operator simply throws away the remainder.

 

[Grant Edwards]

The natural result of doing arithmetic with natural numbers is more
natural numbers.

OK, but I thought we were talking about computer integers.

 

[Grant Edwards]

Hallöchen!

[...]

Nope. I would prefer that int OP int always produce an int.

And 2**-1?

An error.

Your formulation tries to suggest some sort of logical
consequence but in my opinion, it's still a mere matter of
taste and habits. I remember my first steps in C++ 12 years
ago when I tried to implement a couple of astronomical
formulae, always getting false results because C++ calculated
3/4=0.

I think the only real reason for people prefering int/int=int
is that computers can deal with inteters better than with
floats, resulting in int-only arithmetic in computer
languages. However, I don't consider this a particularly good
reason.

Well, another reason is that there is existing code that
depends on int/int => int.

 

[Steven D'Aprano]

Integer division means integer result to me in a very real sense.

So, when you have five children over for a birthday party, and one cake,
do you say "Sorry kids, no cake for you: one cake divided by five is
zero"?

Of course you do, you big meanie. I think you catered for my 12th
birthday party.

 

[Torsten Bronger]

Hallöchen!

[...]

Nope. I would prefer that int OP int always produce an int.

And 2**-1?

An error.

? Not here.

Tschö,
Torsten.

 

[Ross Ridge]

D'Arcy said nothing about natural numbers, and bringing them up adds
nothing to this discussion.

The numbers D'Arcy is proposing to operate on that way are natural
numbers whether he says so or not.

No, the discussion has been about the behaviour of the division operator
in Python when used with Python's integral and floating-point data types.
These data types include many numbers that are not natural numbers.

Really, the "natural" division operation on integers, if there is one,
is divmod (which returns a quotient and remainder).

Then either your definition of "natural" is wrong, or the fact that
something is the "natural" way of doing something doesn't mean it should
be done that way in Python.

Ross Ridge

 

[Arnaud Delobelle]

So, when you have five children over for a birthday party, and one cake,
do you say "Sorry kids, no cake for you: one cake divided by five is
zero"?

Of course you do, you big meanie. I think you catered for my 12th
birthday party.

Whereas I bet you would be able to share the cake equally and each
child would get 0.20000000000000001 of a cake

Or perhaps it would be better to have 2**n guests...
Or maybe one should think of the cake as 1.0 cake, as experience shows
that cakes can be cut...

 

[Steven D'Aprano]

I am really having a hard time accepting that "TRUTH (tm)" is determined
by election.

But you're apparently perfectly comfortable that "TRUTH (tm)" is decided
by fiat.

 

[Jeff Schwab]

So do you believe that you should not be able to do natural division
without explicitly casting ints as floats, or is your concern just that
you want to still be able to to integer division simply?

I think the issue is whether this qualifies as "natural" division in the
first place. (For the record, I'm only semi-old-school.)

 

[Jeff Schwab]

The natural result of doing arithmetic with natural numbers is more
natural numbers.

Back when I was just a wee little developer, I was taught that division
over the natural number was *not* a closed operation. (I still like
integer division, and I'm OK with the fact that it truncates.)

 

[Jeff Schwab]

Good one.

I make a lot of typo's on Usenet, so I'm always secretly relieved when
other people do, too. (IOW, thanks for being a good sport about it.)

 

[J. Clifford Dyer]

I think the issue is whether this qualifies as "natural" division in the
first place. (For the record, I'm only semi-old-school.)

OK. My use of the word "natural" was ill advised.

Sorry.

But I don't think that *was* the issue in the first place. The issue is
whether python's division should only yield integers when given integer
inputs. "Natural" is a polemical term no matter who is using it in this
argument, so lets drop it altogether. If the issue is that it should
remain an integer because that mimics how the computer works, than I
think it is worth pointing out that allowing a conversion to a long also
goes against how the computer works; the computer would have a register
overflow. If the issue is that in python the division operator has
always performed integer division, and should not change, then I think
we're talking about a philosophical opposition to Python 3 that goes far
deeper than just how integer division behaves.

At any rate, the whole argument is irrelevant--python already supports
floating point results for integer division, and that isn't going away,
but neither is integer division that always results in integer results,
so if you don't like getting floating point results, you never have to
use the / operator.

Practicality beats purity.

Cheers,
Cliff

 

[Paul Rubin]

If the issue is that it should
remain an integer because that mimics how the computer works, than I
think it is worth pointing out that allowing a conversion to a long also
goes against how the computer works; the computer would have a register
overflow. If the issue is that in python the division operator has
always performed integer division, and should not change, then I think
we're talking about a philosophical opposition to Python 3 that goes far
deeper than just how integer division behaves.

The issue is that python ints mostly act like mathematical integers
(modulo the artifact of the int/long dichotomy which is gradually
going away).

Certainly, I'd expect that if x and y are both integers and x is an
exact multiple of y, then x/y will be computable and not overflow.
But try computing 10**5000 / 10**4000 under future division (that is
supposed to give a float).

At any rate, the whole argument is irrelevant--python already supports
floating point results for integer division, and that isn't going away,
but neither is integer division that always results in integer results,
so if you don't like getting floating point results, you never have to
use the / operator.

I don't know of any other languages that support exact integers but
give you a floating point quotient. CL, Scheme, Haskell, and I think
ML all have exact rationals, which is what the thread is about. All
those scary pitfalls of intermediate results becoming unboundedly
complex simply don't seem to happen.

 

[Grant Edwards]

But I don't think that *was* the issue in the first place. The
issue is whether python's division should only yield integers
when given integer inputs. "Natural" is a polemical term no
matter who is using it in this argument, so lets drop it
altogether. If the issue is that it should remain an integer
because that mimics how the computer works, than I think it is
worth pointing out that allowing a conversion to a long also
goes against how the computer works;

I would have preferred that didn't happen either. I just don't
like implicit/automatic conversions from one type to another.

"If I wanted a long, I'd have used a long."

the computer would have a register overflow. If the issue is
that in python the division operator has always performed
integer division, and should not change, then I think we're
talking about a philosophical opposition to Python 3 that goes
far deeper than just how integer division behaves.

At any rate, the whole argument is irrelevant

Certainly. The decision has been made and it's not going to
change -- at least not until the next time it changes.

 

[Mark Dickinson]

Certainly, I'd expect that if x and y are both integers and x is an
exact multiple of y, then x/y will be computable and not overflow.
But try computing 10**5000 / 10**4000 under future division (that is
supposed to give a float).

And smaller numbers are problematic too:
9999999999.9999981

This despite the fact that the quotient *is* exactly representable
as a float...

Mark

 

[Mark Dickinson]

No, the discussion has been about the behaviour of the division operator
in Python when used with Python's integral and floating-point data types.
These data types include many numbers that are not natural numbers.

I'm surprised that no-one has mentioned duck-typing so far in this
discussion. After all, as I understand it the number one reason
for changing / in Python 3.0 is that the 2.x behaviour breaks duck
typing. Consider:

def mean(number_list):
return sum(number_list)/len(number_list)

If you pass a list of floats, complex numbers, Fractions, or Decimal
instances to mean() then it'll work just fine. But if you pass
a list of ints or longs, it'll silently return the wrong result.

True division and floor division are different operations. It doesn't
seem ridiculous to use different operators for them.

Mark

 

[Gabriel Genellina]

J. Cliff Dyer wrote:

Or Jo thinks // is a typo, and helpfully "fixes" it.

....like someone who "fixed" a raw string by removing the "r", and the
script mysteriously stopped working...

 

[Jeff Schwab]

And smaller numbers are problematic too:

9999999999.9999981

This despite the fact that the quotient *is* exactly representable

You know what I find weird about this? The result of truncating
division in this case is not just less accurate than it could be; it's
actually greater than the result of non-truncating division.
True