[boost] Re: Any interest in a decimal and money class?

From: Martin (adrianm_at_[hidden])
Date: 2005-01-12 02:28:00

> I don't think the point is that a Boost decimal type has to be compatible 
> with the upcoming decimal TR, but that the Boost decimal type could use the 
> TR types or the Rogue Wave decimal types or whatever as the underlying 
> type.

Well, I got another view. My class implements a decimal type and so does Rogue 
Wave and TR, all with different approaches. When you select a decimal type you 
look at the properties of each type and make your choice based on your 
requirements.

If you try to fit everything into one type you would either have to limit 
yourself to the least common functionality or add workarounds (maybe very 
inefficient) for not supported functionality of the underlying type.

Money is a different matter. There I agree that the the type should allow you 
to use different underlying decimal (or maybe even binary) types.

> Since my solution (and your library roadmap)
>  >is fixed precision and the standard will be floating point (+fixed via
>  >encoding) it is not possible.
> 
> The folks pushing the decimal TR have been claiming that the integer subset 
> is robust enough to handle the usual integer operations. Presumably it 
> would include everything needed to implement fixed-point.

That is my view as well and that is why I created my decimal64 type. Do you 
mean that we don't need a fixed decimal type since everyone can implement it 
themselves using integers?

>  >(And as I said in another post I don't actually see the need for decimal
>  >floating point. It solves a couple of theoretical cases where you can
>  >use == to compare values but are there any real applications for it?)
> 
> Some very experienced people believe there is. While I once implemented a 
> lot of business calculations using decimal floating-point, I never had the 
> luxury of having hardware with both binary and decimal floating-point, so 
> don't know if binary would have been more useful than decimal. But since 
> sometimes we were implementing tax related algorithms specified by law as 
> decimal calculations, it was convenient to work in fp-decimal.

Laws are different everywhere ofcourse but the ones I have seen specify the 
number of decimals to use in a calculation and not the number of digits. Did 
you use a fp-decimal type where you could limit the size of the mantissa?