Matrix inputs: preserve c(...) and r(...) model-answer types

[adamant-pwn]

Summary

STACK's fixed and variable-size matrix inputs currently reconstruct every response as matrix(...). A column vector, a row vector, and a one-column or one-row matrix therefore lose the distinction already represented by STACK's c(...), r(...), and matrix(...) forms.

This extends the c(...)/r(...) input convention discussed in #109 to both structured matrix inputs.

This patch makes the instantiated model answer the single source of truth:

• a matrix(...) model answer keeps the existing input and response unchanged;
• a c(...) or r(...) model answer makes either input reconstruct the same vector form;
• the fixed grid infers the corresponding N-by-1 or 1-by-N shape;
• the variable-size input keeps its existing variable length while preserving the model-answer type;
• no new input option or author-supplied dimension is required; and
• rendered HTML exposes data-stack-input-value-type="c" or "r", while the API reports casValueType: matrix|c|r for both input types.

This deliberately does not infer semantics from dimensions: matrix([1],[2]) remains a matrix, while c(1,2) remains a column vector.

Authoring example

stack_linear_algebra_declare(true);
v: c(1, 2, 3);

Choose either matrix input and use v as its model answer. The fixed grid creates one box per component; the variable-size input keeps its existing free-size textarea. Both return c(...). Use vec_convert(ans1) in a PRT when an answer test or calculation requires a matrix.

The same pattern works for a row vector whose model answer is r(...).

Why retain the structured inputs?

An algebraic input already accepts c(1,-2,1), but it requires students to type the function name, commas and balanced parentheses in one field. The fixed grid exposes the expected dimension and gives each component its own box; the variable-size input keeps the lighter whitespace notation without fixing the dimension. This patch preserves both interactions without discarding the CAS type.

Compatibility

Existing matrix(...) model answers render and validate as before. The patch adds no question setting, language string or migration step. Questions opt into the behavior by using STACK's existing c(...) or r(...) value as the model answer.

The HTML inputs continue to use the existing question-level matrixparens option. stack_linear_algebra_declare(true) now sends c(...) and r(...) through stack_matrix_disp(...), so their TeX output respects the same option instead of hardcoding bmatrix. #1848 remains open for the separate question of independent matrix and vector settings.

Verification

• Added focused coverage for fixed and variable-size C/R serialisation, response reconstruction, HTML/API metadata, validation, nested entries and forbidden generated constructors.
• php -l passes for both changed PHP classes and their focused test files in the current STACK API image.
• End-to-end tests in an isolated current STACK API container passed for both input types and both vector forms. The inputs reconstructed c(...) and r(...), preserved them in validation and API metadata, and formatted column- and row-vector sample solutions vertically and horizontally respectively.
• Direct Maxima tests passed for [, (, {, | and no delimiters. An integrated API test confirmed that fixed and variable-size C/R inputs use the same round HTML and TeX delimiters when matrixparens is (.
• The same tests passed with c/r listed in forbidWords: the generated top-level constructor is allowed, while the original rules still apply to each student-entered cell.

[sangwinc]

Thanks @adamant-pwn that's a very helpful suggestion, and not one I'd thought of myself.

1. I've changed the base to "dev" as we typically stage new features for the next release there. (See https://docs.stack-assessment.org/en/Developer/Releasing/#0-code-on-github )
2. I think this is a real improvement, thank you, and it only breaks back-compatibility where a teacher has been somewhat inconsistent!
3. Thanks for remembering the API.

I always thought of r(...) and c(...) as "sugar" for special matrix geometry, and therefore don't see the need to do this. I think, however, your motivation is captured in #1848 where you want different matrix parentheses. In this context, what you're asking for here is very sensible. We'd need the matrix inputs validation display to match the bracket types of the structure.

@LukeLongworth do you have any thoughts or comments, I know you've made a lot of contributions to the linear algebra libraries in STACK.

@adamant-pwn thank you so much for adding in test cases, that's super helpful and very welcome indeed. I think you'll also need the same for the matrix of variable size? https://github.com/maths/moodle-qtype_stack/blob/master/stack/input/varmatrix/varmatrix.class.php

[sangwinc]

@EJMFarrow could you review the proposed modifications to the API please?

[adamant-pwn]

Thanks! I've added the same handling for the variable-size matrix input and rebased onto dev. Both inputs now use the instantiated model-answer type rather than inferring it from the dimensions.

I also included the small parenthesis fix discussed in #1848: c and r now use stack_matrix_disp(), so validation and the HTML input follow the same existing matrixparens setting. #1848 can stay focused on whether matrices and vectors need independent settings. I'll wait for Edmund and Luke's comments before changing that API further.

[EJMFarrow]

API changes are minimal and look good, @sangwinc . Thanks, @adamant-pwn ! (Almost everyone will be using the pre-rendered inputs but great to have the info there for anyone who needs it.) CSS changes have also been added to the mobile CSS - lovely.

[LukeLongworth]

Hi! Thanks for this input, I think it's great. I'll be very transparent and say that this was always a rather hacked-together solution. My programming experience is limited and this worked for my particular use-case so I didn't look further! Integrating these functions more naturally into the broader STACK ecosystem sounds great.

[sangwinc]

Thanks @LukeLongworth if you have any capacity to test/comment on these developments then I'd very much appreciate your continued input.