Fun With Rounding Errors

I love xkcd cartoons. I came across this one thing morning that shows the benefits(?) or rounding up.

My immediate idea was “what a great programming project!”  One of the first “hello world” type of exercises I often assign is simple conversations. Fahrenheit to centigrade, miles to kilometers, etc. This is a step beyond that but with a difference. The difference is rounding up and its effect on accuracy.

This is a good program to use to introduce rounding in general but to also talk about how rounding errors can have a large impact when they occur over and over again.

This example uses velocity but I can imaging there are interesting results with weights, simple distances, and almost anything else that normally requires better than integer accuracy. Currency anyone? I’m thinking about trying that one because it involves money.

It might be interesting and educational to try the difference between rounding normally, always rounding up, and always rounding down.

What do you think? Anyone doing something like this? Would it be useful?

Troubles with Error Messages

Error messages, in theory, are there to help programmers. Of course there are problems with then in practice. With students, the biggest problem is that  they don’t read the messages. I’ve long ago lost count of the times a student told me they had an error but can’t tell me what it is (or was) because they closed it without reading it.  Getting students to read the message and to try to work out the problem themselves can be a struggle but one we have to attempt.

Even if they do read the message, messages are not always clear. Have you seen this poem?

Roses are red
Violets are blue
Missing {
at Line 32

Seems simple enough but that can be deceiving. Often the message doesn’t actually give the right line. The reasons for this can be complicated for a beginner, or even an experienced programmer, to understand. It is a constant source of frustration.  At least one knows that a missing curly brace is (probably) the problem even if we are not really sure where it is missing from.

Other messages are less helpful because the programmer lacks knowledge to understand the words being used.  Or the message just does a poor job of explaining the problem.

Why are error messages less than helpful? Many reasons. One is that error messages are not fun and interesting to write. There are also strict limitations on the number of characters allowed. Still another is that the person writing the message is often so familiar with the software and the error that they write something that, while meaningful to them, is somewhat opaque to people newer to the software.

Reading error messages is not just a problem for students of course. When I was doing technical support for professional developers I would regularly get calls asking to explain an error message. A little secret here – a good explanation could often be found in the documentation! More than once I just looked up a message and read from the documentation. Even the explanation in the documentation needs a little help sometimes but it is a great place to start.

When teaching beginners we don’t often spend a lot of time on error handling which means we don’t spend much time talking about writing good error messages.  We do ask students to write messages in programs about games over and winning and losing. Occasionally we have to suggest rather strongly that an error message that calls the user “an idiot” is perhaps not appropriate.

Perhaps we should spend a bit more time on error handling and as part of that talk about good error messages. Maybe if we had beginners talking about the error messages they see from their systems and how they could do better we;d get better error messages later when (if) they turn professional?

Regardless, I think error messages should be a bigger part of the conversation. Reading them, researching what they mean, and thinking about how they could be done better.