Séparateur décimal / Decimal separator

[ebugnet]

Bonjour,

Je me permet le message en Français... Le séparateur décimal par défaut sur toutes les questions Moodle est soit le point soit la virgule et donc compatible en fonction des langues utilisateurs. Dans ce type de question, seul le point est autorisé sinon la réponse est considérée comme fausse. Il serait vraiment appréciable de permettre aussi la virgule, Français oblige, mais j'ignore la faisabilité ou la quantité de travail pour permettre cela. Merci !

Éric

========== Default decimal separator on all Moodle questions is dot or comma and is compatible depending on the user language. In this question type, only the dot is allowed, otherwise the answer is considered wrong. It would be really nice to allow the comma, but I don't know the feasibility or amount of work to allow this. Thank you!

[dbauer-ets]

Éric,

Merci d'avoir ouvert cette question. Si je ne me trompe pas, Philipp, toi et moi avons le français comme langue maternelle. Nous vivons dans des régions où la majorité des gens parlent français. Par conséquent, nous pourrions travailler en français.

Cependant, il est indéniable que l'anglais est devenu la langue internationale. Afin d'atteindre le plus grand nombre de personnes à travers le monde, il serait préférable de parler ici en anglais.

[dbauer-ets]

Philipp,

As Eric reminds us, most Moodle questions can use either the decimal point or the decimal comma.

It's surprising that the 'Formulas' question doesn't offer this option. It could be better, especially considering how long it has been requested.

It appears that more countries use the decimal comma, while more people use the decimal point. However, that should not be a reason for not having this option in the 'Formulas' question.

I wrote a small JavaScript snippet to make up for the absence of this option, that allows 'number' type answers to accept both the decimal point and the decimal comma. The snippet is used by different users, and reports indicate that it works very well. But a snippet for the Formulas question, it's embarrassing. :-)

There's no reason why we can't implement this option in the 'Formulas' question for all four types of responses (number, algebraic, numeric formula, algebraic formula).

We'll do it when you're ready. I'll be happy to chat with you about the best way to do it, if that helps. :-)

Thank you for your fantastic work.

Cheers!

[PhilippImhof]

It appears that more countries use the decimal comma, while more people use the decimal point. However, that should not be a reason for not having this option in the 'Formulas' question.

The reason why this is not implemented yet is certainly not that I would consider it useless. I don't. And I do not take my own judgement as the sole measure for how a plugin that is used by many people all over the world should work.

There's no reason why we can't implement this option in the 'Formulas' question for all four types of responses (number, algebraic, numeric formula, algebraic formula).

I disagree very strongly. There are good reasons why this is not implemented yet. If it was as simple as you probably imagine, it would have been done long ago. Just to remind you that this issue is open for more than three years, long before I started my work. And there is even an issue in the Moodle tracker that was opened in 2016. You surely don't think that anyone would hold that back just for the sake of holding it back.

In the first version of your comment, you pointed out that "most questions" in Moodle allow entering localised numbers. That's true for questions that only accept numbers as their input. It is however not true for question types that are somewhat similar to this one. To the best of my knowledge, there is no question type where students can enter formulas or arithmetic expressions and use the comma as their decimal separator. So if even the guys who develop the STACK question type -- probably the most sophisticated and advanced question type that exists -- do not offer that option, one might take it as a very reliable hint that it's not that easy…

The main thing to bear in mind is that any solution must be made in a way that will work reliably for all users in all situations while maintaining full backwards compatibility. Also, adding this feature is a one way street; once it is there, there's no turning back. So it must be done in a way that will not limit or block further developments. There are already quite many restrictions because of some design choices that were made 15+ years ago.

While it is fairly easy to allow the decimal comma in the answer type number, this is absolutely not the case for numerical formulas, because we allow the student to use functions and they use comma as their separator of arguments. If the comma is used for numbers, one can either restrict the allowed functions to those with only one argument (thus not allowing ncr() although it absolutely makes sense to have that function) or the functions would have to be done differently and e.g. use the semicolon as a separator of arguments. But that could obviously only be changed on the student side, because teachers already use ncr() and other functions with the comma as a separator. That's not impossible, but it complicates stuff. (We already have that issue with the IMHO very bad idea that ^ means exponentiation for the student, but XOR for the teacher, unless they use it in an algebraic formula, where it will also mean exponentiation. That's a legacy we will carry forever and it goes back to a less than optimal implementation choice.) Also, in the future, we might allow the students to enter vectors or matrices. Or there might (Note to our users: this is not a promise!) be an answer type "set" and/or "list". Those would then need to use semicolons as well, even though all CAS packages use commas.

Now, one could argue that we might at least do it for the number type or even for numeric answers where no functions are allowed. That's true and it would not be extremely difficult. But it would mean that if you have a numeric answer in part 1 and a numerical formula in part 2, the user will have to use a different format for numbers within the same question. IMHO that would be a total usability nightmare.

So while I agree that the current state is not perfect, I simply do not see any better alternative. (I think your script is a nice workaround that people can use in certain situations. But it's not a complete solution that addresses all points mentioned above.) Most students know that they have to use the point in many situations, e.g. when using Wolfram Alpha or CAS packages, in programming languages or when working with their calculator. So they can somehow accept that weakness as a "known problem with those strange computers", even if they don't like it. And, most important, if they enter a comma instead of a point by mistake, the warning triangle gently reminds them of the format to use.

[PhilippImhof]

While preparing test cases for the next major version (which will still take some time…), I had an idea for a viable solution:

Whenever the student (and the student only) enters an answer that does not pass validation, we substitute every occurrence of , by . and send it to validation again. If it passes, we put this as their new answer and show some notice, e.g. "Your input has been changed. Please check your answer. Note that you should use a decimal point rather than a comma."

I think it is legitimate to alter the student's answer in such a case, because (a) if their answer does not pass validation, it would be graded wrong anyway and (b) they can change it back easily. There might even be an "undo" button in the notice.

I have yet to think about possible risks of this, but it might work. Depending on the implementation, it would even be possible to substitute only some of the commas in case the first attempt was not successful. If there are not more than 5, that would be just 32 cycles, so thats probably just a few milliseconds. (I can probably come up with some good heuristics as to what commas are more likely, e.g. commas followed by a space are likely to be separators and commas between numbers are probably decimal points. Also, we already know that a "real" comma can only occur inside a list or inside a function that accepts more than one parameter. Any comma occurring in a string can be skipped as well.)

This method could, in a later step, even be extended e.g. to unmatched parentheses, similar to what Wolfram Alpha does: if the student enters 5*sqrt(3, it might suggest 5*sqrt(3) or if they enter 5*sqrt(3+5 the suggestion would be 5*sqrt(3+5) even though that is probably not what they intended, so the notice should now say something like: "An attempt was made to fix mismatched parentheses. Please check if the expression matches your intention."

[PhilippImhof]

Forgot to mention: With the new parser, we have a good idea as to why the validation failed. With some errors, it is clear that we do not have to try this at all, e.g. if the error concerns mismatched parens, unknown variables or unknown functions.