Jonas Öchsner

Winning a prize at my first hackathon

2026-10-12T00:00:00Z

12 October 2026 · 7 min read · 🤓 1/3 nerds

#hackathon #project report

Tallaght University Hospital loses track of its wheelchairs because nobody has time to update an Excel file. We spent a night building an LLM-powered voice logger for inventory management and learned that the hard part of solving the problem isn't technology.

Our pitch deck for the app, produced AFTER Hackathon submission, for further presentation to TUH. Due to low risk and time constraints fully AI generated and iterated on. Source Code
▶ Interactive figure — try it on oechsner.dev

Introduction

This weekend I took part in the Health Innovation Challenge at TU Dublin’s Tallaght Campus, run together with Tallaght University Hospital (TUH) and supported by Amazon. Clinicians from TUH briefed us on real problems from their wards, Amazon people coached us on prototyping and pitching, and then we had ten hours, through the night, to build something.

My team, Graciela Uscanga, Marvin Chewchut and I, won Best Use of Technology!

In this post I want to talk about our solution and approach. I especially want to cover the technical solution we chose.

Feel free to read the short version on LinkedIn, your time is valuable.

The situation: One monolythic Excel File

We worked on Challenge 2, Smarter equipment tracking for better patient care, submitted by a discharge planning occupational therapist.

The Occupational Therapy (OT) department owns about 155 items of specialist equipment. They are issued to inpatients on the daily, based on clinical need. Currently, all of it is tracked in an Excel workbook that only one person can open at any given time. Colour coding marks items that are in repair, out on a short-term loan or missing. A separate tab holds the waitlist.

When a therapist issues an item, they are supposed to open the spreadsheet and enter the patient, the equipment, the location, the date and whether it’s on loan. In practice, that often happens hours later or not at all. You can’t blame the Therapists for that, hospital reality is a lot of stress and chaos. It’s natural human error in a system, that’s not adjusted to the real needs.

Updates are retrospective, so the tracker never reflects reality.
Therapy assistants do a monthly stock check, walking the wards to see where things actually are.
The waitlist gets skipped, because checking it means logging in, finding the file and scrolling through it, so equipment goes to whoever is asking rather than to whoever is next.
With that much colour-coded spreadsheet, it is hard to see at a glance what is actually available.
About €4,600 a year of equipment goes missing and has to be replaced.
A lot of money gets lost due to the added working time.

Everything we wanted to build, and why we couldn’t

Our first brainstorm went where every engineer’s brainstorm goes: tag everything and track it automatically. RFID tags, NFC stickers, BLE beacons, OCR on Serial numbers, maybe even tracking staff location so the system could infer who moved what.

Research with the staff shut all of that down quickly:

RFID won’t work. That was the clearest "" we got all night.
Stickers don’t stick. Equipment gets washed and decontaminated between patients. NFC tags fall off or get scrubbed off.
Staff don’t carry smartphones. The device on the ward is the Universal Communication Device (UCD from now on), a hospital handset whose main jobs are sending email and looking up patient records.
No Cameras available those UCD don’t have cameras. Buying them and supplying a device with a camera to every staff member wouldn’t be financially viable and will probably violate some privacy regulation.
Equipment leaves the building. Some items go home with discharged patients on loan. A tracker that only works inside the hospital misses exactly the items that get lost.

So the real constraint was not about technology at all. The tracker already holds the right information. It’s just that updating it is a separate task, done at a desk: a place where hospital staff should spend the least possible amount of time at.

The winning idea

After some research and brainstorming, we realized that everything we needed for identification was already there! It turns out the hospital uses a service called HealthCare21 for equipment maintainence. This service requires a clear identifieing sticker on every piece of equipment they service: if the sticker is missing, they won’t maintain the equipment. This is perfect opportunity to use as a primary identifier for our system, since this is a Stable, Unique and always present ID. This also perfectly reflected on the approach on change: See Change management.

The moment a therapist hands a wheelchair to a patient, they already know everything needed for documentation: item id (it’s on the item), which patient, which bed, roughly how long. What they don’t have is a free hand.

So our solution was a central database replacing the spreadsheet, with voice input from the handset staff already carry. At the bedside you press one button and say something like:

“Book wheelchair four eight two nine, ten fifty-three to bed 4B twelve for three weeks.”

An LLM turns that into a structured record, the screen shows what it understood, and one tap confirms it. If the item is already out, confirming puts the patient on the waitlist instead, and the waitlist stops being a tab nobody opens.

But of course we know that in a chaotic hospital environment, input would rather look like this:

“Uh, the wheelchair, four eight two nine one oh five three, no wait, ending three five, to bed twelve, actually, sorry, fourteen, for like a week. Oh and the cushion next to bed seven is broken by the way.”

This is why we also added a custom llm prompt that accounts for exactly that: Try to understand what was meant (not said) and always let the last value win

The data architecture we chose. The patient id encryption is necessary to ensure pseudonymisation

None of this is clever on its own. Together, it’s the difference between a demo that works when you speak slowly and clearly, and one that works when someone talks the way people actually talk.

Change management: touch as little as possible

The first thing we emphasised in the pitch was that we were trying to change as little of the existing workflow as possible.

The tracker’s columns stay the same. The asset numbers and HC21 stickers stay the same. The device stays the same. The only thing that changes is when and how the record gets updated: at the bedside, by voice, in the ten seconds after the handover, instead of hours later at a desk.

Why did we do this? A hospital is not a startup. Every new process needs training across shifts, and every new app competes for staff attention. And especially non-technical medical experts surely struggle to adapt to drastic change. A system that needs everyone to change their habits will fail just like the spreadsheet it depends on compliance.

Financial viability: someone has to pay for this

The second thing was money. Innovation is exciting, but the project still has to be fundable, and €4,600 a year in lost equipment does not pay for a building-wide tracking network.

Our approach needs no new hardware. Staff already have the handsets, and the equipment already has its stickers. What’s left is a database, a small app, and speech parsing per log entry, which costs very little at the volume of one OT department. Then there is the time that comes back: fewer monthly stock-check walks, fewer hunts for “that cushion that should be on 4B”. That’s an argument a hospital can take to whoever signs off the budget. Installing RTLS everywhere is not.

It also scales perfectly well. Other departments that lend out shared equipment have the same problem, and none of them would need anything new installed either. We are talking about low initial investment and even lower scaling costs

Learnings

The constraints are the problem. Our most exciting ideas were the first ones that were implicitly rejected. The ten hours of working time were only useful because we took our time to develop an idea that conforms to the constraints.
LLMs are good at understanding stuff. Extracting JSON is not impressive by itself. Handling a messy, self-correcting sentence and showing what was understood before saving anything is what makes it usable.
The pitch is half the project. Leading with restating the problem and ending with finance, rather than with the architecture, is what made the idea land.

Huge thanks to Graciela and Marvin, to TUH, to Amazon, and to the TU Dublin School of Enterprise Computing & Digital Transformation for organising it.

Originally published on oechsner.dev. Read it there →

This LLM has a Context window of 1

2026-09-21T00:00:00Z

21 September 2026 · 9 min read · 🤓🤓🤓 3/3 nerds · ✒️ 100% human-written

#project report

Exploring the basics of LLMs by training a N-Gram model on my lecture notes

Introduction

An n-gram model analyzes training data to determine how frequently specific word sequences occur. For example, given the phrase “my house is,” the model examines all words that follow “my” in the dataset. If “house” is the most common continuation, the model predicts “house.”

In this Post, I will cover the mathematical basics of modern LMs and train my own N-Gram Model based on my lecture notes. I’ll take a mathematical dive into different token selection functions and prove why the maximum likelihood assumption leads to periodic repetition.

Mathematical Basics

This section is largely based on the book Speech and Language Processing by Jurafsky & Martin (2026, I.3)

Most language models use context consisting of $n-1$ tokens $C:= w_1w_2\cdots w_{n-1}$ to predict the nth token $w_n$ and describe the probability for every next token with $P(w_n|w_{1:n-1}) = P(w_n|C)$ . N-Gram models limit this context by assuming $\approx P(w_n| w_{n-N+1} \cdots w_{n-1})$ . In the extreme case of a bigram model ( $N=2$ ) this assumption simplifies to $P(w_n|C)\approx P(w_n|w_{n-1})$ , we call this the markov assumption. The probability of outputting a sentence $s=w_{1}w_{2}\dots w_{m}$ with token-length $m$ based on context token $c$ is $P(s)=\prod_{w\in s}P(w)$ . I define $S_{N}$ as the set of all sentences with length N. And $s_{w_n}$ We define $T(a | B)$ as the number of occurrences of $a$ with the sentence $B$ preceeding. The next token selection is decided by $Sel: C \longrightarrow w_n$ .

In our case, we define $P(w_{n}|C)=\frac{ T(w_{n}| w_{n-N+1 \cdots w_{n-1}})}{ T(w_{n})}$ , simplifying to $P(w_{n}|C) = \frac{T(w_n|w_{n-1})}{T(w_n)}$ with bigrams.

Greedy decoding always ends in a loop

Let’s take the maximum likelihood assumption of picking with $Sel(C) := \max_{w_{i}} (P(w_{i}|C))$ .

Before we improve $Sel$ , let’s prove why choosing greedily will fail.

Proof

Adapted from Knuth (1997)

We define a greedy $Sel$ as:

f: V \longrightarrow V, \quad f(w) := \operatorname*{arg\,max}_{w' \in V} P(w' \mid w),

Token selection function under the maximum likelihood assumption

Given vocabulary $V$ with $|V| = v < \infty$ : Generation from a seed $w_{0}$ is then nothing but iterating: $w_{t} = f(w_{t-1}) = f^{t}(w_{0}).$

Theorem. For every $w_{0} \in V$ the greedy sequence $(w_{t})_{t \ge 0}$ is eventually periodic: there are $i,j \in \mathbb{R}$ where $i < j \le v$ such that $w_{i} = w_{j}$ , and the sequence repeats with an arbitrary period $p$ : $f^{p+1}(w_{i})=w_j$

Proof. Look at the first $v+1$ tokens $w_{0}, w_{1}, \dots, w_{v}$ . They are $v+1$ elements drawn from a set of only $v$ tokens, so by the pigeonhole principle two of them must coincide: $w_{i} = w_{j}$ for some $0 \le i < j \le v$ . Because $f$ is a function:

\forall k \ge 0:\quad w_{i+k} = f^{k}(w_{i}) = f^{k}(w_{j}) = w_{j+k}

