




Fortran Programming Language









c = inverse(sqrt(epsilon nought *mu nought))
This program is simply not going away:
!********************************************************
! APPLICATION OF THE FINITE DIFFERENCE METHOD
! This program involves the penetration of a lossless dielectric
SPHER
! The program provides in the maximum absolute value of
! Ey and Ez during the final halfwave of timestepping
! Assumption:
! +ydirected incident wave with components Ez and Hx.
! I,J,K,NN correspond to X,Y,Z, and Time.
! IMAX,JMAX,KMAX are the maximum values of x,y,z
! NNMAX is the total number of timesteps.
! NHW represents one halfwave cycle.
! MED is the number of different uniform media sections.
! JS is the jposition of the plane wave front.
!
! THIS PROGRAM WAS DEVELOPED BY V. BEMMEL [43]
! AND LATER IMPROVED BY D. TERRY
!*******************************************************
PARAMETER( IMAX=19, JMAX=39, KMAX=19)
PARAMETER( NMAX=2, NNMAX=500, NHW=40, MED=2, JS=3 )
PARAMETER( DELTA=3E3, CL=3.0E8, F=2.5E9 )
PARAMETER( PIE=3.141592654)
integer, parameter :: dp = kind(1.0d0)
! Define scatterer dimensions
PARAMETER( OI=19.5, OJ=20.0, OK=19.0, RADIUS=15.0)
DIMENSION EX(0:IMAX+1, 0:JMAX+1, 0:KMAX+1,
0:NMAX), &
& EY(0:IMAX+1, 0:JMAX+1, 0:KMAX+1,
0:NMAX), &
& EZ(0:IMAX+1, 0:JMAX+1, 0:KMAX+1,
0:NMAX), &
& HX(0:IMAX+1, 0:JMAX+1, 0:KMAX+1,
0:NMAX), &
& HY(0:IMAX+1, 0:JMAX+1, 0:KMAX+1,
0:NMAX), &
& HZ(0:IMAX+1, 0:JMAX+1, 0:KMAX+1,
0:NMAX), &
& EY1(0:JMAX+1), EZ1(0:JMAX
+1), &
& ER(MED), SIG(MED), CA(MED), CB(MED)
DIMENSION IXMED(0:IMAX+1, 0:JMAX+1, 0:KMAX+1)
DIMENSION IYMED(0:IMAX+1, 0:JMAX+1, 0:KMAX+1)
DIMENSION IZMED(0:IMAX+1, 0:JMAX+1, 0:KMAX+1)
! STORE CB(M)/RB HERE
DIMENSION CBMRB( 2 )
! CONSTITUTIVE PARAMETERS
DATA ER/1.0,4.0/
DATA SIG/0.1,0.0/
!
real(kind=dp) :: x
! Statement function to compute position w.r.t. center of the sphere
!
position(RI,RJ,RK)=SQRT((RIOI)**2+(RJOJ)**2+(RKOK)**2)
E0=(1E9)/(36*PIE)
U0=(1E7)*4*PIE
DT=DELTA/(2*CL)
R=DT/E0
RA=(DT**2)/(U0*E0*(DELTA**2))
RB=DT/(U0*DELTA)
TPIFDT = 2.0*PIE*F*DT
x = 0.0_dp
x = (E0*U0)**(.5)
write (*,*) x
!********************************************************
! EP # 1  COMPUTE MEDIA PARAMETERS
!********************************************************
DO 1 M=1,MED
CA(M)=1.0R*SIG(M)/ER(M)
CB(M)=RA/ER(M)
CBMRB(M) = CB(M)/RB
1 CONTINUE
!
! (i) CALCULATE THE REAL/ACTUAL GRID POINTS
!
! Initialize the media arrays.Index (M) determines which
! medium each point is actually located in and is used to
! index into arrays which determine the constitutive
! parameters of the medium.There are separate M determining
! arrays for EX, EY, and EZ. These arrays correlate the
! integer values of I,J,K to the actual position within
! the lattice. Computing these values now and storing them in these
! arrays as opposed to computing them each time they are
! needed saves a large amount of computation time.
!
DO 3 I=0, IMAX+1
DO 3 J=0, JMAX+1
DO 3 K=0, KMAX+1
IF(position(float(I)+0.5,float(J),float(K)).LE.RADIUS) then
IXMED( I, J, K ) = 2
else
IXMED( I, J, K ) = 1
endif
IF(position(float(I),float(J)+0.5,float(K)).LE.RADIUS) then
IYMED( I, J, K ) = 2
else
IYMED( I, J, K ) = 1
endif
IF(position(float(I),float(J),float(K)+0.5).LE.RADIUS) then
IZMED( I, J, K ) = 2
else
IZMED( I, J, K ) = 1
endif
3 CONTINUE
!*************************************************
! STEP # 2  INITIALIZE FIELD COMPONENTS
!*************************************************
! components for output
DO 4 J=0,JMAX+1
EY1(J)=0
EZ1(J)=0
4 END DO
DO 5 I=0,IMAX+1
DO 5 J=0,JMAX+1
DO 5 K=0,KMAX+1
DO 5 N = 0, NMAX
EX(I,J,K,N)=0
EY(I,J,K,N)=0
EZ(I,J,K,N)=0
HX(I,J,K,N)=0
HY(I,J,K,N)=0
HZ(I,J,K,N)=0
5 CONTINUE
print *, 'initialization complete'
!********************************************************
! STEP # 3  USE FD/TD ALGORITHM TO GENERATE
! FIELD COMPONENTS
!********************************************************
! SINCE ONLY FIELD COMPONENTS AT CURRENT TIME (t) AND PREVIOUS
! TWO TIME STEPS ( t1 AND t2) ARE REQUIRED FOR COMPUTATION,
! WE SAVE MEMORY SPACE BY USING THE FOLLOWING INDICES
! NCUR is index in for time t
! NPR1 is index in for t1
! NPR2 is index in for t2
!
NCUR = 2
NPR1 = 1
NPR2 = 0
! TIME LOOP
DO 15 NN = 1, NNMAX
IF (MOD( NN,10).EQ.0) THEN
! DISPLAY PROGRESS
print *,'NN=',NN
ENDIF
! Next time step  move indices up a notch.
NPR2 = NPR1
NPR1 = NCUR
NCUR = MOD( NCUR+1, 3)
! Z LOOP
DO 20 K=0,KMAX
! Y LOOP
DO 25 J=0,JMAX
! X LOOP
DO 30 I=0,IMAX
!
! (ii)APPLY SOFT LATTICE TRUNCATION CONDITIONS
!
!x=delta/2
IF(I.EQ.0) THEN
IF ((K.NE.KMAX).AND.(K.NE.0)) THEN
HY(0,J,K,NCUR) =
(HY(1,J,K1,NPR2) &
& + HY(1,J,K,NPR2)+HY(1,J,K+1,NPR2))/3
HZ(0,J,K,NCUR)=(HZ(1,J,K1,NPR2) &
& + HZ(1,J,K,NPR2)+HZ(1,J,K+1,NPR2))/3
else
IF (K.EQ.KMAX) THEN
HY(0,J,KMAX,NCUR) =
(HY(1,J,KMAX1,NPR2) &
& + HY(1,J,KMAX,NPR2))/2.
HZ(0,J,K,NCUR)=( HZ(1,J,K1,NPR2) &
& + HZ(1,J,K,NPR2) )/2
ELSE
HY(0,J,K,NCUR) =
( HY(1,J,K,NPR2) &
& + HY(1,J,K+1,NPR2))/2.
HZ(0,J,0,NPR2)=(HZ(1,J,
0,NPR2) &
& + HZ(1,J,1,NPR2))/2
ENDIF
ENDIF
ENDIF
!y=0
IF(J.EQ.0) THEN
EX(I,0,K,NCUR)=EX(I,1,K,NPR2)
EZ(I,0,K,NCUR)=EZ(I,1,K,NPR2)
ELSE
!y=ymax
IF(J.EQ.JMAX) THEN
EX(I,JMAX,K,NCUR)=EX(I,JMAX1,K,NPR2)
EZ(I,JMAX,K,NCUR)=EZ(I,JMAX1,K,NPR2)
ENDIF
ENDIF
!z=0
IF(K.EQ.0) THEN
IF ((I.NE.0).AND.(I.NE.IMAX)) THEN
EX(I,J,0,NCUR) = (EX(I1,J,
1,NPR2) &
& + EX(I,J,1,NPR2)+EX(I+1,J,1,NPR2))/3
EY(I,J,0,NCUR) = (EY(I1,J,
1,NPR2) &
& + EY(I,J,1,NPR2)+EY(I+1,J,1,NPR2))/3
ELSE
IF(I.EQ.0) THEN
EX(0,J,0,NCUR)=(EX(0,J,1,NPR2)+EX(1,J,1,NPR2))/2
EY(I,J,0,NCUR)=(EY(I,J,1,NPR2)+EY(I+1,J,1,NPR2))/2
ELSE
EX(I,J,0,NCUR)=(EX(I1,J,1,NPR2)+EX(I,J,1,NPR2))/2
EY(I,J,0,NCUR)=(EY(I1,J,1,NPR2)+EY(I,J,1,NPR2))/2
ENDIF
ENDIF
ENDIF
!
! (iii) APPLY FD/TD ALGORITHM
!
!a. HX generation:
HX(I,J,K,NCUR)=HX(I,J,K,NPR1)+RB*(EY(I,J,K
+1,NPR1) &
&  EY(I,J,K,NPR1)+EZ(I,J,K,NPR1)EZ(I,J+1,K,NPR1))
!b. HY generation:
HY(I,J,K,NCUR)=HY(I,J,K,NPR1)+RB*(EZ(I
+1,J,K,NPR1) &
&  EZ(I,J,K,NPR1)+EX(I,J,K,NPR1)EX(I,J,K+1,NPR1))
!c. HZ generation:
HZ(I,J,K,NCUR)=HZ(I,J,K,NPR1)+RB*(EX(I,J
+1,K,NPR1) &
&  EX(I,J,K,NPR1)+EY(I,J,K,NPR1)EY(I+1,J,K,NPR1))
!k=kmax ! SYMMETRY
IF(K.EQ.KMAX) THEN
HX(I,J,KMAX,NCUR)=HX(I,J,KMAX1,NCUR)
HY(I,J,KMAX,NCUR)=HY(I,J,KMAX1,NCUR)
ENDIF
!d. EX generation:
IF((J.NE.0).AND.(J.NE.JMAX).AND.(K.NE.0)) THEN
M = IXMED( I, J, K )
EX(I,J,K,NCUR) = CA(M)*EX(I,J,K,NPR1) +
CBMRB(M)* &
& (HZ(I,J,K,NCUR)HZ(I,J1,K,NCUR)
+HY(I,J,K1,NCUR) &
& HY(I,J,K,NCUR))
ENDIF
!e. EY generation:
IF(K.NE.0) THEN
M = IYMED( I, J, K )
EY(I,J,K,NCUR)=CA(M)*EY(I,J,K,NPR1) +
CBMRB(M)* &
& (HX(I,J,K,NCUR)HX(I,J,K1,NCUR)+HZ(I1,J,K,NCUR) &
& HZ(I,J,K,NCUR))
! was unpaired right brace^^
ENDIF
!f. EZ generation:
IF ((J.NE.0).AND.(J.NE.JMAX)) THEN
M = IZMED( I, J, K )
! sig(ext)=0 for Ez only from Taflove[14]
IF(M.EQ.1) THEN
CAM=1.0
ELSE
CAM=CA(M)
ENDIF
EZ(I,J,K,NCUR)=CAM*EZ(I,J,K,NPR1)+CBMRB(M)* &
& (HY(I,J,K,NCUR)HY(I1,J,K,NCUR)
+HX(I,J1,K,NCUR) &
& HX(I,J,K,NCUR))
!
! (iv) APPLY THE PLANEWAVE SOURCE
!
IF(J.EQ.JS) THEN
EZ(I,JS,K,NCUR) = EZ(I,JS,K,NCUR)+SIN( TPIFDT*NN )
ENDIF
ENDIF
!i=imax+1/2 ! SYMMETRY
IF(I.EQ.IMAX) THEN
EY(IMAX+1,J,K,NCUR)=EY(IMAX,J,K,NCUR)
EZ(IMAX+1,J,K,NCUR)=EZ(IMAX,J,K,NCUR)
ENDIF
!k=kmax
IF(K.EQ.KMAX) THEN
EX(I,J,KMAX+1,NCUR)=EX(I,J,KMAX1,NCUR)
EY(I,J,KMAX+1,NCUR)=EY(I,J,KMAX1,NCUR)
ENDIF
! I LOOP
30 END DO
!********************************************************
! STEP # 4  RETAIN THE MAXIMUM ABSOLUTE VALUES DURING
! THE LAST HALFWAVE
!********************************************************
IF ( (K.EQ.KMAX).AND.(NN.GT.(NNMAXNHW)) ) THEN
TEMP = ABS( EY(IMAX,J,KMAX1,NCUR) )
IF (TEMP .GT. EY1(J) ) THEN
EY1(J) = TEMP
ENDIF
TEMP = ABS( EZ(IMAX,J,KMAX,NCUR) )
IF (TEMP .GT. EZ1(J) ) THEN
EZ1(J) = TEMP
ENDIF
ENDIF
! J LOOP
25 END DO
! K LOOP
20 END DO ...
read more »
Wade Ward <zaxf@gmail.com> 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.

