Floating point bug?

[Steve Holden]

Why do we care what A. Jo thinks? I would hope that A. Programmer Jo
would see "int {OP} int" and assume int result. A. Jo isn't going to be
debugging anything.

If 3/4 ever returned 0.75 in any language I would drop that language.

Prepare to drop Python then, as this will be the default behavior in 3.x

regards
Steve

 

[D'Arcy J.M. Cain]

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

Exactly. "Programmers" who use a language without learning it are apt
to do anything.

 

[Steve Holden]

I have not been following Python development that closely lately so I
was not aware of that. I guess I won't be going to Python 3 then. It's
great that Python wants to attract young, new programmers. Too bad
about us old farts I guess.

How soon before 2.x is completely deprecated and I have to become a
Walmart greeter?

I'm guessing at least four years: 2.6 will com out at the same time as
3.1, and there will definitely be a 2.7 release. After that you may
indeed be working for Walmart, though do remember that 1.5.2 is still a
perfectly viable language ten years after its release.

regards
Steve

 

[Grant Edwards]

That's creepy for people that are new to programming and doesn't know
how CPUs work and are used to general mathematics.

I don't know where you went to grade school, but where I went,
we learned about integer division long before we learned about
floating point.

That means most people.

I guess it must depend on where you went to shool.

 

[Grant Edwards]

Prepare to drop Python then, as this will be the default behavior in 3.x

IIRC, That was the behavior in Pascal. If you wanted integer
division you used the "div" operator.

 

[Jeff Schwab]

I guess it must depend on where you went to shool.

Temple Israel. You?

 

[Steve Holden]

I have. They don't. I'm not impressed by the fact that the same
generation(s) that can't make change when the cash register is broken
are surprised by integer division. What can I say? I learned
arithmetic with paper and pencil and my head before I was allowed to use
a calculator. Integer division means integer result to me in a very
real sense. Arguing that integer division "should" return a float just
sounds like proof by vigorous assertion to me.

I suppose I will adapt but it really feels wrong.

Yeah, well, join the club, but I had this argument (and lost it) five
years or so ago. Believe me, it *is* possible to continue a meaningful
life when your favorite language makes a wrong-headed move

I too am am member of the old farts club (but then Guido can't be that
far off old fartitude by now ...)

regards
Steve

 

[Mensanator]

I have not been following Python development that closely lately so I
was not aware of that. I guess I won't be going to Python 3 then.  It's
great that Python wants to attract young, new programmers.  Too bad
about us old farts I guess.

Why resign yourself to being old? Why not stay young and envigorated
by learning the new features? How many times have you said "if I knew
then what I know now...". Well, here's your chance. I'm looking
forwards
to it.

How soon before 2.x is completely deprecated and I have to become a
Walmart greeter?

Personally, I plan to drop Python if support for the gmpy module
ever dries up. But I won't be a quitter, just have to start using
C which will suck the life out of the room. But what else can I do?

 

[J. Cliff Dyer]

I have not been following Python development that closely lately so I
was not aware of that. I guess I won't be going to Python 3 then. It's
great that Python wants to attract young, new programmers. Too bad
about us old farts I guess.

How soon before 2.x is completely deprecated and I have to become a
Walmart greeter?

Given your stated criteria (that int OP int == int), you should be a
WalMart greeter now.
<type 'long'>

That's true at least back to Python 2.3. But maybe you're just being
melodramatic, and will actually adapt to this change as well as all the
other changes that have occurred in the python language.

 

[D'Arcy J.M. Cain]

<type 'long'>

A long int is still integral which is the crux of the issue.

 

[J. Cliff Dyer]

A long int is still integral which is the crux of the issue.

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?

For me personally, I'm happy knowing that integer division is still
available through the // operator. I'm not offended that other, highly
useful forms of division would be given operator status. Granted, I'm
not old school like you, but I do appreciate clean design, and typing:

float(3)/4 always struck me as an ugly hack to get integers to do
something that comes naturally to them--divide into a result outside the
set of integral numbers.

I agree that integer division is useful and important, but I don't think
it's a travesty to support other kinds of division, especially when
integer division still has its own operator.

Cheers,
Cliff

 

[Grant Edwards]

Temple Israel. You?

Good one.

 

[Grant Edwards]

Personally, I plan to drop Python if support for the gmpy module
ever dries up. But I won't be a quitter, just have to start using
C which will suck the life out of the room. But what else can I do?

Fork?

 

[Grant Edwards]

So do you believe that you should not be able to do natural
division without explicitly casting ints as floats,

IMO, you're begging the question by using the phrase "natural
division" when what you mean is "floating point division", but
yes, I prefer requiring explicit conversion to floating point.

or is yourw concern just that you want to still be able to to
integer division simply?

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

For me personally, I'm happy knowing that integer division is
still available through the // operator. I'm not offended
that other, highly useful forms of division would be given
operator status. Granted, I'm not old school like you, but I
do appreciate clean design, and typing:

float(3)/4 always struck me as an ugly hack to get integers to do
something that comes naturally to them--divide into a result outside the
set of integral numbers.

Again, you're begging the question by using the term "natural"
to describe your opinion. I find int OP int => float to be
unnatural. It's much too "implicit" for me.

I agree that integer division is useful and important, but I
don't think it's a travesty to support other kinds of
division, especially when integer division still has its own
operator.

If integer division is going to have it's own operator, why not
the same for integer subtraction or integer multiplication?
Yes, I know the theoretical answer, but from a computer
architecture POV, integer addition and floating point addition
are completely separate and unrelated things.

 

[D'Arcy J.M. Cain]

I agree that integer division is useful and important, but I don't think
it's a travesty to support other kinds of division, especially when
integer division still has its own operator.

I don't think that it is a travesty either. I would also not be so
offended if the language treated it that way from the start although I
would still have had to get used to it having spent so much time in C
and assembler which has natural results. The real problem here is that
it is an arbitrary, fundamental change to the way the language works. I
would be almost as upset if the change was happening the other way.

Note, I use the word "natural" above. Natural is an opinion and that
happens to be mine. I am really having a hard time accepting that
"TRUTH (tm)" is determined by election. See signature.

 

[Torsten Bronger]

Hallöchen!

[...]

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

And 2**-1?

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.

Tschö,
Torsten.

 

[Paul Rubin]

Note, I use the word "natural" above. Natural is an opinion and that
happens to be mine.

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

 

[Ross Ridge]

I don't think that it is a travesty either. I would also not be so
offended if the language treated it that way from the start although I
would still have had to get used to it having spent so much time in C
and assembler which has natural results. The real problem here is that
it is an arbitrary, fundamental change to the way the language works. I
would be almost as upset if the change was happening the other way.

I feel pretty much the same way. This change in behaviour is likely to be
the sole reason keeping me from switching to Python 3 for a long time.
If the slash (/) operator had always been defined as floating point
division then I would've gotten used to it. Now however, there's no
compelling reason for me to try to adjust to this new behaviour.

Ross Ridge

 

[D'Arcy J.M. Cain]

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

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

 

[Terry Reedy]

| >>> 3/5
| 0.59999999999999998

I think this either changed in 3.0a2 or may in upcoming releases.