maths / moodle-qtype_stack

Stack question type for Moodle
GNU General Public License v3.0
138 stars 147 forks source link

String input fields in automatic test case #1099

Closed Mat-Ge closed 3 months ago

Mat-Ge commented 5 months ago

According to the documentation, the answers to questions that use JSXGraph should be saved in a string type input field. This leads to two problems when creating automatic test cases.

  1. The first and last character of the sample answer is truncated. As a workaround, I enclose my sample answer in quotation marks, although a student will not do this.
  2. For randomized questions, the answer (e.g. the coordinate of a point from a JSXGraph board) usually results from a function. However, functions are not evaluated in input fields of type string, which is why the test fails despite a correct answer.

grafik

aharjula commented 5 months ago

Bad documentation for [[jsxgraph]]... Algebraic inputs are fine (as long as you allow them to have floats) when using the provided basic binding functions for points and sliders or lists of them. Those using the stack_jxg.custom_bind logic can choose between string inputs and algebraic inputs based on their chosen style of serialisation. String inputs are typically needed when you serialise to something that is not directly Maxima syntax, but one can, in most cases, also serialise to Maxima syntax if you pick the syntax sensibly and can thus provide a deserialiser. For example, here is a JSON presentation that needs to use string inputs and a matching Maxima expression that will work with algebraic inputs:

{
 "type": "directed_graph",
 "nodes": [[1.2,2.3],[3.4,1.0],[2.1,2.2]],
 "edges": [[1,2],[2,3],[3,1]]
}

Similar information can be transferred as a Maxima expression like this, and it does not matter whether Maxima actually has a function called directed_graph. We are simply using it as an inert container:

directed_graph([[1.2,2.3],[3.4,1.0],[2.1,2.2]], [[1,2],[2,3],[3,1]])

With sensible replacements ("directed_graph(" => "[" and ")" => "]") before parsing as JSON, one can easily deserialise the latter form on the custom_bind logic side.

sangwinc commented 3 months ago

The longer term plans are to add in a dedicate "JSON" input type to store state. Now we have GGB, JSXGraph and the Parsons block all using JSON to store state it makes logical sense to have a dedicated input. This way we can better support this kind of functionality, including test-case construction.