ANN: GMPY 1.11 released
in [Python]
|
Prev: unable to catch this exception
Next: new online shopping.....,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,!!!!!!!!!!!!!!!!!!!!!!!!
From: casevh on 2 Feb 2010 01:45 Everyone, I'm pleased to annouce the final release of GMPY 1.11. GMPY is a wrapper for the MPIR or GMP multiple-precision arithmetic library. GMPY 1.11 is available for download from: http://code.google.com/p/gmpy/ In addition to support for Python 3.x, there are several new features in this release: - Even faster conversion to/from Python longs. - Performance improvements by reducing function overhead. - Performance improvements by improved caching. - Support for cdivmod, fdivmod, and tdivmod. - Unicode strings are accepted on Python 2.x and 3.x. - Fixed regression in GMPY 1.10 where True/False were no longer recognized. Changes since 1.11rc1: - Recognizes GMP 5. - Bugs fixed in Windows binaries (MPIR 1.3.0rc3 -> 1.3.1). Comments on provided binaries The 32-bit Windows installers were compiled with MinGW32 using MPIR 1.3.1 and will automatically recognize the CPU type and use code optimized for the CPU at runtime. The 64-bit Windows installers were compiled Microsoft's SDK compilers using MPRI 1.3.1. Detailed instructions are included if you want to compile your own binary. Please report any issues! casevh
From: Mensanator on 3 Feb 2010 01:03 On Feb 2, 12:45 am, casevh <cas...(a)gmail.com> wrote: > Everyone, > > I'm pleased to annouce the final release of GMPY 1.11. > GMPY is a wrapper for the MPIR or GMP multiple-precision > arithmetic library. GMPY 1.11 is available for download from: > > http://code.google.com/p/gmpy/ > > In addition to support for Python 3.x, there are several new > features in this release: > > - Even faster conversion to/from Python longs. > - Performance improvements by reducing function overhead. > - Performance improvements by improved caching. > - Support for cdivmod, fdivmod, and tdivmod. > - Unicode strings are accepted on Python 2.x and 3.x. > - Fixed regression in GMPY 1.10 where True/False were no > longer recognized. > > Changes since 1.11rc1: > - Recognizes GMP 5. > - Bugs fixed in Windows binaries (MPIR 1.3.0rc3 -> 1.3.1). > > Comments on provided binaries > > The 32-bit Windows installers were compiled with MinGW32 using MPIR > 1.3.1 and will automatically recognize the CPU type and use code > optimized for the CPU at runtime. The 64-bit Windows installers were > compiled Microsoft's SDK compilers using MPRI 1.3.1. Detailed > instructions are included if you want to compile your own binary. > > Please report any issues! My previous replies didn't show up. Something to do the .announce group? I'll trim that and try again. Sorry if they show up eventually. Two issues: 1] why does both gmpy 1.11 and gmpy 1.11rc1 both reply >>> gmpy.version() '1.11' Aren't these different versions? How are we supposed to tell them apart? 2] Is it true that the only changes since 1.11rc1 are not applicable to me since - I'm not using Windows - whether it recognizes GMP 5 is moot as GMP 5 cannot be compiled on a Mac (according to GMP site) Is it possible GMP's problems with getting GMP 5 to compile are the same ones I had with 3.1 on Snow Leopard? (They bemoan not having a set of every Mac system.) Think it would behoove me to try it? > > casevh
From: casevh on 3 Feb 2010 11:37 On Feb 2, 10:03 pm, Mensanator <mensana...(a)aol.com> wrote: > On Feb 2, 12:45 am, casevh <cas...(a)gmail.com> wrote: > > > > > Everyone, > > > I'm pleased to annouce the final release of GMPY 1.11. > > GMPY is a wrapper for the MPIR or GMP multiple-precision > > arithmetic library. GMPY 1.11 is available for download from: > > >http://code.google.com/p/gmpy/ > > > In addition to support for Python 3.x, there are several new > > features in this release: > > > - Even faster conversion to/from Python longs. > > - Performance improvements by reducing function overhead. > > - Performance improvements by improved caching. > > - Support for cdivmod, fdivmod, and tdivmod. > > - Unicode strings are accepted on Python 2.x and 3.x. > > - Fixed regression in GMPY 1.10 where True/False were no > > longer recognized. > > > Changes since 1.11rc1: > > - Recognizes GMP 5. > > - Bugs fixed in Windows binaries (MPIR 1.3.0rc3 -> 1.3.1). > > > Comments on provided binaries > > > The 32-bit Windows installers were compiled with MinGW32 using MPIR > > 1.3.1 and will automatically recognize the CPU type and use code > > optimized for the CPU at runtime. The 64-bit Windows installers were > > compiled Microsoft's SDK compilers using MPRI 1.3.1. Detailed > > instructions are included if you want to compile your own binary. > > > Please report any issues! > > My previous replies didn't show up. Something to do the .announce > group? I'll trim that and try again. Sorry if they show up eventually. > > Two issues: > > 1] why does both gmpy 1.11 and gmpy 1.11rc1 both reply > > >>> gmpy.version() > > '1.11' > > Aren't these different versions? How are we supposed to tell them > apart? Check the name of source tarball? gmpy._cvsid() will return the internal source code revision number. The changes made in each revision number are listed at http://code.google.com/p/gmpy/source/list. I know some applications check gmpy.version(). I don't know if they'll work if the format of the string changes. > > 2] Is it true that the only changes since 1.11rc1 are not > applicable to me since > > - I'm not using Windows > - whether it recognizes GMP 5 is moot as GMP 5 cannot be > compiled on a Mac (according to GMP site) Yes. The only change for GMP 5 was to recognize the new version number when running the tests. > > Is it possible GMP's problems with getting GMP 5 to compile > are the same ones I had with 3.1 on Snow Leopard? (They bemoan > not having a set of every Mac system.) Think it would behoove > me to try it? According to comments on GMP's mailing list, the latest snapshot should work. ftp://ftp.gmplib.org/pub/snapshot/ > > > > > casevh > >
From: Mensanator on 3 Feb 2010 13:22 On Feb 3, 10:37 am, casevh <cas...(a)gmail.com> wrote: > On Feb 2, 10:03 pm, Mensanator <mensana...(a)aol.com> wrote: > > > > > > > On Feb 2, 12:45 am, casevh <cas...(a)gmail.com> wrote: > > > > Everyone, > > > > I'm pleased to annouce the final release of GMPY 1.11. > > > GMPY is a wrapper for the MPIR or GMP multiple-precision > > > arithmetic library. GMPY 1.11 is available for download from: > > > >http://code.google.com/p/gmpy/ > > > > In addition to support for Python 3.x, there are several new > > > features in this release: > > > > - Even faster conversion to/from Python longs. > > > - Performance improvements by reducing function overhead. > > > - Performance improvements by improved caching. > > > - Support for cdivmod, fdivmod, and tdivmod. > > > - Unicode strings are accepted on Python 2.x and 3.x. > > > - Fixed regression in GMPY 1.10 where True/False were no > > > longer recognized. > > > > Changes since 1.11rc1: > > > - Recognizes GMP 5. > > > - Bugs fixed in Windows binaries (MPIR 1.3.0rc3 -> 1.3.1). > > > > Comments on provided binaries > > > > The 32-bit Windows installers were compiled with MinGW32 using MPIR > > > 1.3.1 and will automatically recognize the CPU type and use code > > > optimized for the CPU at runtime. The 64-bit Windows installers were > > > compiled Microsoft's SDK compilers using MPRI 1.3.1. Detailed > > > instructions are included if you want to compile your own binary. > > > > Please report any issues! > > > My previous replies didn't show up. Something to do the .announce > > group? I'll trim that and try again. Sorry if they show up eventually. > > > Two issues: > > > 1] why does both gmpy 1.11 and gmpy 1.11rc1 both reply > > > >>> gmpy.version() > > > '1.11' > > > Aren't these different versions? How are we supposed to tell them > > apart? > > Check the name of source tarball? > > gmpy._cvsid() will return the internal source code revision number. > The changes made in each revision number are listed athttp://code.google.com/p/gmpy/source/list. So, '$Id: gmpy.c 237 2010-01-10 03:46:37Z casevh $' would be Revision 237 on that source list? > > I know some applications check gmpy.version(). I don't know if they'll > work if the format of the string changes. Then gmpy.version() isn't really intended to be a version per se, it's just a level of compatibility for those programs that care? > > > > > 2] Is it true that the only changes since 1.11rc1 are not > > applicable to me since > > > - I'm not using Windows > > - whether it recognizes GMP 5 is moot as GMP 5 cannot be > > compiled on a Mac (according to GMP site) > > Yes. The only change for GMP 5 was to recognize the new version number > when running the tests. Good. > > > > > Is it possible GMP's problems with getting GMP 5 to compile > > are the same ones I had with 3.1 on Snow Leopard? (They bemoan > > not having a set of every Mac system.) Think it would behoove > > me to try it? > > According to comments on GMP's mailing list, the latest snapshot > should work.ftp://ftp.gmplib.org/pub/snapshot/ > I'll have to see if I can get it to work this weekend. I sure hope I don't muck it up after after all the trouble I had getting the previous one to work. Thanks for the links. > > > > > > > casevh
From: casevh on 3 Feb 2010 13:36
On Feb 3, 10:22 am, Mensanator <mensana...(a)aol.com> wrote: > On Feb 3, 10:37 am, casevh <cas...(a)gmail.com> wrote: > > > > > On Feb 2, 10:03 pm, Mensanator <mensana...(a)aol.com> wrote: > > > > On Feb 2, 12:45 am, casevh <cas...(a)gmail.com> wrote: > > > > > Everyone, > > > > > I'm pleased to annouce the final release of GMPY 1.11. > > > > GMPY is a wrapper for the MPIR or GMP multiple-precision > > > > arithmetic library. GMPY 1.11 is available for download from: > > > > >http://code.google.com/p/gmpy/ > > > > > In addition to support for Python 3.x, there are several new > > > > features in this release: > > > > > - Even faster conversion to/from Python longs. > > > > - Performance improvements by reducing function overhead. > > > > - Performance improvements by improved caching. > > > > - Support for cdivmod, fdivmod, and tdivmod. > > > > - Unicode strings are accepted on Python 2.x and 3.x. > > > > - Fixed regression in GMPY 1.10 where True/False were no > > > > longer recognized. > > > > > Changes since 1.11rc1: > > > > - Recognizes GMP 5. > > > > - Bugs fixed in Windows binaries (MPIR 1.3.0rc3 -> 1.3.1). > > > > > Comments on provided binaries > > > > > The 32-bit Windows installers were compiled with MinGW32 using MPIR > > > > 1.3.1 and will automatically recognize the CPU type and use code > > > > optimized for the CPU at runtime. The 64-bit Windows installers were > > > > compiled Microsoft's SDK compilers using MPRI 1.3.1. Detailed > > > > instructions are included if you want to compile your own binary. > > > > > Please report any issues! > > > > My previous replies didn't show up. Something to do the .announce > > > group? I'll trim that and try again. Sorry if they show up eventually.. > > > > Two issues: > > > > 1] why does both gmpy 1.11 and gmpy 1.11rc1 both reply > > > > >>> gmpy.version() > > > > '1.11' > > > > Aren't these different versions? How are we supposed to tell them > > > apart? > > > Check the name of source tarball? > > > gmpy._cvsid() will return the internal source code revision number. > > The changes made in each revision number are listed athttp://code.google.com/p/gmpy/source/list. > > So, '$Id: gmpy.c 237 2010-01-10 03:46:37Z casevh $' would be Revision > 237 > on that source list? > Correct. > > > > I know some applications check gmpy.version(). I don't know if they'll > > work if the format of the string changes. > > Then gmpy.version() isn't really intended to be a version per se, > it's just a level of compatibility for those programs that care? Historically, gmpy really didn't have alpha/beta/rc versions and gmpy.version() just had the version "number" and didn't indicate the status. If I change it, I'd rather go to "1.1.1rc1" or "1.2.0a0" but that might break some applications. > > > > > > 2] Is it true that the only changes since 1.11rc1 are not > > > applicable to me since > > > > - I'm not using Windows > > > - whether it recognizes GMP 5 is moot as GMP 5 cannot be > > > compiled on a Mac (according to GMP site) > > > Yes. The only change for GMP 5 was to recognize the new version number > > when running the tests. > > Good. > > > > > > Is it possible GMP's problems with getting GMP 5 to compile > > > are the same ones I had with 3.1 on Snow Leopard? (They bemoan > > > not having a set of every Mac system.) Think it would behoove > > > me to try it? > > > According to comments on GMP's mailing list, the latest snapshot > > should work.ftp://ftp.gmplib.org/pub/snapshot/ > > I'll have to see if I can get it to work this weekend. I sure hope I > don't muck it up after after all the trouble I had getting the > previous > one to work. > > Thanks for the links. > > > > > > > casevh > > |