> Even / can lead to confusion: a*b/c*d
> - Usually read by programmers as (((a*b)/c)/d)
> - Sometimes read by mathematicians as ((a*b)/(c*d)), with / as fraction line
Your coworker might be an engineer, technical mathematician, ... someone who works more with equations than programming
This is a real world issue. It occurred with graduate professionals working in an interdisciplinary team.
I see two different problems here.
Problem #1
An engineer has modified the code of your project.
He had "(a*b)/(c*d)" in his mind,
but he has written "a*b/c*d" in the code because he is unaware of Lua precedence rules.
But an engineer would probably be unaware of your coding style guides too.
So, the problem #1 would be unsolvable by introducing the rule about parentheses and division.
Problem #2
You are modifying the project, and you want the engineer
from your team to understand math formulas in the code correctly.
So, instead of "a/b*c" you are writing "(a/b)*c".
This will surely solve the problem #2, but not the problem #1.
Conclusion:
Despite having newbie-friendly rules about parentheses,
an engineer should better avoid writing code :-)
A possible solution is to write LaTeX-to-Lua converter
and use the code like the following:
local function p(t)
local g = ....
local z = ....
return
latex_to_lua_func([[
\frac{gt^2}{2z}
]], "t, g, z"
) (t, g, z)
end
The "latex_to_lua_func()" is a memoized converter.
Your engineer should modify only the LaTeX string.
