Обсуждение: IEEE 754-2008 decimal numbers

Поиск
Список
Период
Сортировка

IEEE 754-2008 decimal numbers

От
Thomas Munro
Дата:
Hi

Has anyone done any work on IEEE 754-2008 decimal types for PostgreSQL?

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.  I was thinking I would start out by defining
types DECIMAL32 and DECIMAL64 and some casts between those types and
NUMERIC.  (A more ambitious project for later would be defining
arithmetic operators etc using compiler/hardware support).

Thanks
Thomas

Re: IEEE 754-2008 decimal numbers

От
Craig Ringer
Дата:
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....

 > (A more ambitious project for later would be defining
> arithmetic operators etc using compiler/hardware support).

Hmm, yes. I didn't realize c99 added these. gcc's documentation says
that this support is "only activated on certain targets" - meaning
possibly limited platform/cpu support?

http://gcc.gnu.org/onlinedocs/gccint/Decimal-float-library-routines.html

It seems to have been added in gcc 4.3. It has hardware decimal floating
point support on zseries

There's also Intel's Decimal Floating-Point Math Library , which seems
to be BSD licensed, and is apparently what the gcc decimal floating
point support is based on.

http://software.intel.com/en-us/articles/intel-decimal-floating-point-math-library/

http://software.intel.com/en-us/blogs/2008/03/06/intel-decimal-floating-point-math-library/

--
Craig Ringer

Re: IEEE 754-2008 decimal numbers

От
Darren Duncan
Дата:
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