layout: post title: “Linear Algebra Example” date: 2025-06-10 categories: [blog] —

📘 Lineær Algebra – Eksamen 2025

1. Hvordan multiplicerer man to matricer? Hvilke størrelser skal de to matricer A og B have, så at deres produkt AB er defineret? Lille eksempel på det, fx 3×2-matrix gange to-dimensionelt vektor.

To matricer

kan multipliceres, hvis antallet af søjler i $A$ er lig med antallet af rækker i $B$. Produktet

bliver da en matrix i $\mathbb{R}^{m \times p}$.

Eksempel:

2. Gælder altid AB = BA, hvis A og B begge er n×n-matricer? (Nej, oftest ikke!)

Nej, matrixmultiplikation er ikke kommutativ. Dvs. generelt gælder:

Undtagelser: Det kan dog gælde, hvis:

• ( A = I ) (identitetsmatrix)
• ( A ) og ( B ) er diagonale og kommuterer
• ( A ) og ( B ) er potenser af samme matrix

3. Hvad sker, når man ganger matricen A fra venstre eller højre med identitetsmatricen I af den tilpasse størrelse? (Ingenting, man får bare igen A.)

Hvis \(A = \mathbb{R}^{m \times n} \quad \text{og} \quad I\) har passende størrelse, så gælder: \(IA = A \quad \text{og} \quad AI = A\)

4. Hvor mange løsninger kan et lineært ligningssystem Ax = b i princippet have?

Et lineært system kan have:

• Ingen løsning (inkonsistent)
• Én entydig løsning
• Uendeligt mange løsninger

5. Hvordan kan man undersøge, om Ax = b har løsninger og i givet fald finde dem?

Brug Gauss-elimination til at omskrive systemet til trappeform.

• Tjek om systemet er konsistent
• Brug tilbageindsættelse for at finde løsninger, hvis systemet har løsninger

6. Hvad er totalmatricen tilknyttet Ax = b?

Den totalmatricen er matrixen dannet ved at sætte højresiden $b$ sammen med koefficientmatrixen $A$:

7. Hvilke elementære rækkeoperationer kender du?

1. Ombytning af to rækker
2. Multiplikation af en række med en ikke-nul konstant
3. Lægge en multiplum af én række til en anden

8. Hvad er en trappeform og hvad er specielt ved en reduceret trappeform?

Trappeform:

• Alle nullerækker nederst
• Første ikke-nul element i en række (pivot) er længere til højre end i rækken ovenfor
• Pivotelementet er ofte 1

Reduceret trappeform:

• Alle pivotelementer er 1
• Alle andre elementer i pivot-søjlerne er 0

9. Hvordan kan man aflæse fra en trappeform af totalmatricen, om systemet er løseligt eller ej, og hvor mange løsninger man har hvis systemet er løseligt? Hvordan kan man se, om en variable er fri? Hvordan kan man bestemme løsninger ud fra en trappeform, hvis systemet er konsistent?

• Hvis der er en række som $0 = d$, hvor $d \neq 0$: ingen løsning
• Hvis antallet af pivot-søjler $<$ antal variable: fri variable
• Brug tilbageindsættelse til at finde løsninger

10. Kan du bringe følgende totalmatrix på trappeform?

Løsning (Gauss-elimination):

1. Byt række 1 og 2
2. Brug række 1 til at eliminere elementet i række 2
3. Fortsæt til trappeform

Resultatet (trappeform):

11. Hvad betyder det, at en matrix er på reduceret trappeform?

En matrix er i reduceret trappeform, hvis:

• Den er i trappeform
• Alle pivotelementer (første ikke-nul elementer i hver række) er 1
• Alle andre elementer i pivot-søjlen er 0

Det gør det nemt at aflæse løsninger direkte.

12. Hvordan kan man løse Ax = b vha. reduceret trappeform?

1. Sæt den totalmatricen op: $[A \mid b]$
2. Brug Gauss-Jordan elimination for at opnå reduceret trappeform
3. Aflæs løsningen:
   • Hvis systemet er entydigt løst: én løsning
   • Hvis fri variable: uendelig mange løsninger, skriv som parameterudtryk

13. Hvor mange løsninger har systemet Ax = 0?

Systemet $Ax = 0$ har altid mindst én løsning: den trivielle $x = 0$

Antal løsninger afhænger af rangen:

• Hvis rang $A = n$: kun triviel løsning
• Hvis rang $A < n$: uendelig mange løsninger

14. Hvornår har systemet Ax = 0 kun den trivielle løsning?

Hvis matrix $A \in \mathbb{R}^{m \times n}$ har fuld søjlerang, altså $\text{rang}(A) = n$, så har systemet kun løsningen:

15. Hvordan defineres rangen af en matrix?

Rangen af en matrix $A$ er antallet af lineært uafhængige rækker (eller søjler).

= antallet af pivot-elementer i trappeformen

16. Hvad siger sætningen om rang og løsning af systemet $Ax = b$?

Systemet $Ax = b$ er løseligt hvis og kun hvis:

Hvis løsningen findes, og $\text{rang}(A) = n$: entydig løsning
Hvis $\text{rang}(A) < n$: uendeligt mange løsninger

17. Giv eksempler på vektorer i $\mathbb{R}^n$

Eksempel på en vektor i $\mathbb{R}^3$:

Det er blot en kolonne med 3 reelle tal.

18. Hvordan defineres lineær kombination af vektorer?

En lineær kombination af vektorer $v_1, v_2, \dots, v_k \in \mathbb{R}^n$ er:

hvor $a_i \in \mathbb{R}$

19. Hvornår siges en mængde af vektorer at være lineært afhængige/uafhængige?

• Afhængige: En vektor kan skrives som lineær kombination af de andre
• Uafhængige: Ingen vektor kan skrives som lineær kombination af de andre

Formelt:
\(a_1 v_1 + \dots + a_k v_k = 0 \quad \Rightarrow \quad a_1 = \dots = a_k = 0\)

20. Hvad er søjlerummet for en matrix?

Søjlerummet (column space) for matrix $A \in \mathbb{R}^{m \times n}$ er:

= mængden af alle lineære kombinationer af søjlerne i $A$

21. Hvordan udregner man determinanter af 2×2 og 3×3-matricer?

• 2×2 matrix:

• 3×3 matrix:

Brug sarrus-reglen eller kofaktorudvikling:

22. Hvad betyder kofaktorudvidelse?

Kofaktorudvidelse (Laplace-udvikling) betyder at bestemme determinanten af en matrix ved at:

• Udvikle langs en række eller søjle:

hvor $A_{ij}$ er undermatricen uden række $i$ og søjle $j$.

23. Hvad sker med $\det(A)$, når man bytter to rækker eller søjler?

• Når man bytter to rækker eller søjler i $A$, så ændrer determinanten fortegn:

24. Hvad sker med $\det(A)$, når man lægger et multiplum af én række til en anden?

• Determinanten ændrer ikke værdi:

Gælder også for søjler.

25. Hvad gælder for determinanter under transponering og multiplikation?

• \[\det(A^T) = \det(A)\]
• \[\det(AB) = \det(A) \cdot \det(B)\]

26. Hvis $A$ er inverterbar, hvad er $\det(A^{-1})$?

Fordi:

27. Antag at $S$ er symmetrisk og inverterbar. Vis at $S^{-1}$ også er symmetrisk.

Hvis $S = S^T$, og $S$ er inverterbar:

• Tag transponatet:

• Altså: $S^{-1} = (S^{-1})^T$, dvs. symmetrisk

28. Hvad er en ortogonal matrix $U$?

En kvadratisk matrix $U$ er ortogonal, hvis:

Det betyder, at søjlerne i $U$ er ortonormale.

29. Er produktet $U_1 U_2$ af to ortogonale matricer igen ortogonal?

Ja!

• Hvis $U_1$ og $U_2$ er ortogonale:

Altså er $U_1 U_2$ ortogonal.

30. Hvad forstår vi ved en linearkombination af vektorerne $v_1, …, v_k$?

En linearkombination af vektorer $v_1, …, v_k$ er:

Det er en måde at danne nye vektorer ud fra givne vektorer.

31. Hvad er $\text{span}{v_1, \dots, v_k}$?

Det er mængden af alle linearkombinationer af $v_1, \dots, v_k$:

Span er altså et underrum bestående af alle vektorer, man kan danne ved linearkombination.

32. Hvornår siger vi, at vektorerne $v_1, \dots, v_k$ er lineært uafhængige?

De er lineært uafhængige, hvis:

Dvs. den eneste linearkombination, der giver nulvektoren, er den trivielle.

33. Hvad er et underrum $V \subseteq \mathbb{R}^n$?

Et underrum $V$ er en delmængde af $\mathbb{R}^n$, som opfylder:

• $0 \in V$
• Lukket under addition: $u, v \in V \Rightarrow u + v \in V$
• Lukket under skalering: $c \in \mathbb{R}, v \in V \Rightarrow c \cdot v \in V$

34. Hvad er nulrummet til en givet matrix $A$?

Nulrummet er mængden af løsninger til $Ax = 0$:

Det er et underrum af $\mathbb{R}^n$.

35. Hvad er søjlerummet til en givet matrix $A$?

Søjlerummet er mængden af alle linearkombinationer af søjlerne i $A$:

Det er et underrum af $\mathbb{R}^m$, hvor $A$ er $m \times n$.

36. Hvad er rang af en matrix?

Rangen af $A$ er dimensionen af søjlerummet:

Det er også antal ledende 1-taller i en reduceret trappeform.

37. Hvad er en basis af et underrum $V \subseteq \mathbb{R}^n$?

En basis er en mængde vektorer:

• Som spænder over $V$
• Som er lineært uafhængige

38. Hvad kan man sige om søjlerne i en inverterbar $n \times n$-matrix?

De danner en basis for $\mathbb{R}^n$:

39. Hvornår er to vektorer $v$ og $w$ ortogonale?

Hvis deres indre produkt er 0:

40. Hvad er formlen for den ortogonale projektion af (x) på (\text{span}{v_1, \dots, v_k}), hvis de er ortogonale?

Projektionen (P x) er givet ved:

Gælder kun hvis (v_j)‘erne er parvist ortogonale (ortogonal mængde).

41. Hvad er en ortonormalbasis af (\mathbb{R}^n)?

En ortonormalbasis er en basis hvor vektorerne både er

• Ortogonale: $v_i \cdot v_j = 0$ for $i \neq j$
• Normerede: $|v_i| = 1$

Dvs. vektorerne er ortogonale og har længde 1.

42. Hvad kan man sige om søjlerne i en ortogonal (n \times n)-matrix (U)?

Søjlerne i (U) danner en ortonormalbasis for $\mathbb{R}^n$

Det betyder også:

43. Hvad er en egenværdi af en (n \times n)-matrix (A)?

Et tal (\omega), sådan at der findes en ikke-nul vektor $v \in \mathbb{R}^n$ med

Vektoren $v$ kaldes en egenvektor til egenværdien $\omega$.

44. Hvordan kan jeg bestemme egenværdierne af (A)?

Egenværdierne er nulpunkterne til det karakteristiske polynomium:

Løsning af denne ligning giver egenværdierne $\omega$

45. Hvad er egenrummet af $A$ til egenværdien $\omega$?

Egenrummet er mængden af alle egenvektorer til $\omega$ plus nulvektoren:

46. Hvordan kan jeg bestemme egenvektorer $v$ til egenværdien $\omega$?

Løs det homogene ligningssystem:

Alle løsninger $v \neq 0$ er egenvektorer til $\omega$.

47. Hvornår kaldes en $n \times n -matrix A$ diagonaliserbar?

Hvis den er similær med en diagonal matrix $D$, dvs. hvis der findes en inverterbar matrix $P$, så

48. Hvis $A = P D P^{-1}$ er en diagonalisering af $A$, hvad er indgangene i $D$ og $P$?

• Diagonalen i $D$ indeholder egenværdierne til $A$.
• Søjlerne i $P$ er egenvektorer til $A$, i samme rækkefølge som egenværdierne i $D$.

49. Er alle kvadratiske matricer diagonaliserbare?

Nej, ikke alle er diagonaliserbare.

50. Hvornår er en kvadratisk matrix (A) diagonaliserbar?

Hvis og kun hvis for hver egenværdi stemmer den algebraiske multiplicitet overens med den geometriske multiplicitet.

51. Hvad ved man om symmetriske matricer?

En symmetrisk matrix $S$ er altid diagonaliserbar — faktisk er $S$ endda ortogonalt diagonaliserbar, dvs. der findes en diagonal matrix $D$ og en ortogonal matrix $U$ sådan at

(hvor $U^T = U^{-1}$, fordi $U$ er ortogonal).

52. Hvad er en mindste kvadraters løsning til $Ax = b$?

En vektor $\hat{x}$, sådan at

Dvs. $\hat{x}$ minimerer den kvadrerede afstand mellem $b$ og $A x$.

53. Hvordan kan man bestemme mindste kvadraters løsninger?

$\hat{x}$ er mindste kvadraters løsning til $Ax = b$ hvis og kun hvis $\hat{x}$ løser normalligningen:

54. Er mindste kvadraters løsninger entydige?

Ikke altid. De er entydige hvis og kun hvis $A$ har fuld rang, eller ækvivalent hvis $A^T A$ er inverterbar.

55. Hvornår giver det mening at bruge mindste kvadraters metoden?

Når man ikke har nogen grund til at tro, eller ikke er sikker på, at det oprindelige system $Ax = b$ er konsistent.

56. Hvad, hvis jeg udregner en mindste kvadraters løsning $\hat{x}$ til et system $Ax = b$, som faktisk er konsistent?

Så er enhver mindste kvadraters løsning $\hat{x}$ også en almindelig løsning til $Ax = b$, dvs.

57. Hvad er et lineært programmeringsproblem på kanonisk form?

Maksimer

under bibetingelserne

58. Hvordan kan bibetingelser som $a_i^T x \geq b_i$ eller $a_i^T x = b_i$ omskrives i et lineært programmeringsproblem på kanonisk form?

• $a_i^T x \geq b_i$ omskrives som $-a_i^T x \leq -b_i$
• $a_i^T x = b_i$ omskrives som to uligheder: $a_i^T x \leq b_i$ og $a_i^T x \geq b_i$

59. Hvad, hvis man vil minimere $c^T x$: kan man stadigvæk opstille et lineært programmeringsproblem på kanonisk form?

Ja, minimere $c^T x$ kan omskrives til maksimering af $-c^T x$.

60. Kender du to situationer, hvor man ikke finder en optimal løsning til et lineært programmeringsproblem?

1. Feasibility set $F$ er tomt (ingen løsninger).
2. $c^T x$ er ubegrænset på $F$ (ingen maksimum).

61. Hvis $F$ ikke er tom og $c^T x$ er begrænset på $F$, hvor i $F$ ligger de optimale løsninger?

Mindst én optimal løsning findes i et ekstremalpunkt (hjørnepunkt) af den konvekse mængde $F$

62. Skitser mængden $F$ af alle vektorer $x = (x_1, x_2)$, der opfylder

Hvilke punkter i $F$ ville du afprøve som mulige optimale løsninger i den grafiske metode?

Svar: De mulige optimale løsninger ligger i hjørnerne af $F$:

63. Hvordan opstiller man en initial simplextableau (begyndelsessimplextableau) for et lineært programmeringsproblem på kanonisk form?

• Tilføj slack-variabler for at omskrive uligheder til ligheder.
• Antal slack-variabler svarer til antallet af uligheder.
• Objektfunktionen tilføjes som sidste række i tableau.

64. Beskriv algoritmen i simplexmetoden i tilfælde, hvor alle indgange i $b$ er positive!

• Vælg indgangsvariabel (variabel med mest negativ koefficient i objektfunktionen).
• Bestem udgangsvariabel via minimum ratio test.
• Udfør pivotering.
• Gentag indtil ingen negative koefficienter i objektfunktionen.
• Optimal løsning aflæses i tableau.

65. Kan man gøre noget, hvis $b$ har en eller flere negative indgange?

Ja, man kan bruge en “big M” metode eller to-fase simplex til at starte med en basisløsning.

66. Hvad er det duale problem til et lineært programmeringsproblem på kanonisk form?

Hvis primalproblemet er

så er det duale problem

67. Hvad er udsagnet af dualitetssætningen om lineære programmeringsproblemer samt deres duale problemer?

Hvis primalproblemet har en optimal løsning, så har dualproblemet også en optimal løsning, og deres optimale værdier er ens:

Desuden, hvis enten primal eller dual har ubegrænset løsning, så er det modsatte problem ufeasible.

layout: post title: “Linear Algebra Ordbog” date: 2025-06-10 categories: [blog] —

LIAL, Ordliste

Dansk-Engelsk

A

afbildning

map, transformation
En regel eller funktion der “flytter” en vektor fra ét rum til et andet – fx ved rotation, skalering eller forskydning.

B

basisskift

change of basis
Når man udtrykker vektorer i en ny basis, f.eks. fordi det forenkler en beregning eller tilpasser til en ny geometri.

bijektion

one-to-one correspondence, bijection
En funktion hvor hvert input svarer til ét unikt output, og hvert output dækkes.

bijektiv funktion

one-to-one correspondence, bijection
En funktion der både er injektiv (ingen gentagelser i output) og surjektiv (alle outputs bruges).

bijektiv

bijective
En egenskab ved funktioner: både injektiv og surjektiv, altså perfekt match mellem input og output.

billede

image
Alle de vektorer man får ud efter en afbildning – altså resultatet af at transformere hele definitionsmængden.

billedmængde

range (se også værdimængde)
Det sæt af outputs en funktion faktisk rammer, ofte et underrum af kodomænet.

D

definitionsmængde

domain
Alle de inputværdier man må give til en funktion – altså hvor funktionen er defineret.

delmængde

subset
En mængde hvor alle elementer også findes i en større mængde.

determinant

determinant
Et tal der fortæller om en matrix skalerer, spejler eller vender rummet – fx hvor meget et areal/volumen ændres.

diagonaliserbar

diagonalizable
En matrix er diagonaliserbar hvis den kan omskrives til en diagonal matrix vha. en basistransformation.

diagonalisering

diagonalization
Processen med at omskrive en matrix til en diagonal form, ved hjælp af egenværdier og egenvektorer.

dimension

dimension
Antallet af uafhængige retninger i et rum – fx 2 i et plan, 3 i rum. Også antal basisvektorer.

disjunkte

disjoint
To mængder er disjunkte, hvis de ikke har noget til fælles – deres fællesmængde er tom.

dispositionsmængde

codomain
Alle mulige outputværdier som en funktion kan antage – ikke nødvendigvis alle bliver ramt.

E

echelonform

echelon form (se også trappeform)
En matrix er i echelonform, hvis dens rækker “trapper ned” med nuller foran, og pivoterne står til højre for den ovenstående.

element

entry
Et enkelt tal eller værdi i en matrix eller vektor – også kaldet en indgang.

egenrum

eigenspace
Alle egenvektorer (og deres linearkombinationer) der hører til en bestemt egenværdi – altså rummet af løsninger til ((A - \lambda I)x = 0).

egenvektor

eigenvector
En vektor som ved transformation kun bliver skaleret, ikke ændret retning – opfylder (Av = \lambda v).

egenværdi

eigenvalue
Tallet (\lambda) som fortæller hvor meget en egenvektor skaleres ved transformation.

endelig

finite
Betyder at noget har et begrænset antal elementer eller størrelse – modsætning til uendelig.

F

foreningsmængde

union
Mængden af alle elementer fra to (eller flere) mængder – alt der optræder mindst én gang.

fællesmængde

intersection
Det som to (eller flere) mængder har til fælles – altså de overlappende elementer.

G

Gauss-elimination

Gaussian elimination
En metode til at omskrive et ligningssystem eller matrix til trappeform ved rækkeoperationer, for nemmere løsning.

H

heltal

integer
Et tal uden decimaler – både positive, negative og nul: …, -3, -2, -1, 0, 1, 2, 3, …

hoveddiagonal

main diagonal
Elementerne fra øverste venstre hjørne til nederste højre i en kvadratisk matrix – de hvor række- og søjleindeks er ens.

I

identitetsmatrix

identity matrix
En kvadratisk matrix med 1’ere på hoveddiagonalen og 0’er ellers – fungerer som “1” i matrixmultiplikation.

indgang

entry
Et andet ord for et element i en matrix eller vektor.

indre produkt

inner product
Et mål for “længde og vinkel” mellem to vektorer – i Rⁿ svarer det til prikproduktet.

injektiv

injective, one-to-one
En funktion er injektiv hvis hvert output stammer fra ét unikt input – ingen gentagelser.

inverterbar

invertible (se også invertibel)
En matrix der har en omvendt (inverse) matrix, så (A^{-1}A = I). Kun muligt hvis determinanten er forskellig fra nul.

invertibel

invertible (se også inverterbar)
Samme som ovenfor – betyder at transformationen kan “rulles tilbage”.

K

kanonisk basis

standard basis
En basis bestående af enhedsvektorer – fx ([1,0,0], [0,1,0], [0,0,1]) i R³.

karakteristisk ligning

characteristic equation
Ligningen (\det(A - \lambda I) = 0) som bruges til at finde egenværdier.

karakteristisk polynomium

characteristic polynomial
Polynomiet (\det(A - \lambda I)), hvis rødder er egenværdierne.

kofaktor

cofactor
Et tal man får ved at tage determinanten af en mindre matrix (minor), ganget med ((-1)^{i+j}).

kofaktorudvidelse

cofactor expansion
En metode til at beregne determinanter ved at ekspandere langs en række eller søjle med kofaktorer.

koordinatvektor

coordinate vector
En vektor der viser, hvordan en vektor er sammensat ud fra en valgt basis.

korollar

corollary
En sætning der følger direkte af en anden sætning eller bevis – altså en slags “konsekvens”.

L

ledende koefficient

leading entry
Den første ikke-nul værdi i en række i en matrix – bruges til at finde pivoter.

lemma

lemma
En hjælpesætning der bruges som del af et større bevis.

linearkombination

linear combination
En sum af vektorer ganget med skalarer – fx (2v_1 + 3v_2).

lineær (u)afhængig

linearly (in)dependent
Vektorer er uafhængige hvis ingen kan skrives som kombination af de andre – ellers er de afhængige.

lineær (u)afhængighed

linear (in)dependence
Egenskaben af et vektorsæt – om det er muligt at udtrykke én som en kombination af de andre.

M

mindste kvadraters metode

method of least squares
En metode til at finde den bedste (mindst fejlagtige) løsning til et overbestemt system – f.eks. i regression.

underdeterminant

minor
Det man får ved at fjerne én række og én søjle fra en matrix og tage determinanten af det resterende.

mængde

set
En samling af unikke elementer – fx {1, 2, 3}.

N

nullitet

nullity
Dimensionen af nulrummet – altså hvor mange frie variable der er i løsningen af (Ax = 0).

nulrum

null space
Mængden af alle vektorer (x) der opfylder (Ax = 0). Et underrum af definitionsmængden.

nulvektor

zero vector
En vektor hvor alle indgange er nul – længde 0 og ingen retning.

P

pivotindgang

pivot entry
Den første ikke-nul værdi i en række i en matrix – bruges til rækkeoperationer og trappeform.

pivotsøjle

pivot column
En søjle der indeholder en pivot – typisk en vigtig søjle ifm. løsning af ligninger.

R

rang

rank
Antallet af uafhængige rækker eller søjler i en matrix – afgør matrixens “styrke”.

regulær matrix

invertible matrix
En matrix der har en invers – kun mulig hvis rang = antal rækker (fuld rang).

række

row
En vandret linje i en matrix.

rækkereduktion

row reduction
Processen med at bruge rækkeoperationer til at bringe en matrix på echelonform eller reduceret echelonform.

S

skalarprodukt

scalar product
Et tal man får ved at tage indre produkt af to vektorer – bruges fx til projektion og vinkelberegning.

singulær matrix

singular matrix
En matrix der ikke har en invers – typisk fordi determinanten er 0.

spænd

span
Alle mulige linearkombinationer af et vektorsæt – definerer et underrum.

standardbasis

standard basis (se også kanonisk basis)
De vektorer der peger i én og kun én retning – fx ([1,0], [0,1]) i R².

surjektiv

surjective, onto
En funktion hvor hvert output i kodomænet bliver ramt af mindst ét input.

sætning

theorem
En matematisk påstand der er blevet bevist ud fra aksiomer og tidligere sætninger.

søjle

column
En lodret linje i en matrix.

søjlerum

column space
Mængden af alle linearkombinationer af en matrix’ søjler – samme som billedmængde.

T

totalmatrix

augmented matrix (se også udvidet koefficientmatrix)
En matrix der indeholder både koefficienter og resultatled fra et ligningssystem.

transponering

transpose
Man bytter rækker og søjler i en matrix – altså spejler over hoveddiagonalen.

trappeform

echelon form (se også echelonform)
En form hvor nuller er flyttet ned og til venstre i matrixen – giver trinvis struktur.

triangulær matrix

triangular matrix
En matrix hvor alle elementer under eller over hoveddiagonalen er nul – enten øvre eller nedre triangulær.

triviel løsning

trivial solution
Den simple løsning (x = 0) til ligningen (Ax = 0).

U

uendelig

infinite
Ikke endeligt – noget uden grænse, fx en uendelig løsningsmængde.

udvidet koefficientmatrix

augmented matrix (se også totalmatrix)
En matrix der inkluderer både koefficienterne og resultatleddene fra et ligningssystem.

undermatrix

submatrix
En mindre matrix man får ved at fjerne rækker og/eller søjler fra en større matrix.

underrum

subspace
Et rum inden for et større vektor rum, som også opfylder regler for lukkethed under addition og skalering.

V

vectorspænd

vector span
Alle mulige linearkombinationer af et givet vektorsæt – definerer hvilket rum de “udspænder”.

værdimængde

image/range (se også billedmængde)
Det sæt af outputværdier som en funktion faktisk rammer – samme som billedmængde.

INNHABIT is an Entry-Exit-Tracking system, monitoring every entrance at AAU INNOVATE via Computer Vision, then sending Entry/Exit events to a Central Aggregation Server.

Goal of Networking for INNHABIT

• Send Entry/Exit events from Jetson to Aggregation Server
• Store Entry/Exit events for further analysis
• Update setting on Jetson remotely from Aggregation Server
• Serve a Web Dashboard for detailed statics
• Serve focused statics to existing digital signage

Jetson Internal architecture

The software of the Jetson implement multiple threads each having a class and task assigned.
A simplifyed thread description and diagram can be seen below:
The figure shows all main threads and the shared resourses between them. The main program flow is a follows

• FrameCapturer Thread Captures frames from camera and adds them to frameQueue
• Detection Thread Takes frames from frameQueue, runs ML and tracking, calls Api Handler Thread if Entry/Exit is detected. Adds image with detection and tracking to displayQueue, runs ML and tracking, calls Api Hander Thread if Entry/Exit is detected. Adds image with detection and tracking to displayQueue.
• Display Thread Takes frames from displayQueue and dispays them to either an attached monitor, x11 forwarding session, or RTSP stream.
• DevicePoller Thread uses Api Handler Thread to poll Aggregation server for updated settings
• Api Handler Thread handles all network communication, takes request/events from a queue, ensuring no event is skipped cause of other events stalling.

Sending Entry/Exit events

An Entry/Exit event is sent everytime it is detected that a person has entered or exited. The sending of these event is handled by a dedicated thread ApiHandler.
The flow of such and event can be seen below: The Jetsons installed are only be connected to via Wi-Fi. This makes deployment more flexible and reduces installation costs.
The Jetsons are connected to a Word-Wide-Web connected network, seperate from eduroam. Bypassing alot of issues caused by the security system around eduroam. The Jetsons uploads Entry/Exit events via HTTPs to the Aggregation server hosted with the DNS adress INNHABIT.dk. The Jetsons uses libcurl for sending HTTPs PUT request to INNHABIT at designted API endpoints.

API endpoints for Jetson

For handling the all API events the Jetsons software has a dedicated thread and class ApiHandler. ApiHandler works of a queue of API events ensuring no events are missed or stalls the system. libcurl is designed to simplify the integration of HTTPs, and the code for contruction and sending a HTTPs request with JSON body is seen below.

#ApiHandler:sendPostRequest

json ApiHandler::sendPostRequest(const std::string& endpoint, const json& data) {
    struct curl_slist* headers = nullptr;
    headers = curl_slist_append(headers, "Content-Type: application/json");

    std::string auth_header = "Authorization: Bearer " + api_key_;
    headers = curl_slist_append(headers, auth_header.c_str());

    std::string full_url = base_url_ + endpoint;
    curl_easy_setopt(curl_, CURLOPT_URL, full_url.c_str());

    std::string data_str = data.dump();
    curl_easy_setopt(curl_, CURLOPT_POSTFIELDS, data_str.c_str());

    curl_easy_setopt(curl_, CURLOPT_HTTPHEADER, headers);
    std::string response;
    curl_easy_setopt(curl_, CURLOPT_WRITEFUNCTION, writeCallback);
    curl_easy_setopt(curl_, CURLOPT_WRITEDATA, &response);

    long http_code = 0;
    CURLcode res = curl_easy_perform(curl_);
    curl_easy_getinfo(curl_, CURLINFO_RESPONSE_CODE, &http_code);

    json result;
    if (res == CURLE_OK) {
        if (http_code >= 200 && http_code < 300) {
            try {
                result = json::parse(response, nullptr, false);
                if (result.is_discarded()) {
                    ERROR("Failed to parse response as JSON");
                    result = json();
                } else {
                    last_api_success_ = true;
                }
            } catch (const json::parse_error& e) {
                ERROR("Parse error: " << e.what());
                result = json();
                last_api_success_ = false;
            }
        } else {
            ERROR("HTTP error: " << http_code << " - Response: " << response);
            result = json();
            last_api_success_ = false;
        }
    } else {
        ERROR("CURL error: " << curl_easy_strerror(res));
        result = json();
        last_api_success_ = false;
    }

    curl_slist_free_all(headers);
    return result;
}

The HTTP request contructed from this example looks something like:

POST /api/v1/events/entries/ HTTP/1.1
Host: innhabit.dk
Authorization: Bearer <GoodEncryptedKeyForSpecificEntrance>
Content-Type: application/json

{
  "timestamp": "2025-05-29T12:34:56Z"
}

With a HTTP POST request sent to the server, what then happens when it’s recieved?

Aggregation Server

The internal architecture is run inside a Docker network with multiple containers handling different parts of the system.
The Docker network can be seen below: All arrows a bi-directional As can be seen on the image above, the Docker network consists of 4 containers described below:

NGINX

NGINX can be seen as the front end of the system, being the only container able of direct communication with clients. INGINX servers client with all static resourses such as HTML and Images, thenpasses request to Gunicorn if any logic needs to be handles, such as permissions or dynamically updating charts.

Gunicorn / Django

Gunicorn is where the brain of the Webserver is hosted, Gunicorn hosts a Django Webserver and then handles communication between IGINX and Django. Django then handles database communication and all dynamic content on the Webserver. Some of the dynamic sites is mainly the admindashboard and insights page seen below:

PostgreSQL

PostgreSQL is the database used for storing all the Entry/Exit events, it is hosted in its own docker container for easy integration, and communicates with Gunicorn. The database is contructed with Multiple tables which can be seen on the Figure Below:

Valkey

Valkey is a key/value datastore used to store password API keys, valued for its security and easy integration with Django and Gunicorn. The API keys generated, as shown in the figure below, consist of an easy-to-read identifier, a prefix to distinguish the key, and a secret 64-character long key that is randomly generated. This randomness is why salting is not necessary.

SP1

Hvad er det primære formål med opportunity identification processen og hvad er de vigtigste output? Beskriv/eksemplificer hvordan man kan udføre processen.

En del af frontend, der er forkel på vores ide og en opportunity, Ide er en impulse, opportunity er markeds tilpasset.
En god opportunity skal overkomme en kvalitets barrier.
Disse opportunities kan komme internt eller eksternt fra.
Opprtunity horizons. Hensyn til Computeren
Horizont 1 = Små forbedringer
Horizont 2 = nye løsninger / teknologier, eller ramme et andet marked, som til børn.
Horizont 3 = Innovative løsninger, Iphone, Homeassistant, Computeren.

Step by step
Tragt formet, tournament
Step 1: Innovation Charter, / catagori
Balance mellem katagori størrelse og begænsning og overskuelighed.
Step 2: Idea Generation
Undersøge konkurrenter, nye teknologier, snakker med kunder, studerer markedet, find ulemper med nuværende product.
Step 3: Screen Ideas Fjern urimelige ideer, er dette faktisk muligt.
Step 4: Uddyb gode ideer Undersøge similare produkter, estimere markedet, hvordan kan dette egentligt udføres, små prototyber.
Step 5: Select Candidates
Sammenlign mellem criterier, og kan vi faktisk lave dette.
Output
Key product features, business goals.

Hvad ved jeg at jeg ikke ved, og hvad ved jeg

Er det radikalt nye produkter altid det bedste mål? Hvad er fordelen og ulempen ved radikalt nye produkter?

Ikke udnyttet marked, dyrer løsning / mere udvikling / Høj risiko, ikke bevidst marked.

SP2

Hvad kan vanskeliggøre indhentningen af customer needs? Hvorfor er indhentningen af disse et særligt vigtigt step i produktudviklingsprocessen?

Det er vigtigt at vide hvad kunderne har brug for, da i sidste ende er det kunderne der bestemmer om produktet skal have success.
Men det kan være svært da kunder ikke altid ved hvad de vil have, og hvem er dine kunder egentligt
Sætter udgangspunkt for kravspecifikationen.
4 steps Step 1 Gather Raw data
Intervies, focus grupper, observering a customers(Xbox kinect), Surveys
Der er forskel på kunder, den gennemsnitlige og elite kunder. Jeg er elite bruger af min laptop. Pas på elite brugerne. Brand loyalty. Interview guide, hvad er miljøet, go with the flow, hver objektiv, probs. Man får customer statements
Step 2 Interpret Data
Det vi gjorde efter at have snakket med christoffer. Omskrive og fortolke kunde statements til hvad produktet kan. Undgå løsnings mode. Undgå must and should. Ikke filtrer endnu.
Step 3 Organise Needs
Grupper statements, og sorter data. Ikke fjern modsigende statements endnu.
Step4 Prioritise Needs
Prioriter på baggrund af hvor mange gange det er blevet sagt.

Hvilke andre interessenter kunne være relevante at indhente krav til produktet fra? Hvordan vil du gøre det?

Konkurrenter(Hvad kan konkurrenterne), desk study, Lego, kunden er forældre, barn er bruger. Butikker og resellers, Hvad mener vi selv mangler intern

SP3

Hvilke typer af modularitet findes der for en modulær produktarkitektur? Giv et par eksempler fra konkrete produkter.

Platform modularitet. Noget produkter deler kan udvikles for sig selv. F.eks VW elbil platform, så batterierne er ens. AMD’s Chiplets, som bruges i alle produkter, fra bærbar til server. Fuldt modulær. Semi modulær (smartphones er godt eksempel) Integral. Helt integreret.
Slot-Modular (Smarphone) Ting kan connect 1 sted på det samlede produkt.
Bus-Modular (server/desktop er lidt begge) Alt forbindes til et samlet punkt / ens interface.
Sectional-Modular (Google tingen) Alle moduler er independent, Lego, ting kan stables.

Er en modulær produktarkitektur altid en fordel? Er det tilfælde hvor en integreret arkitektur er en fordel? Giv gerne eksempler.

integreret architecture kan give et “bedre” ende produkt, men kan komme med udviklings udfordringer. Men samtidigt kan modulær arkitektur gøre alle delene extra specialle da alle ikke behøver et overblik over hele løsningen. Mindre produkter. Modulær giver et formt for overhead, ligesom Object orienteret også kan gøre. eksempel (Ram slots er modulære, men har højere latens og laver clock speeds). Fordel er at man kan nemt customize til bestemt cusomer.

SP4

I kurset har vi anvendt en ”screening & scoring” matrix til at udvælge et endeligt koncept. Hvad er styrken ved denne metode? Hvad kunne alternative metoder være til at vælge et koncept?

Et godt koncept men dårligt udført kan være sucess, men dårligt koncept er altid dårligt.
Del produktet op i funktioner / behov(Bilen interrior behøves ikke at hænge sammen med motoren).
Blackbox, Input & output, og hvad sker der så i denne kasse?.
Hvordan bliver dette i kassen så gjort, teknisk specifikt. Undersøg eksiterende løsninger, snak med experter, undersøg specifikke technologier.
Undersøg internt, technologisk, og brug de egenskaber gruppe medlemmerne har.
Disse koncepter kan så blive valgt ved screening & scoring.
steps = Prepare matrix - Rate - Rank - Combine(Merge nogle gode ting man opdager undervejs) - Select:
Tag udgangpunkt i 1 koncept, sæt til lig 0, og sammenlign anre koncepter i forhold til dette.
Nu kan vi vægte værdierne, og derfor prioritere.
Scoring og vægtning kan hurtigt vægte ting mod preferrencer.
Det er vigtigt at have tænkt over vægtende, og ikke ændre vægtende for at prioritere andet produkt.
Kræver en god analyse af features, og krav.
På dette tidpunkt kan det være svært at vurdere hvad man bør scorer de forskellige koncepter.
Alternativ, Vi begyndte at arbejde på forskellige ting samtidigt, og løbende estimere løsninger.

Hvad kunne du gøre for at øge troværdigheden af de enkelte scorer i matrixen?

Understøtte dem med kilder og argumentationer, eller basere dem på customer needs undersøgelser.
Få kunder til at score koncepterne, og give deres mening på det.

SP5

Hvad er fordelene ved at følge en struktureret metode til produktudvikling? Hvad risikerer man ved ikke at gøre det?

Man risikerer at man ender ud med et produkt der ikke lever op til kravene, eller ikke har nogle kunder.
mere… SP5 – Struktur i produktudvikling Hvad er fordelene ved at følge en struktureret metode til produktudvikling? Hvad risikerer man ved ikke at gøre det?

Fordele:

Målrettethed og fokus – En struktureret metode sikrer, at man arbejder mod klart definerede mål, såsom kundebehov, tekniske krav og forretningsmål.

Tids- og ressourceeffektivitet – Ved at følge faser som behovsanalyse, konceptudvikling, prototype og test undgår man spildarbejde.

Bedre kommunikation i teamet – Struktur giver et fælles sprog og forventningsafstemning i tværfaglige teams.

Dokumentation og læring – Man skaber sporbarhed og mulighed for evaluering og forbedring til fremtidige projekter.

Kundecentrering – En god metode (f.eks. Stage-Gate, V-model eller Ulrich & Eppinger) inkluderer kundebehov i processen, hvilket øger chancen for succes på markedet.

Risici ved ikke at følge en struktureret metode:

Udvikling af et produkt uden marked (ingen efterspørgsel).

Fejl og omarbejdning pga. manglende kravspecifikationer.

Manglende integration mellem delsystemer.

Uklare roller og ansvar → dårlig teamkoordinering.

Projektet løber løbsk i tid og budget. ### Hvad er nogle af de største faldgrupper som produktudviklingsteam i forbindelse med processen? Tech-demoer i stedet for rigtige produkter
– Fokus på teknologi frem for brugerbehov. Det kan føre til, at man laver noget "smart", som ingen har brug for.

Springe behovsanalysen over
– Mange teams går direkte til løsning, uden at forstå kundens egentlige problemer. Det fører ofte til forkerte løsninger.

Dårlig kravspecifikation
– Uklare eller ikke-prioriterede krav giver konflikt senere i projektet, især ved test og implementering.

Ingen iterativ test og feedback
– Man udvikler hele produktet uden at teste det løbende. Så opdager man fejlene for sent og må redesigne.

Manglende involvering af relevante interessenter
– Hvis marketing, produktion eller kunder ikke inddrages, kan man ende med et produkt der er svært at sælge eller producere.

For lidt dokumentation
– Uden tilstrækkelig dokumentation kan man ikke overlevere viden, og fremtidig vedligehold bliver svær.

Scope creep
– Projektets mål udvides hele tiden uden kontrol, så man mister fokus og overskrider budget og tid.

Del 2: Kravsspecifikation og system design.

SP6

Hvad er et use case diagram? Hvilke elementer består det af? Hvad bruger man det til? Hvornår anvender man use case diagrammer? Tegn eller vis eksempel/eksempler.

Hvad er et use case diagram?

Et use case-diagram viser aktører (brugere eller andre systemer) og deres interaktioner (use cases) med systemet. Det beskriver funktionerne (use cases), som systemet skal levere, og hvordan brugerne interagerer med dem.
Hvilke elementer består det af?

System (grænse) – Angivet som en rektangulær boks, der indeholder use cases. Det er dét system, man beskriver.

Use case (brugssituation) – En oval der beskriver en funktion (f.eks. "Log ind", "Bestil produkt").

Aktør (actor) – En stick-figur, der repræsenterer en bruger eller andet system, der interagerer med systemet.

Relationer:

Association (linje): Forbindelse mellem aktør og use case.

Include: Angiver at en use case altid inkluderer en anden.

Extend: Angiver at en use case nogle gange udvides med en anden, fx afhængigt af betingelser.

Hvad bruger man det til?

Få overblik over funktionelle krav til et system.

Kommunikere med interessenter (brugere, kunder, udviklere).

Dokumentere brugerbehov og systemets forventede opførsel.

Analyse og design af software og interaktionsflow.

Hvornår anvender man use case-diagrammer?

Tidligt i kravspecifikationsfasen i systemudvikling.

Under analyse og design.

Når man vil visualisere brugerinteraktioner og sikre, at alle funktioner er dækket.

Som supplement til user stories og funktionelle krav ### Hvad er en use case beskrivelse? Hvad er vigtigt i en sådan beskrivelse? Hvordan relaterer disse sig til krav specifikationerne? Hvornår udarbejder man beskrivelserne? Hvem udarbejder dem? Giv eksempler. **Hvad er en use case-beskrivelse?**

En use case-beskrivelse er en tekstuel (detaljeret) beskrivelse af, hvordan en aktør interagerer med systemet for at opnå et bestemt mål. Hvor use case-diagrammer viser overblik, går beskrivelsen i dybden med trin-for-trin scenarier. Hvad er vigtigt i en use case-beskrivelse?

En god use case-beskrivelse indeholder typisk følgende elementer:  
Felt	Beskrivelse  
Navn	Kort og præcis titel (f.eks. "Log ind")  
Mål	Hvad aktøren ønsker at opnå  
Primær aktør	Den bruger eller system der initierer use casen  
Interessenter og behov	Hvem har interesse i funktionen og hvorfor  
Forudsætninger	Hvad skal være opfyldt før handlingen starter  
Efterfølgende tilstand	Hvad er opnået, hvis use casen lykkes  
Hovedforløb (normal flow)	De vigtigste trin i interaktionen  
Alternative forløb / Undtagelser	Hvad sker der, hvis noget går galt eller afviger  
Frekvens (valgfrit)	Hvor ofte use casen typisk forekommer   **Hvordan relaterer use case-beskrivelser sig til kravspecifikationer?**

Use case-beskrivelser konkretiserer funktionelle krav fra kravspecifikationen.

De fungerer som en slags bro mellem overordnede krav og teknisk design.

Gør det nemt at teste og verificere, om krav er opfyldt (basis for test cases).

Hjælper med at prioritere funktionalitet baseret på brugerens behov.

Hvornår og af hvem udarbejdes de?

Spørgsmål	Svar
Hvornår?	I krav- og analysefasen – gerne før design og kodning starter.
Hvem?	Typisk systemanalytikere, UX-designere, eller produktudviklere – ofte i samarbejde med kunden eller slutbrugere.
✏️ Eksempel på use case-beskrivelse

Use case: Bestil produkt

Mål: Kunden ønsker at bestille et produkt online.

Primær aktør: Kunde

Interessenter: Kunden (hurtig levering), webshop (salg), lager (ordrebehandling)

Forudsætning: Kunden er logget ind og har fundet et produkt.

Efterfølgende tilstand: Ordren er registreret og bekræftet.

Hovedforløb:

Kunden klikker på "Køb" på produktet.

Systemet viser kurven og totalbeløb.

Kunden klikker på "Gå til betaling".

Kunden indtaster leverings- og betalingsoplysninger.

Kunden klikker "Bekræft".

Systemet validerer oplysningerne og opretter ordren.

Kunden får bekræftelse på ordren.

Alternative forløb:

4a. Kunden vælger at betale med MobilePay.

6a. Hvis betaling mislykkes → system viser fejl og beder om ny metode. ## SP7 ### Hvad karakteriserer gode krav? Giv eksempler på gode og dårlige krav. Hvor i V-modellen finder vi hvilke typer af krav? Med hvem udarbejder vi krav og på hvilke måde sikrer vi at vi får samtlige vigtige krav med i kravspecifikationen? **Hvad karakteriserer gode krav?**

Gode krav skal være:

Kvalitet	Forklaring
Entydige	Kravet skal kun kunne forstås på én måde (ingen tvetydighed).
Testbare / Verificerbare	Det skal være muligt at afprøve, om kravet er opfyldt.
Nødvendige	Kun krav, der har reel værdi for systemet eller brugeren.
Tydelige og præcise	Ikke vage begreber som "hurtig", "let" eller "bedre".
Sporbare	Man skal kunne se, hvor kravet stammer fra (f.eks. en kundeanmodning).
Konsistente	Krav må ikke modsige hinanden.

Eksempler på gode og dårlige krav

Dårligt krav	Hvorfor dårligt	Godt krav (forbedret)
"Systemet skal være hurtigt."	Uklart, subjektivt	"Systemet skal svare inden for 1 sekund i 95 % af alle tilfælde."
"Brugeren skal nemt kunne oprette en profil."	Ikke målbart	"Brugeren skal kunne oprette en profil via en formular med maks. 5 felter."
"Appen skal være moderne."	For vag og upræcis	"Appen skal følge Android Material Design 3 retningslinjer."

Hvor i V-modellen findes kravene?

V-modellen beskriver systemudvikling som en proces, hvor hver fase på venstresiden har en tilsvarende testfase på højresiden. Krav findes på venstresiden i starten af udviklingen: Fase i V-modellen Type krav Brugerbehov (toppen) Overordnede forretnings- og brugerkrav Systemkrav Funktionelle og ikke-funktionelle krav Designkrav Tekniske specifikationer for hvordan kravene opfyldes

På højresiden verificeres kravene gennem test: systemtest, integrationstest, enhedstest – baseret direkte på kravene. Med hvem udarbejder vi krav?

Krav udarbejdes i samarbejde med:

Slutbrugere / kunder – deres behov og ønsker er fundamentale.

Forretningsanalytikere / produktledere – oversætter behov til krav.