So the sequence is periodic with period $p = j - i$ from index $i$ on. $\blacksquare$

What do we learn from that?

Repetition is structural, not a bug of the dataset. Any finitely large dataset doesn’t fix the underlying problem.
The model can produce at most $|V|$ distinct texts
Termination is luck. We can’t guarantee the loop contains a EOS.

Markov

To prevent this, we sample from $P(\cdot|C)$ . Thus, $f$ is no longer a function, but a stochastic kernel of a markov chain. This leads to the key insight that a bigram model with this $Sel$ is equivalent to a markov chain, where nodes are tokens and edge weights are $P(w_n|w_{n-1})$ .

We can also model higher-order N-Grams as markov chains, where the number of nodes increases exponentially with $V^N$ .

The better selection Funct

This section is based on Jurafsky & Martin (2026) too

The maximum likelihood assumption fails in the real world. No matter how big the training set, some sentences will never be able to be generated. That leaves the model locked on a subset $\subset$ of real language.

One option is Laplace Smoothing:

P_\text{Laplace}(w_{i})=\frac{ T(w_{i} + 1}{ T(w_{n})}

Laplace smoothing: Just adding 1 for every token

This leads to this Prediction function in bigram models:

P_\text{Laplace} (w_{n}|w_{n-1})=\frac{T(w_{n-1}w_n)+1}{\sum\limits_{w}(T(w_{n-1}w)+1)}\overset{\sum1=V}{=}\frac{T(w_{n-1}w_{n})+1}{T(w_{n-1})+V}

Jurafsky & Martin (2026), eq. 3.26

Laplace charges a proportional tax on evidence

What count would have produced this probability without smoothing? Solving $P_\text{Laplace}=\frac{T^{*}}{T(w_{n-1})}$ for $T^{*}$ gives the effective count

T^{*}(w_{n-1}w_{n}) = \bigl(T(w_{n-1}w_{n})+1\bigr)\cdot\underbrace{\frac{T(w_{n-1})}{T(w_{n-1})+V}}_{=:d(w_{n-1})}

The discount factor

d

does not depend on the bigram at all, only on the context. So Laplace is a proportional tax: every continuation of

w_{n-1}

is scaled by the same

d

, no matter whether we saw it 500 times or never.

That factor is brutal at the vocabulary sizes we are dealing with. My vault has $V\approx 2\cdot10^{4}$ types, and a decently frequent context like Gradient might have $T(w_{n-1})=200$ . Then $d \approx \frac{200}{20200}\approx 0.0099$ , and the bigram Gradient Descent, observed 50 times, ends up with an effective count of roughly $0.5$ . We spent a whole corpus collecting that evidence and then threw away $99\%$ of it to fund $V$ continuations that never happened.

Lets add more!

Add- $k$ smoothing, $P_{\text{add-}k}(w_{n}|w_{n-1})=\frac{T(w_{n-1}w_{n})+k}{T(w_{n-1})+kV}$ , only changes the tax rate. The structural problem survives: the amount of mass taken from observed events scales with $V$ and with nothing about the context except its total count. A single $k$ tuned on held-out data is always a compromise between contexts we know a lot about and contexts we saw three times.

Discount, don’t rescale

Both scale multiplicatively. But held-out counts show the MLE error is additive: bigrams seen $r$ times recur about $r-0.75$ times (2026). So subtract a fixed $\delta$ instead. Normalization then forces the freed mass to be

\lambda_{w_{n-1}}=\frac{\delta\,N_{1+}(w_{n-1}\bullet)}{T(w_{n-1})},\qquad N_{1+}(w_{n-1}\bullet)=\bigl|\{w: T(w_{n-1}w)>0\}\bigr|

so diverse contexts leak more. It is only consulted in unseen contexts, so count how many distinct contexts $w$ appears in, not how often. Descent is frequent, yet almost always follows Gradient.

Knesner-Ney

P_{\text{KneserNey}}(w_{i}|w_{i-1})=\underbrace{\frac{\max (T(w_{i-1}w_{i})-\delta,0)}{\sum_{w}T(w_{i-1}w)}}_{\text{measured evidence, deficient by}\ 1-\lambda_{w_{i-1}}} +\lambda_{w_{i-1}}P_{KN}(w_{i})

Bigram KneserNey-Smoothing. Adapted from Ney et al. (1994)

We arrive at Knesner-Ney. The right term spends exactly the deficit the left one creates. $\lambda$ is normalized, so $P_{KN}$ is freely chosen.

Perplexity

For LM evaluation, we use Perplexity. It is the exponentiated average negative log-likelihood the model assigns to held-out text:

\text{PP}(w_{1:M}) = \exp\left(-\frac{1}{M}\sum_{i=1}^{M}\log P(w_{i}\mid w_{i-N+1:i-1})\right)

Perplexity: the model’s average surprise per token

Read it as an effective branching factor: how many words is the model effectively choosing between at each step? A uniform model over my vocabulary has a perplexity of exactly 15,622, because it is choosing uniformly between 15,622 options. Lower is better (Jurafsky & Martin, 2026).

Building an N-Gram Model

I was able to extract 585 .md files, skipping the following:

forbidden = [
    r"*/.claude/*",
    r"*/.obsidian/*",
    r"*.excalidraw.md",
    r"*/node_modules/*",
]

Preprocessing: Markdown is not prose, since markup is far more repetitive than text, so a model trained on the raw vault would spend most of its probability mass learning that [ follows ]. Twenty-one ordered regex substitutions normalise this, anything carrying display text is reduced to it (aliased wikilinks, markdown links, callout headers), anything else is deleted rather than replaced (frontmatter, code, math, embeds, URLs, HTML, hashtags, rules). Pure markers (headings, bullets, blockquotes, checkboxes, emphasis) are stripped. Because a lecture note is a stack of grammatically unrelated bullet fragments, each line becomes its own training sequence. All exact duplicate notes are dropped by content hash, since the same content being in training and validation set would defeat the point.

markdown files	588
after deduplication	533
non-empty documents	388
training tokens	277,208
held-out tokens	11,023
types → vocabulary	23,988 → 15,622 (96.98% coverage)

277k tokens is very small. For scale, GPT-3 was trained on roughly 300 billion.

How much context is worth paying for?

So I trained one model per order, from $N=0$ (uniform) up to $N=19$ , and measured each on the same held-out documents:

N	0	1	2	3	4	5	6	8	10	12	15	19
Perplexity	15622	801	137.8	42.6	28.8	25.5	24.0	22.8	22.5	22.5	23.0	23.9

Improvement seems to be lorarithmic. The “context window of 1” divides perplexity by almost six, and the trigram cuts it by another two thirds. After $N=4$ perplexity doesn’t seem to improve.

Later it surprisingly goes back up. Past $N=12$ , more context makes the model measurably worse. This seemingly is because it has fewer training data for longer lines. At $N=3$ , 15% of held-out tokens arrive with a context the model has never seen; by $N=12$ it is 35%.

What it actually writes

Perplexity doesn’t paint the whole Picture. So a test run: same seed, same prompt, one model per order:

--- N = 1 ---
the main
 of
: ,
:
.
 . 1
 the 3 the , b
die

--- N = 2 ---
the main process
:
for all
x lecture 03 .
removed and the
in order to a basis of b ,
fixed a 4 , then there is true .

--- N = 3 ---
the main process before processes are launched when using a kernel , the
removed property from the other files : , email 42 , concat name , :
the trainer no longer randomly selects a seed no longer returns a triplet 18390
: there is a subset of examples for pytorch 2.4 .
if is even .

--- N = 5 ---
the main academic risks are : unclosed gaps in securityprivacy weeks 14 15 , the rsa calculation error , and the missing .
you can decompress drawing data with the command palette : decompress current excalidraw file .

--- N = 10 ---
the main academic risks are : unclosed gaps in securityprivacy weeks 14 15 , the rsa calculation error , and the missing buffer-overflow payload practice .
a graph is planar if it can be drawn on a paper such that no edges cross each other

Every line break is the model emitting </s> and starting a fresh sequence, so the number of lines is itself a signal: the higher the order, the longer it keeps going before it decides EOS.

$N=1$ is function words and punctuation — the model has no context, so it produces the most common tokens in the language, which are the ones carrying no meaning. $N=3$ is the interesting one: locally grammatical, globally nonsense. “the main process before processes are launched when using a kernel” actually quite good, you’d have to secondguess to figure out it is nonsense.

And then $N=5$ and $N=10$ stop writing and start quoting. “A graph is planar if it can be drawn on a paper such that no edges cross each other” is a line from my notes on discrete modelling, reproduced word for word.

The minimum is a lie

That is just an impression though, so let’s measure it. For each order I sampled a few hundred lines, cut them into 8-grams, and checked how many of those 8-grams appear word for word in the training split and, separately, how many of the generated lines are entire lines of the vault reproduced exactly:

The rows move together. Every point of perplexity I bought past $N=3$ was paid for in originality: at the perplexity minimum, two out of three 8-word spans the model produces are copied straight out of my notes, and half of the lines it writes are completely out of my notes.

At $N=10$ , 62% of the contexts the model knows occur exactly once in the entire corpus. The model isn’t choosing. It is looking up the rest of the line.

Which brings us back to its own proof. Greedy decoding fails because it is a function on a finite set, so it must eventually cycle. Sampling fixes that, but at high $N$ it stops repeating itself and starts repeating me. Both are a model with nothing of its own to say, and only the first one is visible in the loss.

If you want the most original model, I suggest $N=3$ or $4$ : still recombining, just before the counts get sparse enough to overfit. → The best-scoring model and the best model are not the same.

One model, two languages

My notes are bilingual, and both go into one model with one vocabulary. So it code-switches mid-line, as I do in my notes:

fixed an issue to avoid validation loop : : set aller möglichen hypothesen nach der hypothesis
der lokale daemon muss als eigenständige for any

Improvement opportunities

Estimate the discount instead of guessing it. $\delta$ is hard-coded to 0.75 throughout. Let’s change that and use a separate delta for N=1,2,3+: $\delta = \frac{n_1}{n_1 + 2n_2}$ (2026).
Top-k sampling. We could store the k most next $w_i$ and $P(w_i| C)$ , normalized such that $\sum\limits_{i=1}^{k}P(w_{i}|C)=1$ in a key-value store and run the Markov kernel only on those fixed number of tokens. This would mean Inference goes from $\Theta(N\cdot V)$ per token to $\Theta(1)$ , independent of vocabulary and order. Note that this isn’t a lossless operation (Fan et al., 2018).

Limitation

There is a ceiling, and it is not an engineering problem. An n-gram model stores a table indexed by context, so its parameter count grows as $V^{N}$ . With my modest 15,622-token vocabulary, a 10-gram table has $15622^{10} \approx 10^{42}$ cells. I observed 277,208 of them. Every additional token of context multiplies the space by 15,622 and adds zero new evidence.

That is the wall the whole field hit, and the reason the next idea had to be structurally different rather than merely bigger. This ceiling was already visible in the smoothing literature by 2001 (Goodman, 2001), and still standing in 2007 when Google trained 5-grams on two trillion tokens of web text and watched the gains go logarithmic.

Conclusion

So: what does a context window of 1 get you? $\rightarrow$ A perplexity of 137.8, sentences that are grammatical for about four words at a time, and a model small enough an Arduino would be able to run it easily.

It doesn’t get you anywhere near the level of competence modern LLMs have and finds no relation between similar tokens. You can’t embed tokens or find any semantically valuable information in the models.

References

Fan, A., Lewis, M., & Dauphin, Y. (2018). Hierarchical Neural Story Generation. https://arxiv.org/abs/1805.04833
Goodman, J. T. (2001). A bit of progress in language modeling. Computer Speech & Language, 15(4), 403–434. https://doi.org/10.1006/csla.2001.0174
Jurafsky, D., & Martin, J. H. (2026). Speech and Language Processing: An Introduction to Natural Language Processing, Computational Linguistics, and Speech Recognition, with Language Models (3rd ed., I.3). https://web.stanford.edu/~jurafsky/slp3/
Knuth, D. E. (1997). The Art of Computer Programming, Volume 2: Seminumerical Algorithms (3rd ed.). Addison-Wesley.
Ney, H., Essen, U., & Kneser, R. (1994). On structuring probabilistic dependences in stochastic language modelling. Computer Speech & Language, 8(1), 1–38. https://doi.org/https://doi.org/10.1006/csla.1994.1001

Originally published on oechsner.dev. Read it there →

Obsidian for school and Uni

2026-09-10T00:00:00Z

10 September 2026 · 4 min read · 🤓 1/3 nerds · ✒️ 100% human-written

#obsidian #workflow

In this blogpost I will cover my full 4-Year daily obsidian workflow, explain the rationale behind the plugins I chose and why links didn't work for me.

Introduction

Most developers should know the benefits of writing docs in .md. Markdown not only gives you full ownership of all of your files, but also enables integration of arbitrary tools. Especially in the AI age, this is an essential strength. Integrating AI into your notes becomes as easy as just spawning an agent in your vault root and formulating some behaviour rules. You aren’t dependent on any toolset given to you by a firm with the same audience as scam callers.

Choosing Obsidian means configurability, stability and (generally) a feeling of superiority.

But like every highly configurable tool, it needs some setup to be nice to use. I’ve seen many bad tutorials and tips, and want to work my own experience into a small guide. I built my vault to meet specifically my needs as a MINT student.

The vault

I’ve used the software for 4 years now. I’ve installed (and uninstalled) hundreds of community plugins and was in configuration hell, a minimalism trip and everything in between. I think I found a nice middle ground that works for me.

Believe it or not, but I found the builtin link system (and thus the infamous obsidian graph network) as completely useless. That goes against the whole “second brain” crowd and I’m proud of it. When I study, am completely organized into semesters, courses and lectures. Seeing the hierarchy? Specific lecture notes correspond to specific lecture slides and embedded assets correspond to specific files.

Connections in my vault aren’t made via links, they are made with locations and the hierarchy that this creates, so why would I need any more links?

.
├── Archive/
│   ├── SS25/
│   │   └── Course1
│   └── ...
├── Course2/
│   ├── assets/
│   │   └── Lecture01/
│   │       └── image.png
│   ├── Assignments/
│   ├── Exam-prep/
│   ├── ...
│   ├── LecturePDF/
│   │   ├── Lecture01.pdf
│   │   └── Lecture02.pdf
│   ├── Lecture01.md
│   └── Lecture02.md
└── Course3/
    └── ...

That same hierarchy, live: semesters inside Archive, courses inside those. Note what is missing: no ribbon, no tab title bar.

What follows is a list of all the plugins I use, sorted into specific usecases and a short explaination.

Note-Taking

Editor feel

Vimrc Support — Loads a startup vimrc, so my Vim mappings are identical in Obsidian and in my editor.
Vim Yank Highlight — Flashes the yanked region, must-have
Code Editor Shortcuts — VS Code key bindings (line move, duplicate, multi-cursor) inside the editor
Spacekeys — Leader-key style command sequences, so vault actions are reachable from the keyboard without hotkeys.
Typewriter Mode — Buffer lines below the cursor, so you don't have to work at the edge of your screen.

All to meet my needs of navigating quickly. I grew dependent the Vim keybindings.

My .obsidian.vimrc:

" Have j and k navigate visual lines
nnoremap j gj
nnoremap k gk
nnoremap gj j
nnoremap gk k

" Quickly remove search highlights with ESC
nmap <ESC> :nohl<CR>

"" Smarter o and O (inserting prefix for markdown lists). 
nmap o A<CR>
nmap O kA<CR>

" Yank to system clipboard
set clipboard=unnamed

Math and code

Quick Latex — Auto-fractions, matrix and align shortcuts, custom shorthands, use immediately
Completr — Autocompletion for LaTeX commands (I disabled it for everything else)
Solve — Inline calculations in plain text: arithmetic, percentages, unit conversion and date math right where I am writing.
Code Emitter — Executes code blocks directly in Document. I use it mainly for syntax verification
VSCode Editor — Convenience plugin. Open arbitrary code files in Vault in a handy editor, not for fullon coding, good for a quick look

Quick Latex is probably the most important plugin of them all. $\LaTeX$ equations get rapid fast and my custom shorthand list grew to almost $90$. VSCode Editor is nice if you need to look something not .md up quick.

Sketches and diagrams

Excalidraw — One of the most important elements in My workflow. Quickly draw and Embed handdrawn sketches
Mermaid Tools — Toolbar with common Mermaid elements, making it a smoother experience the few times I use Mermaind.
Obsidian Functionplot — Plots mathematical functions inline.

Excalidraw should be self-explaining, as one of the worlds most popular whiteboards.

I’m a bit unhappy with the drawing & config speed though, Diagrams are clunky. This is where Mermaid comes into play. Obsidian has a builtin mermaid renderer, just label a block code with mermaid. I still struggle with the syntax though, thus I use the toolbar.

A small regret I have is Obsidian Functionplot. Have used it a few times and am now stuck with the plugin for backwards compatibility. Don’t be like me, actually think about what you’ll use.

Sources

PDF++ — Annotates lecture slides and papers inside Obsidian and links notes back to the exact highlighted passage in the PDF. I usually split-screen the PDF and note.
Media Extended — Built in media player for lecture recordings. Supports timestamped embeds and Screenshots.
Auto Link Title — Pasting a paper, docs page or lecture URL fetches a readable title instead of a naked link.
Paste URL into selection — Select text, paste a URL, get a Markdown link. Just Intuitive behaviour, should be built in.

Both PDF++ and Media Extended are in my daily workflow. I usually splitscreen the source and my notes.

PDF++ is especially good, because it supports dynamic embeds. It just specifies a rectangle in the source file and renders on-demand, no additional images sitting in assets. Media Extended sadly just takes screenshots. I’m not even sure if dynamic loading would be resourceful though, no idea if the .mp4 file structure would support this.

Consistency

Linter — Normalises YAML, headings, spacing and math blocks on save, making the vault a bit more normalized.
Smart Typography — Converts quotes, dashes and ellipses to their typographic forms so exported PDFs look properly typeset.
Header Adjuster — Bulk-shifts heading levels up or down

Linter is great for solving a very specific problem of mine, because I often use this note structure:

**Technical term**
- Aspect 1
- Aspect 2
**Broken term (gets wrapped upwards)**
- Aspect 1

Sadly, lines directly after lists in markdown gets merged into the previous line. I forced an empty line after every bullet list with this custom regex:

^((?:[ \t]*[-*+] .*\n)+)(?=[ \t]*(?![-*+] )\S) - gm - $1\n

I won’t explain it though, go figure it out yourself at Regex101 — the example above is already loaded as the test string.

Visuals

Styling

Style Settings — Exposes theme, snippet and plugin CSS variables as real settings, which is how I tune the look of callouts and tables without editing CSS by hand.
List Callouts — Lightweight inline callouts inside lists. See Better Export PDF, only exporter that supports them.
Iconize — Icons on course folders and key notes so I can navigate the vault by shape instead of reading every folder name.

I’m currently using the Soft Paper Theme, mainly for its customisability with style settings. I also like the pastel background.

How the screen looks

Hider — Hides specific visual elements. Important for a distraction-free Workspace.
Status Bar Organizer — Reorders and hides status bar items, keeping only the counters I actually watch (edit time, word count) visible.
Hide Sidebars on Window Resize — Collapses sidebars automatically when I shrink the window. This means that notes are always readable, even if I have obsidian only on one side of the screen

I found the standard view to be much to cluttered and distracting, thus I hid most of it. I hid:

The ribbon
the tab title bar
Many Statusbar items, including Vim mode
backlink, canvas, footnotes, page-preview, daily-notes, slash-command, bookmarks, markdown-importer, zk-prefixer, random-note, audio-recorder, publish, bases

I also have keyboard shortcuts to directly hide sidebars and tabbar. This means in fullscreen I only see my note, perfect focus.

Workspaces Plus — Fast switching between saved layouts: One for each Course and usecase
Multiple Notes Outline — Shows the outlines of several notes side by side, which is how I get an overview of a whole course before an exam.
Settings Search — Global search across all settings tabs

Multiple Notes outline is a gem I found relatively recently. I configured it to display the outline of every note in a course folder, superb for navigation and getting a overview on how far your notes are done.

Getting things out of the vault

Advanced Slides — Turns a course note into a slide deck without leaving the vault: Used mainly for tutoring
Better Export PDF — Exports notes as PDFs, produce printable summary sheets for friends. Replaces Obsidian export, because it supports List callouts

Service callers

Claudian — Embeds Claude Code and other coding agents with the vault as working directory, so an agent can read my notes and PDFs, run shell commands and edit files for me.
Google Calendar — Pulls lecture, lab and deadline events into the vault so planning notes sit next to the actual schedule.

Even though claude integration is very easy (see above), I like to have a custom view for the LLM. Claudian gives me that: it embeds the agent in a sidebar pane with the vault as its working directory, and it renders $\LaTeX$, important for math questions. I've tried many agent plugins, Claudian was the best.

Custom system prompt:

You are mainly used as a university tutor for students with solid CS experience (especially ML). Act accordingly, highlight connections and explain with related concepts. If you create a file, mark it with the “LLM: Claude” property. If you modify a file, insert ”— (Claude)” as header and footer to your modification.

Under the hood

Plugin Groups — Enables and disables sets of plugins with one command and delays startup of heavy ones, which keeps this long list from slowing down launch.
Custom Attachment Location — Store embeds near the actual note, not in one big photo wasteland
Update time on edit — Keeps the frontmatter timestamps current automatically, Which is what my Dataview "recently touched" queries depend on.
NLP — Provides NLP primitives (tokenisation, similarity, keyword extraction) that other plugins and my own queries can build on for text analysis over the vault.

Custom Attachment Location is very important to me, since my hierarchical filestructure needs me to have embeds near the actual note. This is where I store my embeds:

.
├── assets/
│   ├── Note1/
│   │   └── img1.png
│   └── Note2/
│       └── drawing.excalidraw
├── Note1.md (embeds img1.png)
└── Note2.md (embeds drawing.excalidraw)

Sync and backup

I actually don’t have a dedicated backup system for obsidian. I put all of my documents in a partition BEFORE my OS. This is backed up to Google drive using this.

Disclaimer

Keep in mind that nothing good comes from optimising your note-taking system to the brim, it’s just wasted time. If another system works for you, honestly keep it. But if you’re already deep in the obsidian rabbithole, I suggest giving my method a try :). Thanks for reading my second blogpost!

Originally published on oechsner.dev. Read it there →

Solving (German) Hangman with Letter Frequencies

2026-09-06T00:00:00Z

6 September 2026 · 4 min read · 🤓🤓 2/3 nerds · ✒️ 100% human-written

#statistics #sidequest

In this article, I walk through how I analysed and solved Hangman with some Stat. I'll talk about game rules, high level implementation of a winning strategy and letter frequencies.

This project is heavily inspired by this video by Ballpark Figures. All code used for this project is available on Github

Hangman Rules

Hangman is a two player game, where one player is the Game master, deciding on a secret word (in my case a noun in German). The other player tries to guess this word by asking for individual letters. If the secret word contains that letter, the Game master reveals all positions, where that letter is at. If it doesn’t, the player loses a life. Figuratively, one body part is added to a stick figure hanging from the gallows. The guessing player knows the number of letters in the secret word. In the following, I will assume the guessing player has perfect knowledge of the wordset and the choosing player randomly selects a word from it.

I settled on hangman with 6 lives (Head, Body and 4 limbs) and set umlauts (Ä, Ö, Ü) and the ‘sharp S’ (ß) as separate characters.

Taumatawhakatangihangakoauauotamateaturipukakapikimaungahoronukupokaiwhenuakitanatahu

The distribution of noun lengths in German

