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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-01-11 20:55:05

At 02:51 AM 1/11/2005, Martin wrote:

 >I understand what you are saying but the comments in this thread (except
 >the discussion Daniel and I have about money implementation) seem to be
 >that there is no need for a decimal type in boost unless it is compatible
 >with the upcoming standard.

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.

 > 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. If you see any 
technical flaws in the IEEE specs, it would be useful if you could identify 
them.

(Calling it the "Floating-Point Decimal Arithmetic Technical Report" seems 
to be misleading people, so the name may be changed to just plain "Decimal 
Arithmetic Technical Report".)

 >(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. The tax 
auditors used fp-decimal hand calculators, so they could easily verify our 
computations. That was a long time ago and the tax laws may have changed.

 >Money and currency isn't mentioned on your library roadmap and there are 
no
 >comments here (except from Daniel and he already got a well proven
 >money/currency class that he will make available to boost).

Well, money/currency may no be on everyone's list, but I'll bet there are a 
lot of applications where it would be a very helpful addition.

--Beman