aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorNavid Samanghoon <nsama24@student.sdu.dk>2025-10-29 15:55:30 +0100
committerAndreas Kapp Lindquist <andkaplin05@gmail.com>2025-10-29 18:33:28 +0100
commit3bf5bfe749261d92dd3c2c21fd0fe341457e81c3 (patch)
treef15959240d4fca1596e4a4ebc1f8f59f4e4e7b89
parent48139d1c1d8f4da22a4ea474abe6f1f6aeffcaad (diff)
downloadsorter-3bf5bfe749261d92dd3c2c21fd0fe341457e81c3.tar.gz
sorter-3bf5bfe749261d92dd3c2c21fd0fe341457e81c3.zip
typo
-rw-r--r--report/report.tex4
1 files changed, 2 insertions, 2 deletions
diff --git a/report/report.tex b/report/report.tex
index 7ef00ba..8989253 100644
--- a/report/report.tex
+++ b/report/report.tex
@@ -314,10 +314,10 @@ random. We also see that Quicksort behaves as expected with a best-case runtime
of $\mathcal O(n\log n)$ when the input is random, and a worst-case runtime of
$\mathcal O(n^2)$ when the input is either sorted or reversely sorted.
-\subsection{Nonagorithmic factors}
+\subsection{Nonalgorithmic factors}
Although the asymptotic run times are caused by the algorithms themselves,
the total run times are also greatly affected by the concrete implementations
-of highly repeated functions. A good example is our old generate_output function,
+of highly repeated functions. A good example is our old generateOutput function,
which was extremely slow. This function has since been removed and exchanged with
a new approach using a buffer. The implementation looped over the sorted list and
used 4 write syscalls per coordinate: One for printing x-coordinate, one for