Richard Maine  Good judgement comes from experience;
email: last name at domain . net  experience comes from bad judgement.
domain: summertriangle   Mark Twain
On May 15, 6:53 pm, nos@see.signature (Richard Maine) wrote:
> Wade Ward <zaxf@gmail.com> 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
Wade Ward <zaxf@gmail.com> wrote:
> Statement functions? That's a new one. I'll have a look at MR&C.
More like an old one. If you are looking in MR&C, be sure to check their
section on old features; it is probably buried in there.

Richard Maine  Good judgement comes from experience;
email: last name at domain . net  experience comes from bad judgement.
domain: summertriangle   Mark Twain
On May 17, 8:39 pm, Wade Ward <zaxf@gmail.com> wrote:
> On May 15, 6:53 pm, nos@see.signature (Richard Maine) wrote:
> > Wade Ward <zaxf@gmail.com> 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
Perhaps it might help to look at the text where these examples may
have originated. Based on the exercise numbers of two programs cited
and chapter titles (finite difference and method of moments) along
with Appendix D (it covers solution of simultaneous equations), I
suspect these may have come from "Numerical Techniques in
Electromagnetics", Matthew N. O. Sadiku, 2000, CRC Press, ISBN
0849313953. [Thanks to Google book search.]
This still leaves unresolved this program's problems with outof
bounds references to arrays. In addition, there is quite a bit of
archaic code.
In the end, I believe that you need some knowledge of the problem
domain to get a handle on this program. (Sorry, not my field at
all. :))
 elliot
