Boost logo

Boost :

From: Ken shaw (ken_at_[hidden])
Date: 2001-05-10 12:43:25


----- Original Message -----
From: "Bill Seymour" <bsey_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, May 10, 2001 11:57 AM
Subject: [boost] Fixed-Point Decimal Interface

> My suggestion for a fixed-point decimal type generated
> a flurry of responses, so I've uploaded a pseudo-header,
> decimal.hpp, that describes what I would consider to be
> a minimal public interface for such a type. I'd like
> to get the interface perfected before I start worrying
> too much about the implementation; so maybe we can use
> this file as a starting point for further discussions.
>
> One discussion I'd like to have is about the type of the
> result of arithmetic operations. Using multiplication
> as an example:
>
> template<int Scale1, int Scale2>
> decimal<???>
> operator*(const decimal<Scale1>&, const decimal<Scale2>&);
>
> should ??? be Scale1 (as I have it now) or Scale1 + Scale2?
> I see this as a very knotty problem, and I'd like to hear
> what other Boosters think.

After looking over the interface that was uploaded and thinking about trying
to use this for any sort of serious app, I think that templating the maximum
number of decimal places is probably not an ideal solution. I suggest an
implementation where there is not a maximum precision. If a calculation
would increase or decrease the number of decimal places stored as needed.

This implementation would have wider usability than just a currency class.
It might be possible to implement various scientific calculations using pi
and natural logarithms and other irrational numbers to whatever precision
was desired for the calculation. Yes this would give up the hard won speed
and efficiency of the fpu. But isn't the fact that a double cannot
accurately represent a 64bit integer a sign that a true full precision
number might be useful?

I do not claim that this decimal class would ever replace the existing fp
types where speed of calculation is at issue.

Ken Shaw


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk