I've seen far too many tendencies to “plug and chug”, as if programming is like reading recipes from a book. This project will focus on your ability to creatively solve programs and craft algorithms, according to various constraints.

Algorithms will rely on both mathematical and logical operations.

The standard deck of playing cards (for our purposes) possesses 52 distinct cards, spread out among 4 different suits.

The suits are (in this order):

• clubs
• diamonds
• hearts
• spades

The face values on the cards are (in this order):

• Ace
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• Jack
• Queen
• King

13 face values, 4 suits, 13 x 4 = 52.

For the purposes of any programs we write, we are going to display the cards as 2- or 3-symbol strings, as such:

• 6 of Hearts: “6H”
• Jack of Spades: “JS”
• Ace of Diamonds: “AD”
• 10 of Clubs: “10C”

With the differing values used by the suits and face values (ie, by name it isn't immediately linear), you are going to need to “flatten” the data so that it can be represented by a single numeric value (ranging from 1-52).

Your task is to write a program that processes cards.

It should have a menu allowing the selection of the following functions, and to prompt the user for the appropriate input, which gets passed into the selected function, displaying the resulting output.

It is to have the following functions:

• char *num2name_if(unsigned char);
• char *num2name_tern(unsigned char);
• char *num2name_algo(unsigned char);
• unsigned char name2num_if(char *);
• unsigned char name2num_tern(char *);
• unsigned char name2num_algo(char *);

And yes, you must implement all six functions, according to their implementation requirements. Any arrays created must be compatible for use by all functions you implement (no custom array per function).

There are 2 actual functions, the num2name() and its reverse, name2num(); however, to aid in your explorations, I'd like for you to create 3 different implementations of each, restricting yourself to the following:

• _if functions make use of your standard selection statements (likely how you'd approach it by default)
• _tern functions will only make use of ternary operators (no if()/switch() statements)
• _algo functions will only make use of math/logic operations (no if()/switch() statements, no ternary operators)

You can (and should) make use of arrays.

I'd recommend 2 arrays:

• char suit[], containing the 'C', 'D', 'H', and 'S' values
  • feel free to use #define's, perhaps:
    • #define CLUB 0
    • #define DIAMOND 1
    • #define HEART 2
    • #define SPADE 4
• char face[][] (array of strings), containing the “A”, “2”, “3”, …, “8”, “9”, “10”, “J”, “Q”, “K” values (in that order)

You can use static arrays (the brackets) or dynamically allocated arrays; I'd caution against just using what you are comfortable with… you'll want to use what is best for the algorithm/program.

You should strive for optimized code, but if you can make something work by “wasting” or “skipping” an occasional space, by all means.

If we had the number 17 (out of 1-52), and we passed it to num2name(), with the specified suit ordering of Clubs, Diamonds, Hearts, and Spades, we should get: 4 of Diamonds

The actual return value from num2name() would be the string: “4D”

Another example, the number 34; we should get: “8H”

Or: 1; we should get: “AC” (Ace of Clubs)

If we had “10C”, we should get: 10

If we had “QH”, we should get: 38

If we had “6D”, we should get: 19

Remember that linearity can be of great value (especially if you cannot divert program flow with some conditional statement).

Finding ways to conveniently arrange or pack your data can make for a much, much easier implementation. But that requires planning, crafting, and maybe even a bit of creative brainstorming.

Do remember your third grade math.

Do consider making use of bitwise logic; by the way, your operators are:

• & bitwise AND
• | bitwise OR
• ^ bitwise XOR
• » logical right shift
• « logical left shift
• ~ bitwise NOT

Remember what a string is (a set of characters), what a character is (merely a number), and how a number can be expressed/manipulated.

Note the required parameter/return data types. Make sure you implement with these in mind. Type cast if necessary, but all input to (parameters) and output from (return value) your functions must be of those types.

To submit this program to me using the submit tool, run the following command at your lab46 prompt:

lab46:~/src/discrete/yol0$ submit discrete yol0 yol0.c
Submitting discrete project "yol0":
    -> yol0.c(OK) 

SUCCESSFULLY SUBMITTED

You should get some sort of confirmation indicating successful submission if all went according to plan. If not, check for typos and or locational mismatches.

To be successful in this project, the following criteria must be met:

• Project must be submit on time, by the posted deadline.
  • Early submissions will earn 1 bonus point per full day in advance of the deadline.
    • Bonus eligibility requires an honest attempt at performing the project (no blank efforts accepted)
  • Late submissions will lose 25% credit per day, with the submission window closing on the 4th day following the deadline.
    • To clarify: if a project is due on Wednesday (before its end), it would then be 25% off on Thursday, 50% off on Friday, 75% off on Saturday, and worth 0% once it becomes Sunday.
    • Certain projects may not have a late grace period, and the due date is the absolute end of things.
• all requested functionality must conform to stated requirements (either on this project page or in comment banner in source code files themselves).
• Output generated must conform to any provided requirements and specifications (be it in syntax or sample output)
  • output obviously must also be correct based on input.
• Processing must be correct based on input given and output requested
• Specification details are NOT to be altered. This project will be evaluated according to the specifications laid out in this document.
• Following are some common evaluation criteria; these may be included, enhanced, and supplemented.
• Code must compile cleanly.
  • Each source file must compile cleanly (worth 3 total points):
    • 3/3: no compiler warnings, notes or errors.
    • 2/3: one of warning or note present during compile
    • 1/3: two of warning or note present during compile
    • 0/3: compiler errors present (code doesn't compile)
• Code must be nicely and consistently indented (you may use the indent tool)
  • You are free to use your own coding style, but you must be consistent
  • Avoid unnecessary blank lines (some are good for readability, but do not go overboard- double-spacing your code will get points deducted).
  • Indentation will be rated on the following scale (worth 3 total points):
    • 3/3: Aesthetically pleasing, pristine indentation, easy to read, organized
    • 2/3: Mostly consistent indentation, but some distractions (superfluous or lacking blank lines, or some sort of “busy” ness to the code)
    • 1/3: Some indentation issues, difficult to read
    • 0/3: Lack of consistent indentation (didn't appear to try)
• Code must be commented
  • Commenting will be rated on the following scale (worth 3 total points):
    • 3/3: Aesthetically pleasing (comments aligned or generally not distracting), easy to read, organized
    • 2/3: Mostly consistent, some distractions or gaps in comments (not explaining important things)
    • 1/3: Light commenting effort, not much time or energy appears to have been put in.
    • 0/3: No original comments
    • should I deserve nice things, my terminal is usually 90 characters wide. So if you'd like to format your code not to exceed 90 character wide terminals (and avoid line wrapping comments), at least as reasonably as possible, those are two sure-fire ways of making a good impression on me with respect to code presentation and comments.
  • Sufficient comments explaining the point of provided logic MUST be present
• Code must be appropriately modified
  • Appropriate modifications will be rated on the following scale (worth 3 total points):
    • 3/3: Complete attention to detail, original-looking implementation
    • 2/3: Lacking some details (like variable initializations), but otherwise complete (still conforms, or conforms mostly to specifications)
    • 1/3: Incomplete implementation (typically lacking some obvious details/does not conform to specifications)
    • 0/3: Incomplete implementation to the point of non-functionality (or was not started at all)
  • Implementation must be accurate with respect to the spirit/purpose of the project (if the focus is on exploring a certain algorithm to produce results, but you avoid the algorithm yet still produce the same results– that's what I'm talking about here).. worth 3 total points:
    • 3/3: Implementation is in line with spirit of project
    • 2/3: Some avoidance/shortcuts taken (note this does not mean optimization– you can optimize all you want, so long as it doesn't violate the spirit of the project).
    • 1/3: Generally avoiding the spirit of the project (new, different things, resorting to old and familiar, despite it being against the directions)
    • 0/3: entirely avoiding.
  • Error checking must be adequately and appropriately performed, according to the following scale (worth 3 total points):
    • 3/3: Full and proper error checking performed for all reasonable cases, including queries for external resources and data.
    • 2/3: Enough error checking performed to pass basic project requirements and work for most operational cases.
    • 1/3: Minimal error checking, code is fragile (code may not work in full accordance with project requirements)
    • 0/3: No error checking (code likely does not work in accordance with project requirements)
• Track/version the source code in a repository
• Submit a copy of your source code to me using the submit tool (make submit will do this) by the deadline.