[boost] Re: Formal Review: fixed-point decimal library

From: Bill Seymour (bill-at-the-office_at_[hidden])
Date: 2003-07-15 07:49:16

Fernando,

Thanks for your input.

The "scale" really is intended to be the number of decimal digits
to the right of the decimal point; so, yes, if int_type on your
system is 64 bits, and if you specify a scale of 18, then no
/whole/ decimal digits will be allowed to the left of the point.
(You might get a 19th digit if it isn't too big.)

One of your tests, for example:
>
> s=2147483647
> [9,s]=2147483647.000000000
> [10,s]=302809239.6290448384
>

Trying to construct the decimal with a scale of 10 results in
signed integer overflow which yields undefined behavior.

>
> Here is a list of other minor issues:
> =====================================
>
> I don't think that is_bounded and is_modulo should be inherited
> from int_type.
>
> is_bounded is intended to be false only for those types which
> can represent numbers in any range. Even if int_type were
> unbounded (is_bounded=false), decimal itself will always
> be bounded, ...
>

Why?

>
> Similarly, is_modulo tells whether the numeric type uses 
> modulo arithmetic, as do the unsigned integral types,
> yet decimal does not do that ...
>

I don't see this.  If int_type just wraps around on overflow,
then why wouldn't the decimal type itself do the same?

>
> ... even if int_type where unsigned, ...
>

int_type can't be unsigned.

>
> Currently, the library cannot be put in a precompiled header
> using BCC because of the 'max_val,min_val' constants. This
> can be solved by making those constants inlined functions.
>

But then they wouldn't be constants, would they?

>
> The documentation is clearly written with some 'old' version
> in mind. I think all references and comparisons with that
> older version should be removed from the docs, or at least,
> put aside on a 'history' section.
>

OK.

>
> IMO the documentation should begin with a brief (but complete)
> overview of what is a 'fixed decimal' number, including the
> concept of a 'scale' (or 'digits' as I much prefer), and of
> rounding modes.
>

I was reticent to do this for fear of talking down to my audience.
I can add more introductory material if others think it would be
a good idea.

>
> I understand why it is not supported to construct a decimal
> from an int_type, but I think that construction from
> 'unsigned int' should be supported ...
>

I'll be happy to put that in if you can give me a use case for it.

>
> The docs say:
>
> "The conversion will be exact if the string contains no more
> than scale digits to the right of the decimal point; otherwise
> the value will be rounded as specified"
>
> This is incorrect, I think. If the string contains more than
> (scale+1) digits, whether to the left or right of the decimal
> point (or both), rounding will ocurr.
>

I think the documentation is basically correct; although if
n * scale**10 can't fit in an int_type, then the behavior is
undefined; so I guess rounding could occur in that case. 8-)

--Bill Seymour