Forbidden words

[impemic]

Is it possible to insert the space in "Forbidden words"?
Thanks

[sangwinc]

Sorry, not sure what you mean here. By default, spaces are not permitted in student's expressions. E.g. by default you get "Illegal spaces found in expression 2_x."

[impemic]

Sorry I'm referring to a "String" input by students; for istance I want a Boolean expression like AB'+A'B and I want to refuse the string "AB' + A'B".

[aharjula]

The "String" input does not actually enforce any forbidden words, they just happen to be present in the question editor due to the limitations of the editor. Have you considered just removing the spaces from the input in the feedback variables before using the value in the PRT?

cleanAns1: ssubst(""," ", ans1);

The whole forbidden words system exists to stop students from calling certain functions in inputs with evaluatable values but strings are not evaluated so they do not apply to them. And I don't see STACK providing any limits for limiting string content.

[impemic]

Thanks Matti, that is a good idea!
Anyway, I confirm you that is possibile stop students from writing some characters in a string answer; get a look to this, where "*" is a Forbidden word:

[aharjula]

Well that is odd the sting input should not do that, and once 4.3 comes out it will most definitely not do that,

[impemic]

Anyway your suggestion works, thanks!

[sangwinc]

Can I just check something?
Are you using the string input because the algebraic input does not allow the ' character?

I can see why the ' would be very useful. But, I assume you will want to accept both A*B'+A'*B and A'B+AB'. That problem is much better solved at a mathematical level (+ is commutative) than trying to solve it by a string match.

I guess your problems with spaces arise because your string match is failing?!

Let's try to solve the real mathematical problems, and not use string matching at all, unless a string match really is what you absolutely want.

I am determined to keep STACK mathematical. If you'd like a post-fix "prime" operator, let's add that in?

What question are you asking your students?

[aharjula]

Chris, careful now... ' is a very special operator in Maxima and messing with it would not be a good idea... Also you would need to make the parser also handle it so you need full rules about its binding powers and nature as an operator. Strings are obviously not the best way for doing things, but if one needs truly odd operators they are more than likely the fastest and simplest way to do things, especially if the answers are simple statements without too many terms...

[sangwinc]

Exactly Matti, we must not confuse ' in Maxima with a new mathematical "prime" operator. But, this is where the value of your new parser really shines.

Stage 1 is to implement "opprime" in Maxima, (not "prime" which might be confused with number theory, or primeop which looks like a predicate). Something like this:

/* Add in a "prime" operator A'. */
texput("opprime", "' ",postfix);

simp:false;
p1:A*opprime(B)+opprime(A)*B;
tex(p1);

/* Repeated "prime", as in a second order ODE. */
p2:opprime(opprime(y))+opprime(y)+y=0;
tex(p2);

/* Interpret "prime" as differentiation with respect to x. */
ev(p2,opprime=lambda([ex],'diff(ex,x)),simp); 

Teachers, and all internal maxima code, must use this mechanism.

Stage 2: for student input only, add in a flexible parsing rule to inrepret the postfix ' as opprime. This needs to be done, both for student input and when de-parsing the "teacher's answer" back into potential student input.

[aharjula]

Chris, there are things one can do and things one should not do. While it is indeed possible to do what you propose it means that you have now added a feature that needs to be checked and processed for every step everywhere, a feature that has a price, a feature that more than likely is used in a single field and even then for just a specific subset of questions. Do think your solution a few steps further and build some estimates on what are the costs both in evaluation and complexity of execution and weight them against the benefit especially as this specific edge case can be handled with strings no matter how badly they fit the STACK ideology.

Personally, I would really suggest you wait for the new parser to actually work and 4.3 to be actually out before starting to think these kinds of extensions. Trust me when I say that what you described is not all that would need to be done and that it will cost and it will cost in a way that cannot be skipped easily. While it will cost in execution the greatest cost will be the cost it will add to us the developers and that is the cost we really need to consider.

[impemic]

Are you using the string input because the algebraic input does not allow the ' character?
Can I just check something?
Are you using the string input because the algebraic input does not allow the ' character?
I can see why the ' would be very useful. But, I assume you will want to accept both A*B'+A'*B and A'_B+A_B'. That problem is much better solved at a mathematical level (+ is commutative) than trying to solve it by a string match. </i>

I totally agree with you! You understood exactly the issue. The question is "Given the truth table of a boolean function f(A,B), write down the equivalent sum of products". Our sintax is: "A+B" for A \lor B, "AB" for A \land B, A' for \lnot A. I am not so clever to translate that question at a mathematical level and I withdrawn on the string input.  

> I am determined to keep STACK mathematical. If you'd like a post-fix "prime" operator, let's add that in?

Yes please, unless it is possibile work without it.
I'm now reading other replies
 

[impemic]

Anyway (please forgive my inexperience, I am a beginner with STACK), how can I ask my students a boolean expression? In which way can they write AND, OR, NOT at a mathematical level?
Thanks

[sangwinc]

I'm going to close this issue, because the support for propositional logic addresses the underling issue (I think). We can open future issues for logic if we need to.