I've never had any call to use floating point numbers and now that I
want to, I can't!
*** Python 2.5.1 (r251:54863, May 1 2007, 17:47:05) [MSC v.1310 32
bit (Intel)] on win32. ***
>>float (.3)
0.29999999999999999
>>foo = 0.3
foo
0.29999999999999999
>>>
Feb 13 '08
135  4139 
On Feb 25, 1:58 pm, Carl Banks <pavlovevide...@gmail.comwrote:
What part of "repeated additions and divisions" don't you understand?
What part of additions and subtractions don't you understand? I'm
invalidating half of your statement, the division part, but validating
another half, the additions part and adding some statements on my own.
>
Try doing numerical integration sometime with rationals, and tell me
how that works out. Try calculating compound interest and storing
results for 1000 customers every month, and compare the size of your
database before and after.
Since when have I said that fractional is appropriate for calculating
compound interests. Fractionals works best in scenarios where the
calculations are mostly addition and subtraction, not percentage
division and multiplications like in compounds.
What is it with people and double++ posting...
If you have a lot to say, say it together and take the time to slow
down, re-read it and not just fly it out, line by line, by line, by
line...
To answer only the following:
That's creepy for people that are new to programming and doesn't know
how CPUs work and are used to general mathematics. That means most
people. As programming language are now more accessible to regular
people without specialized Computer Science degree, it is a just
natural trend that computer arithmetic must be done in an expectable
manner as seen by those general population not by people who holds a
CS degree.
Couldn't disagree with you more, the fact they don't specialise in
Computer Science shouldn't be a reason to follow their "expected
outcomes", they should be informed of the standard CS approach. I'm
all for punishing people for making "well I thought it would always do
the following..." thought process. The quicker they learn certain
methods and expectations are wrong the quicker they get used to the
proper thought patterns.
On Tue, 26 Feb 2008 04:29:18 -0800, Lie wrote:
>J Cliff Dyer:
I'm in the camp that believes that 3/4 does indeed yield the integer 0,
but should be spelled 3//4 when that is the intention.
That's creepy for people that are new to programming and doesn't know
how CPUs work and are used to general mathematics. That means most
people. As programming language are now more accessible to regular
people without specialized Computer Science degree, it is a just
natural trend that computer arithmetic must be done in an expectable
manner as seen by those general population not by people who holds a
CS degree.
So why is it creepy then!? ``3 // 4`` is for the people knowing about
integer division and ``3 / 4`` gives the expected result for those who
don't. Those who don't know ``//`` can write ``int(3 / 4)`` to get the
same effect.
Ciao,
Marc 'BlackJack' Rintsch
On Tue, 26 Feb 2008 09:29:55 -0500, D'Arcy J.M. Cain wrote:
If 3/4 ever returned 0.75 in any language I would drop that language.
Then prepare to drop Python from version 3 on:
Python 3.0a1 (py3k, Aug 31 2007, 21:20:42)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>3 / 4
0.75
Ciao,
Marc 'BlackJack' Rintsch
On Feb 26, 9:02*pm, cokofree...@gmail.com wrote:
That's creepy for people that are new to programming and doesn't know
how CPUs work and are used to general mathematics. That means most
people. As programming language are now more accessible to regular
people without specialized Computer Science degree, it is a just
natural trend that computer arithmetic must be done in an expectable
manner as seen by those general population not by people who holds a
CS degree.
Couldn't disagree with you more, the fact they don't specialise in
Computer Science shouldn't be a reason to follow their "expected
outcomes", they should be informed of the standard CS approach. I'm
all for punishing people for making "well I thought it would always do
the following..." thought process. The quicker they learn certain
methods and expectations are wrong the quicker they get used to the
proper thought patterns.
The problem lies on which maths is the real maths? In real world, 3/4
is 0.75 is 0.75 and that's an unchangeable fact, so programming
languages that do other things is either wrong or have their reason to
do that. Python, C, and other programming languages that uses integer
division by default choose to do default integer division because CPUs
execute integer division faster than floating division, but it doesn't
change the fact that 3/4 is equal to 0.75 but is not equal to 0.
I think a CS should understand that the choice of default integer
division was actually a workaround for the expensive operation, not
because 3/4 actually equals 0. As the more educated person, they
should still expect 3/4 to be 0.75 but could understand why if the
language they're using gives 0. Commoners are the less educated,
languages should appeal to as much people as it could, and giving 3/4
== 0 is the best way to confuse some people right away, instead giving
3/4 == 0.75 would just make the more educated CSs search for the
"regular" division operator.
It is better to think this way:
CSs supposed brain thought:
try:
print 3 / 4
except IntegerResult:
print 'integer division workaround'
if wants[floatdivision]: print 'searching for float division
operator'
elif wants[integerdivision]: print 'that was already correct'
Commoner's supposed brain thought:
try:
print 3 / 4
than this way:
CSs supposed brain thought:
try:
print 3 / 4
except FPointResult:
print 'This language is a jerk'
Commoner's supposed brain thought:
try:
print 3 / 4
The first set of brain thought appeal to everyone, everyone is happy
with the result. The second set of brain thought kills a CS guy and
gives unhandled error to a commoner. DO you still think that default
integer division is better?
On Tue, 26 Feb 2008 06:45:45 -0800 (PST)
Carl Banks <pa************@gmail.comwrote:
On Feb 26, 9:29 am, "D'Arcy J.M. Cain" <da...@druid.netwrote:
If 3/4 ever returned 0.75 in any language I would drop that language.
Have fun dropping Python, then, chief. Integer division with / is
already deprecated, can be disabled ever since Python 2.4, and will be
wholly removed in Python 3.0.
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?
--
D'Arcy J.M. Cain <da***@druid.net | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
On Tue, 26 Feb 2008 06:59:44 -0800 (PST)
Lie <Li******@gmail.comwrote:
The problem lies on which maths is the real maths? In real world, 3/4
is 0.75 is 0.75 and that's an unchangeable fact, so programming
Which real world is that? In my real world 3/4 is 0 with a remainder
of 3. What happens to that 3 depends on the context. When I worked
with a youth soccer group I was pretty sure that I would be disciplined
if I carved up a seven year old player so that I could put 0.75 of a
child on a team.
Anyway, I'm sure that all these arguments have been made and it is
pointless to argue about it now. It sounds like the decision has been
made.
--
D'Arcy J.M. Cain <da***@druid.net | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
On Feb 26, 10:17 pm, "D'Arcy J.M. Cain" <da...@druid.netwrote:
>Carl Banks <pavlovevide...@gmail.comwrote:
>On Feb 26, 9:29 am, "D'Arcy J.M. Cain" <da...@druid.netwrote:
If 3/4 ever returned 0.75 in any language I would drop that language.
>Have fun dropping Python, then, chief. Integer division with / is
already deprecated, can be disabled ever since Python 2.4, and will be
wholly removed in Python 3.0.
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.
Don't worry, Python would still have integer division (// - double
slash), if you still prefer integer division.
Lie <Lie.1...@gmail.comwrote:
The problem lies on which maths is the real maths? In real world, 3/4
is 0.75 is 0.75 and that's an unchangeable fact, so programming
Which real world is that? *In my real world 3/4 is 0 with a remainder
of 3. *What happens to that 3 depends on the context. *When I worked
with a youth soccer group I was pretty sure that I would be disciplined
if I carved up a seven year old player so that I could put 0.75 of a
child on a team.
lol, when counting how much players needed you wouldn't do a division,
you count from one to eleven (a.k.a addition by one a.k.a. increment),
excepting at the point where number of available players + current
count = 11 (+ spares) (or better, you subtract the number of players
to the number of players required). Save the float division for the
time, 90 minutes / number of players if you wanted each child to play
an equal amount of time.
Good joke, and a true argument, I don't wish to see anyone chopped off
because I said floating point division is better.
"D'Arcy J.M. Cain" <da***@druid.netwrites:
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.
Before deciding to drop Python 3 on the grounds of integer division, I
recommend that you at least read PEP 238
( http://www.python.org/dev/peps/pep-0238/) to see arguments *why* the
division was changed. Who knows, maybe they persuade you?
The "Motivation" section of the PEP makes a persuasive argument why
integer division works well in statically typed languages, but results
in many more gotchas in a dynamic language like Python.
On Feb 26, 9:33*pm, Marc 'BlackJack' Rintsch <bj_...@gmx.netwrote:
On Tue, 26 Feb 2008 04:29:18 -0800, Lie wrote:
J Cliff Dyer:
I'm in the camp that believes that 3/4 does indeed yield the integer 0,
but should be spelled 3//4 when that is the intention.
That's creepy for people that are new to programming and doesn't know
how CPUs work and are used to general mathematics. That means most
people. As programming language are now more accessible to regular
people without specialized Computer Science degree, it is a just
natural trend that computer arithmetic must be done in an expectable
manner as seen by those general population not by people who holds a
CS degree.
So why is it creepy then!? *``3 // 4`` is for the people knowing about
integer division and ``3 / 4`` gives the expected result for those who
don't. *Those who don't know ``//`` can write ``int(3 / 4)`` to get the
same effect.
yep, that's the point. The new division operator isn't that creepy
anymore by returning float instead of integer, kudos for whoever made
the change.
On Tue, 26 Feb 2008 09:01:57 -0800
Jeff Schwab <je**@schwabcenter.comwrote:
Or Jo thinks // is a typo, and helpfully "fixes" it.
Exactly. "Programmers" who use a language without learning it are apt
to do anything.
--
D'Arcy J.M. Cain <da***@druid.net | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
D'Arcy J.M. Cain wrote:
On Tue, 26 Feb 2008 06:45:45 -0800 (PST)
Carl Banks <pa************@gmail.comwrote:
>On Feb 26, 9:29 am, "D'Arcy J.M. Cain" <da...@druid.netwrote:
>>If 3/4 ever returned 0.75 in any language I would drop that language.
Have fun dropping Python, then, chief. Integer division with / is
already deprecated, can be disabled ever since Python 2.4, and will be
wholly removed in Python 3.0.
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
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
On 2008-02-26, Lie <Li******@gmail.comwrote:
>I'm in the camp that believes that 3/4 does indeed yield the integer 0,
but should be spelled 3//4 when that is the intention.
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.
As programming language are now more accessible to regular
people without specialized Computer Science degree, it is a
just natural trend that computer arithmetic must be done in an
expectable manner as seen by those general population not by
people who holds a CS degree.
--
Grant Edwards grante Yow! You were s'posed
at to laugh!
visi.com
Grant Edwards wrote:
I guess it must depend on where you went to shool.
Temple Israel. You?
On Feb 26, 9:08*am, "D'Arcy J.M. Cain" <da...@druid.netwrote:
On Tue, 26 Feb 2008 06:45:45 -0800 (PST)
Carl Banks <pavlovevide...@gmail.comwrote:
On Feb 26, 9:29 am, "D'Arcy J.M. Cain" <da...@druid.netwrote:
If 3/4 ever returned 0.75 in any language I would drop that language.
Have fun dropping Python, then, chief. *Integer division with / is
already deprecated, can be disabled ever since Python 2.4, and will be
wholly removed in Python 3.0.
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?
>
--
D'Arcy J.M. Cain <da...@druid.net* * * * | *Democracy is threewolveshttp://www.druid.net/darcy/* * * * * * * *| *and a sheep voting on
+1 416 425 1212 * * (DoD#0082) * *(eNTP) * | *what's for dinner.
On Tue, 2008-02-26 at 10:08 -0500, D'Arcy J.M. Cain wrote:
On Tue, 26 Feb 2008 06:45:45 -0800 (PST)
Carl Banks <pa************@gmail.comwrote:
On Feb 26, 9:29 am, "D'Arcy J.M. Cain" <da...@druid.netwrote:
If 3/4 ever returned 0.75 in any language I would drop that language.
Have fun dropping Python, then, chief. Integer division with / is
already deprecated, can be disabled ever since Python 2.4, and will be
wholly removed in Python 3.0.
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.
>>a = 20000 * 20000
b = 200000 * 200000
type(a)
<type 'int'>
>>type(b)
<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.
On Tue, 26 Feb 2008 13:39:38 -0500
"J. Cliff Dyer" <jc*@sdf.lonestar.orgwrote:
>a = 20000 * 20000
b = 200000 * 200000
type(a)
<type 'int'>
>type(b)
<type 'long'>
A long int is still integral which is the crux of the issue.
--
D'Arcy J.M. Cain <da***@druid.net | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
On 2008-02-26, Jeff Schwab <je**@schwabcenter.comwrote:
Grant Edwards wrote:
>I guess it must depend on where you went to shool.
Temple Israel. You?
Good one. :)
--
Grant Edwards grante Yow! Do you think the
at "Monkees" should get gas on
visi.com odd or even days?
On 2008-02-26, Mensanator <me********@aol.comwrote:
>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?
Fork?
--
Grant Edwards grante Yow! The entire CHINESE
at WOMEN'S VOLLEYBALL TEAM all
visi.com share ONE personality --
and have since BIRTH!!
Hallöchen!
Grant Edwards writes:
[...]
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.
--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: br*****@jabber.org
(See http://ime.webhop.org for further contact info.)
On 26 Feb 2008 12:53:48 -0800
Paul Rubin <"http://phr.cx"@NOSPAM.invalidwrote:
"D'Arcy J.M. Cain" <da***@druid.netwrites:
Note, I use the word "natural" above. Natural is an opinion and that
happens to be mine.
http://en.wikipedia.org/wiki/Natural_number
Recheck the context. I was talking about the natural result, not
natural numbers.
--
D'Arcy J.M. Cain <da***@druid.net | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
"Arnaud Delobelle" <ar*****@googlemail.comwrote in message
| >>3/5
| 0.59999999999999998
I think this either changed in 3.0a2 or may in upcoming releases.
"D'Arcy J.M. Cain" <da***@druid.netwrites:
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.
Paul Rubin <http://ph****@NOSPAM.invalidwrote:
http://en.wikipedia.org/wiki/Natural_number
"D'Arcy J.M. Cain" <da***@druid.netwrites:
Recheck the context. I was talking about the natural result, not
natural numbers.
Paul Rubin <http://ph****@NOSPAM.invalidwrote:
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
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rr****@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
Ross Ridge <rr****@caffeine.csclub.uwaterloo.cawrites:
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.
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.
On 2008-02-26, Paul Rubin <httpwrote:
"D'Arcy J.M. Cain" <da***@druid.netwrites:
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.
OK, but I thought we were talking about computer integers.
--
Grant Edwards grante Yow! My mind is a potato
at field ...
visi.com
On 2008-02-26, Torsten Bronger <br*****@physik.rwth-aachen.dewrote:
Hallöchen!
Grant Edwards writes:
>[...]
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.
--
Grant Edwards grante Yow! What a COINCIDENCE!
at I'm an authorized "SNOOTS
visi.com OF THE STARS" dealer!!
On Tue, 26 Feb 2008 11:43:56 -0500, D'Arcy J.M. Cain wrote:
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.
--
Steven
Hallöchen!
Grant Edwards writes:
On 2008-02-26, Torsten Bronger <br*****@physik.rwth-aachen.dewrote:
>Grant Edwards writes:
>>[...]
Nope. I would prefer that int OP int always produce an int.
And 2**-1?
An error.
? Not here.
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: br*****@jabber.org
(See http://ime.webhop.org for further contact info.)
Ross Ridge <rr****@caffeine.csclub.uwaterloo.cawrites:
D'Arcy said nothing about natural numbers, and bringing them up adds
nothing to this discussion.
Paul Rubin <http://ph****@NOSPAM.invalidwrote:
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
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rr****@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
On Feb 26, 9:47*pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.auwrote:
On Tue, 26 Feb 2008 11:43:56 -0500, D'Arcy J.M. Cain wrote:
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.
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...
--
Arnaud
On Tue, 26 Feb 2008 14:46:04 -0500, D'Arcy J.M. Cain wrote:
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.
--
Steven
J. Cliff Dyer wrote:
On Tue, 2008-02-26 at 13:51 -0500, D'Arcy J.M. Cain wrote:
>On Tue, 26 Feb 2008 13:39:38 -0500
"J. Cliff Dyer" <jc*@sdf.lonestar.orgwrote:
>>>>>a = 20000 * 20000
>b = 200000 * 200000
>type(a)
<type 'int'>
>type(b)
<type 'long'>
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?
I think the issue is whether this qualifies as "natural" division in the
first place. (For the record, I'm only semi-old-school.)
Paul Rubin wrote:
"D'Arcy J.M. Cain" <da***@druid.netwrites:
>>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.
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.)
Grant Edwards wrote:
On 2008-02-26, Jeff Schwab <je**@schwabcenter.comwrote:
>Grant Edwards wrote:
>>I guess it must depend on where you went to shool.
Temple Israel. You?
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.)
On Tue, 2008-02-26 at 14:08 -0800, Jeff Schwab wrote:
J. Cliff Dyer wrote:
On Tue, 2008-02-26 at 13:51 -0500, D'Arcy J.M. Cain wrote:
On Tue, 26 Feb 2008 13:39:38 -0500
"J. Cliff Dyer" <jc*@sdf.lonestar.orgwrote:
a = 20000 * 20000
b = 200000 * 200000
type(a)
<type 'int'>
type(b)
<type 'long'>
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?
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
"J. Clifford Dyer" <jc*@sdf.lonestar.orgwrites:
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.
On 2008-02-27, J. Clifford Dyer <jc*@sdf.lonestar.orgwrote:
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. :)
--
Grant Edwards grante Yow! Is this ANYWHERE,
at USA?
visi.com
On Feb 26, 9:00*pm, Paul Rubin <http://phr...@NOSPAM.invalidwrote:
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:
>>from __future__ import division
10**50/10**40
10000000000.0
>>10**60/10**50
9999999999.9999981
This despite the fact that the quotient *is* exactly representable
as a float...
Mark
Mark Dickinson wrote:
On Feb 26, 9:00 pm, Paul Rubin <http://phr...@NOSPAM.invalidwrote:
>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:
>>>from __future__ import division
10**50/10**40
10000000000.0
>>>10**60/10**50
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.
>>(10**60//10**50) (10**60/10**50)
True
On Feb 26, 11:55*pm, Paul Rubin <http://phr...@NOSPAM.invalidwrote:
So use: *return sum(number_list) / float(len(number_list))
That makes it somewhat more explicit what you want. *Otherwise
But that fails for a list of Decimals...
Mark
Mark Dickinson <di******@gmail.comwrites:
So use: *return sum(number_list) / float(len(number_list))
That makes it somewhat more explicit what you want. *Otherwise
But that fails for a list of Decimals...
Again, that depends on what your application considers to be failure.
Heck, int/int = float instead of decimal might be a failure.
FWIW, I just checked Haskell: int/int is not allowed (compile time
type error). There is an integer division function `div`, like
Python's //, . that you can use if you want an integer quotient. If
you want a floating or rational quotient, you have to coerce the
operands manually. Explicit is better than implicit.
"Gabriel Genellina" <ga*******@yahoo.com.arwrites:
They exist since this semantic change was introduced *seven* *years*
ago, in 2001, so it's not that suddenly the Python world is going to
be upside down... I can't believe how long this thread is by now...
I don't think it's a sudden uproar about int/int being float, it's
just one of the periodic discussions about introducing a rational
type, like we not that long ago got a decimal type.
Mark Dickinson <di******@gmail.comwrote:
>True division and floor division are different operations. It doesn't
seem ridiculous to use different operators for them.
I don't have a problem with there being different operators for integer
and floating-point division. I have a problem with the behviour of the
slash (/) operator changing.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rr****@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
Steven D'Aprano <st***@REMOVE-THIS-cybersource.com.auwrites:
Oh come on. With a function named "mean" that calculates the sum of a
list of numbers and then divides by the number of items, what else could
it be?
You have a bunch of marbles you want to put into bins. The division
tells you how many marbles to put into each bin. That would be
an integer since you cannot cut up individual marbles.
You can always imagine corner cases where some programmer, somewhere, has
some bizarre need for a mean() function that truncates when given a list
of integers but not when given a list of floats. Making that the default
makes life easy for the 0.1% corner cases and life harder for the 99.9%
of regular cases, which is far from the Python philosophy.
I think it's more important that a program never give a wrong answer,
than save a few keystrokes. So, that polymorphic mean function is
a bit scary. It might be best to throw an error if the args are
all integers. There is no definitely correct way to handle it so
it's better to require explicit directions.
Steven D'Aprano <st***@REMOVE-THIS-cybersource.com.auwrites:
When it comes to mixed arithmetic, it's just too darn inconvenient to
forbid automatic conversions. Otherwise you end up either forbidding
things like 1 + 1.0 on the basis that it isn't clear whether the
programmer wants an int result or a float result,
You can parse 1 as either an integer or a floating 1, so 1 + 1.0 can
be correctly typed as a float. However (for example), len(x) is
always an int so len(x) + 1.0 would be forbidden.
or else even more complex rules ("if the left operator is an int,
and the result of the addition has a zero floating-point part, then
the result is an int,
That is ugly and unnecessary.
Steven D'Aprano <st***@REMOVE-THIS-cybersource.com.auwrites:
def pmean(data): # Paul Rubin's mean
"""Returns the arithmetic mean of data, unless data is all
ints, in which case returns the mean rounded to the nearest
integer less than the arithmetic mean."""
s = sum(data)
if isinstance(s, int): return s//len(data)
else: return s/len(data)
Scheme and Common Lisp do automatic conversion and they thought out
the semantics rather carefully, and I think both of them return
exact rationals in this situation (int/int division). I agree
with you that using // as above is pretty weird and it may be
preferable to raise TypeError on any use of int/int (require
either an explicit conversion, or use of //).
On Feb 26, 11:21 pm, Mark Dickinson <dicki...@gmail.comwrote:
On Feb 26, 11:55 pm, Paul Rubin <http://phr...@NOSPAM.invalidwrote:
So use: return sum(number_list) / float(len(number_list))
That makes it somewhat more explicit what you want. Otherwise
But that fails for a list of Decimals...
Mark
Or complex. Or for rationals if you aren't expecting a conversion to
float.
On Wed, 27 Feb 2008 18:43:24 -0800, Paul Rubin wrote:
Steven D'Aprano <st***@REMOVE-THIS-cybersource.com.auwrites:
>def pmean(data): # Paul Rubin's mean
"""Returns the arithmetic mean of data, unless data is all ints, in
which case returns the mean rounded to the nearest integer less
than the arithmetic mean."""
s = sum(data)
if isinstance(s, int): return s//len(data)
else: return s/len(data)
Scheme and Common Lisp do automatic conversion and they thought out the
semantics rather carefully, and I think both of them return exact
rationals in this situation (int/int division).
Potentially better than returning a float, but equally objectionable to
all those insisting that int <opint should only return an int.
I agree with you that
using // as above is pretty weird and it may be preferable to raise
TypeError on any use of int/int (require either an explicit conversion,
or use of //).
Then you have completely misunderstood my objection.
It's not that // is weird, but that the semantics that you want by
default:
"return the mean for arbitrary numeric data, except for all ints, in
which case return the mean rounded to the next smaller integer"
is weird. Weird or not, if you want those semantics, Python gives you the
tools to create it, as above. It's not even very much more work.
But the normal semantics:
"return the mean for arbitrary numeric data"
should be easier, and with Python it is:
def mean(data): return sum(data)/len(data)
That does the right thing for data, no matter of what it consists of:
floats, ints, Decimals, rationals, complex numbers, or a mix of all of
the above.
You want the pmean() case to be easy, and the mean() case to be hard, and
that's what boggles my brain.
--
Steven This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: JS |
last post by:
We have the same floating point intensive C++ program that runs on
Windows on Intel chip and on Sun Solaris on SPARC chips. The program
reads the exactly the same input files on the two platforms....
|
by: Anton Noll |
last post by:
We are using Visual Studio 2003.NET (C++) for the development
of our software in the fields digital signal processing and
numerical acoustics.
One of our programs was working correctly if we are...
|
by: cody |
last post by:
no this is no trollposting and please don't get it wrong but iam very
curious why people still use C instead of other languages especially C++.
i heard people say C++ is slower than C but i can't...
|
by: j0mbolar |
last post by:
C supports single precision floating point and double precision
floating point but does it support fixed floating point? i've read
that fixed floating point is more accurate than single precision...
|
by: Vinoth |
last post by:
I'm working in an ARM (ARM9) system which does not have Floating point
co-processor or Floating point libraries. But it does support long long int
(64 bits).
Can you provide some link that would...
|
by: michael.mcgarry |
last post by:
Hi,
I have a question about floating point precision in C.
What is the minimum distinguishable difference between 2 floating point
numbers? Does this differ for various computers?
Is this...
|
by: Bern McCarty |
last post by:
I have run an experiment to try to learn some things about floating point
performance in managed C++. I am using Visual Studio
2003. I was hoping to get a feel for whether or not it would make...
|
by: jacob navia |
last post by:
Hi people
I continue to work in the tutorial for lcc-win32, and started to try to
explain the floating point flags.
Here is the relevant part of the tutorial. Since it is a difficult part,
I...
|
by: ma740988 |
last post by:
template <class T> inline bool isEqual( const T& a, const T& b,
const T epsilon = std::numeric_limits<T>::epsilon() )
{
const T diff = a - b;
return ( diff <= epsilon ) && ( diff >= -epsilon );...
|
by: rembremading |
last post by:
Hi all!
The following piece of code has (for me) completely unexpected behaviour.
(I compile it with gcc-Version 4.0.3)
Something goes wrong with the integer to float conversion.
Maybe somebody...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
| |
