Re: why still use C?

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

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
-- 
comp.lang.c.moderated - moderation address: [EMAIL PROTECTED]