An IT manager at a big Columbus bank (to remain anonymous) just contacted me, frantic, with a serious problem. He's hoping that someone at OU can help.
Since we just got off the phone, I thought I'd try -- as best I can -- to reconstruct our conversation in the transcript below:
IT manager: Hi, ... ermmm ..., is this Professor Stewart?
me: Yes, speaking. What can I do for you?
IT manager: I work at [anonymous bank] in Columbus, as a manager in their IT department. And, ... well ..., I have a serious problem. A serious programming problem. I was hoping someone at OU could help. Do you have a few minutes?
me: Sure, I guess. Though I'm a bit busy at the moment. Perhaps you could meet with someone at OSU instead since you're based in Columbus and they're local?
IT manager: No, it has to be someone at OU. It was OSU students that gave us this headache in the first place!
me: OK, well, why don't you just tell me what the problem is and we can go from there?
IT manager: OK, but it's a bit embarrassing. I assigned a programming problem to a couple of our summer interns, all of whom were students at OSU at the time.
I gave the interns two separate desks, on opposite sides of the IT department, and asked them to implement an interpreter for a programming language, called Python, that I read about on the internet.
I know -- it's a bit weird that I didn't just ask them to use an existing Python interpreter. The problem is, all of the software we use at [anonymous bank] has to be written in house, no exceptions. And the reason I had the two students implement the language independently, without communicating with one another, was so that we could check the implementations against each other, by running each on a bunch of test Python programs to see whether their results matched. We were hoping that we'd be able to catch bugs in the interpreters that way.
me: Sure, that all sounds pretty reasonable [except for the "all software has to be written in house" bit]. What's the problem, then?
IT manager: The problem is, we've been noticing some weird discrepancies between the two implementations of Python and we're not sure whether we've caught all the bugs, even though we've already written a lot of tests. Even worse, the summer interns are long gone and can't be contacted -- somewhat coincidentally, they've graduated and both independently moved to off-the-grid ecofarms in Hawaii.
me: I think I understand. What can OU do for you concretely?
IT manager: Here's a link to a .tgz file that includes the two binaries:
If you unpack it (using a command like tar xzvf cpython-distrib.tgz), you'll notice that it includes:
We know that there are at least 13 10 discrepancies in how the two interpreters handle Python code. We're hoping that you, or someone else at OU, can help us find them all. Will you do it? Can you help us?
me: Well, I'm pretty busy at the moment. But would it be OK if I asked some of my students to help?
IT manager: Sure!
> ssh username@oddYY.cs.ohio.edu
where YY is the lab machine number, an odd number greater than 0 and less than about 40.
Then do:> wget http://ace.cs.ohio.edu/~gstewart/courses/3200-18/hw/cpython-distrib.tgzto download the .tgz file and
> tar xzvf cpython-distrib.tgzto unpack the interpreters into the directory cpython-distrib.
To run the interpreters from within the cpython-distrib directory, you may first have to make them executable, by doing:
> chmod a+x python1 python2By the due date for the assignment, submit in Blackboard a file called
discrepancies.txtthat reports, using the template discrepancies.txt file, the discrepancies you've found along with a code example, for each discrepancy, illustrating the difference in behavior between the two interpreters.