Re: why still use C?

On 27 Nov 2003 07:15:07 GMT in comp.lang.c.moderated, "P.J. Plauger"
<[EMAIL PROTECTED]> wrote:

>"Hans-Bernhard Broeker" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]
>
>> In comp.lang.c.moderated P.J. Plauger <[EMAIL PROTECTED]> wrote:
>> > "Hans-Bernhard Broeker" <[EMAIL PROTECTED]> wrote in message
>> > news:[EMAIL PROTECTED]
>>
>> > > I'm all for it, _as_long_as_ it doesn't interfere with existing code.
>> > > Scientists will insist that behaviour of existing code that does rely
>> > > on FP being done in base 2 doesn't change.
>>
>> > You really think so?
>>
>> Yes.  Been there, done that.  It was big High-Energy Physics
>> experiment, with a total project time of more than a decade, and still
>> counting.  Lots of computations go on between the actual raw data
>> taking and the output of published results.  At least 3 generations of
>> computer hardware were involved over the time the experiment has been
>> running, and they want to be sure that changing the FPU doesn't affect
>> the results.  Not even minimally.  Result was that they decided to
>> re-configure the Intel FPUs to turn of their "excess" precision.
>> These guys would be *very* upset if a compiler came out that no longer
>> supported binary FP.
>
>This is the kind of simplistic thinking I was referring to when I
>wrote (and you clipped):
>
>: Perhaps you're thinking of the constituency who think the `right'
>: answer is the one that reproduces all the noise digits exactly
>: from the original test run. Not much help for them.
>
>I remember when Princeton University upgraded their IBM 7090 to an
>IBM 7094, which would trap on a zero divide instead of effectively
>dividing by one. After one week of production code bombing regularly,
>the user community *demanded* that the divide check trap be left
>permanently disabled. They just didn't want to know...
>
>I have trouble stifling the evolution of a programming language
>standard to accommodate people who `solve' problems this way.
>
>> > Most `scientists' I know are content to have their FP calculations
>> > produce results that look more or less reasonable to, say, a dozen
>> > decimal places.
>>
>> Then may you only know `scientists' (including the quotes), but no
>> actual scientists.
>
>Uh, I spent most of a decade in cyclotron laboratories while earning
>an AB and a PhD in nuclear physics. I worked my way through school
>writing computer programs for both theoretical calculations and
>data reduction. I've spent a good part of the past 40 years writing
>and rewriting math functions that only a small fraction of our
>clientele cares much about. Many of them consider themselves
>`scientists'. I do too, to the extent they favor rational thinking
>over dogma and/or officiousness.
>
>> I see no problem adding new features to the language.  But the day you
>> start removing features is when you may be causing real trouble for
>> people out there.
>
>Who's talking about removing features? Standard C has *never* promised
>that floating-point arithmetic will be done in binary. And it's damned
>hard to write a program that can determine whether it is.
>
>> Actually, if the plan were to just use decimal FP *instead* of the now
>> common binary FP, there would be nothing for the committee to decide
>> about, as far as I can see.  A platform with FLT_RADIX==10 should be
>> perfectly compliant right now, as far as I can see.  It might enrage
>> some potential users and steer them away from such a platform, but
>> that's an economic risk for its vendors to worry about rather than a
>> concern for the C standardization comittee.
>
>You're mostly correct. The one added piece of work would be to add
>the handful of functions recommended by IEEE 754R. I believe those
>can and should be overhauled to be useful for floating-point of
>*any* base.
>
>> The only thing the current standard(s) doesn't support, and thus
>> requiring an actual committee decision, would be having more than one
>> FP base available on the same platform, to be used within the same
>> program.  And once you support more two, you have to make essentially
>> 3 substantial decisions:
>>
>> 1) Whether to prescribe which of them is used as good old float,
>>    double & surrounding tools, or leave that to the implementors
>> 2) If so, which one to prescribe.
>> 3) Whether to make support for the known-base types optional or mandatory
>
>Exactly. That's *so* much more work than simply fleshing out good
>support for 754R *if present* that it's really worth avoiding, if
>at all possible. I want to explore thoroughly the implications of *not*
>having Standard C support multiple floating-point formats simultaneously,
>before we commit to adding all that complexity to C.

Oh good -- "spirit of C" thinking -- and don't the IBM C compilers
currently select between binary and hex FP instructions with options?
Are they proposing to support anything more than a decimal FP
instructions option? 
-- 
Thanks. Take care, Brian Inglis         Calgary, Alberta, Canada

[EMAIL PROTECTED]       (Brian dot Inglis at SystematicSw dot ab dot ca)
    fake address                use address above to reply
-- 
comp.lang.c.moderated - moderation address: [EMAIL PROTECTED]