Re: c = inverse(sqrt(epsilon nought *mu nought))

On May 15, 6:53 pm, nos...@xxxxxxxxxxxxx (Richard Maine) wrote:
Wade Ward <zaxf...@xxxxxxxxx> wrote:
x = 0.0_dp
...
I added the above, but not without compiler complaint with respect to
*where* the statements go. When I put them before:
position(RI,RJ,RK)=....
, it creates the following error:
: error 381 - POSITION is not an array.
When I place it right after that block, it compiles fine. What gives?

Well, the compiler is right. Position isn't an array. It is intended to
be a statement function, as the comment above it notes.

Statement functions have loist of quirks, which is why many people,
myself included, don't recommend using them in new code. I won't even
try to list all the quirks. It would take way too long (and I'd miss a
bunch of them unless I spent a few hours checking first).

Statement functions are syntactically very easy to confuse with
assignment statements. One result of that is that the compiler can get
confused also. If you have something that isn't a valid statement
function, you can get an error message from the compiler trying to
interpret it as an assignment. That's what happened here. The compiler
guessed that this might be intended as an assignment to an element of an
array named position, but there is no such array declared, so you get an
error message.

It isn't a valid statement function when you put the x=0.0_dp before it
because x=0.0_dp is an executable statement. Statement functions must be
in the specification part - i.e. before any executable statements.

What puzzles me is why you even have x in this code. It seems to have
nothing to do with the rest of the code; nothing ever references it.
Since it doesn't have anything to do with the rest of the code, it is a
bit hard to suggest sensibly what to do with it.
Statement functions? That's a new one. I'll have a look at MR&C.

x was set to the LHS of statement that involved U0 and E0. Since it
was buried in 6k of stuff that I didn't know how to trim out, it's
understandable that a person would miss the statement, which was:
x = (E0*U0)**(-.5)
EO was 10**-7 * 4pi and UO was 10**-9/36 pi . In the product, the
pi's cancel leaving the inverse square root of (10**-16 * 1/9). Both
are perfect squares, ergo
x= 1/(10**-8 * 1/3) which leaves x at 3 x 10**8. The speed of light
is as much of a constant as a person can imagine.
--
Wade Ward

.

Relevant Pages

  • Re: c = inverse(sqrt(epsilon nought *mu nought))
    ... Well, the compiler is right. ... Position isn't an array. ... Statement functions have loist of quirks, which is why many people, ... interpret it as an assignment. ...
    (comp.lang.fortran)
  • Re: c = inverse(sqrt(epsilon nought *mu nought))
    ... error 381 - POSITION is not an array. ... One result of that is that the compiler can get ... interpret it as an assignment. ... Statement functions must be ...
    (comp.lang.fortran)
  • Re: Overloading OPERATOR(+): my usage causing memory leaks.
    ... Imemory leaks when apply it to array arguments. ... I'd guess it to be a compiler bug, and I can even roughly guess where. ... assignment, but it seems a good candidate for something some compilers ... where a and b are derived types with allocatable components, the compiler should allocate ...
    (comp.lang.fortran)
  • Re: c = inverse(sqrt(epsilon nought *mu nought))
    ... error 381 - POSITION is not an array. ... One result of that is that the compiler can get ... interpret it as an assignment. ... Statement functions must be ...
    (comp.lang.fortran)
  • Re: gfortran problem
    ... descriptor for the lhs array has to be touched to get the array's ... Maybe in many cases the compiler ... for a reallocating assignment, or maybe, in the spirit of pointer ...
    (comp.lang.fortran)