Support for `sec^2(x)`

[m-messer]

Currently, sec^2(x) is invalid and not parsed. Users instead have to use sec(x)^2 to get sec^2(x). Requires further investigation in the parser to determine if sec^2(x) can be supported.

[MadScientistBR]

Hi! I attended the Lambda Feedback tutorial at EDM 2026 and I'd love to start contributing to the project. Would it be okay if I picked this one up? Let me know if it's still available and if there's any context I should be aware of before starting.

[m-messer]

Hi! That would be great!

I believe it's a parsing issue. The dev docs have some good documentation on how the evaluation function is developed. But if you have any questions, please let me know.

For the key parameters elementary_functions: true and strict_syntax: false, I would start with the preview (or presubmission feedback) first. This is used to determine whether the student's maths parses as valid before giving them feedback on whether their expression is correct.

Over the next few days, I'll create a PR template and an issue template, so we can better report issues and collaborate. It's one thing working by yourself on an internal backlog and another working with others...)

[MadScientistBR]

Hi! Before doing any changes, I spent yesterday studying and learning more about the repo. Just like Peter said in the conference, I saw that you use the SymPy parser under the hood to evaluate expressions.

Apparently it has some 'extra' (I don't know if this term is the most appropriate one) operations that you must explicitly pass on the 'transformations' parameter of the 'parse_expr' function. You already use it in 'expression_utilities.py' on the following lines of the function 'parse_expression':

        if strict_syntax is True:
            transformations = parser_transformations[0:4] + extra_transformations
        else:
            transformations = (parser_transformations[0:5, 6] + extra_transformations +
                               (split_symbols_custom(can_split),) + parser_transformations[8, 9])

Here are the transformations (I've taken them from the official SymPy documentation):
0: lambda_notation
1: auto_symbol
2: repeated_decimals
3: auto_number
4: factorial_notation
5: implicit_multiplication_application
6: convert_xor
7: implicit_application
8: implicit_multiplication
9: convert_equals_signs
10: function_exponentiation
11: rationalize

If you look carefully, there is a transformation called function_exponentiation (number 10). It automatically rewrites expressions like sec**2(x) into sec(x)**2. Therefore, to solve this problem, you simply have to pass this transformation to the function:

        if strict_syntax is True:
            transformations = parser_transformations[0:4, 10] + extra_transformations
        else:
            transformations = (parser_transformations[0:5, 6, 10] + extra_transformations +
                               (split_symbols_custom(can_split),) + parser_transformations[8, 9])

P.S: We have to pass 'function_exponentiation' before 8: implicit_multiplication and 9: convert_equals_signs to avoid conflicts.

To test this hypothesis, I wrote these tests:

    @pytest.mark.parametrize(
        "response, answer",
        [
            ("sec(x)^4", "sec(x)**4"),
            ("sec**12(x)", "sec(x)**12"),
            ("sec^3(x)", "sec(x)**3"),
            ("sec**2(x)", "sec(x)^2"),
            ("sec^2(x)", "sec(x)^2"),
        ]
    )
    def test_trig_expt_correct(self, response, answer):
        params = {"strict_syntax": False}
        result = evaluation_function(response, answer, params)
        assert result["is_correct"] is True

    @pytest.mark.parametrize(
        "response, answer",
        [
            ("2sec**2(x)", "2*sec(x)**2"),
            ("Bsec**2(x)", "B*sec(x)**2"),
        ]
    )
    def test_trig_expt_with_adjacent_implicit_multiplication_correct(self, response, answer):
        params = {"strict_syntax": False, "elementary_functions": True}
        result = evaluation_function(response, answer, params)
        assert result["is_correct"] is True

They all fail if you don't pass function_exponentiation to parse_expr. However, if you pass it, all tests pass.

Because this is my first contribution, I'd like to hear your thoughts about it. If it's ok, I'll open a PR.

First of all, thank you very much
Best regards,
William Oliveira

[m-messer]

Hi William,

I think that makes sense. Do all the unit tests pass? What about for other elementary functions (sin, cos, tan, etc.)?

We also have the ability to test against our database of historical submissions, so before merging, I'll run your branch against that and check that the transformation hasn't broken anything unexpectedly. (I've had issues with transformers in the past...).

Once this is all merged and if you're happy to keep contributing, I'll move issues from the backlog to the issue tracker here.

Many Thanks,
Marcus

[MadScientistBR]

Hi Marcus,

Yes, all the other unit tests pass. I also added other test cases covering all supported trig and hyperbolic functions. Furthermore, it would be awesome to test against historical submissions to check the robustness of the solution (because this is my first contribution, I probably have broken something unintentionally, lmao).

Regarding the project, I really liked the tutorials and workshops you presented at the Festival of Learning and I'd love to keep contributing. I'd be glad to tackle other issues / features!!

To wrap things up, I've forked the project and opened a PR for this issue.

Cheers,
William Oliveira

[MadScientistBR]

p.s: While working on this repository, I've found some minor improvements opportunities that could make it easier for future people to contribute. It's no major deal and is more about style than substance.

Suggestions

• Types hints for every function signature. It would be easier to understand what every function expects as input. Right now, we have to "mentally" debug to understand what it is expected. For example:

def convert_unicode_dashes(expr)

reads easier as:

def convert_unicode_dashes(expr: str) -> List[Tuple[str, str]]

we can naturally see that it expects a string and will return a list. So we might have to treat the case where the returned list is empty

• Use Enums instead of hard-coded strings. This would make it harder to write silently bugs (like typos). For example:

if parameters_dict["multiple_answers_criteria"] == "all":

reads easier as

criteria = parameters_dict["multiple_answers_criteria"]
if criteria == MultipleAnswersCriteria.ALL:

Where MultipleAnswersCriteria is an enum:

class MultipleAnswersCriteria(str, Enum):
    ALL = "all"
    ALL_RESPONSES = "all_responses"
    ALL_ANSWERS = "all_answers"

BTW, these are just code-style suggestions. not a critique or anything like this, the work you guys have been doing is amazing and I have only compliments!! This is just a suggestion of the things I could help with other issues / backlog activities.

[m-messer]

Thanks for the contribution. #266 has been merged.

For the code style changes, can you open another issue? And then if you want to begin implementing them, that would be greatly appreciated.

I'll add other issues to the tracker later this week, and you are more than welcome to contribute.