Udviklere / arkitekter – vurderer realiserbarhed.

Testere – sikrer at krav kan testes.

UX-designere – bidrager til brugervenlighedskrav.

Hvordan sikrer vi, at vi får alle vigtige krav med?

Workshops & interviews med interessenter.

Observationer & kontekstuel analyse – se hvordan nuværende systemer bruges.

Brainstorming og kravindsamlingsteknikker (f.eks. MoSCoW, Kano).

Use cases og user stories – hjælper med at identificere funktionelle krav.

Prototyper og mockups – skaber feedback og afdækker oversete krav.

Sporbarhedsmatrix – kobler krav til test, design og forretningsmål. ### Hvilke krav har vi til vores kravspecifikation? Hvordan sikrer vi at krav til krav er opfyldt? Hvordan bruger vi krav i efterfølgende udviklingsproces? Hvordan forholder vi os til at skulle lave ændringer i krav i de efterfølgende tidsperioder i en udviklingsproces f.eks. hen mod slutningen af projektet? Giv eksempler. Hvilke krav har vi til vores kravspecifikation?

En kravspecifikation skal være:

Krav til kravspecifikationen	Beskrivelse
Komplet	Alle relevante funktionelle og ikke-funktionelle krav skal være med.
Entydig	Hvert krav skal kun kunne forstås på én måde.
Testbar	Det skal være muligt at verificere hvert krav.
Sporbar	Hvert krav skal kunne spores til kilder (behov, interessenter) og til test, design og kode.
Struktureret og prioriteret	Kravene skal være velorganiserede og eventuelt prioriteret (f.eks. MoSCoW: Must, Should, Could, Won’t).
Versionsstyret	Man skal kunne følge ændringer over tid (hvem ændrede hvad og hvornår). **Hvordan sikrer vi, at “krav til krav” er opfyldt?**

Review og godkendelse
– Gennemgå kravene med interessenter og få dem godkendt. Brug evt. checklister (f.eks. IEEE-830).

Sporbarhedsmatrix
– Kortlæg alle krav til relaterede designbeslutninger og testcases.

Brug af skabeloner og værktøjer
– Kravspecificeringsværktøjer (f.eks. Jira, IBM DOORS) hjælper med konsistens, dokumentation og versionsstyring.

Testbarhedsanalyse
– Involvér testere tidligt: “Kan dette krav testes?” Hvis ikke, skal det omskrives.

Roller og ansvar
– Tydelige ejere af kravene sikrer ansvar for indhold og ændringer.

Hvordan bruger vi krav i den efterfølgende udviklingsproces?

Kravene er fundamentet for hele udviklingsprocessen:
Procesfase	Brug af krav
Design	Udviklere og arkitekter bruger krav til at beslutte systemets struktur og komponenter.
Implementering	Kode baseres på funktionelle krav.
Test	Testcases laves ud fra krav (accepttest, systemtest).
Verifikation og validering	Bruges til at afgøre, om det udviklede system matcher krav og behov.
Dokumentation og overlevering	Krav dokumenterer, hvad systemet skal kunne – bruges til support og videreudvikling. **Hvordan håndterer vi ændringer i krav sent i udviklingsforløbet?**

Ændringer sker ofte – men sent i processen er de dyrere og risikofyldte. Sådan håndteres det:

Change Request-proces
– Formaliseret måde at foreslå, evaluere og godkende ændringer.

Impact analysis
– Hvad påvirker ændringen? Tid, test, funktionalitet, afhængigheder? Dette vurderes før godkendelse.

Sporbarhed
– Man kan hurtigt identificere, hvilke komponenter og testcases der berøres.

Kommunikation
– Informér hele teamet om ændringer (dev, test, design, kunde).

Agile eller iterativ udvikling
– Hvis muligt: arbejd i iterationer, så krav kan justeres løbende med mindre risiko.

Eksempler på ændringer i krav og deres konsekvenser
Ændring i krav Konsekvens Håndtering “Brugeren skal kunne betale med MobilePay” tilføjes sent Integration med ny betalingsgateway → ekstra udvikling og test Change request, teknisk vurdering, planjustering
Ændring af svartid fra 2 sek til 0.5 sek Kræver optimering af backend og database Reprioritering af performancefokus, evt. delvis opfyldelse
Krav om at systemet skal virke offline Ændrer hele arkitekturen Overvej version 2, lav business case for værdi/kost

SP8

Hvordan deler man effektivt krav op i funktionelle moduler? Hvad definerer et modul? Hvad kan vi bruge modulariseringen til? Giv eksempler, gerne på tavle.

Hvordan deler man krav op i funktionelle moduler?
Grundidé:

Du opdeler systemet i mindre funktionelle enheder (moduler), som hver især dækker ét specifikt område af funktionaliteten. Metode:

Identificér hovedfunktioner / use cases
– Hvad skal systemet kunne?

Gruppér relaterede krav
– Krav, der hører sammen funktionelt, samles.

Opdel efter ansvar og grænseflader
– Hvert modul skal have et klart ansvar og minimalt overlap.

Overvej brugerroller og systemaktører
– Hvad har forskellige brugere brug for at gøre? Dette guider opdelingen.

Hvad definerer et modul?

Et modul er:
Egenskab	Forklaring
Afgrænset funktionelt område	Løser én tydelig opgave (f.eks. "Brugerhåndtering")
Indeholder relaterede krav og funktioner	F.eks. "Login", "Opret bruger", "Nulstil adgangskode"
Har en veldefineret grænseflade (API eller UI)	Moduler kommunikerer gennem veldefinerede kald eller skærme
Kan udvikles og testes uafhængigt	Gør teams mere effektive og reducerer kompleksitet

Hvad kan vi bruge modularisering til? Fordel Beskrivelse
✅ Overblik Krav bliver lettere at forstå og styre
✅ Genbrug Moduler kan genbruges i andre projekter
✅ Parallelt arbejde Teams kan arbejde på forskellige moduler samtidigt
✅ Fejlisolering Fejl lokaliseres hurtigere
✅ Ændringer bliver lettere Ændringer i ét modul påvirker ikke hele systemet
✅ Skalerbarhed Systemet kan lettere vokse med nye funktioner

Hvad er en grænseflade? Hvordan bliver man enig om en grænseflade? Hvem er involveret i at definere grænseflader? Hvilke fordele/ulemper er der ved at definere grænseflader tidligt/sent i et projektforløb? Giv eksempler

Typer af grænseflader:

Type	Eksempel
Teknisk grænseflade	API mellem backend og frontend
Fysisk grænseflade	Stikforbindelse, skærm, knap
Brugergrænseflade (UI)	App-skærmbilleder, menuer, formularer
Procesgrænseflade	Overlevering mellem to teams eller systemer i et workflow **Hvordan bliver man enig om en grænseflade?**

Identificér behov og afhængigheder
– Hvad har de to parter brug for fra hinanden?

Samarbejde og kommunikation
– Design, software, hardware, test og brugerrepræsentanter skal involveres.

Brug specifikationer og diagrammer
– Brug f.eks.:

    Interface-specifikationer (API-dokumenter, wireframes)

    Sekvensdiagrammer, I/O-skemaer

Prototyper og mockups
– Visualisering af interaktion hjælper parterne med at forstå grænsefladen.

Hvem er involveret i at definere grænseflader?

Rolle	Bidrag
Systemarkitekt	Fastlægger overordnede tekniske grænseflader
Softwareudviklere	Definerer f.eks. API’er mellem komponenter
Hardwareudviklere	Ved fysiske grænseflader (sensorer, knapper, porte)
UX-designere	Ved brugergrænseflader (UI)
Testere	Sikrer at grænsefladen kan testes og valideres
Kunder/brugere	Ved brugerinteraktion eller systemintegration
⏱️ Fordele og ulemper ved tidlig/sen definition
Timing	Fordele	Ulemper
Tidlig	- Gør parallel udvikling muligt
- Giver klar struktur
- Giver testmuligheder tidligere	- Risiko for ændringer senere
- Kan låse fast i et forkert design
Sen	- Mere viden og erfaring
- Bedre tilpasning til reelle behov	- Forsinker udvikling
- Skaber afhængigheder og flaskehalse
- Øget risiko for misforståelser **Eksempler** **Teknisk eksempel (software):**

Et API mellem en webshop-frontend og backend:

    Grænsefladen definerer kald som: GET /products, POST /checkout

    Frontend- og backendteams arbejder parallelt, fordi grænsefladen er defineret tidligt

Fysisk eksempel (produktdesign):

En elektrisk motor med en standardiseret stikforbindelse til styring:

    Grænsefladen er stiktypen + datasignaler

    Motor og styringsmodul kan udvikles hver for sig

Brugergrænseflade:

En app har et loginmodul, som leverer brugerinfo til resten af systemet

    UI og backend skal blive enige om: Hvilke felter vises? Hvad sendes?

Del 3: Implementering og test

SP9

Hvad er kodestil og kodestruktur? For hvem er dette vigtigt? Hvad har I gjort i jeres projekt? Hvordan bliver man enige om f.eks. brug af white space eller tab’s? Giv eksempler på forskellige kodestilarter der kan øge læsevenligheden, og eksempler på det modsatte (der mindsker læsevenligheden).

Hvad er kodestil og kodestruktur? Kodestil

Kodestil handler om hvordan koden ser ud – det visuelle og sproglige udtryk. Det dækker fx:

Brug af indrykning (tabs vs. spaces)

Navngivning af variabler og funktioner (camelCase, snake_case)

Brug af mellemrum og linjeskift

Kommentarstil og placering

Placering af {} i funktioner og kontrolstrukturer

Eksempel på to forskellige kodestile i JavaScript:

// Kodestil 1 (kompakt, men lidt sværere at læse)
function add(a,b){return a+b;}

// Kodestil 2 (mere læsbar)
function add(a, b) {
  return a + b;
}

Kodestruktur

Kodestruktur handler om hvordan koden er organiseret logisk:

Filstruktur (mappestruktur)

Moduler og komponenter

Funktionsopdeling (små, genanvendelige funktioner)

Separation of concerns (logik adskilt fra præsentation og data)

Eksempel:

projekt/
├── controllers/
│   └── userController.js
├── models/
│   └── userModel.js
├── routes/
│   └── userRoutes.js
└── app.js

For hvem er dette vigtigt?

For hele teamet: Giver fælles sprog og færre misforståelser.

For fremtidige udviklere: Koden bliver nemmere at vedligeholde.

For review og samarbejde: Gør kodegennemgang hurtigere og mere effektiv.

For test og debugging: En ensartet stil gør det nemmere at finde fejl.

💬 Hvordan bliver man enige om stil (fx tabs vs. spaces)?

Læg fælles retningslinjer fra starten:

    Brug fx Google Style Guide, Airbnb JS Guide, PEP8 (Python) osv.

Automatisér med linters og formateringsværktøjer:

    Eksempler: ESLint, Prettier, Black (Python), clang-format

Lav en README.md eller CONTRIBUTING.md med stilregler

Brug Git pre-commit hooks til at tjekke stil før kode pushes

✅ Eksempler på god kodestil (læsevenlig)

def calculate_total(price, tax_rate):
    """Calculate total price including tax."""
    return price * (1 + tax_rate)

Klar funktion

Gode navne

Kommentar (docstring)

Lige mellemrum

❌ Eksempler på dårlig kodestil (ulæselig)

def ct(p,t):return p*(1+t)

Dårlige navne

Ingen mellemrum

Ingen kommentar

Alt på én linje kamelCase, navngivning, function størrelse, nasa's krav. Vi havde både python og C++, python blev tjekket via github action, c++ var mere skrevet så det man skrev lignede det der allerede stod. Manglede generelt måske lidt konsistens. ### Hvad er objekt orienteret programmering? Hvad er en klasse i forhold til et objekt? Hvad er et klassediagram? Tegn gerne et simpelt et på tavlen og diskuter ud fra det tegnede diagram. **Hvad er objektorienteret programmering (OOP)?**

Objektorienteret programmering er en programmeringsparadigme, hvor man strukturerer kode omkring objekter, som repræsenterer ting, begreber eller enheder i virkeligheden. Nøgleprincipper i OOP:

Princip	Forklaring
Indkapsling	Data og funktioner gemmes sammen i objekter
Arv	En klasse kan arve egenskaber fra en anden
Polymorfi	Objekter kan opføre sig forskelligt, selvom de deler samme interface
Abstraktion	Skjuler kompleksitet og viser kun nødvendig information **Hvad er en klasse og et objekt?**
Begreb	Forklaring
Klasse	En skabelon eller blueprint for at lave objekter
Objekt	En konkret instans af en klasse med sine egne data

Eksempel i Python:

class Dog:               # Klasse
    def __init__(self, name):
        self.name = name

    def bark(self):
        print(f"{self.name} says woof!")

my_dog = Dog("Fido")     # Objekt (instans af klassen)
my_dog.bark()            # Output: Fido says woof!

Hvad er et klassediagram?

Et klassediagram er en grafisk måde at vise klasser og deres relationer på. Det er en del af UML (Unified Modeling Language) og bruges i designfasen. Klassediagrammet viser:

Klasser

Attributter (datafelter)

Metoder (funktioner)

Relationer mellem klasser (arv, association, komposition osv.)

Tegn et simpelt klassediagram på tavlen Eksempel: Et system med Person og Student

+————–+ | Person | +————–+ | - name | | - age | +————–+ | + greet() | +————–+ ▲ | inherits | +————–+ | Student | +————–+ | - studentID | +————–+ | + study() | +————–+

Forklaring:

Person er en superklasse

Student arver fra Person

Student har en ekstra attribut og metode

greet() findes i Person og kan bruges af Student ## SP10 ### Hvad er white boks test? Hvornår anvender vi white boks test og i hvilke sammenhæng. Hvad er en path test og hvorfor er en 100% path testing stort set altid umulig at gennemføre? Tegn et flowgraph diagram på tavlen og forklar hvad en branch test er **Hvad er white-box test?**

White-box test (eller strukturtest) er en testmetode, hvor man tester et programs interne struktur og logik. Man kigger ”ind i koden” og bruger sin viden om, hvordan programmet er bygget. Formålet:

Teste alle logiske grene og kontrolstrukturer

Sikre at alle veje i koden fungerer som forventet

Afsløre fx:

    Ubrugte kodelinjer

    Fejl i loops og betingelser

    Forkert håndtering af kanttilfælde

Hvornår bruger man white-box testing – og i hvilke sammenhænge? Bruges typisk ved Eksempler
Unit testing Test af enkeltfunktioner
Integration testing Når moduler integreres og man vil teste flow mellem dem
Ved kritisk kode F.eks. sikkerhed, beregning, pengeoverførsel
Automatiseret test Fx med værktøjer som JUnit, Pytest, osv.

White-box testing bruges tidligt i udviklingen af udviklere og QA, og supplerer black-box tests (som kun ser på input/output uden at kende koden).

Hvad er path testing?

Path testing handler om at teste forskellige stier igennem et program – altså de mulige kørselsforløb gennem kontrolstrukturen.
Eksempel:

Hvis en funktion har en if-else og et while-loop, kan der være mange forskellige måder, koden kan køres på afhængigt af input.
Hvorfor er 100% path testing næsten umuligt?

Antallet af mulige stier vokser eksponentielt med antal beslutninger

Nogle stier kan være umulige at nå pga. logik

Loops med forskellige antal gentagelser giver uendelige kombinationer

Det ville kræve enormt mange testcases og være for tidskrævende

Hvad er en branch test?

Branch testing er en simplere form for path testing:

Her tester man, at alle grene (branches) i programmet bliver kørt mindst én gang

Dvs. hver if, else, case, while, osv. bliver aktiveret i en test

Branch testing sikrer, at alle beslutningspunkter i programmet testes.
Tegn et simpelt flowgraph diagram (til tavle):
Kodeeksempel:

def check(value):
    if value > 0:
        print("Positive")
    else:
        print("Non-positive")

Flowgraph diagram:

[Start] | (1) | [value > 0] /
(2) (3) | | [print P] [print NP] \ / (4) [Slut]

Forklaring:

(1): Start af funktion

(2): Gren for value > 0

(3): Gren for else

(4): Samlet slutpunkt

For branch test skal du have mindst:

    Ét test input hvor value > 0

    Ét test input hvor value <= 0 ### Hvad er debugning? Hvordan bruger man en debugger (princippet)? Hvornår bruger man en debugger? Forklar ud fra et af de tre kodestumper givet på moodle, hvordan du vil white boks teste koden. Vis gerne på laptop hvis du har den med. **Hvad er debugging?**

Debugging er processen, hvor man finder og retter fejl (bugs) i sin kode. Det kan både være syntaksfejl, logiske fejl, runtime-fejl eller uventet adfærd. Målet:

Forstå hvor og hvorfor noget går galt

Identificere årsagen og ikke kun symptomet

Lave rettelser, så koden opfører sig korrekt

Hvordan bruger man en debugger? (princip)

En debugger er et værktøj, der gør det muligt at køre koden trin for trin, observere værdier og indsætte breakpoints.
Typiske funktioner i en debugger:
Funktion	Beskrivelse
Breakpoint	Pause i koden – her stopper eksekveringen
Step over	Kører næste linje kode, men hopper over funktionkald
Step into	Går ind i en funktion og viser dens kode
Step out	Hopper ud af en funktion igen
Watch/Inspect	Se værdien af variabler live
Call stack	Viser hvilke funktioner, der er kaldt, og i hvilken rækkefølge
Debuggere findes i fx:

VS Code, PyCharm, Eclipse, Xcode

Indbygget i browserens devtools (til JS)

CLI (fx pdb i Python, gdb i C)

Hvornår bruger man en debugger?

Situation	Eksempel
Når programmet crasher uden tydelig årsag	Segfault, NoneType error
Når noget opfører sig forkert	En funktion returnerer et forkert resultat
Når man vil forstå andres eller egen kompleks kode	Trinvis analyse
Ved white-box testing	Når man systematisk tester kontrolstrukturer ## SP11 ### Hvad er en black box test? Forklar princippet bag black box tests. Er det realistisk at risikere at en komplet test skal gennemføre 10^100 kombinationsmuligheder af input værdier – hvorfor/hvorfor ikke? Antag det er, hvordan sikrer du så at testen kan gennemføres på realistisk kort tid? Argumenter for hvorfor din metode vil være bullet-proof. Ved sidste spørgsmål, tag gerne udgangspunkt i en løsning fra opgave 1. **Hvad er en Black Box Test?**

Black box test (også kaldet funktionsbaseret test) er en testmetode, hvor du tester systemets funktionalitet udefra – altså uden at kende den interne kode eller struktur.
Princippet bag black box testing

Fokus er på input og output: Giver systemet det rigtige output for det givne input?

Tester typisk:

    Funktionalitetskrav

    Brugerinteraktion

    Grænseværdier

    Fejlhåndtering **Du skriver testcases baseret på kravspecifikationen og tester, om programmet opfører sig som forventet.**     **Er 10^100 kombinationsmuligheder – realistisk?**  

Nej, det er komplet urealistisk.

Et eksempel:

Forestil dig et system der tager 100 inputfelter, og hvert felt kan have 10 værdier → 1010010100 kombinationer = mere end antallet af atomer i universet.

Så:

Det er umuligt at teste alle kombinationer

Det vil tage uendelig lang tid og regnekraft

✅ Hvordan tester vi alligevel på realistisk tid?

Ved at bruge strategiske metoder:

1. Ækvivalensklasser

   Del input i grupper, hvor du forventer samme adfærd

   Test kun én værdi pr. gruppe

🔧 Eksempel: Hvis alder skal være 18–100, så test:

Undergrænse: 17 (ulovlig)

Gyldig: 25

Overgrænse: 101 (ulovlig)

1. Grænseværditest (Boundary Value Analysis)

   Fejl sker oftest ved grænser, fx 0, 1, max

   Test fx værdier: min-1, min, min+1, max-1, max, max+1

2. Fejlspekulation / Edge cases

   Brug erfaring og viden om typiske fejl

   Eksempler: tom input, null, ekstremt store/små tal

3. Risiko-baseret test

   Prioritér test på funktioner der er forretningskritiske eller fejl-udsatte

🛡️ Argument: Hvorfor er dette “bulletproof”?

Det er ikke muligt at sikre 100% korrekthed i alle situationer, men:

✅ Disse metoder minimerer risikoen for kritiske fejl ✅ De fokuserer indsatsen på de vigtigste og mest fejl-udsatte områder ✅ De gør det muligt at teste hurtigt og effektivt med høj dækning ✅ Kombineret med white-box tests, får du både intern og ekstern testdækning 🧪 Eksempel: BubbleSort fra opgave 1

Krav:

BubbleSort skal sortere listen i stigende orden

Black box test cases: Test Case Input Forventet Output Tom liste [] [] Én værdi [5] [5] Allerede sorteret [1, 2, 3] [1, 2, 3] Omvendt sorteret [3, 2, 1] [1, 2, 3] Dobbeltværdier [2, 2, 1] [1, 2, 2]

⚠️ Bemærk: Her kender vi ikke hvordan koden er lavet (black box), men vi ved hvordan den skal opføre sig.

Hvis noget kode ser ud til at virke, er du så helt sikker? Hvordan sikrer du dig, at du også vil have den kode til at være ansvarlig for næste flytur du selv skal på? Beskriv hvordan du fandt fejlen i det kode der blev givet i opgave 2. Er du sikker på du fandt ALLE fejl? Argumenter hvorfor du er sikke

Hvis noget kode ser ud til at virke – er man så helt sikker?

Nej – aldrig.

At koden ser ud til at virke, betyder kun, at den virker i de tilfælde, du har testet den.

Men hvad med alle de utestede situationer, inputkombinationer, kanttilfælde eller fejlscenarier?

Når det handler om kritiske systemer, som fx en flyver, så er “det virker på min maskine” ikke godt nok. ✅ Hvordan sikrer man sig kvalitet og sikkerhed?

Grundig test:

    Brug både black box og white box tests

    Test grænsetilfælde, fejlscenarier, store input, tomme input, uventede input

Code review:

    Flere øjne opdager flere fejl

    Du får feedback på både logik og struktur

Statisk analyse:

    Brug værktøjer der automatisk analyserer koden for potentielle fejl (f.eks. pylint, mypy, flake8)

Formal verification (i kritiske systemer):

    Matematiske beviser for at koden opfører sig korrekt

Test coverage:

    Hvor meget af koden bliver faktisk ramt af tests? (Fx med coverage.py)

🐛 Hvordan fandt vi fejlene i opgave 2?

Vi gennemgik koden linje for linje, og:

Brugte white-box teknik til at se på intern logik

Spottede:

    Forkert abs(...) brugt i sammenligning

    Forkert initialisering og opdatering af swapped i bubble sort

    Logiske fejl i rekursiv tilgang → risiko for uendelig løkke

    Misforståelse af sorteringsretning

    Manglende input() validering

❓Er vi sikre på, at vi har fundet ALLE fejl?

Nej – men vi har reduceret risikoen betydeligt.

Vi kan ikke 100% garantere, at der aldrig er fejl. Der kan stadig være:

Edge cases vi ikke har testet

Performance-problemer på store inputs

Fejl ved flydende tal, NaN, inf, etc.

Men:

Vi har anvendt systematiske metoder

Vi har lavet grundige test og kontrol

Og vi har lavet logiske forbedringer i strukturen

Det gør os trygge ved funktionaliteten, men vi ville stadig ikke bruge det i en flyver uden meget mere test og certificering. 🧠 Konklusion

At være professionel udvikler betyder ikke at “tro” koden virker – det betyder at dokumentere og teste, indtil man ved, at den virker — i hvert fald under de definerede krav og forudsætninger.

The Maix Dock M1W is a small RISC-V based Micro-controller, with the main point of interest being the integrated NPU called KPU. The board is based around the Kendryte K210 chip, which comes with 2 64bit RICS-V cores clocked at 400MHz and a dedicated NPU. The NPU is marketed with the ability to perform 1TOPS at INT8 precision.
This makes the M1W an interresting product for low-power object detection.

The specifictions for the M1W is as follows:
With ESP32-WROOM for comparision

M1W Unboxing

I ordered the M1W from Aliexpress and it arrived in a small cardboard box with a plastic enclosure containing: the M1W itself, the 2.4 inch screen, a small camera already attached, an antenna and a USB-C to Micro-b adapter.

M1W Initial Power On

An inital power on of the M1W originally showed a welcome MaixDuino welcome message on the display, but when trying to recreate it for a picture the display only shows white

Programming on the M1W

When trying to find guides for the M1W especially for programming low-level C code, most links from official sources are either on chinese or points to non existent pages. However, Platformio has the M1W-board listed as sipeed-maix-one-dock, and is compatible with the arduino framework.
So for an easy test I wrote a simple script making the builtin led blink. SUCCESS!!!
The platformio.ini and main.cpp code can be seen below

#platformio.ini

    [env:sipeed-maixduino]
    platform = kendryte210
    board = sipeed-maix-one-dock
    framework = arduino
    upload_speed = 115200
    monitor_speed = 115200

#main.cpp

    #include <Arduino.h>

    void setup() {
        pinMode(LED_BUILTIN, OUTPUT);
        Serial.begin(115200);
        while (!Serial) {}
        Serial.println("Starting LED blink");
    }

    void loop() {
        digitalWrite(LED_BUILTIN, HIGH);
        delay(500);
        digitalWrite(LED_BUILTIN, LOW);
        delay(500);
        Serial.println("Blink!");
    }

Serial communication with M1W

Serial communication is crucial when trying to debug anything on Micro-controllers, so to make sure Serial communication is working properly I added the Serial.println(“Blink!”); to the previous code. This however did not work out of the box, when trying to monitor the serial connection via platformio device monitor nothing would show up, and the LED would stop blinking?.
After doing some research I found that the M1W possibly was entering boot/ISP mode, as if i was trying to flash new software to it. This was easily fixed by disabling DTR and RTS by adding monitor_rts = 0 and monitor_dtr = 0 to platformio.ini

K210 vs ESP32 CPU Performance

The K210s CPU is clocked alot higher than that of the ESP32, so I was curios about what the performance difference could be?
Especially with the K210 supporting FP64 and having a much larger amount of builtin SRAM. For a quick benchmarking of the boards I did a simple and mostly theoretical benchmark, measuring the time it took to do 10 million addtions, multiplications and divisions, for INT64 Float32 and Float64, on a single core, then converting the results to million operations per second. Results can be seen below, where the K210 is on average 2.5x faster compared to the ESP32.
With the K210 having FP64 implemented in hardware, and the ESP32 relying on software, it is disappointing to see that the FP64 performance isn’t much greater than that of the ESP32. This benchmark only focuses on raw performance that isn’t touching the IO.

K210 vs ESP32 Memory Performance

With the CPU performance of the K210 being impressive but still disappointing, I wanted to know how big a difference the larger SRAM capacity could have on performance. The speed of both read and write was tested by allocating a certain buffer size and written and reading from it.

As can been seen on the image above, the K210 outperforms the ESP32 by a wide margin, with write speeds being consistent up to over 5MB, were the ESP32 falls of after 110KB, because everything over that requires the ESP32 to use external RAM.

Memory Impact on Performance

The K210 has a much more fast memory to use, whick makes sense with the point of being able to do live image processing, requiring multiple frames to be kept in memory while processing. To measure the difference when running simple image manipulation tasks, square images between 128-1250 was allocated, filled with a gradiant and downscaled to quarter size. Excution times can be improved by using dedicated libraries and not relying on standard Arduino SDK.

Development with Kendryte-standalone-sdk

To Arduino framework doesn’t have access to all the feature of the M1W, to get this the Kendryte-standalone-sdk is needed. The sdk is used by default when initing a platformio project for the M1W, and the sdk can be found on github SDK Github Page with some documentation here Documentation. Most funcitons seems documented, and a simple hello world example is included in the src/ folder. Running the program writes “hello world” from both cores, with output looking like this.

Core 0 Hello world
Core 1 Hello world

Now that the Arduino framework is no longer used, the program is written in standard c, and printin via serial is a simple as:

#include <bsp.h>
#include <sysctl.h>
int main(void)
{
    printf("Hello world\n");
    return 0;
}