Computer Laboratory 01

Deadline: Mon, Feb 2, 2026 at 5pm

Before you start

For the next few labs you will writing python code. You are free to use whichever text editor and programming environment you choose. That said, the recom- mended lab IDE (Integrated Development Environment) for the python part of this course is Visual Studio Code.

You will need to install Python3 and VS Code in your computer.

  • Go to https://www.python.org/downloads/ and follow the instructions to install python for your specific Operating System (Mac, Windows, etc.)
  • Download and install VS code: https://code.visualstudio.com/download

This assignment is due at 5pm and will be turned in on gradescope.

  • The assignment is intended to be done in pairs or groups of up to 3, although you’re allowed to work on your own if you want. If you work with other people please submit a group submission on gradescope.
  • You can start the assignment before your lab period, although I recommend not getting too far – the lab TAs often have useful hints, and I don’t want you wasting too much time struggling with something that the TAs might announce in-class.
  • Please refer to the lab rules document

Introduction

This laboratory is intended as a short introduction to python for students who are already familiar with a C-style language such as C, C++, or Java. The Python syntax in this lab might go a little beyond what’s been covered in lecture formally, but should be achievable none-the-less. If you find yourself getting stuck on the python syntax – remember that this is normal.

You might find it useful to begin by planning out your program in pseudocode or a familiar programming language. Some of the steps in this code might be non-obvious, or require some problem solving, and it’s much easier to do that before struggling with the new python syntax. Having a solid plan in this way will let you focus on ONLY the translating- into-python part of this lab. Remember, it’s OK to ask the TAs for help with the python syntax, or to reference zybook or your notes for that.

Educationally, by doing this lab you should:

  1. Plan how to solve a problem before start writing code (think about the problem and how to solve it first)
  2. Write and test Python functions to solve the problem
  3. Practice the process of submitting code in this course

Before outlining the assignment itself – you should start by setting up your python environment.

Python syntax notes

Here’s some Python syntax that will help you complete this lab.

Function declarations

The python syntax for declaring a functions is as follows:

def <name>(<parameters>):
  """ docstring -- describe the inputs and outputs """
  code

Parameters are simply a list of names separated by commas (like python variables, python parameters have no type).

Here’s an example:

def is_divisible(x, y):
  """A function to check if x is divisible by y, returning a
  boolean """
  return x % y == 0

Loops

The python for loops basic syntax is as follows:

for <variable> in <something>:
  code using variable

You can also use range():

for <variable> in range(limit):
  code using variable

This loop will run limit times, with variable taking the values 0, 1, 2, . . . , limit− 1 Sometimes you want to loop from 1 up to (and including) limit. If you want to do that I recommend the following loop:

for <variable> in range(1, <limit>+1):
  code using variable

This loop will run limit times, with variable taking the values 1, 1, 2, . . . , limit

Loops in a function with parameters

Putting a loop inside a function can look like this:

def foo(something):
    for thing in something:
        code using thing

ISBN13

ISBN1 (short for “International Standard Book Number”) is a standard way to number and uniquely identify books. You’ve certainly seen ISBN13 Numbers before on books, both in barcode format, and more usefully written out in digits above or below a barcode. The ISBN standard calls for assigning each book a 13 digit number which will uniquely identify that publication from all other books. While this might sound dubiously useful on the surface, it turns out to be massively useful when working with book data in a digital form. Having a simple single standard for identifying books, free from complexities of human language, massively simplifies many digital book management systems.

An interesting property of ISBN codes (and in-fact most barcode numbering systems) is their error detection system. While barcodes can often be scanned without error on new books, used book barcodes can sometimes be scanned incorrectly, or be so broken that a human must type in the ISBN manually. When this happens if the ISBN is entered incorrectly it can cause the book to be misidentified by the system, which can lead to any number of problems in later processing. To protect against incorrectly scanned barcodes ISBNs have a check digit – the final digit of the barcode.

A 13 digit ISBN is in fact a 12-digit number. The 13th digit is not really part of the book’s unique number. Instead, the 13th digit (rightmost digit) is chosen based on the 12 other digits so that an error can be detected.

The algorithm for validating an ISBN (marking it as either valid/correct or invalid/incorrect) is quite simple:

  1. sum up all odd digits of the ISBN as sumodd
  2. sum up the even digits of the ISBN as sumeven
  3. compute total= sumodd + 3 ∗ sumeven
  4. if total is divisible by 10, then the ISBN is valid.

So the barcode \(9780306406157\) would be processed as follows:

\(sumodd = 9 + 8 + 3 + 6 + 0 + 1 + 7 = 34\) (odd position digits)

\(sumeven = 7 + 0 + 0 + 4 + 6 + 5 = 22\) (even position digits)

\(total = 34 + 22 ∗ 3 = 34 + 66 = 100\)

Since 100 is divisible by 10, we know that this is a valid barcode.

While this process may seem a bit arbitrary, it’s mathematically well-designed. This strategy is guaranteed to notice common errors such as single-digit typos, and has a 90% chance of noticing most other forms of errors. Given that this only costs us one extra digit, and a small amount of computation, this is a remarkable amount of error detection.

Formal Requirements

Broadly, your program will be required to have three things. Your submission file should:

  • be named isbn13.py (case sensitive)
  • contain a function for validating ISBNs (named check_isbn13(isbn)) which is designed to be easy for any future program to use.
  • contain a function for computing ISBN check digits (the last digit) (named make_isbn13(number))