Taumatawhakatangihangakoauauotamateaturipukakapikimaungahoronukupokaiwhenuakitanatahu is the longest word in my Wordlist. It has $85$ letters and apparently is the name of a hill in New Zealand. Note that in German, you can infinitely chain nouns together. German-Nouns only selects words that were mentioned in German Wikipedia. Since the guessing player knows the number of letters at the start of the game, we can treat every word length as its own separate problem.

Each different guess can have a maximum of $2^{n}$ different outcomes, where $n$ is the number of unknown positions in the word.

The Frequency tactic

The distribution of letter uses in German

The first real tactic that comes to mind is picking the most frequent letters in order. It is flawed, because it completely disregards existing information the guessing player has: Letter count of the word, Existing successful guesses and his knowledge about the German language.

This naive tactic yields a winrate of about $9.0\%$ with an average number of $10.73$ misses per word. We are already significantly better than just choosing letters in alphabetical order, where we get a winrate of $0.2\%$ with $13.89$ avg misses per word. Note that the miss counts come from letting every game run to the end of the alphabet instead of stopping at the sixth wrong guess. That is why they are so far above the 6 lives an actual game gives you.

The greedy Strategy

At every game step, we can perform a letter frequency analysis on the remaining word options and select the most frequent letter and thus make the optimal greedy choice. I will call this strategy Letter Counting from here on. This of course assumes perfect knowledge of the choosing player’s wordset. After running for about 10 minutes on 500 samples per wordlength, this achieved a $97.2\%$ winrate with $1.21$ average misses. We mainly fail on short, unconventional words. Some examples for len 3-8:

