Added support for brackets

[m-messer]

Problem

Only () was accepted as a valid bracket, causing parse failures for common textbook notation like [x+y]*z.

Limitations

{} is not supported in the feature. {} is already in use for "multiple acceptable answers" ({x+1, x-1} = either is correct), and {} is routinely used to denote sets.

Changes

• expression_utilities.py: new convert_bracket_notation() maps [/] → (/). Called in preprocess_expression() (normalizes preview output) and parse_expression() (covers convention parsing + direct grading-path calls).
• preview_test.py: added [] cases to test_brackets, expecting output normalized to ().

[peterbjohnson]

I've pasted Claude's list of potential issues below. I suggest we only make the substitution if not strict_syntax? And perhaps also a custom parameter to not substitute at all (sub_square_brackets?). You could then do the same with curly brackets, and they can be enabled/disabled - perhaps with the default as disabled?

Claude:

Interval notation: [a,b], (a,b), [a,b) all mean different things (closed/open bounds). Flattening everything to () throws away that distinction — sympy's Interval cares about it.

Matrix/list literals: [1,2,3] or [[1,2],[3,4]] are meant as a sympy list or Matrix. Turning them into (1,2,3) or nested tuples changes the type entirely, and sympify won't build a Matrix from it.

Indexing vs grouping: x[0] is array/element access, not grouping. Convert it and it becomes x(0) — a function call on x. If any of your inputs use bracket indexing, this silently changes meaning.

Naive string replace: swapping every [→( and ]→) doesn't respect nesting or existing parens. Use a stack to match bracket pairs properly, especially with mixed/nested ()/[] — otherwise you can get mismatched or misassociated groupings.

Empty brackets [] — decide what that should even mean before conversion.

[m-messer]

Thanks for the comment. I'll comment on each element below:

. I suggest we only make the substitution if not strict_syntax? And perhaps also a custom parameter to not substitute at all (sub_square_brackets?). You could then do the same with curly brackets, and they can be enabled/disabled - perhaps with the default as disabled?

That's a great idea for excluding it from strict_syntax. Instead of two parameters for supporting bracket substitutions, we could have one and substitute both [] and {} with only one additional parameter?

Interval notation: is currently not supported by compareExpressions, [2,5) will not parse. Is this something we want to support or is it out of scope for this evaluation function?

Matrix/list literals: We have a matrix input that uses a separate evaluation function to handle matrices. Additionally, compareExpressions does not have native matrix support. Is this something we want to add or should we update arraySymbolicEqual to use compareExpressions?

Indexing vs grouping: This also isn't currently supported by compareExpressions

Naive string replace: I don't understand what claude is saying here. If we have an input [(x+y)*(z-y)] subsituting the [] with () would give ((x+y) * (z-y)) which is equivalent.

Empty brackets []: Currently, not supported