RE: [boost] Re: Fixed-decimal partial review

From: Keith Burton (kb_at_[hidden])
Date: 2003-07-21 01:33:01

Beman 

What you say is entirely correct but the issues are in the translation
of this into a usable implementation, 
in particular, the scale and precision of the intermediate result of
multipy and divide.

Using the notation Dn where n is the ( fixed ) scale of the decimal.

D5 = D2 * D3 ;

D2 = D2 * D3 ;

Both are valid and realistic requirements for a decimal library.
The first loses accurary unless the calculation preserves 5 decimal
places.
The second can overflow even when the answer would not unless the
calculation preserves precision.

The way my library dealt with was to use an intermediate result with
greater precision / scale than allowed on the public interface. I have
not checked the proposed library to see if this is a possibility for it.

Keith Burton
 

boost-bounces_at_[hidden] wrote:
> At 08:44 PM 7/19/2003, Misha Bergal wrote:
>  >"Beman Dawes" <bdawes_at_[hidden]> wrote in message
>  >news:4.3.2.7.2.20030719112551.01ecfa40_at_mailhost.esva.net...
>  >> Years ago I worked on some general business applications involving
> liquid
>  >> inventories dealing in tank dimensions, gallons, coefficients of
>  >expansion,
>  >> and all sorts of other non-money related data. Fixed-point
> arithmetic was
>  >> essential for those general business applications even though they
> aren't
>  >> strictly speaking financial or money related. (The reasons
> floating point
>  >> won't do is the legal and business need mandated others, including
>  >> government regulators, to be able to repeat the exact
>  computation, and >> produce the exact answer.)
>  >
>  >Beman,
>  >
>  >Could you elaborate a little more about the requirements to use
> fixed point
>  >instead of floating point. Not being an expert in the area, I don't
>  see >many use cases where fixed point would be preferable to
>  floating point. >I really would appreciate if you described your
> ones. 
> 
> Start by thinking of everyday financial calculations. Gasoline is
> priced (in the US) in terms of dollars, cents, and tenths of cents.
> Three decimal places. Gasoline quantities are measured in terms of
> gallons and tenths, or maybe gallons and hundredths. 1 or 2 decimal
> places. Note that consumer protections regulations may mandate the
> number of places. 
> 
> Now if we multiply quantity to two decimal places of quantity times
> price to three decimal places, you might think the answer would have
> five decimal places. Wrong. Practical business considerations, and
> sometimes government regulations mandate the answer should be give to
> two decimal places (dollars and cents.) The rounding mode may also be
> mandated. 
> 
> Likewise, even in a non-financial application like computing
> temperature compensated volume of propane, the requirement isn't to
> produce an answer accurate as many decimal places as possible.
> Rather, the requirement is to meet some mandate (from the government,
> auditors, or some other authority) which specifies how many decimal
> places are desired. Again, rounding mode and other details of the
> computation are sometimes specified, sometimes even at the level of
> intermediate calculation steps. There may also be a repeatability
> requirement - someone (using a different computer, or a hand
> calculator, or even a pencil and paper) may have to be able to repeat
> the calculation, and produce exactly the same answer. 
> 
> If "as accurate as possible" is the requirement, floating point is
> probably best. But sometimes in business and industry a specific
> accuracy in terms of decimal places and rounding modes is the
> requirement. Fixed-point is better for those situations, IMO.
> 
> --Beman
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost