RE: [boost] Fixed-Point Decimal Type

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-05-15 18:56:46

----- Original Message -----
From: Beman Dawes <bdawes_at_[hidden]>
To: <boost_at_[hidden]>; <boost_at_[hidden]>
Sent: Tuesday, May 15, 2001 6:38 PM
Subject: Re: [boost] Fixed-Point Decimal Type

> At 03:10 PM 5/15/2001, Bill Seymour wrote:
>
>  >Gabriel Dos Reis wrote:
>  >>
>  >> I think the ability of choosing rounding mode should not be
>  >> overlooked.  It is an essential part of LIA-1 and later standards.
>  >>
>  >and Beman Dawes responded:
>  >>
>  >> I'm convinced.
>  >>
>  >but I'm not sure that I am.  I'm under the impression that LIA-1
>  >relates more to numeric programming than to accounting.  If I
>  >hear from accountants that they care about multiple rounding
>  >modes, then I'll echo Beman's statement.
>
> Seems like you need to post a query to an accountant's newsgroup to answer
> that one!  Boost isn't a likely hangout for the green eyeshade crowd:-)
>
> One of the things to consider is whether or not adding a defaulted
rounding
> trait/policy template parameter (or a runtime one per Howard's comment)
> really messes up the interface.
>

I think that a template parameter will be too messy.
For example, since a different template argument makes a completely
different class, decimal<N,RoundA> and decimal<N,RoundB> will be seen a
distinct, but that might cause problems -and even confusion-.
Users WILL need to mix classes with different rounding modes but the same
scale, but they will have to deal with the fact that they might differ in
the second template parameter.
For example, I might like to write:

typedef money<2> my_currency ;
void foo ( my_currency );

were foo is not a template function. But I won't be able to do that unless I
stick with a unique rounding mode, which might not be what I need.
Of course I can write a template foo<>(), but that's something users will
like to avoid.

On the other hand, using a runtime mode will be easier in most cases, but
might introduce unexpected behaviour for users not
been aware that the instances of decimal<> they are operating with have
different rounding modes.

As a user, I would accept easly a global rounding mode, that affects the
rounding mode of *my system*. That's the way rounding mode for fp types is
controlled in IEEE754.  However, a global rounding mode will introduce a
whole new branch of implementation issues and I don't think it is in the
scope of this project.

Thus, I'd stick to a fixed round-to-even (banker's style) mode.
Perhaps, I would add a 'round(int ndigits,int mode)' function.

As a rule of thumb -for library design- I always choose to leave features
off, unless I am confident that the feature is very well defined in most of
the sensible contexts and that most users will understand the feature
completely.

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com