Fix/strict syntax default

[m-messer]

Problem

The platform sets strict_syntax to false by default, but the code defaulted to True in two places (evaluation.py and expression_utilities.py). This meant that when no strict_syntax key was present in params, the code would enforce strict syntax rules (e.g. rejecting ^ for exponentiation) even though the platform's intended behaviour is to be permissive by default.

Fix

Changed the fallback value for params.get("strict_syntax", ...) from True to False in both:

• app/evaluation.py — controls the ^ and ! notation warnings
• app/utility/expression_utilities.py — controls the SymPy parsing strictness

Other changes

None — this is a targeted two-line fix with no refactoring or behaviour changes beyond aligning the defaults.

Database Testing
Results can be found here: https://github.com/lambda-feedback/compareExpressions/actions/runs/25863534753/job/75999407423

10 errors out of 1000

1. (x cosx - sinx) / (x^{2}) could not be parsed as a valid mathematical expression. Ensure that correct codes for input symbols are used, correct notation is used, that the expression is unambiguous and that all parentheses are closed.

• Answer is written in LaTeX

2. Grade mismatch: - Eval function: True, DB: False -- answer: d/(dt)+ujd/(dxj) response: d/(dt)+uj(d/(dxj))

• The answer and the response match

3. 2( tan x) sec^(2) x could not be parsed as a valid mathematical expression. Ensure that correct codes for input symbols are used, correct notation is used, that the expression is unambiguous and that all parentheses are closed.
   • Same as 1.
4. Grade mismatch: - Eval function: True, DB: False -- answer: (1/3)*beta*gamma*z**3 + (1/2)*(rho_0*gamma + beta*g_0)*z**2 + rho_0*g_0*z response: 1/3 beta gammaz^3+1/2(rho_0 gamma)z^2+1/2(g_0 beta)z^2+(rho_0g_0)z

• The answer and response match

5. Grade mismatch: - Eval function: True, DB: False -- answer: (d/(dt)+ujd/(dxj) response: d/(dt)+uj*((d/(dxj)))

• The answer and response match

6. Grade mismatch: - Eval function: True, DB: False -- answer: (d/(dt)+ujd/(dxj) response: d/(dt)+uj*((d/(dxj)))

• The answer and response match

7. x E^{x}(2+x) could not be parsed as a valid mathematical expression. Ensure that correct codes for input symbols are used, correct notation is used, that the expression is unambiguous and that all parentheses are closed.

• Answer is written in LaTeX

8. Grade mismatch: - Eval function: True, DB: False -- answer: A/s( e^(-as)-e^(-bs)) response: A(( E^(-a*s))-( E^(-b*s)))/s

• The answer and response match

9. 2( tan x) sec^(2) x could not be parsed as a valid mathematical expression. Ensure that correct codes for input symbols are used, correct notation is used, that the expression is unambiguous and that all parentheses are closed.

• Answer written in LaTeX

10. -2M0/3 could not be parsed as a valid mathematical expression. Ensure that correct codes for input symbols are used, correct notation is used, that the expression is unambiguous and that all parentheses are closed.

• Parsing issue when no parameters are included, not due to this change.

[m-messer]

Fixed parsing issue for -2M0/3, strict_syntax was not correctly set to false when no parameters were parsed.

Updated DB results (https://github.com/lambda-feedback/compareExpressions/actions/runs/26028090760)

10 errors out of 1000 tests, ran with the same seed, only difference to the above:

10. Is now: Grade mismatch: eval fn True, DB False -- answer: -2M0/3, response: -2*M0/3

• With strict syntax now False by default, implicit multiplication now means that these are equal.

[m-messer]

Remaining errors will be resolved in the following updates, see #257 and #258 for more details.