In line with the recent improvements to the Programmable filters and python editor [1], we are thinking of improving the calculator and python calculator formulaes managements.
One could think to rely on the python editor in the same way as the programmable filters, however, this has a few issues:
Both calculator supports only one liner, not in line with a text editor
Calculator formulaes are not python, which would be confusing to edit in a python editor.
So here is what I have in mind:
Make the formula line edit as wide as possible for both calculator
Make the formula line edit multiline with automatic wrapping so that long one liner can be seen whole
Add a setting to store and manage named python and calculator one liner. Think “Tools->Formulae Manager”.
Let the user access these formulae in a searchable combo box in the [python] calculator
Let the user add the current formula in a new saved formula
Let the user open the Formulae Manager from the [python] calculator
This sounds great. I suggest not using the term formulae as the definition does not exactly fit: “A statement, especially an equation, of a fact, rule, principle, or other logical relation.” I would suggest using something like “calculation” or “expression”.
Another related suggestion is that we have a pull-down menu for the Python calculator that lists the available functions. Or some similar way for people to discover what is possible.
I suggest not using the term formulae as the definition does not exactly fit: “A statement, especially an equation, of a fact, rule, principle, or other logical relation.” I would suggest using something like “calculation” or “expression”.
Good point
Another related suggestion is that we have a pull-down menu for the Python calculator that lists the available functions. Or some similar way for people to discover what is possible.
OK I am confused When we say Formulae, are we talking about user level expressions or built-in functions? For example, is it gradient(foo) / mag(gradient(foo)) or is it just gradient()? I assumed it was the first. I was suggesting a drop-down menu for the second also.
When we say Formulae, are we talking about user level expressions or built-in functions? For example, is it gradient(foo) / mag(gradient(foo)) or is it just gradient()? I assumed it was the first. I was suggesting a drop-down menu for the second also.
User defined expression. gradient(foo) / mag(gradient(foo))
The calculator already have built-in methods that the user can click on.
The python calculator do not have that but rely on the python/numpy knowledge of the user.
We do not plan to improve this in this context.
The python calculator do not have that but rely on the python/numpy knowledge of the user.
The problem is that we have a bunch of VTK-level functions available to the calculator that are not listed anywhere (I think). For example, who knows that we have functions like max_per_block()? I always have to look it up in the algorithms.py module… I totally get that it is out of scope for this work but I wanted to put it in writing so that we are aware that this is an issue.
All I can say is ‘’‘Thank you!’’’. This will be a most welcome feature. It really helps with quick checks involving (somewhat) longer expressions involving vector algebra/calculus.
This is still work in progress, but feedbacks are welcom !
Specially on the integration in the properties panel. We added three buttons around the main text input: reuse expression, store expression and open manager.
The preview suggest them under the text line, so the expression list will not pop over the current text, but not sure if it is a good UX.
My first remark
It would be nice to be able to give a name to an expression/formula because very quickly the readability becomes difficult because of the complex (name with description ?).
My second remark
Some same complex calculations can apply to different fields of values. This is the case, among other things, for complex unit changes. It would be nice to be able to define an expression/formula with one or more value field names passed as parameters.
For realize the idea:
name: toto
expression: $1 * g1/($1 - g2)
description: $1 describe the first name of the variable in parameter, g1 and g2 is field data (global, cell or point)
usage : toto(Val), Val the name of a field data
My third remark:
To be able to introduce one formula into another.
For realize the idea: $1/toto($1)
Adding a name to the expression is indeed a good idea and easy to implement, we will do that.
Looking at the next remarks, I feel like it means implementing a scripting language. It is a lot of work that we are not going to do for this first implementation.
“Looking at the next remarks, I feel like it means implementing a scripting language. It is a lot of work that we are not going to do for this first implementation.”
It is true that it could look like that.
In a first approach, I was thinking of something very simple (not optimized) of macro type like in c/c++ language.
Before the command execution phase, a preprocessing phase would be introduced. It would consist of looping as long as we encounter an expression name (with parameter) to replace it with the corresponding expression.
If I have the expressions:
name: toto, expression: $1 * g1/($1 - g2)
name: titi, expression: $1/toto($1)
I want to build the new quantity:
titi(FOO)/toto(BOO)
the preprocessing phase would then give:
step1: (FOO/toto(FOO))/toto(BOO)
step2: (FOO/(FOO * g1/(FOO - g2)))/toto(BOO)
step3: (FOO/(FOO * g1/(FOO - g2)))/(BOO - g1/(BOO - g2))
step4: no expression to develop
this expression is then executed:
(FOO/(FOO * g1/(FOO - g2)))/(BOO - g1/(BOO - g2))
In order to facilitate expression detection, one can consider prefixing with $. If $ followed by a number then it is an input parameter, otherwise it is the name of an expression.
It’s not totally a scripting language.
But, for the Python calculator aspect, each expression can be seen as a Python method with its parameters.
When we say Formulae, are we talking about user level expressions or built-in functions? For example, is it gradient(foo) / mag(gradient(foo)) or is it just gradient()? I assumed it was the first. I was suggesting a drop-down menu for the second also.