Rationals?

[Mike Meyer]

With the decimals and the unification of int and long coming, it's natural
(for me, anyway) to wonder how much interest there is in a rational type.
There are two PEPs (239 and 240), and the Guido rejects them as no one
seems interested in doing the work, but points out that the python
distribution comes with examples/Demo/classes/Rat.py.

I propose - in the spirit of "batteries included" - that Rat.py be
cleaned up some (mostly to take advantage of the union of ints and
longs) and moved into the standard library.

Any good reasons not to do this?

<mike

 

[Tim Peters]

[Mike Meyer]

With the decimals and the unification of int and long coming, it's
natural (for me, anyway) to wonder how much interest there is in a
rational type.

There are two PEPs (239 and 240), and the Guido rejects them as
no one seems interested in doing the work, but points out that the
python distribution comes with examples/Demo/classes/Rat.py.

I propose - in the spirit of "batteries included" - that Rat.py be
cleaned up some (mostly to take advantage of the union of ints and
longs)
+0

and moved into the standard library.
-1

Any good reasons not to do this?

There's no reason not to clean it up. But Rat.py belongs where it is
regardless: it *is* "a demo", too half-baked for the standard
library. There's a better implementation in the Python sandbox:

http://cvs.sf.net/viewcvs.py/python/python/nondist/sandbox/rational/

Moshe left that behind going on 4 years ago now, as a prototype for
PEP 239. It's also far from being suitable for the standard library:
the PEP is more a sketch of an idea than a specification, the PEP
needs to be accepted, the module needs real documentation, and it
needs a test suite.

The decimal PEP:

http://www.python.org/peps/pep-0327.html

can serve as a good model for what PEP 239 should be. I'll note that
at least a person-year of work has gone into 2.4's decimal
implementation, but even so decimal is still likely years away from
full integration with the language. Nevertheless, several people
contributed major time to decimal, and that bodes well for its future.

leaky-AAA-cells-wasn't-"batteries-included"'s-intent-ly y'rs - tim

PS: If you simply want to *use* a high-powered rational type,
download gmpy and be happy tonight.

 

[Josiah Carlson]

With the decimals and the unification of int and long coming, it's natural
(for me, anyway) to wonder how much interest there is in a rational type.
There are two PEPs (239 and 240), and the Guido rejects them as no one
seems interested in doing the work, but points out that the python
distribution comes with examples/Demo/classes/Rat.py.

I propose - in the spirit of "batteries included" - that Rat.py be
cleaned up some (mostly to take advantage of the union of ints and
longs) and moved into the standard library.

Any good reasons not to do this?

