Boost logo

Boost :

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


"Bill Seymour" (Friday, 18 July, 2003 12:43) says:

> Ilya seems to be giving me mutually contradictory requirements.

I have use cases/request for TWO distinctly different needs
that I encountered in financial applications:
  1. storage (representation of financial data),
  2. calculations.
They are complementary to each other, not contradictory.
I further suggest that they are implemented using TWO
different classes.

> On the one hand, he wants objects with a footprint of no more
> than eight bytes; and he correctly points out that that's
> technically feasible if the scale is a template parameter.

This is correct.
For representation of data, it is most natural that precision/scale
is specified explicitly and bound to type. Templates implement it
most adequately in C++.

> Oh the other hand; he seems to want to be able to do any
> arbitrary calculation without rounding which, in general,
> would require objects of infinite precision.

This is not correct, I have not asked for infinite precision.

I did suggest that all calculations should be done with *maximum*
possible precision, which should guarantee precision for ADD/SUB,
and where possible for MUL/DIV/MOD. I also suggest that
calculations are implemented using *another* class (non-template),
where scale would not need to be specified, and would be variable
(not kept on assignment).

> ........ I'm afraid I'll have to
> disappoint him on the second count. I haven't finally
> decided about the first yet.

So what is your current position?
I understood from your rationale you try to solve the needs
of financial applications, and yet you do not plan to cover
the use cases I described. Please provide *your* detailed
examples of what you think they are. Let's discuss them
specifically.

> .... Daryle Walker and Ilya Buchkin are raising some important
> issues that probably go away if the scale is part of the type.
> I'll address that in another message; .......

Let's be specific again.

One of issues that Daryle Walker raised is that current
implementation is INCOMPATIBLE WITH THE STANDARD LIBRARY
(because a != b after a = b). I.e. this would produce
unexpected results when used with std::vector<>. I have not
seen your response on it.

One of issues I raised is with design and semantics of rounding.
I think most of the behavior is unnatural, and the last line
(modification of an argument) is simply dangerous:

    decimal const a( 1, "1.5" ); decimal const b( 1, "1.5" );
    decimal a2( 1, "1.5" ), c1( 2 ), c2( 2 ), c3( 2 ), c4( 2 );
    c1 = a * b; // expected 2.25, but c1 == 2.20
    c2 [round_up]= a * b; // expected 2.25, but c2 == 2.20
    c3 = a [round_up]* b; // expected 2.25, but c3 == 2.30
    c4 = a2 [round_up]* b; // expected 2.25, but c4 == 2.30, AND a2 ==
2.3!!!

I will certainly stay tuned for your comments on how you
plan to address these.

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk