# Lecture 1: Turn a precise problem into a running C++ program ## Input, process, output, and a first compiled run Bring one problem you can explain in plain language; we will turn it into a small, observable program. **Instructor:** [Dr. Debasish Pattanayak](https://drdebmath.github.io)

## Programming lets you hand precise thinking to a machine - A computer is fast and tireless, but it does exactly what it is told — nothing more. - Programming is writing instructions precise enough for a machine to carry them out. - One person who can program can automate calculations, control robots, test scientific models, and build tools used by millions. - In every branch of engineering and science, the people who can program get to ask bigger questions. By the end of today you will have written, compiled, and run a program of your own. The language is the tool; the skill is turning a problem into precise instructions.

## High-level languages hide the machine; low-level languages expose it | Level | You write | Example | Translated by | |---|---|---|---| | Machine code | binary instructions | `10110000 01100001` | nothing — the CPU runs it directly | | Assembly | named instructions | `mov al, 97` | an assembler | | High-level (C++, Python) | intent: names and formulas | `price = base + tax;` | a compiler or interpreter | - **Low-level:** total control and detail, but tied to one processor family. - **High-level:** readable, portable, and safer — the translator handles the machine's choreography. - C++ sits deliberately in between: high-level abstraction, with low-level control when a problem needs it.

## Each generation of languages moves work from you to the compiler - **1940s · machine code:** programs entered as raw numbers; one wrong bit meant checking them all. - **1950s · assembly and Fortran:** names replaced numbers; Fortran (1957) let scientists write formulas instead of instructions. - **1970s · C:** one portable language for systems that had needed a rewrite on every machine. - **1980s–90s · C++, Python, Java:** objects, rich libraries, and automatic memory management for much larger programs. - **2010s · Rust, Swift, Go:** compilers that prove safety properties before the program ever runs. Each era automates the previous era's manual discipline — which is why the *ideas* you learn here outlast any single language.

## Travel-time estimator A familiar question — "how long will the trip take?" — becomes the input → process → output pattern used by every program. ~~~cpp #include <iostream> int main() { double distanceKm, speedKmph; std::cin >> distanceKm >> speedKmph; double travelHours = distanceKm / speedKmph; std::cout << "Estimated hours: " << travelHours << "\n"; return 0; } ~~~ **Takeaways** - Inputs become named values. - The formula in the middle is the whole process. - Output makes the program's result observable.

## A program is a precise set of instructions a computer can execute A program leaves nothing to guess: every step is stated, in order, in a form the machine can carry out. The plan behind those steps is an **algorithm**; the program is that plan written so a computer can run it. Use the same problem-solving workflow every time you build one: 1. **Problem:** state inputs, outputs, constraints, and success. 2. **Model:** keep only the details that affect the answer. 3. **Represent:** choose state and data structures. 4. **Solve:** write precise steps; implement one at a time. 5. **Verify:** explain why they work; test boundaries. 6. **Improve:** compare clarity, safety, generality, and cost.

## A wish is not an algorithm until it has finite steps <figure class="course-meme-figure"> <img src="assets/lecture-memes/l01/algorithm-workflow.png" alt="A student turns a tangled pile of vague sticky notes into a calm three-step path from input to process to output — visual point: a compiler runs explicit steps, never an intention." width="900" height="506" loading="lazy"> <figcaption> <p class="course-meme-setup"><strong>Setup</strong> You, to the compiler: “you know what I mean.”</p> <p class="course-meme-punchline"><strong>Punchline</strong> It does not. It has never known what you mean. Write the steps.</p> </figcaption> </figure>

## The CPU executes instructions while RAM holds active state - The **CPU** executes machine instructions. - RAM holds active instructions and values temporarily. - Storage keeps files when power is off. - Binary encodes information using bits. **Abstraction** lets C++ express ideas without writing machine instructions directly.

## One line of C++ replaces a thousand hidden switches <figure class="course-meme-figure"> <img src="assets/lecture-memes/l01/hardware-abstraction.png" alt="A student calmly writes a C++ idea while a tiny CPU robot follows a long hidden trail of machine-level steps underneath the desk — visual point: C++ gives you the idea; the hardware handles the microscopic choreography." width="900" height="506" loading="lazy"> <figcaption> <p class="course-meme-setup"><strong>Setup</strong> You wrote one line of C++ and left for chai.</p> <p class="course-meme-punchline"><strong>Punchline</strong> Under the desk, the CPU is flipping a million switches to spell “Hello”.</p> </figcaption> </figure>

## main starts the program and output makes the result observable ~~~cpp #include <iostream> int main() { std::cout << "Hello, CS103!\n"; return 0; } ~~~ <code>main</code> is the entry point. Output makes the program's result observable.

## Game evolution: Output makes the first world visible | Today's concept | Exact game part enabled | |---|---| | observable output | draw one fixed Snake-and-Cleaner frame in the terminal | ~~~cpp #include <iostream> int main() { std::cout << "+-----+\n"; std::cout << "|S..*C|\n"; std::cout << "+-----+\n"; return 0; } ~~~ **Predict and verify:** write the seven visible characters in the middle row before running it. **Next unlock · L02:** replace fixed symbols with named coordinates, score, and dirt state.