"Wade Ward" <zaxf@gmail.com> wrote in message
news:1179448796.877248.278660@u30g2000hsc.googlegroups.com...
> 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.
> 
Indeed. It is defined to be 2.99792458e8 m/s exactly.
Regards,
Mike Metcalf
On May 17, 8:39 pm, Wade Ward <zaxf@gmail.com> wrote:
> On May 15, 6:53 pm, nos@see.signature (Richard Maine) wrote:
> > Wade Ward <zaxf@gmail.com> 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
Indeed, by doing some algebra, some relevant constants take on
interesting values:
[let c = Cl = speed of light]
Eo Uo = 1 / c^2
c Uo = 1 / c Eo
Dt / delta = 1 / 2c
R = delta c Uo /2
RA/RB = c Uo /2
R = 180 pi / 1000
RA = 1/4
RA/RB = 60 pi
Constants used later in the program take on the values:
RB = 1 / (240 pi)
CA = [ 1  (180 pi)/10000 , 1  0 ]
CBMRB = [ 60 pi, 15 pi ]
TPIFDT = (2 pi)/80
Adding a "guard" plane for I=1 in HY and HZ and setting this to zero
makes very little difference in the leading digits of the output. This
may not be a legitimate way to deal with the out of bounds program but
it is tempting to think that it does not perturb the solution very
much.
 email: epc8 at juno dot com
