-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Calculate Sum of Rating Aspects Automatically (if possible) #200
Comments
Sorry for my ignorance: Is the „Sum of Rating Aspects“ the final grade? Or is “final grade” used for two different things (sum of points of one task, sum of points across all tasks)? Seems linke it... :-( One problem with this request is that to the Praktomat, grading scales are just abstract lists and no proper calculation is possible. It would be possible to do so on a best-effort basis (e.g. if both are numbers, and the sum is a possible value for the total score, then use that). Maybe using some simple JavaScript in the edit view. |
Example: for our final exams we create the two aspects "Methodology" (range: 0-7) and "Functionality" (range: 0-14). The sum is then, yes, the "final grade" of one task (range: 0-21). As the rating scales of the aspects (technically) could also have different granularities (1 point, half point, etc.) this really only makes sense on a best effort basis. Maybe a piece of javascript would be the best solution, but I am not aware of the true amount of flexibility of the system or whether that amount of flexibility is really necessary. But if I'm really able to define abstract rating aspects it should be possible to define an abstract operation for final grade calculation, too. It would be sufficient to just define the relation between the "rating aspects" and the "final grade". Then there could be a generator-macro for sums (just like the generator-macro for scales). |
Tricky. That would require a table with a varying number of columns (one for each rating aspect). |
Well, actually there is another possibility, but it is a bit awkward: One could flatten/distribute further and introduce a column-id. Example (Boolean 2-AND): A | B | A & B For each row we then have 3 entries: row-id, column-id, value The SELECT would be two-fold, first one needs to extract the correct row-id, next the result can be selected via row and col-id. I have the gut-feeling that this violates some db-design rule, as there is no natural index. Well, we can still introduce relation-table-entry-ids. Defining and storing each entry of a relation as an entity, while in most cases it is calculable by simple arithmetics smells a bit like overkill. Maybe still the algorithmic solution (client-side javascript) is the way to go. The third option, storing macros in the database, seems too insecure. |
Another, slightly hackish but still convenient solution would be a button in the admin interface „recalculate final score as sum of rating aspects for all selected attestations“ that would do the best-effort-thing, but server side. You’d run that once before calculating the final grade. Downside: It can be forgotten, and the tutors would still have to add up. |
Well, that is very specific. For me that'll do. If noone else uses these aspects differently and wants to add a suggestion... |
Am I right that this problem only occurs in final exams, as the regular ones do not have multiple rating scales? In that case, please remind me again once the task for the next year is set (but before the tutors start working), it is more convenient (and more motivating) for me to develop on the live data (in the mirror instance of course). Current plan:
|
As it has to be entered manually, wrong or forgotten sums are a frequent problem in tasks with many submissions (in my case >300). Btw. assisting correctors always tend to laugh about that one ;-)
The text was updated successfully, but these errors were encountered: