Re: [boost] Re: arbitrary base floating point class?

From: Damien Fisher (dfisher_at_[hidden])
Date: 2001-09-26 10:35:41

----- Original Message -----
From: <helmut.zeisel_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, September 27, 2001 1:27 AM
Subject: [boost] Re: arbitrary base floating point class?

> --- In boost_at_y..., "Damien Fisher" <dfisher_at_u...> wrote:
> > Hi,
> >
> > I work in a company which processes data from the local stock
> > exchange.  A problem we are running into is that the exchange
> > places an upper limit on the number of significant figures in
> > prices disseminated (10), but the decimal point can float.
>
> Do I understand correctly that your prices are, say USD,
> and the frational part is just cents?
>
> If this is the case,
> will it suffice to make the computations in cent
> and use an arbitrary precision integer class?
>
> Helmut

No, it's slightly more complicated.

Basically, company XYZ will usually trade to tenths of a cent, so generally
we have 3 dp, eg 5.051, 30.012, etc.

However, when these big institutions get together and sell each other half a
billion dollars worth of stock in one hit, they negotiate in terms of
millions of dollars, and when it gets averaged out over the transaction, a
LOT of precision gets used.

So, an off-market trade for XYZ might get reported as 5.051234, etc.

The exchange sets a limit in the documentation of 10 significant figures for
prices, but obviously this is application specific, and not really an issue.

So basically what I wrote was a floating point class which works in base 10,
not base 2.  Eg, 5.051234 becomes the integer 5051234, mantissa 6.  If
really huge numbers need to be stored, then int64_t or even bigints can be
specified as the underlying storage.  Obviously this is not as efficient,
but the loss in accuracy is unacceptable.  While I personally don't see any
point in extending it to other bases, I don't see any point in not doing so
either :).

This requirement is very common in the financial industry, so I can see some
reason for providing a standard interface.  The problem with most standard
"money" or "currency" classes is that they do not allow more than say,
tenths of a cent to be expressed.

Damien