Re: why still use C?

From: Morris Dovey (mrdovey_at_iedu.com)
Date: 11/18/03 

Date: 18 Nov 2003 18:57:48 GMT

James Kuyper wrote:

> Morris Dovey wrote:
> ....

(Short reminder that I'm an "ordinary programmer" - and not a
language guru [IANAG])

>>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?

>>Has WG14 made the decision that the needs of "typical billing
>>programs" should determine the C language architecture and
>>associated standards?
>
> Apparantly they've decided that those needs should be considered. Your
> use of "determine" is a loaded phrase; taken to it's logical extreme,
> your criticism implies that the C standard should never contain any
> feature that is needed only by a minority of the users. In fact, most of
> C's features are needed only by a minority, especially in the C standard
> library. A great many programs make no use of floating point at all,
> whether binary or decimal.

Unfair of me. I apologize. I value C as a "tiny" but "rich"
language. I don't worry much about the library (because it's so
easy to expand upon); but feel that the "tiny" and "rich" should
be preserved. In current context, I'd feel very much more at ease
if the change under consideration was to standardize a compiler
switch to produce code using a particular floating point radix;
and perhaps specifying (and requiring) conformance to specific
IEEE standards for each radix supported.

The addition of a decimal floating point type to the C standard
would seem to me burdensome to those who produce compilers for
"small" embedded systems, for example. Fully conforming compilers
are scarce enough already. If the core language becomes
sufficiently bloated, I'm concerned that the standard will become
(or be perceived by implementors as) non-relevant. Note that I'm
/not/ saying that FP-10 wouldn't be useful in embedded systems.

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

> ....

>>Since when (and by whom) has there been a declaration that C is
>>competing (with whom and for what) as a tool for building
>>commercial applications? Is the term "panacea" being added to the
>>language definition?

> The term "commercial" describes most of the software that has ever been
> written in the C language. I suspect you may mean "financial" rather
> than "commercial". There's a lot more freeware out there nowadays, but
> most programs still have to be paid for.

Yup. I did mean "financial". Sorry for the ambiguity. I'm a bigot
who likes freeware and who likes to be paid for designing and
writing programs (and of late, compiling the paid for code with
freeware compilers.)

What I was reacting to was the notion that the C language is
somehow engaged in a competition for the financial community's
attention. That notion struck me as particularly silly because
the financial community is perfectly aware of C and hasn't (in my
experience) needed to be "sold" on the idea of using it.

> C has always been meant to be a general-purpose language. That's similar
> to "panacea", but not as ambitious. It's not meant to be the ideal
> solution for every problem, but it's meant to be an acceptable solution
> for a wide variety of problems. It's a low-level language, far closer to
> assembly language than many others, but not so low-level as to be
> inappropriate for some financial applications.

/Exactly/ so!

>>Given that the floating point radix has never been restricted to
>>any particular value, you should probably not contract the
>>language definition at this point by deciding that you've fallen
>>in love with ten. My sense is that any requirements (other than
>>the specific radix value, of course) for one radix should also be
>>in force for all others.
>
> I think you're under the mistaken impression that decimal floating point
> is being proposed as a replacement for binary floating point. Such a
> mistake would make your criticisms seem more appropriate. My
> understanding was that the proposal is to add support for decimal
> floating point types, in addition to the default types, not that it
> would be a mandatory re-interpretation of them.

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?

If there is a strong desire to "marry" a program to a particular
radix, then why not just do so with a

    #pragma fp_radix 10

or similar.

(After a break for a cup of coffee and a bit of soul searching) I
think I'm skeptical about the need for additional types rather
than simply being reactionary. I just don't see how a new FPU
architecture "under the covers" necessitates a language change. 

-- 
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Read my lips: The apple doesn't fall far from the tree.
-- 
comp.lang.c.moderated - moderation address: clcm@plethora.net

Relevant Pages

  • Re: why still use C?
    ... It's not "high degrees of precision" that are needed. ... A great many programs make no use of floating point at all, ... In general that will happen only when using a radix that is a ... > language definition? ...
    (comp.lang.c)
  • Re: why still use C?
    ... >>of more than a single floating point radix made any sense at all. ... for different types and a different standard header. ... Dan Pop ...
    (comp.lang.c)
  • Re: Is C99 the final C? (some suggestions)
    ... > that someone will try compile their stuff on an old compiler. ... > because the ANSI standard obsoleted them, and everyone picked up the ANSI ... fixed by using another language. ... >>are multiplying two expressions of the widest type supported by your ...
    (comp.lang.c)
  • Re: subroutine stack and C machine model
    ... They could have standardized that the language would be ... getting the facts wrong anyway. ... And the answer, for the Schildt books, is that they consistently produced ... to C start with the standard. ...
    (comp.lang.c)
  • Re: Two Questions about "strlen", "strcat" and "strcpy"
    ... >> No. zero terminated strings is the whole problem in the first place. ... > OR length prefixed strings the language would retain compatibility ... is not easily duplicated with the old standard then it will foster interest. ... The C standards committee is dead. ...
    (comp.lang.c)
Loading