# Re: Fixed Point Arithmetic

Date: Thu, 29 Mar 2007 18:50:22 GMT

Message-ID: <OTTOh.9329$fA2.1807_at_trndny02>

"Marshall" <marshall.spight_at_gmail.com> wrote in message
news:1175188140.978189.245960_at_r56g2000hsd.googlegroups.com...

> On Mar 29, 7:32 am, "David Cressey" <cresse..._at_verizon.net> wrote:

*> >
**> > These FP numbers do not have closure over multiplication, because the
**> > product may have up to four significant digits after the decimal point,
*

and

> > therefore have to be rounded off for storage purposes.

*>
**> Yes, and they also have overflow.
**>
**>
**> > Anyway, I'm going to say that FP numbers with a scale factor of 2 save
*

an

> > enormous amount of head-scratching when working with bean counting

*> > applications. You won't spend time looking for the missing penny.
***OTOH,
**

*> > if you use these numbers for complicated arithmetic (example:
*

amortization

> > schedule) you have to think about roundoff errors.

*>
**> At my company, we often use fixedpoint with a scale factor of 6
**> for money.
**>
**>
**> > When it comes to the stock market, it depends on the country. AFAIK,
*

the

> > NYSE still records stock "points" in units of dollars, with binary

*> > fractional points like 1/4, 1/32, and the like.
**>
**> I flirted with the idea of stockbroker as career. Got the license,
**> had some clients, etc. Watched the SUNW IPO; that was cool.
**> Had a fancy real-time market data device with me on
**> Black Monday '87, that was dramatic. How low can it go?
**> Ultimately it wasn't for me. Back then (mid-eighties) the
**> NYSE still used fractions, but it's decimal now:
**>
**> http://finance.google.com/finance?q=ibm
**>
**> (Gosh I love it when the URLs are nice and clean.)
**>
**>
**> > Are fixed point numbers a useful form for DBMSes to support?
**>
**> I expect so. Wouldn't it be nice to be able to specify a fixed
**> point type just by supplying the number of bits total and the
**> number of bits to the right of the decimal?
**>
**>
*

I think you could implement this just by extending Oracle's "number"
datatype.

In Oracle, NUMBER (8,3) means 8 digits, with 3 after the decimal point.
We could extend this to

NUMBER (127, 63, 2) where the third argument is the radix. Default radix
would be ten.

That doesn't answer the question of how these numbers would be implemented down at the bits and bytes level. That's really a DBMS internals question. Received on Thu Mar 29 2007 - 20:50:22 CEST