patch in Python?

[Gerhard Häring]

* Fernando Pérez <fperez528 at yahoo.com> [2002-10-01 14:42 -0600]:
> Gerhard Häring wrote:
> 
> > Using the difflib module, I can create diffs between text files. Now,
> > has anybody written a patch-replacement in Python, yet?
> > 
> > The reason I'm asking is that I'm wrapping a library [1] whose license
> > requires that the sources are distributed unchanged. I don't need to
> > patch the library, yet, but in case I'll ever need, I'd need a Python
> > module to do the patching.
> > 
> > -- Gerhard
> > 
> > [1] http://www.tc.umn.edu/~ringx004/mapm-main.html
> 
> A few questions:
> 
> - Do you think you could post a notice when you have the wrappers
>   done? I'm very interested in this.

Certainly. Although the short-term goal is to provide pyPgSQL with a
fast fixed-point type, the module will certainly be useful outside
pyPgSQL, too. I think it'll make sense to distribute it separately from
pyPgSQL, too.

> - How does this compare to gmpy?

No idea. It doesn't have rationals, which GPM has (not sure about gmpy).
Btw. I think mxNumber from MAL is the GMP wrapper that has the most
momentum nowadays. His aim is a similar one: NUMERIC support for his
mxODBC library.

> - Do you have any plans to bind this into Numeric?

Nope. I'm not much into maths myself. Once this is reasonably finished,
you're free to connect it to Numeric.

> That would be absolutely 
> fantastic. One of the things which keeps us bound to Mathematica here is the 
> need for arbitrary precision algorithms. With Numeric being extended to 
> arbitrary precision, we'd have a great system.
> 
> - Have you looked at http://more.btexact.com/people/briggsk2/XR.html? Do you 
> know how they compare?

Sorry. No idea. The reason for chosing MAPM was that it's _not_ under
the GPL or LGPL and written in C. We don't want to require a C++
compiler for pyPgSQL.

> - And http://www.nersc.gov/~dhbailey/mpdist/mpdist.html? This one is supposed 
> to be first rate.

These are written in Fortran and C++, it seems. See above. In my tries
to wrap MAPM I have found, however, that creating a new Python number
type is relatively easy. So if these are worth wrapping, I think it
should be a matter of days, rather than weeks.

> I'd love to have the ability not only to define extended/arbitrary precision 
> scalars, but especially to have them carry over to Numeric. One could then 
> develop a difficult algorithm in arbitrary precision and then move it over to 
> only extended (or even normal) precision once everything is working reliably.

Yeah, this sounds like a neat idea.

One "problem" I currently have is this:

Under MAPM, certain operations (division, exponentiation, ...) require
an additional parameter for the precision. My current API is this:

module mapm:
def set_default_div_precision(n)
def set_default_pow_precision(n)

class MAPM:
    ...
    def __div__(self, other, precision=None)
    def __pow__(self, other, precision=None)

But under normal operation, such as in:

    a = mapm.MAPM("27.34")
    b = mapm.MAPM("3.17")
    c = a / b

you can't give the precision operator to __div__, so you'd have to set
the precision before with something like:

    mapm.set_default_div_precision(10)

alternatively, you can do without the "/" operator:

    c = a.__div__(b, 10)

but this feels clumsy.

To put it short: do you have any suggestion for a better API wrt.
precision?

-- Gerhard