## No output, no proof the program ran <figure class="course-meme-figure"> <img src="assets/lecture-memes/l01/main-observable-output.png" alt="A tiny program enters through a doorway marked by the main function and proudly turns on a visible terminal result — visual point: a program proves it ran by producing output." width="900" height="506" loading="lazy"> <figcaption> <p class="course-meme-setup"><strong>Setup</strong> It compiled. It ran. It printed nothing.</p> <p class="course-meme-punchline"><strong>Punchline</strong> A program with no output is just a very fast way to do nothing.</p> </figcaption> </figure>

## The toolchain turns source code into a testable executable Save the source as <code>hello.cpp</code>, then use the toolchain: ~~~text g++ -std=c++17 hello.cpp -o hello ./hello ~~~ - A compiler checks and translates the source. - A linker combines required compiled parts. - The executable is the program you run.

## Choose a language from the problem’s trade-offs A **programming language** makes some kinds of thinking and engineering easier than others. - **C++17 is our main workshop:** high-level libraries, visible representation, resource control, and performance for games, graphics, science, and systems. - **Rust is our modern glimpse:** ownership is checked by the compiler, preventing many memory and data-race defects before execution. - Python favors rapid exploration; JavaScript reaches the browser; other languages serve other constraints. There is no universally best language. We learn transferable models and algorithms, then choose tools from the problem.

## Names and declarations make program state readable ~~~cpp // A comment explains intent. int attempts = 0; // declaration and initialization double distanceKm = 2.5; bool laboratoryOpen = true; ~~~ An identifier names something. A declaration introduces a name and its type.

## Edit → compile → link → run → test is a reliable workflow - Every program begins with input, process, and output. - A program must be finite and precise about every step. - The CPU executes the compiled instructions. - <code>main</code> is the C++ entry point. - Edit → compile → link → run → test.

## Verify the travel-time estimator Treat the example as a small experiment. Before you leave, make the reasoning visible: - **Claim:** with inputs `120 60`, the program prints exactly `Estimated hours: 2`. - **Trace:** write each variable and its value after every line to confirm the claim. - **Boundary:** what happens when the speed is `0`? Run it and explain the result. - **Improvement:** one change that would make the program clearer or safer. ### Exit ticket Choose one problem to solve now and two to attempt in the lab: - Read a temperature in Celsius and print the Fahrenheit equivalent. - Read the length and width of a classroom and print area and perimeter. - Read three quiz scores and print their arithmetic mean.

## Explain the travel-time estimator without opening the code Explain today’s idea to a partner without opening the code: 1. State the input, output, and one rule the solution must preserve. 2. Point to the operation that makes progress or changes the state. 3. Name the first test you would run after changing the implementation. If the explanation needs “and then another unrelated thing,” split the design before you code.

## Programs become concrete when state changes are visible | Build | State and structure | Algorithmic idea | |---|---|---| | cleaning robot | grid + position + dirt | simulation and sweep | | graph cleaner | vertices + edges + visited set | BFS/DFS coverage | | object components | pixels + labels + frontier | flood fill | | shortest routes | grid/graph + queue/heap + parents | BFS and weighted search | | Snake, two representations | text/linked body + occupied cells | update loop, traversal, collision search | | multi-agent cleaner | classes + shared world | policies, allocation, graph coverage | | music and circuits | event sequences / component graph | randomized generation and optimization | These are **non-assessed previews**. Today, notice the state change and ask what the program must remember.

## One verified model can drive every view ~~~text Problem → model/state → algorithm → trace ├─ ASCII terminal animation ├─ HTML/SVG interactive view └─ modern C++ graphics window ~~~ - The **model** is the source of truth; a renderer is only a view. - A recorded trace lets every view replay the same run. - Extensions can add color, sound, controls, multiple agents, or procedural music without changing a verified core. By semester end, you should be able to explain not only *what* you built, but *why its representation and algorithm fit the problem*.

## Five lab problems that reuse today’s pattern **IC151 lab practice · 5 problems** 1. Read a temperature in Celsius and print the Fahrenheit equivalent. 1. Read the length and width of a classroom and print area and perimeter. 1. Read three quiz scores and print their arithmetic mean. 1. Read seconds and express the duration as hours, minutes, and seconds. 1. Write an IPO chart and C++ program for estimating simple interest. Reaching this set marks the lecture as studied in this browser. [Open the IC151 lab setup and batch schedule](ic151.html).

## Did you know? - ENIAC, finished in 1945, was programmed with plugboards and switches, and its first job was computing artillery firing tables. - Ada Lovelace published the first algorithm meant for a machine in 1843, for Charles Babbage's Analytical Engine, which was never built. - Fortran, released in 1957, was the first language that let scientists write formulas instead of machine instructions.

## Make a machine carry out one observable action. **Studio thread:** Demo theatre → first robot command | Ask | Today’s answer | |---|---| | **Problem** | Make a machine carry out one observable action. | | **Model** | Input describes a command; a finite process produces output. | | **Represent** | Names stand for the few values the action needs. | | **Solve** | Write an input → process → output program, then compile it. | | **Verify** | Predict the exact output; compare it with one run and one deliberate error. | | **Improve** | Rename vague steps and remove every instruction a partner cannot follow. | **Technique lens:** simulation and precise sequencing **Compare:** a fixed command list versus a rule-based cleaner (preview only)