As the problem statement suggested, the input contains 80-column punch cards and the encoding used is EBCDIC.
You can read about this encoding at http://www.cs.uiowa.edu/~jones/cards/codes.html, and at http://www.kloth.net/services/cardpunch.php you can find a service that allows you to create your very own punched card images.
However, getting to the correct answer required not only decoding the information, but also a deeper knowledge of times long past.
Easy data set
In the easy input, three of the cards make sense. They contain the following text:
THE ANSWER IS EQUAL TO TWENTY THREE TIMES ONE HUNDRED AND SEVENTEEN THOUSAND
TWO HUNDRED AND ELEVEN PLUS THIRTEEN PLUS FORTY SEVEN MILLION THREE THOUSAND EIGHT HUNDRED AND FIFTY NINE |
However, the third card does not contain any useful information – and this should immediately be suspicious.
The third card is a lace card (see http://en.wikipedia.org/wiki/Lace_card). These cards usually caused the reader to jam. This is where the formulation “(most probably)” from the problem statement comes to play. If we took these four cards and feed them into a card reader, the most probable outcome would be that it reads the first two cards and then gets jammed on the third one.
Hence the text it read is just
THE ANSWER IS EQUAL TO TWENTY THREE TIMES ONE HUNDRED AND SEVENTEEN THOUSAND
TWO HUNDRED AND ELEVEN PLUS THIRTEEN PLUS FORTY SEVEN MILLION THREE THOUSAND |
giving us the answer 49698866.
Hard data set
When we decode the cards in the hard input, we get a program in Fortran:
INTEGER COUNT
COUNT = 47 COUNT = COUNT + 47 COUNT = COUNT + 47 COUNT = COUNT + 47 47 * 47 ********** AND NOW WE JUST OUTPUT THE ANSWER ********** WRITE(*,*) ’THE ANSWER IS ’, COUNT END |
Again, this program hides several nasty surprises. Getting a Fortran compiler (such as gfortran) and running it is much better than trying to understand it.
The tricks include:
Thus this program outputs 22470.