[boost] Re: Fixed-Point Decimal Formal Review

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2003-07-18 15:14:37

Bill Seymour <bill-at-the-office_at_[hidden]> wrote in message
news:3F18319D.FD4E498E_at_pobox.com...
> Paul Bristow has convinced me that I need longer, clearer names
> for the I/O manipulators.  First draft:
>
>   pure_number
>   national_currency
>   international_currency
>
>   number_stream_frac_digits
>   number_decimal_frac_digits
>
>   money_stream_frac_digits
>   money_decimal_frac_digits
>   money_locale_frac_digits
>
Those look fine to me.

>
> I'll also take the suggestion to put frac_digits() in the public
> interface and "fraction digits" in the text of the documentation.
>
fine

>
> Daryle Walker and Ilya Buchkin are raising some important issues
> that probably go away if the scale is part of the type.

I'm not sure how to decide if making the scale part of the type is a good
idea.
Do users really want that?
Suppose we apply the LSP (*1) to decimals of different scales, that is, we
subsitute a decimal of one scale with a decimal of a different scale, how
much does the change affect the program behaviour?
If the answer is "not much", it would indicate that type equivalence between
decimals of different scales is important, thus making the scale part of the
type will be more of a burden than a gain.

OTOH, if it is important not to mix/substitue decimals of different scales
without explicit intervention, then the scale should be part of the type.

If the motivation is _only_ to allow for more efficient algorithms and more
compact representations, then I don't think coupling the scale with the type
is the right choice.

(*1) Liskov Substitution Principle
http://www.objectmentor.com/resources/articles/lsp.pdf

>
> Daryle suggests operations that increment and decrement by 1 ULP;
> and I think that's a good idea.  The names I like are next_value()
> and previous_value();

Good.

>  and I'll probably include versions with
> dummy int arguments to parallel the built-in postfix operators.
>
???

> Daryle also suggests opening up the internal representation
> with accessors.  How about:
>
>   int_type raw_value() const;   // value in ULPs
>   int_type unity_value() const; // representation of 1.0
>   int frac_digits() const;      // formerly scale()
>
Hmmmm.
Why not: significand() (or mantisa()), and one()?

Fernando Cacciola