Re: Decimal Floating Point (was Re: why still use C?)

Dan Pop wrote:
>>>> That would be nice, too, but what if you need decimal FLOAT?
>>> What for? Given the intrinsic nature of floating point, if the
>>> base is
>>> relevant to your application, then you should review the
>>> application.
>>>
>>> If the ability of representing $3.11 *exactly* is important, simply
>>> do all your computing in pennies and the base used by your floating
>>> point representation no longer matters (only the precision is
>>> relevant).
>>
>> This does not work, because applications are constantly changing.
>> Items are often costed in sub-penny decimal units; taxes are now
>> sometimes specified to 4 or 5 decimal places. The scaling factor
>> you need to apply, to get exact results, is difficult to work out,
>> and
>> has to be updated often as the data changes. And if the application
>> designer or maintainer doesn't allow enough fractional digits, all
>> of a sudden results become Inexact, with no indication.
>
> This is trivially handled by defining the scaling factor as a macro.
> The precision of an IEEE 754 double allows enough space for that,
> without limiting the range of precise representations too much for
> the needs of the usual financial application.

I suggest you try it; it is not trivial at all.

> And what is the exact result of dividing 1 penny by 3, when using
> decimal floating point arithmetic? Or is division a prohibited
> operation for this class of applications?

This is exactly why floating-point is the right solution. Whenever
the result is Inexact, you get the best possible approximation to
the 'ideal' result -- that is, full precision. With a fixed scaling
factor you cannot make full use of the precision unless you
know how many digits there will be to the left of the radix
point.

Mike Cowlishaw
--