Suggestion for a penalty regime improvement

Suggestion for a penalty regime improvement

de Chris Nelson -
Número de respuestas: 5

Hi Richard,

A colleague has noticed that his students were getting a score of .96 despite several (>4)  submissions.

It turned out that this was happening because a trailing comma in the score regime was missing. If there's no comma, then obviously it just applies the first two penalties. But it's really easy to miss! Would it be possible to highlight this issue in any way, or make progressive regimes be a bit more flexible?


Recognised as the penalties for the first two tries: '2%, 4%,' or '2% 4%'

Recognised as a progressive penalty: '2%, 4%...,', '2%, 4%...', or '2% 4% ...'

Best wishes,

Chris Nelson.

En respuesta a Chris Nelson

Re: Suggestion for a penalty regime improvement

de Richard Lobb -

Hi Chris

Thanks for reporting. Indeed that's a trap - I'm only surprised I haven't fallen into it myself. Or perhaps I have but I didn't notice and students unsurprisingly never complained.

I was surprised to see the '%' symbols in there, too. I would have expected those to cause an error but in fact the call to the function to convert the strings to floats just silently ignores all the stuff at the end so that never got picked up (like the trailing '...').

I've pushed an update to CodeRunner to github. As you suggested, it allows comma-separated or space-separated items, and allows a trailing '%' symbol after each number. However, it converts all the variant forms to the originally-expected generic form with a comma and a space as a separator and no percent symbols. That generic form is what you see if you then edit the question again.

This does mean the display of the penalty regime to your students will look slightly different. You would have had

(penalty regime: 0%, 10%, 20%, ... %)

but will now see

(penalty regime: 0, 10, 20, ... %)

which is what I see and always expected others would see. The percent on the end is added by my code when displaying the penalty regime - it's not valid input.

Non-progressive penalty regimes display as

(penalty regime: 0, 10%)

or, with only one penalty (the only common non-progressive case?)

(penalty regime: 0%)
Again the final '%' is added by me.

I hope you don't mind the change. It will apply only to new or newly-edited questions, not to your existing ones.


En respuesta a Richard Lobb

Re: Suggestion for a penalty regime improvement

de Chris Nelson -

Thanks for the very quick response, Richard!

That sounds great - thanks very much :-) We probably won't be able to grab the code for a couple of months for our main server, but I'll check it out on one of our test servers soon.



En respuesta a Richard Lobb

Re: Suggestion for a penalty regime improvement

de Anton Dil -
Hi Richard, the help for the 'Marking' field in a question shows an example like you have above, e.g. 0, 5, 10, 30, ... but the default setup for a question contains the penalty regime 10, 20, ...

This means that the default is to penalise from the first check. I just wondered if that was intended. It's not something I noticed before and it feels like another thing that could easily be missed.
En respuesta a Anton Dil

Re: Suggestion for a penalty regime improvement

de Richard Lobb -
Hi Anton, the default penalty regime can be set in the CodeRunner plugin admin settings:

Admin settings screenshot

So you can ask your sysadmin to change it to a friendlier regime if you like. That might solve your immediate problem?

However, that's a system-wide change so all courses using CodeRunner will be affected. 

A better approach might be to inherit the penalty regime from the prototype but that doesn't fit with the current design, where the inherited attributes are all hidden unless 'Customise' is clicked, at which point all inherited attributes become customised. I'm not sure that this use case warrants breaking that convention - it might require a major design and UI overhaul. But ... I'll mull it over.