New input for typed text

[sangwinc]

Currently, STACK provides input boxes into which students can type algebraic expressions. The "equivalence reasoning" input type extends this, but that's also limited to algebraic expressions. What's missing is the facility to type a complete mathematical argument.

This issue is to discuss a new input which will allow students the opportunity to edit a text-based format for mathematics.

The goal is for students to type a short, complete mathematical argument as free-form typed text as they derive it, with minimum friction from the computer interface. Diagrams, graphs and tables of information is an entirely separate issue, and are not discussed here. However, the inclusion of diagrams should be an option for the future, indeed this is a proposal for a flexible extensible system.

Ideas for the text-based format.

1. Students type unicode text. Text-formats give complete transparency over what the student types and are future-proof.
2. Students use Markdown for document structure and formatting
3. Students can include ASCIIMath/Space Math for mathematics. See https://asciimath.org/
4. Students optionally include LaTeX mathematics environments

One option is to implement the above features as a twin-pane system. Students type text into one pane and see an immediate preview of their text in the other pane. Adopting a text-format allows students to cut and paste between expressions. The immediate preview shows the student all mathematics using the traditional layout of symbols, two-dimensional structures, etc. Cut and paste provides students with the option to re-draft and edit their text, without messy crossing out of rough working. This may prove more efficient than traditional writing, and does not interrupt the flow of thought in the same way changing to a mouse-driven equation editor seems to do.

This diagram shows how this proposed text-based format interacts with other components

We expect AI will support hand-writing to typed-text conversion, either from a photo, tablet or other written input.

Ideas for the future:

1. Add in an "equation editor", to allow students to drag and drop equations or select text and then edit an equation in existing text (significant and separate project needed!)
2. Extended markdown for proof structures.
3. Calculator tool. It seems incongruous for students to reach for a pocket calculator, or type digits into a calculator tool, and then copy the answer back into their digital document. Instead, the proposal is that students can embed a calculation within their document, e.g. by giving students limited access to CAS-text.

At the outset we need an input type, so that part (e.g. the end) of a students' calculation can be automatically assessed by STACK. This is, immediately, an advance on current inputs since we can capture the students' working as well as their final answer.

In the first instance, this will extend the "textarea" input to capture multiple lines of students' working.

[sangwinc]

Just as a specific example below is raw text of what we might expect students to type into this input. Note, this is unicode text with some ASCIIMath between backticks, and LaTeX with $s. We need to agree on delimiters, etc. in due course.

## Theorem: ∀ n ∈ ℕ, 1+3+5+7+...+(2n−1) = n².

Let P(n) be the statement `sum_(k=1)^n 2k − 1 = n²` ∀ n ∈ ℕ.

Since `sum_(k=1)^1 =1 =1^2`, we see that $P(1)$ is true.

Assume that P(n) is true. Then  
````
sum_(k=1)^(n+1) (2k−1) = sum_(k=1)^(n) (2k−1)+ (2(n+1)−1)
                       = n² + 2n + 1
                       = (n+1)².
````

Since `P(1)` is true and `P(n+1)` follows from `P(n)`, we conclude 
that `P(n)` is true `forall n in NN` by the principle of mathematical induction. 

This is how the markdown (extended by ASCIIMath, LaTeX etc) would appear to students

[georgekinnear]

It would be great to have a longer text input type that could be available to PRTs. I can imagine this being useful for some quite modest applications, with answers much shorter than the example you've given.

For instance, I recently asked students to compute the partial sum $$s_n$$ of the series $$\displaystyle \sum_{k=1}^\infty ({2 k+3})$$ then decide whether the series converges. I included a "Notes" input type where students could give a brief reason. Looking at what students actually typed here, it was entirely possible to check them using regular expressions, e.g.

valid_reasons: [
  "Sn is not bounded.*",
  ".*(s_n|S_n|sn|Sn|partial sum).*(go to infinity|do not have bound|not bounded above|unbounded|unbouneded|grow without a bound|not bounded|no upper bound).*",
  ".*(s_n|S_n|sn|Sn|partial sum).*(\\&rarr\\;|go(es)? to|tends? to|approach(es)?|diverge(s)?|going towards).*(infinity|inf)?.*",
  ".*(terms|Terms|sequence|Sequence).*(does not|do not|doesn.?t).*(approach|approaches|tends? to).*(0|zero).*"
];
valid_reason_given: maplist(lambda([pat], regex_match_exactp(pat, their_reason)), valid_reasons);

However it was only at that point that I realised (/recalled from the docs!) that Notes are not available to PRTs.

One other aspect that would make this feature really powerful, is to have better support for hybrid grading approaches. In a moodle quiz, if I go to Results > Manual grading, I can choose to look through all of the responses to a particular STACK question. It would be amazing if I could filter this (e.g. based on whether a particular PRT node was hit) so that I could then author questions where the PRT grades everything that it can manage automatically, and exits to a particular node in case some manual review is needed.

