CS274: Computer Architecture - Number System Conversions (100 Points)

Assignment Goals

The goals of this assignment are:

To programmatically convert between numbers represented in base-2, base-10, and base-16
To develop appropriate unit tests for functions
To write and use a Makefile

Background Reading and References

Please refer to the following readings and examples offering templates to help get you started:

The Assignment

Purpose

This assignment builds fluency with the number systems the machine itself uses: binary, decimal, and hexadecimal. By writing the digit-by-digit conversions yourself (rather than calling a library), you internalize place value and the bit/nibble relationship between binary and hex that we will use constantly when reading instruction encodings, addresses, and memory dumps. You will also establish two habits we will rely on all semester: automating your build with a Makefile and validating each function with unit tests.

Task

Recall the approaches we used to convert between a decimal value and a binary value, and between binary and hexadecimal values.

In this assignment, you will write a program (or a series of programs) that:

allow the user to input which base they would like to convert from and to (base 2, 10, and 16),
allow the user to input a value in the base they’re converting from
convert the value to the target base

The input value should be a string that represents the numeric value; this will facilitate your looping over each digit. If desired, you may convert it to an integer data type. However, you may not use a library to convert between the bases themselves: you should do that yourself!

You may use any of several programming languages: C, C++, Java, Python, or another language if pre-approved by the instructor. You must, however, include a Makefile that compiles and runs the program. In addition, you must provide appropriate unit tests for each of your functions.

Submission

In your submission, please include answers to any questions asked on the assignment page, as well as the questions listed below, in your README file. If you wrote code as part of this assignment, please describe your design, approach, and implementation in a separate document prepared using a word processor or typesetting program such as LaTeX. This document should include specific instructions on how to build and run your code, and a description of each code module or function that you created suitable for re-use by a colleague. In your README, please include answers to the following questions:

Describe what you did, how you did it, what challenges you encountered, and how you solved them.
Please answer any questions found throughout the narrative of this assignment.
If collaboration with a buddy was permitted, did you work with a buddy on this assignment? If so, who? If not, do you certify that this submission represents your own original work?
Please identify any and all portions of your submission that were not originally written by you (for example, code originally written by your buddy, or anything taken or adapted from a non-classroom resource). It is always OK to use your textbook and instructor notes; however, you are certifying that any portions not designated as coming from an outside person or source are your own original work.
Approximately how many hours it took you to finish this assignment (I will not judge you for this at all...I am simply using it to gauge if the assignments are too easy or hard)?
Your overall impression of the assignment. Did you love it, hate it, or were you neutral? One word answers are fine, but if you have any suggestions for the future let me know.
Using the grading specifications on this page, discuss briefly the grade you would give yourself and why. Discuss each item in the grading specification.

Any other concerns that you have. For instance, if you have a bug that you were unable to solve but you made progress, write that here. The more you articulate the problem the more partial credit you will receive (it is fine to leave this blank).

Assignment Rubric

Description Pre-Emerging (< 50%) Beginning (50%) Progressing (85%) Proficient (100%)

Algorithm Implementation (50%) The program does not compile or run via the Makefile, or the conversions are performed by a library call (for example, parseInt with a radix, or int(s, base)) rather than by your own digit-by-digit algorithm The program builds and runs, prompting for the source base, target base, and input value, but produces incorrect conversions on one or more of the base-2, base-10, or base-16 test inputs due to a minor issue (for example, digits processed in the wrong order or an incorrect hex letter mapping) The program correctly converts between base 2, 10, and 16 by looping over the digits of the input string for the tested values, but would fail in a general case (for example, uppercase vs. lowercase hex digits, a value of 0, or one direction of conversion is hard-coded), or the Makefile does not both compile and run the program The program prompts for the source base, target base, and value as a string, correctly converts between any pair of bases 2, 10, and 16 by iterating over digits without using a base-conversion library, handles general cases such as 0 and hex letter digits, and includes a Makefile that compiles and runs it

