Re: a question about formatOf operations

["Malcolm Cohen" <malcolm@xxxxxxxxxxx>]

On Fri, 07 Mar 2008 10:37:30 +0900, David Hough 754R work <754r@xxxxxxxxxxx> 
wrote:
> > > In my view, the principal issue is that clause 10 (expression evaluation)
> > > recommends that:
> > >
> > > 1) languages define the "literal meaning" of arithmetic statements by
> > > translating them into 754R operations
> > > In general, programming language vendors don't want that.
> > Most users don't want that either.
>  The "literal meaning" is what you get by default, unoptimized.

I don't agree.

> Why would users not want that to be documented and implemented?

The "literal meaning" is what programs get, full stop.
Barring software and hardware faults of course.

> Optimized code may well deviate from the "literal meaning" due to the
> difference between floating-point arithmetic and real numbers.

In my experience programs without optimisation also use floating-point
arithmetic that differs from real numbers.

> > > according to these principles, Fortran should define the semantics of
> > >       w = x + y + z
> > > whether from left to right or right to left, and if the types differ,
> > > where widening of operands occurs.
>  > > That is completely unacceptable.  Fortran is not going to do that.
>  That might be true - it's hard to predict what a committee might do.

Not at all hard for a demand like that one.
It would probably be close to unanimous disapproval!

I wrote:
> > Not one proposal in this direction (and there have been several) have
> > been even close to achieving lack of consensus against them, let alone
> > achieving consensus in favour of them.
>
> Yet there are numerous instances of compiler directives with larger or smaller
> scopes being used to extend Fortran in various ways,
> not as smoothly as if they had been
> integrated into the language.    And every Fortran compiler has something like
> "-O" as a compile time option with large scope, augmented by a vast set of
> modifiers unique to each implementation.    It would have been better if 
> something
> more portable were better integrated with the language.

There are very good reasons why not, starting with "vast set of modifiers
unique to each implementation", continuing with [many modifiers being
horrendous kludges, most of the kludging being essential to their effective 
use].

> > Fortran doesn't standardise computer arithmetic and its properties at all.
> > As far as Fortran is concerned, it is outwith the scope of the standard.
> > It is not defined by the language or by the processor: it is not defined
> > at all.
>
> That's an interesting position for a language oriented toward floating-point
> computation!

And the correct position.

Fortran is not about standardising computer arithmetic, it is about
standardising a programming language.  Limiting a general programming
language to one particular computer arithmetic does not seem like an
obviously good thing to do.  I'm sure the people who wrote the floating
point for the IBM 704 were very proud of their product too, but it doesn't
mean Fortran ought to have required it (if it had, we would be using
Fivetran by now).

...
> Most Fortran compilers don't optimize by default;

Most don't do full optimisation by default, but that doesn't mean
they come close to satifying your IEEE-specific "literal meaning"
demands.  Most don't.

> users have to say something.
> Yet users manage to put -O in their Makefiles when they want it and not when
> they don't, so "impossibility" seems a strong word.
>
> So there's nothing novel about that aspect of things.    Even within a local
> scope, there's nothing novel about using funny comments in Fortran or
> pragmas in C to control compilation.   The novelty here is asking
> the language standard to better integrate the control of compilation into
> the language so that control of semantics is portable too.
> This may be impossible as you say, but only because of the dynamics of
> standardization committees.

Nonsense.  Good people have tried *and failed utterly* at producing work
acceptable at a technical level.  Maybe this problem will prove tractable
at sometime in the future, but from where I am sitting it looks to be
getting worse, not better.

To a certain extent we are talking about machine-independent specification
of optimisations; well, to quote Bill Wulf,

   "There is no such thing as a "machine-independent" optimization!
    Not one! People who use the phrase don't understand the problem!"

Of course that was 20 years ago but there is still a lot of truth in it.
Another good reason why there is little traction in standardising compiler
directives.

Cheers,
-- 
................Malcolm Cohen (malcolm@xxxxxxxxxxx)