Project 2: Temperature Conversion

Changelog

Any relevant changes to this page after it’s released will be listed here.

• None so far.

Due date

This project is due on Wednesday, October 8th, 2025, 4:30pm ET.

You have a 15-minute buffer for any technical issues, after that you can use your project late days if needed. Please see syllabus for late days policy.

Problem

Overview

Your program will receive a temperature value, convert it to a different scale, and output it. It will support conversion between the Celsius and Fahrenheit temperature scales, as well as custom scales.

See scale conversion for the formula to do temperature conversions.

Details

You will create a file called temp.S.

First, your program will read a single byte from STDIN. This byte (x) will have an ASCII digit indicating which conversion your program should do.

• If x is '1', you will convert from ºC to ºF.
• If x is '2', you will convert from ºF to ºC.
• If x is '3', you will convert from custom scale 1 to custom scale 2.

You can assume this first byte will always be one of '1', '2', or '3'.

After this first byte, there will be a line break (\n).

Then, there will be three bytes to represent the input temperature (t). All values will have 3 digits, e.g., 002, 025, 123. There will be no negative values for input, i.e., all values you receive from STDIN will range from 000 to 999.

Note that all numerical values will be sent as 3 separate bytes, e.g., 123 will be received as '1', '2', and '3'. Your program has to combine those 3 ASCII digits into a single number for other operations.

Cases '1' and '2'

If x was '1' or '2', there is no more input to process. Your program should convert t into the appropriate scale and output the value as 3 digits as well. E.g., if the result is 77, you will output 077.

Case '3'

If x was '3', there will be more input to process.

First, a line break in STDIN (\n).

Then bytes in this format:

WFA WBA
WFB WBB

where:

• WFA is the 3-digit value corresponding to the water freezing-point for scale A
• WBA is the 3-digit value corresponding to the water boiling point for scale A
• WFB is the 3-digit value corresponding to the water freezing point for scale B
• WBB is the 3-digit value corresponding to the water boiling point for scale B

Your program should convert t from scale A to scale B and output the value as 3 digits as well. E.g., if the result is 77, you will output 077.

Exit

Finally, your program should exit with a status code of 0.

Examples

1. Celsius to Farenheit

• Input:

1
025

• Expected Output: 077

2. Farenheit to Celsius

• Input:

2
077

• Expected Output: 025

3. Celsius to Farenheit using custom scale

3
025
000 100
032 212

• Expected Output: 077

4. Celsius to Celsius using custom scale

3
025
000 100
000 100

• Expected Output: 025

5. Farenheit to Kelvin using custom scale

3
041
032 212
273 373

• Expected Output: 278

6. Custom scale to custom scale

3
050
001 050
900 999

• Expected Output: 999

Project Grading

Your code will be graded on documentation (20%) and accuracy (80%).

Documentation

The documentation score is calculated based on the ratio of comments and lines of code in your file. It is calculated in two equally-weighted parts:

(1) ratio of comment-only lines to all instruction lines

Say x is the ratio of your comment-only lines to all the instruction lines you have. The grade for this section follows the table below:

(2) ratio of instructions with inline-comments to all instructions

Say y is the ratio of your instruction lines that have inline comments to all the instruction lines you have. The grade for this section follows the table below:

Accuracy

Your code will be tested with multiple test cases. Each test case for this project is worth 1 point each, so they’re all equally weighted. All test cases for this proejct are open, so you should be able to see which ones you passed and which ones you failed when grading your code.

Submission

Grading your code

You will use webassembliss to grade your code:

• csc236-100-host.csc.ncsu.edu/grader (preferred)
• web.assembliss.app/grader

On the grader page, you will enter your full name and UnityID, and upload your temp.S solution and the temp.pb2 project configuration file.
Click here to download the project configuration file.

Important: make sure your file is called temp.S!

After filling in the page and clicking on submit, the page should take you to the grader results.

It might take a minute or so for your submission to be graded if there’s many people submitting, please do *not* refresh right away. If you get a timeout grading your code on the public instance (web.assembliss.app), try using the NCSU-restricted one as that one allows for a longer wait time for the request.

The grader results page shows you the total score your solution received, and has a button at the top that says Download file for submission. This button should let you download a file called Temp_UnityID_results.json. Here’s an example of the top of the grader results page:

The Temp_UnityID_results.json file contains your name, ID, source code, all information about the tests you passed, and your overall score. This is the file you will submit to Moodle.

If you scroll down on the grader results, it will also show you which tests you passed, with diffs for all of them. You can also see the documentation score you received.

You can resubmit your updated code as many times as you wish to the server, so you’re able to fix any bugs you have compared to the expected test cases. Whenever you’re satisfied with the grade you received, you can submit the appropriate json file to Moodle.

There are no efficienty targets for this project, you’re fine to ignore the Source Efficiency and Execution Efficiency sections of the results.

Submitting to Moodle

You will submit your Temp_UnityID_results.json to Moodle. The last json file you upload to Moodle will be the one considered for grading, and the timestamp of the last moodle submission will be considered the time you submitted your code for early/late submission policies.

Only files submitted through Moodle will be graded. The teaching staff will not accept submissions received through other channels (email, EdStem, etc.).

The teaching staff will only grade this project after no more submissions can be made (i.e., after the late submission window is closed).

Getting help

Please use EdStem and office hours! For EdStem, make sure to set your posts to private if you’re sharing code. We also have a planned project workday before this project is due, check the course schedule.

Hints

Scale conversion

To convert a temperature from scale A to scale B, you need to know:

1. the value on scale A (let’s call this T_a)
2. the water boiling point for A (let’s call this B_a)
3. the water boiling point for B (let’s call this B_b)
4. the water freezing point for A (let’s call this F_a)
5. the water freezing point for B (let’s call this F_b)

Then, you can find the equivalent temperature on scale B (T_b) with: $$T_{b} = (T_{a} - F_{a}) * \frac{B_{b} - F_{b}}{B_{a} - F_{a}} + F_{b}$$

For example:

• For ºC, water freezes at 0 and boils at 100
• For ºF, water freezes at 32 and boils at 212

Converting 25_C to F: $$T_{F} = (25 - 0) * \frac{212 - 32}{100 - 0} + 32 = 77_{F}$$

Converting 77_F to C: $$T_{C} = (77 - 32) * \frac{100 - 0}{212 -32} + 0 = 25_{C}$$

Order of implementation

There are 22 test cases for the Celsius to Farenheit conversion, 22 test cases for the Farenheit to Celsius conversion, and 10 test cases for the custom scale conversion. That makes roughly 15% of your total score dependent on the custom scale, so I’d suggest starting with the 2 base cases first, as they account for the bulk of the points.

Taking input

It might be easier to take all possible input at once and then process it later. If you ask to read more bytes than there are in the stdin input, assembliss will fill extra bytes with null characters (0-filled bytes).

Mul/Div approximations

Test cases have numbers that are small enough where multiplication operations should not overflow. Additionally, we chose input values where the expected result should be an exact number.

However, it is usually better to do all multiplications before starting divisions.

Range of I/O values

• There will be no negative values for input, i.e., all values you need to read from STDIN are in the (000, 999) range.
• There will be no negative values for output, i.e., all expected results you need to write to STDOUT are in the (000, 999) range.
• There can be intermediate values that fall outside the (000, 999) range while you do your calculations, but you are not expected to output them.