Floating point bug?

[Steven D'Aprano]

Automatic conversions, okay... but converting a result when all
inputs are of one time, NO...

What? How does that make any sense?

By that logic, we should see this:

len("a string") '8'
len([2, 4, 6]) [3]
len({'key': 'value'})

{1: None}

The only rule needed is very simple: promote simpler types to the
more complex type involved in the current expression (with expression
defined as "value operator value" -- so (1/2) * 3.0 is INTEGER 1/2,
resultant 0 then promoted to float 0.0 to be compatible with 3.0).

Very simple rule, used by very many traditional programming
languages.

And rightly rejected by many other programming languages, including
modern Python, not to mention calculators, real mathematics and common
sense.

 

[Carl Banks]

Automatic conversions, okay... but converting a result when all
inputs are of one time, NO...

People, this is so cognitive dissonance it's not even funny.

There is absolutely nothing obvious about 1/2 returning a number that
isn't at least approximately equal to one half. There is nothing self-
evident about operations maintaining types.

You people can't tell the difference between "obvious" and "learned
conventions that came about because in limitations in the hardware at
the time". Nobody would have come up with a silly rule like "x op y
must always have the same type as x and y" if computer hardware had
been up to the task when these languages were created.

Very simple rule, used by very many traditional >programming languages.

I'd be interested in hearing what languages those are.


Carl Banks

 

[Grant Edwards]

People, this is so cognitive dissonance it's not even funny.

There is absolutely nothing obvious about 1/2 returning a number that
isn't at least approximately equal to one half.

I guess obviousness is in the eye of the beholder. To me it's
obvious that "1" and "2" are integers, and it's also obvious
that 2 goes into 1 zero times.

There is nothing self-evident about operations maintaining
types.

By that logic, there's no reason for 1 + "two" shouldn't
convert one operand or the other.

You people can't tell the difference between "obvious" and "learned
conventions that came about because in limitations in the hardware at
the time".

It seems to me that the expectation that 1/2 yield 0.5 is just
as much a convention as that it yield 0 or a true rational.

 

[Torsten Bronger]

Hallöchen!

[...]

You people can't tell the difference between "obvious" and
"learned conventions that came about because in limitations in
the hardware at the time".

It seems to me that the expectation that 1/2 yield 0.5 is just as
much a convention as that it yield 0 or a true rational.

Should be set up a poll? Do you really think that less than 90% of
the voters would enter something else than 0.5 in the result edit
field?

Tschö,
Torsten.

 

[Carl Banks]

I guess obviousness is in the eye of the beholder. To me it's
obvious that "1" and "2" are integers, and it's also obvious
that 2 goes into 1 zero times.

2 goes into 1 0.5 times.

By that logic, there's no reason for 1 + "two" shouldn't
convert one operand or the other.

False dilemma, chief. That preserving type is not self-evident
doesn't make all operations that don't preserve type a good idea.

It seems to me that the expectation that 1/2 yield 0.5 is just
as much a convention as that it yield 0 or a true rational.

Sure it is, but unlike the old convention, it's the obvious one.


Carl Banks

 

[D'Arcy J.M. Cain]

Automatic conversions, okay... but converting a result when all
inputs are of one time, NO...

What? How does that make any sense?

By that logic, we should see this:

len("a string") '8'
len([2, 4, 6]) [3]
len({'key': 'value'})

{1: None}

I think that you have to show your work here. How does the above
statement about operators imply that the len method should return the
type of its argument?

And rightly rejected by many other programming languages, including
modern Python, not to mention calculators, real mathematics and common
sense.

Lost me again. I was not aware that calculators, real mathematics and
common sense were programming languages. Check out the definition in
http://en.wikipedia.org/wiki/Programming_language and others if you are
unclear. PLs are designed to communicate with machines. Even a
calculator is an application, not a language. This is an important
difference.

 

[D'Arcy J.M. Cain]

People, this is so cognitive dissonance it's not even funny.

I'll say.

There is absolutely nothing obvious about 1/2 returning a number that
isn't at least approximately equal to one half. There is nothing self-
evident about operations maintaining types.

Not obvious to you. You are using subjective perception as if it was a
law of nature. If "obvious" was the criteria then I would argue that
the only proper result of integer division is (int, int). Give me the
result and the remainder and let me figure it out.

You people can't tell the difference between "obvious" and "learned
conventions that came about because in limitations in the hardware at
the time". Nobody would have come up with a silly rule like "x op y
must always have the same type as x and y" if computer hardware had
been up to the task when these languages were created.

What makes you say they weren't? Calculating machines that handled
floating point are older than Python by far.

 

[J. Cliff Dyer]

Not obvious to you. You are using subjective perception as if it was
a
law of nature. If "obvious" was the criteria then I would argue that
the only proper result of integer division is (int, int). Give me the
result and the remainder and let me figure it out.

I'd like to point out that now you are talking about int OP int
returning a tuple, not an int.

 

[Ross Ridge]

Not obvious to you. You are using subjective perception as if it was
a law of nature. If "obvious" was the criteria then I would argue that
the only proper result of integer division is (int, int). Give me the
result and the remainder and let me figure it out.

I'd like to point out that now you are talking about int OP int
returning a tuple, not an int.

No, D'Arcy's point was that "obvious" isn't the criteria because it
would lead to behaviour that no one wants.

No one is going to win this argument by using words like "natural" or
"obvious". You're just going to have to accept that there that there
is no concensus on this issue and there never was. In the end only one
person's opinion of what was natural and obvious really matters.

Ross Ridge

 

[D'Arcy J.M. Cain]

I'd like to point out that now you are talking about int OP int
returning a tuple, not an int.

Which would be stupid. Good thing I don't think that "obvious" should
be the criteria.

 

[Paul Rubin]

Which would be stupid. Good thing I don't think that "obvious" should
be the criteria.

We already have that function (divmod) and it is very useful.

 

[D'Arcy J.M. Cain]

We already have that function (divmod) and it is very useful.

Yes it is and has nothing to do with this discussion. I don't think
that anyone here has suggested that methods should return the type of
their arguments although there have been a few suggestions that the
suggestions were made.

 

[Steven D'Aprano]

Automatic conversions, okay... but converting a result when all
inputs are of one time, NO...

What? How does that make any sense?

By that logic, we should see this:

len("a string") '8'
len([2, 4, 6]) [3]
len({'key': 'value'})

{1: None}

I think that you have to show your work here. How does the above
statement about operators imply that the len method should return the
type of its argument?

Consider the argument list to the function call len("a string").

args = ["a string"] # all the arguments
all(type(arg) == str for arg in args)

True

So therefore all the arguments to len() in this case are of a single
type, namely str, and by Dennis' assertion, "converting a result when all
inputs are of one [type], NO...", should return the same type as all the
arguments. Which for the avoidance of all doubt is str.


Similarly for the case len([2, 4, 6]), except this time all the arguments
(all one of them) are lists, and therefore len() should return a list.

Naturally it's a crazy argument. Which is my point. Operators are merely
a different syntax for functions of two arguments, and any restriction
that functions must return the same type as all its arguments is just
crazy.

Lost me again. I was not aware that calculators, real mathematics
and common sense were programming languages.

I didn't say they were. Please parse my sentence again.

 

[Steven D'Aprano]

Calculating machines that handled
floating point are older than Python by far.

Yes, and they almost universally give the result 1/2 -> 0.5.

 

[Steven D'Aprano]

You're just going to have to accept that there that there is no
concensus on this issue and there never was.

But that's not true. The consensus, across the majority of people (both
programmers and non-programmers alike) is that 1/2 should return 0.5.
There's a small minority that argue for a rational result, and a bigger
minority who argue for 0.

The interesting case is -1/2. According to the argument that "2 doesn't
go into 1", -1/2 should also return 0. But that's not what Python
returns, so it looks like the "int division" camp is screwed no matter
whether Python keeps the status quo or the other status quo.

 

[Paul Rubin]

any restriction that functions must return the same
type as all its arguments is just crazy.

I don't think anyone is saying that they should necessarily do that
in general. Just in some specific cases.

 

[Paul Rubin]

Yes, and they almost universally give the result 1/2 -> 0.5.

Can you name an example of a calculating machine that both:
1) represents the integer 1 and the real number 1.0 as distinct objects;
and
2) says 1/2 = 0.5 ?

 

[Grant Edwards]

But that's not true. The consensus, across the majority of
people (both programmers and non-programmers alike) is that
1/2 should return 0.5. There's a small minority that argue
for a rational result, and a bigger minority who argue for 0.

Yeay! I'm in the bigger minority!

The interesting case is -1/2. According to the argument that
"2 doesn't go into 1", -1/2 should also return 0. But that's
not what Python returns, so it looks like the "int division"
camp is screwed no matter whether Python keeps the status quo
or the other status quo.

I do integer division pretty regularly, but apparently never on
negative numbers since I wasn't even aware that -1/2 yields -1
(yes, I'm still running 2.4).

 

[Arnaud Delobelle]

On Feb 28, 10:41 pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.au> wrote:
[...]

The interesting case is -1/2. According to the argument that "2 doesn't
go into 1", -1/2 should also return 0. But that's not what Python
returns, so it looks like the "int division" camp is screwed no matter
whether Python keeps the status quo or the other status quo.

I'm in the "int division camp" and I like that -1 / 2 is -1. It's
nice because I can be sure that for any p and q:

* 0 <= p%q < q
* p = q*(p/q) + p%q

In other words, p/q is the largest r such that rq <= p.

It ensures that / and % are well behaved in a lot of situations, e.g:

* (x - y)%n == 0 if and only if x%n == y%n
* if a/n == b/n then abs(a - b) < n
...

So that doesn't screw me, on the contrary I find it a mathematically
very sound decision. What screws me is that I'm going to have to type
p//q in the future.

 

[Ross Ridge]

You're just going to have to accept that there that there is no
concensus on this issue and there never was.

But that's not true. The consensus, across the majority of people (both
programmers and non-programmers alike) is that 1/2 should return 0.5.

You're deluding yourself. If there were a concensus then this issue then
it wouldn't be so controversial. Even the Python developers admitted
that in the documentation for Python 2.2 when the feature was first
introduced:

(The controversy is over whether this is really a design flaw,
and whether it's worth breaking existing code to fix this. It's
caused endless discussions on python-dev, and in July 2001 erupted
into an storm of acidly sarcastic postings on comp.lang.python. I
won't argue for either side here and will stick to describing
what's implemented in 2.2. Read PEP 238 for a summary of arguments
and counter-arguments.)

The decision to change Python's behavior wasn't made by consensus,
or by popular vote. It was made by fiat.

Ross Ridge