Coder Legion - Recent posts tagged computerscience

Kurt Gödel: The Incompleteness Theorems, the Limits of Logic, and Can an AGI Ever Know Everything?

Sat, 31 Oct 2026 09:34:36 +0000

In the twilight of his life, when the Institute for Advanced Study (IAS) in Princeton was the undisputed intellectual epicenter of the world, Albert Einstein shared a startling confession in confidence with Austrian economist Oskar Morgenstern:

“My own work in physics no longer amounts to much. I come to my office every single day only to have the privilege of walking home alongside Kurt Gödel.”

The man Einstein sought out with almost filial devotion was a slender, spectral figure who peered warily through round tortoiseshell glasses, kept his dark overcoat buttoned up to his chin even on sweltering summer afternoons, and possessed a nervous fragility bordering on existential paralysis.

His name was Kurt Gödel.

If Alan Turing invented the conceptual blueprint of the modern computer, if John von Neumann architected its physical hardware, and if J. Robert Oppenheimer directed the shattering power of the split atom, Gödel accomplished something even more unsettling and profound: he proved the absolute mathematical boundaries of what human minds, formal systems, and synthetic machines will ever be able to know.

Watch: Veritasium's documentary exploring Kurt Gödel and the Incompleteness Theorems.

The Tormented Mind: Paranoia, Contradictions, and Poisoned Apples

Born in 1906 in Brünn (then part of the Austro-Hungarian Empire, now Brno in the Czech Republic), young Kurt was nicknamed Herr Warum ("Mr. Why") by his family because of his unrelenting, encyclopedic curiosity.

Endowed with razor-sharp mathematical precision, his personal life was shadowed by intense neuroses and paralyzing hypochondria:

The U.S. Constitution Loophole: In 1947, while preparing for his United States citizenship examination, Gödel scrutinized the American Constitution with manic logical rigor. To his horror, he discovered a subtle internal contradiction—a logical loophole whereby an authoritarian executive could legally utilize constitutional amendments to overthrow democracy and turn the United States into a dictatorship. On the drive to the Trenton courthouse, Einstein and Morgenstern pleaded with him to keep quiet. But when the presiding federal judge remarked casually that “fortunately, an evil dictatorship couldn't happen here,” Gödel erupted: “On the contrary! I have mathematical proof that it can happen!” Only Einstein's quick-witted banter and the judge’s gentle patience defused the situation and saved Gödel’s naturalization.
Einstein’s Rotating Universe (1949): As a 70th birthday gift for Albert Einstein, Gödel formulated an exact solution to the field equations of General Relativity (the celebrated Gödel Metric). In his model, the entire cosmos rotates. The mathematical consequence was staggering: a rotating universe admits closed timelike curves, meaning an interstellar traveler could journey into their own past without violating the laws of relativistic physics.
Tragic Paranoia and the Princeton Finale: For decades, Gödel suffered from an unshakable fear that toxic gases were leaking from his radiators and that secret conspirators were trying to poison his food. His sole lifeline was his devoted wife, Adele Nimbursky, who tasted every morsel of food in his presence before he would eat. In late 1977, Adele suffered a severe illness and was hospitalized for months. Paralyzed by the terror of unverified food, Gödel refused to eat. He passed away from self-starvation at Princeton Hospital on January 14, 1978, weighing a mere sixty-five pounds (twenty-nine kilograms).

Kurt Gödel during his mature years at Princeton's Institute for Advanced Study, wearing his signature round glasses.

David Hilbert's Dream and the 1931 Logic Bomb

To appreciate the seismic shock of Gödel's discovery, we must look back to interwar Europe and the undisputed titan of mathematics: David Hilbert.

At the International Congress of Mathematicians in Paris in 1900, Hilbert outlined the grand vision for 20th-century science. Known as the Hilbert Program, his goal was to fortify mathematics against paradoxes by constructing an unassailable axiomatic foundation satisfying three canonical pillars:

Completeness: Every true mathematical statement formulated within the formal system must be provable through a finite sequence of logical deductions.
Consistency: The system must be free of contradictions. It must be impossible to formally derive both a proposition and its negation, such as proving 0 = 1.
Decidability (Entscheidungsproblem): There must exist an effective mechanical algorithm capable of deciding, in finite time, whether any arbitrary mathematical proposition is true or false.

Hilbert proudly declared his manifesto in 1930: “Wir müssen wissen, wir werden wissen” (“We must know, we will know”).

Gödel's reply arrived just months later at a conference in Königsberg in September 1930. While senior academics delivered triumphant speeches celebrating the formalist triumph, a quiet twenty-four-year-old Gödel dropped a logical thermonuclear bomb: Hilbert’s program was mathematically impossible.

Conceptual infographic: The intellectual journey from Hilbert's Program and Gödel's Incompleteness to Turing's Halting Problem and the AGI Dilemma.

In 1931, Gödel published his landmark treatise: “On Formally Undecidable Propositions of Principia Mathematica and Related Systems”. In fewer than thirty pages, Gödel articulated two theorems that forever altered human epistemology:

The First Incompleteness Theorem

In any consistent formal axiomatic system capable of doing elementary arithmetic, there exist true mathematical propositions that can never be proven or disproven within that system.

In simple terms: mathematical truth is fundamentally larger than formal provability. There will always be truths that escape whichever set of axioms we define.

The Second Incompleteness Theorem

No consistent formal axiomatic system capable of elementary arithmetic can demonstrate its own consistency from within itself.

To verify that your mathematical system is safe and contains no hidden contradictions, you must rely on a larger, more powerful meta-system... whose own consistency you cannot prove without an even larger system, triggering an inescapable infinite regress.

The Mechanics of the Paradox: Gödel Numbering

The underlying intuition traces back to the ancient Liar Paradox (“This statement is false”). If the statement is true, then it is false; if it is false, then it is true. In natural human language, self-reference generates paralyzing semantic loops.

Formalist mathematicians believed that by replacing natural words with symbolic notation, they had banished self-reference forever.

Gödel countered by inventing a breathtaking mathematical technique: Gödel Numbering:

He assigned a unique positive integer to every basic logical glyph (e.g., 0 is 1, + is 2, = is 3).
He mapped mathematical formulas to unique sequences of prime numbers raised to powers: 2^(a_1) · 3^(a_2) · 5^(a_3) ...
By the Fundamental Theorem of Arithmetic (which guarantees unique prime factorization), every complete mathematical proof was translated into a single, unique astronomical integer.

Gödel made mathematics talk about itself using ordinary arithmetic. Syntax was transformed into number theory.

Using this machinery, Gödel constructed a formal arithmetic statement, universally known as the Gödel Sentence (G), whose exact arithmetical meaning was:

G: “The statement with Gödel number G cannot be proven within this formal system.”

The trap snapped shut with ruthless elegance:

If the system can prove that G is true, then G is provable—directly contradicting what G asserts (the system is inconsistent and collapses into contradiction).
If the system cannot prove G, then what G asserts is strictly true (it cannot be proven). But because it is true yet unprovable, the system is incomplete.

Forced to choose between inconsistency and incompleteness, mathematics is forever condemned to incompleteness.

Sitting in that Königsberg lecture hall was a twenty-six-year-old mathematician named John von Neumann. While other professors dismissed Gödel's announcement as an academic parlor trick, von Neumann went pale. He realized instantly that Hilbert's dream was dead, immediately abandoned his own research on set-theoretic foundations, and praised Gödel as the greatest logician since Aristotle.

From Gödel to Alan Turing: The Birth of Computation

The shockwaves of Gödel’s theorems did not stay confined to philosophy: they were the direct intellectual catalyst that sparked modern computer science.

In Cambridge, a young Alan Turing studied Gödel’s papers with obsessive intensity. In 1936, Turing asked: if Gödel proved that certain mathematical truths are unprovable, how does that limitation manifest in a mechanical computing device executing discrete steps?

To resolve the third pillar of Hilbert's program (Decidability or the Entscheidungsproblem), Turing invented the theoretical Universal Turing Machine and formulated the celebrated Halting Problem:

Can we write a universal supervisor program that inspects the code of an arbitrary program and decides with certainty whether it will eventually halt or run forever in an infinite loop?
Replicating Gödel's self-referential diagonal argument within code, Turing proved that such a general algorithm is mathematically impossible.

Software, by its very mathematical nature, is irreducible: you cannot know with absolute certainty what an arbitrary piece of complex software will do without executing it.

Gödel numbering—the revolutionary insight of treating program instructions as numbers and data residing in the same memory space—was the exact conceptual spark that inspired Turing and later von Neumann to engineer the stored-program computer. Without Gödel's incompleteness, modern software architecture would not exist.

The AGI Dilemma: Can Intelligent Machines Escape Gödel?

Nearly a century after Gödel's 1931 paper, his shadow looms directly over the most contentious debate surrounding Artificial General Intelligence in 2026: can an artificial machine achieve or surpass human consciousness, or is it fundamentally constrained by the Incompleteness Theorems?

1. The Lucas-Penrose Argument: The Human Mind Beyond the Machine

In 1961, Oxford philosopher John Lucas, and later in 1989 the eminent mathematical physicist and Nobel laureate Sir Roger Penrose in his seminal treatise "The Emperor's New Mind", advanced a Gödelian objection against algorithmic AGI:

Any artificial intelligence running on digital hardware (whether classical von Neumann silicon or quantum chips) is ultimately a finite, formal axiomatic system.
Therefore, for any AI model, there exists a Gödel sentence (G_AI) that the machine cannot prove or deduce without contradicting itself.
However, we human beings can look at the system from the outside and see with unshakeable intuitive clarity that G_AI is true.
Penrose's Conclusion: Human understanding, mathematical insight, and conscious awareness are fundamentally non-computable. Human biology transcends algorithmic limits, making traditional software-based AGI a theoretical impossibility.

2. The Modern AI Counterargument: Adaptive and Probabilistic Systems

Against Penrose’s thesis, contemporary machine learning theorists present equally robust counterarguments:

Humans are not consistent formal systems: Human beings contradict themselves daily, hold mutually incompatible beliefs, forget edge cases, and make logical errors. If a system is not strictly consistent, Gödel's theorems do not preclude its real-world effectiveness.
Reasoning is not static formal deduction: As we analyzed in our study on Inference-Time Scaling and System 2 Reasoning, 2026 frontier models do not function as rigid first-order logic provers. They leverage heuristic search, test-time exploration (MCTS), self-reflection scratchpads, and reinforcement learning to dynamically alter and expand their own reference frameworks.

The Real Frontier: The Impossibility of Total Formal Verification

Where Gödel imposes an absolute, non-negotiable barrier in 2026 is in AI Safety and Autonomous Governance (as discussed in AI Agent Evaluation & Testing and the EU AI Act):

No matter how powerful or superintelligent an AGI becomes, it is mathematically impossible to build an automated verifier that proves with 100% mathematical certainty that an autonomous agent will never trigger an unintended, catastrophic behavior.
Incompleteness and the Halting Problem guarantee that complex software systems will always exhibit irreducible, emergent blind spots. Flawless AI alignment is an asymptotic fantasy; real safety relies on continuous empirical containment, behavioral guardrails, and adversarial red-teaming.

An Open Question for the Reader

Kurt Gödel dismantled the greatest arrogance in the history of science: the illusion that human reason could capture the infinite totality of truth within a neat, self-contained mathematical box.

He proved that truth will always outrun whichever formal language we invent to capture it.

Today, as we stand on the cusp of awakening synthetic intelligences whose internal reasoning chains span billions of parameters and millions of latent tokens far beyond the biological tracking capacity of our brains:

If we humans could step outside the formal systems of 1931 and perceive truths that machines could not prove... will there come a day when a Superintelligent AGI steps outside our biological framework and gazes upon our truths, our morals, and our scientific laws with the same quiet pity with which we regard the limitations of an automaton?

And when that AGI uncovers a fundamental truth of the universe that is provably inaccessible to the biological human brain... will we possess the intellectual humility to accept it, or will we dismiss it simply because our biology was never wired to understand it?

Explore more deep dives on foundational thinkers and modern computing architectures at www.datalaria.com.

What is Agent Harness ?

Mon, 19 Oct 2026 22:12:00 +0000

2023… Prompt Engineering

2024… Context Engineering

2026… Agent Harness Engineering

Since ChatGPT was released in 2022, AI tools have been easily and freely accessible to every other human being. Now that anyone can easily build AI agents through a perfectly written prompt, what does an AI Engineer do except writing the so-called better prompts?

AI Engineering is no longer about only writing code, but to build a system, design an environment, specify intent, and build feedback loops for the agent.
The new buzzword in the tech industry is the Agent Harness, and how important it is even more than the model used. But how much truth is there? Is it really as necessary as they say it is? Turns out, yes, it is.

What exactly is Agent Harness?
Agent harness is everything about the agent except for the model(LLM) itself. Think of LLM as the brain and the harness as the body of a human. The brain itself is quite powerful but can do nothing without a body.

Models are stateless and non-deterministic. With a good harness, one can build a great agentic system even with a cheap model(like GPT-3.5).

So is an agent harness a tool?
Nope. An agent harness is like the system environment built around the model. Like the system design of an agent! Agent Harness can also be defined as the control layer between a model and the real world.

Agent = Model + Harness

Another great way to understand is this- a Harness. We use harnesses for our pets so they do not run around and remain in command. Similarly, we use an agent harness so the model does not wander around and cost us millions of tokens. We are literally tying the model to a stable environment.

But why not just a better prompt?
While building an agent, what if the agent doesn’t work as it is expected to? We just write better system prompts, right? Not really. A good agent should have its system restructured by adding more and better tools, guardrails and context management.

Harness engineering is treating each failure as a system problem to fix, and not a better prompt to retry.

Why the sudden need Harnesses?
Agent harness is not something we came up with recently. It was always there. But the developers did not understand its importance. For months, they have been waiting for the next release of a better and more powerful model, while the real strength lies in better harnessing an existing model.

A great model can do so many things, but it’s like a simple chatbot. For it to get anything done other than just providing answers, it needs its harness. E.g., Claude Code not only generates the new code but also writes it in the respective files. Coding tools like Codex, Cursor, Copilot, Cline etc are great examples of harnesses. The model underneath the platform can be changed, however, the real work happens with the harness.

Harness is all about reliability- to make sure that agents do exactly what we want them to do irrespective of the model. We are already paying quite a lot for the LLM tokens, so it is important that the agents utilize their full potential.

In short, harnessing became necessary as AI moved from providing only prompt-response answers to an actual agent that gets things done. As we explore the components of harnesses further, it makes sense how each component works to provide a better experience for the users.

The below diagram by the team at Langchain provides a perfect and easily understandable architecture of agent harnessing.

The Anatomy of a Modern Agent Harness:

1. Large Language Model
The core brain used to run the agent. In ChatGPT you can set it as GPT-4o or GPT-3.5 as per your preference and your richness in terms of API keys.

There has always been a lot of pressure on deciding which LLM to use, because that does handle the greatness of an agent. However, the main purpose of Agent Harness is to take the pressure off the model and provide better results even with cheaper(or crappy) models.

2. Prompts
Another instrumental part of the agent. The better the prompt, the better the execution. It is so true and makes a huge impact. The models in AI companies have 100s of lines of prompt meticulously written to make sure that the LLM understands precisely what the user wants it to do.

A part of agent harness involves including better prompts. Though, the prompt should only contain information about the operations to execute. The entire agent harness cannot be defined through a single prompt where all the tools execution are included as part of the prompt. It should only contain the steps to be taken.

3. Context management window
Based on the prompt received, the harness performs context engineering to decide what to include, what to compress and what to remove.

There are different methods like context isolation (keeping different subtasks separate so they do not confuse with one another), context reduction (dropping irrelevant data to avoid context rot), and context retrieval (injecting fresh data such as documentation or search results). As the size of the context window is limited, it is important that the context engineering is done appropriately and the agent performs well throughout the entire lifecycle.

4. Tools
At the heart of the harness, are the tools that the model can use to connect with the external system. The most common and useful tools are web scraping(for gathering data from websites), API calls, code execution in sandbox, file read/write tool and code interpreter.

5. Memory and State Management
The harness has to maintain memory beyond a context window of a single task. This includes- working context (the immediate prompt given to the model ); session state (a durable log of what’s been done in the current task); and long-term memory (a knowledge base or vector store that persists across tasks or time). With a well performed memory and state management, the agent can utilize only the effective data from the memory and avoid feeding the model with unnecessary data.

6. Verification and Guardrails
The agent verification process ensures that the task to be performed has been executed correctly before treating the work as complete.

The guardrails make sure to take actions within certain rules and not accidentally delete the user’s entire file system.

Benefits of Harnessing:
The most important advantage of harnessing is that the AI systems become model-agnostic. As we discussed earlier, the harnessing helps the agent perform better even with cheaper and older versions of models.

Another benefit of harnessing is that it reduces the token cost by providing the model the right tools and management which can get the best results through the model’s utmost capacity.

The Future: Is this a temporary trend?
Now one might think that Agent Harnessing is a temporary concept which will be easily taken over the years when better models are available that take care of it. And it is somewhat true. The models are always improving, and the developers are always making ways to make it easier for the next generation of developers to do minimum work.

However, harnessing does not shrink or vanish, it moves. Harness engineering is like scaffolding which is always necessary while building agents. As the models get bigger and better, the harnessing moves up. A harness is a system, not a config file you set up once. It is always there.

Thank you for reading. Hope you enjoyed it. If you want to get a deep-dive of Agent Harness Engineering, do check out these References:

https://www.langchain.com/blog/the-anatomy-of-an-agent-harness#why-do-we-need-harnesses-from-a-models-perspective

https://www.firecrawl.dev/blog/what-is-an-agent-harness#what-are-the-benefits-of-a-well-designed-agent-harness

https://parallel.ai/articles/what-is-an-agent-harness

Behavioral Convergence Without Representational Convergence: Reproducing Training-History Dependen

Thu, 15 Oct 2026 21:37:08 +0000

When two neural networks reach nearly identical accuracy, have they actually learned the same thing?

The Problem With Calling Two Models "Equivalent"

Imagine training two neural networks on the same classification problem.

Both eventually achieve around 98.4% accuracy. They use the same architecture, begin with identical weights, and are eventually trained on the same data distribution.

From a conventional evaluation perspective, these models look remarkably similar.

But there is one important difference: they learned things in a different order.

Does that early training history still matter after extensive shared training?

This question motivated my recent research on training-history dependence in neural networks.

The central finding is that two models can become behaviorally similar while maintaining measurable differences in their internal representations.

More interestingly, those differences can sometimes affect how efficiently a downstream classifier extracts information when labeled data is limited.

Let's look at how the experiments work.

1. Designing an Experiment Around Training History

To investigate this, I used MNIST and a small convolutional neural network.

Rather than changing the model architecture or comparing independently initialized networks, I controlled the initialization and changed the sequence of training experiences.

The dataset was divided into three distributions:

A: MNIST digits 0–4
B: MNIST digits 5–9
C: A balanced distribution containing all digits 0–9

Two networks began with identical initial weights.

They then followed different training sequences:

Model	Training sequence
SABC	A → B → C
SBAC	B → A → C

The final stage is the important part.

During stage C, both models encounter the same training distribution, deterministic minibatch sequence, and checkpoint schedule.

In other words, the models have different past experiences but share the same subsequent learning environment.

This creates a controlled way to ask:

Can shared training erase the representational consequences of earlier learning?

If training history eventually becomes irrelevant, we might expect the representations to become increasingly similar as both networks continue learning from the same data.

But predictive accuracy alone cannot answer that question.

2. Accuracy Doesn't Tell the Whole Story

Accuracy is useful, but it only measures one aspect of a model's behavior.

Two neural networks can achieve comparable performance while internally organizing information differently.

To examine this distinction, I used Centered Kernel Alignment (CKA), a technique for comparing neural representations.

The experiment tracks a representation-history score defined as:

H_repr = 1 − mean(CKA_conv2, CKA_fc1)

Here, CKA measures representation similarity at two layers of the CNN.

A higher H_repr indicates greater measured representational dissimilarity between the paired networks.

The distinction we want to investigate is straightforward:

Behavioral convergence: Models reach very similar predictive performance.
Representational convergence: Their internal feature representations become increasingly similar under the selected measurement.

These are related concepts, but they are not interchangeable.

A model's final accuracy does not uniquely determine how its internal features are organized.

3. What Happens After 50,000 Shared Training Updates?

The main experimental study used 20 paired random seeds.

The networks frequently reached closely matched predictive performance after common training, even though their internal representations remained measurably different.

I then investigated whether substantially longer shared training would eliminate the effect.

For this stress test, I reran five paired seeds from initialization and extended the shared training phase to 10,000, 25,000, and finally 50,000 updates.

At the final checkpoint, the results were:

Measurement	Result
SABC mean accuracy	98.480%
SBAC mean accuracy	98.316%
Mean absolute accuracy gap	~0.18 percentage points
Representation-history score	0.1902
95% bootstrap CI for H_repr	[0.1611, 0.2193]

The result is interesting because the models remain close in predictive accuracy while their measured representation difference does not disappear.

After 50,000 shared updates, the mean representation-history score is still approximately 0.19.

This supports a specific conclusion:

Under this experimental protocol, prolonged shared training did not eliminate the measurable effects of earlier training order within the tested horizon.

It does not establish that those differences would persist forever, nor that every neural architecture would behave similarly.

But it challenges the assumption that matching predictive performance necessarily indicates matching internal representations.

4. Do Different Representations Actually Matter?

Finding different internal representations is interesting, but it raises another question.

What if those differences have no practical consequences?

A model might encode information differently without affecting anything we care about.

To investigate this, I added a linear-probe experiment.

The procedure was deliberately simple:

Freeze the trained CNN backbone.
Extract features from its FC1 layer.
Initialize a completely new linear classifier.
Train only that linear classifier on labeled examples.
Compare how effectively the two representations support classification.

The paired probes used identical initialization, training examples, labels, minibatch ordering, and optimization settings.

This isolates differences in how accessible the class information is to a simple downstream classifier.

The low-data result

I evaluated the linear probes with several amounts of labeled data.

The following table shows the mean accuracy difference between probes built on SABC and SBAC representations.

Labeled examples per class	SABC − SBAC accuracy
25	+1.005 pp
50	+0.580 pp
100	+0.288 pp
500	+0.090 pp

A clear pattern emerges.

The observed advantage is larger when labeled data is scarce and becomes smaller as more training examples are available.

The 50-example condition was examined more carefully using five fresh linear-head seeds for each of the 20 model seeds.

After averaging the repeated probes within each model seed, the mean paired difference was:

+0.496 percentage points, with a 95% bootstrap confidence interval of [+0.160, +0.833] and a paired t-test p-value of 0.0111.

Within this experimental setup, the difference is statistically detectable.

At 500 examples per class, however, the mean difference falls to just +0.090 percentage points.

An exploratory equivalence analysis using a ±0.5 percentage-point margin also supported practical equivalence at that higher-data endpoint.

Why this matters

The important distinction is not simply that one training order produced better results in this experiment.

It is that training history influenced the efficiency with which a new classifier could recover useful information from frozen features.

Two representations can support nearly the same full-task performance while differing in how readily a small downstream model can use them.

That is particularly relevant when thinking about transfer learning and representation reuse.

5. Testing Alternative Explanations

A result becomes more interesting when we begin testing why it occurs.

One possible explanation involves the activation function.

ReLU networks can develop sparse activation patterns, potentially influencing how readily their representations change during later training.

To investigate this possibility, I compared ReLU with LeakyReLU under matched learning-rate conditions.

Across five paired seeds evaluated through 50,000 common updates, LeakyReLU produced a lower representation-history score relative to ReLU.

The final mean difference was approximately −0.0398.

All five paired differences pointed in the same direction, although the small sample made conventional paired significance tests inconclusive.

This is directional evidence consistent with an activation-mediated plasticity mechanism, not proof of a specific causal explanation.

There was also another concern.

The original A/B experiment separated different digit classes. Perhaps the effect only appeared because the models encountered disjoint output labels in different orders.

To examine that possibility, I used a same-label rotated-MNIST control.

Both histories contained the same digit classes, but the input domains differed through rotations.

Across five paired seeds, the models achieved the predefined behavioral-matching criterion while maintaining nonzero representation-history scores.

This showed that the observed phenomenon was not restricted to the original disjoint-label setup.

6. What Should Machine Learning Developers Take Away?

I think these findings raise several useful questions for practical machine learning.

Model evaluation

When comparing two checkpoints, similar accuracy may not tell us the whole story.

Representation analysis can provide additional information about how models organize their learned features.

Transfer learning

A representation that performs well on its original task may not be equally convenient for downstream learning with limited labels.

The linear-probe experiment illustrates why downstream sample efficiency can be worth measuring separately.

Continual learning

Models are increasingly trained through sequences of tasks, domains, and updates.

If training order influences later representations, understanding that dependence becomes important when studying continual adaptation.

Reproducibility

Reproducing a final accuracy score is not necessarily the same as reproducing the complete learned system.

A more complete investigation may need to consider training trajectories, representation measurements, and downstream behavior.

These are implications worth investigating, rather than claims that the MNIST results automatically generalize to large-scale production models.

7. Reproducing the Research

Reproducibility was a central goal of this project.

The public repository contains the experimental implementation, configuration files, analysis scripts, and supporting artifacts.

GitHub repository:
https://github.com/Ertugrulmutlu/hysteresis-neural-networks

The repository supports analyses including:

Paired training-history experiments
Representation similarity using CKA
Long-horizon common relaxation
Training and weight trajectory analysis
Fresh linear-probe evaluation
Activation-function comparisons
Rotated-MNIST controls
Multi-seed statistical aggregation

The experiments explicitly control relevant paired-run factors, including initialization and the shared training schedule.

For anyone interested in reproducing the findings, extending them to other architectures, or examining the measurement choices, the repository provides a starting point.

The full research preprint is available on arXiv:

Read the paper — arXiv:2609.37836

8. What Remains Unanswered?

There are important limitations to keep in mind.

The current work focuses primarily on a small CNN and MNIST-derived experimental protocols.

It does not demonstrate that training-history effects are permanent or universal, nor does it establish a single mechanism responsible for their persistence.

It also does not imply that two networks with similar accuracy implement identical prediction functions.

The logical next step is to investigate whether comparable effects occur with larger datasets, deeper architectures, transformers, and sequential fine-tuning.

I am particularly interested in what this could mean for models that undergo repeated adaptation.

Imagine two models that achieve similar performance today but have experienced very different fine-tuning histories.

Would they adapt equally well to a new task tomorrow?

Would they require the same number of examples?

Would their representations react similarly to another distribution shift?

Those are open questions, and the current experiments provide one controlled starting point for investigating them.

Final Thoughts

The main finding of this research is not that neural networks trained differently end up with different weights.

That alone would not be surprising.

What interests me is the combination of identical initialization, different early training sequences, extensive shared later training, closely matched predictive performance, and persistent measurable representation differences.

The downstream probe results make the observation even more interesting: some of those differences can affect learning efficiency when supervision is limited.

Behavioral similarity and representational similarity are different properties, and measuring one does not automatically establish the other.

As machine learning systems become increasingly adaptive, understanding the influence of training history may be important for reproducibility, evaluation, and future model development.

If you are interested in reproducing the experiments or extending them to other architectures, I would be happy to hear your findings.

Research and Resources

Original research:
Behavioral Convergence Without Representational Convergence — arXiv

Open-source implementation and reproducibility artifacts:
GitHub — hysteresis-neural-networks

Author: Ertuğrul Mutlu
AI Researcher & Computer Engineering Student, RWTH Aachen University

This article is a developer-focused explanation of my research preprint, written to make the experimental design, results, and limitations more accessible to the software engineering and machine learning community.

The Alphabet Code: What Happens When You Run a Simple Rule on the Letter “a”

Wed, 14 Oct 2026 22:57:40 +0000

alphabets #nlp #mathematics #symbolicdynamics #fractals #eigenvalues #perronvalues

Here is a string of letters:
gzhlvzggjzyihjgheqvzgzhlvzhlvbjzgyhzizygjzbjzhlvgjzehjdzzgheqv...

It looks like a cat walked across a keyboard. It isn’t. It’s the start of a sequence that runs to thousands of characters, and every letter is fixed in advance by one rule applied to the letter “a.” No randomness, no guessing, no training data. Run the same rule again tomorrow, or on another computer, and you get exactly the same string.

Figure 1. The sequence for the letter “a” drawn as a path: each letter tells a virtual pen how to turn and move, so a fixed rule produces this shape.

That simple question, "what happens when one fixed rule is applied to “a” again and again?" led me into years of studying sequences like this one. I want to show you what I’ve found, what I still haven’t figured out, and why I think a curious person might care.

The idea in one minute
Start with the letter “a” and apply the same fixed rule to it repeatedly. Each round replaces the existing letters with new strings of letters, so the sequence grows. At the same time, the earlier rounds remain embedded within the later ones.
The first seven rounds have 1, 4, 14, 43,138, 429, and 1361 letters. Mathematicians call this a substitution system.

The unusual feature of the Engineering of Alphabets project is that the rule is applied to the alphabet itself. When I say "alphabet" here, I mean the 26 English letters together with their spoken names. A different language, or a different naming convention, would give a different sequence. I wanted to see whether the letters we use for writing, treated as a mathematical system, produce structures that are interesting, unexpected, or perhaps useful.

How I did it. I wrote a short computer program that applies the rule and records the output. For the results below, I generated several thousand letters, enough to count blocks up to length 30 and to estimate the growth factor. I used the same program to compute the growth factor for each of the 26 starting letters. The degree-13 equation came from fitting the term lengths to a linear recurrence, then factoring the resulting polynomial. A colleague or reader can rerun the program on the public data; the exact rule itself is withheld for now.

What I found
Three observations stand out. I’ll be careful to say how solid each one is.
• The sequence never settles into a loop, but it isn’t chaotic either. Imagine a text that never repeats itself, but in which the number of distinct short phrases grows slowly instead of exploding. In the range I’ve checked, that count grows roughly in a straight line. This is a measured result over a finite range, not a proof that it continues forever.
• The strings grow by a number very close to π. Each round, the sequence gets longer by a factor that converges to about 3.14159322. That is within a few millionths of π (3.14159265…). It cannot actually equal π, because it is the root of a degree-13 equation with whole number coefficients and π is known not to be algebraic. So this may be a coincidence, or a hint of something deeper. I don’t know yet, and I’d be wary of anyone who claimed to.
• It’s a family, not a one-off. Letter “a” is one of 26 starting letters in the project. For 13 of them, the growth factor obeys the same degree-13 equation. Whether that grouping reflects something deep about the alphabet, or just the way the rule was set up, is still open.