You are required to have a comment at the top of any file you author that contains your name, and the name of any lab partners you worked with, as well as docstrings for each function.

Development description and strategies

check_isbn13(isbn)

This function should take a single integer (not a string) and return True or False to indicate if the number is a valid ISBN.

  • The return value of this function should be a Boolean, with True indicating a valid ISBN.
  • Negative numbers are not valid ISBNs
  • Numbers with more than 13 digits are not valid ISBNs (There are a few good ways to check this – I recommend thinking of this as a “numbers” problem, what’s the largest 13 digit number?)
  • We will allow numbers with fewer than 13 digits (assuming the check-digit is correct), while those are technically invalid on a book right now, it’s for a completely unrelated reason to what we’re focusing on here. – NOTE If you are processing a number with fewer than 13 digits assume digits are numbered left-to-right.
  • Your function will need to apply the algorithm listed above to check if the check-digit for a number is correct.
  • Your function is not expected to handle non-integer data. We will not test your functions with non-integer data, and it’s OK if your function crashes or otherwise “misbehaves” when given non-integer data.

How do you know when a digit is in a even or odd position? You can use the % (modulus) operator. Think about dividing a number by 2 and the remainder of this division.

make_isbn13(book_number)

This function should take a single integer (a book number) and convert it to an equivalent valid ISBN 13 (returning the new isbn13 as an integer). So for example, given the book number \(978030640615\) (12 digit book number) the make_isbn13 should return \(9780306406157\) (13 digit valid ISBN – note that the only change is adding “7” to the end.)

  • The return value and input should both be integers

  • If given a number which cannot be converted into an ISNB13 as seen, this should return -1. There are a few cases where this might happen:

    • numbers which are already 13 digits or more.

    • negative numbers

  • For valid inputs, the return value should always start with the same digits as it’s input, with one extra digit added to the end to make it a valid ISBN13.

  • There are several ways to solve this problem we’ve left this as a problem for you to solve.

    • This can be solved mathematically – think through what you can compute from the first 12 digits and how that relates to what the last digit must be to be correct.

    • If you can’t see a mathematical solution, you could also use the fact that there could only be 10 possible options (I.E. you must either add 0, 1, 2, 3, 4, 5, 6, 7, 8, or 9 to the number. One of them must be valid – you can simply try them all until you find the valid one.)

    • If you can’t find a way to approach this problem after substantial and active consideration and pencil-paper problem solving, please contact course staff. We can help guide you through problem-solving this time since it’s only Lab01, and might have some good problem-solving hints for you.

Grading

Grading on this assignment will be 50% automated tests, and 50% manual checks. The automatic tests are not always the same as the tests seen in the tester file. The point allocation is broken down as follows:

  • 8 points for turning the file in, having the right file name, the right function names, and a file that loads.
  • 24 points for check_isbn13
  • 18 points for make_isbn

The Manual grading will be 10% code style, and 40% spot-checks. The spot-checking will focus on

  • Bad approaches to the problem. This can take the form of correct solutions, but vastly over-complicated/inefficient, or cases where you coded to pass the tests, but failed to actually solve the problem as stated in this document.
  • Things that make the code anything less than a joy to read – bad variable names, problematic code duplication (especially where this could have been avoided by calling a function). Poor use of “formatting” features like newlines, whitespace, etc.

For code style, we will use the following style guidelines for this lab. Future labs may have a more restrictive style guideline (as will most workplaces).

  • Every function should have a docstring (if you are not confident you know what this is, just google it!)
  • Every file should have a comment at the top, which should say, at a minimum, your name and your partners name.
  • Variable and function names should be as descriptive as possible (clearly n and i will be accepted here as common loop variables or math variables, but c instead of count would be considered a bad variable name choice)
  • Reasonable use of whitespace – don’t spread the lines of a function out with massive whitespace, don’t use 1-space-only for indentation. That sort of thing.
  • If there are problems that actively make your code hard to read, we reserve the right to mention them, even if they are not listed here. Ultimately, code is about com- munication, if your code doesn’t make sense it’s not correct (no matter how well it runs!)
  • Code is well commented (in-line comments with # describing what the code does)

Submission

Before submitting your work:

  • Please use the tester code on canvas (lab01_tester.py), and any tests you devise on your own, to test the code and carefully check that your code is bug-free. Buggy code is worth very little in the programming community – especially if the bugs prevent it from running.
  • Make sure the file is named isbn13.py (case sensitive)
  • Make sure the that you name, and your partner’s name, are in a comment at the top of the file
  • If you and your partner are submitting one copy of the assignment – make sure whoever submits it marks their partner in gradescope itself. Please do this unless you and your partner are turning in different files.

You are only required to submit the isbn13.py file, which will be submitted through gradescope. You can submit as many times as you want, only the final submission will be considered for grading.

If you worked with a lab partner, gradescope has a way to add your partner to your submission after you submit (to show yourself as having worked in a group). We prefer you use this feature if at all possible. Not using it may lead to trouble getting credit for your work. More information on this feature can be found on gradescope’s help page on adding group members to a submission. If you worked with a lab partner, please make sure both you and your partner have a copy of the lab files for future reference.

If you finish this lab during the lab time, feel free to notify your lab TAs, and then leave early. If you do not finish this lab during the lab time you are responsible for finishing and submitting this assignment before the deadline.

Footnotes

  1. There are actually two ISBN standards, ISBN10 (the older standard) and ISBN13 (the newer standard) –we’re talking about ISBN13 here↩︎