FAQ

[Python] Why gmp is not in the standard library?

Miki Tebeka
Jan 15, 2004 at 10:11 am
Hello All,
On a different thread Skip wrote:
Yes, you're right. Starting at 2**1000 I found three safe primes quite
quickly. Using my version I gave up waiting after seeing one safe prime
float by.
Which made me think why Python don't use gmp as it's primary math
package - we'll get fast results, a lot of number types and much more.

Can't think of any reason why Python is implementing its own long
numbers...
Can you enlighten me?

Thanks.
Miki
reply

Search Discussions

12 responses

  • Michael Hudson at Jan 15, 2004 at 12:26 pm

    miki.tebeka at zoran.com (Miki Tebeka) writes:

    Hello All,
    On a different thread Skip wrote:
    Yes, you're right. Starting at 2**1000 I found three safe primes quite
    quickly. Using my version I gave up waiting after seeing one safe prime
    float by.
    Which made me think why Python don't use gmp as it's primary math
    package - we'll get fast results, a lot of number types and much more.

    Can't think of any reason why Python is implementing its own long
    numbers...
    Can you enlighten me?
    Licensing? IIRC, GMP is GPL.

    Also, possibly, portability.

    Cheers,
    mwh

    --
    34. The string is a stark data structure and everywhere it is
    passed there is much duplication of process. It is a perfect
    vehicle for hiding information.
    -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html
  • Brian Kelley at Jan 15, 2004 at 3:45 pm

    Michael Hudson wrote:
    miki.tebeka at zoran.com (Miki Tebeka) writes:

    Hello All,
    On a different thread Skip wrote:

    Yes, you're right. Starting at 2**1000 I found three safe primes quite
    quickly. Using my version I gave up waiting after seeing one safe prime
    float by.
    Which made me think why Python don't use gmp as it's primary math
    package - we'll get fast results, a lot of number types and much more.

    Can't think of any reason why Python is implementing its own long
    numbers...
    This discussion partly happened a couple of years ago when mxNumber was
    released from egenix. Here is a google link:

    http://mail.python.org/pipermail/python-list/2001-April/040453.html
    Can you enlighten me?

    Licensing? IIRC, GMP is GPL.
    So is bsddb and that is included with python. Anyway, gmp is LGPL'd not
    GPL'd.
    Also, possibly, portability.
    GMP is incredibly portable, it does have one large flaw for use with python:

    Q: I get a Segfault/Bus error in a program that uses GMP to calculate
    numbers with several hundred thousand digits. Why?

    A: GMP allocates most temporaries on the stack, and some machines give
    user programs very little stack space by default. See setrlimit(2) for
    information on how to increase the stack allocation. You can also change
    it from the shell (using ulimit or limit depending on the shell). You
    can also configure with --disable-alloca to instead allocate temporaries
    using malloc, but that will make the library run somewhat slower.

    Brian
  • Skip Montanaro at Jan 15, 2004 at 3:58 pm
    Licensing? IIRC, GMP is GPL.
    Brian> So is bsddb and that is included with python.

    Bsddb is the name of Python's module which wraps Sleepycat's Berkeley DB,
    commonly abbreviated as bdb. Bsddb is in Python and maintained by the
    current developer (Greg Smith), so I assume any necessary accommodations
    were made. A quick glance as a few of the Python files in the bsddb package
    didn't make it look like GPL.

    Bdb's license is not GPL:

    http://www.sleepycat.com/download/oslicense.html

    Skip
  • Brian Kelley at Jan 15, 2004 at 8:27 pm

    Skip Montanaro wrote:
    Bdb's license is not GPL:

    http://www.sleepycat.com/download/oslicense.html
    I stand corrected, it makes perfect sense that the Berkeley DB should be
    released using the Berkeley license :) I don't know why I thought
    otherwise.

    That being said, wasn't there some issue with making the Python License
    GPL compatible for issues like these?
    Skip


    From http Thu Jan 15 21:26:33 2004
    From: http (Paul Rubin)
    Date: 15 Jan 2004 12:26:33 -0800
    Subject: python & mathematical methods of picking numbers at random
    References: <bu6ptu$kjm$1@solaris.cc.vt.edu>
    Message-ID: <7xd69largm.fsf@ruckus.brouhaha.com>

    Bart Nessux <bart_nessux at hotmail.com> writes:
    I am using method 'a' below to pick 25 names from a pool of 225. A
    co-worker is using method 'b' by running it 25 times and throwing out
    the winning name (names are associated with numbers) after each run
    and then re-counting the list and doing it all over again.

    My boss thinks that 'b' is somehow less fair than 'a',
    Both are the same, as you can see by calculating the probability of
    any given name being selected. What is the application, and the
    computer environment? You may also need to worry about correlations
    in the underlying Mersenne Twister PRNG. If the application is
    something where randomness is very important (you're picking winners
    for a big lottery or something) then you should use a better RNG.
  • Jeremy Yallop at Jan 15, 2004 at 11:05 pm

    Brian Kelley wrote:
    Skip Montanaro wrote:
    I stand corrected, it makes perfect sense that the Berkeley DB should be
    released using the Berkeley license :) I don't know why I thought
    otherwise.
    It's not the Berkeley licence, but it's not the GPL either, although
    it's similar:

    * Redistribution and use in source and binary forms, with or without
    * modification, are permitted provided that the following conditions
    * are met:
    [...]
    * 3. Redistributions in any form must be accompanied by information on
    * how to obtain complete source code for the DB software and any
    * accompanying software that uses the DB software.

    Note in particular "and any accompanying software". Previous versions
    of BDB were under the Berkeley licence, which is still included below
    the Sleepycat licence.

    Jeremy.
  • John J. Lee at Jan 16, 2004 at 8:04 pm

    Brian Kelley <bkelley at wi.mit.edu> writes:

    Skip Montanaro wrote:
    I stand corrected, it makes perfect sense that the Berkeley DB should
    be released using the Berkeley license :) I don't know why I thought
    otherwise.

    That being said, wasn't there some issue with making the Python
    License GPL compatible for issues like these?
    Yes.

    "GPL-compatible" is very different from "GPL", of course.


    John
  • Terry Reedy at Jan 16, 2004 at 8:46 pm

    That being said, wasn't there some issue with making the Python
    License GPL compatible for issues like these?
    "GPL-compatible" is very different from "GPL", of course.
    I 'believe' that GPL-compatible means that someone can mix (compile) Python
    with GPL code and release the mixture -- as a GPL bundle, which the PSF
    does not want to do with Python itself but which repackagers are free to
    do. It does not mean that PSF can put GPL code into the core and still
    release Python with *its* non-GPL license.

    tjr
  • Christopher A. Craig at Jan 15, 2004 at 3:02 pm

    miki.tebeka at zoran.com (Miki Tebeka) writes:

    Which made me think why Python don't use gmp as it's primary math
    package - we'll get fast results, a lot of number types and much more.

    Can't think of any reason why Python is implementing its own long
    numbers... Can you enlighten me?
    Originally I'm sure licensing was a concern, but portability is still
    a huge concern. I haven't tried to port gmp, but from what I've heard
    it's an absolute nightmare. Python's long type, on the other hand,
    was (before kmul) essentially a textbook (a Knuth text book, to be specific)
    implementation of multiprecision integers. kmul takes a couple
    shortcuts, especially in cases where the two numbers are of wildly
    differing sizes, but is still pretty close to textbook. As such
    longobject.c should compile pretty much anywhere with anything
    resembling ANSI C with no problems.

    --
    Christopher A. Craig <list-python at ccraig.org>
    Perl is worse than Python because people wanted it worse -- Larry Wall
  • Skip Montanaro at Jan 15, 2004 at 3:04 pm
    Miki> Which made me think why Python don't use gmp as it's primary math
    Miki> package - we'll get fast results, a lot of number types and much
    Miki> more.

    Miki> Can't think of any reason why Python is implementing its own long
    Miki> numbers... Can you enlighten me?

    In addition to the reasons Michael Hudson provided, I'll add:

    * Python's native longs have been around much longer than gmpy, perhaps
    even predating gmp itself.

    * Converting from Python's longs to gmpy would probably be at least a
    moderately nontrivial undertaking.

    Skip
  • Tim Churches at Jan 15, 2004 at 9:20 pm

    On Thu, 2004-01-15 at 21:11, Miki Tebeka wrote:

    Which made me think why Python don't use gmp as it's primary math
    package - we'll get fast results, a lot of number types and much more.

    Can't think of any reason why Python is implementing its own long
    numbers...
    Can you enlighten me?
    As others have said, re-engineering Python to use GMP numeric types
    would be a huge undertaking. But I think there is a case to be made for
    including gmpy as a library in the standard Python distribution. It is
    very small and doesn't take long to compile, but is incredibly useful.

    Of course, someone would need to prepare Python-style docs, and someone
    would need to track GMP development and update the version included with
    Python at each release (the current gmpy developers perhaps) - thus I
    suspect it is more a resourcing issue than anything else. However, if
    some dead wood is ever removed from the Python standard library, I would
    love to see gmpy take its place. Thanks to the gmpy (and GMP) developer,
    BTW.

    --

    Tim C

    PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere
    or at http://members.optushome.com.au/tchur/pubkey.asc
    Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0


    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: This is a digitally signed message part
    Url : http://mail.python.org/pipermail/python-list/attachments/20040116/5ab6872d/attachment.pgp
  • Brian Kelley at Jan 16, 2004 at 4:44 pm

    Tim Churches wrote:
    Of course, someone would need to prepare Python-style docs, and someone
    would need to track GMP development and update the version included with
    Python at each release (the current gmpy developers perhaps) - thus I
    suspect it is more a resourcing issue than anything else. However, if
    some dead wood is ever removed from the Python standard library, I would
    love to see gmpy take its place. Thanks to the gmpy (and GMP) developer,
    BTW.
    Isn't some of this work done?

    http://www.lemburg.com/files/python/mxNumber.html

    Brian
  • Rick Muller at Jan 18, 2004 at 4:19 am
    Tim Churches <tchur at optushome.com.au> wrote in message news:<mailman.418.1074201211.12720.python-list at python.org>...
    However, if
    some dead wood is ever removed from the Python standard library, I would
    love to see gmpy take its place. Thanks to the gmpy (and GMP) developer,

    Amen to that. GMP is a sweet library, and gmpy makes it so easy to
    play around with I can waste all sorts of time when I should be
    getting real work done.

Related Discussions