Update the PEP, do the work, and offer a good rational number object (if
you are interested in doing such). I have personally written at least
two different rational classes, and I am aware of at least 3 others
(though I can't remember their names).

If it is implemented in Python; stay away from the binary GCD algorithm,
Euclid's is faster.

- Josiah

 

[Bengt Richter]

Update the PEP, do the work, and offer a good rational number object (if
you are interested in doing such). I have personally written at least
two different rational classes, and I am aware of at least 3 others
(though I can't remember their names).

If it is implemented in Python; stay away from the binary GCD algorithm,
Euclid's is faster.

I just looked at Rat.py in the demos, and I am wondering why floating point
is at all included. IMO rationals should be exact, and unless you define
what exact value you would like to have a floating point value represent (e.g.,
all available bits, or some rounding specification) you don't have a way
to make an exact rational. With longs there is no legal floating point double
number whose value can't be represented exactly as a rational, so there's no
problem except deciding. Likewise any floating point string literal can be
converted exactly, e.g., '123.4e-5' => Rat(1234, 1000000) etc., which I think
can be handy. BTW, IIRC complex is implemented strictly with floating point pairs,
so that doesn't seem satisfactory, unless a new complex class is implemented using
rational pairs. Otherwise I'd say leave complex out.

Obviously fractional powers can produce non-rational results, so that poses
a design problem if you want to handle them at all.

Anyway, am I the only one who thinks that rational should be exact?

Regards,
Bengt Richter

 

[Nick Craig-Wood]

PS: If you simply want to *use* a high-powered rational type,
download gmpy and be happy tonight.

I was just about to chip in with that!

http://gmpy.sourceforge.net/

gmpy is really good (I've used it for some numerical experiments).
Its very fast and very easy to use and has very good infinite
precision integers (mpz, rationals mpq and floats mpf)

However it still seems to be in alpha after its last release more than
one year ago?
.... sum = zero
.... i = zero + 1
.... n = 1
.... epsilon = (zero + 10) ** -digits
.... while i > epsilon:
.... sum += i
.... i = i / n
.... n += 1
.... return sum
.... 337310723185584470837549/124089680346647887872000

 

[Josiah Carlson]

I just looked at Rat.py in the demos, and I am wondering why floating point
is at all included. IMO rationals should be exact, and unless you define
what exact value you would like to have a floating point value represent (e.g.,
all available bits, or some rounding specification) you don't have a way
to make an exact rational. With longs there is no legal floating point double
number whose value can't be represented exactly as a rational, so there's no
problem except deciding. Likewise any floating point string literal can be
converted exactly, e.g., '123.4e-5' => Rat(1234, 1000000) etc., which I think
can be handy. BTW, IIRC complex is implemented strictly with floating point pairs,
so that doesn't seem satisfactory, unless a new complex class is implemented using
rational pairs. Otherwise I'd say leave complex out.

Obviously fractional powers can produce non-rational results, so that poses
a design problem if you want to handle them at all.

Anyway, am I the only one who thinks that rational should be exact?

I'm a big fan of being exact whenever possible (hence the symbolic
maximum and minimum values PEP...which strangely enough, a friend that I
introduced to Python commented out of the blue that a symbolic infinity
/should/ be in Python, but I digress). Every rational class I've
written used longs, and I am of the opinion that any reasonable rational
class /would/ use longs.

The moment one cannot help but return a float, return a float (like
sqrt(1/2)).


It does look like gmpy does the right thing in most cases, though I am
uncertain as to its suitability for Python stdlib inclusion.


- Josiah

 

[Mike Meyer]

[Mike Meyer]

With the decimals and the unification of int and long coming, it's
natural (for me, anyway) to wonder how much interest there is in a
rational type.

There are two PEPs (239 and 240), and the Guido rejects them as
no one seems interested in doing the work, but points out that the
python distribution comes with examples/Demo/classes/Rat.py.

I propose - in the spirit of "batteries included" - that Rat.py be
cleaned up some (mostly to take advantage of the union of ints and
longs)
+0

and moved into the standard library.
-1

Any good reasons not to do this?

There's no reason not to clean it up. But Rat.py belongs where it is
regardless: it *is* "a demo", too half-baked for the standard
library. There's a better implementation in the Python sandbox:

http://cvs.sf.net/viewcvs.py/python/python/nondist/sandbox/rational/

Cool. I knew there had to be some out there, but couldn't find one in
either PyPI or the cookbook. I picked on Rat.py because it was what I
found.

Moshe left that behind going on 4 years ago now, as a prototype for
PEP 239. It's also far from being suitable for the standard library:
the PEP is more a sketch of an idea than a specification, the PEP
needs to be accepted, the module needs real documentation, and it
needs a test suite.

Actually, I don't like the two PEPs. Both include changes to the
language that would surprise programmers and non-programmers as well
as having a negative impact on performance. You should only get a
rational if you specifically ask for a rational.

And I'm aware that any "clean up" means writing real documenation and
a test suite, as well as fixing the code.

leaky-AAA-cells-wasn't-"batteries-included"'s-intent-ly y'rs - tim

PS: If you simply want to *use* a high-powered rational type,
download gmpy and be happy tonight.

No - it's that rationals are available in a number of other
programming languages I use, and it seems strange that they would be
missing from a language that comes with "batteries included".

And yes, I am willing to do this work. But don't want to bother if
there's no chance of it getting into the standard library. Creating
yet another rational package outisde the standard library is pretty
pointless.

<mike

 

[Tim Peters]

[Tim Peters]
[Mike Meyer]

Cool. I knew there had to be some out there, but couldn't find one in
either PyPI or the cookbook. I picked on Rat.py because it was what I
found.
....

Actually, I don't like the two PEPs. Both include changes to the
language that would surprise programmers and non-programmers as
well as having a negative impact on performance. You should only
get a rational if you specifically ask for a rational.

Not true of PEP 239. The only specific thing it proposes is adding a
rational() constructor to the builtins, of course backed by a new
rational type. Some *possible* interactions with the rest of the
language are briefly discussed in its "open issues" section.

....

No - it's that rationals are available in a number of other
programming languages I use, and it seems strange that they would be
missing from a language that comes with "batteries included".

And yes, I am willing to do this work. But don't want to bother if
there's no chance of it getting into the standard library. Creating
yet another rational package outisde the standard library is pretty
pointless.

If you want to use rationals in Python, gmpy is a fine way to do it today.

There's always been some interest in adding rationals to the core, but
I wouldn't say "a lot". There was a lot more interest in adding a
decimal type to the core, and the first version of that is being
released in Python 2.4 this year. Since the decimal type supports
user-settable precision, it can handle exact decimal-fraction + - *
operations within the bounds of the precision set, and "gracefully"
lose precision when that bound is crossed.

Many arguments in favor of rationals have been made over the last
decade, but it's unclear how many will still be made after the decimal
type becomes familiar. For example, the historically common argument
that rationals would support exact addition of dollars-and-cents
values will lose all force. The less common argument that it's
somehow obscene <wink> not to have a type for which 1/x*x == 1 will
still hold.

In any case, if you don't like the existing rational PEPs (which isn't
hard to understand ...), the best hope to get rationals into the core
is to ask Guido to reject the current dead-in-the-water PEPs, and
start a new alternative PEP. I suspect you assume that adding a
library module would be exempt from the PEP process, but that's not
so. The most relevant example is that 2.4's decimal module is a pure
Python module, and absolutely nothing in the rest of the language
changed to accommodate it -- it didn't even get a builtin constructor.
That may change over time, but its PEP was only "selling" the Python
module we now have.

 

[Nick Craig-Wood]

If you want to use rationals in Python, gmpy is a fine way to do it
today.

I would say gmpy (or something like it, eg mxNumber) should be added
to the standard library.

I'm personally more interested in the fixed point numbers rather than
the rationals, and having played with various implementations of that
concept recently, I can say that the new decimal module is by far the
slowest, and gmpy is by far the fastest.

Eg simplistic program to calculate 1000 decimal places of e :-

gmpy.mpf 0.00271s
FixedPointNcw.py 0.0118s (FixedPoint.py with simple mod for * by int)
FixedPoint.py 0.358s
decimal 1546.9s

People are going to come new to Python and see the decimal type and
think - oh this looks ideal for high precision calculations, then get
rather a shock!

The GMP library upon which gmpy it is based

http://www.swox.com/gmp/

is very portable and lovingly maintained by a team of experts ;-) Why
should python re-implement its own versions of what it does when it
exists already in a usable (LGPL) format? In fact I'd go one further
and suggest gmpy.mpz() should replace long(). Yes python now has a
Karatsuba multiply for long * long, but GMP has much more...

