Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Format numbering

JohnNichols
Valued Contributor III
2,588 Views

I was laughing at myself this morning,  I sometimes hate how you use a nice format numbering system, 100, 110, 120 etc.. , and then you come back and add one, say 115, and it breaks your nice system.  

It would be nice, if IF renumbered your formats for you. 

Of course, that is bizarre request. It clearly shows a brain that has been too long coding Fortran. 

I realize humour is not allowed on this board, we are serious people.  

<I have edited this thrice to correct the English>. 

0 Kudos
23 Replies
JohnNichols
Valued Contributor III
229 Views

@mecej4 

RE: 

See the second page of EWD1009 for a discussion from 1987.

----------------------------------------------------------------------------------------------------

I laughed till I cried.  A perfect letter, thank you for showing it to me.  

 

JMN

0 Kudos
JohnNichols
Valued Contributor III
296 Views

Your winning advantage is placing these parameters into a module that is reusable.  

Such as the method mecej4 used in the Magni program.  

  Module Base

    INTEGER, PARAMETER :: dp = selected_real_kind(15, 307)

    INTEGER, PARAMETER :: sw = 2, srA = 20, st = 11, sa = 3, sm = 4, sc = 12, sRT = 25
    Integer, parameter :: slog = 9, sCAD = 21, sINI = 13, sWULF = 18
    INTEGER, parameter :: sXOUT = 21, SYOUT = 22, SZOUT = 23
    Integer, parameter :: array_size = 18000
    integer, parameter :: nt = 2000
    integer, parameter :: mt = 2000        !   Number of members
    integer, parameter :: mn = 2
    integer, parameter :: ml = 3
    integer, parameter :: mn_12 = 12
    integer, parameter :: mn_4 = 4
    integer, parameter :: nFA = 8
    integer :: readFlag = 0
    integer, parameter :: MSize = 1023
    integer, parameter :: CSize = 512
    integer, parameter :: XSize = 1000000

    REAL (KIND=dp) :: g = 9.806, pi = 3.14159265D0

    REAL (KIND=dp) :: delta = 0.000000000001d0
    REAL (KIND=dp) :: h = 0.0005d0
    REAL (KIND=dp) :: ADELTA = 0.005d0
    REAL (KIND=dp) :: alpha = 0.16666d0
    REAL (KIND=dp) :: beta = 0.25d0
    REAL (KIND=dp) :: gamma = 0.5d0
    REAL (KIND=dp) :: ONE = 1.0d0
    REAL (KIND=dp) :: SMALLMASS = 0.001d0
    REAL (KIND=dp) :: TWO = 2.0d0
    REAL (KIND=dp) :: TEN = 10.0d0
    REAL (KIND=dp) :: ZERO = 0.0d0
    REAL (KIND=dp) :: DAMPRATIO = 100.0d0
    REAL (KIND=dp) :: RATIO1 = 0.45d0
    REAL (KIND=dp) :: MULTIPLER = 0.4d0

    REAL (KIND=dp) :: RATIO2 = 0.25d0
    REAL (KIND=dp) :: SuggestG = 0.0d0
0 Kudos
JohnNichols
Valued Contributor III
233 Views

I fully agree, relying on short circuiting is a very bad idea.  It is common in some language definitions. I would never rely on it, but it is interesting that this code has lasted since 1966 with changes, the last major changes appear to be about 2000.  

It had to work, in the other compilers, because the second element of the if was not evaluated or if it was, then it took whatever was in the "apparent location" and did not flag an error. Otherwise someone would have fixed it. 

I am not a compiler writer so I have no idea.  And you are correct, it is the compiled version of the code, but the compiler has an algorithm to handle the if statement. I can think of several ways that the error would be ignored, given the limitations of older compilers.  The fact that Intel picked it up I thought was worth noting.  

>> A Fortran program that was developed and debugged only on processors that employed short circuit evaluation is at risk of failing when used on a system where short circuit evaluation is not assured. <<

This appears to me to be what has happened here.  But I am constrained as I have only ever used MS,  Visual and IFORT Fortran. I would not expect it to work, but it was interesting to find it in code that has been through some "good" coding places.  I use those compilers because they are reliable and the ones I have access to. 

 

Of course I cringed a lot, when I looked at the old Hagar code.  This uses Hermite polynomials to solve curve grading., from 1988.

But at the time, curve grading was done by hand and it was trial and error. It might take a draughts person, a full day to solve one problem, which is expensive.  The problem is a point data for the length of curve with a height and slope known at each end.  By hand you use two parabola's and a HP41C to solve the grading problem.  I have checked hundreds of them, it is not fun. 

So Hagar, named for the comic, solved the problems with a Hermite polynomial fitted.  It has to be smooth and differentiable which means it solves the grading problem perfectly, and Fortran is perfect for generating DXF files, so you can draw it for them.  

C      ***********************************************************
C
C      THIS PROGRAM SOLVES HERMITE POLYNOMIALS OF DIFFERENT DEGREE
C
C      This progamme developed by John Nichols in September 1987
C      This version gives standard road curve format except
C      for the natural surface.  This will be implemented shortly.
C
C      Last update : 5 APRIL 1988 TO CHANGE LAYER DRAW TO
C
C      ***********************************************************
C
       PROGRAM HAGAR
C
C      ***********************************************************



       CALL TITLE

       CALL KERB

       END

C      ****************************************************************
C
       SUBROUTINE KERB
C
C      ****************************************************************

       COMMON /GROUPM/ SLOPE(2,100),WIDTH(2,100),NKERB

       READ(1,*)NKERB

       IF (NKERB .LT. 4 ) THEN
	   CALL KERB1
       ENDIF

       END

C      ****************************************************************
C
       SUBROUTINE KERB1
C
C      ****************************************************************

       COMMON /GROUPJ/ BL(75),NL,CBLT(75)
       COMMON /GROUPL/ AKERB(3,100),NKERB1
       COMMON /GROUPM/ SLOPE(2,100),WIDTH(2,100),NKERB
       COMMON /GROUPN/ RATE(2,100),BL3(3,100)


       DO 10 I=1,NKERB

	NKERB1=I

	CALL INPUT1

	CALL CURVE

	CALL ACAD

	 DO 20 J=1,NL
	  BL3(I,J)=BL(J)
20	 CONTINUE

10	CONTINUE

	IF (NKERB .GT. 1) THEN
	 CALL SLOPES
	ENDIF


       END

 

Any Fortran not matter how interesting is always going to be better than any other language. I was reading at the weekend in a CompSci mag about a Federal Employee bemoaning that the problem was so intense they would have to resort to the stone age Fortran.  I smiled and thought any Fortran even MS 3.03 is better than anything else.  Again personal opinion.   

We are forced by circumstance to use other languages, LISP in AutoCAD etc..  

But it is just fun. 

 

0 Kudos
Reply