RunFormula: math expression parser and evaluator

[stormray]

Hello!

I would like to announce you RunFormula, my math expression parser and scripting engine for FreePascal and Lazarus.

Key features:

Supported
    integers in decimal, hexadecimal and binary formats;
    floating-point numbers in decimal and scientific notation;
    complex numbers and operations on them;
    intervals and operations on them;
    strings and ASCII characters;

Arithmetic and logical operations: + - * / or and xor not shl (<<) shr (>>) mod ( div == <> < <= >= > & (string concatenation) ** (integer exponentiation).
Variables and runtime initialization of variables via external callback function.
A set of built-in functions and the ability to register and use additional user-defined functions.
Control flow functions: if() repeat() exit() result() continue() break()
Ability to use inline function definitions directly within the formula (subroutines).
Support for the define directive.
Compiling the source formula into bytecode for multiple execution.
Minimal dependencies (only SysUtils in the base configuration).

Source code, Demo project, Help, Examples on GitHub:

https://github.com/runnfla/RunFormula

Any feedback are appreciated.

[Handoko]

Hello stormray,
Welcome to the forum.

Nice, I like. I may need it someday, bookmarked.
Thank you for sharing it.

[stormray]

Version 0.0 is released. Added experimental support for physical dimensions, including unit consistency checks, automatic result dimensioning and automatic conversion between unit systems.

[LeP]

I just want to make a note: when generating commits, give them a meaningful name that helps understand the story (not a generic UPD)

[valdir.marcos]

Hello!

I would like to announce you RunFormula, my math expression parser and scripting engine for FreePascal and Lazarus.

Key features:

Supported
    integers in decimal, hexadecimal and binary formats;
    floating-point numbers in decimal and scientific notation;
    complex numbers and operations on them;
    intervals and operations on them;
    strings and ASCII characters;

Arithmetic and logical operations: + - * / or and xor not shl (<<) shr (>>) mod ( div == <> < <= >= > & (string concatenation) ** (integer exponentiation).
Variables and runtime initialization of variables via external callback function.
A set of built-in functions and the ability to register and use additional user-defined functions.
Control flow functions: if() repeat() exit() result() continue() break()
Ability to use inline function definitions directly within the formula (subroutines).
Support for the define directive.
Compiling the source formula into bytecode for multiple execution.
Minimal dependencies (only SysUtils in the base configuration).

Source code, Demo project, Help, Examples on GitHub:

https://github.com/runnfla/RunFormula

Any feedback are appreciated.

Version 0.0 is released. Added experimental support for physical dimensions, including unit consistency checks, automatic result dimensioning and automatic conversion between unit systems.

Welcome to the forum.

Interesting. Thanks for sharing.

[stormray]

GaleFuncs - extension for LibreOffice Calc and MS Excel based on the RunFormula scripting engine.

https://github.com/runnfla/GaleFuncs
https://extensions.libreoffice.org/en/extensions/show/99599

You can now add meters to seconds directly within Calc cells 

[CM630]

I tried the demo (RFDemo.lpi).

1. 1,23+4,56   resulted in ... 56 

I could be 42 or something more common.
2. 5/0 resulted in a crash.

[stormray]

Hi CM630, thank you for your interest in RunFormula.

1. 1,23+4,56   resulted in ... 56 

The result 56 is correct. You used a comma as a decimal separator, but RunFormula uses a dot. If you type 1.23+4.56 you will get 5.79. But due to regional settings, the result might be displayed as 5,79. This will be fixed soon.

Commas are used to separate expressions. So, 1,23+4,56 means: evaluate 1, then evaluate 23+4, and then evaluate 56. The system returns the last result, which is 56.

Upd: To resolve this issue, I plan to disallow digits immediately following a comma. Writing 1,23+4,56 will trigger an error. The correct format will be 1, 23+4, 56

2. 5/0 resulted in a crash.

You need to turn off debugging in Project Options. Please uncheck everything on the Compiler Options -> Debugging tab, and then you'll see a proper error message.

[CM630]

Hi CM630, thank you for your interest in RunFormula.

1. 1,23+4,56   resulted in ... 56 

The result 56 is correct. You used a comma as a decimal separator, but RunFormula uses a dot. If you type 1.23+4.56 you will get 5.79. But due to regional settings, the result might be displayed as 5,79. This will be fixed soon.

Commas are used to separate expressions. So, 1,23+4,56 means: evaluate 1, then evaluate 23+4, and then evaluate 56. The system returns the last result, which is 56.

Upd: To resolve this issue, I plan to disallow digits immediately following a comma. Writing 1,23+4,56 will trigger an error. The correct format will be 1, 23+4, 56

Hardcoding the decimal delimiter and the parameter separator will result in nothing good.
I would not like dots as decimal separators in my output, no matter what my regional settings are: they will look pretty odd in an ISO/IEC compliant report and will be perfectly wrong in a ГОСТ document.
On the other hands for India I would like dots, probably.

[Jorg3000]

Upd: To resolve this issue, I plan to disallow digits immediately following a comma. Writing 1,23+4,56 will trigger an error. The correct format will be 1, 23+4, 56

Hi!
I would like to suggest that the function RunFlaParse() gets an optional parameter that allows you to specify how points/commas should be interpreted, for example: has decimal point, or decimal comma, or use default setting, or use the operating system setting.

The advantage would be that you could define individually for each call exactly what this string contains.
Then you could pass either user input or program-defined strings, without having to change any global settings for this call.
Jörg

[stormray]

Hi Jörg,

I would like to suggest that the function RunFlaParse() gets an optional parameter that allows you to specify how points/commas should be interpreted, for example: has decimal point, or decimal comma, or use default setting

I'm afraid that this will just cause confusion, and the scripts will become non-portable across different systems.

Yes, it’s a dilemma: whether to use the comma as a decimal mark or as an expression/variable separator. By choosing the dot as the decimal separator and the comma for expressions, I was following the convention of most programming languages, as well as the mathematical practice of separating expressions with commas. I’ll think about this issue some more. Alternatively, both the dot and the comma could be allowed as decimal separators, while restricting the expression separator strictly to the semicolon. However, that would make the syntax feel unconventional—for example, a function call would look like func(X; 1; 2), an array element like A[10; 20], and a complex number like (1;2).

[CM630]

When the regional decimal delimiter is a dot, Excel separates the parameters with a comma.
But when the decimal seprator is a comma, they are separarted with a ;
One never knows what data (file) will come as an input, so autoswicthing only will cause troubles.

... However, that would make the syntax feel unconventional—for example, a function call would look like func(X; 1; 2), an array element like A[10; 20], and a complex number like (1;2).

The syntax might feel unconvetional to programmers, but software is also often used by humans.


Btw:
procedure Calculate(a : Double; b : Double);
but
Calculate (5,6);

[stormray]

When the regional decimal delimiter is a dot, Excel separates the parameters with a comma.
But when the decimal seprator is a comma, they are separarted with a ;

You are absolutely right about how Excel handles this. However, this automatic switching often causes major problems when users with different regional settings collaborate. I want to avoid this completely in RunFormula scripts. A script shouldn't depend on a user's locale.
For now, I'm leaning toward keeping things as they are: a dot as the strict decimal separator, and a comma for expressions. In the future, I plan to add dedicated functions for input and output formatting to accommodate different regional views.