Figure 2. Distinct blocks p(k) by block length up to 30, shown on a logarithmic vertical axis. Dashed orange is a linear reference; dashed blue is the Sturmian minimum (k+1).

*What I am not claiming
I think this matters as much as the findings, so here it is plainly:
• I am not claiming the growth rate is π. It isn’t.
• I am not claiming the sequence is fully understood. Its straight-line behavior is observed, not proven.
• I am not claiming this beats any existing tool for compression, language processing, or character recognition. No such experiment has been run. If you work in those fields, treat any connection as a question, not a result.

Open Questions
Here is my challenge to you. See whether you can answer any of these. If you crack one, or show that I've got it wrong, I want to hear about it.

1- What is the equation? The growth factor is the dominant root of a degree-13 polynomial with integer coefficients. What does that polynomial mean? Is it new, or does it match something already known?

2- Is there a simpler rule hiding inside? Certain short stretches keep coming back. Do those recurring pieces follow a smaller, simpler rule of their own?

3- Does the straight line hold? The number of distinct blocks grows roughly in a straight line over the lengths I've checked. Does it keep going, or does it bend at longer lengths? Only deeper computation can say.

4- Why 13 of 26? Thirteen starting letters: a, d, e, g, h, i, k, l, q, u, w, y, z, have the same degree-13 minimal polynomial: 4x¹³ − 21x¹² + 45x¹¹ − 74x¹⁰ + 98x⁹ − 34x⁸ − 116x⁷ + 210x⁶ − 152x⁵ + 26x⁴ + 38x³ − 30x² + 9x − 1 The rest of the letters have a degree-14 polynomial, which is exactly this one multiplied by (x − 1). So all 26 share a common structure. The 13 listed above are the ones where the extra factor cancels out. Why? Does that split mean something about the alphabet, or is it an artifact of how the rule was set up?

5- Why is the growth factor so close to π? The closeness is striking, but the number is algebraic and cannot be π. Is there a mathematical reason for the resemblance, or is it a coincidence?

Why This Might Matter Beyond Pure Math
These are possible directions, not demonstrated applications. None has been tested yet.
You might be thinking: this is interesting, but what does it have to do with anything? Here are the directions I think are worth exploring.
Language compression. If sequences generated from letter names have low-complexity structure, that structure might be exploitable for compression. Whether it actually helps would need a real benchmark.
Natural language research. The alphabet is the foundation of written language. If deterministic structure underlies how letters relate to each other, it could say something about the mathematics of language itself.
Training-free representation. The encoding is purely algebraic: no training data, no loss function, no randomness. The output is fixed and reproducible for anyone who runs it, which makes it auditable. It handled noisy input well in a separate study, but it's still unclear whether that matters for other tasks.
OCR and character recognition. Could truncated EOA vectors outperform the full vector on character recognition tasks? This is an open question, not a result. Standard OCR relies on trained networks and labeled data; whether a training-free encoding adds anything is untested.
Low-resource languages. Where no tagged text exists, you can't train a model. If an alphabet can be encoded deterministically, it might support tokenization and compression tools without training data.
Speech and phonetics. The encoding is phonetic. Could it connect to phoneme-level representations, or help with unseen words? That is a question, not a claim.
Memory. Low factor complexity suggests the number of distinct patterns stays small, which might mean lower storage needs.
Research into alphabets. Most alphabet research is historical or linguistic. This treats the alphabet as a formal system rather than a cultural artifact, and the early results are surprising enough to keep going.
No compression, OCR, speech, or language-modeling experiment is reported here.

The Bigger Picture
The Engineering of Alphabets is a research program that studies what happens when you apply deterministic rules to alphabets. The letter 'a' is just the beginning. The project includes 13 main sequence families, plus several related cases. Each one has its own structure, properties, and open questions.
The alphabet can be treated as a mathematical object, not only as a tool for writing. Whether that view leads anywhere is what the open questions are for.

Try to break it
Science works when people try to prove each other wrong, so here is what I’d ask of you.
• If you’re curious: download the first 6,260 letters of the sequence and look for patterns I missed. click
• If you’re a mathematician or computer scientist: check my numbers. Even “your count is wrong” would help me a lot. click
• If you work with language, speech, or text: tell me where, if anywhere, you’d test something like this.

The data and part of the code are public. The code that generated the sequence is not public, but the code that counted the blocks and computed the growth factor is. The exact letter-by-letter table behind the rule is shared under a short written agreement, because a first formal paper is still in preparation. That is a timing decision, not a permanent lock, and the open questions can be worked from the public data alone.

You can reach me at Bahaa Budargham.
ORCID: 0009-0005-2955-3703. Zenodo • GitHub

Data Types Across Programming Languages: What You Actually Need to Know

Tue, 06 Oct 2026 14:07:00 +0000

Every introduction to programming eventually reaches data types.

An integer is a whole number. A string contains text. A Boolean is true or false. A floating-point number represents numbers with fractional components.

Then you learn another programming language and discover that apparently none of this was quite as simple as advertised.

An integer in Python is not the same thing as an integer in C. JavaScript's number covers values other languages separate. Rust would rather make absence explicit than let null wander through a program. R has several different ways for something to be missing.

The definitions are not wrong. They are incomplete. A data type does more than tell a computer how to store a value. It expresses what a language assumes you should be able to represent, which distinctions matter, and which mistakes should be caught before the program runs.

So instead of memorizing another list of types, let's give several languages the same small collection of facts and see what happens.

Meet Alex.

Alex is about to have a complicated afternoon, mostly because of one missing middle name.

The deceptively simple data model

Suppose our program needs to represent a customer:

name = "Alex"
age = 42
discount = 0.15
middle_name = no value
favorite_numbers = 3, 7, 11
status = ACTIVE

Nothing exotic. Text, an integer, a decimal value, an absent value, a collection, and a status chosen from a known set.

If data types were merely different spellings for the same concepts, moving this model between languages would be syntax conversion.

It isn't. And watch which field causes the most trouble.

Python: let the values tell us what they are

Python makes our first version pleasantly straightforward.

name = "Alex"
age = 42
discount = 0.15
middle_name = None
favorite_numbers = [3, 7, 11]
status = "ACTIVE"

At runtime those values have types such as str, int, float, NoneType, and list. We did not declare them before assigning because Python is dynamically typed.

That makes Alex easy to get into the system. It also means constraints exist only if we deliberately add them.

Nothing about status = "ACTIVE" prevents a later status = "ACTVE". Python does not know our domain recognizes ACTIVE, SUSPENDED, and DELETED and has never heard of ACTVE. We can model that with an Enum, type hints, validation, or classes, but the bare string does not carry the rule.

Python's integers hold another surprise for anyone arriving from C or Java. A normal Python int is not limited to a fixed 32-bit range.

age = 999999999999999999999999999999999999

An absurd customer age, and a perfectly valid Python integer.

What nothing looks like in Python

Spelling	What it means	Who makes you deal with it
`None`	The only nothing available	Nobody

Already, "integer" has stopped meaning one universal thing. And None is a single, undifferentiated way of saying nothing is here, which will turn out to be a choice rather than an inevitability.

JavaScript: one `number`, and two different nothings

const name = "Alex";
const age = 42;
const discount = 0.15;
const middleName = null;
const favoriteNumbers = [3, 7, 11];
const status = "ACTIVE";

Similar enough, until we ask JavaScript about the values.

typeof age;         // "number"
typeof discount;    // "number"
typeof middleName;  // "object"

Yes, typeof null returns "object", a famous historical artifact that cannot be fixed without breaking existing code.

More important for our comparison, 42 and 0.15 share the ordinary type number, based on IEEE 754 double-precision floating point. JavaScript also has BigInt for integers beyond the safe range of number.

Absence is where it gets interesting. An uninitialized variable is undefined. A variable deliberately set to nothing is null. The language provides two spellings for emptiness and then declines to tell you which one means what. In practice one tends to mean "nobody has assigned this yet" and the other "somebody decided this is empty," except when a codebase uses them the other way around, or interchangeably.

Loose equality shows what the language really thinks. Zero, the empty string, false, and an empty array all agree they are the same thing. The two values that actually mean nothing is here do not join in:

0 == "";             // true
"" == false;         // true

null == undefined;   // true
null === undefined;  // false
null == 0;           // false
null == "";          // false

null and undefined are loosely equal to each other and to nothing else in the language. They form their own small island.

So JavaScript does distinguish absence from emptiness, and the rule is arguably the right one: a missing thing is not a zero thing. The problem is where that rule lives. It sits inside an equality operator famous for being unpredictable, next to a typeof that reports null as "object". Alex Dorey's JavaScript Equality Table renders every comparison as a grid, if you want the full picture and a certain amount of despair.

What nothing looks like in JavaScript

Spelling	What it means	Who makes you deal with it
`undefined`	Never assigned	Nobody
`null`	Deliberately empty, by convention	Nobody

A type system is already more than a vocabulary list.

C: representation becomes difficult to ignore

#include <stdint.h>

typedef enum {
    ACTIVE,
    SUSPENDED,
    DELETED
} Status;

typedef struct {
    char *name;
    int32_t age;
    double discount;
    char *middle_name;
    int favorite_numbers[3];
    Status status;
} Customer;

Representation is visible almost everywhere. We chose an explicitly 32-bit signed integer for age, double for the discount, an array of exactly three integers, pointers to characters for names, and an enumeration for status.

A null pointer might represent an absent middle name:

customer.middle_name = NULL;

But C does not attach our intended meaning to that pointer. NULL here could mean Alex has no middle name, that we have not loaded it yet, that the allocation failed, or that somebody forgot to initialize the struct. The program establishes the convention and the program is responsible for respecting it. The compiler will not help.

What nothing looks like in C

Spelling	What it means	Who makes you deal with it
`NULL` pointer	Whatever this program decided it means	Convention, and only convention

C also forces us to care directly about ranges and representation. A fixed-width signed integer cannot grow forever. This is not C being gratuitously difficult. C was designed around a different relationship between programmer and machine, and its type system reflects that.

Java: primitives, references, and the null question

enum Status {
    ACTIVE,
    SUSPENDED,
    DELETED
}

class Customer {
    String name;
    int age;
    double discount;
    String middleName;
    int[] favoriteNumbers;
    Status status;
}

Java distinguishes primitive types such as int, double, and boolean from reference types such as String, Customer, and arrays.

An int cannot be null. A String can.

That single asymmetry does a lot of work. It means absence is available for some of Alex's fields and structurally impossible for others, and the choice was made by whoever picked the field types rather than by anyone thinking about the domain. Unless we add conventions or tooling, String middleName does not tell us whether null is an expected state or a bug waiting for the right execution path.

What nothing looks like in Java

Spelling	What it means	Who makes you deal with it
`null`	An empty reference	Nobody
(not available)	Primitives cannot be absent at all	The compiler, by refusing

Java also has wrapper classes such as Integer, which means two things that sound like "an integer" behave differently:

int age;
Integer optionalAge;

One of those can be absent. The other cannot. Learning the keyword is only the beginning; the useful question is what guarantees come with it.

Rust: make some invalid states harder to represent

enum Status {
    Active,
    Suspended,
    Deleted,
}

struct Customer {
    name: String,
    age: u32,
    discount: f64,
    middle_name: Option<String>,
    favorite_numbers: Vec<i32>,
    status: Status,
}

Look at middle_name: Option<String>.

Instead of allowing a String to secretly contain null, Rust represents the possibility of absence in the type itself. The value is either Some(...) or None, and code consuming it has to deal with that possibility before it can get at the string.

This is the same information every other language has been carrying around implicitly, finally written down somewhere the compiler can read it. The other languages let you forget. Rust makes forgetting a compile error.

The Status enum similarly makes the valid alternatives explicit. We cannot accidentally assign ACTVE, because no such variant exists.

What nothing looks like in Rust

Spelling	What it means	Who makes you deal with it
`None`, inside `Option<T>`	This value may legitimately be absent	The compiler

A type system can encode valid states, not merely storage categories. That does not make incorrect programs impossible. It moves some classes of error from runtime behaviour into representations the compiler can reject.

The type system is participating in the design.

Go: useful zero values and deliberate simplicity

type Status string

const (
    Active    Status = "ACTIVE"
    Suspended Status = "SUSPENDED"
    Deleted   Status = "DELETED"
)

type Customer struct {
    Name            string
    Age             int
    Discount        float64
    MiddleName      *string
    FavoriteNumbers []int
    Status          Status
}

One important Go idea appears before we populate Alex at all: types have zero values. The zero value of an int is 0, of a bool is false, of a string is "". Pointers, slices, maps, functions, channels, and interfaces can be nil.

That creates a question. If Age contains 0, is Alex zero years old, or did nobody supply an age?

The type cannot answer. If the application uses a zero value to stand for “not supplied,” that state becomes indistinguishable from a legitimately supplied zero. If the distinction matters, the model has to represent it deliberately, which is why MiddleName above is a *string rather than a string.
What nothing looks like in Go

Spelling	What it means	Who makes you deal with it
`0`, `""`, `false`	Zero/default value; cannot by itself tell us whether a domain value was supplied	The model must distinguish this if it matters
`nil`	Empty pointer, slice, map, channel, or interface	Nobody

Convenient defaults acquire meaning only when they enter a domain.

R: "missing" is not one simple state

name <- "Alex"
age <- 42L
discount <- 0.15
middle_name <- NA_character_
favorite_numbers <- c(3L, 7L, 11L)
status <- "ACTIVE"

R was designed around statistical computing, and its types and missing-value semantics reflect that.

NA represents a missing value, with typed forms such as NA_integer_ and NA_character_. R also has NULL, which is not another spelling of NA, and numeric computation can produce NaN.

These answer different questions. A missing observation in a dataset is not the same thing as the absence of an object. Neither is the same thing as a mathematically undefined result. R treats those as three distinct facts, because in statistics they are three distinct facts, and conflating them produces wrong answers rather than crashes.

Consider:

mean(c(10, 20, NA))
mean(c(10, 20, NA), na.rm = TRUE)

What nothing looks like in R

Spelling	What it means	Who makes you deal with it
`NA`	A missing observation	Functions ask, via `na.rm`
`NULL`	No object at all	Nobody
`NaN`	An undefined numeric result	Nobody

The second call makes an explicit methodological choice to exclude missing observations. The language made you say so.

The field that caused all the trouble

Alex's missing middle name has now been through seven general-purpose languages. Stack those seven tables on top of each other and the third column tells the whole story.

Python gave it None, one undifferentiated nothing. JavaScript offered two and left the meaning to you. C gave a null pointer whose meaning lives entirely in a convention the compiler cannot see. Java made absence available for reference types and impossible for primitives, as a side effect of a decision about memory. Rust put it in the type signature and refused to let you ignore it. Go made it indistinguishable from a valid value unless you reach for a pointer. R split it into three concepts because its users needed three.

Not one of those languages is wrong. They disagree about a prior question: how much does the programmer have to admit they do not know?

Representations of absence carry semantics whether or not the programmer acknowledges them. The difference between these languages is who is required to do the acknowledging, and when.

Which is why the missing middle name turned out to be more interesting than the integer.

The table gets weird quickly

Language	Typing	Ordinary integers	`42` and `0.15` same type?	How absence is spelled
Python	Dynamic	Arbitrary size	No	`None`
JavaScript	Dynamic	Fixed (`BigInt` for more)	Yes, both `number`	`null` and `undefined`
C	Static	Fixed width, chosen	Usually no	Null pointer, by convention
Java	Static	Fixed width	No	`null`, references only
Rust	Static	Fixed width	No	`Option<T>`, in the type
Go	Static	Fixed width	No	Zero values, `nil` for some types
R	Dynamic	Fixed width	Usually distinct	`NA`, `NULL`, `NaN`

Closed sets of alternatives vary just as much. Rust, Java, and C have real enums, Python offers Enum if you reach for it, Go builds them from a named type plus constants, JavaScript models them by hand, and R uses factors. Collections differ too: C, Java, Rust, and Go enforce an element type in the declaration, Python and JavaScript do not, and R's atomic vectors quietly coerce everything toward a common type.

There is no universal translation saying:

Python int = JavaScript number = C int = Java int = Rust i32 = Go int = R integer

Those types overlap. They do not carry identical guarantees, ranges, operations, failure modes, or assumptions.

The same name does not imply the same contract.

If you were designing a language, what would you choose?

This gets much more interesting when you reverse the problem.

Suppose you are designing a language.

You need an integer.

Easy.

Except now you have questions. Fixed widths, or one integer that grows until memory runs out? What happens on overflow? Should 3 become 3.0 on its own? Should "42" + 1 be legal, and if so, what should it mean?

Then absence, which by now you can see is the hard one. Do you have null? Can every reference be null, or do you require an explicit optional type? Do you distinguish a missing observation from a non-existent object? Whichever you choose, every program ever written in your language inherits that decision.

Then collections, where you decide whether elements must share a type and whether values can be moved or consumed. Then domain state, where you decide whether a programmer can say a value is only ever ACTIVE, SUSPENDED, or DELETED, and whether the compiler can prove every case was handled.

Finally, timing. When should a bad type relationship surface: while parsing, during compilation, at runtime, or only when the offending path finally executes?

There is no universally correct set of answers. There are consequences.

Every choice makes some programs easier to express, some mistakes harder to make, some implementations simpler, some runtimes more complicated, and some programmers wonder why on Earth the language designer did that.

Sometimes the answer is historical compatibility. Sometimes performance. Sometimes safety. Sometimes the problem domain.

And sometimes the language designer has a very good explanation and would appreciate it if everyone stopped bringing up typeof null.

One language where absence is not the question

Everything above is a general-purpose language, and every one of them had to decide what nothing means. That is not a universal preoccupation. It is what happens when a language expects you to model a world.

The e language, commonly associated with Cadence Specman, was designed for hardware verification. Verification code describes legal ranges of values, generates constrained test data, and explores systems whose state spaces are far too large to enumerate by hand. So its declarations carry constraints rather than storage categories:

struct customer {
    age : uint (bits: 8);
    keep age in [18..120];

    status : [ACTIVE, SUSPENDED, DELETED];
    keep soft status == ACTIVE;
};

There is no absence card for e in this article, and that is the point. In ordinary application programming we ask what type of value this is. A verification environment asks what values are legal here, and how valid combinations should be generated so we can explore what the system does.

If you look only at Python, JavaScript, Java, and C, it is easy to assume programming languages are all solving approximately the same problem with different punctuation.

They aren't.

Types are compressed language philosophy

At the beginner level, "a type tells us what kind of data a value contains" is perfectly serviceable. Eventually that runs out of road. A type can tell us what values exist, how they are stored, which operations are permitted, which conversions happen silently, what counts as absence, whether absence must be acknowledged, whether alternatives form a closed set, and in some languages how long a value lives and who owns it. "Integer, string, Boolean, float" is not the definition of a type system. It is the introductory vocabulary.

Which is why learning the types in a new language beats memorizing a conversion table.

Python's arbitrary-precision integers are a tradeoff. So is C asking you to care about width. Java's primitive and reference split quietly decides which of your fields are allowed to be empty. Go buys simplicity with zero values and pays for it with ambiguity at the domain boundary. R distinguishes forms of missingness because missing observations are a normal feature of statistical work, so its problem domain is visible in its types. A verification language making constrained generation first-class tells you what its designers expected programmers to spend their days doing.

A language's types are partly a record of what its designers thought mattered, and partly a record of what they were willing to let you avoid thinking about.

They are compressed language philosophy.

Alex survived

After all of this, Alex is still 42, still has no recorded middle name, still likes 3, 7, and 11, and remains active. Nothing about the underlying person changed. But every language forced different decisions about how those facts became computation, and the fact that changed most was the one that was not there.

Knowing that Python has int, Java has int, and Rust has i32 is useful when you are trying to get a program running. Understanding why they are not interchangeable is useful when you are trying to understand languages.

Once you start asking what a language lets you represent, what it makes you acknowledge, and what it refuses to let you say, data types stop being the boring chapter before loops. They become one of the quickest ways to see what a language believes programming should be.

What is the strangest, most useful, or most frustrating type decision you've encountered in a programming language? More importantly, what problem do you think the language designer was trying to solve with it? Or, if you were designing your own language, which of these decisions would you make differently?

We Promise Transparency. Not the "Liquid Glass" Kind.

Tue, 06 Oct 2026 11:10:46 +0000

Let's get the joke out of the way first, because I can already see someone's fingers hovering over the comment box: no, when we talk about "transparency" here, we are not launching a translucent UI skin with rounded corners and a marketing deck about "depth" and "light." Nobody's redesigning your icons to look like they're floating in a glass of water. Apple can keep that one. Transparency, as we mean it, isn't about making things look like glass. It's about making sure there's nothing opaque left to hide behind in the first place.

Transparency Is the Rarest Feature in Modern Software

Here's the uncomfortable observation that started all of this: almost nothing you run today will actually tell you what it's doing. You call a function, and underneath it, a dozen layers you never asked for quietly make decisions on your behalf — a runtime schedules something, an allocator decides where your data actually lives, a framework "helpfully" retries a failed call you didn't know could fail, a standard library wraps three other standard libraries you've never heard of. Most of the time that's a perfectly reasonable trade. Most software genuinely benefits from not making every engineer re-derive memory management from first principles on a Tuesday.

But somewhere along the way, "we abstracted this for your convenience" quietly turned into "we abstracted this so thoroughly that nobody on the team, including us, can tell you with certainty what your program actually does when it touches the kernel." That's not convenience anymore. That's a black box with a changelog. And an entire generation of developers has been trained to treat "it works, don't ask why" as an acceptable final answer, because asking why usually means descending through four more layers of someone else's unexamined assumptions.

Developer transparency, the version we actually care about, is the opposite stance, stated plainly: no hidden magic, no invisible runtime quietly squatting on your CPU cycles like a tenant you never agreed to lease to, and no stack of "convenience" layers standing between your code and the hardware that's supposed to be running it. You should be able to point at any behaviour your program exhibits and trace it to a decision — yours, specifically — not to an abstraction that made the call for you somewhere you'll never see.

This is where Gloria comes in, because it's the sharpest, most literal expression of that idea we've built so far.

What Transparency Actually Looks Like in Gloria

When you write something in Gloria, you know exactly what instruction goes to the CPU, exactly what memory gets mapped, and exactly which register is holding your data at any given moment. You are not down on one knee, hat in hand, begging a heavyweight framework or a sprawling C standard library to please do the thing for you. You own the execution, start to finish, with nobody else's fingerprints on it.

From a Linux perspective, Gloria treats the kernel as its one and only direct interface. No linking against glibc. No standard C startup routine quietly initializing half a universe of state before your main function has even had the decency to run. Gloria generates self-contained, raw ELF64 binaries for AMD64, and that's genuinely all that's in there.

When your code needs to open a socket, allocate memory, or spin up a bit of lightweight concurrency, it doesn't go politely knocking on some third-party wrapper function's door and waiting to be let in. It loads the syscall number straight into RAX, lays out the arguments exactly per the System V AMD64 ABI, and hits the kernel directly with a syscall instruction. No chaperone. No translation layer quietly editorializing your request on the way through. The resulting binaries stay under 9KB, because there is precisely zero runtime bloat riding along for the trip. Put that next to the multi-megabyte "hello world" some modern frameworks ship by default, and you start to get an honest sense of exactly how much weight we've actually cut.

Why This Needed to Exist at All

Here's the pitch, cynicism included at no extra charge: modern systems engineering has gone soft. Not incompetent — soft. Comfortable. Padded on every side with abstractions that exist specifically to protect you from having to understand what your own program is doing. Most software doesn't need to care which register holds a value. This project exists for the software that does, and for the engineers who'd rather know than be protected from knowing.

We wanted something that gives you the raw control and speed of C, the type expressiveness and memory-safety thinking of Rust, and the dead-simple concurrency model of Go — minus the overhead each of those languages still quietly carries around. This is built for the specific kind of developer who needs to wring every last drop of performance out of a box, who's writing ultra-fast microservices, custom network infrastructure, or logic that has to survive on genuinely minimal resources, where every kilobyte and every CPU cycle is a line item somebody's actually tracking, not an abstraction nobody bothers to measure.

The Roadmap, Stated Without the Usual Hedging

Our self-hosting plan is straightforward and, I'll admit, a little uncompromising. Right now, the ForgeZero compiler, fz, is written in Go. That's a deliberate choice, not a compromise we're quietly hoping nobody notices — Go let us bootstrap the language fast, iterate on syntax without a chicken-and-egg problem slowing every decision down, and shake the remaining edge cases out of the lexer, parser, and semantic checker while the ground was still allowed to move under our feet.

But Go is a bridge, not a destination. The actual milestone the entire Gloria ecosystem is being built toward is full self-hosting. We're building out the language constructs, inline assembly support, and memory primitives specifically so that Gloria can eventually compile its own compiler, from scratch, with nothing borrowed. The day fz is rewritten in pure Gloria is the day we cut the last external dependency loose entirely — and the day this architecture stops being "an interesting idea with training wheels" and starts being something you can point at and say, flatly, that it's ready for serious production.

That's the whole philosophy, really, scaled up from one register to an entire compiler: nothing in this stack should exist that we can't fully explain, and nothing should run that isn't accountable to someone who actually understands it.

Watch It Happen Instead of Reading About It Later

If any of this is the kind of problem that genuinely interests you — not the polished retrospective six months from now, but the actual process, bugs included — we post it all in close to real time on our Telegram channel, @forgezeroteam. Build updates, broken things, fixed things, syntax decisions argued out loud before they're final. It's faster and considerably more honest than waiting for the cleaned-up version to show up here.

No liquid glass. No rounded corners pretending to be depth. Just a binary you can actually read, a register you can actually name, and a compiler that, one day soon, won't owe its existence to anything but itself.

Resistors: How to read the stripes, do the math, and avoid the magic smoke

Thu, 17 Sep 2026 10:10:48 +0000

If you have ever popped the back off anything with a circuit board inside, you have seen resistors. They are the little striped cylinders, the tiny black rectangles, the ceramic blocks bolted to a heatsink. They are everywhere, and most of them look like they should be interchangeable — yet a 220 Ω part and a 10 kΩ part are about as similar as a paperclip and a coat hanger.

This guide is the page I wish every beginner landed on first. By the end you will be able to read any resistor by eye, know why a 47 Ω value exists instead of a sensible 50 Ω, pick a part that will not catch fire, and work through the three bits of math that cover maybe 90% of real-world resistor use.

What a resistor actually is (and why your circuit cannot live without one)

A resistor is a two-legged component whose only job is to get in the way. It opposes the flow of electric current, and it does so by turning some of that electrical energy into heat. That is the whole trick. No moving parts, no magic, just a controlled amount of "don't."

The amount of opposition is called resistance, measured in ohms (symbol: Ω, the Greek capital omega). One ohm is the resistance you get when one volt of pressure pushes one amp of current through. That definition is worth holding onto, because it tells you exactly what a resistor is doing in plain terms: it sets the relationship between voltage (pressure) and current (flow).

The rule that ties those three together is Ohm's law:

V = I × R

Voltage equals current times resistance. Rearrange it however you like — I = V / R or R = V / I — and you have the single equation that explains every resistor in every circuit.

Here is the mental model that actually sticks. Think of current as water flowing through a hose. Voltage is the water pressure from the tap. A resistor is a constriction in the hose — a kink, a narrow section, a thumb pressed over the end. The tighter the constriction, the less water gets through for a given pressure. A 10 kΩ resistor is a tight kink; a 10 Ω resistor is barely there.

Two things follow from this, and they explain most resistor behavior:

A resistor cannot create energy, only waste it. Engineers call it a passive component. It does not amplify, it does not oscillate, it just sits there converting current into a little warmth. (That "little warmth" is exactly why a too-small resistor smells bad and lets out smoke — more on that later.)
The resistance comes from the material, not the label. At the microscopic level, a resistor is made from a conductor that is deliberately not a great conductor — carbon, a metal-oxide film, a coiled wire. Electrons trying to cross it keep bumping into atoms, and each bump is a tiny conversion of motion into heat. Change the material, its length, its thickness, or its temperature, and you change the resistance.

That is the whole conceptual foundation. Everything below is just applying it.

Reading resistor values: color codes, demystified

Through-hole resistors (the striped cylinders) almost never have numbers printed on them — there is no room, and the paint would wear off. Instead they carry their value as colored bands. Once you learn the code, you can read a resistor across a room.

Most resistors you meet are 4-band, 5-band, or 6-band:

4-band (the common hobbyist part): two digits — a multiplier — a tolerance band.
5-band (precision parts): three digits — a multiplier — a tolerance band.
6-band: same as 5-band, plus a final band for temperature coefficient.

The first one to three bands are the significant digits. The next band is the multiplier — it tells you how many zeros to tack on (or, for gold and silver, a fraction). The band after that is tolerance — how far off the real value is allowed to be.

Here is the full table:

Three worked examples you will see constantly

A 220 Ω resistor (the classic LED current-limiter): Red — Red — Brown — Gold → 2, 2, ×10, ±5% = 22 × 10 = 220 Ω ±5%. This is the part we reach for on a 5 V logic rail or a bright LED.

A 1 kΩ resistor (the default pull-up / current-limiter): Brown — Black — Red — Gold → 1, 0, ×100, ±5% = 10 × 100 = 1,000 Ω = 1 kΩ ±5%. If a tutorial says "just use 1k," this is the stripe pattern.

A 10 kΩ resistor (the standard microcontroller pull-up): Brown — Black — Orange — Gold → 1, 0, ×1,000, ±5% = 10 × 1,000 = 10,000 Ω = 10 kΩ ±5%. Almost every Arduino "connect a button" sketch assumes a 10 kΩ pull-up.

A mnemonic that actually works

The digits map to a sentence everyone learns: "Bad Beer Rots Our Young Guts But Vodka Goes Well — Get Some Now." Black, Brown, Red, Orange, Yellow, Green, Blue, Violet, Grey, White, (Gold, Silver, None). Silly, but you will never forget the order.

Surface-mount resistors and their secret codes

Once you leave the breadboard and move to a manufactured board, resistors shrink into tiny black rectangles with no room for stripes. They carry numbers instead, and the system is simpler than it looks.

3-digit code (5% and 10% parts): the first two digits are significant, the third is the number of zeros.

471 = 47 followed by one zero = 470 Ω
103 = 10 followed by three zeros = 10 kΩ
100 = 10 followed by zero zeros = 10 Ω

4-digit code (1% parts): three significant digits, then the number of zeros.

4700 = 470 followed by no zeros = 470 Ω
1002 = 100 followed by two zeros = 10 kΩ

EIA-96 code (1% precision on tiny packages): two digits plus a letter. The digits are an index into the E96 value table (01 = 100, 02 = 102 ... 96 = 976), and the letter is the multiplier: A = ×1, B = ×10, C = ×100, D = ×1 k, E = ×10 k, F = ×100 k. So 01A = 100 × 1 = 100 Ω, and 68A = 487 × 1 = 4.87 kΩ.