On May 18, 7:09 am, e p chandler <e@juno.com> wrote:
> On May 17, 8:39 pm, Wade Ward <zaxf@gmail.com> wrote:
> > On May 15, 6:53 pm, nos@see.signature (Richard Maine) wrote:
> > > Wade Ward <zaxf@gmail.com> 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
> Perhaps it might help to look at the text where these examples may
> have originated. Based on the exercise numbers of two programs cited
> and chapter titles (finite difference and method of moments) along
> with Appendix D (it covers solution of simultaneous equations), I
> suspect these may have come from "Numerical Techniques in
> Electromagnetics", Matthew N. O. Sadiku, 2000, CRC Press, ISBN
> 0849313953. [Thanks to Google book search.]
> This still leaves unresolved this program's problems with outof
> bounds references to arrays. In addition, there is quite a bit of
> archaic code.
> In the end, I believe that you need some knowledge of the problem
> domain to get a handle on this program. (Sorry, not my field at
> all. :))
>  elliot Hide quoted text 
>
program elliot6
PARAMETER( PIE=3.141592654)
integer, parameter :: dp = kind(1.0d0)
!contains real function position
! Define scatterer dimensions
PARAMETER( OI=19.5, OJ=20.0, OK=19.0, RADIUS=15.0)
real(kind=dp) :: x
! Statement function to compute position w.r.t. center of the sphere
position(RI,RJ,RK)=SQRT((RIOI)**2+(RJOJ)**2+(RKOK)**2)
! another statement function
asf(arg1) = SQRT(arg1OI)**2
E0=(1E9)/(36*PIE)
U0=(1E7)*4*PIE
C =(E0*U0)**(.5)
x = 0.0_dp
x = (E0*U0)**(.5)
write (*,*) x, C, E0, U0
i = 4
j = 5
k = 6
IF(position(float(I)+0.5,float(J),float(K)).LE.20) then
write (*,*) "tja"
else
write (*,*) "hja"
endif
!$$$$$$ IF( asf(float(I)).GE.20) then
!$$$$$$ write (*,*) "tja"
!$$$$$$ else
!$$$$$$ write (*,*) "hja"
!$$$$$$ endif
end program elliot6
I intend to post this using the google portal and intend it as a
response to Richard Maine and Mike Metcalf as well. Google doesn't
let a person see a tree of messages that one sees in a newsbrowser, so
it's harder to tailor responses and keep track of subthreads.
I found the option in silverfrost to "Integrate with SDBG," yet don't
find a difference in the debugger as I experience it. I have a
variable list but no idea what type of function position or asf is. I
can't step into them. So I'm a little stuck guessing how to replace
them with an explicit function.
I tried to make a onedimensional analog of position with asf. What I
have compiles but causes my computer to beep on execution instead of
giving the other branch of the ifthenelse control. The variables
that serve as the arguments for the statement function remain
undefined for the duration of the program, that is, RI,RJ,RK and
arg1. Should I expect otherwise?
I've always lobbied for the existence of Cstyle comments in fortran,
but found that my IDE had a way to comment out (and in) highlighted
blocks, as seen in the final if statement. Very handy stuff. Right
next to those buttons are ones that will decrease (increase) the
spacing for an entire block.
With MM posting a value for c at tens of thousands of meters per
second less than 3 x 10**8, this forces either
C =(E0*U0)**(.5) to be an approximation or
E0=(1E9)/(36*PIE)
U0=(1E7)*4*PIE are approximations. While I took undergrad
electromagnetics, we never calculated epsilon nought or mu nought.
These were constants in Maxwell's equations that no one argued about.
My guess is that to solve for them, you would need to make a contrived
choice of parameters and gaussian surfaces that isolates them during
the integration. The formula for the inverse of the square root of
their product equalling the speed of light I got from a book I was
reading a few years back by Bryan Green. It may have been _The
Elegant Universe_. Since the formula was in the footnotes, which was
reserved for more technical treatment, I have to think it was right.
This inclines me to the view that the transmittivity and permittivity
in free space are off. I've got a guess here though. In the fourth
of Maxwell's equation there was a term that Dr. Clerk Maxwell added to
make the theory robust. I think this term was ignored when E0 and U0
were calculated. As I recall, it involved the product of E0 and U0
and would have been orders of magnitude smaller, so ignoring it for
the sake of getting a quick and dirty result is understandable.
Anyways, I'll see if a library in Western Michigan has the book you
mention.

Wade Ward
In article <TAi3i.18$ix.2@trndny01>,
Michael Metcalf <michaelmetc@compuserve.com> wrote:
>"Wade Ward" <zaxf@gmail.com> wrote in message
>> The speed of light is as much of a constant as a person can imagine.
>Indeed. It is defined to be 2.99792458e8 m/s exactly.
You won't get that many figures with most processors. If you need
to do physical theory with high accuracy 2.99792458d8 is safer.
 John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
