I'm usually not in Saturdays, but tomorrow one of my senior design teams is meeting with other senior design teams from the college on a joint project. The meeting is in the Hertzberg Forensics Science Center (HDFSC) room 238 from 10:00 to noon. I can look at your work afterwards if you want to come by.  (Come to the meeting room, not my office.) The HDFSC is at the southeast corner of the campus, directly south of the campus police building. 

===================

Regarding the project on Roman Numerals.

Please be sure you understand Roman Numerals. You should be able to explain to me how Roman Numerals encode values without looking at the code, and you should be able to convert an arbitrary Roman Numeral to Arabic on your own -- also without looking at the code. You should be able to explain how the conversion works.

As I've said a number of times, the primary objective of the course is for you to understand the material, not to convince me that you can manipulate it without understanding. You cannot claim to understand software if you don't understand the input the software is operating on. That's true even if you understand every step the software takes. You still do not understand the software itself.

As an illustration consider this sentence composed by Noam Chomsky 60 years ago: Colorless green ideas sleep furiously. Chomsky composed the sentence as an example of a sentence that was syntactically valid but semantically meaningless. You can understand every word in the sentence, you can tell me the syntactic structure of the sentence and the syntactic role played by each work. Nonetheless, you can't tell me what the sentence as a whole means. (You can't tell me what it means because it doesn't express a coherent thought.)

The programs we examine are coherent. It is up to you to understand them in the entirety, not just piece by piece.

For the Roman numerals program-, and for all the other programs we discuss, you should be able to tell me:

• the strategy the program is following,
• why that strategy works, and
• how the program implements the strategy.

===================

The credit card problem should convert a String to a Bool.

isValid :: String -> Bool

It does not take an Integer (or an Int) as input. The input is a String of characters, presumably all of which are digits.

Don't worry about the length of the credit card number.  Don't invalidate an input if it's not 16 characters. But be sure to double the correct digits -- every other digit starting from the last digit on the right. Use that rule whether the input has an even or odd number of digits. For example, whether the input is 1234567 or 234567, the digits to be doubled are 2, 4, and 6 in both cases.