Floating point bug?

[Lie]

Well, I do a test on my own fraction class. I found out that if we set a
limit to the numerators and denominators, the resulting output fraction
would have limit too. I can't grow my fraction any more than this limit
no matter how many iteration I do on them. I do the test is by something
like this (I don't have the source code with me right now, it's quite
long if it includes the fraction class, but I think you could use any
fraction class that automatically simplify itself, might post the real
code some time later):

while True:
a = randomly do (a + b) or (a - b)
b = random fraction between [0-100]/[0-100] print a

And this limit is much lower than n!. I think it's sum(primes(n)), but
I've got no proof for this one yet.

*jaw drops*

Please stop trying to "help" convince people that rational classes are
safe to use. That's the sort of "help" that we don't need.

For the record, it is a perfectly good strategy to *artificially* limit
the denominator of fractions to some maximum value. (That's more or less
the equivalent of setting your floating point values to a maximum number
of decimal places.) But without that artificial limit, repeated addition
of fractions risks having the denominator increase without limit.

No, it is a real limit. This is what I'm talking about. If the input
data has a limit, the output data has a real limit, not a defined-
limit. If the input data's denominator is unbounded, the output
fraction's denominator is also unbounded

In a repeated addition and subtraction with input data that have limits

 

[Lie]

Well, I do a test on my own fraction class. I found out that if we set a
limit to the numerators and denominators, the resulting output fraction
would have limit too. I can't grow my fraction any more than this limit
no matter how many iteration I do on them. I do the test is by something
like this (I don't have the source code with me right now, it's quite
long if it includes the fraction class, but I think you could use any
fraction class that automatically simplify itself, might post the real
code some time later):

while True:
a = randomly do (a + b) or (a - b)
b = random fraction between [0-100]/[0-100] print a

And this limit is much lower than n!. I think it's sum(primes(n)), but
I've got no proof for this one yet.

*jaw drops*

Please stop trying to "help" convince people that rational classes are
safe to use. That's the sort of "help" that we don't need.

For the record, it is a perfectly good strategy to *artificially* limit
the denominator of fractions to some maximum value. (That's more or less
the equivalent of setting your floating point values to a maximum number
of decimal places.) But without that artificial limit, repeated addition
of fractions risks having the denominator increase without limit.

No, it is a real limit. This is what I'm talking about. If the input
data has a limit, the output data has a real limit, not a user-defined-
limit (FOR ADDITION AND SUBTRACTION). If the input data's denominator
is unbounded, the output fraction's denominator is also unbounded

 

[Lie]

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.




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]

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.

 

[Lie]

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


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.

And it should, as floats have native CPU support, 3/4 (with __future__
import) should yields 0.75. Fractional is safe for many usage
scenario, but obviously it is not appropriate for all cases, just like
floats and decimals. I think this mailing list already have enough
absolutist, who can go to either side of the camp but doesn't want to
be in the middle.

In real world, money is probably best described by float or Decimals,
as non-computer money calculations are used to do rounding at 1 cents.
But the interest rate is probably better described by rationals.

In trigonometry, _perhaps_ the world would be better if trigonometric
functions returns rational. Perhaps it is better to use rational for
pi (ratio of diameter and circumferrence) and phi (golden ratio). But
I think angles is better described as floats nevertheless.

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.

 

[J. Cliff Dyer]

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.

Of course. That's why I think you ought to spell it 3//4. Nobody gets
confused when a strange operator that they've never seen before does
something unusual. Average Jo off the street looks at python code and
sees 3/4, and immediately thinks "aha! .75!" Show the same person 3//4,
and she'll think, "A double slash? I'd better check the
documentation--or better yet, play with it a little in the interactive
interpreter."

 

[cokofreedom]

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.

 

[D'Arcy J.M. Cain]

Of course. That's why I think you ought to spell it 3//4. Nobody gets
confused when a strange operator that they've never seen before does
something unusual. Average Jo off the street looks at python code and
sees 3/4, and immediately thinks "aha! .75!" Show the same person 3//4,

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.

 

[Marc 'BlackJack' Rintsch]

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]

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.0.75

Ciao,
Marc 'BlackJack' Rintsch

 

[Carl Banks]

Why do we care what A. Jo thinks? I would hope that A. Programmer Jo
would see "int {OP} int" and assume int result.

There's no reason why int op int would imply an int result. It's only
a convention in some languages, and a bad one.

A. Jo isn't going to be
debugging anything.

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.


Carl Banks

 

[Lie]

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]

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]

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.

 

[Lie]

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.

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.

 

[Arnaud Delobelle]

There's no reason why int op int would imply an int result.  It's only
a convention in some languages, and a bad one.



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.

Carl Banks

And of course A. Jo will love this:

Python 3.0a1+ (py3k:59330, Dec 4 2007, 18:44:39)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.0.59999999999999998

On a more general note, though, I believe that integer division is a
more important concept to CS than 'near exact' division. CS deals
mainly with discrete objects (and one might say exclusively, given the
digital nature of modern computers), and integers are the more natural
numerical objects to associate with discrete things. As with the
soccer example given by D'Arcy J.M. Cain, many objects can't be
chopped in halves or quarters (especially in CS) therefore float
division is no meaningless to them.

 

[Hrvoje Niksic]

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]

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.

 

[D'Arcy J.M. Cain]

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?

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.

 

[Jeff Schwab]

Of course. That's why I think you ought to spell it 3//4. Nobody gets
confused when a strange operator that they've never seen before does
something unusual. Average Jo off the street looks at python code and
sees 3/4, and immediately thinks "aha! .75!" Show the same person 3//4,
and she'll think, "A double slash? I'd better check the
documentation--or better yet, play with it a little in the interactive
interpreter."

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