(Intrinsic) equation parsing

1

I would love some sort of equation parser (one that’s intrinsic) that’s able to read a string and convert it into an equation
For example: We should be able to run a Python program that uses SymPy and then pipe the output which is a SymPy equation that gets converted to a string to a Fortran program.

3 Likes
2

You can do exactly that with SymPy already. Simply use any of the SymPy’s parsers to parse a string (in many formats, such as basic Python style equation, or Latex, Mathematica, etc.) into SymPy and then use one of the code generators, such as Fortran, to print it as Fortran code.

2 Likes
3

No, I mean like passing that output that SymPy generates to the Fortran program, and the Fortran program being able to read it. Convert it from a string or etc.

Example:

$ python equationmaker.py > ./fort_eq_user

or something like that…

4

I see – you want Fortran code to read an equation at runtime?

Something like a symbolic engine in Fortran? We have one here: GitHub - symengine/symengine.f90: Fortran wrappers of SymEngine, it uses symengine (which is solid), but the Fortran wrapper is preliminary / pre-alpha.

1 Like
5

In the past I have used with good profit FortranParser, probably there are other new, similar options around nowadays. In this scenario, I think that the main aspect to check would be ensuring that the output string from SymPy is compatible with the input format of the library.

1 Like
6

Yes this is what I wanted thank you. :+1:

1 Like
7

I wanna try this option as well

8

@Aurelius_Nero the Fortran wrapper to symengine would need more work, but if you are interested, we can collaborate on that.

1 Like
9

I would love to help, however the max I can do right now is test code. I have another project I have to finish urgently.

10

from

There are at least these

  • fortran_function_parser: function parser module by Jacob Williams is intended for applications where a set of mathematical fortran-style expressions is specified at runtime and is then evaluated for a large number of variable values. This is done by compiling the set of function strings into byte code, which is interpreted efficiently for the various variable values.

  • Fortran Function Parser (ffp): evaluates a string containing a mathematical expression that can be formed by numbers, brackets, functions, and variables, by Wilton P. Silva and Ivomar B. Soares

  • Fortran Equation Parser (feqparse): equation parser Fortran class that is used to interpret and evaluate functions provided as strings, by Joe Schoonover

  • M_calculator: parse Fortran-like double precision scalar expressions, by urbanjost

  • M_matrix: Fortran callable version of old matlab-like interface

There used to be several very complete byte code engines that were very fast that I cannot seem to find so far. Hope they are not
lost to history, like the old F77 interpreters that seem to have vanished.

@Beliavsky; if you add this one to the list, maybe these kind of string parsers are of sufficient number to get their own subsection?

2 Likes
11

They do exist, but none of them are intrinsic. I think in order to prevent them being lost to time, we need to make them intrinsic packages in Fortran.

12

Perhaps gathering them all into a fpm package for people to test with and deriving something to submit to stdlib would get this one out of the “reinvented wheel” category. I have wanted NAMELIST to be able to take equations for ages; and I dislike that the many configuration file “standards” (INI, JSON, TOML, XHTML, …) do not permit conditionals and expressions directly either. Since Fortran is not required to be interpreted and does not expose its variables (well, NAMELIST almost does) supporting anything but the intrinsic types would get complicated. Of course implementing NAMELIST was probably hard enough that anyone supporting it is probably already groaning at the thought of adding expressions but it already supports user-defined types and arrays; which is quite powerful.

1 Like
13

I also think adding expressions to namelist input, and also possibly list-directed input in a similar way, would be a good idea. The current semantics for * and / would need to be overridden somehow, maybe with a flag in the read statement itself (e.g. parse=.true.). Then once it is available in the i/o system, it could be accessed within a fortran program with internal i/o.

What kind of expressions should be allowed? Should they include some or all fortran intrinsic functions? How about functions from the program itself?

All of the functionality to do this is already in the language. If a compiler can parse and evaluate an expression at compile time, then that same code could evaluate an expression at run time.

1 Like
14
1 Like
15

I created an Expression Parsers category, listing the projects above and FortranParser.

2 Likes
16

Nice. Not on github, but there are others such as String functions which has “evaluate”.

1 Like