Variables with ^

[JB74]

Would it be possible to enable variables in STACK with ^
We use e.g. û heavily in electrical engineering for complex "pointers".

Best regards, Juergen

[aharjula]

Actually, we already support variables inside the question logic with any unicode "letters" as long as the Maxima underneath is new enough and properly configured.

The actual limiting factor here is with the student inputs having extra rules blocking more complicated characters from being used to avoid some confusion, for those inputting things and not noticing "extra accents", and yes those rules are silly in the modern world. These limits date back nearly 15 years when we had a nice little bug where inputting non-ASCII chars made the system break down and vomit out a bit too much information for the student to see, now we should be safe from that.

The bigger problem is that if we allow all chars, we might end up with a problem with certain characters looking the same but not being the same, for this we actually have a new feature from last summer that deals with this very issue on a small scale for parenthesis and some other special symbols. For example, there are Latin alphabet characters that look very much the same as some Cyrillic ones, and we might want to avoid collisions with them. So while the allowed set should probably be larger than ASCII it might still need to be somewhat limited as otherwise, our character replacement map could grow to be quite large.

Personally, I see no big problems opening up from ASCII letters to LATIN-1 letters at least with those letters, the developers can understand them, but at some point, someone will want us to support even more, and we need to think through how we do that and how we can target subsets of the whole possible world of characters in a somewhat consistent manner. If we allow ^ accented ones then what do we do with all the other accents, many of which can be easy to confuse (à vs. á etc.) with each other?

[aharjula]

To further complicate this issue, we really need to consider some of the accents that are possibly confused with operators. Basically, if someone enters "ū" do we consider that macron as an overline and if so will we then force some specific interpretation for it? Forcing an interpretation would probably be a bad thing, but if we do not then we need to ask if the student meant something specific if we see that and it is not a variable within the question itself.

The problem here is, that if we connect the logic for deciding which chars are acceptable to the chars used in the question itself, our character mapping logic becomes somewhat more complex we just cannot bulk replace things like we now do.

[JB74]

I would suggest to stick to the "english" alphabet (in terms of "base" letters) and do not include any "accents" coming from other languages, as the main focus (at least from my side) are mathematical expressions. The "^" would reflect a peak value in electrical engineering. We could also use some commands (\hat{a}) as used in LaTeX, but this makes the live of the students more complicated, when entering results. But basically the same situations occurs for subscripts. I also would not do a special interpretation of e.g. û - as there is also no special interpretation of u_1 - which would be from my side basically two different variable names.

I am not that much involved in programming, so I cannot comment on this, but I come more from "the user" side as we would like to use STACK for our EE courses.

[sangwinc]

Anther option, which might work in some situations, is to use texput to tune the display. That's not what you need for student input but it will help teachers.