Integrating User-Defined Functions in Fortran 95: Troubleshooting Runtime Errors

[ngendler]

Hi! I'm trying to write a function that will integrate a user given function. I am having trouble with reading the function. Here is a section of my code:

function f(x)
implicit none
real :: x,f,p
print *,'Type a probability density function'
read *, p
!It doesn't like line 34...
f = p
end function f

It compiles fine, but then when I run the program and enter a function (say, x**2), it gives me the error:

Fortran runtime error: Bad real number in item 1 of list input

Help, please!

 

[Solkar]

A)

read *, p
f = p

is the wrong approach for achieving
B)

I'm trying to write a function that will integrate a user given function

To achieve B you need to parse the user provided string and either
1) compile that parsed expression during run-time and execute the code in your integration function
2) or sample it by other means over a given Riemann-partition

Unfortunately, writing parsers is generally one of the most challenging programming tasks; and Fortran is not exactly well suited for parser development; it's a language for numerical programming and that's it.

Fortunately in your case, almost every parsing solution (e.g. lex/yacc resp. flex/bison) has a calculator as standard example, so you can take such a sample and refine that according to your needs.

 

[Borek]

Are you sure your program is expected to parse the function entered manually by the user on the prompt, and not given in an external file compiled together with your program? The latter is a rather standard assignment on many programming courses.

 

[ngendler]

@Borek, yes I am sure. I want the user to be able to say "x**2" and have the program read it and integrate it.

 

[SteamKing]

There are a number of FORTRAN issues here:
1. The function f will be expected to return a numerical value. If you want f to return a CHARACTER string, then f must be declared accordingly.
2. Ditto for reading in the variable 'p'. How is the program supposed to know that 'p' should be reading a CHARACTER string rather than a floating point or integer value? This is why you get a run-time error when you type in the string 'x**2'.
3. FORTRAN is very poor at deciphering user intent and then self-writing code to fill in the blanks. Most programming languages are.
4. The response by Solkar is very apt. In order for a user-input function to be integrated, the character string must first be parsed so that the program can decipher the input string. The logic for doing this can be implemented with FORTRAN code, but that will require much more programming than you have shown so far. Instead of using a FUNCTION to do this, a SUBROUTINE would be more appropriate.

 

[Solkar]

I want the user to be able to say "x**2" and have the program read it and integrate it.

And how to achieve that was what I explained.

 

[SteamKing]

A)

read *, p
f = p

is the wrong approach for achieving
B)

To achieve B you need to parse the user provided string and either
1) compile that parsed expression during run-time and execute the code in your integration function
2) or sample it by other means over a given Riemann-partition

Unfortunately, writing parsers is generally one of the most challenging programming tasks; and Fortran is not exactly well suited for parser development; it's a language for numerical programming and that's it.

Fortunately in your case, almost every parsing solution (e.g. lex/yacc resp. flex/bison) has a calculator as standard example, so you can take such a sample and refine that according to your needs.

I don't think you will need an elaborate parser for the OP's purpose; he is not trying to have a general purpose parser which would be needed for implementing a programming language. The OP, I think, could use a restricted set of functions, like polynomials, basic trig functions, hyperbolics, etc., to which the user would be constrained.

FORTRAN possesses basic string manipulation intrinsic functions, so it is possible to search for substrings, manipulate characters, etc. The idea that FORTRAN is restricted to numerical programming solely is an old wives' tale, and has been since at least FORTRAN77.

I think the OP assumed that because the mathematical term 'x^2' is written as 'x**2' in FORTRAN code, his program would read that string and interpret it to mean x*x, not realizing that some extra steps were required to accomplish his desired goal.

 

[Solkar]

have a general purpose parser which would be needed for implementing a programming language.

We do neither discuss "general purpose parsers" nor "implementing a programming language"

The complexity of the parsing task at hand is above the complexity of implementing a calculator, which a the standard example for parser generators and lexers; that's what we discuss.

So lex/yacc (flex/bison) or a similar toolset it is; Fortran having some string processing feats does not imply it'd be suited for any up-from-scratch parser development.

 

[SteamKing]

Obviously, we are talking past one another.
In a FORTRAN program like the OP envisioned, the user could type in 'SIN(X)' in response to the question 'Which Function do you wish to integrate?'

The program could then scan the input string to determine if the substring 'SIN" was present. The various functions which are in the permitted list of functions, e.g. 'SIN', 'COS', 'TAN', etc., could be programmed already in several separate FUNCTION statements. Based on its analysis of the input string, the program then branches to calculating using the proper function.

Tools like lex/yacc work in a similar fashion. Based on the description of the programming language, they analyze the source file to strip out white space, and figure out what are keywords, data, variable names, commands, etc. so that the code generator can do its thing.

IMO, the OP is trying to write a simple calculation tool, something which doesn't quite have the capability of a computer-aided algebra system.

All I am trying to say to the OP is that his program can be written if the list of functions is kept restricted in some fashion, otherwise, it becomes more the development of a parser than the development of a calculation routine. (What folks in other times and other places called 'Mission Creep'.)

 

[Borek]

We do neither discuss "general purpose parsers" nor "implementing a programming language"

Actually we have no idea what we are discussing, as OP didn't tell what exact kind of input is the program expected to work with. So everyone answers not the OP question, but their own guess of what the original question is.

 

[Solkar]

For dealing with prob. densities the program requests here

print *,'Type a probability density function'

the program must at least be capable to deal with
$$\frac{1}{\sqrt{2\pi\sigma^2}}\exp\left(-\frac{\left(x-\mu\right)^2}{2\sigma^2}\right)$$

given in at least one (whichever) ascii or unicode repr; and even just that consists of e.g.

unary "-", binary "-", "/", "*", "(", ")", "exp ", "sqrt", "²", "π"
and actual floats provided for σ and μ

And all that must be handled by the parser.

 

[Solkar]

Actually we have no idea what we are discussing

The snippet the OP provided together with his explanations was sufficient for determining the problem domain, and it is obvious that we're neither discussing a "general purpose parser" nor a parser for a "programming language".

 

[D H]

For dealing with prob. densities the program requests here

print *,'Type a probability density function'

the program must at least be capable to deal with
$$\frac{1}{\sqrt{2\pi\sigma^2}}\exp\left(-\frac{\left(x-\mu\right)^2}{2\sigma^2}\right)$$

given in at least one (whichever) ascii or unicode repr; and even just that consists of e.g.

unary "-", binary "-", "/", "*", "(", ")", "exp ", "sqrt", "²", "π"
and actual floats provided for σ and μ

And all that must be handled by the parser.

Why must all that be handled by the parser? That the program must at least be capable of handling an expression of that level of complexity is your requirement. It might well be that what is wanted is a simple parser that can handle polynomials and nothing else. We don't know.

The OP has yet to come back and say what his/her requirements are, and why they are this way. We don't know if this is an undergrad assignment, something that needs to be done for work or a grad school project, or a self-imposed problem. We don't know is the operative phrase.

 

[Solkar]

Why must all that be handled by the parser?

Because that's the normal distribution,

but even

It might well be that what is wanted is a simple parser that can handle polynomials

just handling polynomials would imply having to deal with

unary "-", binary "+", "*", "x^i"

operator associativity and precedence rules.