texput not working properly at validation step

[azampa]

Since the %union and %intersection functions cannot deal with symbolic sets (e.g. A, or B), I wanted to use functions named Union, Intersection, Complement, Difference to work with letters and sets, allowing constructions like Union(A,{1,2,3},C). To properly show the mathematical symbolism (e.g. A ∪ {1,2,3} ∪ C) I used texput in conjunction with stack_disp. The lambda function passed to texput checks the validity of an argument as a set (i.e. a maxima symbol, a maxima set or an expression built on these two types by means of the above functions) and display ? if some argument is not valid. Therefore, an input like Union(1,B) should display as ?: this happens at the levels of question text and node feedbacks, while at validation STACK shows (1) ∪ B! Another kind of problem is the following. While Union and Intersection are correctly displayed by means of symbols ∪ and ∩ respectively, at validation level Complement(A,B) and Difference(A,B) are not rendered as Ā_B and A−B respectively, being displayed as they are written. I attach an example of question. I tried both using and not using ev(..., simp) for any if statement, but nothing changed. My stack version is 2020120600

questions-HS.1-SL.1-From characteristic properties to sets-20210915-1425.xml.zip

[marlag]

Having same (seems so) issue - regarding variables used. In question text it is displayed fine, not resolved in feedback part. I would love to see any hint or patch as it is affecting my course using randomized math exercises - having rich feedback based on variables.

Example:

Question variables:
p:5;
texput(aa, tex1(p));
texput(bb, "5");
texput(cc, tex1(5));

Then:

[sangwinc]

So, the way this works is that some expressions in the question variables are pulled out as "context variables". In the example above, texput(aa, tex1(p)); will be pulled out and used everywhere else. But the assignment of p:5 only happens when the full question variables are in play - that is when you create the question. This is not completely clear from the docs (sorry),

https://docs.stack-assessment.org/en/Authoring/Variables/#context-variables

which only make it clear functions are not supported. Basically the texput command (currently) has to be completely self-contained. I would expect the aa=p example, and I don't consider it a "bug". Expanding the functionality would be very complicated.

Your texput for Union relies on the function _valid_set_arg(_x), so you are trying to do something which is not currently supported as well.

at validation STACK shows (1) ∪ B!

I think this is because returns function _valid_set_arg(_x) returns unevaluated (being unavailable at that point in the code!).

I'm really sorry STACK does not support this. I can see what you are trying to do, and it is very valuable.

[sangwinc]

I think one way to allow this to happen is to have some way of making anything in the question variables also "context variables". We have a mechanism for context variables now so this should be straightforward. Matti, any comments on this?

[aharjula]

Indeed the STACK way of minimizing what gets sent to Maxima does have all sorts of side effects. Hopefully, the Stateful way of not minimizing what gets sent but instead minimizing the times stuff gets sent (i.e. number of CAS-sessions) is something we could move towards in the future.

The older STACK way might be something that we could move away in the current world, now that most systems have more power that the ones that were available 15 years ago when most of the logic for processing order was designed. To me it does not seem necessary to separate any context-variables at all, why not just send the whole question variables into the validation session and forget about any differences, it is not like many people do so much processing in the question variables that it would take too much time to evaluate them.

In the input2/Stateful world the validation session receives pretty much (actually all) all the variables, starting from question-variables and validation-setup for all the inputs and the session that renders the validation does indeed have access to all the code of the question and it does not seem too slow, most of it will anyway end up in caches.

[sangwinc]

Matti,

Certainly, in the past we couldn't send in all the variables to inputs. If the teacher used the variable "ta" (as I often do) to hold the teacher's answer, then evaluating the student's input "ta" in the context of the question variables will give them a correct answer! Yes, we do now forbid the variable names used by teachers. Do you think that is sufficient?

Chris

[aharjula]

Naturally, allowed and forbidden words do not do enough if the variables are in the context (simp:false is not always enough to stop them from being placed in the expression), but that is something that can be handled through other means. The rendering of the student's validation message can simply use filters like 910 to turn defined variables into things that will not get expanded when printed out. 910 of course only deals with floats but it is an example of a filter that is specifically meant for use in cases where we wish to control the output form of the input.

Alternatively, the rendering portion of the message can be executed in a block that has intentionally detached those variables from the context, which is a very simple way of dealing with that issue:

ta:9;
(%o1)                                 9
print(ta);
9 
(%o2)                                 9
block([ta],print(ta));
ta 
(%o3)                                ta

[azampa]

Thanks to both Cris and Matti,

I solved the problem moving the definition of the function _valid_set_arg(_x) inside the lambda functions of each texput, making each of them self consistent.