Lahey Support
08-15-2003, 01:23 AM
I believe you are referring to the Einstein summation convention, in which the
summation symbol (capital sigma) is omitted and summation is understood to be
performed over all repeated indices UNLESS the expression is specifically said
not
to be summed. (If I've mis-described it, somebody please correct me.)
IF I misunderstood what you were referring to THEN
I apologize.
EXIT message here.
END IF
If I am correct, then the expansion you show for d is incorrect, because all
indices
are repeated and therefore should be summed somehow. In this case, assuming
that i,j,k each run from 1 to 3, the expansion can be written in pseudocode
form
(NOT Fortran) as
d = SUM[(i=1,3) SUM[(j=1,3 ) SUM[(k=1,3) a(i,j)*b(i,k)*c(j,k) ] ] ]
This is very similar to what you wrote in your "not means the following
operation"
example, except that you left out (1) an initialization of d to zero before
the nested
loops and (2) the term d itself inside the summed expression. It also
reverses the
order of summation, but that doesn't matter as long as these are simple
numeric
values and not function calls with side effects.
d = 0 !Initialize accumulator variable
DO k = ...
DO j = ...
DO i = ...
d = a(i,j)*b(i,k)*c(j,k) + d ! "+d" needed to accumulate value
END DO
END DO
END DO
Please note that the summation convention specifically allows the expression
to
mean different things depending on whether the author specifies that certain
repeated indices are NOT to be summed. To implement this in a programming
language, it would be necessary to allow the programmer a way to prevent
unwanted summation. That's equivalent to NOT assuming the summation
convention and allowing the author to specify which indices ARE to be summed,
which is what old-fashioned Fortran allows.
I believe that implementing the summation convention would require overloading
the
"+" operator. That can be done in C++, but I don't know about Fortran 90/95.
-- Actually, it would require more than that because the question of which
indices
are summed depends on the entire expression rather than on any individual
term.
I'm not a computer scientist, but the phrase "context-dependent grammar"
springs
to mind, and I know that's a difficult thing that language implementers
generally
avoid.
As to your reference that Fortran is the queen of formula translation, please
note
that it is first of all an EFFICIENT language that maximizes how much
number-crunching can be done in a given amount of time and space. Languages
that are designed to cope with operator overloading and expressions with
multiple
possible meanings have to spend a significant amount of processing power doing
so, and raw number-cruncing power is decreased. Specific example: it might
very
well be that to support operator overloading it would be necessary to use a
pointer
to an index variable rather than the index variable itself. By itself, the
need to
dereference such pointers every time the expression is evaluated in a nested
loop
could hurt performance.
Richard Daehler-Wilking
[address removed]
cosine Cheng wrote:
> Hi:
>
> FORTRAN90 support the way to express/deal in matrix form,
>
> but how about in index form or tensor form.
>
> Here I mean the following operation:
>
> d = a(i,j)*b(i,k)*c(j,k) in index notation
>
> or d = ( a(1,j)*b(1,k)+a(2,j)*b(2,k)+a(3,j)*b(3,k) )*c(j,k)
>
> not means the following operation:
>
> DO k = ...
> DO j = ...
> DO i = ...
> d = a(i,j)*b(i,k)*c(j,k)
> END DO
> END DO
> END DO
>
> The two operation are NOT the same.
>
> Since FORTRAN is the queen of FORmula TRANsformation, how come she
>
> can not deal with tensor notation?
>
> Note that I'm using LF90, if LF95 or any other FORTRAN can deal
>
> w/ tensor notation directly, do let me know.
>
> Thank you
>
> by Cheng Cosine
> Feb/08/2k UT
>
> __________________________________________________ ____
> Get Your Private, Free Email at http://www.hotmail.com
>
> --------------------------------------------------------------------------
> To unsubscribe from Fortran Forum, send a message to [address removed]
> with the following command as the first and only line of the message body:
> unsubscribe fortran
> --------------------------------------------------------------------------
--------------------------------------------------------------------------
To unsubscribe from Fortran Forum, send a message to [address removed]
with the following command as the first and only line of the message body:
unsubscribe fortran
--------------------------------------------------------------------------
summation symbol (capital sigma) is omitted and summation is understood to be
performed over all repeated indices UNLESS the expression is specifically said
not
to be summed. (If I've mis-described it, somebody please correct me.)
IF I misunderstood what you were referring to THEN
I apologize.
EXIT message here.
END IF
If I am correct, then the expansion you show for d is incorrect, because all
indices
are repeated and therefore should be summed somehow. In this case, assuming
that i,j,k each run from 1 to 3, the expansion can be written in pseudocode
form
(NOT Fortran) as
d = SUM[(i=1,3) SUM[(j=1,3 ) SUM[(k=1,3) a(i,j)*b(i,k)*c(j,k) ] ] ]
This is very similar to what you wrote in your "not means the following
operation"
example, except that you left out (1) an initialization of d to zero before
the nested
loops and (2) the term d itself inside the summed expression. It also
reverses the
order of summation, but that doesn't matter as long as these are simple
numeric
values and not function calls with side effects.
d = 0 !Initialize accumulator variable
DO k = ...
DO j = ...
DO i = ...
d = a(i,j)*b(i,k)*c(j,k) + d ! "+d" needed to accumulate value
END DO
END DO
END DO
Please note that the summation convention specifically allows the expression
to
mean different things depending on whether the author specifies that certain
repeated indices are NOT to be summed. To implement this in a programming
language, it would be necessary to allow the programmer a way to prevent
unwanted summation. That's equivalent to NOT assuming the summation
convention and allowing the author to specify which indices ARE to be summed,
which is what old-fashioned Fortran allows.
I believe that implementing the summation convention would require overloading
the
"+" operator. That can be done in C++, but I don't know about Fortran 90/95.
-- Actually, it would require more than that because the question of which
indices
are summed depends on the entire expression rather than on any individual
term.
I'm not a computer scientist, but the phrase "context-dependent grammar"
springs
to mind, and I know that's a difficult thing that language implementers
generally
avoid.
As to your reference that Fortran is the queen of formula translation, please
note
that it is first of all an EFFICIENT language that maximizes how much
number-crunching can be done in a given amount of time and space. Languages
that are designed to cope with operator overloading and expressions with
multiple
possible meanings have to spend a significant amount of processing power doing
so, and raw number-cruncing power is decreased. Specific example: it might
very
well be that to support operator overloading it would be necessary to use a
pointer
to an index variable rather than the index variable itself. By itself, the
need to
dereference such pointers every time the expression is evaluated in a nested
loop
could hurt performance.
Richard Daehler-Wilking
[address removed]
cosine Cheng wrote:
> Hi:
>
> FORTRAN90 support the way to express/deal in matrix form,
>
> but how about in index form or tensor form.
>
> Here I mean the following operation:
>
> d = a(i,j)*b(i,k)*c(j,k) in index notation
>
> or d = ( a(1,j)*b(1,k)+a(2,j)*b(2,k)+a(3,j)*b(3,k) )*c(j,k)
>
> not means the following operation:
>
> DO k = ...
> DO j = ...
> DO i = ...
> d = a(i,j)*b(i,k)*c(j,k)
> END DO
> END DO
> END DO
>
> The two operation are NOT the same.
>
> Since FORTRAN is the queen of FORmula TRANsformation, how come she
>
> can not deal with tensor notation?
>
> Note that I'm using LF90, if LF95 or any other FORTRAN can deal
>
> w/ tensor notation directly, do let me know.
>
> Thank you
>
> by Cheng Cosine
> Feb/08/2k UT
>
> __________________________________________________ ____
> Get Your Private, Free Email at http://www.hotmail.com
>
> --------------------------------------------------------------------------
> To unsubscribe from Fortran Forum, send a message to [address removed]
> with the following command as the first and only line of the message body:
> unsubscribe fortran
> --------------------------------------------------------------------------
--------------------------------------------------------------------------
To unsubscribe from Fortran Forum, send a message to [address removed]
with the following command as the first and only line of the message body:
unsubscribe fortran
--------------------------------------------------------------------------