Re: gmpy adapter - Mailing list psycopg

From Daniele Varrazzo
Subject Re: gmpy adapter
Date
Msg-id AANLkTikKRFgyOd2K_F-TS+ThGGKL2GrJiPKDK5BaCWKO@mail.gmail.com
Whole thread Raw
In response to gmpy adapter  (Daniel Popowich <danielpopowich@gmail.com>)
Responses Re: gmpy adapter  (Daniel Popowich <danielpopowich@gmail.com>)
List psycopg
On Tue, Mar 1, 2011 at 5:03 PM, Daniel Popowich
<danielpopowich@gmail.com> wrote:

> Thanks for the ideas.  One thing I didn't specify in my original post
> is that the numeric columnss in my database are for monetary values,
> so I can't use binary floating point representations in my python
> code, else I risk inexactness and accumulated error in long
> computations.

Yes, of course: this is the normal reason to avoid floating point
numbers and go for fixed point.

> I need to use decimal floating point, e.g., decimal.Decimal (or
> cdecimal for a C implementation) or a rational object, like
> fractions.Fraction (or gmpy.mpq for a C impl).
>
> I could use mpq for internal computations then use mpf for the final
> conversion to the string I need for my adapter, but I want a single
> type I can use throughout my code without such concerns.
>
> I'm going to try cdecimal for now.

If cdecimal is good for you (i.e. if the decimal semantics is fine),
you may use mpf throughout your program instead of mpq. It is an exact
type (as exact as decimal of course: you can't represent all the
rationals) and likely to be more efficient than mpq. Plus, it maps
directly with the postgres decimal on I/O.

cdecimal may make your life easier instead if you have already working
code using the Python Decimal and you want to speed it up.

-- Daniele

psycopg by date:

Previous
From: Daniele Varrazzo
Date:
Subject: Re: gmpy adapter
Next
From: Daniel Popowich
Date:
Subject: Re: gmpy adapter