Len 3: 'gäa' in 8 guesses (6 wrong: eoinbd, 6 to finish)
Len 3: 'sou' in 8 guesses (6 wrong: aebndg, 7 to finish)
Len 3: 'rtl' in 6 guesses (6 wrong: aeouid, 7 to finish)
Len 3: 'ivf' in 7 guesses (6 wrong: aeouhl, 8 to finish)
Len 3: 'ria' in 8 guesses (6 wrong: eocdfm, 7 to finish)
Len 4: 'tipp' in 8 guesses (6 wrong: aeonkl, 7 to finish)
Len 4: 'crow' in 8 guesses (6 wrong: aelgbf, 6 to finish)
Len 4: 'smog' in 8 guesses (6 wrong: aelrnh, 6 to finish)
Len 4: 'chef' in 7 guesses (6 wrong: aiorln, 6 to finish)
Len 4: 'zaya' in 7 guesses (6 wrong: mrgnpv, 7 to finish)
Len 5: 'füdle' in 9 guesses (6 wrong: aiuoth, 6 to finish)
Len 5: 'wippe' in 8 guesses (6 wrong: anlktr, 8 to finish)
Len 5: 'ziege' in 9 guesses (6 wrong: smflrw, 6 to finish)
Len 5: 'haxen' in 10 guesses (6 wrong: rlmgbf, 7 to finish)
Len 5: 'debüt' in 8 guesses (6 wrong: aiourh, 6 to finish)
Len 6: 'tauber' in 9 guesses (6 wrong: lnskgp, 6 to finish)
Len 6: 'medium' in 7 guesses (6 wrong: nrlstg, 6 to finish)
Len 6: 'fasson' in 9 guesses (6 wrong: eirkmb, 6 to finish)
Len 6: 'schulz' in 11 guesses (6 wrong: eaiotd, 7 to finish)
Len 6: 'zörbig' in 7 guesses (6 wrong: eansou, 6 to finish)
Len 7: 'dämlack' in 7 guesses (6 wrong: eonhru, 7 to finish)
Len 7: 'curling' in 10 guesses (6 wrong: eathbm, 6 to finish)
Len 7: 'bexbach' in 7 guesses (6 wrong: nrslti, 6 to finish)
Len 7: 'fußfall' in 8 guesses (6 wrong: eonhrb, 6 to finish)
Len 7: 'gezücht' in 11 guesses (6 wrong: nrslim, 6 to finish)
Len 8: 'luftkuss' in 7 guesses (6 wrong: eaoicn, 6 to finish)

