Creating a rubric for computer arithmetic

Question

I'd like to move to mastery-based grading and have drafted a set of rubrics for my undergraduate computer architecture class. I am having trouble with the one for computer arithmetic, which includes two's complement and IEEE floating-point formats. I have the following criteria:

• Converting between decimal and two's complement, including identifying the largest and smallest numbers
• Comparing two's complement numbers
• Understanding two's complement limitations (carry into and borrowing from the sign bit)
• Converting between decimal and IEEE floating-point formats, including identifying the largest and smallest numbers (not counting special values).
• Comparing floating point numbers
• Understanding floating point limitations (underflow, overflow, range limits, precision limits)
• Choosing best numeric representation, given range, accuracy, and performance requirements

I am concerned that there are too many critiera. (Not shown are the ratings for different levels of proficiency.) It also raises the question of how a student shows they know how to, say, convert between decimal and two's complement. Do I keep testing them until they show me one successful conversion in each direction, or do they have to demonstrate that they can consistently do so? Is this too trivial of a skill to test, given that they'll forget the details, which aren't really important, five minutes after the test?

Answer 1

I missed this question!

I will attempt to provide feedback in parts:

I am concerned that there are too many critiera.

I don't understand the reason for this concern, so I cannot comment upon it. The criteria seem reasonable to me.

It also raises the question of how a student shows they know how to, say, convert between decimal and two's complement. Do I keep testing them until they show me one successful conversion in each direction, or do they have to demonstrate that they can consistently do so?

I would personally be happy with a one-time demonstration within my own classroom (see below)

Is this too trivial of a skill to test, given that they'll forget the details, which aren't really important, five minutes after the test?

I think it's perfectly acceptable to explain to students that you are asking them to learn a skill that you expect will be temporary (converting a floating point number to IEEE) in order to help them get their heads around a deeper, more profound understanding that you hope will be permanent and intuitive (e.g. the general nature of floating point in practical computation).

In my classroom, I have students reproduce proofs with a similar explanation. I explain that, after memorizing a proof and reproducing it for me, I do not imagine that they will be able to reproduce it again 5 years later. But I expect that they will come to understand the structure of the proof well enough that the next time they encounter such a structure, they won't be immediately lost, and I also expect that they will roughly remember that the fact that they proved is, itself, true.

In this case, while none of your students will presumably remember, give years out, exactly how to figure out what the least significant bit would be in an IEEE representation, you can expect that the students will (long term!) remember the tiered nature of the IEEE structure, and the broad-strokes, general elements of what it stores.

I think those are good and sufficient goals, and I think that the students will be okay with learning it as long as you break down the expected long-term benefits of the short-term learning.