Re: [boost] Fixed-Point Decimal Type

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-05-21 17:30:31

Gabriel Dos Reis wrote:
> 
> John Max Skaller <skaller_at_[hidden]> writes:
> 
> [...]
> 
> |       The LIA-FP model isn't quite applicable here: it is intended
> | to model various hardware, emphasising _discovery_ of the rounding
> | mode used, and dynamically setting the mode of the hardware
> | (since that is often possible).
> 
> Untrue.  The LIA model does not require a dynamic setting and nor does
> emphasize discovery.  That setting can be part of the properties of the
> floattint point datatype.  It is more flexible than the
> characterization you're giving.

        I wan't trying to characterize it completely.
The point I was trying to make was that LIA takes into account
a much wider setting than is needed here (IMHO).

> Here, we're designing from scratch and we need to be careful about
> mischaracterizations. 

        I agree. Thats why I said "isn't _quite_ applicable".
My intent was simply that we do not need to deal with the
whole LIA/rounding apparatus, that really _is_ needed
when supporting a wide range of floating point models.

        My 'gut feeling' on this is that the basic
calculations don't involve rounding at all. 
They're exact. My mental model is driven by an implementation
model: fixed point arithmentic does integer arithmetic at
run time, and the position of the point is tracked statically
by the type system.

        That is why I don't think that 'round on multiply'
is the correct solution: I proposed:

        decimal<n+m> mul(decimal<n> a, decimal<m> b)
        { return a.rep * b.rep; }

which is exact and very fast. If you want to round the result,
you do it explicitly with an expensive function:

        decimal<n> round_up<n>(decimal<m> a)

which rounds 'a' to n places.  One problem with this approach
is that overflow on multiply occurs before rounding:
if the rounding is 'built-in' to the multiply, it is possible
to avoid overflow in some cases:

        decimal<n> mul<n>(decimal<n> a, decimal<n> b)

is more general and could avoid overflows (by, for example,
scaling the arguments first, before multiplying).

Note that these kinds of issues do NOT occur with floating
point as such: at best, with FP, you have two or three
discrete FP types with differing precisions. Here we have 
a whole family of decimal types (one for each number of
decimal places), and we don't have to contend with
various specialised pieces of hardware.

-- 
John (Max) Skaller, mailto:skaller_at_[hidden]
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net