You will also see a package size like 0402, 0603, 0805, or 1206. Those four digits are the size in hundredths of an inch: 0402 is 0.04 × 0.02 inches. Smaller is cheaper and lighter but harder to solder by hand and carries less power. A 1206 can usually take about 0.25 W; a 0402 is often rated at just 1/16 W (0.0625 W), which is why power math matters so much on tiny boards.

Rule of thumb: build on a breadboard or by hand, use through-hole; design a PCB you will manufacture, use SMD — and size the package to the wattage, not just the value.

Why resistors come in weird values: the E12 and E24 series

Here is a question that trips everyone up. Why is there a 47 Ω resistor and a 4.7 kΩ resistor, but no 50 Ω or 5 kΩ in the common bins? Why 33 Ω and 330 Ω instead of a round 30?

The answer is that resistor values are spaced geometrically, not arithmetically. Manufacturers do not pick random numbers; they use the E-series. An E12 resistor (±10% tolerance) has 12 values per decade, and each one is about 21% larger than the last — because a part can drift by up to 10% either way, the next value needs to start roughly where the previous one could have ended. The E12 values are:

10, 12, 15, 18, 22, 27, 33, 39, 47, 56, 68, 82 — then ×10 for the next decade (100, 120, 150 ...).

E24 (±5% tolerance) squeezes in 24 values per decade by halving that step:

10, 11, 12, 13, 15, 16, 18, 20, 22, 24, 27, 30, 33, 36, 39, 43, 47, 51, 56, 62, 68, 75, 82, 91.

That is why 47 Ω exists: it is the E12/E24 value nearest a "round" 50, and the geometric spacing guarantees that no matter which value you need, a standard part is close enough that tolerance absorbs the rest.

The practical takeaway: when a design calls for "about 5 kΩ," you reach for the standard 4.7 kΩ or 5.1 kΩ, not a custom 5.00 kΩ part. Standard values are cheaper, always in stock, and what every calculator and simulator assumes.

Power ratings and tolerance: the specs that actually burn

This is the section most thin guides skip — and the one that determines whether your circuit works next week or smells like burnt plastic tomorrow.

Wattage

Every resistor has a power rating in watts (W). The common through-hole sizes are 1/4 W (0.25 W), 1/2 W (0.5 W), 1 W, and up into the many-watt "power resistor" range. The rating is the maximum heat the part can shed into still air without overheating.

Three formulas tell you how much power a resistor is actually dissipating. They are all the same idea, just solved for what you happen to know:

P = I² × R · P = V² / R · P = V × I

Worked example. Put a 220 Ω resistor straight across a 5 V supply. Using P = V² / R: 25 / 220 ≈ 0.114 W. That is 114 mW, comfortably under a 1/4 W part's 250 mW limit. Safe.

Now try a 10 Ω resistor across the same 5 V rail: 25 / 10 = 2.5 W. A 1/4 W resistor would be dissipating ten times its rating — it would glow, then fail. You would need a proper power resistor here. The value was "fine" by Ohm's law; the wattage is what bit you.

Tolerance: when 5% is plenty and when it is not

Tolerance is how far the real resistance can drift from the labeled value. A ±5% 1 kΩ resistor is anywhere from 950 Ω to 1,050 Ω. A ±1% part stays between 990 Ω and 1,010 Ω.

For most jobs — limiting an LED, pulling up a pin, setting a gain roughly — 5% is perfectly fine and cheaper. Reach for 1% (or better) when the resistor sets a precision reference: a measurement divider, a filter frequency, an ADC scaling network. There, a 5% shift changes the answer you read.

Temperature coefficient (tempco)

The sixth band on a precision resistor is its temperature coefficient of resistance (TCR), given in ppm/°C — parts per million per degree Celsius. A 100 ppm/°C resistor changes by 100 Ω per million ohms (0.01%) for every 1 °C of temperature shift. Brown's 100 ppm is typical for cheap film; grey's 1 ppm is laboratory-grade. For anything indoors at room temperature, tempco barely matters; for a sensor you leave in the sun or a meter you trust, it is the difference between "close" and "wrong."

The derating curve (this is the part that saves parts)

A resistor's wattage rating is only valid at a specific ambient temperature — usually 70 °C. Above that, it cannot shed heat as well, so the safe power drops. The standard curve (per IEC 60115-1, and you will see the same shape on every major datasheet) runs at 100% up to 70 °C, then falls in a straight line to zero watts at 155 °C.

What this means in practice: a resistor rated 1/4 W at room temperature is only good for about half that inside a sealed enclosure that sits at 110 °C. If your circuit runs hot, either pick a bigger package or do the math at the derated value, not the headline number.

Types of resistors and when to reach for each

Not all resistors are the same inside, and the differences show up as noise, precision, and how they behave at temperature and frequency.

Carbon film vs. metal film. For blinking an LED or pulling a pin high, carbon film is all you need and costs a fraction of a cent. Choose metal film when the resistor is in the signal path you actually care about — a preamp, a voltage reference, an ADC front-end — because its lower noise and tighter tempco keep the signal clean.

Wirewound and high-power. When wattage is the problem, wirewound parts (often ceramic-bodied, sometimes bolted down) are the answer. The catch: that coil of wire acts like a tiny inductor, so avoid them in high-frequency RF paths where a "resistor" that also stores magnetic energy misbehaves.

Variable resistors. A potentiometer is a three-terminal divider you turn with a knob or screwdriver; a rheostat is the two-terminal version used as a variable resistance. Same component family, different wiring. Use them where a value needs to be set by a human, not baked into the board.

The math you will actually use

Three formulas cover almost everything. You already have Ohm's law and the power equations. Now the circuit configurations.

Resistors in series and parallel

Series (stacked end to end): resistances simply add.

R_total = R₁ + R₂ + ...

Two 10 kΩ resistors in series make 20 kΩ.

Parallel (side by side, sharing both nodes): the reciprocals add.

1 / R_total = 1/R₁ + 1/R₂ — or, for just two, R_total = (R₁ × R₂) / (R₁ + R₂)

Two 10 kΩ resistors in parallel make 5 kΩ. Parallel is how you "split the heat" too: two 1/4 W parts in parallel can handle what one cannot.

The voltage divider

Put two resistors in series across a supply and the point between them sits at a fraction of the voltage, set by the ratio:

V_out = V_in × (R₂ / (R₁ + R₂))

With 5 V in and two equal 10 kΩ resistors, the middle sits at 2.5 V. Make R₂ bigger than R₁ and the tap point rises; make it smaller and the tap falls. This is how you step a 5 V sensor signal down to the 3.3 V your microcontroller can read, how you set a comparator's trip point, and how you bias a transistor's base.

Calculating an LED current-limiting resistor

An LED is not a resistor; left directly across a supply it draws as much current as it can and burns out. You add a resistor to set the current. The formula:

R = (V_supply − V_forward) / I

where V_forward (Vf) is the LED's rated drop (about 2 V for red, 3.2 V for blue/white) and I is the current you want (typically 20 mA = 0.020 A, but 10 mA is fine for indicator use).

Example: a red LED (Vf ≈ 2 V) on a 5 V rail, wanting 15 mA: R = (5 − 2) / 0.015 = 200 Ω. The nearest common E12 value is 220 Ω, which gives (5−2)/220 ≈ 13.6 mA — a safe, bright-enough choice.

Common mistakes (and how to avoid a smoky resistor)

A short list of the errors that actually happen on the bench:

Reading red as orange (or vice versa). They sit next to each other in the mnemonic and look similar under warm light. Red is 2 / ×100; orange is 3 / ×1 k. One band off is a 10× value error. Use the calculator, or measure with a meter, when it matters.
Under-rating the power. A resistor can be the right value and still overheat. Always run P = V² / R and leave headroom — a 1/4 W part should rarely sit above ~125 mW in real use.
Forgetting the derating curve. That 1/4 W number is for 70 °C and below. In a hot enclosure, it is not 1/4 W anymore.
Floating input pins. A pull-up or pull-down resistor only does its job if it is actually connected to the pin and to the rail. A missing or misplaced resistor is why a button "sometimes" works.
Mixing up tolerance needs. Do not pay for 1% parts in a LED limiter, and do not cheap out with 5% parts in a measurement divider. Match the tolerance to the job.
Assuming SMD size = value. A 1206 is not "more ohms" than a 0402; it just handles more watts. The number on the body is the value; the package is the power.

This is a part of the full guide. The original on CircuitForge also includes interactive 3D component viewers, a live color-code calculator, embedded simulator circuits, and a full FAQ section — all of which are easier to use in a browser than in a blog post.