Test Cases (20%) Testing was performed by hand outside of a unit test framework, or not performed at all A unit test framework is used, but only one or two trivial cases are checked (for example, a single one-digit conversion), and not every conversion function has a test Each conversion function has unit tests covering typical values, but some boundary cases or branches are untested (for example, 0, single-digit values, hex values containing letter digits, or one of the six base-pair directions) Each conversion function has unit tests covering all six base-pair directions and the boundary cases, including 0, single-digit values, multi-digit values, and hex values with letter digits, and all tests can be run from the Makefile

Code Quality and Documentation (20%) Code commenting and structure are absent, the conversion logic is a single monolithic block rather than functions, and/or the code departs significantly from the style guide Comments are sparse or restate the code (for example, "loop over the string"), and/or there are minor departures from the style guide that reduce readability The conversion logic is organized into functions with comments describing what each does, and the code mostly adheres to the style guide, but comments restate definitions rather than explaining the place-value reasoning Each conversion function is documented in terms of the algorithm (for example, how place values are accumulated or how remainders produce digits), variable names reflect their roles (base, digit, accumulator), and the code follows the style guide

Writeup and Submission (10%) An incomplete submission is provided; the readme is missing The program is submitted, but not according to the directions in one or more ways (for example, the readme is missing, or the Makefile and tests are not included in the submission) The program is submitted according to the directions with a minor omission or correction needed, and the readme describes the solution and how to build, run, and test it at least superficially The program is submitted according to the directions, including a readme that describes your conversion approach for each base pair, explains how to build and run the program and its unit tests via the Makefile, and gives thoughtful answers to any bolded questions throughout

Please refer to the Style Guide for code quality examples and guidelines.

Description	Pre-Emerging (< 50%)	Beginning (50%)	Progressing (85%)	Proficient (100%)
Algorithm Implementation (50%)	The program does not compile or run via the Makefile, or the conversions are performed by a library call (for example, parseInt with a radix, or int(s, base)) rather than by your own digit-by-digit algorithm	The program builds and runs, prompting for the source base, target base, and input value, but produces incorrect conversions on one or more of the base-2, base-10, or base-16 test inputs due to a minor issue (for example, digits processed in the wrong order or an incorrect hex letter mapping)	The program correctly converts between base 2, 10, and 16 by looping over the digits of the input string for the tested values, but would fail in a general case (for example, uppercase vs. lowercase hex digits, a value of 0, or one direction of conversion is hard-coded), or the Makefile does not both compile and run the program	The program prompts for the source base, target base, and value as a string, correctly converts between any pair of bases 2, 10, and 16 by iterating over digits without using a base-conversion library, handles general cases such as 0 and hex letter digits, and includes a Makefile that compiles and runs it
Test Cases (20%)	Testing was performed by hand outside of a unit test framework, or not performed at all	A unit test framework is used, but only one or two trivial cases are checked (for example, a single one-digit conversion), and not every conversion function has a test	Each conversion function has unit tests covering typical values, but some boundary cases or branches are untested (for example, 0, single-digit values, hex values containing letter digits, or one of the six base-pair directions)	Each conversion function has unit tests covering all six base-pair directions and the boundary cases, including 0, single-digit values, multi-digit values, and hex values with letter digits, and all tests can be run from the Makefile
Code Quality and Documentation (20%)	Code commenting and structure are absent, the conversion logic is a single monolithic block rather than functions, and/or the code departs significantly from the style guide	Comments are sparse or restate the code (for example, "loop over the string"), and/or there are minor departures from the style guide that reduce readability	The conversion logic is organized into functions with comments describing what each does, and the code mostly adheres to the style guide, but comments restate definitions rather than explaining the place-value reasoning	Each conversion function is documented in terms of the algorithm (for example, how place values are accumulated or how remainders produce digits), variable names reflect their roles (base, digit, accumulator), and the code follows the style guide
Writeup and Submission (10%)	An incomplete submission is provided; the readme is missing	The program is submitted, but not according to the directions in one or more ways (for example, the readme is missing, or the Makefile and tests are not included in the submission)	The program is submitted according to the directions with a minor omission or correction needed, and the readme describes the solution and how to build, run, and test it at least superficially	The program is submitted according to the directions, including a readme that describes your conversion approach for each base pair, explains how to build and run the program and its unit tests via the Makefile, and gives thoughtful answers to any bolded questions throughout