"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:[EMAIL PROTECTED]
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
