Rational numbers

[Martin Manns]

Hi,

I am starting to use rationals and since I found no batteries included,
I tried out the mxNumber package.

However, I get strange warnings on comparison operations
(which however seem to yield correct results):

---
$ python
Python 2.4.3 (#1, Jan 15 2007, 15:46:19)
[GCC 4.1.1 (Gentoo 4.1.1-r3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

>>from mx.Number import *
a=Rational(0,1)
a

0/1

>>str(a)

'0.0'

>>b=-50000000000000000000000000000000000000000000000000 00000000
b

-50000000000000000000000000000000000000000000000000 00000000L

>>a==b

__main__:1: RuntimeWarning: tp_compare didn't return -1, 0 or 1
False

>>>

---

How do I get rid of these warnings?

Is there any rational number library around that
1) is comparably fast for large denominators
2) allows deriving types from Rationals without wrapping?

Regards

Martin

P.S. The respective mailing list does not like me, so that I try my
luck here.

[Larry Bates]

Martin Manns wrote:

Hi,

I am starting to use rationals and since I found no batteries included,
I tried out the mxNumber package.

However, I get strange warnings on comparison operations
(which however seem to yield correct results):

---
$ python
Python 2.4.3 (#1, Jan 15 2007, 15:46:19)
[GCC 4.1.1 (Gentoo 4.1.1-r3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

>>>from mx.Number import *
a=Rational(0,1)
a

0/1

>>>str(a)

'0.0'

>>>b=-50000000000000000000000000000000000000000000000000 00000000
b

-50000000000000000000000000000000000000000000000000 00000000L

>>>a==b

__main__:1: RuntimeWarning: tp_compare didn't return -1, 0 or 1
False
---

How do I get rid of these warnings?

Is there any rational number library around that
1) is comparably fast for large denominators
2) allows deriving types from Rationals without wrapping?

Regards

Martin

P.S. The respective mailing list does not like me, so that I try my
luck here.

I quick search of Google turned up:

http://books.google.com/books?id=1Sh...PSweVNyi8cS2eg
http://calcrpnpy.sourceforge.net/clnum.html
http://gmpy.sourceforge.net/

-Larry

[Martin Manns]

On Fri, 23 Feb 2007 09:52:06 -0600
Larry Bates <lb****@websafe.comwrote:

I quick search of Google turned up:

http://books.google.com/books?id=1Sh...PSweVNyi8cS2eg
http://calcrpnpy.sourceforge.net/clnum.html
http://gmpy.sourceforge.net/

Sorry that I did not point these out initially.

+ clnum seems to be slower and for speed may be compiled to wrap gmp so
that it is just an additional layer between python and gmp .

+ gmpy is looking pretty unmaintained (dead) to me (newest update of
cvs 10 months ago).

+ boost indeed is a quite nice C++ library. However, I fear that I
would end up writing the python wrappers for operators (+ - * / min
max cmp etc.) myself. I would like to avoid this since these operators
should work correctly for any type (not just int and float) and I have
little experience with verifying such generic code. The problems
encountered in the mxNumber wrapper support this notion.

Martin

[Martin Manns]

On Fri, 23 Feb 2007 11:39:11 -0500
Martin Manns <mm****@gmx.dewrote:

+ boost indeed is a quite nice C++ library. However, I fear that I
would end up writing the python wrappers for operators (+ - * / min
max cmp etc.) myself. I would like to avoid this since these operators
should work correctly for any type (not just int and float) and I have
little experience with verifying such generic code. The problems
encountered in the mxNumber wrapper support this notion.

I just saw the pyboost-linux-0.1.1 package and tried it out.

ImportError: /home/mn/notes/libboost_python.so.1.34.0: undefined
symbol: PyUnicodeUCS4_FromEncodedObject

It seems to have problems with UCS2 compiled python.
Any robust rational wrapper out there?

[bearophileHUGS]

Martin Manns:

+ gmpy is looking pretty unmaintained (dead) to me (newest update of
cvs 10 months ago).

I have used it on Py2.5, so it seems to work anyway, and it's fast
enough for my purposes. And probably soon some alex-shaped life will
show up elsewhere.

Bye,
bearophile

[Marc 'BlackJack' Rintsch]

In <20070223113911.05dcc555@localhost>, Martin Manns wrote:

+ gmpy is looking pretty unmaintained (dead) to me (newest update of
cvs 10 months ago).

What CSV activities do you expect? This package seems to be pretty
stable. As long as there is no bug or incompatible changes in the
underlying library I would not expect changes to that package.

Ciao,
Marc 'BlackJack' Rintsch

[mensanator]

On Feb 23, 10:39 am, Martin Manns <[e-mail]:

On Fri, 23 Feb 2007 09:52:06 -0600

Larry Bates <[e-mail]:

I quick search of Google turned up:

http://books.google.com/books?id=1Sh...lpg=PA625&dq=p...
http://calcrpnpy.sourceforge.net/clnum.html
http://gmpy.sourceforge.net/

Sorry that I did not point these out initially.

+ clnum seems to be slower and for speed may be compiled to wrap gmp so
that it is just an additional layer between python and gmp .

+ gmpy is looking pretty unmaintained (dead) to me (newest update of
cvs 10 months ago).

Actually, gmpy is being maitained even if SourceForge isn't up to
date.

I got my gmpy 1.04a for Python 2.5 Windows binary from

<http://home.comcast.net/~casevh>

I haven't used the rationals all that much, but been very
happy with them when I have.

>
+ boost indeed is a quite nice C++ library. However, I fear that I
would end up writing the python wrappers for operators (+ - * / min
max cmp etc.) myself. I would like to avoid this since these operators
should work correctly for any type (not just int and float) and I have
little experience with verifying such generic code. The problems
encountered in the mxNumber wrapper support this notion.

Martin

[casevh]

On Feb 23, 10:34 am, "[e-mail]" <[e-mail]:

On Feb 23, 10:39 am, Martin Manns <[e-mail]:

On Fri, 23 Feb 2007 09:52:06 -0600

Larry Bates <[e-mail]:

I quick search of Google turned up:

>http://books.google.com/books?id=1Sh...lpg=PA625&dq=p...
>http://calcrpnpy.sourceforge.net/clnum.html
>http://gmpy.sourceforge.net/

Sorry that I did not point these out initially.

+ clnum seems to be slower and for speed may be compiled to wrap gmp so
that it is just an additional layer between python and gmp .

+ gmpy is looking pretty unmaintained (dead) to me (newest update of
cvs 10 months ago).

I worked with Alex Martelli (gmpy's maintainer) to fix a bug found by
mensanator. With Alex's permission, I released it as gmpy 1.04a. Alex
has not updated cvs with the fix.

gmpy 1.04a compiles cleanly with the latest releases of Python and
GMP, so I consider it stable.

>
Actually, gmpy is being maitained even if SourceForge isn't up to
date.

I got my gmpy 1.04a for Python 2.5 Windows binary from

<http://home.comcast.net/~casevh>

I haven't used the rationals all that much, but been very
happy with them when I have.

casevh

[Martin Manns]

On 23 Feb 2007 12:00:10 -0800
ca****@comcast.net wrote:

>
I worked with Alex Martelli (gmpy's maintainer) to fix a bug found by
mensanator. With Alex's permission, I released it as gmpy 1.04a. Alex
has not updated cvs with the fix.

gmpy 1.04a compiles cleanly with the latest releases of Python and
GMP, so I consider it stable.

Actually, gmpy is being maitained even if SourceForge isn't up to
date.

I got my gmpy 1.04a for Python 2.5 Windows binary from

<http://home.comcast.net/~casevh>

I haven't used the rationals all that much, but been very
happy with them when I have.

casevh

Thank you for all the replies.

I think that I am going to switch to gmpy.

Martin

[mensanator]

On Feb 23, 2:00 pm, [e-mail] wrote:

On Feb 23, 10:34 am, "[e-mail]" <[e-mail]:

On Feb 23, 10:39 am, Martin Manns <[e-mail]:

On Fri, 23 Feb 2007 09:52:06 -0600

Larry Bates <[e-mail]:
I quick search of Google turned up:

http://books.google.com/books?id=1Sh...lpg=PA625&dq=p...
http://calcrpnpy.sourceforge.net/clnum.html
http://gmpy.sourceforge.net/

Sorry that I did not point these out initially.

+ clnum seems to be slower and for speed may be compiled to wrap gmp so
that it is just an additional layer between python and gmp .

+ gmpy is looking pretty unmaintained (dead) to me (newest update of
cvs 10 months ago).

I worked with Alex Martelli (gmpy's maintainer) to fix a bug found by
mensanator. With Alex's permission, I released it as gmpy 1.04a. Alex
has not updated cvs with the fix.

gmpy 1.04a compiles cleanly with the latest releases of Python and
GMP, so I consider it stable.

Am I hallucinating? Didn't I see at least some version
of gmpy for Python 2.5 on SourceForge awhile back?
I distinctly remember thinking that I don't have to
direct people to your site, but SourceForge is not
showing anything beyond vesion 1.01 for Python 2.4.

>

Actually, gmpy is being maitained even if SourceForge isn't up to
date.

I got my gmpy 1.04a for Python 2.5 Windows binary from

<http://home.comcast.net/~casevh>

I haven't used the rationals all that much, but been very
happy with them when I have.

casevh

[casevh]

Am I hallucinating? Didn't I see at least some version
of gmpy for Python 2.5 on SourceForge awhile back?
I distinctly remember thinking that I don't have to
direct people to your site, but SourceForge is not
showing anything beyond vesion 1.01 for Python 2.4.

Alex released versions 1.02 and 1.03 as CVS updates only. I think he
may have made an announcement that 1.02 included alpha support for
Python 2.5. 1.04a is 1.03 with one additional fix. I don't think there
has been an official release, though.

casevh

[Gabriel Genellina]

En Fri, 23 Feb 2007 12:35:19 -0300, Martin Manns <mm****@gmx.deescribió:

I am starting to use rationals and since I found no batteries included,
I tried out the mxNumber package.

However, I get strange warnings on comparison operations
(which however seem to yield correct results):

mx.Number.Rational is horribly broken. They break this rule:

a==b =hash(a)==hash(b)

so they can'b be used as dictionary keys, by example.
Try the other packages suggested. I've used clnum without problems.

--
Gabriel Genellina

[aleaxit]

On Feb 23, 12:00 pm, [e-mail] wrote:
...

+ gmpy is looking pretty unmaintained (dead) to me (newest update of
cvs 10 months ago).

I worked withAlex Martelli(gmpy's maintainer) to fix a bug found by
mensanator. With Alex's permission, I released it as gmpy 1.04a. Alex
has not updated cvs with the fix.

Heh, I see why one might get that impression -- I'm in the process of
moving gmpy from sourceforge (where I find it harder and harder, and
ever more problematic, to work) to code.google.com 's new hosting
facility -- gmpy 1.02 prerelease (more updated than that "1.04a", and
particularly including your fix, Case) is already available at
http://code.google.com/p/gmpy/ but I have made no official
announcement yet (partly because what's available is yet limited:
sources, and binaries for Python 2.3, 2.4 and 2.5 but only for MacOSX
10.4 on Macs with intel processors)... building binaries for Windows
(not having a Windows machine or development system) or Universal
binaries for the Mac (due to problems building Universal versions of
the underlying GMP in its latest, 4.2 incarnation... I'm running out
of PPC-based Macs, and have none left with MaxOSX 10.3...) is much
more problematic for me.

To call this (Google Code) release 1.02, with a "1.04" (?) out from
another source, may be confusing, but I'd rather not "force" the
number upwards

I do have one new co-owner on the Google Code "version" of gmpy (Chip
Turner, once author of a similar GMP wrapper for perl, now a Python
convert and a colleague of mine) but I suspect that won't make the
building of Windows (and Universal Mac) binaries much easier. If
anybody who has easy access to Microsoft's MSVC++.NET (and is willing
to try building GMP 4.2 with/for it), or a PPC Mac with XCode
installed (possibly with MacOSX 10.3...), wants to volunteer to build
"the missing binaries" for the platforms that the current owners of
gmpy can't easily support, we could complete, test and release the
definitive 1.02, and move on with the development (I could get
enthusiastic about this again, if I could develop just the sources,
and the binaries for the one architecture I really use -- Macs w/intel
-- rather than strive each time with binaries for architectures that
are quite a pain for me...!-).

Anybody who's interested in helping out is welcome to mail me and/or
use the "wiki" and "issues" entry of the Google Code gmpy site...
Thanks,

Alex

[aleaxit]

On Feb 23, 2:52 pm, [e-mail] wrote:

Am I hallucinating? Didn't I see at least some version
of gmpy for Python 2.5 on SourceForge awhile back?
I distinctly remember thinking that I don't have to
direct people to your site, but SourceForge is not
showing anything beyond vesion 1.01 for Python 2.4.

Alex released versions 1.02 and 1.03 as CVS updates only. I think he
may have made an announcement that 1.02 included alpha support for
Python 2.5. 1.04a is 1.03 with one additional fix. I don't think there
has been an official release, though.

Right: apparently sourceforce doesn't want me to do "releases" any
more (quite apart from the utter mess that doing a "release" on
sourceforce always was and still is), though I can still update the
cvs repository -- that's part of why I'm moving to Google Code
hosting.
Alex

[casevh]

On Feb 23, 3:27 pm, [e-mail] wrote:

On Feb 23, 12:00 pm, [e-mail] wrote:
...

+ gmpy is looking pretty unmaintained (dead) to me (newest update of
cvs 10 months ago).

I worked withAlex Martelli(gmpy's maintainer) to fix a bug found by
mensanator. With Alex's permission, I released it as gmpy 1.04a. Alex
has not updated cvs with the fix.

Heh, I see why one might get that impression -- I'm in the process of
moving gmpy from sourceforge (where I find it harder and harder, and
ever more problematic, to work) to code.google.com 's new hosting
facility -- gmpy 1.02 prerelease (more updated than that "1.04a", and
particularly including your fix, Case) is already available athttp://code.google.com/p/gmpy/but I have made no official
announcement yet (partly because what's available is yet limited:
sources, and binaries for Python 2.3, 2.4 and 2.5 but only for MacOSX
10.4 on Macs with intel processors)... building binaries for Windows
(not having a Windows machine or development system) or Universal
binaries for the Mac (due to problems building Universal versions of
the underlying GMP in its latest, 4.2 incarnation... I'm running out
of PPC-based Macs, and have none left with MaxOSX 10.3...) is much
more problematic for me.

To call this (Google Code) release 1.02, with a "1.04" (?) out from
another source, may be confusing, but I'd rather not "force" the
number upwards

I do have one new co-owner on the Google Code "version" of gmpy (Chip
Turner, once author of a similar GMP wrapper for perl, now a Python
convert and a colleague of mine) but I suspect that won't make the
building of Windows (and Universal Mac) binaries much easier. If
anybody who has easy access to Microsoft's MSVC++.NET (and is willing
to try building GMP 4.2 with/for it), or a PPC Mac with XCode
installed (possibly with MacOSX 10.3...), wants to volunteer to build
"the missing binaries" for the platforms that the current owners of
gmpy can't easily support, we could complete, test and release the
definitive 1.02, and move on with the development (I could get
enthusiastic about this again, if I could develop just the sources,
and the binaries for the one architecture I really use -- Macs w/intel
-- rather than strive each time with binaries for architectures that
are quite a pain for me...!-).

Anybody who's interested in helping out is welcome to mail me and/or
use the "wiki" and "issues" entry of the Google Code gmpy site...

Thanks,

Alex

I can keep building gmpy for Windows. I actually use MINGW since
getting GMP compiled under MSVC is "challanging". I should be able to
build new binaries for Windows this weekend. And I would be happy to
point everyone to a real release.

casevh

[aleaxit]

On Feb 23, 3:44 pm, [e-mail] wrote:
...

I can keep building gmpy for Windows. I actually use MINGW since
getting GMP compiled under MSVC is "challanging". I should be able to
build new binaries for Windows this weekend. And I would be happy to
point everyone to a real release.

Great! May I add you as a Member to the Google Code gmpy project?
After which, you should be able to use svn to get the latest sources,
make fixes, etc, etc -- including (if I understand the Google Code
mechanics correctly) simply uploading the Windows installer or
whatever, if it passes all tests (formal and informal) satisfactorily.

Please don't use the "1.02 prerelease" sources zip -- the SVN trunk is
more updated, I'll make a "1.02 definitive" sources zip once we have
gmpy built and working correctly on all variants of Windows and Mac
that we're going to support (I suggest that the binaries be made for
Python 2.3, 2.4 and 2.5, for Windows, Mac intel and Mac PPC -- unless
we can make Mac Universal work, but I'm finding that quite
problematic... a PPC Mac somewhere I shd be able to find:-).
Thanks,

Alex

[Martin Manns]

On Fri, 23 Feb 2007 20:20:12 -0300
"Gabriel Genellina" <ga******@yahoo.com.arwrote:

En Fri, 23 Feb 2007 12:35:19 -0300, Martin Manns <mm****@gmx.de>
escribió:

I am starting to use rationals and since I found no batteries
included, I tried out the mxNumber package.

However, I get strange warnings on comparison operations
(which however seem to yield correct results):

mx.Number.Rational is horribly broken. They break this rule:

a==b =hash(a)==hash(b)

so they can'b be used as dictionary keys, by example.
Try the other packages suggested. I've used clnum without problems.

I would be interested, under which circumstances the rule is broken.
In my (few) tests, hash(a)==hash(b) worked.

But I will definitely try clnum.
However, I already started trying out gmpy (1.1):

$ python
Python 2.4.3 (#1, Jan 13 2007, 20:53:15)
[GCC 4.1.1 (Gentoo 4.1.1-r3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

>>from gmpy import *
a=mpq(0,1)
a

mpq(0)

>>b=-50000000000000000000000000000000000000000000000000 000000000
a==b

__main__:1: RuntimeWarning: tp_compare didn't return -1, 0 or 1
False

>>>

Looks pretty much the same as mx.Number

Does this warning come up from gmp? Do I have to compile it with
different flags?
Or do both wrappers use the same code?

I would like to encourage the python community (i.e. the guys
maintaining the python docs) to point out a recommended rational
library. In one of the rational PEPs, it is stated that there are
multiple robust rational wrappers for python. But it is not stated,
which ones were thoroughly reviewed.

Martin

[casevh]

Looks pretty much the same as mx.Number

>
Does this warning come up from gmp? Do I have to compile it with
different flags?
Or do both wrappers use the same code?

I would like to encourage the python community (i.e. the guys
maintaining the python docs) to point out a recommended rational
library. In one of the rational PEPs, it is stated that there are
multiple robust rational wrappers for python. But it is not stated,
which ones were thoroughly reviewed.

That specific error message is only a warning that occurs the first
time a comparison operation is performed. I've successfully used gmpy
and just ignored the one-time only error. You can use the "warnings"
module to filter out that error. If I remember correctly, it was fixed
in version 1.01. I know it is fixed in the SVN version.

Which specific version of gmpy are you using? (What is
gmpy.version()?)

I just compiled Alex's most recent SVN version on Linux without any
problems. I'll make Windows binaries next.

casevh

[Martin Manns]

On 23 Feb 2007 22:19:30 -0800
ca****@gmail.com wrote:

Looks pretty much the same as mx.Number

Does this warning come up from gmp? Do I have to compile it with
different flags?
Or do both wrappers use the same code?

I would like to encourage the python community (i.e. the guys
maintaining the python docs) to point out a recommended rational
library. In one of the rational PEPs, it is stated that there are
multiple robust rational wrappers for python. But it is not stated,
which ones were thoroughly reviewed.

That specific error message is only a warning that occurs the first
time a comparison operation is performed. I've successfully used gmpy
and just ignored the one-time only error. You can use the "warnings"
module to filter out that error. If I remember correctly, it was fixed
in version 1.01. I know it is fixed in the SVN version.

Which specific version of gmpy are you using? (What is
gmpy.version()?)

$ python
Python 2.4.3 (#1, Jan 13 2007, 20:53:15)
[GCC 4.1.1 (Gentoo 4.1.1-r3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

>>import gmpy
gmpy.version()

'1.01'

>>>

Martin

[Toby A Inkster]

aleaxit wrote:

If anybody who has easy access to Microsoft's MSVC++.NET (and is willing
to try building GMP 4.2 with/for it), or a PPC Mac with XCode installed
(possibly with MacOSX 10.3...)

I'm writing this message on a MacOS 10.3.9 box with Xcode 1.5 (gcc 3.3)
installed. If you tell me how, I'd be happy to compile it for you.

Contact me through the feedback form on the site below.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact
Geek of ~ HTML/SQL/Perl/PHP/Python*/Apache/Linux

* = I'm getting there!

[aleaxit]

On Feb 24, 12:25 am, Toby A Inkster <[e-mail]>
wrote:

aleaxit wrote:

If anybody who has easy access to Microsoft's MSVC++.NET (and is willing
to try building GMP 4.2 with/for it), or a PPC Mac with XCode installed
(possibly with MacOSX 10.3...)

I'm writing this message on a MacOS 10.3.9 box with Xcode 1.5 (gcc 3.3)
installed. If you tell me how, I'd be happy to compile it for you.

Contact me through the feedback form on the site below.

Thanks, but unfortunately getting GMP 4.2 built right on any platform
is never a trivial task -- GMP's maintainer is apparently actively
hostile to any attempts of making fixes to GMP to make it build
correctly on MAC OS X, in particular. I have a correspondent who
thinks he's got a working patch (for PPC on MacOSX 10.4, at least);
he's very busy but I hope he'll send it to me eventually.

gmpy itself is or should be pretty trivial to build on any platform
(and I'll always happily accept any fixes that make it better on any
specific platform, since it's easy to make them conditional so they'll
apply to that platform only), but the underlying GMP is anything but:-
(.
Alex

[Fernando Perez]

al*****@gmail.com wrote:

gmpy itself is or should be pretty trivial to build on any platform
(and I'll always happily accept any fixes that make it better on any
specific platform, since it's easy to make them conditional so they'll
apply to that platform only), but the underlying GMP is anything but:-
(.

Alex, have you had a look at SAGE?

http://modular.math.washington.edu/sage/

it uses GMP extensively, so they've had to patch it to work around these
issues. You can look at the SAGE release (they package everything as the
original tarball + patches) for the GMP-specific stuff you need, though I
suspect you'll still want to play with SAGE a little bit :). It's a mighty
impressive system.

Cheers,
f

[Gabriel Genellina]

En Sat, 24 Feb 2007 01:42:00 -0300, Martin Manns <mm****@gmx.netescribió:

On Fri, 23 Feb 2007 20:20:12 -0300
"Gabriel Genellina" <ga******@yahoo.com.arwrote:

>mx.Number.Rational is horribly broken. They break this rule:
a==b =hash(a)==hash(b)
so they can'b be used as dictionary keys, by example.

I would be interested, under which circumstances the rule is broken.
In my (few) tests, hash(a)==hash(b) worked.

I can't reproduce this issue with the latest mx experimental package, it
appears to be fixed now. Also, I'm currently using Python 2.5 and it was
2.3 by that time.

--
Gabriel Genellina

[aleaxit]

On Feb 25, 3:09 pm, Fernando Perez <[e-mail]:

[e-mail] wrote:

gmpy itself is or should be pretty trivial to build on any platform
(and I'll always happily accept any fixes that make it better on any
specific platform, since it's easy to make them conditional so they'll
apply to that platform only), but the underlying GMP is anything but:-
(.

Alex, have you had a look at SAGE?

http://modular.math.washington.edu/sage/

it uses GMP extensively, so they've had to patch it to work around these
issues. You can look at the SAGE release (they package everything as the
original tarball + patches) for the GMP-specific stuff you need, though I
suspect you'll still want to play with SAGE a little bit :). It's a mighty
impressive system.

Thanks Fernando, I will take a look at that.
Alex

[Fernando Perez]

al*****@gmail.com wrote:

On Feb 25, 3:09 pm, Fernando Perez <[e-mail]:

>Alex, have you had a look at SAGE?

http://modular.math.washington.edu/sage/

it uses GMP extensively, so they've had to patch it to work around these
issues. You can look at the SAGE release (they package everything as the
original tarball + patches) for the GMP-specific stuff you need, though I
suspect you'll still want to play with SAGE a little bit :). It's a
mighty impressive system.

Thanks Fernando, I will take a look at that.

Just to save you a bit of time, if you unpack the source tarball, inside the
distro you'll find a bunch of .spkg files. Those are really .tar.bz2 files
for each included package, containing the original plus any SAGE patches
and some install-related scripts.

The GMP .spkg has all the OSX patches, plus a few more.

Cheers,
f

[M.-A. Lemburg]

On 2007-02-23 16:35, Martin Manns wrote:

Hi,

I am starting to use rationals and since I found no batteries included,
I tried out the mxNumber package.

However, I get strange warnings on comparison operations
(which however seem to yield correct results):

---
$ python
Python 2.4.3 (#1, Jan 15 2007, 15:46:19)
[GCC 4.1.1 (Gentoo 4.1.1-r3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

>>>from mx.Number import *
a=Rational(0,1)
a

0/1

>>>str(a)

'0.0'

>>>b=-50000000000000000000000000000000000000000000000000 00000000
b

-50000000000000000000000000000000000000000000000000 00000000L

>>>a==b

__main__:1: RuntimeWarning: tp_compare didn't return -1, 0 or 1
False
---

How do I get rid of these warnings?

FYI: The next version of mxNumber will have this warning removed.

Is there any rational number library around that
1) is comparably fast for large denominators
2) allows deriving types from Rationals without wrapping?

Regards

Martin

P.S. The respective mailing list does not like me, so that I try my
luck here.

Why is that ? The egenix-user mailing is open for all our users.
We do require registration to stop spam from reaching the list.

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source (#1, Apr 27 2007)

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

__________________________________________________ ______________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,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