I am new to Fortran. I am trying to compute a simple function, but I'm having trouble with the exponent. If I run the following:
module procedures
contains
double precision function f(x)
f = x**sigma - alpha*x**sigma + 5
return
end function f
end module procedures
program main
use procedures
parameter (alpha = 5.0, sigma = 2)
write(6,"('f(3) = ',1f15.8)") f(3.0)
end program main
I get f(3) = 6, even though the answer should be -31. I feel like I'm missing something extremely basic about exponentiation.
Careful with your modules. You defined alpha and sigma in the main program but not in the module therefore, alpha and sigma are equal to zero in the module, then: x** 0 - 0*x** 0 + 5 = 6 for any value of x.
You do not need another module for this. Define the parameters inside the module above. Since the main program uses this module, the values are valid in the module, in the main program, and any other program segment that has 'use procedures' in it.
Related
I'm generally new to Fortran, and I have a project in which my professor wants the class to try to find pi. To do this he wants us to create our own arctan subroutine and use this specific equation: pi = 16*arctan(1/5) - 4*arctan(1/239).
Because the professor would not let me use the built in ATAN function, I made a subroutine that approximates it:
subroutine arctan(x,n,arc)
real*8::x, arc
integer::n, i
real*8::num, nm2
arc = 0.0
do i=1,n,4
num = i
nm2 = num+2
arc = arc+((x**num)/(num)) - (x**(nm2)/(nm2))
enddo
end subroutine arctan
This subroutine is based off of the Taylor series for arctan approximation, and seemed to work perfectly because I tested it by calling this.
real*8:: arc=0.0, approx
call arctan(1.d0,10000000,arc)
approx = arc*4
I called this from my main program which should return pi and I got
approx = 3.1415926335902506
which is close enough for me. The problem occurs when I try to do
pi = 16*arctan(1/5) - 4*arctan(1/239). I tried this:
real*8:: first, second
integer:: n=100
call arctan((1.d0/5.d0), n, arc)
first = 16*arc
call arctan((1.d0/239.d0), n, arc)
second = 4.d0*arc
approx = first - second
and somehow approx = 1.67363040082988898E-002, which is obviously not pi. arc resets with every call of the arctan subroutine so I know that isn't the problem. I think the problem is in how I'm calling the subroutine before I declare first and second, but I don't know what I could do to improve them.
What am I doing wrong?
EDIT:
I actually solved the problem and the actual problem was just fortran decided that it did not want to do approx = first - second
and was making it so that approx == second I have no idea why, but I solved the problem by replacing that statement with the following:
approx = (second-first)
approx = approx *(-1)
and as stupid as it looks, it works perfectly now, with a result of 3.1415926535897940!
The problem results from different types (single/double precsion) of the
variable arc in the call of arctan and the implementation of the subroutine. The iteration count of 10000... is way too much and may cause numerical problems, just 100 is more than enough (and much faster...).
Tip: always use implicit none for all progs and procedures. Here the compiler would have immediately told you that you forgot to declare arc...
Just make it double precision in the main program and you will get the desired answer.
I have been working with some old legacy code in Fortran used by a colleague. The actual code is proprietary, so the examples I use here are abbreviated compared to the code I'm working with.
Some of the procedures individually defined in *.f files included a file called variables.h:
Example contents of variables.h:
c VARIABLE DIMENSIONS FOR MODEL
c height_dim -- number of vertical (z) steps
c length_dim -- number of horizontal (x) steps
c width_dim -- number of horizontal (y) steps
INTEGER height_dim, length_dim, width_dim, nmodes, styleFlag
PARAMETER (height_dim=80, length_dim=50, width_dim=40)
PARAMETER (nmodes = 4,
$ styleFlag = 3)
I changed that to the following:
! VARIABLE DIMENSIONS FOR MODEL
! height_dim -- number of vertical (z) steps
! length_dim -- number of horizontal (x) steps
! width_dim -- number of horizontal (y) steps
INTEGER height_dim, length_dim, width_dim, nmodes, styleFlag
PARAMETER (height_dim=80, length_dim=50, width_dim=40)
PARAMETER (nmodes = 4, styleFlag = 3)
An example routine that uses these might be the following, called initial_conditions.f:
c This sets up the PDE's initial conditions
subroutine initial_conditions( temperature, density )
IMPLICIT NONE
INCLUDE 'variables.h'
real*8 temperature(height_dim,length_dim,width_dim)
real*8 density(height_dim)
temperature = 273.15D0
density = 1.0D0
return
end
I tried to compile a test routine written in F90 (or newer?) that included dimensions.h, but the compiler didn't like the fixed-form comments being included into the free-form *.f90 source file, so I changed all comments from c to !. Then I was able to compile my test program successfully. Let's call it test.f90:
program test
implicit none
include 'variables.h'
real*8, dimension(height_dim,length_dim,width_dim) :: vx, vy, vz
! <<Initialize data...>>
! << Output data...>>
end program test
Unfortunately, now the original code doesn't compile. It seems that code doesn't like commented lines to begin with ! (based on the fact that that was all I changed), but the actual errors it gives are the following:
variables.h(8): error #5082: Syntax error, found END-OF-STATEMENT when expecting one of: =
PARAMETER (nmodes = 4, styleFlag = 3)
------------------------------------------^
variables.h(5): error #6219: This variable, used in a specification expression, must be a dummy argument, a COMMON block object, or an object accessible through host or use association. [NMODES]
INTEGER height_dim, length_dim, width_dim, nmodes, styleFlag
---------------------------------------------^
What in the world is going on, and how can it be fixed?!
I imagine that comment styles are incompatible (free-form fortran thinks c is a variable, not a comment?), but I have no idea how it would produce these errors.
This question already has an answer here:
How to avoid declaring and setting the value of a variable in each subroutine?
(1 answer)
Closed 5 years ago.
I have a program that calls functions within the same program but I want to declare and initialize the variables on the top and access them at the end of the program.
!Declaration
INTEGER TOPCHORD,BOTCHORD, SUPPS, PURLINS;
!Initialization
! Define Layers for connecting lines
TOPCHORD = 32
BOTCHORD = 32
SUPPS = 36
PURLINS = 30
INTEGER FUNCTION IFLANGE1(IEND1,IEND2,ISUP)
IFLANGE1=TOPCHORD
SELECT CASE(IEND1)
CASE(2,4,6,8,9,10)
IFLANGE1=BOTCHORD
IF(ISUP.EQ.1)IFLANGE1=SUPPS
END SELECT
SELECT CASE(IEND2)
CASE(2,4,6,8,9,10)
IFLANGE1=BOTCHORD
IF(ISUP.EQ.1)IFLANGE1=SUPPS
END SELECT
RETURN
END
I get error that variable 'SUPPS' referenced but not set
You might want to have a look at the documentation - you're missing a couple of important statements. (Also try to always include implicit none -- this is very helpful for catching certain issues).
A slightly modified code that should compile is
!Declaration
INTEGER TOPCHORD,BOTCHORD, SUPPS, PURLINS;
!Initialization
! Define Layers for connecting lines
TOPCHORD = 32
BOTCHORD = 32
SUPPS = 36
PURLINS = 30
contains !Indicate that the program unit contains other procedures
INTEGER FUNCTION IFLANGE1(IEND1,IEND2,ISUP)
IFLANGE1=TOPCHORD
SELECT CASE(IEND1)
CASE(2,4,6,8,9,10)
IFLANGE1=BOTCHORD
IF(ISUP.EQ.1)IFLANGE1=SUPPS
END SELECT
SELECT CASE(IEND2)
CASE(2,4,6,8,9,10)
IFLANGE1=BOTCHORD
IF(ISUP.EQ.1)IFLANGE1=SUPPS
END SELECT
RETURN
END FUNCTION !End the function definition
END !This is a required end statement to say we've reached the end of the program
This isn't the nicest style etc. but has the minimum number of changes to compile.
For any slightly more complex program I would strongly recommend using modules for storing variables (and also procedures) that you want to access from different parts of the code.
I am trying to convert a Rainflow cycle counting algorithm which is in Fortran, which is a language I am not familiar with, into Matlab.
There is a ready made Rainflow I've downloaded for Matlab but that does not fit the requirements of my project so I'm trying to build one from scratch.
Here is the Fortran code:
INTEGER BUFFER (4096), INDEX, VALUE, RANGE, MEAN, X, Y
INDEX = 0
10 CONTINUE
call 'get next peak/valley', VALUE
INDEX = INDEX + 1
BUFFER (INDEX) = VALUE
20 CONTINUE
IF (INDEX.LT.3) THEN
not enough points to form a cycle
GOTO 10
ELSE
X = ABS (BUFFER(INDEX) - BUFFER(INDEX - 1))
Y = ABS (BUFFER(INDEX - 1) - BUFFER(INDEX - 2))
IF (X.GE.Y) THEN
c -- cycle has been closed
RANGE = Y
MEAN = (BUFFER(INDEX-1) + BUFFER(INDEX-2))/2
c -- remove the cycle
INDEX = INDEX - 2
BUFFER(INDEX) = BUFFER(INDEX+2)
c -- see if this value closes any more cycles
GOTO 20
ELSE
GOTO 10
END IF
END IF
I had downloaded f2matlab (a Fortran to Matlab converter) but it requires a Fortran compiler which I do not have.
The bits I don't really understand how I can convert are:
The call 'get next… line (is this an input()?)
The BUFFER(4096) etc (is this a bit large to be a matrix in matlab?)
The GOTO/CONTINUE structure.
What do they mean, in English (or Matlab)?
I have seen
How to translate fortran goto state to matlab
and
translating loop from Fortran to MATLAB
but they do not help me very much.
This
call 'get next peak/valley', VALUE
isn't (currently) syntactically valid Fortran and I'm not sure whether any compiler of yore would have understood it either. I guess that it means get a VALUE for use in the following bits of code.
INTEGER BUFFER (4096)
is a simple declaration that BUFFER is a vector of 4096 integers, nothing to scare Matlab in that volume of data.
Finally, GOTO is an unconditional jump and the number following it is the label of the line to jump to, so GOTO 10 means execute the line with label 10 next. It was fairly common in FORTRAN of the vintage you are showing us to jump to a CONTINUE statement which is, in this context, a no-operation, execution continues to the next line.
In another context, with DO loops CONTINUE would have marked the end of the block of code inside the scope of the loop and would have a subtly different effect.
The GNU C Library has the function drem (alias remainder).
How can I simulate this function just using the modules supported by Google App Engine Python 2.7 runtime?
From the GNU manual for drem:
These functions are like fmod except that they round the internal quotient n to the nearest integer instead of towards zero to an integer. For example, drem (6.5, 2.3) returns -0.4, which is 6.5 minus 6.9.
From the GNU manual for fmod:
These functions compute the remainder from the division of numerator by denominator. Specifically, the return value is numerator - n * denominator, where n is the quotient of numerator divided by denominator, rounded towards zero to an integer. Thus, fmod (6.5, 2.3) returns 1.9, which is 6.5 minus 4.6.
Reading the documentation the following Python code should work:
def drem(x, y):
n = round(x / y)
return x - n * y
However with Python, drem(1.0, 2.0) == -1.0 and with C drem(1.0, 2.0) == 1.0. Note Python returns negative one and C returns positive one. This is almost certainly an internal difference in rounding floats. As far as I can tell both functions perform the same otherwise where parameters 2 * x != y.
How can I make my Python drem function work the same as its C equivalent?
The key to solving this problem is to realise that the drem/remainder function specification requires the internal rounding calculation to round to half even.
Therefore we cannot use the built-in round function in Python 2.x as it rounds away from 0. However the round function in Python 3.x has changed to round to half even. So the following Python 3.x code will be equivalent to the GNU C Library drem function but will not work in Python 2.x:
def drem(x, y):
n = round(x / y)
return x - n * y
To achieve the same with Python 2.x we can use the decimal module and its remainder_near function:
import decimal
def drem(x, y):
xd = decimal.Decimal(x)
yd = decimal.Decimal(y)
return float(xd.remainder_near(yd))
EDIT: I just read your first comment and see that you cannot use the ctypes module. Anyways, I learned a lot today by trying to find an answer to your problem.
Considering that numpy.round() rounds values exactly halfway between rounded decimal values to the next even integer, using numpy is not a good solution.
Also, drem internally calls this MONSTER function, which should be hard to implement in Python.
Inspired by this article, I would recommend you to call the drem function from the math library directly. Something along these lines should do the trick:
from ctypes import CDLL
# Use the C math library directly from Python
# This works for Linux, but the version might differ for some systems
libm = CDLL('libm.so.6')
# For Windows, try this instead:
# from ctypes import cdll
# libm = cdll.libc
# Make sure the return value is handled as double instead of the default int
libm.drem.restype = c_double
# Make sure the arguments are double by putting them inside c_double()
# Call your function and have fun!
print libm.drem(c_double(1.0), c_double(2.0))