email john.har@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
In article <1179703684.134338.96@n15g2000prd.googlegroups.com>,
Wade Ward <zaxf@gmail.com> wrote:
>With MM posting a value for c at tens of thousands of meters per
>second less than 3 x 10**8, this forces either
>C =(E0*U0)**(.5) to be an approximation or
>E0=(1E9)/(36*PIE)
>U0=(1E7)*4*PIE are approximations.
Not quite. You don't say what units you are using, but in SI units
both C and U0 above are both exact, E0 is an approximation.
The SI definitions give the units of U0 as N/A**2 = kg m s**(2) A**(2),
C as m/s, E0 as F/m = kg**(1) m**(3) s**4 A**2.
(If you invent suitable derived types you can even make Fortran do
your units as well as your numbers)
See, for example, http://www.physicstoday.org/guide/fundcon.html
 John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
email john.har@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
John Harper wrote:
> In article <1179703684.134338.96@n15g2000prd.googlegroups.com>,
> Wade Ward <zaxf@gmail.com> wrote:
>> With MM posting a value for c at tens of thousands of meters per
>> second less than 3 x 10**8, this forces either
>> C =(E0*U0)**(.5) to be an approximation or
>> E0=(1E9)/(36*PIE)
>> U0=(1E7)*4*PIE are approximations.
> Not quite. You don't say what units you are using, but in SI units
> both C and U0 above are both exact, E0 is an approximation.
> The SI definitions give the units of U0 as N/A**2 = kg m s**(2) A**(2),
> C as m/s, E0 as F/m = kg**(1) m**(3) s**4 A**2.
> (If you invent suitable derived types you can even make Fortran do
> your units as well as your numbers)
> See, for example, http://www.physicstoday.org/guide/fundcon.html
Or for a selectable list (with equations where appropriate):
http://physics.nist.gov/cuu/Constants/index.html
cheers,
paulv

Paul van Delst Ride lots.
CIMSS @ NOAA/NCEP/EMC Eddy Merckx
On May 20, 9:32 pm, har@mcs.vuw.ac.nz (John Harper) wrote:
> In article <1179703684.134338.96@n15g2000prd.googlegroups.com>,
> Wade Ward <zaxf@gmail.com> wrote:
> >With MM posting a value for c at tens of thousands of meters per
> >second less than 3 x 10**8, this forces either
> >C =(E0*U0)**(.5) to be an approximation or
> >E0=(1E9)/(36*PIE)
> >U0=(1E7)*4*PIE are approximations.
> Not quite. You don't say what units you are using, but in SI units
> both C and U0 above are both exact, E0 is an approximation.
> The SI definitions give the units of U0 as N/A**2 = kg m s**(2) A**(2),
> C as m/s, E0 as F/m = kg**(1) m**(3) s**4 A**2.
> (If you invent suitable derived types you can even make Fortran do
> your units as well as your numbers)
> See, for example,http://www.physicstoday.org/guide/fundcon.html
I'm able for the first time in a while to surf the net and see at the
above link that c is defined as a rational slightly less than 3 x
10**8 and U0 is indeed as above. Wouldn't that force E0 to be
irrational as well?

Wade Ward
Wade Ward wrote:
> On May 20, 9:32 pm, har@mcs.vuw.ac.nz (John Harper) wrote:
>> In article <1179703684.134338.96@n15g2000prd.googlegroups.com>,
>> Wade Ward <zaxf@gmail.com> wrote:
>>> With MM posting a value for c at tens of thousands of meters per
>>> second less than 3 x 10**8, this forces either
>>> C =(E0*U0)**(.5) to be an approximation or
>>> E0=(1E9)/(36*PIE)
>>> U0=(1E7)*4*PIE are approximations.
>> Not quite. You don't say what units you are using, but in SI units
>> both C and U0 above are both exact, E0 is an approximation.
>> The SI definitions give the units of U0 as N/A**2 = kg m s**(2) A**(2),
>> C as m/s, E0 as F/m = kg**(1) m**(3) s**4 A**2.
>> (If you invent suitable derived types you can even make Fortran do
>> your units as well as your numbers)
>> See, for example,http://www.physicstoday.org/guide/fundcon.html
> I'm able for the first time in a while to surf the net and see at the
> above link that c is defined as a rational slightly less than 3 x
> 10**8 and U0 is indeed as above. Wouldn't that force E0 to be
> irrational as well?
Why is the irrationality a problem? They're still constants:
c = 299792458 m.s^1 (exact)
u0 = 4pi x 10^7 N.A^2 (exact)
e0 = 1/(u0.c^2) F.m^1 (exact)
where the "exact" refers to the uncertainty of the value (in a vacuum). Since they are all
defined quantities, not measured, their knowledge is considered "exact".
cheers,
paulv

