Floating point bug?

[Carl Banks]

Re: How about adding rational fraction to Python?

On Feb 25, 9:41 am, Mensanator <mensana...@aol .comwrote:

On Feb 25, 12:58�am, Carl Banks <pavlovevide... @gmail.comwrote :
>
>
>

On Feb 24, 10:56 pm, Mensanator <mensana...@aol .comwrote:

>

But that doesn't mean they become less manageable than
other unlimited precision usages. Did you see my example
of the polynomial finder using Newton's Forward Differences
Method? The denominator's certainly don't settle out, neither
do they become unmanageable. And that's general mathematics.

>

No, that's a specific algorithm. �That some random algorithm doesn't
blow up the denominators to the point of disk thrashing doesn't mean
they won't generally.

>

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.

>
Nobody said rationals were the appropriate solution
to _every_ problem, just as floats and integers aren't
the appropriate solution to _every_ problem.

I was answering your claim that rationals are appropriate for general
mathematical uses.

Your argument is that I should be forced to use
an inappropriate type when rationals _are_
the appropriate solution.

I don't know where you got that idea.

My argument is that rationals aren't suitable for ordinary uses
because they have poor performance and can easily blow up in your
face, trash your disk, and crash your program (your whole system if
you're on Windows).

In other words, 3/4 in Python rightly yields a float and not a
rational.


Carl Banks

[Grant Edwards]

Re: How about adding rational fraction to Python?

On 2008-02-25, Carl Banks <pavlovevidence @gmail.comwrote :

In other words, 3/4 in Python rightly yields a float

Unless you're in the camp that believes 3/4 should yield the
integer 0. ;)

and not a rational.

--
Grant Edwards grante Yow! Zippy's brain cells
at are straining to bridge
visi.com synapses ...

[Steve Holden]

Re: How about adding rational fraction to Python?

Grant Edwards wrote:

On 2008-02-25, Carl Banks <pavlovevidence @gmail.comwrote :
>

>In other words, 3/4 in Python rightly yields a float

>
Unless you're in the camp that believes 3/4 should yield the
integer 0. ;)
>

>and not a rational.

>

No, that wouldn't be rational ;-)
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

[J. Cliff Dyer]

Re: How about adding rational fraction to Python?

On Mon, 2008-02-25 at 16:27 +0000, Grant Edwards wrote:

On 2008-02-25, Carl Banks <pavlovevidence @gmail.comwrote :
>

In other words, 3/4 in Python rightly yields a float

>
Unless you're in the camp that believes 3/4 should yield the
integer 0. ;)

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.

Cheers,
Cliff

[Lie]

Re: How about adding rational fraction to Python?

On Feb 25, 11:34 am, casevh <cas...@gmail.c omwrote:

On Feb 24, 7:56 pm, Mensanator <mensana...@aol .comwrote:
>

But that doesn't mean they become less manageable than
other unlimited precision usages. Did you see my example
of the polynomial finder using Newton's Forward Differences
Method? The denominator's certainly don't settle out, neither
do they become unmanageable. And that's general mathematics.

>
Since you are expecting to work with unlimited (or at least, very
high) precision, then the behavior of rationals is not a surprise. But
a naive user may be surprised when the running time for a calculation
varies greatly based on the values of the numbers. In contrast, the
running time for standard binary floating point operations are fairly
constant.
>
>
>

If the point was as SDA suggested, where things like 16/16
are possible, I see that point. As gmpy demonstrates thouigh,
such concerns are moot as that doesn't happen. There's no
reason to suppose a Python native rational type would be
implemented stupidly, is there?

>
In the current version of GMP, the running time for the calculation of
the greatest common divisor is O(n^2). If you include reduction to
lowest terms, the running time for a rational add is now O(n^2)
instead of O(n) for a high-precision floating point addition or O(1)
for a standard floating point addition. If you need an exact rational
answer, then the change in running time is fine. But you can't just
use rationals and expect a constant running time.
>
There are trade-offs between IEEE-754 binary, Decimal, and Rational
arithmetic. They all have there appropriate problem domains.

I very agree with this statement. Fractionals do have its weakness,
and so do Decimal and Hardware Floating Point. And they have their own
usage, their own scenarios where they're appropriate. If you needed
full-speed calculation, it is clear that floating point wins all over
the place, OTOH, if you need to manage your precision carefully
Fractional and Decimal both have their own plus and mins

[Lie]

Re: How about adding rational fraction to Python?

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.

[cokofreedom@gmail.com]

Re: How about adding rational fraction to Python?

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.

[Marc 'BlackJack' Rintsch]

Re: How about adding rational fraction to Python?

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

[Marc 'BlackJack' Rintsch]

Re: How about adding rational fraction to Python?

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

[Lie]

Re: How about adding rational fraction to Python?

On Feb 26, 9:02 pm, cokofree...@gma il.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?

[D'Arcy J.M. Cain]

Re: How about adding rational fraction to Python?

On Tue, 26 Feb 2008 06:45:45 -0800 (PST)
Carl Banks <pavlovevidence @gmail.comwrote :

On Feb 26, 9:29 am, "D'Arcy J.M. Cain" <da...@druid.ne twrote:

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 <darcy@druid.ne t | 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]

Re: How about adding rational fraction to Python?

On Tue, 26 Feb 2008 06:59:44 -0800 (PST)
Lie <Lie.1296@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 <darcy@druid.ne t | 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.

[Lie]

Re: How about adding rational fraction to Python?

On Feb 26, 10:17 pm, "D'Arcy J.M. Cain" <da...@druid.ne twrote:

>Carl Banks <pavlovevide... @gmail.comwrote :

>On Feb 26, 9:29 am, "D'Arcy J.M. Cain" <da...@druid.ne twrote:

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.

[Hrvoje Niksic]

Re: How about adding rational fraction to Python?

"D'Arcy J.M. Cain" <darcy@druid.ne twrites:

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.

[Lie]

Re: How about adding rational fraction to Python?

On Feb 26, 9:33 pm, Marc 'BlackJack' Rintsch <bj_...@gmx.net wrote:

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.