Re: why still use C?
From: Mike Cowlishaw (mfcowli_at_attglobal.net)
Date: 11/22/03
- Next message: Mike Cowlishaw: "Re: why still use C?"
- Previous message: Richard Heathfield: "Re: printing error mesgs."
- In reply to: Morris Dovey: "Re: why still use C?"
- Next in thread: Richard Bos: "Re: why still use C?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 21 Nov 2003 23:48:45 GMT
Morris Dovey wrote:
>>> The need for high degrees of precision in computation is not a
>>> new issue and I fail to see how a change in radix will provide a
>>> major improvement.
>> It's not "high degrees of precision" that are needed. It's a
>> fairly low degree of precision, but it needs to be provided
>> exactly, which makes is similar in some ways to requiring
>> infinite precision.
> I'm going to have to think about this statement for a while. I'm
> mulling over simple arithmatic operations like 1/3, 1/7, etc.;
> and asking myself: "What's improved by performing this operation
> in FP-10?" Am I grossly missing the point?
Perhaps so. Even with those divisions base 10 helps a little,
because the result you get will always be the same as a 'manual'
calculation of the same operation.
But the real benefits are where the results are expected to be
exact, or certain rounding rules must be strictly applied.
See the section 'What problems are caused by using binary floating-point?'
in: http://www2.hursley.ibm.com/decimal/decifaq.html
>>> Would anyone care to wager that "the typical billing program"
>>> /cannot/ be improved by overall factors in excess of three even
>>> if decimal floating point is not provided?
>>
>> It's not an issue where improvement can be measured in terms of "[a]
>> factor in excess of three". The key point is that the financial
>> community has a commonly occuring need for the numbers, as printed
>> with a fixed number of decimal places, to add up exactly to the
>> specified total printed with the same number of decimal places,
>> without roundoff error. In general that will happen only when using
>> a radix that is a power of 10. One solution is to use scaled
>> integers, such that an integer such as 3412 represents a value of
>> 34.12. However, use of scaled integers complicates programs; a
>> common problem is forgetting to apply the scale factor, or applying
>> it inappropriately.
>
> I guess I should have put a smiley on that statement - but I'd
> like to respond seriously to your serious response. When PHLX
> (The Philadelphia Stock Exchange) switched from fractional prices
> to decimal prices in 2000, they switched from scaled integers to
> binary floating point. The difficulties you present were examined
> and efficient solutions implemented. It was a highly educational
> process for all involved since we nearly all "knew" (at the
> beginning) that floating point wasn't any good for monetary
> values. My discovery was that the problem didn't lie with the
> hardware or the format - it lay with the uninformed prejudice of
> programmers.
It is indeed possible, with great care and skilled error analysis, to
use binary floating point for some financial applications (especially
those where no calculation takes place .. numbers are just moved
around). But it is hard and unnecessarily complicated -- and as
soon as the application is modified or maintained, 'accidents' are
just waiting to happen. It's faster (given the hardware), simpler,
and easier to use base-10 arithmetic.
> Never wanting to miss an opportunity to display my considerable
> ignorance, why not leave selection of floating point radix a
> compile/link option? I've been thinking back over all the
> financial code I've ever written/seen and can't think of any
> instance where use of more than a single floating point radix
> made any sense at all. Why not simply use the type names we
> already have?
This would mean that one could never have both binary and decimal
FP data in the same program/structure. A pragma which could be used
inside a program would be especially dangerous (consider the
base being switched inside an #include). The entire existing base
of binary FP functions could not be used from a program which
selected base 10.
Mike Cowlishaw
Google: decimal arithmetic
-- comp.lang.c.moderated - moderation address: clcm@plethora.net
- Next message: Mike Cowlishaw: "Re: why still use C?"
- Previous message: Richard Heathfield: "Re: printing error mesgs."
- In reply to: Morris Dovey: "Re: why still use C?"
- Next in thread: Richard Bos: "Re: why still use C?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