Note that the first guess can be different depending on lengths, because each len has a unique letter distribution

These words are pretty unsurprising. Due to the lower letter count, we have much less information that narrows down the candidate count. There also is a lower probability the letter appears in the guessed word, just because it is shorter. Thus, we can generally expect worse performance on shorter words.

Average number of wrong guesses for every word length. From about length 15 onwards, misses are already negligible.

Letter distributions

It’s actually pretty interesting, how the letter distribution of the words Letter Counting loses on differs from the wordset as a whole:

Letter distribution on All words in the dataset vs just the ones Letter Counting lost on.

We see, that unpopular letters such as j, ß or x are much more popular in difficult words, confirming my theory. By looking at the outliers, we can conclude, that the choosing player should generally choose words with a, u, k and specifically p and z more, and n,r and s less often.

Conclusion

Average false guesses per word length, for all three strategies

We can see, that for long words, the game is pretty much trivial. To ensure a fair (and fun) game assuming perfect play, I suggest a system of dynamic lives according to this table:

Word Length	3	4	5	6	7/8	9+
Lives	6	5	4	3	2	1
Hangman

Every colour in those hangmen is one life. As the count drops, parts get merged into a single stroke: both legs at once, then both arms, until for 9+ letters we just draw a head. Hangmen drawn in Excalidraw btw

