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

  • Context: Fortran 
  • Thread starter Thread starter ngendler
  • Start date Start date
  • Tags Tags
    Error Fortran Runtime
Click For Summary

Discussion Overview

The discussion revolves around troubleshooting runtime errors in a Fortran 95 program designed to integrate user-defined functions. Participants explore the challenges of reading and parsing user input for mathematical expressions, particularly in the context of probability density functions.

Discussion Character

  • Technical explanation
  • Debate/contested
  • Conceptual clarification

Main Points Raised

  • One participant describes an error encountered when trying to read a user-defined function input, specifically a mathematical expression like "x**2".
  • Another participant suggests that the approach of reading a function directly as a real number is incorrect and proposes the need for parsing the input string to execute the integration.
  • Some participants argue that Fortran is not well-suited for developing parsers, suggesting that writing a parser is a complex task that may exceed the scope of the current program.
  • There is a discussion about whether the program should expect user input directly or read from an external file, with differing opinions on the expected functionality.
  • Several participants emphasize the need for a restricted set of functions to simplify the parsing task, while others argue that the complexity of the input could require a more sophisticated parsing solution.
  • One participant highlights the importance of handling various mathematical symbols and functions, such as exponential and square root, in the parsing process.
  • There is a contention regarding the clarity of the original question posed by the OP, with some participants feeling that assumptions about the input requirements may lead to miscommunication.

Areas of Agreement / Disagreement

Participants express differing views on the feasibility of implementing a parser in Fortran and the expected input format for the program. There is no consensus on the best approach to take for integrating user-defined functions, and the discussion remains unresolved.

Contextual Notes

Participants point out limitations in the current understanding of the input requirements and the complexity of the parsing task. The discussion highlights the need for clarity regarding the expected format of user input and the capabilities of the Fortran programming language in handling such tasks.

ngendler
Messages
20
Reaction score
0
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!
 
Technology news on Phys.org
A)
Code:
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.
 
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.
 
@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.
 
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.
 
ngendler said:
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.
 
Solkar said:
A)
Code:
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.
 
SteamKing said:
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.
 
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'.)
 
  • #10
Solkar said:
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.
 
  • #11
For dealing with prob. densities the program requests here
Code:
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.
 
  • #12
Borek said:
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".
 
  • #13
Solkar said:
For dealing with prob. densities the program requests here
Code:
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.
 
  • #14
D H said:
Why must all that be handled by the parser?
Because that's the normal distribution,

but even
D H said:
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.
 

Similar threads

  • · Replies 5 ·
Replies
5
Views
5K
  • · Replies 11 ·
Replies
11
Views
2K
  • · Replies 2 ·
Replies
2
Views
8K
  • · Replies 4 ·
Replies
4
Views
3K
  • · Replies 4 ·
Replies
4
Views
28K
  • · Replies 2 ·
Replies
2
Views
9K
  • · Replies 3 ·
Replies
3
Views
2K
  • · Replies 2 ·
Replies
2
Views
3K
  • · Replies 3 ·
Replies
3
Views
2K
Replies
12
Views
9K