# Simple Modelling with Code

Computer Science I · Programming I · https://tryals.app/learn/computer-science-i/simple-modelling-with-code

## From Problem to Program

The hardest part of programming is **modelling**: deciding how to represent a real-world problem for a computer. A model is a deliberate simplification that captures what matters and ignores the rest.

Modelling follows three core steps. First, identify the **data**: what quantities and entities are involved, and what type is each?

| Entity | Data Representation | Example |
| --- | --- | --- |
| Shopping Cart | **List** | Items with prices |
| Phone Book | **Dictionary** | Names to numbers |

The right structure makes the algorithm easy; the wrong one makes it painful.

## Algorithms and Constraints

Second, define the **algorithm**: the step-by-step procedure transforming input into output. Write this in plain, structured **pseudocode** before real code to get the logic right without fighting syntax.

Third, state the **assumptions and constraints** (prices are non-negative, lists may be empty) so the program handles them properly.

**Common pitfall:** Diving straight into code before modelling. Always name your data types, sketch pseudocode steps, and then translate.

## Practice questions

5 of this lesson's 11 practice questions, with answers. The full set is in the app.

### 1. Modelling a phone book as a dictionary rather than a list of pairs changes almost nothing about what the program can do, and a great deal about what it costs. Why does the representation matter so much when the information is identical?

A. Because dictionaries use less memory than lists for the same data.
B. Because dictionaries keep the entries sorted by name, which lists cannot do.
C. Because the representation decides which operations are cheap.
D. Because a list of pairs cannot store the same information as a dictionary.

**Answer:** C. Because the representation decides which operations are cheap.

**Why:** The two hold identical information and differ in what the structure makes easy, and since lookup by name is essentially all a phone book does, the choice decides whether the program is fast at the one thing it does. Note dictionaries preserve insertion order and are not sorted, so a sorted listing needs a sort either way. Get the representation wrong and no later optimisation recovers it.

Page: https://tryals.app/practice/computer-science-i/simple-modelling-with-code/modelling-a-phone-book-as-a-dictionary-rather-than-a-list-of-pairs

### 2. Select every practice that the lesson recommends when modelling a problem.

A. State the assumptions and constraints explicitly
B. Identify the data and its type before coding
C. Sketch the algorithm in pseudocode first
D. Decide what can vary and what must hold
E. Start writing real code before deciding what the data is

**Answer:** A. State the assumptions and constraints explicitly; B. Identify the data and its type before coding; C. Sketch the algorithm in pseudocode first; D. Decide what can vary and what must hold

**Why:** Naming the data, sketching pseudocode, stating constraints, and deciding what may vary are all recommended. Writing real code before modelling is the pitfall the lesson names, it almost always produces tangled, buggy code.

Page: https://tryals.app/practice/computer-science-i/simple-modelling-with-code/select-every-practice-that-the-lesson-recommends-when-modelling-a

### 3. Choosing a fitting data representation is half the battle. Sort each quantity by the type that best models it.

**Answer:**

- A single number: A person's age, The total price of the cart
- A list: The items in a shopping cart, in order
- A dictionary: A phone book from names to numbers

**Why:** Ages and totals are single numbers; a cart's items and a class's scores are ordered lists; a phone book and id-keyed stock are dictionaries. Matching each quantity to a fitting representation is the modelling step that makes the later algorithm easy rather than painful.

Page: https://tryals.app/practice/computer-science-i/simple-modelling-with-code/choosing-a-fitting-data-representation-is-half-the-battle-sort-each

### 4. Order the steps of modelling a problem before writing real code.

**Answer:**

1. Identify the data: what quantities and entities, and what type is each
2. Define the algorithm as steps that transform input into output
3. Write those steps in plain pseudocode
4. State the assumptions and constraints the program must handle

**Why:** Name the data, design the algorithm, record it as pseudocode, and pin down the assumptions. Getting the logic right in pseudocode before real code lets you avoid fighting syntax while thinking, diving straight into code is the pitfall this lesson names.

Page: https://tryals.app/practice/computer-science-i/simple-modelling-with-code/order-the-steps-of-modelling-a-problem-before-writing-real-code

### 5. Storing money as a floating-point number is a well-known mistake. What actually goes wrong?

A. Floats are too small to hold large monetary amounts
B. Floats cannot represent numbers with two decimal places at all
C. Values like 0.10 have no exact binary form, so error accumulates
D. Float arithmetic is slower than integer arithmetic, which matters at scale

**Answer:** C. Values like 0.10 have no exact binary form, so error accumulates

**Why:** A tenth is a repeating fraction in binary, so every operation rounds and the errors accumulate across millions of transactions. Storing pence as integers makes the arithmetic exact, the choice of representation is a correctness decision here, not a performance one.

Page: https://tryals.app/practice/computer-science-i/simple-modelling-with-code/storing-money-as-a-floating-point-number-is-a-well-known-mistake