Paul van Delst Ride lots.
CIMSS @ NOAA/NCEP/EMC Eddy Merckx
In article <f2sr4o$p8@news.nems.noaa.gov>,
Paul van Delst <Paul.vanDe@noaa.gov> wrote:
>Wade Ward wrote:
>> On May 20, 9:32 pm, har@mcs.vuw.ac.nz (John Harper) wrote:
>>> In article <1179703684.134338.96@n15g2000prd.googlegroups.com>,
>>> Wade Ward <zaxf@gmail.com> wrote:
>>>> C =(E0*U0)**(.5) to be an approximation or
>>>> E0=(1E9)/(36*PIE)
>>>> U0=(1E7)*4*PIE are approximations.
>>> Not quite. You don't say what units you are using, but in SI units
>>> both C and U0 above are both exact, E0 is an approximation.
>>> See, for example,http://www.physicstoday.org/guide/fundcon.html
>> I'm able for the first time in a while to surf the net and see at the
>> above link that c is defined as a rational slightly less than 3 x
>> 10**8 and U0 is indeed as above. Wouldn't that force E0 to be
>> irrational as well?
>Why is the irrationality a problem? They're still constants:
>c = 299792458 m.s^1 (exact)
>u0 = 4pi x 10^7 N.A^2 (exact)
>e0 = 1/(u0.c^2) F.m^1 (exact)
>where the "exact" refers to the uncertainty of the value (in a vacuum).
>Since they are all defined quantities, not measured, their knowledge
>is considered "exact".
I have another problem with Wade's terminology. c is a velocity, which
happens to be a rational (for that matter an integer) number of metres
per second, which Paul gave. c is NOT a rational number. Rational
numbers are dimensionless. Remember the spacecraft that crashed on Mars
because someone was careless with units...
 John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
email john.har@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
John Harper wrote:
(snip)
> I have another problem with Wade's terminology. c is a velocity, which
> happens to be a rational (for that matter an integer) number of metres
> per second, which Paul gave. c is NOT a rational number. Rational
> numbers are dimensionless. Remember the spacecraft that crashed on Mars
> because someone was careless with units...
I would agree with you, except that this is the Fortran newsgroup
where variables do not have units. The quantity stored in the
variable is the desired quantity divided by the appropriate units.
It seems to me that physicists and related scientists tend to
consider variables as holding a quantity with units, while
engineers tend to consider the units as part of the equation.
For the latter case, you might see in a book:
F(Newtons) = m (kilograms) * a (meters/second**2).
 glen
> I'm able for the first time in a while to surf the net and see at the
> above link that c is defined as a rational slightly less than 3 x
> 10**8 and U0 is indeed as above.
IIRC, u0 is just from geometry  the surface area of a unit sphere in some
suitable space. As to c, among it, the meter and the second, you can define a
value for two of them, and the third results from a measurement based on those
standard values. It used to be the case that the meter and the second were
given definitions, and you needed to measure c. But the definition of the
meter is quite inexact: Being based on the wavelength of some line in a
spectrum, its relative error was fairly high, compared to the second (I
remember three or four orders of magnitude). So what was done was to retain
the definition of the second, _define_ c to be a certain value (derived from
the best _measured_ value of c before this decision), and to derive the value
of one meter from those two. The meter is now defined to the same accuracy as
the second, and c is now an exact fundamental constant (as it should be, IMO).
Jan
On May 21, 7:49 pm, glen herrmannsfeldt <g@ugcs.caltech.edu> wrote:
> John Harper wrote:
> (snip)
> > I have another problem with Wade's terminology. c is a velocity, which
> > happens to be a rational (for that matter an integer) number of metres
> > per second, which Paul gave. c is NOT a rational number. Rational
> > numbers are dimensionless. Remember the spacecraft that crashed on Mars
> > because someone was careless with units...
> I would agree with you, except that this is the Fortran newsgroup
> where variables do not have units. The quantity stored in the
> variable is the desired quantity divided by the appropriate units.
> It seems to me that physicists and related scientists tend to
> consider variables as holding a quantity with units, while
> engineers tend to consider the units as part of the equation.
> For the latter case, you might see in a book:
> F(Newtons) = m (kilograms) * a (meters/second**2).
program elliot7
implicit none
integer, parameter :: dp = kind(1.0d0)
real(kind=dp):: x,U0,E0,PIE, c, e0_calc
PIE = 4* atan(1.0)
U0=(1E7_dp)*4.0 * PIE
E0= 8.854187E12_dp
c = 2.99792458E8_dp
x = (E0*U0)**(.5)
write (*,'(f30.20)') x, E0, U0, PIE
write (*, *) "going the other way"
e0_calc = 1/ (U0 * c**2.0)
write (*,'(f35.25)') c, U0, PIE, e0_calc
write (*,*) "12345678.0000000000012345678911234"
write (*,*) "12345678.1234567891123456789212345"
! end source begin output
end program elliot7
299792467.67059397698000000000
0.00000000000885418700
0.00000125663709640503
3.14159274101257324230
going the other way
299792458.0000000000000000000000000
0.0000012566370964050291944
3.1415927410125732423000000
0.0000000000088541875712302
12345678.0000000000012345678911234
12345678.1234567891123456789212345
This is the latest version of this program. I tried to get as much
width as I could for e0_calc. When I took E0 from a website that gave
it to 7 figures it gives the speed of light off by 9 m/s, which is
faster than Ben Johnson. I'd be curious to know how much accuracy I
got.
One question: If I have a variable declared as dp and assign it a
value like (1E7)*4.0 , am I welladvised to append _dp on the things
on the RHS?

