At 07:46 PM 2/17/00 +0100, Phillip Helbig wrote:
>> >   A*(B+C) is better, write that
>> >   (A*B)+(B*C) is better, write that
>> >   you don't care ***AND IT IS IN AN INNER LOOP***, write A*B+A*C
>> 
>> The problem with the third notation as a means of requesting the fastest
>> code possible is that it almost certainly will _not_ produce the fastest
>> code on a processor that attempts little or no optimization -- for those
>> processors, A*(B+C) will usually produce faster code.  
>
>But if you are concerned with speed, surely you are using an optimising 
>compiler?  (OK, perhaps you want to hand-code speed BECAUSE you have no 
>optimising compiler.)

I was thinking of the case of a person supporting a code on multiple
platforms.  One may have an optimizing compiler on some platforms but not
all.  Even on a platform where an optimizing compiler is available, this
may not be one of the optimizations it does.  Thus, it is important to have
a notation that does something reasonable if it is translated in a
straightforward way and that gives an optimizing compiler the option to use
an alternative if it seems appropriate.  

When supporting multiple platforms, you don't want to have to hand code
separately for each platform.
>
...
>
>> There have been so many different suggestions about how additional
>> bracketing characters might be used if they were available that I doubt J3
>> would be inclined to consume a bracketing pair on something as "small" as
>> this proposal.  [I tend to think it unlikely that they would use "[ ]" for
>> subscripts for much the same reason.]
>
>Probably true on both counts.  People have objected to [] due to
>Co-Array Fortran, and I think that interval-arithmetic stuff likes them 
>as well.  So why not {} for this?

Whoever doesn't get "[ ]" is likely to request "{ }".  I believe there may
also have been other proposals directly requesting "{ }".
>
>> My gut feeling is that in most programs, "( )" is used primarily to group
>> and only occasionally to force an evaluation stategy, so I like the
>> suggestion that was made when this topic was discussed in the context of
>> interval arithmetic optimization -- provide for a second expression
>> evaluation mode in which parentheses group but do not force evaluation.  
>
>Right---this was the motivation for me starting this thread.
>
>> separate notation would be used to force evaluation -- I happen to like
>> doubled parentheses, but an intrinsic function would also work.  Thus, in
>> the new mode you might write
>> 
>> A*((B+C))		or	A*eval(B+C)		to force addition then multiplication
>> ((A*B))+((A*C))	or	eval(A*B)+eval(A*C)	to force multiplication then
addition
>> A*(B+C)		to give the processor freedom with "addition first" as the default
>> A*B+A*C		to give the processor freedom with "multiplication first" as the
>> default
>> 
>> [Note that if a programmer mistakenly uses the current evaluation mode
>> instead of the proposed new one, the above expression will still give
>> correct answers, but the processor would fail to recognize it had the
>> freedom to consider alternative evaluation strategies in the third case.]
>
>This isn't backward-compatible, as A*(B+C) forces evaluation now; you 
>need a NEW notation for a new feature.

That's why it was proposed to add a second evaluation mode rather than
changing the behavior of the existing mode.  The new mode would reflect
what people usually meant by parentheses, while the old one would be
retained for those people who actually depended on the evaluation order
guarantees it provided.

(If I were writing the description of these two modes, I would probably
make the new mode the primary mode and describe to the old mode as one in
which each grouping parenthesis is interpreted as though it were doubled
(or preceded by "eval").)

The proposal for two evaluation modes might be seen as analogous to there
being two source forms in Fortran 90.  Only one of those source forms was
compatible with FORTRAN 77.

I agree that if you want to extend the current evaluation mode rather than
introducing a new one, then the new notation must be used for grouping
without forcing evaluation.  I find this approach less attractive because I
think you most often want to group without forcing evaluation.  Thus, if
you wish to introduce the new distinction into an existing code, you would
need to convert nearly all of the grouping parentheses to the new
bracketing mechanism.  This seems like a lot of work to me.  In contrast,
if you add a second evaluation mode, you can simply switch to the new mode
and add the forced evaluation bracketing in those few places where you feel
you need it.
>
>> There is a related question about propagating this kind of optimization
>> through assignments.  E.g., in
>> 	T=B+C
>> 	D=A*T
>> should it be permissible for the processor to evaluation D as A*B+A*C.  
>
>Can't this be done now with standard-conforming optimisation?

No.  The published interpretation is that the assignment to T has an effect
similar to parentheses.  (To look at it another way, the license to use
alternative evaluation applies to single expressions and thus single
assignment statements.  No explicit license is given for this kind of
multi-statement optimization.)
--
Kurt W. Hirchert                          [log in to unmask]
Center for Computational Sciences                +606-257-8748


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%