From e43fef5b73b74849e0f85df48a62b29be52534b3 Mon Sep 17 00:00:00 2001
From: Aria Shrimpton <me@aria.rip>
Date: Thu, 8 Feb 2024 14:39:45 +0000
Subject: some writing

---
 thesis/parts/design.tex | 26 ++++++++++++++++++++++----
 1 file changed, 22 insertions(+), 4 deletions(-)

(limited to 'thesis/parts/design.tex')

diff --git a/thesis/parts/design.tex b/thesis/parts/design.tex
index ce7fa8e..0a93836 100644
--- a/thesis/parts/design.tex
+++ b/thesis/parts/design.tex
@@ -27,10 +27,8 @@ This method works well for many operations and structures, although has notable
 
 For example, the container implementation \code{LazySortedVec} (provided by Primrose) inserts new elements at the end by default, and only sorts them when an operation that relies on the order is called.
 
-This means that operations which are performed on a full container will appear much worse than they should, since they must do work 'deferred' by the benchmarking setup.
-To prevent this, we perform some untimed 'warmup' operations.
-
-\todo{No the fuck we don't}
+were unable to work around this, although a potential later solution could be to perform untimed 'warmup' operations before each operation.
+this is complex because it requires some understanding of what operations will have deferred work for them.
 
 Once we have the data, we fit a polynomial to the data.
 Whilst we could use a more complex technique, in practice this is good enough: Very few common operations are above $O(n^3)$, and factors such as logarithms are usually 'close enough'.
@@ -44,7 +42,27 @@ As mentioned above, the ordering of operations can have a large effect on contai
 Unfortunately, tracking every container operation in order quickly becomes unfeasible, so we settle for tracking the count of each operation, and the size of the collection.
 
 Every instance of the collection is tracked separately, and results are collated after profiling.
+results with a close enough n value get sorted into partitions, where each partition has the average amount of each operation, and a weight indicating how common results in that partition were.
+this is done to compress the data, and also to allow searching for adaptive containers later
+
+\todo{deal with not taking into account 'preparatory' operations during benchmarks}
 
 \todo{Combining}
 
+\subsection{Adaptive Containers}
+
+adaptive containers are implemented using const generics, and a wrapper class.
+
+they are detected by finding the best implementation for each partition, sorting by n, and seeing if we can split the partitions in half where a different implementation is best on each side
+
+we then check if the cost saving is greater than the cost of a clear operation and n insert operations
+
+\subsection{Associative Collections for Primrose}
+
+We add a new mapping trait to primrose to express KV maps
+
+\todo{add and list library types}
+
+the constraint solver has been updated to allow properties on dicts (dictproperty), but this was unused.
+
 \todo{Summary}
-- 
cgit v1.2.3

