Re: IEEE 754-2008 decimal numbers

From: Darren Duncan <darren(at)darrenduncan(dot)net>
To: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, Thomas Munro <munro(at)ip9(dot)org>, pgsql-general(at)postgresql(dot)org
Subject: Re: IEEE 754-2008 decimal numbers
Date: 2010-10-11 02:29:24
Message-ID: 4CB27684.1060907@darrenduncan.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Craig Ringer wrote:
> On 10/11/2010 04:46 AM, Thomas Munro wrote:
>> Has anyone done any work on IEEE 754-2008 decimal types for PostgreSQL?
>
> I haven't seen any discussion. Perhaps you should ask on pgsql-hackers@
> as well, as some folks who might've tried it read that list but not this
> one.
>
>> I couldn't find anything, so I was thinking it might be a fun exercise
>> for learning about extending PostgreSQL with user defined types. My
>> first goal is to be able to store decimal numbers with a smaller disk
>> footprint than NUMERIC.
>
> NUMERIC just got a smaller header in 9.1, but AFAIK is still binary
> coded decimal (BCD). A smaller and possibly faster fixed-precision
> numeric would certainly be awfully nice. Not everybody needs perfect
> precision, only tightly controlled precision with sane and controllable
> rounding rules.
>
> What I'd give for rounding rule control with numeric types....

I for one did design in rounding rule control awhile ago to my "Muldis D"
language for object-relational DBMSs such as Postgres.

My specification lets you apply a rounding rule to any operation that would in
general produce an irrational number so to say how exactly it would be rounded
to a rational number (assuming we're not doing symbolic math), or it could be
used simply for rounding, such as when degrading a "big rat" to a fixed-bit
numeric type.

The control (which is radix-agnostic) takes 3 details, which are essentially the
target radix (integer 2..N; usually 2 or 10), a quantum size in that radix
(expressed as a usually-negative integer power of the radix), and an enum-typed
indicator to affect rounding direction (9 options so far, including the most
common programming language defaults of Down (floor), ToZero (truncate)).

For example, you could say something like:

foo ** bar round RoundRule:[10,-3,Down]

... or some such to fit the exponentiation result in a DECIMAL with thousandths
precision.

Or, a simpler version to control an all-integer operation:

needed_boxes := num_widgets div widgets_per_box round Up

Other systems would be wise to adapt such a design also.

-- Darren Duncan

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Derk Jan Horstman 2010-10-11 12:33:45 Re: Error while compiling on HP-UX ia64
Previous Message Craig Ringer 2010-10-11 01:40:38 Re: IEEE 754-2008 decimal numbers