Floating point bug?

[Steven D'Aprano]

Re: How about adding rational fraction to Python?

On Sun, 24 Feb 2008 11:09:32 -0800, Lie wrote:

I decided to keep the num/den limit low (10) because higher values might
obscure the fact that it do have limits.

You do realise that by putting limits on the denominator, you guarantee
that the sum of the fractions also has a limit on the denominator? In
other words, your "test" is useless.

With denominators limited to 1 through 9 inclusive, the sum will have a
denominator of 2*3*5*7 = 210. But that limit is a product (literally and
figuratively) of your artificial limit on the denominator. Add a fraction
with denominator 11, and the sum now has a denominator of 2310; add
another fraction n/13 and the sum goes to m/30030; and so on.


--
Steven

[Mensanator]

Re: How about adding rational fraction to Python?

On Feb 24, 4:50�pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com .auwrote:

On Sun, 24 Feb 2008 11:09:32 -0800, Lie wrote:

I decided to keep the num/den limit low (10) because higher values might
obscure the fact that it do have limits.

>
You do realise that by putting limits on the denominator, you guarantee
that the sum of the fractions also has a limit on the denominator? In
other words, your "test" is useless.
>
With denominators limited to 1 through 9 inclusive, the sum will have a
denominator of 2*3*5*7 = 210.

Th limit will be 2*2*2*3*3*5*7. As MD said, "equivalent ly
the product over all primes p <= n of the highest power
of p not exceeding n".

But that limit is a product (literally and
figuratively) of your artificial limit on the denominator. Add a fraction
with denominator 11, and the sum now has a denominator of 2310; add
another fraction n/13 and the sum goes to m/30030; and so on.
>
--
Steven

[Mel]

Re: How about adding rational fraction to Python?

Mensanator wrote:

On Feb 24, 1:09�pm, Lie <Lie.1...@gmail .comwrote:

>I decided to keep the num/den limit low (10) because higher values
>might obscure the fact that it do have limits. [ ... ]

>
Out of curiosity, of what use is denominator limits?
>
The problems where I've had to use rationals have
never afforded me such luxury, so I don't see what
your point is.

In calculations dealing only with selected units of measure: dollars
and cents, pounds, ounces and tons, teaspoons, gallons, beer bottles
28 to a case, then the denominators would settle out pretty quickly.

In general mathematics, not.

I think that might be the point.

Mel.

[Mensanator]

Re: How about adding rational fraction to Python?

On Feb 24, 6:09 pm, Mel <mwil...@the-wire.comwrote:

Mensanator wrote:

On Feb 24, 1:09�pm, Lie <Lie.1...@gmail .comwrote:

I decided to keep the num/den limit low (10) because higher values
might obscure the fact that it do have limits. [ ... ]

>

Out of curiosity, of what use is denominator limits?

>

The problems where I've had to use rationals have
never afforded me such luxury, so I don't see what
your point is.

>
In calculations dealing only with selected units of measure: dollars
and cents, pounds, ounces and tons, teaspoons, gallons, beer bottles
28 to a case, then the denominators would settle out pretty quickly.

Ok.

>
In general mathematics, not.

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.

>
I think that might be the point.

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?

>
        Mel.

[casevh]

Re: How about adding rational fraction to Python?

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.

And sometimes you just need unlimited precision, radix-6, fixed-point
arithmetic....

casevh

[Carl Banks]

Re: How about adding rational fraction to Python?

On Feb 24, 12:32 pm, Lie <Lie.1...@gmail .comwrote:

On Feb 18, 1:25 pm, Carl Banks <pavlovevide... @gmail.comwrote :
>

On Feb 17, 1:45 pm, Lie <Lie.1...@gmail .comwrote:

>

Any iteration with repeated divisions and additions can thus run the
denominators up. This sort of calculation is pretty common (examples:
compound interest, numerical integration).

>

Wrong. Addition and subtraction would only grow the denominator up to
a certain limit

>

I said repeated additions and divisions.

>
Repeated Addition and subtraction can't make fractions grow
infinitely, only multiplication and division could.

What part of "repeated additions and divisions" don't you understand?



Carl Banks

[Carl Banks]

Re: How about adding rational fraction to Python?

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.


Carl Banks

[Paul Rubin]

Re: How about adding rational fraction to Python?

Carl Banks <pavlovevidence @gmail.comwrite s:

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.

Usually you would round to the nearest penny before storing in the
database.

[Carl Banks]

Re: How about adding rational fraction to Python?

On Feb 25, 2:04 am, Paul Rubin <http://phr...@NOSPAM.i nvalidwrote:

Carl Banks <pavlovevide... @gmail.comwrite s:

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.

>
Usually you would round to the nearest penny before storing in the
database.

I throw it out there as a hypothetical, not as a real world example.
"This is why we don't (usually) use rationals for accounting."


Carl Banks

[M.-A. Lemburg]

Re: How about adding rational fraction to Python?

If you're interested in rationals, then you might want to have a look
at mxNumber which is part of the eGenix mx Experimental
Distribution:

http://www.egenix.com/products/python/mxExperimental/mxNumber/

It provides fast rational operations based on the GNU MP
library.

On 2008-02-25 07:58, Carl Banks wrote:

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.

It is well possible to limit the denominator before storing it
in a database or other external resource using Farey neighbors:

http://en.wikipedia.org/wiki/Farey_sequence#Farey_neighbours

mxNumber implements an algorithm for this (not the most efficient
one, but it works nicely).

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source (#1, Feb 25 2008)

>>Python/Zope Consulting and Support ... http://www.egenix.com/
>>mxODBC.Zope.D atabase.Adapter ... http://zope.egenix.com/
>>mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

_______________ _______________ _______________ _______________ ____________

:::: Try mxODBC.Zope.DA for Windows,Linux,S olaris,MacOSX for free ! ::::


eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611

[Jorge Godoy]

Re: How about adding rational fraction to Python?

Paul Rubin wrote:

Carl Banks <pavlovevidence @gmail.comwrite s:

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

>
Usually you would round to the nearest penny before storing in the
database.

There are cases where the law requires a higher precision or where the
rounding has to be a floor or...

Some things make no sense and when dealing with money things make even less
sense to either protect the customer or to grant the State getting its
share of the transaction.

Here in Brasil, for example, gas stations have to display the price with 3
decimal digits and round the end result down (IIRC). A truck filling 117
liters at 1.239 reais per liter starts making a mess... If the owner wants
to track "losses" due to rounding or if he wants to make his inventory of
fuel accurately, he won't be able to save just what he billed the customer
otherwise things won't match by the end of the month.

[Mensanator]

Re: How about adding rational fraction to Python?

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.

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

I have never used the Decimal type, but I'm not
calling for it's removal because I know there are
cases where it's useful. If a rational type were
added, no one would force you to use it for
numerical integration.

>
Carl Banks

[Steven D'Aprano]

Re: How about adding rational fraction to Python?

On Sun, 24 Feb 2008 23:41:53 -0800, Dennis Lee Bieber wrote:

On 24 Feb 2008 23:04:14 -0800, Paul Rubin <http://phr.cx@NOSPAM.i nvalid>
declaimed the following in comp.lang.pytho n:
>
>

>Usually you would round to the nearest penny before storing in the
>database.

>
Tell that to the payroll processing at Lockheed...My paycheck
tends to vary from week to week as the database apparently carries
amount to at least 0.001 resolution, only rounding when distributing
among various taxes for the paycheck itself. Tedious data entry in
Quicken as I have to keep tweaking various tax entries by +/- a penny
each week.

"Worst practice" in action *wink*

I predict they're using some funky in-house accounting software they've
paid millions to a consultancy firm (SAP?) for over the decades, written
by some guys who knows lots of Cobol but no accounting, and the internal
data type is a float.

[snip]

Oh... And M$ -- the currency type in VB is four decimal places.

Accounting standards do vary according to context: e.g. I see that
offical Australian government reporting standards for banks is to report
in millions of dollars rounded to one decimal place. Accountants can
calculate things more or less any way they like, so long as they tell
you. I found one really dodgy example:

"The MFS Water Fund ARSN 123 123 642 (‘the Fund’) is a registered managed
investment scheme. ... MFS Aqua may calculate the Issue Price to the
number of decimal places it determines."

Sounds like another place using native floats. But it's all above board,
because they tell you they'll use an arbitrary number of decimal places,
all the better to confuse the auditors my dear.


--
Steven

[Steven D'Aprano]

Re: How about adding rational fraction to Python?

On Sun, 24 Feb 2008 23:09:39 -0800, Carl Banks wrote:

On Feb 25, 2:04 am, Paul Rubin <http://phr...@NOSPAM.i nvalidwrote:

>Carl Banks <pavlovevide... @gmail.comwrite s:

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.

>>
>Usually you would round to the nearest penny before storing in the
>database.

>
I throw it out there as a hypothetical, not as a real world example.
"This is why we don't (usually) use rationals for accounting."

But since accountants (usually) round to the nearest cent, accounting is
a *good* use-case for rationals. Decimal might be better, but floats are
worst.

I wonder why you were doing numerical integration with rationals in the
first place? Are you one of those ABC users (like Guido) who have learnt
to fear rationals because ABC didn't have floats?


--
Steven

[M.-A. Lemburg]

Re: How about adding rational fraction to Python?

On 2008-02-25 16:03, Steven D'Aprano wrote:

On Sun, 24 Feb 2008 23:09:39 -0800, Carl Banks wrote:
>

>On Feb 25, 2:04 am, Paul Rubin <http://phr...@NOSPAM.i nvalidwrote:

>>Carl Banks <pavlovevide... @gmail.comwrite s:
>>>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.
>>Usually you would round to the nearest penny before storing in the
>>database.

>I throw it out there as a hypothetical, not as a real world example.
>"This is why we don't (usually) use rationals for accounting."

>
But since accountants (usually) round to the nearest cent, accounting is
a *good* use-case for rationals. Decimal might be better, but floats are
worst.

That's not necessarily true in general: finance libraries usually try
to always do calculations at the best possible precision and then only
apply rounding at the very end of a calculation. Most of the time a float
is the best data type for this.

Accounting uses a somewhat different approach and one which various
between the different accounting standards and use cases. The decimal
type is usually better suited for this, since it supports various
ways of doing rounding.

Rationals are not always the best alternative, but they do help
in cases where you need to guarantee that the sum of all parts
is equal to the whole for all values. Combined with interval
arithmetic they go a long way towards more accurate calculations.

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source (#1, Feb 25 2008)

>>Python/Zope Consulting and Support ... http://www.egenix.com/
>>mxODBC.Zope.D atabase.Adapter ... http://zope.egenix.com/
>>mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

_______________ _______________ _______________ _______________ ____________

:::: Try mxODBC.Zope.DA for Windows,Linux,S olaris,MacOSX for free ! ::::


eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611