Boost logo

Boost :

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

> 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

(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
>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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at