M8: numbers in C and Python

course/en/20-numbers-in-c-python.md

@@ -0,0 +1,47 @@
+# Numbers in C and Python
+
+C and Python can express the same binary and hexadecimal values, but their integer models differ substantially.
+
+## PREDICT
+
+Will `255 + 1` always behave the same way in C and Python?
+
+## STEP — literals
+
+Both languages support forms such as `0b101010`, `0x2A` and decimal `42`. In C, language type and literal rules determine the resulting type. Python `int` is not confined to a fixed 8-, 16-, 32- or 64-bit width.
+
+## C: explicit widths
+
+When machine width matters, `<stdint.h>` provides types such as `uint8_t`, `uint16_t` and `int32_t` when the implementation has suitable exact-width integer types.
+
+Unsigned C arithmetic wraps modulo (2^n) for the type width. Do not assume the same rule for signed overflow; signed integer overflow is not defined by C as ordinary two's-complement wraparound.
+
+## Python: arbitrary-size integers
+
+Python integers grow as required within practical resource limits. To model an 8-bit register explicitly, impose a width:
+
+```python
+x = (255 + 1) & 0xFF
+```
+
+The result is zero.
+
+## Shifts, masks, parsing and formatting
+
+Bitwise operations look familiar in both languages, but type widths, promotions and negative-value behavior require language-specific care.
+
+Python can parse bases with `int(text, base)` and format values with forms such as `f"{42:08b}"` and `f"{42:02X}"`.
+
+C offers conversion routines such as `strtoul`; portable formatting of fixed-width integers can use the macros in `<inttypes.h>`.
+
+## OBSERVE
+
+The source literal `0xFF` is a numeric value. Storing or interpreting it as an 8-bit signed value, 8-bit unsigned value or wider type is a separate operation.
+
+## EXPLAIN
+
+Programming languages add rules on top of bit representations. Reliable low-level code requires understanding both the machine model and the language model.
+
+## Check yourself
+
+Why does `(255 + 1) & 0xFF` produce zero in Python? Why should signed C overflow not be assumed to work the same way?

course/no/20-tall-i-c-python.md

@@ -0,0 +1,98 @@
+# Tall i C og Python
+
+C og Python kan uttrykke de samme binære og heksadesimale verdiene, men heltallsmodellene deres er svært forskjellige.
+
+## PREDICT
+
+Vil `255 + 1` alltid gi samme resultat i C og Python?
+
+## STEP — literals
+
+Begge språk støtter moderne former som:
+
+```
+0b101010
+0x2A
+42
+```
+
+I C bestemmes typen også av språkets type- og literalregler. I Python er `int` ikke begrenset til en fast 8-, 16-, 32- eller 64-bit bredde.
+
+## C: eksplisitte bredder
+
+Når maskinbredde betyr noe, er typene fra `<stdint.h>` nyttige:
+
+```c
+#include <stdint.h>
+
+uint8_t  a = 0xFF;
+uint16_t b = 0x1234;
+int32_t  c = -42;
+```
+
+Eksakt-bredde-typene finnes når implementasjonen tilbyr en heltallstype med den aktuelle bredden.
+
+Unsigned C-aritmetikk følger modulo (2^n) for typens bredde. Signed overflow må ikke behandles som om C lover samme wraparound; signed integer overflow er ikke definert på samme måte av språket.
+
+## Python: vilkårlig store heltall
+
+```python
+x = 255
+print(x + 1)   # 256
+```
+
+Python-`int` vokser etter behov innen praktiske ressursgrenser. Hvis du vil simulere et 8-bit register, må du selv innføre bredden, for eksempel:
+
+```python
+x = (255 + 1) & 0xFF
+```
+
+Da blir resultatet 0.
+
+## Shifts og masks
+
+```
+value & 0x0F
+value | 0x80
+value ^ 0x01
+value << 1
+value >> 1
+```
+
+Betydningen av høyreskift for negative verdier og effekten av promotions/typebredder må vurderes etter språket og typen. Ikke flytt maskinantakelser ukritisk mellom språk.
+
+## Parsing
+
+Python:
+
+```python
+int("101010", 2)
+int("2A", 16)
+int("0x2A", 0)
+```
+
+C bruker blant annet funksjoner som `strtoul`, der base og feilhåndtering må behandles eksplisitt.
+
+## Formatering
+
+Python:
+
+```python
+f"{42:b}"      # 101010
+f"{42:02X}"    # 2A
+f"{42:08b}"    # 00101010
+```
+
+I C brukes formatmakroer fra `<inttypes.h>` når portabel formatering av fixed-width heltall er viktig.
+
+## OBSERVE
+
+Kildekoden `0xFF` beskriver en numerisk literal. Om du senere tolker eller lagrer den som 8-bit signed, 8-bit unsigned eller en større type er en egen beslutning.
+
+## EXPLAIN
+
+Programmeringsspråk legger regler oppå bitrepresentasjonene. God lavnivåkode krever at du forstår både maskinmodellen og språkmodellen.
+
+## Sjekk deg selv
+
+Hvorfor gir `(255 + 1) & 0xFF` verdien 0 i Python? Hvorfor bør du ikke anta at signed C-overflow fungerer på samme måte?

exercises/no/09-c-python.md

@@ -0,0 +1,10 @@
+# Øvelser: tall i C og Python
+
+1. Skriv 173 som binær og hex literal.
+2. Hva er forskjellen mellom Python-`int` og `uint8_t` med hensyn til range?
+3. Hva blir `(0xFF + 1) & 0xFF` i Python?
+4. Hva blir `0xAB & 0x0F`?
+5. Hva gjør `value | 0x80` med en 8-bit verdi?
+6. Parse teksten `"11110000"` som base 2 i Python.
+7. Formater 10 som åtte binære sifre i Python.
+8. Hvorfor er det risikabelt å stole på signed overflow i C som en eksplisitt wraparound-mekanisme?

solutions/no/09-c-python.md

@@ -0,0 +1,10 @@
+# Løsninger: tall i C og Python
+
+1. `0b10101101` og `0xAD`.
+2. Python-`int` kan vokse utover en fast maskinbredde; `uint8_t` representerer verdier 0–255 når typen finnes.
+3. 0.
+4. `0x0B`.
+5. Den setter bit 7 til 1 og lar de andre bitene beholde sine tidligere verdier.
+6. `int("11110000", 2)`, som gir 240.
+7. `f"{10:08b}"`, som gir `00001010`.
+8. C definerer ikke signed integer overflow som vanlig modulo-wraparound. Kode som krever eksplisitt modulooppførsel bør bruke passende unsigned representasjon eller andre definerte metoder.