Re: gmpy adapter

From: Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>
To: Daniel Popowich <danielpopowich(at)gmail(dot)com>
Cc: psycopg(at)postgresql(dot)org
Subject: Re: gmpy adapter
Date: 2011-03-01 17:19:29
Message-ID: AANLkTikKRFgyOd2K_F-TS+ThGGKL2GrJiPKDK5BaCWKO@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: psycopg

On Tue, Mar 1, 2011 at 5:03 PM, Daniel Popowich
<danielpopowich(at)gmail(dot)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

In response to

Responses

Browse psycopg by date

  From Date Subject
Next Message Daniel Popowich 2011-03-01 17:39:33 Re: gmpy adapter
Previous Message Daniel Popowich 2011-03-01 17:03:28 Re: gmpy adapter