What now?

A list of possible research questions for the future:

You could further investigate the frequency differences to English (or other languages) and do a frequency analysis on specific wordlengths.
You could also develop a system for humans to implement the greedy strategy as best as they can.
The dataset doesn't consider arbitrary composite nouns
What would happen if the guessing player didn't know the letter count?

Seriously try playing it this way! It actually is really fun. Thanks for reading this post, it took a lot of effort. :)

Originally published on oechsner.dev. Read it there →

Jonas Öchsner

Winning a prize at my first hackathon

Introduction

The situation: One monolythic Excel File

Everything we wanted to build, and why we couldn’t

The winning idea

Change management: touch as little as possible

Financial viability: someone has to pay for this

Learnings

This LLM has a Context window of 1

Introduction

Mathematical Basics

Greedy decoding always ends in a loop

Proof

What do we learn from that?

Markov

The better selection Funct

Laplace charges a proportional tax on evidence

Lets add more!

Discount, don’t rescale

Knesner-Ney

Perplexity

Building an N-Gram Model

How much context is worth paying for?

What it actually writes

The minimum is a lie

One model, two languages

Improvement opportunities

Limitation

Conclusion

References

Obsidian for school and Uni

Introduction

The vault

Note-Taking

Editor feel

Math and code

Sketches and diagrams

Sources

Consistency

Visuals

Styling

How the screen looks

Navigation & Search

Getting things out of the vault

Service callers

Under the hood

Sync and backup

Disclaimer

Solving (German) Hangman with Letter Frequencies

Hangman Rules

Taumata­whakatangihanga­koauau­o­tamatea­turi­pukaka­piki­maunga­horo­nuku­pokai­whenua­ki­tana­tahu

The Frequency tactic

The greedy Strategy

Letter distributions

Conclusion

What now?

Taumatawhakatangihangakoauauotamateaturipukakapikimaungahoronukupokaiwhenuakitanatahu