http://swox.com/gmp/manual/Multiplication-Algorithms.html

Anyway, I see from a bit of googling that python used to have an mpz
module based on GMP in the stdlib, but it was dropped for some reason.
Probably the pain of external library dependencies in cross platform
code (a very familiar pain from my day to day working life!).

 

[Mike Meyer]

I would say gmpy (or something like it, eg mxNumber) should be added
to the standard library.

I'm personally more interested in the fixed point numbers rather than
the rationals, and having played with various implementations of that
concept recently, I can say that the new decimal module is by far the
slowest, and gmpy is by far the fastest.

Eg simplistic program to calculate 1000 decimal places of e :-

gmpy.mpf 0.00271s
FixedPointNcw.py 0.0118s (FixedPoint.py with simple mod for * by int)
FixedPoint.py 0.358s
decimal 1546.9s

People are going to come new to Python and see the decimal type and
think - oh this looks ideal for high precision calculations, then get
rather a shock!

Possibly the documentation for the decimal modules (and any rational
module) should mention this, and provide a pointer to gmpy?

<mike

 

[Tim Peters]

[Nick Craig-Wood]
....

I'm personally more interested in the fixed point numbers rather than
the rationals, and having played with various implementations of that
concept recently, I can say that the new decimal module is by far the
slowest, and gmpy is by far the fastest.

Eg simplistic program to calculate 1000 decimal places of e :-

gmpy.mpf 0.00271s
FixedPointNcw.py 0.0118s (FixedPoint.py with simple mod for * by int)
FixedPoint.py 0.358s
decimal 1546.9s

People are going to come new to Python and see the decimal type and
think - oh this looks ideal for high precision calculations, then get
rather a shock!

When they do, point them at gmpy.

The decimal module's intent is to provide a complete and conforming
implementation of IBM's proposed standard for decimal arithmetic:

http://www2.hursley.ibm.com/decimal/

gmpy doesn't aim at that.

The GMP library upon which gmpy it is based

http://www.swox.com/gmp/

is very portable and lovingly maintained by a team of experts ;-)

Why should python re-implement its own versions of what it does
when it exists already in a usable (LGPL) format?

As above, GMP''s and decimal's goals have a tiny intersection.

In fact I'd go one further and suggest gmpy.mpz() should replace
long(). ....
Anyway, I see from a bit of googling that python used to have an mpz
module based on GMP in the stdlib, but it was dropped for some
reason. Probably the pain of external library dependencies in cross
platfor code (a very familiar pain from my day to day working life!).

Nobody cared enough about mpz to support it, and people who cared
enough about GMP to want it were happy enough with the other Python
wrappers (gmpy and Marc-Andre Lemburg's mxNumber). Or, at least, they
were happy enough that they didn't volunteer work on mpz. We can only
distribute what people contribute.