about presicion

[Alex Martelli]

mensanator at aol.com <mensanator at aol.com> wrote:
   ...
> > > > > I just tried it and found out it's not compatible with gmpy.
   ...
> What I meant was the OP can't compare Decimal and gmpy unless he has
> a version of gmpy that runs in 2.4. Or has a version of Decimal that
> runs in 2.3.

Or both 2.3 and 2.4 installed (they coexist).

> I didn't mean it wasn't compatible. I meant you can't use the

Sorry, I read "it's not compatible" as meaning what it says!-)

> 2.3 version of gmpy in the 2.4 alpha that's currently available,

Not the pre-built version, no.

> so I can't experiment with 2.4 because all my interesting programs
> are dependant on gmpy. Not everyone is a professional software
> developer, some of us ignorant users need to be told that.

I'm not sure what being a professional has to do with it -- it's more an
issue of being or not familiar with the specific issues of C-coded
Python extension on Windows.

> > Unfortunately, compiling any binary extension module on Windows for
> > Python 2.4 requires Microsoft's very latest C++ compiler -- I do not
   ...
> How feasible is it that the end user could compile it himself?

As long as the end user has a correctly installed and compatible
compiler, running "python setup.py install" in the directory where the
gmpy sources have been unpacked (and running it with the version of
Python one wants to build for) is all it takes, so I would say
"perfectly feasible".

> Would the command line c compiler from the MS SDK suffice or do you
> have to purchase the full .NET package? Would the source files need
> a lot of tweaking?

I predict no need for tweaking.  I'm not sure what the support for the
MS SDK compiler is currently -- maybe somebody with more current Windows
knowledge can chime in?  It used to be that the free C compiler had no
optimization, thus the resulting gmpy would be substantially slower, but
I don't even know if that is still currently the case or not.

> > Not by magic -- I hope somebody out there owns all the needed
> Microsoft
> > software and is interested in compiling gmpy for Windows under Python
> > 2.4 and making it available, but it won't be me.
> 
> Unfortunately, us ignorant end users depend on the magic that is
> supplied by others. But that doesn't mean we're unwilling to help.
> I had no clue that there won't be any more Windows gmpy updates
> unless someone volunteers to help.

...or unless I happen to get any kind of paid consultancy contract which
requires me to have the latest MS tools, so I can justify purchasing
them (and a PC to run them on, but that's the least of issues).  A
couple of years ago I still made a substantial amount of my income
testing/delivering on Windows, but at the time Win98 (running on win4lin
on my Linux box) and MSVC++6 were sufficient for my clients'
requirements; and lately I've had not much demand for Windows work --
MacOSX, Linux and OpenBSD are it.  But that could change, of course,
e.g. if IronPython turns out to be as big as it seems it might become, I
could get to consult on programs using it (and I doubt they'll use Mono
-- MS dotnet will no doubt be required...).


> I've got an XP machine and given a choice between abandoning Python
> completely and getting a copy of the MS compiler...
> 
> Of course, I realize that handing someone a box of wrenches doesn't
> make them a mechanic. But we always have this newsgroup. I would
> rather try and fail than see gmpy whither away from lack of interest.

I'm quite willing to offer any help, short of purchasing tools I don't
otherwise need, to make gmpy run on all sorts of platforms, whether I
use them myself or not.

> > > Were you aware that there is apparently a memory leak in the
> > > gmpy.divm() function? Calling it several million time caused my
> > > computer to run out of virtual memeory. Luckily, I was able to
> > > work around it using the gmpy.invert() which didn't consume any
> > > memory regardless of how many times it was called.
> >
> > No, I was not aware of that -- I'll look into it, thanks.

I'm still not aware of any bug in gmpy because I can't reproduce your
observation (on MacOSX 10.3.5, Python 2.3).  Try this script...:

import gmpy

tot = 0
while True:
    n = input('How many more divm: ')
    if n<=0: break
    print '%d more...' % n,
    for i in xrange(n): gmpy.divm(3,7,9)
    tot += n
    print '...total %d' % tot

I've used it to perform millions of divm calls and I monitor its virtual
memory usage from the outside, and absolutely no leak shows up.  Maybe
it's in the Windows version of the underlying GMP library...?  Can any
other gmpy user try this out and report...?  Thanks!


Alex