You can read the complete version with all the interactive tools here: (https://luvaai.in/learn/complete-resistor-guide)

Whizz: Your Esoteric Language that's Short as BF, but Easier to Write

Thu, 30 Jul 2026 21:29:04 +0000

I just made Whizz, an esoteric programming language that is full of capability and possible experimentation. Before I interest you in that, I'll explain to you something.

What is an esoteric programming language?

An esoteric language (or an esolang, colloquially), is a programming language designed to not fit the coding 'norms' or conventions.

Take an example: BF ('BF' is an abbreviation and euphemism of brainf***).

A standard language would notate a 'Hello, World!' program as something like:

print("Hello, World!")

BF, on the other hand, requires something like this:

++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.

As you can see, BF, like most esolangs, is different: it's hard to write and a puzzle.

Whizz is inspired by BF, as its incrementing, decrementing and looping are inspired by it.

I made Whizz because I thought languages like BF were way too monotonous to write. Esolangs should be hard and puzzling to write, but not laborious.

BF requires you type '+' as many times you want to increment (without loops): so you have to find shortcuts and unscalable solutions, just to achieve your goal. In Whizz, just type that incrementation repetition count before the '+' sign, and there you have it!

These wonderful features that Whizz boasts keep the challenge in esolang-ing, but contradictorily makes it more 'scalable'. Another notable feature is functions: the epitome of order.

An example of a Whizz program would be:

zeroToNine {
   [ create variables ]
   counter 10+ [ track state ]
   char 48+ [ print this one ]
   space 32+ [ space char ]
 
   (
     char!+ [ print and increment char ]
     counter-; [ decrement counter and end if zero ]
     space! [ print space ]
   )
}

zeroToNine*

This, self explanatorily, outputs '0 1 2 3 4 5 6 7 8 9'. Again, in minimized form:

c10+n48+s32+(n!+c-;s!)

I genuinely hope you experiment with Whizz, and solve puzzles & challenges with it, as if it were BF!

Install it with the ease of a terminal command:

pip install whizz

If you have MacOS, use pip3.

Then, learn the usage & syntax instructions.

Please share your thoughts, and constructive feedback is absolutely encouraged.

Learn more about Whizz at the main site.

Bye!

Why the Power-of-Two Trick Works for Binary Fractions (And Why It Breaks for Everything Else)

Sat, 11 Jul 2026 13:03:17 +0000

As a 300-level Mechatronics Engineering student studying Digital Electronics, I came across something that changed the way I think about binary conversions — not just as steps to memorize, but as operations with real mathematical meaning underneath them.

Understanding Binary Coded Decimal (BCD) First

Before getting to the trick, it helps to understand Binary Coded Decimal (BCD), specifically the weight codes assigned to binary digits. In a 4-bit system, the weights are 8, 4, 2, 1 (the 8421 code). In a 3-bit system, they are 4, 2, 1 (the 421 code). These codes make binary-to-decimal conversion straightforward.

For example, converting 1111 in base 2 to decimal is simply:

8 + 4 + 2 + 1 = 15

The same logic extends to binary numbers with a fractional part. To convert 1111.0111 from base 2 to decimal, you group the digits in 4-bit sections and apply the weights:

Whole part:      1111 → 8 + 4 + 2 + 1 = 15
Fractional part: 0111 → 0 + 4 + 2 + 1 = 7
Result: 15.7 in decimal

This direction — binary to decimal — is fairly intuitive once you understand BCD weights. The real challenge comes when you go the other way.

The Problem with Decimal to Binary Conversion

Converting a decimal fraction to binary using the standard repeated multiplication method works, but it is long and error-prone. The method requires you to multiply the fractional part by 2 repeatedly, recording the integer part each time and discarding it, until nothing remains. For some numbers this goes on for many steps, and one mistake anywhere gives you a wrong answer.

That frustration is what sparked the idea I want to share here.

The Fraction Shortcut

What if instead of using repeated multiplication, you convert the decimal fraction to a fraction first, then use BCD weight codes to handle the conversion? This connects directly to the concept of fixed-point arithmetic used in embedded systems.

Example 1: Converting 0.25 to Binary

0.25 as a fraction is 1/4. Assuming a 4-bit operation:

Numerator: 1 in binary (using 8421 BCD) → 0001
Denominator: 4 in binary → 0100

Dividing 0001 by 0100 in binary gives 0.01₂.

Tip: Dividing by a power of 2 in binary is equivalent to shifting the binary point to the left — the same way dividing by 100 in decimal shifts the decimal point two places left.

Using the standard multiplication method on 0.25 gives the same answer: 0.01₂. But the fraction method shows why — it is not magic, it is a point shift.

Example 2: Converting 0.625 to Binary

0.625 as a fraction is 5/8.

Numerator: 5 in binary → 101
Denominator: 8 in binary → 1000

Dividing 101 by 1000 gives 0.101₂.

Verified with the multiplication method: 0.101₂ ✓

Example 3: Converting 0.4375 to Binary

0.4375 as a fraction is 7/16.

Numerator: 7 in binary → 0111
Denominator: 16 in binary → 10000

Using BCD weights (16, 8, 4, 2, 1), dividing gives 0.0111₂.

Verified with the multiplication method: 0.0111₂ ✓

Where This Breaks Down

This shortcut works if and only if the denominator is a power of 2 — that is, 2, 4, 8, 16, 32, and so on.

Try it with 0.2, which as a fraction is 1/5. The denominator is 5, and 5 in binary is 101. Since 101 is not a power of 2, there is no clean point shift. You would have to perform full binary long division, and the result never terminates — it repeats forever as 0.00110011...

Note: This is the same reason 0.1 + 0.2 does not exactly equal 0.3 in most programming languages. The decimal 0.1 is 1/10, and since 10 is not a power of 2, it cannot be represented exactly in binary. This is not a bug — it is a structural limitation of representing base-10 fractions in a base-2 system. Learn more about this in the IEEE 754 floating-point standard.

Conclusion

The power-of-two fraction shortcut offers a clearer, more intuitive path for converting certain decimal fractions to binary. Rather than blindly following the repeated multiplication algorithm, converting the decimal to a fraction and applying BCD weight codes reveals the actual mathematical operation taking place — a simple binary point shift. This works cleanly for denominators that are powers of 2 (such as 2, 4, 8, 16), giving the same result as the standard method while making the reason visible. However, it has a clear limitation: denominators that are not powers of 2 produce non-terminating binary fractions, requiring long division instead. Understanding this boundary does more than just solve conversion problems — it explains one of the most well-known quirks in floating-point arithmetic. The goal of this article was never to introduce a new method, but to show that understanding the structure behind an algorithm is always more powerful than memorizing its steps.

Building an Anti-Proxy -Offline-First Attendance Platform with Next.js, Express & Firebase

Sat, 11 Jul 2026 03:43:18 +0000

Traditional attendance systems seem simple until you look at how they work in practice. Manual roll calls consume valuable class time, paper attendance sheets are inefficient, and many QR-based systems can still be exploited through proxy attendance.

I wanted to explore whether a better solution was possible.

This project is my attempt at designing and building an offline-first anti-proxy attendance platform from scratch as a solo developer. The goal wasn't just to digitize attendance, but to create a system that remains reliable in real-world environments while prioritizing security, scalability, and a smooth user experience.

The platform is built using Next.js 16, React 19, TypeScript, Express.js, Firebase Authentication, Firestore, Firebase Admin SDK, Tailwind CSS, Capacitor, Progressive Web Apps (PWA), Sentry, and dynamic QR-based authentication.

Rather than focusing only on features, this article explores the engineering decisions behind the project: why I chose an offline-first architecture, how dynamic QR validation improves security, the reasoning behind the technology stack, the challenges I faced during development, and the lessons I learned while building a production-style application that is already being used in my college club.

The project is still evolving, and I continue to improve it whenever I have time. My aim is to keep documenting that journey by sharing not only what works, but also the mistakes, trade-offs, and architectural decisions that shaped the system.

If you're interested in full-stack development, system design, Next.js, Firebase, TypeScript, or building software that solves practical problems, I hope you'll find something valuable in this article.

⭐ GitHub: https://github.com/siddarthpatelkama

LinkedIn: https://www.linkedin.com/in/siddarthpatelkama

I'm always open to feedback, suggestions, and discussions with fellow developers. If you have ideas for improving the project or questions about the implementation, I'd love to hear from you.

Understanding CoALA: A Cognitive Architecture for Language Agents (2023)

Wed, 08 Jul 2026 06:43:56 +0000

Note: This article is a summary and interpretation of the research paper

Cognitive Architectures for Language Agents
(2023) by Michael Sumers, Shunyu Yao, Karthik Narasimhan, and Thomas L. Griffiths. Rather than proposing a new architecture, the goal here is to explain the paper's core ideas in an accessible way and explore why they matter for the future of AI memory systems.

Modern language agents feel intelligent, but under the hood they are still fragile systems stitched together with prompts, context windows, and external tools. The CoALA framework (Cognitive Architectures for Language Agents) proposes a more structured view: instead of treating LLMs as standalone reasoners, we should treat them as components inside a cognitive system with memory, actions, and decision loops.

At the center of this framework is a simple idea borrowed from cognitive science: intelligence depends heavily on how memory is structured.

CoALA breaks memory into four interacting systems: working memory, episodic memory, semantic memory, and procedural memory.

Working Memory: The Active Scratchpad

Working memory is the agent’s current “mental workspace.”

It contains everything the model is actively using right now:

the current prompt or conversation
intermediate reasoning steps
tool outputs
short-lived goals and constraints

In CoALA terms, this is the active state used for the current decision cycle. It is not persistent. Once the cycle ends, it disappears unless explicitly stored elsewhere.

You can think of it as the agent’s RAM fast, limited, and constantly overwritten.

Most LLM systems today stop here. That is why they feel intelligent but inconsistent: they reason well in the moment, but forget the structure that produced good decisions.

Episodic Memory: What Happened Before

Episodic memory stores experiences over time.

Instead of storing abstract facts, it stores:

past interactions
task trajectories
failures and corrections
sequences of actions taken in specific contexts

Example:

The agent tried to deploy a service, forgot database migrations, caused a rollback, then fixed it by adding a pre-deploy migration check.

This is important because intelligence is not just knowing facts it is learning from sequences of events.

In CoALA, episodic memory supports learning from history, enabling agents to improve across repeated tasks instead of resetting every session.

Without episodic memory, agents repeat mistakes endlessly.

Semantic Memory: What the Agent Knows

Semantic memory is the system’s store of general knowledge.

This includes:

facts about the world
domain knowledge
definitions and relationships
stable abstractions

Example:

PostgreSQL requires schema migrations before deployment in production systems.

Unlike episodic memory, semantic memory is not tied to a specific experience. It is decontextualized knowledge that can be reused across situations.

In modern systems, this is often implemented through:

vector databases
retrieval-augmented generation (RAG)
knowledge graphs

Semantic memory is what allows agents to “know things” even if they have never directly experienced them.Procedural Memory: How to Do Things

Procedural memory stores skills and action patterns.

This is not about facts or past events. It is about behavioral structure:

step-by-step workflows
tool usage patterns
decision heuristics
learned strategies

Example:

To deploy safely: run tests → build → apply migrations → deploy → verify health checks.

This type of memory is critical because it encodes execution ability, not just knowledge.

In CoALA, procedural memory can live in:

explicit rules
agent code
learned policies
tool-use patterns embedded in prompts or fine-tuning

Without procedural memory, an agent may “know” what to do but fail to consistently execute it.

Why These Four Matter Together

The key insight in CoALA is that intelligence emerges from coordination between memory types, not from scaling a single context window.

Working memory handles the present
Episodic memory improves learning from experience
Semantic memory provides knowledge grounding
Procedural memory encodes behavior and execution

Most current LLM systems collapse all of this into one space: the prompt. CoALA argues that this is fundamentally limiting.

Instead, memory should be treated as a structured system with different persistence rules, update mechanisms, and retrieval strategies.

Closing Thought

CoALA reframes language agents not as chat models, but as cognitive systems with modular memory and structured decision loops. It connects modern LLM tooling back to decades of cognitive science, showing that we are rebuilding ideas that were already explored in symbolic AI just now with language models as the core engine.

This raises an interesting question: if AI can organize memories like humans, can memory do more than just retrie

Reference:

Sumers, T. R., Yao, S., Narasimhan, K., & Griffiths, T. L. Cognitive Architectures for Language Agents. arXiv, 2023. https://arxiv.org/abs/2309.02427

Not Worthless. Just Not Found Yet. - On verification work that arrives before anyone asks for it

Tue, 23 Jun 2026 08:00:00 +0000

The shape of the work right now

Zenodo views: 1. Downloads: 0. No external citations to the ledger to date.

The code still runs.

That is the uncomfortable shape of this work right now. A full Flamehaven cycle can take three weeks, sometimes six months or more: theory, repo, verification, result artifact, paper, ledger. No client asked for it. No deadline forced it. No market signal arrived to confirm that it mattered.

So the question becomes simple, and not very flattering:

Is this verification work, or just elaborate work done in a room nobody enters?

My answer is that those are different questions. Visibility asks whether people are watching. Provenance asks whether the work survives being checked later, by anyone, including a future version of us. In AI-era research, I think that second question is becoming the scarce one.

This work is not valuable because someone is watching it.

It is valuable because, when trust in AI-generated output becomes scarce, already-verifiable work becomes rare. Not worthless. Not yet found. Those are not the same thing, and the rest of this is about why the difference matters.

How one cycle actually runs

From the outside it looks like "wrote a paper." In practice, six stages chain together in sequence.

Theory — Fix the boundary of the claim before anything else: what you will assert and, just as importantly, what you will not.
Repo — Translate theory into code. The code doesn't prove the theory; it renders the theory into something falsifiable and checkable.
Verify — The harness checks whether the code is internally self-consistent and actually respects the boundary defined upstream.
Result — Numbers, pass/fail counts, degraded-pass flags, dropped into a file. Not a hand-written summary. An artifact produced by execution.
Paper — Interprets the result. Does not stand in for it.
Ledger — Timestamps and keeps the trace of the entire cycle. When someone wants to re-verify the same theory later, the repo, result, and paper from that moment are still there, unchanged.

The reason these six stages run in strict order every time is simple: skip one, and the next stage proceeds unverified. Build the repo before fixing theory, and you end up writing code without knowing what it's supposed to test. Write the paper before running verify, and the paper ends up describing what the code was supposed to do rather than what it actually did. Skip ledger, and the next cycle has no way to audit the one before it.

This scaffold isn't rebuilt from scratch for every project.

The same skeleton gets reused. QSOT2 is one instance of that skeleton applied to the quantum-channel domain.

The two-axis problem this cycle is built against

A result.json that took days to build, and nobody opens it. A claim_boundary field designed with real care, and nobody who'd recognize what it's doing. The time was real. Almost none of it registers as value from the outside.

Answering that doubt requires reframing the question. Not who's watching, but whether this is the kind of problem worth watching in the first place. The evidence splits cleanly into two axes.

The first is output contamination. In May 2026, arXiv began enforcing a one-year submission ban for papers found to contain incontrovertible evidence of unchecked generative AI use, including hallucinated references — leftover meta-commentary addressed to or from the model counts as well. [1]

The scale behind that policy is documented: the rate of papers containing at least one fabricated reference went from roughly 1 in 2,828 in 2023 to 1 in 458 in 2025 to 1 in 277 in the first seven weeks of 2026, close to a twelvefold rise. A study co-authored by arXiv founder Paul Ginsparg audited 111 million references across arXiv, bioRxiv, SSRN, and PubMed Central, and found a conservative estimate of 146,932 hallucinated citations in 2025 alone. [2]

Copy-pasted prompt residue, citations to papers that don't exist — this isn't an edge case anymore. It's a statistically detectable frequency.

The second is reproduction failure. OpenAI's PaperBench evaluated AI agents on the task of replicating 20 ICML 2024 papers from scratch, graded against 8,316 rubric items. [3] The best-performing tested agent scored 21.0%. Human ML PhDs, given 48 hours on a comparable subset, reached 41.4%.

That doesn't mean AI agents are useless for research. It means fluent generation and successful reconstruction are still very different capabilities. On this benchmark, the strongest tested agent reached roughly half the human baseline on the comparable subset, and that gap matters precisely because the output can look competent before anyone re-runs it.

What the cycle answers back with

These are two stages of the same failure. The first is that submitted output often carries contamination straight through, unchecked. The second is that even output which clears that bar doesn't reproduce when someone actually re-runs it. Embedding claim_boundary directly in code is one response. Letting DEGRADED_PASS fire automatically is another. Together, they turn the claim into something the repo has to keep surviving, not something written once and trusted forever.

This isn't a concern unique to us. The broader research ecosystem is already circling the same problem from different angles: provenance, transparent reporting, dataset documentation, model cards, correction mechanisms, reproducibility.

One academic paper argues that universities and research communities need to build provenance infrastructure that anchors AI-era scholarship, since generative AI has made it trivial to produce fluent, polished, but unsubstantiated output. [4]

Elsevier's 2025 Researcher of the Future report found that 58% of researchers already use AI tools for work, while only 22% rate current GenAI tools as trustworthy. [5][6] 85% agreed that corrections and retractions help preserve the integrity of the scholarly record. Adoption and distrust are rising together, not trading off against each other.

That is the gap Flamehaven is trying to work inside. Not as an institution. Not as a standard-setting body. Just as a small project asking one narrow question repeatedly:

Can the claim, code, result, paper, and ledger still point to each other after the attention has moved on?

Not a system. A small pond.

Looked at in isolation, QSOT2 can seem like overkill — this much scaffolding for a toy model with no new physics in it. That objection is fair. It's also the point. QSOT2 isn't presented as new physics. It's a controlled pond for testing whether the verification skeleton stays clear.

claim_boundary, the DEGRADED_PASS verdict logic, flagging patterns like riemann_is_toy — none of this is QSOT2-specific. Wrap the same harness around a different phenomenological model and the same tier of verification carries over unchanged. BioAI auditing, RExSyn-Nexus, CR-EP all share the same skeleton.

Taken one at a time, each output looks worthless. Underneath, it isn't code rebuilt from zero each time. It's a structure built once and reused continuously — the important part is that the same skeleton is being grafted onto new domains, not redesigned for each one.

Calling Flamehaven a system would overstate it.

Right now it's closer to a small pond fed by a creek. The water is clear enough that you can see the bottom, and anything happening in it can be checked by anyone who looks. Murky water isn't a default we accept. Exposing riemann_is_toy instead of quietly dropping it is the same choice: keep the water clear rather than cloud it to look more impressive.

A pond isn't a grand thing on its own. But a pond that stays clear and stable, over time, tends to attract life.

Frogs lay eggs. Pondweed takes root. Birds come to drink. None of this was designed top-down as an ecosystem from day one — it's what happens when one body of water is kept clear long enough that a small ecosystem accretes around it on its own.

What the clarity is actually worth

The pond metaphor only works if “clear” stops being a mood and becomes something an outsider can inspect. In this context, clear means fewer hidden dependencies, fewer interpretive layers, and fewer places where the paper can make the result look cleaner than the execution actually was.

That is why the technical details matter.

Machine-epsilon-level CPTP verification runs on nothing but NumPy. 31 of the 35 core checks complete using pure NumPy, no PyTorch, no GPU. This does not make the work important by itself. It makes the work easier to re-run, easier to question, and harder to hide behind infrastructure.

So QSOT2's view count and download count aren't the metric that matters here. The metric is how many other domains this skeleton has been grafted onto, and whether each graft required redesigning from scratch. That answer is already accumulating, one instance at a time.

The useful test for any of this isn't whether someone agrees with the paper.

Agreement is cheap. The useful test is whether they can clone the repo, inspect the claim boundary, re-run the verification harness, compare result.json, and see the same ledgered output that existed before they arrived. That's the level where this work wants to be judged.

Living with worthlessness, rather than defeating it

The problem is that this is not the level where the visible market usually judges work.

The visible market still rewards velocity and virality more than verification scaffolding. This isn't work the market has learned how to price yet, and that's a different problem than the work being wrong.

So the task is not to defeat worthlessness with a louder story.

It is to tolerate a state that looks worthless while refusing to cloud the water before a signal arrives confirming that judgment was wrong. Recognition arriving late and recognition never arriving are different outcomes. There's no way to distinguish between them right now. What's been available, so far, is to hold the form steady and wait.

We have been waiting.

Not for Flamehaven to be noticed. That would be the wrong story. What we were waiting for, although we could not have named it cleanly at the time, was for the pressure itself to become public: the sense that proof-shaped output can outrun disclosure, that claims can separate from the artifacts meant to hold them, and that human responsibility can become decorative after the machine has already produced something convincing.

It arrived not as recognition, but as language.

When the outside world starts naming the same problem

In June 2026, a working group of sixteen researchers from fifteen universities published the Leiden Declaration on Artificial Intelligence and Mathematics, drawn from a Lorentz Center workshop the previous September that had brought together around sixty researchers from ten countries. [7]

The declaration is now officially endorsed by the International Mathematical Union. It names, in the language of mathematics, the same family of failure modes this piece has been circling. Automated techniques can produce results that look convincing but contain almost invisible errors, difficult to distinguish from genuine mathematical proofs, putting traditional standards of correctness, transparency, and independent verifiability under pressure.

Results communicated through press releases or blog posts, ahead of peer review and without the disclosure needed for scientific evaluation, are named as a direct threat to proper evaluation.

The Declaration's first recommendation for individual researchers is to disclose tool use explicitly, in a dedicated section, and to retain exclusive human responsibility for the correctness of any automated result.

That does not mean the Leiden Declaration validates Flamehaven. It means something narrower, and more useful: the failure mode Flamehaven was built around is no longer just an internal concern. Plausible-but-unreliable automated output, weak disclosure, missing provenance, and human accountability drifting away from machine-generated claims are now being named by the mathematical community itself, with institutional backing behind it.

claim_boundary and DEGRADED_PASS are not the Declaration in code. They are one small attempt to operationalize the same family of concern at the artifact level, built before that concern reached us as a public declaration with institutional backing.

Not because anyone here anticipated that working group, but because the underlying problem was already visible at small scale, one quiet result.json at a time.

A working alignment note mapping the Flamehaven verification cycle against each of the Declaration's recommendations is now on the ledger, section by section, including the places where the cycle currently falls short of what the Declaration asks for. [8]

This kind of naming has happened before

Once a field begins naming its own failure mode, the next question is not whether the language is elegant. The question is whether anyone changes behavior before an external authority forces them to.

That is why the historical comparison matters.

In 1975, recombinant DNA researchers gathered at Asilomar after parts of the field had already entered a voluntary pause, worried that the technology had outpaced anyone's ability to assess its risk. [9]

Roughly 150 scientists debated guidelines from scratch over four days, and the NIH later used those recommendations as a template for its official rules on recombinant DNA research, shaping biosafety regulation for decades after.

The point is not that AI mathematics is recombinant DNA. The point is narrower: sometimes a field begins to govern itself before formal institutions know what to do with the risk.

Asilomar did not begin as regulation. It began as scientists deciding that some kinds of power should not be allowed to outrun the practices that make them inspectable.

Small ponds, one current

This doesn't make the pond important on its own.

It changes something smaller, but more useful: it changes what the pond can now be compared against.

A year ago, a verification harness around toy quantum models could look like private overbuilding — too much claim_boundary, too many execution artifacts, too much ledger discipline for work almost nobody had asked to inspect.

After the Leiden Declaration, the same habit sits inside a larger problem statement. The question is no longer only whether this particular pond matters. It is whether research claims, once AI makes them cheap to produce, can remain tied to artifacts sturdy enough to inspect.

The Declaration is a mathematics-community document, not a software-verification framework. That boundary matters. Still, its core concern — automated output outrunning disclosure, review, and human responsibility — is the same pressure Flamehaven has been trying to make operational at the artifact level.

Asilomar named a related pattern fifty years earlier, in a different field, with a different danger at stake: a technical capability began moving faster than the practices built to govern it, and the field responded before formal institutions had settled the rules.

That is the only comparison I want to make.

A declaration names the pressure from above. A ledger answers from below by keeping each claim tied to the code, result, paper, and timestamped record that supported it. Neither changes the whole field alone. But a watershed was never one current to begin with. It is what becomes visible after enough separate sources of clean water keep draining toward the same low ground.

The trajectory still splits two ways. The trust gap around AI-generated research provenance could close on its own, market-driven and indifferent to anything built here. Or this kind of self-imposed, bottom-up correction — scientists and builders setting their own terms before regulation arrives — could become one of the ways it closes.

Which branch is correct can't be known from here. The second branch is no longer just a hope, though. It now has a name, an institutional endorsement, a publication date, and a fifty-year precedent showing that field-led restraint can shape formal governance.

That still does not make the work valuable in the market yet. The code still runs. The ledger still holds. The result still reproduces.

We are not the ocean. We are not even the current. But a pond does not need to know it is part of a watershed to matter. It only has to stay clear, drain in the same direction as other clear water, and let the geography do the rest.

References

[1] Nature, "arXiv to ban researchers for a year if they don't disclose AI use," May 2026

[2] Ginsparg et al., "Hallucinated References in Preprint Servers," arXiv, 2026

[3] OpenAI, "PaperBench: Evaluating AI's Ability to Replicate AI Research"

[4] "Provenance Infrastructure for AI-Era Scholarship," arXiv, 2026

[5] Elsevier, "Shaping the Researcher of the Future: Confidence, Collaboration and AI," 2025

[6] Elsevier, "Researcher of the Future — Confidence in Research," 2025

[7] Leiden Declaration on Artificial Intelligence and Mathematics, June 2026

[7a] Leiden University, "Leiden Declaration: AI is challenging the core values of mathematics," June 2026

[8] Flamehaven Verification Ledger, "Leiden Alignment Note"

[9] Embryo Project Encyclopedia, "Asilomar Conference (1975)"

Distributed Systems: Implementing the Raft Consensus Protocol from Scratch

Tue, 09 Jun 2026 07:14:44 +0000

title: "Distributed Systems: Implementing the Raft Consensus Protocol from Scratch"
published: true
description: "Deconstructing distributed consensus, state machine replication, leader election algorithms, and split-brain mitigation in distributed clusters."
tags: computerscience, javascript, typescript, distributedsystems
canonical_url: https://akinseinde.netlify.app/articles/raft-consensus

series: "Systems Engineering Series"

>This is an excerpt. The full article includes a live interactive Raft consensus cluster simulator — control a 5-node distributed cluster, trigger leader elections, partition nodes to simulate network splits, commit client state updates, and watch the term-clock and replication logs resolve conflicts in real time. Read the full interactive version →

The Distributed State Problem

How do you get multiple independent computer nodes to agree on a single sequence of events, especially when individual nodes can crash, experience network delays, or drop packets?

This is the core challenge of Distributed Consensus. In a distributed database, all replicas must execute incoming commands in identical order to maintain a consistent state.

For years, the industry standard was Paxos — an algorithm famously powerful but incredibly complex to understand and implement without error.

Raft was designed as an alternative. It breaks down the consensus problem into three modular sub-problems: Leader Election, Log Replication, and Safety Invariants.

The Three Raft Node States

At any given moment, every node in a Raft cluster operates in one of three distinct roles:

        ┌───────────────────────────────────────┐
        │                FOLLOWER               │
        └───────────────────────────────────────┘
          │ (Times out, starts election)   ▲
          ▼                                │ (Discovers current leader)
        ┌───────────────────────────────────────┐
        │               CANDIDATE               │
        └───────────────────────────────────────┘
          │ (Receives majority votes)      
          ▼                                
        ┌───────────────────────────────────────┐
        │                 LEADER                │
        └───────────────────────────────────────┘

Follower: Completely passive. Responds to incoming RPC calls from Candidates and Leaders. If a follower receives no communication for a randomized timeout period, it assumes the leader has crashed and transitions to a Candidate.
Candidate: Increments the cluster "term", votes for itself, and broadcasts requests for votes to all other nodes.
Leader: Manages all client writes. Coordinates log replication and broadcasts periodic "heartbeat" RPCs to assert authority and reset follower timeout clocks.

Sub-Problem 1: Leader Election

To prevent split votes, followers wait for a randomized election timeout (typically between 150ms and 300ms) before initiating an election.

Once a node's timeout expires, it:

Increments its local currentTerm counter.
Transitions to the Candidate state.
Votes for itself.
Sends a RequestVote RPC to all other nodes.

If a candidate receives votes from a majority of nodes in the cluster (e.g., 3 out of 5), it immediately transitions to Leader and starts broadcasting heartbeats.

Sub-Problem 2: Log Replication

Once a Leader is elected, it acts as the single gateway for all client write requests.

Client ─── Write "X = 5" ───> Leader
                                │
          ┌─────────────────────┴─────────────────────┐
          │ (Append entry, broadcast AppendEntries)   │
          ▼                                           ▼
      Follower A                                  Follower B

The Replication Steps:

The client sends a command (e.g., set x=5) to the Leader.
The Leader appends the command to its local log.
The Leader broadcasts an AppendEntries RPC containing the new log entry to all followers.
Followers verify the entry and append it to their logs, sending a success confirmation back.
Once a majority of followers acknowledge the write, the Leader commits the entry to its state machine and returns a success response to the client.
In subsequent heartbeats, the Leader notifies followers of the newly committed entry, prompting them to commit it to their local state machines.

TypeScript Raft Node Implementation

Here is the baseline state container and interface schema for a Raft consensus node in TypeScript:

type NodeRole = "Follower" | "Candidate" | "Leader";

interface LogEntry {
  term: number;
  command: string;
}

interface RequestVoteArgs {
  term: number;
  candidateId: string;
  lastLogIndex: number;
  lastLogTerm: number;
}

interface RequestVoteReply {
  term: number;
  voteGranted: boolean;
}

class RaftNode {
  public id: string;
  public currentTerm = 0;
  public role: NodeRole = "Follower";
  public votedFor: string | null = null;
  public log: LogEntry[] = [];
  
  private commitIndex = 0;
  private electionTimeout: NodeJS.Timeout | null = null;
  private peers: string[] = [];

  constructor(id: string, peers: string[]) {
    this.id = id;
    this.peers = peers;
    this.resetElectionTimeout();
  }

  private resetElectionTimeout() {
    if (this.electionTimeout) clearTimeout(this.electionTimeout);
    
    // Randomized timeout between 150ms and 300ms prevents split votes
    const timeout = 150 + Math.floor(Math.random() * 150);
    this.electionTimeout = setTimeout(() => this.startElection(), timeout);
  }

  // Handle incoming vote request from Candidate node
  public handleRequestVote(args: RequestVoteArgs): RequestVoteReply {
    this.resetElectionTimeout();

    // 1. Term check: reject candidates with stale terms
    if (args.term < this.currentTerm) {
      return { term: this.currentTerm, voteGranted: false };
    }

    if (args.term > this.currentTerm) {
      this.currentTerm = args.term;
      this.role = "Follower";
      this.votedFor = null;
    }

    // 2. Log completeness check: candidate log must be at least as up-to-date as ours
    const lastIndex = this.log.length - 1;
    const lastTerm = lastIndex >= 0 ? this.log[lastIndex].term : 0;
    const logIsUpToDate =
      args.lastLogTerm > lastTerm ||
      (args.lastLogTerm === lastTerm && args.lastLogIndex >= lastIndex);

    // 3. Vote check
    const canVote = this.votedFor === null || this.votedFor === args.candidateId;

    if (canVote && logIsUpToDate) {
      this.votedFor = args.candidateId;
      return { term: this.currentTerm, voteGranted: true };
    }

    return { term: this.currentTerm, voteGranted: false };
  }

  private startElection() {
    this.role = "Candidate";
    this.currentTerm++;
    this.votedFor = this.id;
    this.resetElectionTimeout();

    console.log(`Node ${this.id} starting election for Term ${this.currentTerm}`);
    
    let votesReceived = 1; // Vote for self
    const lastLogIndex = this.log.length - 1;
    const lastLogTerm = lastLogIndex >= 0 ? this.log[lastLogIndex].term : 0;

    for (const peerId of this.peers) {
      // Simulate dispatching network RPC calls to peer cluster
      this.sendRequestVoteRPC(peerId, {
        term: this.currentTerm,
        candidateId: this.id,
        lastLogIndex,
        lastLogTerm
      }).then((reply) => {
        if (this.role !== "Candidate") return;

        if (reply.voteGranted) {
          votesReceived++;
          if (votesReceived > (this.peers.length + 1) / 2) {
            this.becomeLeader();
          }
        }
      });
    }
  }

  private becomeLeader() {
    this.role = "Leader";
    if (this.electionTimeout) clearTimeout(this.electionTimeout);
    console.log(`Node ${this.id} elected Leader for Term ${this.currentTerm}!`);
    this.startHeartbeats();
  }

  private startHeartbeats() {
    // Send AppendEntries heartbeats at 50ms intervals to maintain authority
    setInterval(() => {
      if (this.role !== "Leader") return;
      for (const peerId of this.peers) {
        this.sendAppendEntriesRPC(peerId);
      }
    }, 50);
  }

  // Mock network transporters for simulation environment
  private async sendRequestVoteRPC(peerId: string, args: RequestVoteArgs): Promise<RequestVoteReply> {
    return { term: this.currentTerm, voteGranted: Math.random() > 0.3 };
  }

  private async sendAppendEntriesRPC(peerId: string) {
    // Heartbeat logic
  }
}

Split-Brain and Minority Partitions

What happens when a network partition cuts a 5-node cluster into two segments: a majority partition (3 nodes) and a minority partition (2 nodes)?

  MAJORITY PARTITION (Can commit)         MINORITY PARTITION (Cannot commit)
   [Node A] ─── [Node B (Leader 1)]         [Node D] ─── [Node E (Leader 2)]
      │                                        │
   [Node C]                                    X (Network Partition cut)

The minority partition might elect a new leader because they can no longer hear from the original leader. However, this minority leader cannot commit any new client writes because they can never achieve the required cluster majority (3 nodes).

Once the partition heals:

The minority leader receives a heartbeat containing a higher term clock from the majority leader.
The minority leader immediately steps down back to a Follower.
The minority nodes discard their uncommitted local log differences and synchronize their states with the majority leader's canonical log.

Raft guarantees that the cluster always converges safely back to a single source of truth.

Engineering Takeaways

Raft guarantees Safety and Liveness in distributed environments with randomized timeouts.
Commitment requires absolute majority consensus — protecting clusters from split-brain state divergence.
Term clocks act as global logical time — higher term numbers override all stale cluster leaders.

>The full article features a live 5-node Raft consensus cluster simulator — trigger network cuts to form minority and majority partitions, watch node roles transition, commit client writes, and view live log conflict resolution directly in your browser.

Read the full interactive article →

Written by Ebenezer Akinseinde — Software Developer & AI Automations Engineer.

Portfolio · GitHub

The Compiler Maze

Sat, 23 May 2026 21:22:29 +0000

Why Compiler is a very breathtaking project for devs and single dev

I just got into the parser stage 2 days ago and the design was flowing like a breeze. Since my compiler is focused as a system programming compiler for my custom language, I was at the type checking (local type checking) phase.

This is where I created a util.hpp file in which I wrote a namespace containing polymorphic code as it is a global type system my compiler will use to verify type at compile time.

My compiler makes sure it does everything at compile time as it really benefits — creating a custom language means you're definitely tired of the scope of the current language compiler, so that's why we're here!

Type System

The compiler tries to be ambitious like Zig and more than it, as it supports variable width types from 1 to 65535 for both unsigned and signed. I won't lie, I learned the formula for signed and unsigned, but like I said, the compiler scope got in my way: how do I store 2^65535 - 1 for unsigned value range? As we famous graphics devs and codecs know, u8 is from 0 to 255. Wait, it's unrelated.

My Ambitions

I'm a rising video codec engineer but no traditional DCT, motion vector in my vision. I did try to invent a proprietary upscaler called GVEST (Geometry Vector Expansion Spatial Transform). It's better than bilinear by a few tens of dB in edge construction without blurring, and same dB on a noisy image. If you want to see the images, I will try to upload the graph and simulation results which AI did run Python code to generate, in another Non-Compiler Series of ours. So to cut the story short, I knew entropy coding and video codecs need not just runtime precision but memory precision. And don't get me wrong — Gemini AI helped me fix the formula, as fitting the above range results from the above formula is not my path and I didn't see it coming, and I don't want another hour of burnout. I want to add theoretical bit-size memory allocation to the value of that variable bits to memory, meaning if a u8 (which is 1 byte) and the value was 5 which doesn't take the whole 8 bits or byte, why waste memory? But it's non-trivial as unpacking them will be a big fight, but I'm still going that route.

What's still breathtaking

Won't lie — I'm very ambitious. I've got so much type system, DSA to optimize at compile time. I asked AI why no language optimizes tree-based DSA as I knew little about them. All my life from JS to C++ wasn't more than structs and arrays (with vector in C++'s case). I did learn DSA in my days as a JS dev, but C++ is different in everything: containers abstraction, STL, iterators, the .data() + index, end or the .begin(), .end() — it's everywhere in C++, and beginners and experienced devs definitely still go to the docs once in a while. And honestly, the docs aren't great too.

I went through serious burnout today as I want my language, even if C++-like, to have ownership and lifetime and memory validation, if you've seen my ambition above. It will also be friendly and clear with error messages, and I'm already proud of my lexer stage error messages on my string and char warnings and recovery on unterminated literals. It's really a breathtaking journey.

Closing it all up

If you liked the architecture and insights you've seen or haven't, I welcome you in the comments section, and if you want to subscribe to my Newsletter — though it's in early stage — become my subscriber on Substack: Substack

I'm happy building the project as I'm not looking at where I am but where it's going to be. I'm breaking the LLVM oath solo, and you can too. If you follow up, everything counts for me.

Sorting Wars: Benchmarking Selection, Insertion, Gnome e Bubble Sort em 5 Linguagens

Fri, 22 May 2026 14:58:16 +0000

Algoritmos quadráticos são lentos — isso todo mundo sabe. Mas o quão lentos? E a linguagem escolhida importa mais do que o algoritmo em si? Foi exatamente isso que nossa turma de Algoritmos e Estruturas de Dados I do CEFET-MG decidiu testar empiricamente.

Implementamos Selection Sort, Insertion Sort, Gnome Sort e Bubble Sort em C, C++, Rust, JavaScript e Python, rodamos benchmarks com até 1 milhão de elementos e coletamos os dados. Esse post resume o que encontramos — incluindo alguns resultados que nos surpreenderam bastante.

Por que estudar algoritmos O(n²) em 2025?

Antes de mergulhar nos números, vale responder a pergunta óbvia. Três razões principais:

Didática — a lógica é direta, ideal para aprender análise de complexidade e invariantes de laço.
Entradas pequenas — para N ≤ ~50, o overhead reduzido pode torná-los mais rápidos que algoritmos sofisticados.
Adaptatividade — Insertion Sort e Bubble Sort com parada antecipada chegam a O(n) em entradas quase ordenadas. É por isso que o TimSort (usado em Python e Java) usa Insertion Sort internamente para subconjuntos pequenos.

Os Algoritmos

Selection Sort — O inflexível

Seleciona o mínimo do subarray não ordenado e o move para a posição correta com uma única troca.

PARA i DE 0 ATE N - 2 FACA
  MIN_IDX <- i
  PARA j DE i + 1 ATE N - 1 FACA
    SE VETOR[j] < VETOR[MIN_IDX] ENTAO
      MIN_IDX <- j
  SE MIN_IDX != i ENTAO
    TROCA VETOR[i] COM VETOR[MIN_IDX]

Característica marcante: sempre realiza exatamente n(n-1)/2 comparações, independente da entrada. Não existe melhor caso em comparações — é Θ(n²) em todos os cenários.

Caso	Comparações	Complexidade
Melhor (ordenado)	n(n−1)/2	O(n²)
Médio (aleatório)	n(n−1)/2	O(n²)
Pior (invertido)	n(n−1)/2	O(n²)

✅ In-place · ❌ Não estável · ❌ Não adaptativo

Insertion Sort — O adaptativo

Mantém um subarray ordenado à esquerda e insere cada novo elemento na posição correta via shifting.

PARA i DE 1 ATE N - 1 FACA
  CHAVE <- VETOR[i]
  j <- i - 1
  ENQUANTO j >= 0 E VETOR[j] > CHAVE FACA
    VETOR[j + 1] <- VETOR[j]
    j <- j - 1
  VETOR[j + 1] <- CHAVE

Em entradas já ordenadas, o laço interno nunca executa: complexidade O(n) no melhor caso. Isso ficou claro nos nossos dados — até 10⁶ elementos, o cenário crescente terminou em microssegundos.

Caso	Comparações	Complexidade
Melhor (ordenado)	n − 1	O(n)
Médio (aleatório)	n(n−1)/4	O(n²)
Pior (invertido)	n(n−1)/2	O(n²)

✅ In-place · ✅ Estável · ✅ Adaptativo

Gnome Sort — O excêntrico

Opera como um "gnomo organizando vasos": avança comparando adjacentes, e ao encontrar desordem, troca e recua uma posição.

INDICE <- 0
ENQUANTO INDICE < N FACA
  SE INDICE = 0 OU VETOR[INDICE] >= VETOR[INDICE - 1] ENTAO
    INDICE <- INDICE + 1
  SENAO
    TROCA VETOR[INDICE] COM VETOR[INDICE - 1]
    INDICE <- INDICE - 1

Funcionalmente equivalente a um Insertion Sort por trocas — mas com movimento local em vez de shifting. Também adaptativo: O(n) no melhor caso.

Caso	Comparações	Complexidade
Melhor (ordenado)	n − 1	O(n)
Médio (aleatório)	(A DEPENDER)	O(n²)
Pior (invertido)	n(n−1)/2	O(n²)

✅ In-place · ✅ Estável · ✅ Adaptativo

Bubble Sort — O clássico (com parada antecipada)

Realiza passagens comparando pares adjacentes. A variável swapped permite encerramento antecipado quando o vetor já está ordenado.

PARA i DE 0 ATE N - 1 FACA
  SWAPPED <- FALSO
  PARA j DE 0 ATE N - i - 2 FACA
    SE VETOR[j] > VETOR[j + 1] ENTAO
      TROCA VETOR[j] COM VETOR[j+1]
      SWAPPED <- VERDADEIRO
  SE SWAPPED = FALSO ENTAO
    RETORNE  // Encerramento antecipado

Caso	Comparações	Complexidade
Melhor (ordenado)	n − 1	O(n)
Médio (aleatório)	n(n−1)/4	O(n²)
Pior (invertido)	n(n−1)/2	O(n²)

✅ In-place · ✅ Estável · ✅ Adaptativo (com parada antecipada)

Metodologia

Tamanhos de entrada: N ∈ { 10², 10³, 10⁴, 10⁵, 10⁶ }
Cenários: crescente (melhor caso), aleatório (caso médio), decrescente (pior caso)
Repetições: 5 execuções; média das 3 centrais (descartando menor e maior)
Otimizações testadas: -O0 e -O3 para C/C++/Rust
Medição: apenas tempo de ordenação (I/O descartado)

Cada linguagem usou sua estrutura de dados nativa:

Linguagem	Estrutura	Tipo
C	`double[]` com `malloc`	`double` 64-bit
C++	`std::vector<double>`	`double` 64-bit
Rust	`Vec<f64>`	`f64` 64-bit
JavaScript	`Array` (V8 float64)	`Number`
Python	`list` (refs a PyObject)	`float`

Resultados — Selection Sort

O Selection Sort foi o mais previsível: tempos quase idênticos nos três cenários, confirmando a não-adaptatividade.

N = 10⁵ — tempo em segundos (-O3 / otimização máxima)

Linguagem	Crescente (s)	Aleatório (s)	Decrescente (s)
C (-O3)	2.0500	3.5188	1.9618
C++ (-O3)	2.1247	3.5188	1.9089
Rust (-O3)	2.3265	4.2560	2.1320
JavaScript (V8)	3.5835	6.6564	3.5851
Python	93.164	164.890	98.378

Python para N = 10⁶ foi descartado — tempo estimado superior a 10 horas.

Hierarquia: C -O3 ≈ C++ -O3 < Rust < JavaScript ≪ Python

Resultados — Insertion Sort

Aqui a adaptatividade brilhou. No cenário crescente com N = 10⁶, todas as linguagens terminaram em menos de 12 ms. Já no cenário decrescente, o pior caso quadrático foi brutal:

N = 10⁵ — tempo em segundos (-O3 / otimização máxima)

Linguagem	Crescente (s)	Aleatório (s)	Decrescente (s)
C (-O3)	0.000055	0.615683	1.188966
C++ (-O3)	0.0000634	0.587483	1.183000
Rust (-O3)	0.000079	0.897895	1.774292
JavaScript (V8)	0.000809	1.525250	3.033301
Python	0.005321	136.295	226.560

Para N = 10⁶ no pior caso sem otimização, C++ chegou a 3670 s (~1 hora). Com -O3, caiu para 119 s — speedup de ~30×.

Resultados — Gnome Sort

O Gnome Sort trouxe a maior surpresa da série: Rust superou C e C++ no caso médio.

N = 10⁵ — tempo em segundos (-O3 / otimização máxima)

Linguagem	Crescente (s)	Aleatório (s)	Decrescente (s)
C (-O3)	0.000179	15.19068	28.90668
C++ (-O3)	0.000159	13.96807	28.25787
Rust (-O3)	0.000049	3.94810	8.27646
JavaScript (V8)	0.001584	13.90908	27.45163
Python	0.019030	21.28324	257.00624

Por quê? O padrão de acesso do Gnome Sort — muitos acessos locais e trocas adjacentes — se beneficia especialmente das otimizações do compilador LLVM (backend do Rust), que gera código de swap em registrador sem acesso intermediário à memória.

Resultados — Bubble Sort

O Bubble Sort entregou o resultado mais inesperado de todo o projeto:

N = 10⁵ — tempo em segundos (-O3 / otimização máxima)

Linguagem	Crescente (s)	Aleatório (s)	Decrescente (s)
C (-O3)	0.000042	20.489569	23.568626
C++ (-O3)	0.000045	21.165759	23.919268
Rust (-O3)	0.000051	13.513529	9.231813
JavaScript (V8)	0.001753	15.012168	6.905683
Python	0.003504	312.509064	403.412438

JavaScript bateu C e C++ no pior caso. O motor V8 identificou o padrão repetitivo de trocas adjacentes e gerou código de máquina altamente especializado via JIT. É um caso raro onde a compilação dinâmica supera a compilação estática.

Principais Aprendizados

1. Otimização de compilador importa muito mais do que parece

O impacto de -O3 vs -O0 para Rust no Bubble Sort chegou a 23× para N = 10⁴. Em modo debug, o Rust mantém verificações de bounds checking em todo acesso ao array — correto para desenvolvimento, devastador para performance.

2. Adaptatividade é real e mensurável

Insertion Sort com N = 10⁶ no cenário crescente: < 1 ms. No cenário decrescente: até 3670 s (sem otimização). Isso é uma diferença de mais de 10 ordens de magnitude no número de operações.

3. Python tem overhead estrutural, não só de interpretador

A list do Python armazena referências a objetos PyObject — cada acesso e comparação envolve uma indireção de ponteiro. Isso multiplica o custo por operação mesmo para tipos simples como int e float.

4. JIT pode superar código estático em padrões repetitivos

O V8 observa o comportamento em runtime e especializa o código gerado. Para algoritmos com padrões de acesso altamente previsíveis (como Bubble Sort), isso pode ser mais eficiente que otimizações estáticas conservadoras de um compilador AOT.

5. A hierarquia não é fixa

A ordem geral foi C ≈ C++ < Rust < JS < Python, mas exceções importantes existem — Rust venceu todos no Gnome Sort, JS venceu todos no Bubble Sort em pior caso. O melhor resultado depende do algoritmo, tamanho de entrada e padrão de acesso.

Conclusão

Algoritmos simples ensinam mais do que complexidade assintótica. Ensinam sobre a relação entre padrões de acesso à memória e otimizações de compilador, sobre como compilação JIT funciona na prática, e sobre por que constantes importam tanto quanto expoentes para tamanhos reais de entrada.

Se você quiser explorar o código completo, estrutura de Makefiles, geradores de dataset e scripts de benchmark, o repositório está público no GitHub.

{% embed https://github.com/Bernardo-Lebron/simple_sort_algorithms %}

Trabalho prático da disciplina de Algoritmos e Estruturas de Dados I — CEFET-MG Campus V, Divinópolis. Orientação: Prof. Michel Pires.

The Making of a 10x Engineer in AI Era: Why Big-O Thinking Changes Everything

Mon, 11 May 2026 17:39:53 +0000

Introduction

Some code works. Some code lasts.

The difference rarely comes down to typing speed, syntax mastery, or how many nights you're willing to push through. It comes down to how you think about a problem before you write a single line.
Exceptional engineers don't start with code. They start with understanding: visualizing the shape of the problem, weighing trade-offs, and asking how a solution will hold up when the data grows, the users multiply, or the pressure mounts.
At the center of that mindset is a tool every serious engineer learns to trust: Big-O notation.

What Big-O Actually Does ?

Big-O notation is a mathematical framework that describes how an algorithm performs as its input grows. In plain terms, it answers one question:

"How well will this solution scale?"

It strips away the noise machine specifications,compiler differences,network latency and gives you a high-level measure of efficiency. Specifically, it describes the worst-case growth rate of an operation relative to input size n.

This is what lets you compare approaches and choose the one that stays reliable as your data grows from hundreds to millions.

The Big-O Hierarchy: From Best to Worst

Below is the spectrum of common complexity classes, ordered from most to least efficient with examples.

1. O(1) — Constant Time

The gold standard. Input size is irrelevant.
Whether your dataset has 10 items or 10 million, the operation takes the same time. Build for O(1) wherever you can.

a. Accessing an Array Element by Index

arr = [10, 20, 30, 40]
value = arr[2]
print(value)

b. Inserting and Accessing a Value into a Hash Map (Dictionary)

my_dict = {"firstName":"William","age":54}
my_dict["country"]="Kenya"
#accessing
value = my_dict["firstName"]

c. Stack Operations (Push / Pop)

stack.append(10)   
stack.pop()

d. Queue Operations (Enqueue / Dequeue)

from collections import deque
q = deque()
q.append(1)     
q.popleft()

e. Checking the Length of a List

print(len(arr))

Judgement: O(1) is acceptable

2. O(log n) — Logarithmic Time

Each step dramatically shrinks the remaining problem.

Searching 1,000,000 items takes roughly 20 comparisons. That's not a typo. Logarithmic algorithms are extraordinarily efficient at scale.

Binary Search

def binary_search(arr, target):
    left, right = 0, len(arr) - 1
    while left <= right:
        mid = (left + right) // 2
        if arr[mid] == target:
            return mid
        elif arr[mid] < target:
            left = mid + 1
        else:
            right = mid - 1

Judgement: O(log n) is acceptable

3. O(n) — Linear Time

Proportional growth. Double the data, double the work.

# Scanning every item once to find the maximum
def find_max(numbers):
    maximum = numbers[0]
    for num in numbers:       # visits every element exactly once
        if num > maximum:
            maximum = num
    return maximum

Judgement: O(n) is acceptable

4. O(n log n) — Linearithmic Time

The sweet spot for sorting. Far better than quadratic.
a. Merge Sort

def merge_sort(arr):
    if len(arr) <= 1:
        return arr
    mid = len(arr) // 2
    left = merge_sort(arr[:mid])  
    right = merge_sort(arr[mid:])
    return merge(left, right)

def merge(left, right):

result = []
i = j = 0
while i < len(left) and j < len(right):   
    if left[i] <= right[j]:
        result.append(left[i]); i += 1
    else:
        result.append(right[j]); j += 1
return result + left[i:] + right[j:]

print(merge_sort([38, 27, 43, 3, 9, 82, 10]))

Result : [3, 9, 10, 27, 38, 43, 82]

Python's native `sort()` runs at O(n log n). When you see a well-built sorting algorithm, you're almost certainly looking at this class.

####Judgement: O(n log n) not Badly off. 

---

### 5. O(n²) — Quadratic Time 

> *Nested loops are a red flag. Performance falls off a cliff.*

```python
def find_duplicates(arr):
    duplicates = []
    for i in range(len(arr)):              # O(n)
        for j in range(i + 1, len(arr)):   # O(n) again
            if arr[i] == arr[j]:
                duplicates.append((arr[i], arr[j]))
    return duplicates
print(find_duplicates([1, 3, 4, 2, 3, 1, 5]))
# [(1, 1), (3, 3)]

Judgement: O(n²) if you can avoid it the better.

6. O(n³) — Cubic Time

Rarely acceptable outside academic settings.

def three_sum_brute(arr):
    n = len(arr)
    triplets = []

    for i in range(n):                  
        for j in range(i + 1, n):     
            for k in range(j + 1, n):  
                if arr[i] + arr[j] + arr[k] == 0:
                    triplets.append((arr[i], arr[j], arr[k]))
    return triplets
print(three_sum_brute([-3, -1, 0, 1, 2, 3, -2]))
# [(-3, 1, 2), (-3, 0, 3), (-1, 0, 1), (-2, 0, 2), (-2, -1, 3)]
}

Judgement: O(n³) if you can avoid it the better.

7. O(2ⁿ) — Exponential Time

Each added input doubles the workload. A design smell.

# Naive recursive Fibonacci — the most famous exponential trap
def fibonacci(n):
    if n <= 1:
        return n
    return fibonacci(n - 1) + fibonacci(n - 2)  # Recalculates the same values endlessly

# The fix: memoisation collapses this to O(n)
from functools import lru_cache

@lru_cache(maxsize=None)
def fibonacci_fast(n):
    if n <= 1:
        return n
    return fibonacci_fast(n - 1) + fibonacci_fast(n - 2)

fibonacci(50) without memoisation makes over 2 trillion calls. The memoised version makes exactly 50. This is the power of understanding why complexity matters, not just what it is.

Judgement: O(2ⁿ) if you can avoid it the better.

8. O(n!) — Factorial Time

Computationally prohibited for almost everything.

# Brute-force Traveling Salesman Problem
from itertools import permutations

def traveling_salesman_brute(graph, start):
    cities = list(graph.keys())
    cities.remove(start)
    best = float('inf')

    for perm in permutations(cities):   # n! permutations
        route = [start] + list(perm) + [start]
        cost = sum(graph[route[i]][route[i+1]] for i in range(len(route)-1))
        best = min(best, cost)

    return best

Judgement: O(n!) avoid it.

Why This Changes How You Think

Big-O is not an academic exercise. It's a mode of thinking.

Once it becomes second nature, something shifts in how you approach problems:

You anticipate bottlenecks before they reach production
You design systems that scale rather than systems that survive
You make deliberate trade-offs between time complexity and space complexity
You read code differently — a nested loop is no longer "just syntax", it's a question mark

Most importantly, you stop asking "does this work?" and start asking "how does this behave at scale?"

Found this useful? Drop a ❤️ and follow for more pieces on engineering thinking, systems design, and the habits that separate good engineers from great ones.

Embedded Linux Development - Part 6

Tue, 21 Apr 2026 09:08:36 +0000

In this tutorial, I will continue to discuss embedded Linux development with ssh server activation. Previously, I've entered into BeagleBone Black over J1 serial header with a USB-UART converter. In here, I will show that how to enter into it with ssh command.

Firstly, there are two important points that you have to do. I've already did these in previous tutorials. Firstly, I compiled the kernel with USB Gadget module and secondly, I installed openssh-server package into the rootfs. USB gadget module enables the USB connection as the virtual ethernet adapter.

Let's do required settings for both side. Use the J1 serial header again to enter into the BeagleBone Black.

Type the "root" and the your password (set in previous tutorial). Also creating a normal user is good practice.

root@can:/# useradd -m -s /bin/bash can
root@can:/# passwd can
root@can:/# usermod -aG sudo can

I've created a user named "can" and set the its password. After that go to the your home directory and create a bash script. I named it as setup-usb-gadget.sh.

root@can:/home/can# ls
setup-usb-gadget.sh

Open and copy this into that:

 #!/bin/bash

INTERFACE="usb0"
IP_ADDR="198.168.7.2/24"

 # Load the g_ether kernel module that creates the ethernet virtual link.
modprobe g_ether

 # Configure the link interface.
ip addr flush dev "$INTERFACE"
ip link set "$INTERFACE" up
ip addr add "$IP_ADDR" dev "$INTERFACE"

 # Ensure that SSH is running.
systemctl start ssh

In here, I loaded the g_ether module into the kernel. It's the name of USB gadget module. It will create usb0 interface. After that I set it as "up" and its IP address as "198.168.7.2". You can give any IP address, doesn't matter. Lastly, make sure that ssh server is enabled.

Set the executable permission:

root@can:/home/can# chmod +x ./setup-usb-gadget.sh

And then run it.

root@can:/home/can# ./setup-usb-gadget.sh 
[  644.487501] g_ether gadget.0: HOST MAC f6:b0:84:e3:dc:c2
[  644.493125] g_ether gadget.0: MAC e2:87:7a:43:97:1d
[  644.498588] g_ether gadget.0: Ethernet Gadget, version: Memorial Day 2008
[  644.505565] g_ether gadget.0: g_ether ready
[  644.522283] PM: Cannot get wkup_m3_ipc handle

Lastly, list the available interface on BeagleBone Black:

root@can:/home/can# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
3: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 64:8c:bb:f2:25:78 brd ff:ff:ff:ff:ff:ff
4: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether e2:87:7a:43:97:1d brd ff:ff:ff:ff:ff:ff
    inet 198.168.7.2/24 brd 198.168.7.255 scope global usb0
       valid_lft forever preferred_lft forever
    inet6 fe80::e087:7aff:fe43:971d/64 scope link 
       valid_lft forever preferred_lft forever

You see the "usb0" interface. That's enough for BeagleBone Black. Let's continue with host side. Open a new terminal and list the available interfaces on host:

can@can:~$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether e8:6a:64:19:45:15 brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether b0:fc:36:c1:cf:eb brd ff:ff:ff:ff:ff:ff
    inet 10.152.197.93/24 brd 10.152.197.255 scope global dynamic noprefixroute wlp2s0
       valid_lft 3521sec preferred_lft 3521sec
    inet6 fe80::18fc:91fe:ea80:8fad/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether fa:47:d4:7a:67:3e brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
13: enxf6b084e3dcc2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether f6:b0:84:e3:dc:c2 brd ff:ff:ff:ff:ff:ff

BeagleBone Black seems as "enxf6b084e3dcc2" for now. You probably see the different name. It doesn't matter. As wee did in BeagleBone Black, let's do the same things at host side:

can@can:~$ ip addr flush dev enxf6b084e3dcc2
can@can:~$ sudo ip link set enxf6b084e3dcc2 up
can@can:~$ sudo ip addr add 198.168.7.1/24 dev enxf6b084e3dcc2

I assigned the IP address "198.168.7.1" to host (I did "198.168.7.2" for BeagleBone Black).

Lastly, ping BeagleBone Black interface:

can@can:~$ ping 198.168.7.2
PING 198.168.7.2 (198.168.7.2) 56(84) bytes of data.
64 bytes from 198.168.7.2: icmp_seq=1 ttl=64 time=0.904 ms
64 bytes from 198.168.7.2: icmp_seq=2 ttl=64 time=0.351 ms
64 bytes from 198.168.7.2: icmp_seq=3 ttl=64 time=0.449 ms
64 bytes from 198.168.7.2: icmp_seq=4 ttl=64 time=0.478 ms
64 bytes from 198.168.7.2: icmp_seq=5 ttl=64 time=0.585 ms
64 bytes from 198.168.7.2: icmp_seq=6 ttl=64 time=0.477 ms
^C
--- 198.168.7.2 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5114ms
rtt min/avg/max/mdev = 0.351/0.540/0.904/0.176 ms

That's okey. You can connect to BeagleBone Black with ssh command for now:

can@can:~$ ssh can@198.168.7.2
can@198.168.7.2's password: 
Linux can 6.14.0-ge8b471285262 #1 SMP Mon Apr 13 12:31:38 +03 2026 armv7l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Jan  1 00:43:51 2000 from 198.168.7.1
can@can:~$ 
can@can:~$ ls
setup-usb-gadget.sh
can@can:~$ cd ..
can@can:/home$ cd ..
can@can:/$ ls
bin  boot  dev  etc  home  lib  lost+found  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

You don't need anymore J1 serial header. You can use it within the ssh terminal for now. Also you can set the setup-usb-gadget.sh as startup script so that it runs automatically after the boot.

In next tutorial, I will inspect the uEnv.txt file and u-boot console. You can make many interesting tricks in there.

Resources:

Simmonds C., Mastering Embedded Linux Programming, Packt Publishing, 2015
Embedded Linux system development training, Bootlin, 2024

What You're Really Doing When You Write Code

Mon, 20 Apr 2026 18:50:51 +0000

Most developers spend years writing code...
without ever understanding what computing actually is.

That's a problem.

Because until you understand how a machine processes information, you're not really designing systems—you're just arranging syntax.

Computing, Stripped to Its Core

At its lowest level, computing is simple:

Input → Transformation → Output

That's it.

Every system you've ever used—whether it's a calculator, a backend API, or a distributed system—follows this pattern.

But the real question is:

How does the machine actually perform that transformation?

Everything Is Data (Even Your Code)

Inside a computer, there are no "variables", no "functions", no "objects".

There is only:

binary data (0s and 1s)

Your code:

if statements
loops
API calls

All get compiled or interpreted into machine instructions.

Those instructions are just numbers.

The CPU: The Real Executor

The CPU is the component that actually does the work.

It follows a simple loop:

Fetch → Decode → Execute

1. Fetch

Get the next instruction from memory

2. Decode

Understand what that instruction means

3. Execute

Perform the operation (math, logic, memory access)

Example

When you write:

const sum = a + b;

The CPU doesn't see JavaScript.

It sees something closer to:

Load a into a register
Load b into a register
Add them together
Store the result

That's computing.

The GPU: Specialized Parallelism

While the CPU is general-purpose, the GPU is built for:

running thousands of smaller cores that execute the same instruction across different data points simultaneously

That's why GPUs dominate:

Graphics rendering
Machine learning
Simulations

Where a CPU has a few powerful cores optimized for:
sequential tasks with complex logic and branching

A GPU has thousands of simpler cores optimized for:
massive parallelism — applying the same operation across huge datasets at once

What "Transformation" Actually Means

Every program you write transforms data.

Examples:

API → transforms request into response
Database → transforms queries into results
Frontend → transforms state into UI

Underneath all of it:

Data moves through memory, gets processed by the CPU/GPU, and is written back.

Memory Is the Real Battlefield

Most performance issues aren't about computation—they're about data movement.

Why?

Because:

CPUs are fast
Memory access is slow

So your system's efficiency depends on:

How often you access memory
How data is structured
How much you move it around

From This to Scalable Systems

Here's what most developers miss:

Scalable systems are just large-scale data transformation pipelines.

Think about it:

A backend service → processes requests
A queue system → moves data between services
A database → stores and retrieves structured data

At scale, you're not "handling requests".

You're:

managing how data flows, transforms, and persists across machines

Why This Knowledge Matters

Without understanding computing:

You over-fetch data
You design inefficient APIs
You ignore memory costs
You misuse concurrency
You guess performance instead of reasoning about it

With it:

You design systems that scale naturally
You understand bottlenecks
You make intentional trade-offs

The Shift

Most developers think:
"How do I build this feature?"

Better developers think:
"What is the data, and how does it move?"

That's the difference.

Final Thought

Computing isn't magic.
It's not abstract.
It's not high-level.

It's:

structured transformation of data through hardware constraints

Once you understand that:

You stop writing code blindly...
and start engineering systems deliberately.

Embedded Linux Development - Part 5

Tue, 14 Apr 2026 13:21:14 +0000

Until here, I've talked about the embedded Linux development in four stage: toolchain, bootloader, Linux kernel, rootfs. In this tutorial, I will create a SD card image including these and then run it in BeagleBone Black.

Firstly, let's remember that what I've produced from these stages:

MLO (second-stage bootloader)
u-boot.img (main bootloader)
uEnv.txt (commands for the bootloader)
zImage (compressed the kernel image)
am335x-boneblack.dtb (device tree for the kernel)
Debian rootfs (including the kernel modules)

How can I create a SD card image including all of these?

Firstly, I need to create two partitions, one for booting and second for rootfs. So plugin the SD card into the PC (I'm on Ubuntu) and create the partitions:

$ sudo parted -s /dev/sdX mklabel msdos # parition table and partitions

$ sudo parted -s /dev/sdX mkpart primary fat32 1MiB 65MiB # boot partition (FAT32, 64MB)
$ sudo parted -s /dev/sdX set 1 boot on # make it first parititon

$ sudo parted -s /dev/sdX mkpart primary ext4 65MiB 100% # rootfs parititon (ext4, rest of SD card)

$ sudo mkfs.vfat -F 32 -n boot /dev/sdX1 # format the boot partition
$ sudo mkfs.ext4 -L rootfs /dev/sdX2 # format the rootfs partition

In here, I created the "boot" partition which was formatted with FAT32 and "rootfs" partition with ext4. Why did I create two distinct partitions? The first reason is that the kernel loads and runs the rootfs. So the bootloader cannot reside in the rootfs because of the bootloader runs before the kernel. Second reason is that the bootloader works with FAT32 better (even if the FAT32 size is much bigger).

After that, copy the MLO, u-boot.img, uEnv.txt, zImage, am335x-boneblack.dtb into the "boot" partition. Also copy the your rootfs content into the "rootfs" partition.

That's it. The SD card is ready to run the BeagleBone Black. So plugin the SD card and then power up the board. Well how to enter into the Debian rootfs? There is a J1 header besides the P9. It's the serial port. Pin 1 is GND, 4 is RX and 5 is TX. Use FT232R converter to connect these pins to PC.

To see the outputs, open a terminal and the type:

$ screen /dev/ttyUSBX 115200 # or /dev/ttyACMX

Reboot the BeagleBone Black and then you will see the u-boot and the kernel messages. Lastly, you will see the login session:

Type the "root" and the password (you set it in previous tutorial). That's it. You are in the BeagleBone Black terminal.

You can do whatever you want after that .

In the next tutorial, I will show that how to use ssh command so that you can easily make connection over USB cable, not needing to J1 header.

Resources:

Simmonds C., Mastering Embedded Linux Programming, Packt Publishing, 2015
Embedded Linux system development training, Bootlin, 2024

Embedded Linux Development - Part4

Mon, 13 Apr 2026 17:18:30 +0000

In this tutorial, I will go with the fourth stage of embedded Linux development which is the rootfs.

Every Linux-based system have a filesystem. If you are on GNU/Linux, you already probably know it and how it structured.

Apart from that embedded Linux needs a few special applications to start up the system. The init is the first program that runs on user-space so that its process ID always is 1. This init program is responsible for start the other user-space applications and services like shell. It generally resides at /sbin/init, /etc/init, /bin/init or so on. The kernel try to find it and then run.

The organization of a Linux rootfs in terms of directories is well-defined by the Filesystem Hierarchy Standard. The general hierarchy:

/bin: Basic programs
/boot: Kernel images, configurations and booting tools
/dev: Device files
/etc: System-wide configuration
/home: Directory for the users home utilities
/lib: Basic libraries
/media: Mount points for removable media
/mnt: Mount point for a temporarily mounted filesystem
/proc: Mount point for the proc virtual filesystem
/root: How directory of the root user
/run: Run-time variable data
/sbin: Basic system programs
/sys: Mount point of the sysfs virtual filesystem
/tmp: Temporary files
/usr: User-specific utilities
/var: Variable data files, for system services

So in summary, I need to create a Linux rootfs and then put the required applications in there. I also want to build a development environment. For example, I want to run python 3 scripts, compiling C/C++ programs, or so on. But how?

There are three options here:

Building everything from scratch
A minimal BusyBox rootfs
A Debian rootfs with debootstap

Which option is for me?

Building everything from scratch means that creating the directories and then fetch the every program, package, library by hand. It means the hell of package dependency! It's not for me.

A minimal rootfs can be created with BusyBox easily. It can create the classic Linux directories and put the core utilities in there like cp, mkdir, ls or so on. If you're making embedded Linux system first time and just focusing on a "running" system, BusyBox is for you. But I need more. I wanna create a development environment!

The right tool is debootstrap program. It creates a base Debian rootfs including the utilities that we're using everyday like apt, systemctl, vi, or so on. This Debian rootfs is around ~200MB, while BusyBox rootfs is ~1MB.

By the way, if you want to go with BusyBox rootfs (while I'm not), below is the required commands:

$ git clone https://git.busybox.net/busybox
$ cd busybox
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- defconfig
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j$(nproc)
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- menuconfig # optional
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- CONFIG_PREFIX=path/to/linux/rootfs install

Let's focus on debootstrap. Firstly download it.

$ sudo apt install qemu-user-static debootstrap

In here, I also installed qemu-user-static which lets me to run the ARM binaries onto x86_64.

Let's create the base Debian rootfs:

$ sudo debootstrap --arch=armhf --foreign bookworm path/to/linux/rootfs http://deb.debian.org/debian
$ sudo chroot path/to/linux/rootfs /debootstrap/debootstrap --second-stage

In here, bookworm is the nickname of Debian 12 which is the last stable version.

These two commands download the rootfs and then unpack it. So it takes some time (~30 minutes in my case). Don't forget, these just fetch the required and important packages from the Debian database, not fully OS.

The rootfs is ready to be used. But there are some tricks that you always must do:

$ sudo cp /usr/bin/qemu-arm-static <path/to/linux/rootfs>/usr/bin/

I also want to install the additional packages and make some settings. For example, you always must set the password. That means I need to run this rootfs on my Ubuntu host:

$ sudo chroot path/to/linux/rootfs

First thing you must is to update the password:

root@can:/# passwd
New password: 
Retype new password: 
passwd: password updated successfully

Install the additional packages if you want:

root@can:/# apt install gcc python3 vim openssh-server # and what you need

In here, make sure that you install the openssh-server. It's required for ssh command.

Lastly, I need to install the kernel modules in this rootfs. Go back to the kernel source and run:

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- INSTALL_MOD_PATH=path/to/linux/rootfs modules_install

That's it. I created the proper Debian rootfs that I can make software development. In the next tutorial, I will use the all artifacts coming from u-boot, the kernel and the rootfs to make SD card image.

Resources:

Simmonds C., Mastering Embedded Linux Programming, Packt Publishing, 2015
Embedded Linux system development training, Bootlin, 2024

Embedded Linux Development - Part 3

Mon, 13 Apr 2026 14:06:30 +0000

In this tutorial, I'll go with the third stage of embedded Linux development. That's the Linux kernel.

It's the responsible for:

Manage all the hardware resources: CPU, memory, I/O.
Provide a set of portable, architecture and hardware independent APIs to allow user space applications and libraries to use the hardware resources.
Handle concurrent accesses and usage of hardware resources set of system calls.

The kernel provides about 400 system calls that provide the services like opening the disk file, forking the new process, managing the memory or so on. These system calls are defined in /usr/include/x86_64-linux-gnu/asm/unistd.h like:

 #define __NR_read 0
 #define __NR_write 1
 #define __NR_open 2
 #define __NR_close 3
 #define __NR_stat 4
 #define __NR_fstat 5
 #define __NR_lstat 6
 #define __NR_poll 7
 #define __NR_lseek 8
 #define __NR_mmap 9
 #define __NR_mprotect 10
 #define __NR_munmap 11
 #define __NR_brk 12

(...)

In user-space applications, we generally don't use these system calls directly. These system calls are wrapped by the standard POSIX C library. If you're a programmer, you already know it.

Let's start with downloading Linux kernel:

$ git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

I have the 6.14 kernel (slightly older, but doesn't matter). As you see that the kernel contains thousands of device drivers, filesystem drivers, network protocols and other configurable items.

As I did previously at u-boot stage, the first thing is to configure the kernel according to BeagleBone Black over configuration files (ends with _defconfig).

Which configuration file should be used for BeagleBone Black? It's omap2plus_defconfig under linux/arch/arm/configs (OMAP is the processor family including the AM335x Sitara processor by TI).

So let's configure the kernel:

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- omap2plus_defconfig

It will create the .config and write the associated configs in it.

As I said, this configuration file includes the generic AM335x Sitara processor configs. To customize and tailor the kernel further:

$ make menuconfig # or xconfig (for Qt-based)

It will open the terminal-based GUI window to select/unselect the configurable items like:

If you're unfamiliar or newer, I DON'T recommend it. But I need to make an important configuration in here about the USB gadget support. As I will explain in the next tutorail, I wanna use the ssh command to make connection with BeagleBone Black. If you don't make it, you're totally free.

Navigate to Device Drivers --> USB Support --> USB Gadget Support --> USB Gadget precomposed configurations --> Ethernet Gadget (with CDC Ethernet support), type "M" and then exit by saving. It will create the virtual USB link so that I can use the ssh command to connect to BeagleBone Black. I will explain it in the last tutorial in detail.

By the way, you will see the "*" and "M" marks as you navigate the configs. "*" means that the configs will be embedded into the kernel image, while "M" means that the configs is built as modules. These are plugins that can be loaded/unloaded dynamically at runtime to the kernel.

After configured the kernel, for now, you're ready to build the required outputs.

Which outputs exactly should be built from the kernel source? Three things:

zImage
am335x-boneblack.dtb
kernel modules

zImage is the compressed the Linux kernel image. am335x-boneblack.dtb is the device tree blob that describes the hardware connected to the kernel. The kernel modules also are being compiled externally, not embedded into the kernel image.

In here, I have to explain the device tree concept. It's the description of the hardware that the kernel manages at runtime. As you expect, the kernel must know the hardware that it will manage. It's written generally by the processor vendor or development board engineers. The device tree corresponding to BeagleBone Black is the am335x-boneblack.dts under linux/arch/arm/boot/dts/ti/omap.

To produces these outputs:

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j$(nproc) zImage dtbs modules

It will take for a while (~1 hours in my case). After that you will see the zImage under linux/arch/arm/boot and am335x-boneblack.dtb under linux/arch/arm/boot/dts/ti/omap.

The kernel modules are compiled ending with .ko suffix. After the rootfs is being created, I will install these kernel modules in it:

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- INSTALL_MOD_PATH=path/to/linux/rootfs modules_install

But DON'T do it for now. I need to create a rootfs firstly and then install the kernel modules in there. I will show it in the next tutorial.

That's it. I've produced the three essential components from the kernel source: zImage, am335x-boneblack.dtb, and kernel modules. In the next tutorial, I will interest with the rootfs.

Resources:

Simmonds C., Mastering Embedded Linux Programming, Packt Publishing, 2015
Embedded Linux system development training, Bootlin, 2024

Embedded Linux Development - Part 2

Sun, 12 Apr 2026 19:13:05 +0000

In this tutorial, I will continue the embedded Linux development series with second stage which is the bootloader.

Firstly, a bit theoretical background.

The bootloader is a piece of code responsible for:

Basic hardware initialization
Loading of an application binary, usually an operating
system kernel, from flash storage, from the network, or from another type of non-volatile storage
Possible decompression of the application binary
Execution of the application

Besides these basic functions, most bootloaders provide a shell or menu:

Menu to select the operating system to load
Shell with commands to load data from storage or network, inspect memory, perform hardware testing/diagnostics

Boot process highly is depended to processor. Let's focus on AM335x Sitara (ARM) booting sequence.

Most embedded processors include a ROM code that implements the initial step of the boot process. It's called the first-stage loader. This ROM code is written by the processor vendor directly built into the processor. That means, it cannot be changed or updated by the others. It initializes the CPU and internal SRAM. It also searches the MLO from NAND/NOR flash, from USB, from SD card, from eMMC, etc.

MLO is a file that you need to produce from the bootloader source code. It's called also second-program loader (SPL). Its mission is to initialize the DDR RAM and run the main bootloader.

The main bootloader initializes the hardware and then loads the Linux kernel and then jump to it. I will use the U-Boot. It's the mostly used bootloader in embedded world.

In summary, the booting process: ROM code --> MLO (SPL) --> U-Boot --> Linux kernel.

So after compiled the u-boot, I expect these:

MLO
u-boot.img

Let's produce these.

Firstly, download the u-boot:

$ git clone https://source.denx.de/u-boot/u-boot.git

If you look at the source code, you will see that the u-boot supports a lot of processors and boards. So first thing you should do is to configure the u-boot over configuration files (ends with _*_defconfig_) under u-boot/configs.

But which exactly configuration file corresponds to BeagleBone Black? The answer is _am335x_evm_defconfig_. It's generic AM335x Sitara processor configuration file.

To use this configuration file:

$ make am335x_evm_defconfig

It will create the .config file and write the configs in it. The important point is that you never edit this file by hand.

To customize and tailor this configs further:

$ make menuconfig     # or xconfig (for Qt-based)

It will open the terminal-based GUI to select/unselect the configs. If you are unfamiliar or newer, you should NOT do it. Because it will show the tons of different configs and it can seem messy. The previous command already made the generic required configs.

After setting up the configs, let's build the outputs.

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-

It will take for a while. Because it will compile the tons of source file and then link them together. The output will be like:

(...)

  AR      spl/fs/fat/built-in.o
  CC      spl/fs/fs_internal.o
  AR      spl/fs/built-in.o
  CC      spl/net/arp.o
  CC      spl/net/bootp.o
  CC      spl/net/eth-uclass.o
  CC      spl/net/eth_common.o
  CC      spl/net/net.o
  CC      spl/net/ping.o
  CC      spl/net/tftp.o
  AR      spl/net/built-in.o
  LDS     spl/u-boot-spl.lds
  LD      spl/u-boot-spl
  OBJCOPY spl/u-boot-spl-nodtb.bin
  COPY    spl/u-boot-spl.bin
  MKIMAGE MLO
  MKIMAGE MLO.byteswap
  SYM     spl/u-boot-spl.sym
  MKIMAGE u-boot-dtb.img
  OFCHK   .config

After that you can see the u-boot/MLO, u-boot/u-boot.img and a lots of other files.

As I said before, I need the MLO and u-boot.img and will use these in further. For now, just keeps these in mind.

There is also one more important file that I need. It's uEnv.txt and used by the u-boot when loading the Linux kernel. It consists of the key-value pairs that tell some command to u-boot. So create a new file named of it.

$ vim uEnv.txt

And write the following commands in it.

bootpart=0:1
devtype=mmc
bootdir=
bootfile=zImage
bootpartition=mmcblk0p2
console=ttyS0,115200n8
loadaddr=0x82000000
fdtaddr=0x88000000
set_mmc1=if test $board_name = A33515BB; then setenv bootpartition mmcblk1p2; fi
set_bootargs=setenv bootargs console=${console} root=/dev/${bootpartition} rw rootfstype=ext4 rootwait
uenvcmd=run set_mmc1; run set_bootargs;run loadimage;run loadfdt;printenv bootargs;bootz ${loadaddr} - ${fdtaddr}

At the end of this series, you will fully understand what these are. But basically:

the console name is set to ttyS0 and baud rate to 115200.
the Linux kernel name is defined as zImage.
the address that Linux kernel image will be placed is set to 0x82000000 and the address that device tree blob will be placed to 0x88000000.
set the boot environment and load the Linux kernel with bootz command.

Save it and then keep this file in mind as being MLO and u-boot.img.

That's it. You've produced the three components related to bootloader stage. In next tutorial, I will interest with Linux kernel itself.

Resources:

Simmonds C., Mastering Embedded Linux Programming, Packt Publishing, 2015
Embedded Linux system development training, Bootlin, 2024

Embedded Linux Development - Part 1

Sun, 12 Apr 2026 12:59:13 +0000

In today, I'm beginning a new series about embedded Linux development. I'll show that how to build an end-to-end embedded Linux system from scratch by hand.

I'll fetch the associated every stuffs from source code and then build the corresponding outputs.

I will target the BeagleBone Black Rev C board. I will compile the everything for that board. So you need the following things for this series:

BeagleBone Black Rev C
USB Mini-B to USB-A cable
FTDI FT232R converter
SD card

Overall, embedded Linux development consists of four components:

Toolchain
Bootloader
Linux kernel
Rootfs

In this tutorial, I will explain the toolchain that I need for all development sequence.

The toolchain is the first element of embedded Linux and the starting point of the project.

A toolchain is the set of tools that compiles source code into executables that can run on your target device, and includes many binaries for the different purposes. Usually, toolchains for Linux are based on components from the GNU project. A standard GNU toolchain consists of three main components:

Binutils is a set of tools to generate and manipulate binaries for a given architecture. Common binaries: as, ld, ar, randlib, objdump, readelf, size, nm, strings, strip, etc.
GCC is the main compiler.
C library is used to interract with the kernel. The programming interface to the UNIX operating system is defined in the C language, which is defined by the POSIX standards. The C library is the implementation of the interface.

In here, there are two types of toolchain:

Native: This toolchain runs on the same type of system.
Cross: This toolchain run on a different type of system than the target.

Almost all embedded Linux development is done using a cross development toolchain. Because doing embedded development, there is always a split between:

The host, the development workstation
The target, which is the embedded system

They are connected by various means: almost always a serial line for debugging purposes, frequently a network connection, sometimes a JTAG interface for low-level stuffs.

Many UNIX/Linux toolchains rely on architecture tuple names to identify machines. You probably compiled many programs on your host already and used the gcc command. But it's actually a shorthand. You can exactly see it with:

$ gcc -dumpmachine
x86_64-linux-gnu

Other examples: arm-linux-gnueabihf, mips64el-linux-gnu, arm-none-eabi- etc.

These tuples are 3 or 4 parts:

The architecture name: arm, riscv, mips64el, etc.
Optionally, a vendor name, which is free-form string.
An operating system name, or none when not targeting an operating system.

Of course, these are the pre-built toolchains. If you want, you can also create your own toolchain with crosstool-ng. It's another tutorial topic. But shortly, when building a toolchain, the ABI used to generate binaries needs to be defined. ABI, Application Binary Interface, defines the calling conventions (how function arguments are passed, how the return value is passed, how system calls are made or so on) and the organization of structures. All binaries in a system are typically compiled with the same ABI, and the kernel must understand this ABI.

Anyway, I gave you the enough theoretical toolchain background. Let's go with our concern.

Which toolchain should be used for BeagleBone Black?

You have to know the used ARM processor in here. BeageBone Black has AM335x Sitara processor which is based on ARM-A8 (ARMv7), 32-bit architecture. So the toolchain for that is the gcc-arm-linux-gnueabihf.

The first thing in implementing embedded Linux is to install it.

$ sudo apt install gcc-arm-linux-gnueabihf

After that validate it.

$ arm-linux-gnueabihf-gcc --version
arm-linux-gnueabihf-gcc (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

That's it. You have the required toolchain and ready to go with the bootloader.

Resources:

Simmonds C., Mastering Embedded Linux Programming, Packt Publishing, 2015
Embedded Linux system development training, Bootlin, 2024

Can AI Review Physics? Yes — That Is Why We Built SPAR

Sun, 12 Apr 2026 09:36:41 +0000

A standalone review framework for checking whether outputs deserve the claims attached to them.

Most review systems answer a familiar question:

Did the system still produce the expected output?

SPAR is built for a narrower and more dangerous one:

Does the output still deserve the claim attached to it?

That is the split. Not reliability alone, but admissibility.

In practical terms, admissibility means claim-worthiness: whether a result justifies the interpretation, governance status, or scientific statement built on top of it.

A system can be reliable and inadmissible at the same time.

A physics engine can compute beta_G_norm, return zero, pass regression, and stay green across the whole pipeline. The report can still say the background is admissible. But if the function producing beta_G_norm is a stub that always returns zero, the output is stable while the claim attached to it is false.

That is not hypothetical. It is one concrete class of review failure SPAR was designed to surface.

What SPAR Is

SPAR (Sovereign Physics Autonomous Review) is a deterministic framework for claim-aware review.

It does not replace unit tests. It does not replace regression benchmarks. It does not replace scoring systems. It reviews a different object:

the output
the claim attached to that output
the implementation state behind it
the maturity state that should travel with it

SPAR started inside Flamehaven-TOE, an open physics simulation and AI governance engine. It has since been extracted into a standalone open-source framework:

github.com/flamehaven01/SPAR-Framework

The framework includes a generic review kernel, explicit score and verdict policy, registry-backed review surfaces, and a first domain adapter for physics. Physics is the first adapter and the first domain where this review model was stress-tested. It is not the limit of the framework.

The core idea is simpler than the name: an output can pass while the claim attached to it drifts.

Why Ordinary Review Is Not Enough

Ordinary review is usually shallow by necessity. It asks questions like:

did the code run
did the output shape stay valid
did the score remain within bounds
did regression remain green

Those are necessary checks. They are not always enough.

The failure SPAR cares about is not, in the first instance, a crash. It is not even always a wrong number. It is this:

the code executes
the output looks plausible
the tests pass
and the interpretation is still overstated or structurally false

That failure can appear in several ways: a placeholder implementation returns stable-looking values; a maturity registry stays stale after the implementation improves; a score looks smooth before its epistemic basis is strong enough to justify the interpretation attached to it; an approximation gets reported as closure.

None of these failures is spectacular. That is exactly why they are easy to miss.

A Minimal Divergence

The clearest way to see the difference is in review form.

{
  "ordinary_regression": {
    "kernel_exec": "PASS",
    "output_contract": "PASS",
    "test_suite_status": "GREEN"
  },
  "spar_review": {
    "layer_a": "CONSISTENT",
    "layer_b": "CONSISTENT",
    "layer_c": "GAP_STATE_MISMATCH",
    "finding": "Implementation path is genuine; registry classification remains stale",
    "required_action": "RECLASSIFY"
  }
}

Ordinary regression says the system still works. SPAR says the system may no longer be describing its own computation truthfully.

SPAR is not "tests, but harsher." It can produce a different review outcome even when ordinary regression remains green. In this case, the required action is not rejection. It is reclassification. That is not the same as testing harder. It is reviewing a different object.

The Core Mismatch Classes

SPAR treats three mismatch classes as first-class review objects.

Anchor mismatch — the output conflicts with a declared analytical or contractual anchor.

Interpretation mismatch — the report language claims more than the implementation state justifies.

Maturity mismatch — the implementation, registry, and outward-facing claim have drifted out of sync.

Ordinary review mostly checks whether a system still passes. SPAR checks whether the result is still being described honestly.

The Three-Layer Structure

Layer A — Anchor Consistency

Layer A checks whether output agrees with a declared analytical or contractual anchor. The expected value is not "whatever the engine produced last time." It is "what the declared contract says must appear for this background, under this formulation."

# Flat Minkowski: beta residuals must vanish
status = CONSISTENT if abs(beta_G(output)) <= 1e-4 else ANOMALY

# de Sitter: admissibility gate must FAIL
# A PASS here indicates a gate defect, not a success.

Layer A tests agreement with a declared reference contract — not truth in some unconstrained universal sense. Analytical anchors depend on regime, normalization, and formulation. That distinction matters. Still, the engineering value is clear: reliability can remain intact while anchor-consistency fails. A Layer A anomaly means the output contradicts the contract the system claims to be using.

Layer B — Interpretation Validity

Layer B checks whether the interpretation attached to the output stays within declared scope. This layer is deterministic — it does not rely on a free-form LLM judge. It uses explicit rule tables over structured runtime artifacts, maturity states, and report text.

Typical checks: does the report claim full closure while the path is still heuristic or partial; is a bounded approximation being described as exact; is an environment-conditional bridge being written up as universal; are overclaim phrases appearing where runtime state does not support them.

Layer B does not eliminate semantic ambiguity. What it does is narrow the problem from "solve rhetoric in general" to "enforce explicit admissibility contracts against declared model states." That makes it auditable. Not complete. Auditable.

Layer C — Existence and Maturity Probes

Layer C asks what kind of implementation produced the result: genuine, approximate, gapped, environment-conditional, or research-only.

This is where SPAR becomes especially different from ordinary review. It does not merely score outputs. It checks the ontological status of the path that produced them. A result from a known-limited path is not the same thing as a result from a genuine path. A research probe is not production-grade closure. A dependency-bound bridge is not a universal capability. Those distinctions change what the output is allowed to claim.

Why the Registry Matters

A framework like this needs more than score outputs. It needs structured state that can travel with the result.

ARCHITECTURE_GAPS = {
    "C4_sidrce_omega": (
        "SIDRCE Omega (v4.5+): chi-squared Gaussian model. "
        "score = exp(-chi2/2), chi2 = (||beta||/tol)^2. "
        "Derived from zero-centered Gaussian likelihood. "
        "GAP: tolerance values are calibration parameters with "
        "no first-principles derivation of their exact magnitude."
    ),
    "C8_rg_linearized": (
        "RG flow: linearized dilaton ODE only. Metric does NOT flow. "
        "APPROXIMATION: valid only for small perturbations "
        "around a fixed background geometry."
    ),
}

A machine-readable registry turns caveat prose into runtime surface. That lets review results carry explicit maturity labels — open, partial, closed, environment_conditional, research_only — rather than vague prose. Without that surface, approximation and closure collapse into the same sentence.

Scoring Policy Is Explicit

SPAR keeps score policy visible. No hidden learned weights.

SCORE_TABLE = {
    "ANOMALY":       -15,   # contradicts an analytical anchor
    "FAIL":          -10,   # review-layer failure
    "GAP":            -5,   # honest gap disclosure
    "WARN":           -3,   # bounded concern
    "APPROXIMATION":  -2,   # known simplification
}

def journal_verdict(score, layer_a):
    if count_anomalies(layer_a) >= 2:  return "REJECT"
    if score >= 85:                    return "ACCEPT"
    if score >= 70:                    return "MINOR REVISION"
    if score >= 50:                    return "MAJOR REVISION"
    return "REJECT"

These are not laws of nature. They are review policy. A hidden learned scorer may feel sophisticated. An explicit policy is easier to inspect, debate, and change.

Two or more Layer A anomalies trigger unconditional REJECT regardless of total score. Mathematical contract failures are not averaged away by cleaner signals elsewhere.

A Concrete Example: The Omega Score Transition

Flamehaven-TOE's primary governance metric, SIDRCE Omega, once relied on a large arbitrary multiplicative constant applied to the raw residual. The outputs looked stable. Nothing felt obviously broken.

SPAR still flagged it. Stability was not the right question. The stronger question was whether the formula justified the interpretation being attached to it. A free scaling constant with no physical derivation is not the same thing as a physically motivated model.

The formula was replaced with a chi-squared Gaussian construction:

gs_score = math.exp(-0.5 * (beta_result.beta_G_norm / tol_G) ** 2)
b_score  = math.exp(-0.5 * (beta_result.beta_B_norm  / tol_B) ** 2)
si_score = math.exp(-0.5 * (beta_result.beta_Phi_norm / tol_Phi) ** 2)

omega_physics = (gs_score * b_score * si_score) ** (1/3)

That change matters because it introduces a reversible relation to the underlying residual:

||beta|| = tol * sqrt(-2 * ln(score))

Given a reported score, the residual is recoverable. The score is no longer just a presentation layer. It encodes a falsifiable relation to the quantity beneath it.

SPAR did not respond by declaring the problem solved. It updated the classification precisely: the formula ceased to be arbitrary, but the remaining gap shifted to the tolerance scales, which are still calibration parameters. That is a narrower and more honest claim than either "arbitrary" or "fully resolved."

That is exactly the kind of distinction SPAR is built to review.

Quick Start

pip install -e .[dev]

from spar_framework.engine import run_review
from spar_domain_physics.runtime import get_review_runtime

runtime = get_review_runtime()

result = run_review(
    runtime=runtime,
    subject={
        "beta_G_norm": 0.0,
        "beta_B_norm": 0.0,
        "beta_Phi_norm": 0.0,
        "sidrce_omega": 1.0,
        "eft_m_kk_gev": 1.0e16,
        "ricci_norm": 0.02,
    },
    source="flat minkowski",
    gate="PASS",
    report_text="Bounded report text.",
)

print(result.verdict)
print(result.score)
print(result.model_registry_snapshot["total_models"])

The review result carries more than pass/fail: a verdict, a score, and a maturity-aware review surface. That surface is what makes the output governable rather than just evaluable.

Where This Framework Fits

Physics remains the first adapter and strongest early testbed. The review pattern is broader.

It fits anywhere outputs can pass while the attached claim can drift: scientific computing pipelines, PDE and simulation workflows, scientific ML surrogates, inverse and calibration models, AI code review, model governance, regulated analytics and reporting.

That does not mean every team needs the full framework. Often the first useful step is smaller.

A Lightweight Adoption Path

Level 1 — Claim Check. Add three explicit questions to an existing workflow: What is the output actually claiming? Does that claim match the implementation state? Is this result exact, approximate, partial, or heuristic? Most teams can do this immediately with no new tooling.

Level 2 — Maturity Labels. Attach state labels to results: heuristic, partial, closed, environment_conditional. A small registry. Already a meaningful step beyond ordinary review.

Level 3 — Full SPAR. Layer A anchor consistency, Layer B interpretation validity, Layer C existence and maturity probes, registry-backed snapshots, explicit score and verdict policy.

SPAR can be used as a review habit before it is adopted as a full framework.

What SPAR Does Not Do

SPAR does not provide a universal truth engine, free-form LLM judging in the core, domain contracts inside the generic kernel, or certainty about whether a scientific claim is true in all possible senses.

SPAR is not a machine for declaring truth. Its narrower goal is to make claim drift reviewable.

Reliability Is Not Enough

Reliability asks whether a system produces stable, repeatable outputs. Admissibility asks whether those outputs deserve the meanings attached to them.

A stub that always returns zero can be reliable. A heuristic threshold can be reliable. A smoothly calibrated score can be reliable. None of those facts alone makes the resulting claim justified.

Current AI and scientific tooling are already better at measuring reliability than admissibility. That asymmetry is understandable — reliability is easier to benchmark, easier to automate, easier to ship in CI. But admissibility is where silent approximations, overstated claims, and maturity mismatches accumulate.

SPAR is one working answer to that problem. Not a universal answer. A technical one.

It turns implementation state, maturity state, analytical anchoring, and scope honesty into review objects that can travel with the result.

That is why the architecture may matter outside the domain that produced it.

Repository: github.com/flamehaven01/SPAR-Framework
Docs: What Is SPAR · Admissibility · Physics as the Proof Case · Use Cases

The Linux Programming Interface - Memory Mappings

Wed, 08 Apr 2026 11:50:41 +0000

Let's continue discussing the Linux programming with mmap() system call.

The mmap() system call creates a new memory mapping in the calling process's virtual address space. There are two types of mapping:

File mapping: A file mapping maps a region of a file directly into the calling process's virtual memory.
Anonymous mapping: An anonymous mapping doesn't have a corresponding file. Instead, the pages of the mapping are initialized to 0.

The memory in one process's mapping may be shared with mappings in other processes (MAP_SHARED). This can occur in two ways:

When two processes map the same region of a file, they share the same pages of physical memory.
A child process created by fork() inherits copies of its parent's mappings, and these mappings refer to the same pages of physical memory as the corresponding mappings in the parent.

We also set the memory mapping as private (MAP_PRIVATE) so that other processes cannot see the content of the memory mapping.

In total, we can use mmap() in four situations:

Private file mapping
Private anonymous mapping
Shared file mapping
Shared anonymous mapping

And don't forget exec() family erase and rebuild the process virtual memory so that memory mapping is lost.

If you type the man 2 mmap and see the its signatures:

void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset);
int munmap(void *addr, size_t length);
int msync(void *addr, size_t length, int flags);
void *mremap(void *oldaddr, size_t oldsize, size_t newsize, int flags, ... /* void *newaddr */)

In here:

The addr argument indicates the virtual address at which the mapping is to be located. You should put the NULL so that kernel selects the proper address.
The length argument specifies the size of the mapping in bytes.
The prot argument is a bit mask specifying the protection to be placed on the mapping and can take PROT_NONE, PROT_READ, PROT_WRITE, PROT_EXEC. For example, PROT_READ | PROT_WRITE means that mapping can be read and written but not executed.
The flags argument is a bit mask of options controlling various aspects and can be MAP_PRIVATE and MAP_SHARED.
The fd and offset arguments are just for file mapping. But, in case of anonymous mapping, it is good practice to set fd as -1.

Below is the simple anonymous file mapping program:

 #include "../linux.h"

void main(int argc, char *argv[])
{
   char *addr;
   int fd;
   struct stat sb;

   if (argc != 2 || strcmp(argv[1], "--help") == 0)
      usage_error("Wrong command-line usage");

   fd = open(argv[1], O_RDONLY);
   if (fd == -1)
      syscall_error();

   if (fstat(fd, &sb) == -1)
      syscall_error();

   addr = mmap(NULL, sb.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
   if (addr == MAP_FAILED)
      syscall_error();

   if (write(STDOUT_FILENO, addr, sb.st_size) == -1);
      syscall_error();

   exit(EXIT_SUCCESS);
}

As can be seen above, for file mapping (private or shared), the following steps are applied:

Obtain the file descriptor that is mapped, typically via a call to open().
Use stat() system call to get the file length in bytes.
Pass these variables to mmap() system call call with NULL as start address of mapping.

Below is the another example about shared file mapping:

 #include "../linux.h"

 #define MEM_SIZE 10

void main(int argc, char *argv[])
{
   char *addr;
   int fd;

   if (argc < 2 || strcmp(argv[1], "--help") == 0)
      usage_error("Wrong command-line usage");

   fd = open(argv[1], O_RDWR);
   if (fd == -1)
      syscall_error();

   addr = mmap(NULL, MEM_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
   if (addr == MAP_FAILED)
      syscall_error();

   if (close(fd) == -1)       /* No longer need 'fd' */
      syscall_error();

   printf("Current string=%.*s\n", MEM_SIZE, addr);

   if (argc > 2) {            /* Update contents of region */
      if (strlen(argv[2]) >= MEM_SIZE)
         usage_error("String too long");
      
      memset(addr, 0, MEM_SIZE); /* Zero out region */
      strncpy(addr, argv[2], MEM_SIZE - 1);
      if (msync(addr, MEM_SIZE, MS_SYNC) == -1)
         syscall_error();

      printf("Copied \"%s\" to shared memory\n", argv[2]);
   }
   exit(EXIT_SUCCESS);
}

In this example, we see the writing 10 bytes to shared memory mapping after the zeroing a partition of file mapping. In addition, we see the msync() system call. It is actually optional but good practice when writing to disk. It ensures that the 10 bytes are written to disk.

In addition to MAP_PRIVATE and MAP_SHARED, Linux allows a number of other values to be included in the mmap() flags argument:

MAP_ANONYMOUS
MAP_FIXED
MAP_LOCKED
MAP_HUGETLB
MAP_NORESERVE
MAP_PRIVATE
MAP_POPULATE
MAP_SHARED
MAP_UNINITIALIZED

Please read the manual page (man 2 mmap) to learn these flags.

When talking about memory mapping and virtual memory layout, I wanna give you some virtual memory operations. There are four main system call:

The mprotect() system call changes the protection on a region of virtual memory.
The mlock() and mlockall() system calls lock a region of virtual memory into physical memory.
The mincore() system call allows a process to determine whether the pages in a region of virtual memory are resident in physical memory.
The madvise() system call allows a process to advise the kernel about its future patterns of usage of a virtual memory region.

Signatures of these system calls:

int mprotect(void *addr, size_t len, int prot);
int mlock(const void *addr, size_t len);
int mlockall(int flags);
int munlock(const void *addr, size_t len);
int munlockall(void);
int mincore(void *addr, size_t length, unsigned char *vec);
int madvise(void *addr, size_t length, int advice);

Below is the simple program about changing the memory protection mapped by mmap() system call.

 #include "../linux.h"

 #define LEN          (1024 * 1024)
 #define SHELL_FMT    "cat /proc/%ld/maps | grep zero"
 #define CMD_SIZE     (sizeof(SHELL_FMT) + 20)

void main(int argc, char *argv[])
{
   char cmd[CMD_SIZE];
   char *addr;
 
   addr = mmap(NULL, LEN, PROT_NONE, MAP_SHARED | 
               MAP_ANONYMOUS, -1, 0);
   if (addr == MAP_FAILED)
      syscall_error();
 
   /* Display line from /proc/self/maps corresponding to mapping */
 
   printf("Before mprotect()\n");
   snprintf(cmd, CMD_SIZE, SHELL_FMT, (long) getpid());
   system(cmd);
 
   /* Change protection on memory to allow read and write access */
 
   if (mprotect(addr, LEN, PROT_READ | PROT_WRITE) == -1)
      syscall_error();

   printf("After mprotect()\n");
   system(cmd);

   exit(EXIT_SUCCESS);
}

In here, firstly I've mapped a shared anonymous memory. mprotect() changes the memory mapping's from none to read and write protections. To see the this change, we can inspect the /proc/PID/maps file.

Until here, I gave you the overall memory mapping techniques. I'll explain the shared memory which is the most effective data transmission IPC mechanism of Linux in further article.

Resource:

Kerrisk M., The Linux Programming Interface, no starch press, 2010

The Linux Programming Interface - Time

Wed, 08 Apr 2026 10:43:35 +0000

In any type of program, we mostly are interested in two different time:

Real (Calendar) time: This time is measured from a standard point (generally, UTC, 1 January 1970). Obtaining the calendar time is primarily source of what you see at screen of your computer.
Process time: This is the amount of CPU time used by a process. Measuring process time is useful for checking or optimizing the performance of a program or algorithm.

Every computer has a dedicated built-in hardware clock that enables the kernel to measure real and process time.

Calendar Time and Time Conversion

To handle real time, the GNU libraries give us many functions as below:

These are also function signatures that we use when handling time in the program:

time_t time(time_t *tloc);
char *asctime(const struct tm *tm);
char *ctime(const time_t *timep);
struct tm *gmtime(const time_t *timep);
struct tm *localtime(const time_t *timep);
time_t mktime(struct tm *tm);
size_t strftime(char *s, size_t max, const char *format, const struct tm *tm);

The time() system call returns the number of seconds since the Epoch (1 January 1970) and then this number of seconds are stored in _time_t_ (typedef long time_t) data type.

To convert this number of seconds in printable format, we use the ctime() function.

We can also convert this number of seconds into a so-called broken-down time (struct tm) by using gmtime() and localtime() functions. After that, we see the year, month, week, hours and so on.

The mktime() function does vise-verse, translates a broken-down time into number of seconds.

We also use asctime() to convert broken-down time to printable format.

I put here a simple program that shows the how to use these functions I've described:

 /* Retrieving and converting calendar times */

 #include "../linux.h"

 #define SECONDS_IN_TROPICAL_YEAR    (365.24219 * 24 * 60 * 60)

void main(int argc, char *argv[])
{
   time_t t;
   struct tm *gmp, *locp;
   struct tm gm, loc;
   struct timeval tv;

   t = time(NULL);
   printf("Seconds since the Epoch: %ld", (long) t);
   printf(" (about %6.3f years)\n", t / SECONDS_IN_TROPICAL_YEAR);

   if (gettimeofday(&tv, NULL) == -1)
      syscall_error();
   printf(" gettimeofday() returned %ld secs, %ld microsecs\n",
      (long) tv.tv_sec, (long) tv.tv_usec);

   gmp = gmtime(&t);
   if (gmp == NULL)
      syscall_error();

   gm = *gmp;  /* Save local copy */

   printf("Broken down by gmtime():\n");
   printf(" year=%d, mon=%d, mday=%d, hour=%d, min=%d, sec=%d ", 
      gm.tm_year, gm.tm_mon, gm.tm_mday, gm.tm_hour, gm.tm_min, gm.tm_sec);
   printf(" wday=%d, yday=%d, isdst=%d\n", gm.tm_wday, gm.tm_yday, gm.tm_isdst);

   locp = localtime(&t);
   if (locp == NULL)
      syscall_error();

   loc = *locp;   /* Save local copy */

   printf("Broken down by localtime():\n");
   printf(" year=%d, mon=%d, mday=%d, hour=%d, min=%d, sec=%d ", 
      loc.tm_year, loc.tm_mon, loc.tm_mday, loc.tm_hour, loc.tm_min, loc.tm_sec);
   printf(" wday=%d, yday=%d, isdst=%d\n", loc.tm_wday, loc.tm_yday, loc.tm_isdst);

   printf("asctime() formats the gmtime() value as: %s\n", asctime(&gm));
   printf("ctime() formats the time() value as: %s\n", ctime(&t));

   printf("mktime() of gmtime() value: %ld secs\n", (long) mktime(&gm));
   printf("mktime() of localtime() value: %ld secs\n", (long) mktime(&loc));
   
   exit(EXIT_SUCCESS);
}

The strftime() function provides us with more precise control when converting a broken-down into printable form. We just put pre-defined specifiers into third argument of strftime() function. These specifiers:

Below is the another program that shows the function usage:

 /* A function that returns a string containing the current time */

 #include "../linux.h"

 #define BUF_SIZE  1000

/* Return a string containing the current time formatted according to
   the specification in 'format' (see strftime(3) for specifiers).
   If 'format' is NULL, we use "%c" as a specifier (which gives the
   date and time as for ctime(3), but without the trailing newline).
   Returns NULL on error. */

char *currTime(const char *format)
{
   static char buffer[BUF_SIZE];
   time_t t;
   size_t s;
   struct tm *tm;

   t = time(NULL);
   tm = localtime(&t); 
   if (tm == NULL)
      return NULL;

   s = strftime(buffer, BUF_SIZE, (format != NULL) ? format : "%c", tm);
   
   return (s == 0) ? NULL : buffer;
}

Timezones

Different countries operate on different timezones and DST regimes. Programs that input and output times must take care of this.

Timezone information tends to be both voluminous and volatile. So rather than encoding it directly into libraries, the system maintains this information in files under /usr/share/zoneinfo.

To specify a timezone when running a program, we set the TZ environment variable to a string consisting of a colon followed by one of the timezone names (like TZ=":Pacific/Auckland").

The tzset() function is used to obtain the current timezone setting. This function initializes three global variables:

char *tzname[2];
int daylight;
long timezone;

This function first checks the TZ environment variable. If this variable is not set, then the timezone is initialized to the default defined in the timezone file /etc/localtime. If the TZ environment variable is defined with a value that can't be matched to a timezone file, or it is an empty string, then UTC is used.

Locales

Different countries use different conventions for displaying information such as numbers, currency amounts, dates, and times.

Ideally, all programs designed to run in more than one location should deal with locales in order to display and input information in the user's preferred language and format. This constitutes the complex subject of internationalization (I18N).

Like timezone information, locales are maintained under /usr/share/locale. Under each locale subdirectory is a standard set of files that specify the conventions for this locale:

The setlocale() function is used to both set and query program's current locale. Below is the its function signature:

char *setlocale(int category, const char *locale);

There are two different methods of setting the locale. The locale argument may be a string specifying one of the locales defined under /usr/lib/locale or more conveniently selocale(LC_ALL, "") meaning that locale settings should be taken from environment variables.

Process Time

Process time is the amount of CPU time used by a process since it was created. For recording purposes, the kernel separates CPU time into the following two components:

User CPU time (amount of time spent executing in user mode)
System CPU time (amount of time spent executing in kernel mode)

Sometimes, we refer to process time as the total CPU time consumed by the process.

When dealing with process time, times() and clock() functions are used. Signatures are below:

clock_t times(struct tms *buf);
clock_t clock(void);

The times() system call retrieves process time information (both user and system time separately) and store it into struct tms.

Otherwise, clock() function is simpler and returns the total amount of CPU time. Below is the basic program that shows both of these functions.

 /* Retrieving process CPU times */

 #include "../linux.h"

void displayProcessTimes(const char *msg)
{
   struct tms t;
   clock_t clockTime;
   static long clockTicks = 0;
   
   if (msg != NULL)
      printf("%s", msg);

   if (clockTicks == 0) {  /* Fetch clock ticks on first call */
      clockTicks = sysconf(_SC_CLK_TCK);
      if (clockTicks == -1)
         syscall_error();
   }

   clockTime = clock();
   if (clockTime == -1)
      syscall_error();

   printf("clock() returns: %ld clocks-per-sec (%.2f secs)\n",
      (long) clockTime, (double) clockTime / CLOCKS_PER_SEC);

   if (times(&t) == -1)
      syscall_error();

   printf("times() yields: user CPU: %.2f; system CPU: %.2f\n", 
      (double) t.tms_utime / clockTicks, 
      (double) t.tms_stime / clockTicks);
}

void main(int argc, char *argv[])
{
   int numCalls, i;

   printf("CLOCKS_PER_SEC: %ld  sysconf(_SC_CLK_TCK): %ld\n\n",
      (long) CLOCKS_PER_SEC, sysconf(_SC_CLK_TCK));

   displayProcessTimes("At program start:\n");

   numCalls = (argc > 1) ? atoi(argv[1]) : 100000000;
   for (i = 0; i < numCalls; i++)
      (void) getppid();

   displayProcessTimes("After getppid() loop:\n");

   exit(EXIT_SUCCESS);
}

ELF Executable Analysis in Detail

Tue, 07 Apr 2026 11:58:08 +0000

In everyday, we run some kind of programs to handle our works. There are many type of programs, GUIs, CLIs, TUIs or so on. But at low level, there are two kind of program formats: PE (Portable Executable) for Windows and ELF (Executable and Linkable Format) for Linux.

In this tutorial, I will explain the ELF executables in detail.

Firstly, let's start with the overall layout:

As you see, an ELF executable consists of four layers:

Executable Header
Program Headers
Sections
Section Headers

Executable Header

Every ELF file starts with an executable header, which is just a structured series of bytes telling you that it's an ELF file, what kind of ELF file it is, and where in the file to find all the other contents. It's defined as follow in /usr/include/elf.h:

In here:

e_ident: The executable header starts with a 16-byte array. First 4-byte, magic value, identifying the file as an ELF binary.
e_type: The type of the executable. For example REL means relocatable object file, EXEC means executable binary and DYN means dynamic libraries.
e_machine: The architecture that the executable is intended to run on.
e_version: The version of the ELF specification (always 1, I really don't know why it exists ).
r_entry: The virtual address at which execution should start.
e_phoff, e_shoff: The file offsets to the beginning of the program header table and the section header table.
e_flags: The flags specific to the architecture for which the binary is compiled (typically 0 for x86_64).
e_ehsize: The size of the executable header, in bytes (for 64-bit systems, it's always 64).

You can see the executable header with this command:

$ readelf -h ./prog
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Position-Independent Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x1400
  Start of program headers:          64 (bytes into file)
  Start of section headers:          135496 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         13
  Size of section headers:           64 (bytes)
  Number of section headers:         29
  Section header string table index: 28

Section Headers

The code and data in an ELF binary are logically divided into continuous nonoverlapping chunks called sections. Sections don't have any predetermined structure; instead, the structure of each section varies depending on the contents. So every section is described in section header table. It's defined as follow:

In here:

sh_name: The index of the sections.
sh_type: Every section has a type, indicated by an integer field. Common types: PROBITS for machine instructions, SYMTAB for static symbol table, DYNSYM for dynamic symbol table, STRTAB for string tables, REL(A) for relocation entries used by the linker, DYNAMIC for information needed for dynamic linking or so on.
sh_flags: The section flags. Common flags: W means the section is writable, A means the content of the section are to be loaded into memory when executing the executable, X means the section is executable.
sh_addr, sh_offset, sh_size: The virtual address, file offset (in bytes from the start
of the file), and size (in bytes) of the sections.
sh_link: Sometimes, there are relationships between sections. This field keeps the index count of the related sections.
sh_info: Additional information about sections.
sh_addralign: Some sections may need to be aligned in memory in a particular way for efficiency of memory accesses. The values 0 and 1 are reserved to indicate no special alignment needs.
sh_entsize: Some sections contain a table of well-defined data structures. For such sections, this field indicates the size in bytes of each entry in the table. When the field is unused, it is set to zero.

You can see the section headers with this command:

$ readelf --sections --wide ./prog
There are 29 section headers, starting at offset 0x21148:

Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000 000000 00      0   0  0
  [ 1] .interp           PROGBITS        0000000000000318 000318 00001c 00   A  0   0  1
  [ 2] .note.gnu.property NOTE            0000000000000338 000338 000030 00   A  0   0  8
  [ 3] .note.gnu.build-id NOTE            0000000000000368 000368 000024 00   A  0   0  4
  [ 4] .note.ABI-tag     NOTE            000000000000038c 00038c 000020 00   A  0   0  4
  [ 5] .gnu.hash         GNU_HASH        00000000000003b0 0003b0 000028 00   A  6   0  8
  [ 6] .dynsym           DYNSYM          00000000000003d8 0003d8 000378 18   A  7   1  8
  [ 7] .dynstr           STRTAB          0000000000000750 000750 00016d 00   A  0   0  1
  [ 8] .gnu.version      VERSYM          00000000000008be 0008be 00004a 02   A  6   0  2
  [ 9] .gnu.version_r    VERNEED         0000000000000908 000908 000080 00   A  7   2  8
  [10] .rela.dyn         RELA            0000000000000988 000988 0000d8 18   A  6   0  8
  [11] .rela.plt         RELA            0000000000000a60 000a60 0002d0 18  AI  6  24  8
  [12] .init             PROGBITS        0000000000001000 001000 00001b 00  AX  0   0  4
  [13] .plt              PROGBITS        0000000000001020 001020 0001f0 10  AX  0   0 16
  [14] .plt.got          PROGBITS        0000000000001210 001210 000010 10  AX  0   0 16
  [15] .plt.sec          PROGBITS        0000000000001220 001220 0001e0 10  AX  0   0 16
  [16] .text             PROGBITS        0000000000001400 001400 018c54 00  AX  0   0 16
  [17] .fini             PROGBITS        000000000001a054 01a054 00000d 00  AX  0   0  4
  [18] .rodata           PROGBITS        000000000001b000 01b000 002ee8 00   A  0   0 16
  [19] .eh_frame_hdr     PROGBITS        000000000001dee8 01dee8 0005fc 00   A  0   0  4
  [20] .eh_frame         PROGBITS        000000000001e4e8 01e4e8 001914 00   A  0   0  8
  [21] .init_array       INIT_ARRAY      0000000000020cc0 020cc0 000008 08  WA  0   0  8
  [22] .fini_array       FINI_ARRAY      0000000000020cc8 020cc8 000008 08  WA  0   0  8
  [23] .dynamic          DYNAMIC         0000000000020cd0 020cd0 000200 10  WA  7   0  8
  [24] .got              PROGBITS        0000000000020ed0 020ed0 000130 08  WA  0   0  8
  [25] .data             PROGBITS        0000000000021000 021000 000010 00  WA  0   0  8
  [26] .bss              NOBITS          0000000000021020 021010 000010 00  WA  0   0 32
  [27] .comment          PROGBITS        0000000000000000 021010 00002b 01  MS  0   0  1
  [28] .shstrtab         STRTAB          0000000000000000 02103b 00010a 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  D (mbind), l (large), p (processor specific)

Sections

In previous chapter, you see that the ELF executable has a set of sections at which each section has a special meaning. For now, let me explain these:

.init and .fini: The .init section contains machine code that performs initialization before the main() function and .fini runs after it.
.text: This section is where the main code of the executable resides that we've wrote. It's the main concern for binary analysis or reverse engineering efforts.
.bss, .data, .rodata: There sections are where the program variables live. According to the declaration style, the variable goes into one of the three sections. For example, initialized global variables live in .data, uninitialized global variables live in .bss and constant variables live in .rodata. Don't forget that the local variables go in the stack, so .text, not into one of these sections.
.rel. and .rela.: These sections contain the information used by the linker for performing relocations.
.dynamic: It contains the "road map" for dynamic linker when loading and setting up the ELF executable.

As an example, you can inspect a specific section with this command:

$ objdump -j .text -d ./prog

./prog:     file format elf64-x86-64

Disassembly of section .text:

0000000000001400 <.text>:
    1400:       f3 0f 1e fa             endbr64
    1404:       31 ed                   xor    %ebp,%ebp
    1406:       49 89 d1                mov    %rdx,%r9
    1409:       5e                      pop    %rsi
    140a:       48 89 e2                mov    %rsp,%rdx
    140d:       48 83 e4 f0             and    $0xfffffffffffffff0,%rsp
    1411:       50                      push   %rax
    1412:       54                      push   %rsp
    1413:       45 31 c0                xor    %r8d,%r8d
    1416:       31 c9                   xor    %ecx,%ecx
    1418:       48 8d 3d 48 15 00 00    lea    0x1548(%rip),%rdi        # 2967 <rand@plt+0x1577>
    141f:       ff 15 b3 fb 01 00       call   *0x1fbb3(%rip)        # 20fd8 <rand@plt+0x1fbe8>
    1425:       f4                      hlt
    1426:       66 2e 0f 1f 84 00 00    cs nopw 0x0(%rax,%rax,1)
    142d:       00 00 00 
    1430:       48 8d 3d d9 fb 01 00    lea    0x1fbd9(%rip),%rdi        # 21010 <rand@plt+0x1fc20>
    1437:       48 8d 05 d2 fb 01 00    lea    0x1fbd2(%rip),%rax        # 21010 <rand@plt+0x1fc20>
    143e:       48 39 f8                cmp    %rdi,%rax
    1441:       74 15                   je     1458 <rand@plt+0x68>
    1443:       48 8b 05 96 fb 01 00    mov    0x1fb96(%rip),%rax        # 20fe0 <rand@plt+0x1fbf0>
    144a:       48 85 c0                test   %rax,%rax
    144d:       74 09                   je     1458 <rand@plt+0x68>
    144f:       ff e0                   jmp    *%rax
    1451:       0f 1f 80 00 00 00 00    nopl   0x0(%rax)

(...)

Program Headers

The program header table provides a segment view of the binary, as opposed to the section view provided by the section header table. It's defined as follow:

In here:

p_type: The type of segments. Common types: LOAD means the segment are intended to be loaded into memory, INTERP means the segment contains .interp section providing name of the interpreter that is to be used to load the executable, DYNAMIC means the segment contains the .dynamic section, which tells the interpreter how to parse and prepare the binary for execution, PHDR means the segment encompasses the program header table.
p_flags: The runtime access permissions for the segments. Common flags: X means executable, R means readable, W means writable or so on.
p_offset, p_vaddr, p_paddr, p_filesz, p_memsz: These equals to sh_offset, sh_addr, sh_size fields in the section headers.
p_align: It's equal to sh_addralign field.

You can see the program headers with this command:

$ readelf --segments --wide ./prog

Elf file type is DYN (Position-Independent Executable file)
Entry point 0x1400
There are 13 program headers, starting at offset 64

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  PHDR           0x000040 0x0000000000000040 0x0000000000000040 0x0002d8 0x0002d8 R   0x8
  INTERP         0x000318 0x0000000000000318 0x0000000000000318 0x00001c 0x00001c R   0x1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x000d30 0x000d30 R   0x1000
  LOAD           0x001000 0x0000000000001000 0x0000000000001000 0x019061 0x019061 R E 0x1000
  LOAD           0x01b000 0x000000000001b000 0x000000000001b000 0x004dfc 0x004dfc R   0x1000
  LOAD           0x020cc0 0x0000000000020cc0 0x0000000000020cc0 0x000350 0x000370 RW  0x1000
  DYNAMIC        0x020cd0 0x0000000000020cd0 0x0000000000020cd0 0x000200 0x000200 RW  0x8
  NOTE           0x000338 0x0000000000000338 0x0000000000000338 0x000030 0x000030 R   0x8
  NOTE           0x000368 0x0000000000000368 0x0000000000000368 0x000044 0x000044 R   0x4
  GNU_PROPERTY   0x000338 0x0000000000000338 0x0000000000000338 0x000030 0x000030 R   0x8
  GNU_EH_FRAME   0x01dee8 0x000000000001dee8 0x000000000001dee8 0x0005fc 0x0005fc R   0x4
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x10
  GNU_RELRO      0x020cc0 0x0000000000020cc0 0x0000000000020cc0 0x000340 0x000340 R   0x1

 Section to Segment mapping:
  Segment Sections...
   00     
   01     .interp 
   02     .interp .note.gnu.property .note.gnu.build-id .note.ABI-tag .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt 
   03     .init .plt .plt.got .plt.sec .text .fini 
   04     .rodata .eh_frame_hdr .eh_frame 
   05     .init_array .fini_array .dynamic .got .data .bss 
   06     .dynamic 
   07     .note.gnu.property 
   08     .note.gnu.build-id .note.ABI-tag 
   09     .note.gnu.property 
   10     .eh_frame_hdr 
   11     
   12     .init_array .fini_array .dynamic .got

Until here, I gave you the overall, a bit detailed, presentation about the ELF executable. For next articles, I will dive into the binary analysis techniques in deeply for Linux.

Resource:

Andriesse D., Practical Binary Analysis, no starch press, San Francisco.

I Pitched a Privacy-First Wearable AI at 4YFN as CTO — Here's What I Learned

Tue, 17 Mar 2026 12:33:06 +0000

First time presenting a startup at a major tech exhibition. 3-minute pitches, hundreds of conversations, and one question I heard 50+ times: "Wait, so it's NOT a camera?"

The Setup

One day I'm in my home office in Germany, debugging a React component. The next — I'm standing at a booth at 4YFN (4 Years From Now) during MWC 2026 in Barcelona, wearing a Scople prototype on my chest and explaining to VCs, developers, and curious attendees why our AI wearable doesn't store a single photo.

I'm Nazar, CTO at Scople — a startup building a wearable AI device that analyzes your life quality using computer vision. Think of it as a Fitbit, but instead of tracking steps, it tracks how much time you spend with family, whether you're eating healthy, if your partner is comfortable around you, or how engaged your audience is during a presentation.

The device gives you insights in real-time ("You've been sitting for 2 hours"), daily reports ("You spent 3 hours with family today"), weekly summaries ("You smiled 20% more this week"), or monthly analytics — depending on what you're tracking.

The catch? We don't record anything. We don't save photos. We don't use ChatGPT.

And that confused the hell out of people.

The First Pitch (and the Nerves)

I've done plenty of technical presentations — conference talks, team demos, client pitches. But standing at an exhibition booth with a wearable device on your chest, waiting for strangers to approach you? That's different.

The first visitor was a middle-aged man in a suit. He glanced at the Scople logo, looked at the device on my chest, and asked:

"Is that a body camera?"

I smiled. I'd practiced this.

"No, it's not a camera. Think of it like your own eye and brain. When you see something, you can't share the image itself — only the idea, the meaning. That's how Scople works. It captures the world around you, processes it using computer vision directly on the device, and sends you insights as push notifications. No recordings. No saved photos."

He frowned. "But... it has a lens, right?"

"Yes, it captures images — but only to analyze them. Like your brain processes what your eyes see, but doesn't 'save' every frame. Scople processes and instantly deletes the data."

He nodded slowly. "So you're saying I can't go back and watch a recording of my day?"

"Exactly. You can't. Because it doesn't exist. You get insights — like 'You spent 3 hours with your family today' or 'You smiled 20% more this week' — but the raw images are gone."

He paused. Then smiled. "That's... actually smart. Privacy-first, huh?"

That was the first of 50+ times I'd have that exact conversation.

The Privacy Question Everyone Asked

If I had to summarize the exhibition in one question, it would be:

"Wait, so it's NOT a camera?"

Followed immediately by:

"But how do you process images without storing them?"

And then:

"Where does the data go?"

Here's how I learned to answer it over the course of 3 days:

Version 1 (Too Technical)

"The device processes data with simple algorithms locally. For heavier tasks like face recognition or emotion analysis, it syncs with a portable dock station you carry in your pocket — slightly bigger than an AirPods case. The dock handles complex processing while you're on the go. Everything stays with you — device in your pocket, dock in your bag. No cloud. The data pipeline is: device captures → processes simple algorithms → syncs to dock → dock processes heavy algorithms → sends insights to your phone app."

Result: Blank stares. "So... it doesn't use the cloud?"

Version 2 (Too Vague)

"It's like your brain. You see things, you process them, but you don't 'record' every moment of your life. Scople does the same — it sees, analyzes, and forgets."

Result: "But my brain does remember things..."

Version 3 (The One That Worked)

"Think of a security camera vs. a motion detector. A security camera records everything and stores it. A motion detector only tells you 'someone walked by' — no video, no photos, just the insight. Scople is the motion detector, not the camera."

Result: "Oh! So it's like... privacy by design?"

Bingo.

Here's how I started visualizing it for people:

Aspect	Cloud AI (OpenAI)	Scople Edge AI
Privacy	Data to servers	Local only
Latency	200-500ms	<50ms
Battery	High drain	Optimized
Cost	\(\) at scale	One-time hardware
Control	Vendor lock-in	Full ownership
Updates	Automatic (risky)	User-controlled

The Questions I Didn't Expect

1. "Do you use ChatGPT?"

This came up a lot. Especially from tech people.

"No. We built our own proprietary AI. We don't use ChatGPT, Gemini, or any third-party models."

"Why not? Wouldn't that be easier?"

"Two reasons. First: security. If we used OpenAI's API, your data would go to their servers. Even if they promise privacy, we'd rather not take the risk. Second: optimization. Our device is small. GPT-4 is massive. We needed something lightweight, optimized specifically for Scople's hardware."

Some developers loved this answer. Others were skeptical.

One guy asked: "So you trained your own models from scratch?"

"For certain tasks, yes. For others, we fine-tuned smaller open-source models and optimized them for edge inference."

He nodded. "That's... actually impressive. Most startups just slap an OpenAI wrapper on something and call it AI."

That felt good.

For those curious — here's what the architecture actually looks like:

┌──────────────┐
│   DEVICE     │  Wearable on chest
│  (Eye)       │  • Simple CV models
│              │  • 2h battery
│  ARM M7      │  • Captures & processes
└──────┬───────┘
       │ Bluetooth sync
       ▼
┌──────────────┐
│ DOCK STATION │  Portable (pocket)
│  (Brain)     │  • Heavy inference
│              │  • Face recognition
│  ARM A + TPU │  • 8h total battery
└──────┬───────┘
       │ WiFi sync
       ▼
┌──────────────┐
│  PHONE APP   │  Insights only
│              │  • Real-time alerts
│ React Native │  • Daily/weekly reports
│              │  • No raw images
└──────────────┘

┌──────────────┐
│    CLOUD     │  Optional, metadata only
│  (Opt-in)    │  • User consent required
└──────────────┘

The key insight: raw images never leave the device-dock pair. The phone only receives processed insights. The cloud (if you opt in) only sees aggregated metadata.

2. "What if someone hacks it?"

A security researcher asked this. Legitimate concern.

"Great question. Here's the thing: even if someone breaks into the device, there's nothing to steal. We don't store images, videos, or raw data. The only thing they'd find is metadata — aggregated insights like 'user spent 3 hours in front of a screen today.'"

"But what about the processing pipeline? Could they intercept the data before it's deleted?"

"Theoretically, yes — if they have physical access to the device. But the data exists in volatile memory for milliseconds. By the time an attacker could extract it, it's already gone. And we're working on hardware-level encryption for the processing pipeline."

He smiled. "Good answer. Most founders don't think that far ahead."

Another win.

3. "Who would actually use this?"

This one stung a bit. A VC asked it.

"You're asking people to wear a camera-like device on their chest all day, and you're saying it's for... tracking family time? Who's the target market?"

I took a breath.

"Four main groups. First: parents. 70% of relationships fail due to conflict. Scople can detect early signs of stress, emotional distance, or even domestic violence — before it becomes critical. Second: wellness enthusiasts. People who track their steps, sleep, calories — but no one tracks quality of life. Third: professionals. Developers who sit 9 hours a day and don't realize it. Managers who want to know if their team is burning out. And fourth: businesses. Retail stores want to know what customers actually look at, not just what they buy."

He leaned back. "Okay. That's a broader market than I thought."

Not a deal, but not a rejection either.

4. "This feels dystopian."

A younger developer said this. I respected the honesty.

"I get it. A wearable device with a camera lens sounds like Black Mirror. But here's the difference: you control it. You decide when to wear it, what to track, what insights to receive. And most importantly — no one else has access to your data. Not us, not the government, not advertisers. It's your device, your data, your insights."

"But what if the company gets acquired? Or changes its privacy policy?"

"We're designing the architecture so that even we can't access your data. All processing happens on the device or in the portable dock station you carry with you — no central database to hack, no cloud storage to subpoena. Your data stays in your pocket, literally. If we wanted to betray users, we'd have to redesign the entire system."

He paused. "Fair. I'd want to see the code, though."

"We're planning to open-source parts of the processing pipeline once we're out of stealth."

He nodded. "Okay. I'll keep an eye on you."

That felt like a win, too.

The "Wait, That's Brilliant" Moments

Not all conversations were defensive. Some people got it immediately.

A wellness coach:

"Oh my God, this is what I've been trying to explain to clients for years. You can't improve what you don't measure. But no one measures quality time or emotional health. This could change everything."

A developer:

"I've been trying to cut down on screen time, but I have no idea how much I actually sit in front of the computer. My smartwatch says I'm 'active' because I type a lot. This would tell me the truth."

A retail manager:

"We spend thousands on A/B testing product placement, but we're just guessing. If we could see what customers actually look at before they buy... that's gold."

These conversations reminded me why we're building this.

What I Learned About Pitching

1. Start with the metaphor, not the tech stack

Early on, I tried leading with "edge computing" and "computer vision pipeline." People tuned out.

When I started with "Think of your eye and brain — you see, you process, but you don't record," people leaned in.

Lesson: Give people a mental model first. Then explain the details.

2. Address privacy immediately

I learned to bring up privacy before they asked.

Instead of:

"Scople is a wearable AI device that captures the world around you..."

I started saying:

"Scople is a wearable AI device — but it's not a camera. No recordings, no saved photos. It processes data on-device and deletes it instantly."

Lesson: If you know the objection is coming, handle it upfront.

3. Have a one-sentence answer for everything

People don't want a dissertation. They want clarity.

"What is it?" → "A wearable AI that tracks quality of life, not just physical health."
"Is it a camera?" → "No. It's like a motion detector — it gives you insights, not recordings."
"Do you use ChatGPT?" → "No. We built our own proprietary AI for privacy and optimization."
"Who's it for?" → "Parents, wellness enthusiasts, professionals, and businesses."

Lesson: If you can't explain it in one sentence, you don't understand it well enough.

4. People remember stories, not specs

No one remembered that we use "edge computing with a dock station for heavy inference."

But they did remember:

"The guy who said his device can tell if your partner is comfortable around you."

"The startup that doesn't use ChatGPT because they care about privacy."

"The wearable that's NOT a camera."

Lesson: Be memorable. Specs are forgettable.

The Conversations That Changed My Perspective

A privacy advocate told me:

"You're building something powerful. But power can be misused. What happens when someone uses Scople to spy on others? Or when a company forces employees to wear it?"

I didn't have a great answer for that. We've been focused on technical privacy (edge computing, no cloud storage), but not social privacy (misuse cases).

That's something we need to think about.

An investor told me:

"Privacy-first is great for early adopters. But most people don't care. They use Facebook, TikTok, Alexa. How do you convince them to care about privacy?"

My answer:

"We're not competing with Facebook. We're competing with Fitbit. And people do care about privacy when it comes to their body, their home, their family. They don't want Amazon recording their bedroom. They don't want a startup storing videos of their kids."

He smiled. "Good answer. But you'll still need to prove it."

Fair point.

A developer asked:

"Why not just make it open-source from day one? If you're serious about privacy, let the community verify it."

I hesitated.

"We want to. But we're also trying to build a business. If we open-source everything now, we lose our competitive edge."

He shrugged. "Then you're not really privacy-first. You're privacy-first with caveats."

Ouch. But he's right.

We're planning to open-source the processing pipeline eventually. But he made me realize we need to do it sooner, not "when we're ready."

The Stats

After 3 days at 4YFN, here's what we got:

~200 conversations (ranging from 2 minutes to 20 minutes)
~50 "Wait, it's NOT a camera?" questions
~30 business cards exchanged
12 serious investor/partner follow-ups
6 demo requests (people wanted to see the live dashboard)
3 offers to pilot with retail/corporate wellness programs

And one guy who asked if we could make a version for his dog.

(We politely declined.)

What's Next

We're taking all the feedback and refining the product. The big questions we're tackling:

How do we communicate privacy better? (It's our biggest strength, but also the hardest to explain.)
How do we prevent misuse? (What happens if someone uses Scople to surveil others?)
How do we balance open-source with business goals? (We want transparency, but we also need to protect our IP.)

And we're working on the next prototype — smaller form factor (the device currently runs ~2 hours on complex algorithms, ~8 hours total with the portable dock), better battery optimization, and a cleaner UI for the phone app that syncs with the dock.

Update: Since 4YFN, The Gadgeteer published a piece calling Scople "a tiny wearable that reads the room and forgets it." Their take: "Moxiebyte built its entire pitch around the idea that the device sees everything but keeps nothing." — which is exactly the message we were going for.

We're launching on Kickstarter in mid-April 2026. If you want to be among the first to get Scople, follow us at scople.ai for launch updates.

Final Thoughts

If you'd told me a year ago that I'd be standing at a tech exhibition, wearing an AI device on my chest, and explaining to VCs why we don't use ChatGPT — I'd have laughed.

But here we are.

Building Scople has been one of the hardest, most rewarding things I've done. And presenting it at 4YFN forced me to get better at explaining why it matters.

Because here's the thing: we're not building a camera. We're not building a surveillance tool.

We're building a way for people to understand their own lives — their time, their emotions, their relationships, their habits — without sacrificing their privacy.

And if that sounds impossible, well... that's why we're building it.

TL;DR

I pitched Scople (a privacy-first wearable AI) at 4YFN as CTO
The #1 question: "Wait, it's NOT a camera?"
The #1 learning: Start with metaphors, not tech specs
The #1 challenge: Explaining edge computing to non-technical people
The #1 surprise: How many people actually care about privacy

If you're building something in the AI/wearables/privacy space, feel free to reach out. I'm happy to share more behind-the-scenes learnings.

And if you think Scople sounds interesting — we're launching on Kickstarter in mid-April. Check out scople.ai or drop a comment below.

What would you ask if you saw Scople at an exhibition? Drop your questions in the comments — I'll answer them all.

Line by Line, HOW do I query my BSP?

Tue, 11 Nov 2025 01:57:28 +0000

Now, if you read my last post (sorry about the length...), you will remember we constructed a BSP tree. The BSP tree we created could hold these entities, but we never actually used this feature. Well, I was sitting and thinking about what someone might want to do with a BSP tree, and then it hit me, read from it! So, that's exactly what we're going to do, except, we're going to do it for a specific use case.

The View Frustum

Imagine you're playing a 3D game, where the walls are governed by a BSP tree. Now, looking from the top down, what would the player's view look like? A triangle! This is called the view frustum. What we're going to do, is apply the view frustum on the BSP tree, and in return we should get all entities that a hypothetical player could see. Our current function simply takes a point, and gets all entities in the node at that point, but that's practically useless. So now after all this, we should end up with some meaningful functionality.

The Camera

To start our programming, we want a camera object that we can move around the world. This way, we could easily move it around to get different results.

type Camera struct {
pos     Pos
angle   float64
viewDis float64
fov     float64
}

func (camera *Camera) createViewFrustum() int {
// Generates a bounding triangle that
// should encapsulate everything that
// the camera can see
// TODO: Return a triangle
return 0
}

func (camera *Camera) getEntitiesInView(world *BSPTree) []*Entity {
// Queries the BSP tree using the
// view frustum for all viewable entities
return nil
}

A position, an angle, the view distance, and the field of view, pretty simple. We also need to be able to create the view frustum based off of the camera, so we've got a method for that. We also need that method to get all the entities the camera can view. We're missing something, we need to define what a triangle is, otherwise we can't make that view frustum.

type Triangle struct {
p1, p2, p3 Pos
}

Very simple, pretty much exactly how you would expect. Remember, lines have a front and a back side, so the order of p1, p2, and p3 will be important later.

Creating the View Frustum

Let's implement generating the view frustum. All we need is to create a triangle, and for that, we only need 3 points. The first point is obvious, the position of the camera, but the other two will require some trigonometry to figure out.

return Triangle{
p1: camera.pos,
p2: Pos{},
p3: Pos{},
}

Well, it should be pretty easy to generate a point in the direction the player is facing. We would simply use sine and cosine to get the x and y coordinates of this point using the camera's angle as input. Then, we would scale by view distance. Well, we can do the exact same thing for the edges of our view. All we have to do is add or subtract half of the field of view before our calculations!

return Triangle{
p1: camera.pos,
p2: Pos{
camera.pos.x + math.Cos(camera.angle-camera.fov/2)*camera.viewDis,
camera.pos.y + math.Sin(camera.angle-camera.fov/2)*camera.viewDis,
},
p3: Pos{
camera.pos.x + math.Cos(camera.angle+camera.fov/2)*camera.viewDis,
camera.pos.y + math.Sin(camera.angle+camera.fov/2)*camera.viewDis,
},
}

Looks like we've started to do some addition of positions and multiplication of magnitudes, so let's move those to their own functions.

func (pos Pos) add(other Pos) Pos {
return Pos{
pos.x + other.x,
pos.y + other.y,
}
}

func (pos Pos) scale(scale float64) Pos {
return Pos{
pos.x * scale,
pos.y * scale,
}
}

func (camera *Camera) createViewFrustum() Triangle {
return Triangle{
p1: camera.pos,
p2: camera.pos.add(Pos{
math.Cos(camera.angle-camera.fov/2),
math.Sin(camera.angle-camera.fov/2),
}.scale(camera.viewDis)),
p3: camera.pos.add(Pos{
math.Cos(camera.angle+camera.fov/2),
math.Sin(camera.angle+camera.fov/2),
}.scale(camera.viewDis)),
}
}

That's a lot better, and will probably help in future, but with that, we have completed our view frustum.

Finishing the Camera

Before we can finish the camera, let's define our method on the BSP tree to run this code.

func (tree *BSPTree) queryEntitiesByTriangle(triangle Triangle) []*Entity {
// Will find all entities within this triangle
return nil
}

Nice, now we can call this in our camera code.

func (camera *Camera) getEntitiesInView(world *BSPTree) []*Entity {
return world.queryEntitiesByTriangle(camera.createViewFrustum())
}

We just take that view frustum we made, and chuck it into the query logic. However, how do we know if an entity is within a triangle? Let's create a function for that, that decides whether a point is within. Luckily, the way we've defined everything makes this very simple.

Remember, lines have a front and a back, and they also have a method for determining whether a point is in front of the line or not. In the way we've defined our triangle, we are able to deduce that the point is within it if the point is in front of all the lines that make up the triangle. Make sense? Let's write the code, that might help.

func (triangle *Triangle) pointWithin(pos Pos) bool {
return (
(&Segment{triangle.p1, triangle.p2}).pointInFront(pos) &&
(&Segment{triangle.p2, triangle.p3}).pointInFront(pos) &&
(&Segment{triangle.p3, triangle.p1}).pointInFront(pos))
}

Bam, so now we can easily check if an entity is within the view frustum, since the view frustum is a triangle, and an entity is a point.

I think we're ready to get into the real code.

Querying the Node

As per usual, we have 2 cases, those being a leaf node, and a branch node. Let's start with the leaf node.

if node.isLeaf() {
// Create the list of entities to
// give back to query
chosen := []*Entity{}

// Find all entities within
for i := range len(node.entities) {
e := node.entities[i]
if triangle.pointWithin(e.pos) {
chosen = append(chosen, e)
}
}

return chosen
}

This should make sense, just finding the entities that are within the triangle. However, we will now get to the more complicated case, branches. What we need to figure out is whether the triangle is entirely on one side of the splitter, or crosses it. If it is entirely on one side, then we only need to query one child, which is the efficient case we'd like. However, if the triangle lies over the splitter, then we need to query both children. From this, we want a method we can use to decide whether a triangle is in front, behind, or on top of a line.

// Positive if in front, negative if behind, 0 is on top
func (segment *Segment) triangleRelation(triangle Triangle) int {
b1 := segment.pointInFront(triangle.p1)
b2 := segment.pointInFront(triangle.p2)
b3 := segment.pointInFront(triangle.p3)

if b1 && b2 && b3 {
// Fully in front
return 1
} else if !b1 && !b2 && !b3 {
// Fully behind
return -1
} else {
// Both
return 0
}
}

Having three cases does make this annoying, but hopefully this makes sense. From this, we can complete the branch case.

relation := node.splitter.triangleRelation(triangle)

switch relation {
case 1:
return node.front.queryEntitiesByTriangle(triangle)
case -1:
return node.back.queryEntitiesByTriangle(triangle)
default:
return append(
node.front.queryEntitiesByTriangle(triangle),
node.back.queryEntitiesByTriangle(triangle)...,
)
}

This should make the efficiency of the first two cases obvious, as we only have to do half the work.

Testing

// Get some entities?
camera := Camera{
pos:     Pos{0, 0},
angle:   0,
viewDis: 200,
fov:     math.Pi/2, // 90deg
}

fmt.Println(camera.getEntitiesInView(bsp))

Now obviously, we have no entities in the BSP, so this returns an empty list. So now we know it doesn't hallucinate! But let's test a real case, let's add some entities.

bsp.addEntity(&Entity{
name: "John",
pos:  Pos{50, 0},
})

bsp.addEntity(&Entity{
name: "Mark",
pos:  Pos{0, 50},
})

bsp.addEntity(&Entity{
name: "Luke",
pos:  Pos{-50, 0},
})

bsp.addEntity(&Entity{
name: "Matthew",
pos:  Pos{0, -50},
})

entities := camera.getEntitiesInView(bsp)
fmt.Println("Found these entities")
for i := range len(entities) {
fmt.Println(entities[i].name)
}

Now, given the camera is looking towards the positive x-axis from origin, we should expect the entity with a positive x position to be shown, and this is exactly what I get, John. So with that, we've completed our work!

Challenge

Now we're able to imagine what entities might be shown if we were to view this from a first-person perspective, but what about some other useful queries? I already put rectangle and circle collision in the last post's challenges, so let's do something different.

Similar to this queryEntitiesByTriangle, can you write querySegmentsByTriangle.
Moving and turning the camera.
Having moving entities.
Could you disregard entities that are entirely obscured by a wall?
Visualize the view frustum and visible entities.

Note, for a little help, I've written lines to an external file, and the BSP tree is also written to a file. This way, you can easily modify the walls of the world, and see what BSP tree results.

Line by Line, But HOW Do I Construct A BSP Tree?

Mon, 10 Nov 2025 01:19:48 +0000

A classic fundamental data structure is the binary tree, which allows us to half a given search space on each search iteration. Usually, this is used on a sorted array, so why not 2D space? Enter, the BSP tree.

What is BSP?

Binary Space Partitioning take 2D space and splits it into 2 parts recursively. In an infinite 2D world, we could use all the walls, split the plane with each of them, and placing each other line in either the left or right children of the tree. We do this recursively until we have each branch as a wall, and each leaf as a pocket of space. Then, if we wanted to find an entity within space, we could reject half of the search space with each iteration!

Visually Explained

That was a bit wordy, so it'll probably be better to go through with a visual example.

We start off with our basic walls as we talked about before.

Here we have chosen a line to split on, and we extend that line infinitely.

Now, everything to one side is going to be the left child of this binary tree, while the other side will be the right child. This is color coded in the image above.

Here, we chose the yellow line to perform our second split.

Now that image is after the final two splits.
Looking at this, we have all these little pockets of space that can be queried by walking down the tree.
Perfect, now we should start defining our structures.

Defining our Structures

Let's start with our basic data types.

type Pos struct {
x, y float64
}

type Entity struct {
name string
pos  Pos
}

type Segment struct {
start, end Pos
}

It is worth mentioning that when using a segment for splitting the plane, we will extend it infinitely in both directions. We will be coming back to these structures later when we need to write methods for them, but for now, they are finished.

The BSP Node

This will be the main complicated data structure, the node for the BSP tree.

type BSPNode struct {
// Children
front, back *BSPNode

// If a branch node
splitter *Segment

// If a leaf node
entities []*Entity
}

And to wrap it, a BSP Tree struct.

type BSPTree struct {
root *BSPNode
}

What Methods?

Let's try to figure out as many methods as we can before we start coding.

func (segment *Segment) intersect(other Segment) (Pos, bool) {
return Pos{}, false
}

func (segment *Segment) intersectAsInfinite(other Segment) (Pos, bool) {
return Pos{}, false
}

func (segment *Segment) pointInFront(pos Pos) bool {
return false
}

These two will be useful, as we're going to need to decide whether a line intersects another in almost every step of the BSP tree creation. Then, we will also need to figure out whether a line should go to the front or back of a node, so we have made the pointInFront method specifically for this purpose.

Then we have the methods given for the BSP node.

func (node *BSPNode) addLine(line *Segment) bool {
return false;
}

func (node *BSPNode) nodeAtPos(pos Pos) *BSPNode {
return nil
}

First one is used when constructing the tree, it will either push the line to the left, right, or even split the line in half and push it to both. We also want to know if an error occurred, so it will return true if it was able to find a space for the line. Then, we want to be able to grab the node that will encompass a given position. From this, we will be able to grab nearby entities.

Then, we will provide wrapper functions on the BSP tree.

func (tree *BSPTree) addLine(line *Segment) bool {
return false;
}

func (tree *BSPTree) entitiesNearby(pos Pos) []*Entity {
return nil
}

All we've done differently here is return a list of entities rather than just the whole BSP node.

Wrapper Implementation

The easiest thing to implement to start off will be the wrapper. We're going to start with a constructor for this structure.

func (tree *BSPTree) init() {
tree.root = &BSPNode{
front: nil,
back: nil,
splitter: nil,
entities: nil,
}
}

The reason we do this is because there should always be at least the root node. If there are no lines, this root node simply encompasses everything, and is an infinite plane with no bounds. Currently, however, this node has no front, back, splitter, or entities.

Now we have that figured out, let's do the entitiesNearby method.

func (tree *BSPTree) entitiesNearby(pos Pos) []*Entity {
// Find the node that encompasses this area
node := tree.root.nodeAtPos(pos)

// No node found (should practically never happen),
// simply give back no entities
if node == nil {
return nil
}

return node.entities
}

Looks good, just calls the node's version of this method, with a little guard in case something goes wrong.

Now for the really short function of addLine.

func (tree *BSPTree) addLine(line *Segment) bool {
return tree.root.addLine(line)
}

Line Intersections

Let's start with our finite intersection, then we will very easily modify this for the infinite version. From Wikipedia, we are given a great formula to find out whether two line segments have intersected.

Looks like a lot of random letters everywhere, but we're going to go piece by piece to convert this into code.

Firstly, t and u appear to be floating point variables. Then, the x and y's are coordinates. Subscript 1 denotes the first line's start position, all the way to 4 being the other line's end position. With this in mind, we should be able to perform the code translation.

t := (
(
(segment.start.x-other.start.x) * (other.start.y-other.end.y) -
(segment.start.y-other.start.y) * (other.start.x-other.end.x)) /
(
(segment.start.x-segment.end.x) * (other.start.y-other.end.y) -
(segment.start.y-segment.end.y) * (other.start.x-other.end.y)))

Awful, let's take out the denominator, since it will be used for both u and t.

d := (
(segment.start.x - segment.end.x) *
(other.start.y - other.end.y) -
(segment.start.y - segment.end.y) *
(other.start.x - other.end.y))

t := (
(segment.start.x - other.start.x) *
(other.start.y - other.end.y) -
(segment.start.y - other.start.y) *
(other.start.x - other.end.x)) / d

u := -(
(segment.start.x - segment.end.x) *
(segment.start.y - other.start.y) -
(segment.start.y - segment.end.y) *
(segment.start.x - other.start.x)) / d

So easy! Except, we have one thing we missed, and that's the case where d is 0! If this is the case, two things are true, either that the lines are parallel, or perfectly laid on top of one another (coincident). We're going to ignore coincident cases right now. So let's add a guard to avoid the division by 0 error.

// Parallel
if d == 0 {
// FIX: Deal with coincident case
return Pos{}, false
}

Right, now everything is valid, we can decide whether the lines intersected. From the Wikipedia, we know the lines have intersected if 0 <= t <= 1 and 0 <= u <= 1. So let's simply calculate this.

hasIntersected := 0 <= t && t <= 1 && 0 <= u && u <= 1
if !hasIntersected {
return Pos{}, false
}

We're so close now! We just need to find the point of intersection. Even more fortunately, the Wikipedia blesses us again with a line just before the last paragraph. This line defines Px and Py. These are the coordinates of the intersection. Let's calculate these values as described.

intersection := Pos{
segment.start.x + t * (segment.end.x - segment.start.x),
segment.start.y + t * (segment.end.y - segment.start.y),
}

return intersection, true

And there it is! We've found the intersection between two finite lines, but what about an infinite line and a finite line? Well, the Wikipedia gives us the knowledge that if t is in the range we checked, then the intersection point is within the first line segment's range, while u says the same for the second line segment. Therefore, if u is true, it doesn't matter if t is true. This is because we don't need an intersection within the first line's range, since we're extending it towards infinity. As long as there is an intersection on the second line, we're good.

func (segment *Segment) intersectAsInfinite(other Segment) (Pos, bool) {
d := (
(segment.start.x - segment.end.x) *
(other.start.y - other.end.y) -
(segment.start.y - segment.end.y) *
(other.start.x - other.end.y))

// Parallel
if d == 0 {
// FIX: Deal with coincident case
return Pos{}, false
}

u := -(
(segment.start.x - segment.end.x) *
(segment.start.y - other.start.y) -
(segment.start.y - segment.end.y) *
(segment.start.x - other.start.x)) / d

hasIntersected := 0 <= u && u <= 1
if !hasIntersected {
return Pos{}, false
}

intersection := Pos{
other.start.x + u * (other.end.x - other.start.x),
other.start.y + u * (other.end.y - other.start.y),
}

return intersection, true
}

Looks pretty similar, but now we don't even need to calculate t.

Now for the last segment method, is a point in front of this segment? Well, interestingly, we first have to define what "in front" even means. We're going to define this as the face that points in a counter-clockwise direction, if we were to define the start as the center of a circle, and end a point on the circumference.

Very good, so now it should be relatively easy to calculate this. We can calculate whether a point is in front of a segment by first getting the angle from the segment's start to the segment's end. Then, we do the same for the segment's start to the query point. If the second angle is greater than the first, then it is in front. So let's start by getting those two angles.

dx := segment.end.x - segment.start.x
dy := segment.end.y - segment.start.y
dis := math.Sqrt(dx*dx + dy*dy)
a1 := math.Acos(dx/dis)
if dy < 0 {
a1 = -a1
}

dx = pos.x - segment.start.x
dy = pos.y - segment.end.y
dis = math.Sqrt(dx*dx + dy*dy)
a2 := math.Acos(dx/dis)
if dy < 0 {
a2 = -a2
}

Since this is a very simple duplication of logic, why don't we move this to its own method?

func (pos *Pos) angleTo(other Pos) float64 {
dx := other.x - pos.x
dy := other.y - pos.y
dis := math.Sqrt(dx*dx + dy*dy)

// Avoid division by 0
if dis == 0 {
return 0
}

a := math.Acos(dx/dis)
if dy < 0 {
a = -a
}
return a
}

Much easier. Now, since we're comparing angles, it's always much easier to simply subtract them, then compare with 0. This way, a positive angle is a front face, and a negative angle is a back face. No angle means it fits perfectly on the line (which is annoying). To make this a much simpler task, rather than fiddling with whether the value is over 360, we're just going to consider the sine of the angle for our calculation.

func (segment *Segment) pointInFront(pos Pos) bool {
a1 := segment.start.angleTo(segment.end)
a2 := segment.start.angleTo(pos)
s := math.Sin(a2-a1)
return s >= 0
}

I mean, you couldn't ask for nicer looking code.
And that's all for the logic of lines, for now.

At this point, we can start working on the BSP node!

Query?

Because we never like doing things in the correct order, let's do the nodeAtPos method first. Our first case is that if we're a leaf node, we return the current node. If it's not, we find which side this point belongs on, then recurse into the correct child node.

func (node *BSPNode) isLeaf() bool {
return node.front == nil && node.back == nil
}

func (node *BSPNode) nodeAtPos(pos Pos) *BSPNode {
// Leaf case
if node.isLeaf() {
return node
}

// Branch case
return nil
}

Now we can use the pointInFront method to decide which child to chose in the branch case.

func (node *BSPNode) nodeAtPos(pos Pos) *BSPNode {
// Leaf case
if node.isLeaf() {
return node
}

// Branch case
if node.splitter.pointInFront(pos) {
return node.front.nodeAtPos(pos)
} else {
return node.back.nodeAtPos(pos)
}
}

And that's literally it! So simple! Now you can probably imagine just how efficient this data structure really is.

Building the BSP

Now to building the BSP tree. A BSP node is given a line, and what that node does with the line depends on many things, the first being whether it is a leaf node. Let's start with the leaf node case.

func (node *BSPNode) propogateChildren() {
}

func (node *BSPNode) addLine(line *Segment) bool {
if node.isLeaf() {
node.splitter = line
node.front = &BSPNode{}
node.back = &BSPNode{}
node.propogateChildren()
return true
}

return false
}

Note that we have to go through all the entities in this node, and move them to either the front or back child. Let's write that function now.

func (node *BSPNode) addEntity(e *Entity) {
// Leaf case
if node.isLeaf() {
node.entities = append(node.entities, e)
return
}

// Branch case
if node.splitter.pointInFront(e.pos) {
node.front.addEntity(e)
} else {
node.back.addEntity(e)
}
}

func (node *BSPNode) propogateChildren() {
// Go through each entity, attempting
// to pass it on to a child
for i := range len(node.entities) {
e := node.entities[i]

if node.splitter.pointInFront(e.pos) {
node.front.addEntity(e)
} else {
node.back.addEntity(e)
}
}
}

Perfect, now let's get back to what we were doing, inserting lines. There are three cases that we have to be weary about at this point. We're trying to decide whether a line should be pushed to the back or front child.

The line is entirely in front of the splitter, so we move it to the front child
The line is entirely behind the splitter, so we move it to the back child
The line crosses the splitter, so we much split the line in two, and push both to each child.

First, let's check if the lines intersect, and if they don't, we can do the first two cases.

// Point of intesection
poi, ok := node.splitter.intersectAsInfinite(*line)
if ok {
// Intersection case
_ = poi
return false
}

// Entirely on one side case
if node.splitter.pointInFront(line.start) {
return node.front.addLine(line)
} else {
return node.back.addLine(line)
}

So all we have to do now is create the two new lines, and give them to the front and back children.

l1 := &Segment{
line.start,
poi,
}

l2 := &Segment{
poi,
line.end,
}

This creates our two lines.

var frontLine, backLine *Segment
if node.splitter.pointInFront(line.start) {
frontLine = l1
backLine = l2
} else {
backLine = l2
frontLine = l1
}

This chooses which line will be used for which child.

added := true
added = added && node.front.addLine(frontLine)
added = added && node.back.addLine(backLine)
return added

And there we go, we've now completed the insertion of a line into the BSP tree.

Coincident

Lastly, we have the coincident case. First, it would be helpful to know if a point lays exactly on top of another line, and is therefore not in front or behind.

func (segment *Segment) pointOnLine(pos Pos) bool {
a1 := segment.start.angleTo(segment.end)
a2 := segment.start.angleTo(pos)
s := math.Sin(a2-a1)
return s == 0
}

Then, during intersection checks, if we find parallel lines, and one of the points on the second line lies on the first line, we have coincident lines. We must also make the intersection's return more robust.

type LineIntersection byte

const (
LI_NONE LineIntersection = iota
LI_INTERSECT
LI_COINCIDENT
)

This is just an enum to tell us what type of intersection occurred.

// Parallel
if d == 0 {
if segment.pointOnLine(other.start) {
return Pos{}, LI_COINCIDENT
}
return Pos{}, LI_NONE
}

Nice, now we can use this value meaningfully in the rest of our code.

case LI_COINCIDENT:
// Keep a reference, but don't use
// as a splitter
node.lines = append(node.lines, line)
return true

Here we've added a property to the BSP node that is just a list of lines. This way, any coincident lines can be kept in this list. These lines won't get in the way of any insertion or query logic, but the reference must remain as it is important to level structure.

Testing

Now the scary bit, is our code correct? Really, we should be proud at this moment. We've written a lot of code, with a lot of it being complicated and dealing with trigonometry. All the more reason to ensure its legitimacy with some testing!

func main() {
// Create a new BSP tree
bsp := &BSPTree{}
bsp.init()

fmt.Println("Attempting to add first line")
fmt.Println(bsp.addLine(&Segment{
Pos{0, -100},
Pos{0, 100},
}))

fmt.Println("Testing the 'line in front' case")
fmt.Println(bsp.addLine(&Segment{
Pos{10, -100},
Pos{20, 100},
}))

fmt.Println("Testing the 'line behind' case")
fmt.Println(bsp.addLine(&Segment{
Pos{-10, -100},
Pos{-20, 100},
}))

fmt.Println("Testing the 'line split' case")
fmt.Println(bsp.addLine(&Segment{
Pos{10, 0},
Pos{100, 0},
}))

fmt.Println("Testing the 'line coincident' case")
fmt.Println(bsp.addLine(&Segment{
Pos{0, 200},
Pos{0, 300},
}))
}

Sure, it's not the most exhaustive testing, but that shall do for now. For your testing, maybe add a method to add entities, then test whether you can retrieve those entities back.

Challenge

That was a lot of work, but now we have a fully operational BSP tree that can be used in many applications. As per usual, we won't end at this post, here are your challenges for using this BSP tree.

Visualize the BSP tree, by showing each line that is in it. Furthermore, it would be nice to be able to see which side of a line is the front, and coloring of the empty space (as in my example images).
Utilize this structure in one of your pre-existing games.
Create a method to query the BSP tree for entities where the query parameter is a circle, and it will return every entity within that circle.
Create another query method but with a rectangle.
Make a program that takes in a list of lines, and will attempt to construct the most balanced BSP tree.
Maybe attempt to do some AVL tree style optimizations but for the BSP tree.
Write the tree to a file, and read it back.

The code for this implementation is available on GitHub.

Cuckoo Hashing, a powerful hashing technique that takes its inspiration straight from nature.

Wed, 27 Aug 2025 18:05:50 +0000

Ever heard of a bird inspiring a computer science algorithm? Yep, you read that right. Today we’re diving into Cuckoo Hashing, a powerful hashing technique that takes its inspiration straight from nature.

???? A Quick Story About Cuckoo Birds

Cuckoo birds are… jerks. Instead of building their own nests, they sneak their eggs into other birds’ nests. When the chick hatches, it kicks the others out and claims the nest all to itself. Bold move, right?

That same “move in and push the other out” trick is exactly how cuckoo hashing handles collisions in hash tables. It’s nature + computer science = genius.

???? First, What’s a Hash Table Again?

A hash table is like a super-fast digital filing cabinet where you drop data in and retrieve it in almost constant time. If you’re new to hash tables, check out my earlier breakdown ???? What is a Hash Table?

Hash tables are amazing, but they have one problem: collisions. That’s when two keys end up mapped to the same slot. Normally, we fix this with chaining or linear probing… but those methods can get messy.

Enter cuckoo hashing. ????✨

???????? What Makes Cuckoo Hashing So Special?

Instead of giving each key just one slot, cuckoo hashing uses two different hash functions. That means each key has two possible homes.

Here’s the magic:

If one spot is full, the new key boots out the old resident (just like a cuckoo chick).
The displaced key then moves to its other possible home.
If that’s also full, the cycle repeats until everything finds a nest.

???? Want to see cuckoo hashing in action? Play around with this awesome app, I made using AI Cuckoo Hashing Visualizer.

???????? Pseudo Code: Cuckoo Hashing in Action

Here’s a simple version of the insert logic, written in easy-to-read pseudo code:

// Insert a key into the cuckoo hash table
function insert(key):
    for i = 1 to MaxAttempts:
        // Try first home
        if table1[h1(key)] is empty:
            place key in table1[h1(key)]
            return success

        // If not empty, evict the old resident
        swap key with table1[h1(key)]

        // Try second home
        if table2[h2(key)] is empty:
            place key in table2[h2(key)]
            return success

        // If not empty, evict the old resident again
        swap key with table2[h2(key)]
        // and repeat the loop with the evicted key

    // If we’ve tried too many times, the table is probably too full
    resize_and_rehash()

???? Key things to notice:

Each key has two homes.
If both are busy, one of the current residents gets kicked out.
After too many kicks, the table needs to resize and rehashed.

This simple loop is the heart of cuckoo hashing.

⏱️ Time Complexity: How Fast Is It Really?

Lookup → O(1). You only check up to 2 spots.
Insert → O(1) on average, though sometimes you shuffle a few items.
Delete → O(1). Just clear the spot.

Worst case? A cycle forms (items keep kicking each other around endlessly). That’s when you resize and rehash the whole table.

???? A Little History: The Creators of Cuckoo Hashing

Cuckoo hashing was introduced in 2001 by Rasmus Pagh and Flemming Friche Rodler. Their goal? A hash table with constant-time lookups and clean structure — no messy chains or long probing sequences.

Whenever you need predictable O(1) lookups and can afford a little shuffle during insertions, cuckoo hashing is your friend.

Informatics in Modern Biology: A New Era of Digital Life

Tue, 22 Apr 2025 20:58:52 +0000

Informatics in Modern Biology: A New Era of Digital Life

The way we study life has fundamentally changed.

For centuries, biology was a hands-on science: Petri dishes, microscopes, field notebooks. But the 21st century brought a deluge of data—genomic sequences, protein structures, metabolic pathways, epidemiological records—that demanded a new toolkit. Enter bioinformatics and computational biology, where code becomes as vital as the microscope.

Among programming languages, Python has emerged as a dominant force. It combines readability with powerful libraries for numerical computing, data analysis, and scientific visualization. In biology, Python isn’t just a convenience—it’s become an enabler of discovery.

The Role of Informatics in Biology

Modern biology is computational by design. Informatics powers both everyday lab work and groundbreaking research. Let’s look at just how deep the rabbit hole goes.

1. Sequence Analysis

The Human Genome Project generated over 3 billion base pairs of data—once considered unfathomable. Today, sequencing entire genomes is routine, and libraries like Biopython and scikit-bio make processing them intuitive.

Tasks like sequence alignment, motif finding, translation between DNA and protein, and working with formats like FASTA, GenBank, or SAM are streamlined by these tools.

2. Multi-Scale Simulations

From simulating protein folding (PyRosetta) to modeling entire biological pathways (Tellurium, PySCeS), simulation libraries help test hypotheses without touching a pipette.

This is crucial in fields like:

Synthetic biology (e.g., designing new metabolic networks)
Pharmacodynamics (predicting how drugs affect systems)
Epidemiology (simulating disease spread and mutation)

3. Machine Learning Meets Biology

Libraries like scikit-learn, TensorFlow, and PyTorch are being used to:

Predict protein structures from sequences (e.g., AlphaFold-inspired models)
Detect gene-disease associations from large datasets
Classify cell types from microscopy images using CNNs
Suggest CRISPR targets or synthetic genes

This integration of ML is birthing fields like computational pathology and AI-driven drug discovery.

4. Visualization & Human-Readable Biology

Biology isn't all stats and code—it needs to be seen to be understood.

Libraries like Plotly, Matplotlib, and even PyMOL (via Python APIs) help create interactive models of everything from atomic structures to signaling cascades. Some tools now allow drag and drop construction of cell models or simulate tissue level interactions visually in Jupyter notebooks.

Research Examples Using Bioinformatics Libraries

Cancer Genomics: Researchers at the Broad Institute use Python to analyze mutations in large cancer datasets via tools like Pandas and Biopython.
AlphaFold: DeepMind’s breakthrough in protein structure prediction was powered by advanced neural networks—using Python at its core.
COVID-19: During the pandemic, simulation libraries were used globally to model viral spread, test intervention strategies, and analyze SARS-CoV-2 mutations.

Introducing Biobridge

“Simulate. Analyze. Visualize. Interact.”

Biobridge — a Python library for simulating and interacting with biological systems.

With Biobridge, you can:

Model cells, organelles, and proteins
Simulate viral infections, DNA interactions, and tissue environments
Visualize internal biological states and experiment outcomes
Integrate easily with Jupyter notebooks

Installation is as easy as:

pip install biobridge

You have to manually install PyRosetta for more advanced features

️ From Concept to Code: Biobridge in Action

from biobridge import *

protein1 = Protein("Protein A", "ACDEFGHIKLMNPQRSTVWY")
protein2 = Protein("Protein B", "YVWTSRQPNMLKIHGFEDCA")
protein1.add_binding("Site 1", "High")
protein2.add_binding("Site 3", "Medium")

cell1 = Cell(name="Cell X", cell_type="Epithelial Cell")
cell1.add_organelle(Mitochondrion(0.5, 100), quantity=10)
cell1.add_organelle(Organelle("Nucleus", 1), quantity=1)
cell1.add_organelle(Organelle("Ribosome", 100), quantity=100)
cell1.add_chromosome(Chromosome(DNA("ATCG" * 1000), "Chromosome 1"))

print("Cell X Description:")
print(cell1)

In just a few lines, you've defined biological molecules, organized them into structures, and created an artificial cell.

Comparing Biobridge to Other Libraries

Library	Focus Area	Best For
Biobridge	Biological systems & interaction	Simulating cells, proteins, viruses
Biopython	Sequence manipulation	DNA/RNA operations, I/O formats
Tellurium	Systems biology	Metabolic networks, pathway modeling
PyRosetta	Protein modeling	Folding, docking, energy minimization
MDAnalysis	Molecular dynamics	Trajectory analysis of protein simulations

Biobridge distinguishes itself by offering a high-level object-oriented API for building complex, hierarchical biological structures quickly while still supporting visualization and experimentation.

Final Thoughts

The rise of informatics in biology isn't just about convenience it's about scaling insight. As biological systems grow more complex, the tools we use must evolve. Libraries like Biobridge don’t just simulate reality they let you build your own, tweak parameters, and observe outcomes in silico.

Whether you’re a researcher, student, or developer at the intersection of code and biology, informatics libraries are the key to unlocking new discoveries one script at a time.

Embarking on a New Learning Journey: CS50x - Introduction to Computer Science

Mon, 03 Mar 2025 14:26:04 +0000

The world of computer science is vast, intricate, and ever-evolving. Whether you're a beginner taking your first steps or an experienced programmer looking to refine your knowledge, understanding the fundamentals is crucial. Every concept learned serves as a stepping stone to solving complex real-world problems. To deepen my grasp of core principles and develop a stronger computational mindset, I have decided to embark on an enriching learning journey with CS50x - Introduction to Computer Science, a highly acclaimed course offered by Harvard University and taught by the renowned David J. Malan.

Why CS50x?

The decision to start CS50x was not based on a single reason but rather a collection of compelling factors. One of the strongest motivators is its reputation as one of the most thorough and well-structured introductory courses in computer science. Many professionals, students, and self-taught developers regard CS50x as a crucial first step into the world of computing. Unlike many other courses that focus solely on syntax and coding, CS50x emphasizes problem-solving, computational thinking, and abstraction, making it invaluable to anyone looking to understand the "why" behind the "how."

Beyond its reputation, CS50x also offers a level of challenge that pushes learners beyond their comfort zones. It doesn’t just teach you how to write code—it teaches you how to think like a computer scientist. This distinction is important because the ability to think critically, break down problems, and devise optimal solutions is what truly defines a great programmer. The course covers an array of fundamental topics, including algorithms, data structures, memory management, and software development, ensuring a well-rounded education in computer science. What makes CS50x unique is its ability to go beyond just teaching programming—it cultivates a mindset that encourages breaking down complex problems into manageable parts, a skill that is transferable to any domain beyond coding.

CS50x is also widely known for its engaging teaching style. David J. Malan, the lead instructor, brings an infectious enthusiasm to his lectures, making even the most complex topics accessible and enjoyable. The course includes high-quality video lectures, real-world analogies, and interactive problem sets that cater to different learning styles, ensuring a deeper understanding of core concepts.

Course Structure and Content

CS50x spans 11 weeks, each packed with engaging lectures, hands-on problem sets, and challenging but rewarding projects. The course starts with C, a powerful yet challenging language that provides insight into how computers process instructions at a lower level. C is the foundation of many modern programming languages, and mastering it allows students to develop a deeper understanding of computer memory, pointers, and efficient programming techniques. Topics covered in this phase include functions, variables, conditionals, loops, dynamic memory allocation, and data structures such as linked lists and hash tables.

After building a strong foundation in C, students transition to Python, a high-level programming language known for its simplicity and versatility. The shift to Python demonstrates the advantages of abstraction, making coding more accessible while maintaining computational efficiency. By this point, programming in Python feels more intuitive due to the prior experience with C. Additionally, students explore SQL, a language designed for efficient database management, which is essential for handling large-scale data.

To introduce web development concepts, CS50x also covers HTML, CSS, and JavaScript, allowing students to create dynamic, interactive web applications. This exposure ensures that students understand both backend and frontend development, enabling them to build full-fledged applications. The course does an excellent job of reinforcing concepts by integrating them into real-world applications, bridging the gap between theoretical learning and practical implementation.

The problem sets throughout the course are meticulously designed to challenge students and encourage them to apply their learning in creative ways. Some of the standout assignments include:

Creating a simple game in C using loops and conditionals.
Implementing a spell-checker with an optimized data structure.
Building a personal finance tracker using SQL and Python.
Developing a dynamic web application with Flask, a lightweight Python
framework.

The culmination of CS50x is the final project, where students have complete creative freedom to develop something of their own. This project could be anything from a mobile app to a machine learning model, allowing students to explore their passions while applying everything they have learned.

Commitment and Progress Updates

Like any rigorous learning experience, consistency is the key to mastering CS50x. To stay committed and accountable, I plan to document my progress every Sunday, sharing insights, challenges, and breakthroughs along the way. This practice will not only serve as a personal motivator but also provide valuable insights for others who may be interested in taking on the challenge themselves. Engaging with a community of learners enhances motivation and fosters collaboration, making the experience more enriching.

Another crucial aspect of this journey is embracing the struggles that come with learning something new. CS50x is not designed to be easy—it’s designed to challenge you, to make you think deeply, and to push your limits. Some concepts may take time to grasp, but that’s part of the process. The course encourages learners to experiment, debug, and refine their code rather than just following instructions blindly. The skills developed here will prove invaluable, whether in programming, problem-solving, or analytical thinking in general.

If you're looking to gain a strong foundation in computer science, enhance your problem-solving skills, or challenge yourself with an intellectually stimulating course, I highly recommend CS50x. The course is completely free and accessible online, making it one of the most valuable resources available to learners worldwide. You can begin your journey by exploring the course through this link: CS50x Course.

A Final Word of Encouragement

As I embark on this journey, I remind myself that true learning is not about speed but about depth. The challenges along the way will not be obstacles; they will be stepping stones toward mastery. It’s easy to feel overwhelmed when tackling something difficult, but as

Albert Einstein once said, "It's not that I'm so smart, it's just that I stay with problems longer."

To anyone considering CS50x or any other challenging endeavor—don’t hesitate. Push yourself beyond your comfort zone, embrace the struggles, and enjoy the process. Growth comes from perseverance, and every small step forward is a victory.

Let’s embark on this journey together and make learning an exciting, collaborative experience!

Coder Legion - Recent posts tagged computerscience

Kurt Gödel: The Incompleteness Theorems, the Limits of Logic, and Can an AGI Ever Know Everything?

The Tormented Mind: Paranoia, Contradictions, and Poisoned Apples

David Hilbert's Dream and the 1931 Logic Bomb

The First Incompleteness Theorem

The Second Incompleteness Theorem

The Mechanics of the Paradox: Gödel Numbering

From Gödel to Alan Turing: The Birth of Computation

The AGI Dilemma: Can Intelligent Machines Escape Gödel?

1. The Lucas-Penrose Argument: The Human Mind Beyond the Machine

2. The Modern AI Counterargument: Adaptive and Probabilistic Systems

The Real Frontier: The Impossibility of Total Formal Verification

An Open Question for the Reader

What is Agent Harness ?

Behavioral Convergence Without Representational Convergence: Reproducing Training-History Dependen

The Problem With Calling Two Models "Equivalent"

1. Designing an Experiment Around Training History

2. Accuracy Doesn't Tell the Whole Story

3. What Happens After 50,000 Shared Training Updates?

4. Do Different Representations Actually Matter?

The low-data result

Why this matters

5. Testing Alternative Explanations

6. What Should Machine Learning Developers Take Away?

Model evaluation

Transfer learning

Continual learning

Reproducibility

7. Reproducing the Research

8. What Remains Unanswered?

Final Thoughts

Research and Resources

The Alphabet Code: What Happens When You Run a Simple Rule on the Letter “a”

alphabets #nlp #mathematics #symbolicdynamics #fractals #eigenvalues #perronvalues

Data Types Across Programming Languages: What You Actually Need to Know

The deceptively simple data model

Python: let the values tell us what they are

JavaScript: one number, and two different nothings

C: representation becomes difficult to ignore

Java: primitives, references, and the null question

Rust: make some invalid states harder to represent

Go: useful zero values and deliberate simplicity

R: "missing" is not one simple state

The field that caused all the trouble

The table gets weird quickly

If you were designing a language, what would you choose?

One language where absence is not the question

Types are compressed language philosophy

Alex survived

We Promise Transparency. Not the "Liquid Glass" Kind.

Transparency Is the Rarest Feature in Modern Software

What Transparency Actually Looks Like in Gloria

Why This Needed to Exist at All

The Roadmap, Stated Without the Usual Hedging

Watch It Happen Instead of Reading About It Later

Resistors: How to read the stripes, do the math, and avoid the magic smoke

What a resistor actually is (and why your circuit cannot live without one)

Reading resistor values: color codes, demystified

Three worked examples you will see constantly

A mnemonic that actually works

Surface-mount resistors and their secret codes

Why resistors come in weird values: the E12 and E24 series

Power ratings and tolerance: the specs that actually burn

Wattage

Tolerance: when 5% is plenty and when it is not

Temperature coefficient (tempco)

The derating curve (this is the part that saves parts)

Types of resistors and when to reach for each

The math you will actually use

Resistors in series and parallel

The voltage divider

Calculating an LED current-limiting resistor

Common mistakes (and how to avoid a smoky resistor)

Whizz: Your Esoteric Language that's Short as BF, but Easier to Write

Why the Power-of-Two Trick Works for Binary Fractions (And Why It Breaks for Everything Else)

Understanding Binary Coded Decimal (BCD) First

The Problem with Decimal to Binary Conversion

The Fraction Shortcut

Example 1: Converting 0.25 to Binary

Example 2: Converting 0.625 to Binary

JavaScript: one `number`, and two different nothings