Wade Ward
On May 21, 3:15 pm, Paul van Delst <Paul.vanDe@noaa.gov> wrote:
> Wade Ward wrote:
> > On May 20, 9:32 pm, har@mcs.vuw.ac.nz (John Harper) wrote:
> >> In article <1179703684.134338.96@n15g2000prd.googlegroups.com>,
> >> Wade Ward <zaxf@gmail.com> wrote:
> >>> With MM posting a value for c at tens of thousands of meters per
> >>> second less than 3 x 10**8, this forces either
> >>> C =(E0*U0)**(.5) to be an approximation or
> >>> E0=(1E9)/(36*PIE)
> >>> U0=(1E7)*4*PIE are approximations.
> >> Not quite. You don't say what units you are using, but in SI units
> >> both C and U0 above are both exact, E0 is an approximation.
> >> The SI definitions give the units of U0 as N/A**2 = kg m s**(2) A**(2),
> >> C as m/s, E0 as F/m = kg**(1) m**(3) s**4 A**2.
> >> (If you invent suitable derived types you can even make Fortran do
> >> your units as well as your numbers)
> >> See, for example,http://www.physicstoday.org/guide/fundcon.html
> > I'm able for the first time in a while to surf the net and see at the
> > above link that c is defined as a rational slightly less than 3 x
> > 10**8 and U0 is indeed as above. Wouldn't that force E0 to be
> > irrational as well?
> Why is the irrationality a problem? They're still constants:
> c = 299792458 m.s^1 (exact)
> u0 = 4pi x 10^7 N.A^2 (exact)
> e0 = 1/(u0.c^2) F.m^1 (exact)
> where the "exact" refers to the uncertainty of the value (in a vacuum). Since they are all
> defined quantities, not measured, their knowledge is considered "exact".
The irrationality of mu nought and epsilon nought isn't a problem, it
simply is. I disagree with John that a number loses rationality or
lack thereof if it has units.
I tried to find a treatment of how u0 is derived. (I miss Halliday
and Resnick.) It doesn't help that it's pronuounced mu nought and
looks like u zero. I think Jan has the right idea, thinking that a
person looks at the unit sphere somehow, but I'm way to rusty to work
it up from first principles.

Wade Ward
Wade Ward wrote:
(snip)
> I tried to find a treatment of how u0 is derived. (I miss Halliday
> and Resnick.) It doesn't help that it's pronuounced mu nought and
> looks like u zero. I think Jan has the right idea, thinking that a
> person looks at the unit sphere somehow, but I'm way to rusty to work
> it up from first principles.
Electromagnetic units are derived either through the magnetic
effect (force per unit length between two wires carrying
a specified current a specified distance apart) or electrostatic
(force between two charge distributions a specified distance apart).
MKSA (the A being Ampere) is magnetic based, such that mu nought
is based on geometry and to make the units have a reasonable size.
That is, the Ampere is based on the force between wires with
a specific geometry which sets the value of mu nought in the
appropriate equations.
Epsilon nought is then determined through Maxwell's equations
to satisfy the previously indicated relation.
The more commonly used CGS units are based on setting the
electrical charge unit to specify the force between two charges,
which again results in 4pi in the equations. Another set of
units, HeavisideLorentz units, are similar but with the 4pi
moved around such that it doesn't appear in most equations.
But yes, the 4pi comes from a surface integral of the electric
field divided by radius squared, and the area of a sphere
being 4 pi r**2.
 glen
In article <1179875920.294189.65@w5g2000hsg.googlegroups.com>,
Wade Ward <zaxf@gmail.com> wrote:
>integer, parameter :: dp = kind(1.0d0)
>real(kind=dp):: x,U0,E0,PIE, c, e0_calc
>PIE = 4* atan(1.0)
>U0=(1E7_dp)*4.0 * PIE
>E0= 8.854187E12_dp
>c = 2.99792458E8_dp
and then lots of calculations showing not very many correct figures.
With only 7 significant figures quoted in E0 you can't hope for better
in anything depending on it, and atan(1.0) is the singleprecision
version of atan. So I'd leave c as is, but change the statements
evaluating PIE, U0 and E0 to
PIE = 4.0_dp*atan(1.0_dp)
U0 = 4e7_dp * PIE
E0 = 1/ (U0*c**2) ! because **2 is better for integer powers
>One question: If I have a variable declared as dp and assign it a
>value like (1E7)*4.0 , am I welladvised to append _dp on the things
>on the RHS?
Yes. Two reasons.
1. You sometimes lose accuracy if you don't, so it's safer to get
into the habit of avoiding singleprecision real (or complex) numbers
in doubleprecision expressions.
2. If you think that single precision might be enough or that quadruple
precision is needed (and available), you have to change only one
statement in the entire program: the definition of dp. That's also a
reason to avoid writing PIE = 4d0*atan(1d0) even though it's briefer.
 John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
email john.har@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
> This is the latest version of this program. I tried to get as much
> width as I could for e0_calc. When I took E0 from a website that gave
> it to 7 figures it gives the speed of light off by 9 m/s, which is
> faster than Ben Johnson. I'd be curious to know how much accuracy I
> got.
Ben Johnson et al. are definitely faster than 9 m/s  they do the 100 m in
less than ten seconds!
As u0 and c are now exact, so should e0 in the same system of units. And the
NIST web site says so. It just doesn't give enough significant figures for
your use.
Jan
On May 23, 2:09 am, Jan Vorbrggen <jvorbrueg@notmediasec.de>
wrote:
> > This is the latest version of this program. I tried to get as much
> > width as I could for e0_calc. When I took E0 from a website that gave
> > it to 7 figures it gives the speed of light off by 9 m/s, which is
> > faster than Ben Johnson. I'd be curious to know how much accuracy I
> > got.
> Ben Johnson et al. are definitely faster than 9 m/s  they do the 100 m in
> less than ten seconds!
I realized that right after I posted. I named the only people on the
planet who _can_ exceed 9 m/s without machines or free fall or
catastrophic consequences.

