$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Martin (adrianm_at_[hidden])
Date: 2005-01-09 10:45:16
> The point is that when I want to use a new underlying type for
> calculations, I have a single point of customization, about 100-200
> lines. The specialization of decimal_traits<T> for that type T and the
> typedef for decimal. I don't have to touch the 300.000+ lines of code
> that use it. What do you prefer?
With your solution:
1. typedef basic_decimal<decimal64> decimal
2. typedef basic_decimal<decimalBCD> decimal
With my solution
1. typedef decimal64 decimal;
2. typedef decimalBCD decimal;
Same amount of code to change. (We both need to implement the interface, you
do it in decimal_traits, I do it in decimal64 & decimalBCD). What worries me
with your solution is that your decimal_traits class implies a way to
implement things that might not be the most efficient one for each
implementation.
Lets take an example:
Assume that basic_decimal implements "<=" as "traits::less_than ||
traits::equal" which works fine if "less_than" and "equal" are "cheap"
operations. In decimal64, both "less_than" & "equal" might need to scale one
of the operands before the comparison so the scaling occurs twice in "<=".
With my solution I am free to implement the interface in the most efficient
way for each class.
> I think it's most useful if you work on decimal64 independently of
> money/currency issues. Make it a cool new float-point type and
> basic_decimal will be able to use it :)
Do you have an example of an application where decimal floating point is
useful? To me floating point means that you give up precision to be able to
handle a large range of values. But if loss of precision is acceptable, you
can just as well use binary floating point.
> Another benefit of the indirection through basic_decimal<T>: FWIW, there
> is one thing that my classes don't do right now and which I always
> dreamed of: "Correct" epsilon handling. Like
>
> operator== respects a given epsilon
> native_less(a,b) like the current operator< for the underlying type
Isn't the whole point with decimal math that values are stored exactly? Why
would you need epsilon for exact values?