[boost] Fixed-Point Decimal Formal Review

From: Ilya Buchkin (elias_at_[hidden])
Date: 2003-07-21 18:10:09

I understand today is the last day of the Formal Review,
and author has not made any comments for the last two days,
so my vote will be based on how things stand now.

I vote that the library is NOT accepted.

I think it has major issues (showstoppers) which were raised
on this forum during the Formal Review, and the library is simply
not ready to be accepted.
Particularly:

USABILITY/DOCUMENTATION

1. No references to prior art by the author.
This is a shame, because library addresses the needs that existed for
really long time, and prior art *is* available. (Mention of COBOL
does not count, as it is not backed up by any detail. No indication is
given whether library works as COBOL or how it differs -- is every
user supposed to find it out themselves?)
The lack of prior art in this case is a **showstopper**.

2. The definition of the library goals is too general.  Rationale claims
that library provides "what's needed  for financial software".
My opinion, the Rationale has to enumerate in finer detail
what use cases it supports, and provide code examples.
(I.e. "if you need to achieve such-and-such thing, your code
should look like this")
This is **major** issue, because it affects expectations.

3. I posted previously that I encountered two needs in my financial
applications:
a. data class, with precise representation of decimal numbers
    of up to declared by programmer fixed scale, with small footprint.
b. calculations with maximum possible precision, and variable (floating)
    scale, which would guarantee precision for ADD/SUB and where
    possible for MUL/DIV/MOD.
As it stands right now, the proposed library does not provide good
solution to either of these needs. Author has not commented
whether he is planning to address these needs or not.
The bottom line is that I will not use the library (although based on
declared goals I could), so to me this is **showstopper**.

DESIGN/IMPLEMENTATION

The decision to design the decimal class as lightweight is good.

The design of numerical operations is poor:
1.  a + b != b + a;  and also   a * b != b * a
    These are **major** inconveniences, for numerical class.
2. a = b does NOT imply that a == b
   Particular implication is that class is not std::vector-compatible
   **showstopper**
3. rounding, determined by scale of operands instead of the result:
    decimal a( 1, "1.5" ); decimal b( 1, "1.5" ); decimal c( 2 );
    c = a * b;    // c != 2.25
    c [round_up]= a * b;    // c != 2.25
    c = a [round_up]* b;    // c != 2.25, BUT value of a is changed <-
simply bug?
    c = decimal( 2, a ) * b;  // is this what's needed to get 2.25?

These comments have been made in earlier threads, and
they are fixable, but author has not responded conclusively
on how he plans to address them. As long as this is the case,
I consider the issues unresolved and my vote is "NO".

--
Thanks & Best Regards.
Ilya Buchkin
MetaCommunications Engineering
mailto:elias_at_[hidden]