From: ThatWouldBeTelling@thevillage.com
Anton Ertl wrote:
> MitchAlsup writes:
>> So, would it not be easier and faster to simply make a densely-packed
>> 128-bit Fixed-Point decimal function unit ?!?
>
> 128-bit binary integers are mostly good enough, and support for that
> is ok in current architectures; division support might be better,
> though, but see below. Rescaling with a power of 10 is something that
> may merit additional hardware support if it occurs often enough; but I
> am not convinced that it occurs often enough:
>
> You usually don't need it for addition and subtraction, because the
> operands have the same scale factor, and the same scale factor as the
> result.
>
> For multiplication, one common operation is to multiply a price with a
> number of pieces resulting in a price, and no rescaling is necessary
> there. Another common operation is to compute a percentage; you do
> have rescaling there.
>
> For division, it seems to me that the most common case is division by
> a percentage that is applied to many dividends (maybe not in the USA,
> but certainly in Europe it is common to compute the price without VAT
> (sales tax) from the price with VAT; but there are only few VAT rates
> in each country); that can be turned into a two-stage operation that
> might include any necessary rescaling: compute an inverse that can
> then be used for a cheap multiplication-and-rounding operation (e.g.,
> where a power-of-2 scale factor is involved for computing something
> below the least significant digit, in order to implement rounding).
>
> And yes, support for several rounding modes is needed when an inexact
> result is involved. Hardware may be helpful here.
>
> I have not done much financial programming, so maybe somebody else can
> complement my views.
>
> - anton
There are many different kinds of bonds each with its own calculation.
Bonds were invented by the Dutch in the early 1600's.
They are a just a business deal to borrow money and repay it
and these calculations are standardizations of those terms.
People have had 400 years to be creative in designing these deals
which is why there are many different calculations.
Many bonds are time series polynomials with non-integer times.
Many calculations use pow(base,exp) to a non-integer exponent.
I used double for everything and my results were fine
matching the benchmarks exactly to their 11 digits,
and matching the HP Financial Calculator to 13 decimal places.
Decimal would also need conversions with integers and BFP.
Many of these values are coming from and going to databases
and are exchanged with other systems.
The book I have on bond calculations lists different rules for
different types of bonds (municipal, corporate, T-bill, other),
and rules and calculations for price given yield and yield given price.
e.g.:
- all prices and yields calculated to at least 10 significant digits
- for municipal and corporate securities dollar prices should be accurate
to seven places after the decimal, *truncating* to 3 places just prior
to display.
- for T-bills dollar price accuracy should be eight places after the
decimal, *rounding* to seven places just prior to display.
- for all other securities dollar price accuracy should be to seven places
after the decimal, *rounding* to six places just prior to display.
- calculations for yield should be at a minimum accurate to four places
after the decimal. *rounding* to three places just prior to display.
There are also many different ways of counting the number of days
between dates which are not always integers.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