Wade Ward
Wade Ward <zaxf@gmail.com> wrote:
> On May 23, 2:09 am, Jan Vorbrggen <jvorbrueg@notmediasec.de>
> wrote:
> > > it gives the speed of light off by 9 m/s, which is
> > > faster than Ben Johnson.
> > Ben Johnson et al. are definitely faster than 9 m/s  they do the 100 m in
> > less than ten seconds!
> I realized that right after I posted. I named the only people on the
> planet who _can_ exceed 9 m/s without machines or free fall or
> catastrophic consequences.
Well, it all depends on your frame of reference. Since the speed of
light was mentioned, seems like relativity ought to be important. I
figure I'm doing something on the order of 300 m/s sitting here at my
desk rotating around the center of the earth. Or quite a bit more around
the Sun or the center of the galaxy. It's enough to make me giddy, or is
that just from my age? :)

Richard Maine  Good judgement comes from experience;
email: last name at domain . net  experience comes from bad judgement.
domain: summertriangle   Mark Twain
On May 22, 10:51 pm, har@mcs.vuw.ac.nz (John Harper) wrote:
> and then lots of calculations showing not very many correct figures.
> With only 7 significant figures quoted in E0 you can't hope for better
> in anything depending on it, and atan(1.0) is the singleprecision
> version of atan. So I'd leave c as is, but change the statements
> evaluating PIE, U0 and E0 to
> PIE = 4.0_dp*atan(1.0_dp)
> U0 = 4e7_dp * PIE
> E0 = 1/ (U0*c**2) ! because **2 is better for integer powers
Does an integer exponent make for a mixedmode calculation?
> >One question: If I have a variable declared as dp and assign it a
> >value like (1E7)*4.0 , am I welladvised to append _dp on the things
> >on the RHS?
> Yes. Two reasons.
> 1. You sometimes lose accuracy if you don't, so it's safer to get
> into the habit of avoiding singleprecision real (or complex) numbers
> in doubleprecision expressions.
> 2. If you think that single precision might be enough or that quadruple
> precision is needed (and available), you have to change only one
> statement in the entire program: the definition of dp. That's also a
> reason to avoid writing PIE = 4d0*atan(1d0) even though it's briefer.
program elliot8
implicit none
integer, parameter :: dp = kind(1.0d0)
real(kind=dp):: U0,E0,PIE, c, e0_calc
PIE = 4.0_dp* atan(1.0_dp)
U0=(1E7_dp)*4.0_dp * PIE
E0= 8.854187E12_dp
c = 2.99792458E8_dp
e0_calc = 1.0_dp/ (U0 * c**2.0_dp)
write (*,'(f35.25)') c, U0, PIE,E0, e0_calc
write (*,*) "12345678.0000000000012345678911234"
write (*,*) "12345678.1234567891123456789212345"
end program elliot8
!end source begin output
299792458.0000000000000000000000000
0.0000012566370614359172885
3.1415926535897931160000000
0.0000000000088541870000000
0.0000000000088541878176204
12345678.0000000000012345678911234
12345678.1234567891123456789212345
I think this version gives as much width on epsilon nought as double
precision can do. I can't believe I got stung with a singleprecision
pi. It may have been an overreaction, but I went through and
appended _dp to every constant. It isn't my idea of pretty, but
wouldn't making everything dp be the best way to avoid having
something implicitly single precision? In particular, it looks odd as
an exponent.

Wade Ward
On Jun 4, 9:34 pm, nos@see.signature (Richard Maine) wrote:
> Wade Ward <zaxf@gmail.com> wrote:
> > On May 23, 2:09 am, Jan Vorbrggen <jvorbrueg@notmediasec.de>
> > wrote:
> > > > it gives the speed of light off by 9 m/s, which is
> > > > faster than Ben Johnson.
> > > Ben Johnson et al. are definitely faster than 9 m/s  they do the 100 m in
> > > less than ten seconds!
> > I realized that right after I posted. I named the only people on the
> > planet who _can_ exceed 9 m/s without machines or free fall or
> > catastrophic consequences.
> Well, it all depends on your frame of reference. Since the speed of
> light was mentioned, seems like relativity ought to be important. I
> figure I'm doing something on the order of 300 m/s sitting here at my
> desk rotating around the center of the earth. Or quite a bit more around
> the Sun or the center of the galaxy. It's enough to make me giddy, or is
> that just from my age? :)
If we can get creative with frame of reference on running the 100
meter dash, you could go the Xeno route and simply stay stationary for
the duration of the race. Then define your origin on the sternum of
the fella who crossed the finish line first. You will have gone as
far and as fast as anyone, and the athletes who ran aren't likely to
have a background in special relativity to make the same arguments.
You wouldn't have to worry about a false start. It might work. Then
again, it might not.

Wade Ward