Sorry if these points are a bit off-topic, but they do feel related!

[sangwinc]

Yes @georgekinnear, that's also going to be part of the design here. The goal is to make the text available for the purposes of assessment.

I've also been wondering about how to group responses by auto-generated outputs. The moodle Manual grading features might not be up to that. To be honest I've not done a lot of digging into that yet, but yes this is also on the radar here. Thanks for the comments.

[sangwinc]

@georgekinnear I think we have a design proposal which will allow the student's answer (the whole text string) to be passes to a PRT. This involves a new input type "freetext", which does not change the design of the current "notes" input.

This input type will return a Maxima "string", just as other input types do (string, JSON,....).

This input type will have much more sophisticated client-side rendering of Markdown, ASCIImath (perhaps later replaced), etc. so the student gets the best possible typed experience. That's described above.

The proposal is that Javascript can then take part (or later parts) from this input and add those to other inputs within the question, in a very similar way to the way JSXGraph blocks place JSON into the JSON input type to store state.

This is proposed to be a one-way transfer into the auxiliary input.

The advantages of this design include the following.

1. teachers can rely on the regular validation options of the exiting inputs, e.g. algebraic, units, textarea, equiv, with all their current feature.
2. In the future, we can have multiple links enabling automatic assessment of separate parts of a proof.
3. We can re-use the manualgraded option of the existing notes input as well here.

[sangwinc]

@EJMFarrow I'd like to suggest, for the MVP, that we match STACK's rather conservative view on delimiters for LaTeX.

Students must only use the two forms: (1) \( ... \) for inline and (2) \[ ... \] for displayed mathematics. This input system will not support $ ... $ for inline (and certainly not the mix of $ ... $ and \[ ... \] which a lot of people use!). (People who would like to use LaTeX over ASCIIMath will be used to typing \ a lot anyway.)

Let's re-use backticks for inline ASCIIMaths I proposed, accepting for the MVP that this is also used in traditional markdown for code. It's the least obtrusive delimiters available and so it is in-keeping with ASCIIMath, and it works within markdown as delimieters (!).

[EJMFarrow]

@sangwinc I've added the Tex plugin for Markdownit which allows us to detect maths blocks. Delimiter is currently set to brackets as you've requested but we could use dollar signs as well by changing the delimiter option to all here:

moodle-qtype_stack/corsscripts/ascii/stackascii.js

Line 34 in 6063dfd

.use(window.mdItPluginTex.tex, { render: (content) => content, delimiters: 'brackets' })

\( ... \) uses the math_inline rule in mardownitrules.js and \[ ... \] uses math_block. The math_inline rule just puts the brackets back currently. The math_block rule does the alignment as before but not the call to ASCIIMath. For code_inline we still call ASCIIMath.

[sangwinc]

Thanks @EJMFarrow I've just pushed a sample question (https://github.com/maths/moodle-qtype_stack/blob/iss1748/samplequestions/stacklibrary/Features/input-type-sample-questions/Free-text_final_answer.xml) as a target to work from. This has the free-text input, and also an algebraic input to link the final line to. I hope this makes sense?

Eventually, we can hide the input ans2 itself (html) and just show the valuation message.

[EJMFarrow]

OK @sangwinc , I think I've hooked that question up to take the final(ish) line and plug into the second answer. The question has an ascii block now which takes the input and answer fields as parameters. The actual find and tidy of the final line happens here:

moodle-qtype_stack/corsscripts/ascii/stackascii.js

Lines 22 to 36 in ba1e710

	let lines = raw.split('\n');
	lines.reverse();
	for (const line of lines) {
	const trimmed = line.trim()
	if (['```', '/]', ''].includes(trimmed)) {
	continue;
	}
	// Convert 'f(x) = answer' to 'answer', removing backticks from beginning and end.
	if (/^`*f\(x\)\s*=\s*/.test(trimmed)) {
	const answerEl = document.getElementById(answerContainerId);
	answerEl.value = trimmed.replace(/^`*f\(x\)\s*=\s*|`+$/g, '');
	answerEl.dispatchEvent(new Event("change"));
	break;
	}

We'll need to minimise this file in the final version but at the moment you can just update the code and reload the page and see what happens. Chances are that it's currently not doing exactly what you envisaged. We'll also need to think about scalability with multiple answers, etc.

Questions:

• Your sample question still uses ``` to fence ASCIIMaths but we don't currently have a delimiter for multiline ASCIIMaths.
• Validation. Do we ever want validation of the freetext answer? (I've updated the input.js to access the validation function in the freetext class now anyway.) And how do we handle ASCIIMaths as the final answer?

[sangwinc]

Thanks @EJMFarrow that's super quick of your to sort all that out! I think we need to talk about the next steps, particularly a flexible architecture for dealing with delimiters like ```. Let's chat in person.