Coder Legion - Recent posts tagged math

The Alphabet as a Sequence Engine: A Census of What Letter Names Generate & What the OEIS Missed.

Tue, 27 Oct 2026 21:09:02 +0000

Abstract
We evaluate the integer sequences generated across 36 human writing systems under the Engineering of Alphabets (EOA) operator. Auditing all 1,056 resulting sequences against the On-Line Encyclopedia of Integer Sequences (OEIS), three facts survive every check we could devise. First, the growth rates of these sequences cluster on a small set of exact algebraic numbers 2.618…, 3.414…, 2.414…, 2, and 3, with 2.618… (φ²) the single largest cluster. Second, several of the generated sequences are, term for term, classics of mathematics: the powers of two, the Fibonacci bisections, the Lucas bisection, the Pell family, the Mersenne numbers, and the bare counting numbers, each verified against the full published OEIS record (up to 90 terms) from our 500-term exact sequences. Third, 388 distinct generated sequences appear in no catalogue, although every one satisfies an explicit integer linear recurrence. To test whether these observations arise by chance, we evaluate two random-baseline controls: random alphabets of matched size never form the tiny cores that natural scripts form (0 of 250 simulations), and the English E5 spectrum splits into two equal halves, a pattern random alphabets never produce (0 of 100 simulations). We release the full census, the matrices, and the verification code, and we pose two challenges to the sequence community.

1. THE RULE, IN ONE PARAGRAPH
Every letter has a name. Apply a fixed recursive expansion rule to each letter name, and repeat round after round. This produces an endless string of letters. Count how long the string becomes at each round: that growing list of numbers is the letter’s sequence. The counts obey a fixed recipe fixed by the script’s letter names alone; no tuning, no search. The mathematical engine behind every sequence is the script’s incidence matrix, and the growth rate of the counts is the Perron eigenvalue of that matrix. The matrices for all 36 scripts are open data; everything below was recomputed from them in exact integer arithmetic.

2. WHAT WE MEASURED
This census covers 36 different writing systems, totaling 1,056 individual letters. We chose these scripts based on their documented historical names and to include a wide mix of different writing styles from unconnected parts of the world. We did not cherry-pick this list to force a result. We deliberately kept all the 'failures' in our dataset: 8 scripts that matched nothing in the OEIS at all (seven formed massive, tangled graphs, while Georgian collapsed), along with several scripts that produced completely trivial, flat sequences. If we had filtered the data to keep only the 12 scripts that generated the non-trivial mathematical families, two-thirds of the dataset would have been thrown out. Because we kept them in, you can trust that the patterns we found emerged naturally from the raw data.
The 1,056 letter-sequences collapse into 402 distinct sequences, because letters that share a naming pattern share their sequence (Appendix, Tables A1–A2). For each distinct sequence we computed its exact recurrence order and its growth rate. Two summaries:
• Recurrence orders run from 1 to more than 14. The most common orders are 13 (47 sequences), 5 (41), 4 (29), and 11 (23); 176 sequences need order above 14.
• Growth rates cluster tightly: 78 sequences grow at φ² = 2.618…, 44 at 2+√2 = 3.414…, 27 at 1+√2 = 2.414…, 20 near 3.1416 (English), 19 near 4.21 (Ogham), 19 at exactly 2 (the Mersenne regime), 8 at exactly 3 (Korean), and 30 distinct sequences are flat (rate 1), matched by 176 letters total.
This census is not a sample; it is the whole population of distinct sequences the 36 scripts can produce. Growth at φ² is the most common outcome in the entire dataset.

3. WHAT MATCHED THE OEIS, AND SURVIVED VERIFICATION
While all our sequences were generated to 500 terms, published OEIS records cut off much earlier; we kept only identities that hold term-by-term across the entire available OEIS entry (up to 90 terms) under an exact recurrence check. These are exact structural identities, not coincidental prefix agreements or numerical approximations. Six families pass:
• The powers of two, A000079: generated by four Hebrew letters (bet, tet, mem, nun), and by the same naming pattern in Phoenician, Aramaic, Syriac, Arabic, Japanese-pronounced Latin, Sanskrit and Amharic. (1, 2, 4, 8, 16 … to 2⁸⁹, exact.)
• The Fibonacci bisection, A001906: generated in Ge’ez and Thai (1, 3, 8, 21, 55 …). Its recurrence t(n+2) = 3•t(n+1) − t(n) is the polynomial x²−3x+1 , the same equation behind the φ² growth above. The odd Fibonacci numbers, A001519, appear the same way in both scripts.
• The odd-index Lucas numbers, A002878: two Thai letters (1, 4, 11, 29, 76 …), same polynomial, different seeds.
• The Pell family, A094723 and A048739: generated in Arabic. Their growth rate is the silver ratio 1+√2 , which is exactly why the Arabic core grows at 1+√2.
• The Mersenne numbers 2ⁿ−1, A000225: generated in Japanese-pronounced Latin, Aramaic and Sanskrit.
• The bare counting numbers: one Syriac letter group generates 1, 2, 3, 4, 5 … with no offset and no error, through all 90 published OEIS terms and continuing through all 500 generated terms.
Table A1 lists all fourteen catalogued sequences, including the further matches beyond these six (the shifted counting variant, the odd numbers, the cake numbers A000125, A000295, and the Burmese silver-square recurrence A007070).

4. WHAT MATCHED NOTHING, THE UNCATALOGUED HALF
388 distinct sequences have no OEIS entry (Table A2 lists the per-script breakdown; every sequence is released with its recurrence in census.csv and uncatalogued_sequences.csv). Each one satisfies an explicit integer linear recurrence of small order, derived from its matrix, and each is released with that recurrence, its matrix, its script and its letters. They concentrate in the large-core scripts: every letter of English E5, Greek, Gothic, Runic, Ogham and Glagolitic is uncatalogued. We make no claim that they are important; we claim only that they are generated, that their recurrences are known, and that no catalogue records them. Whether that gap is worth filling is precisely Challenge I below.

5. TWO CONTROLS THAT MAKE THE ABOVE MEAN SOMETHING
(a) The small-core anomaly. The six verified families come from tiny closed loops of letters: Hebrew and Arabic have dominant cores of 3 letters, Thai of 2, Japanese of 4. Is that usual? We built 250 random 26-letter alphabets with the same name lengths (2–5 letters per name) and computed their cores. Every random alphabet entangled into one giant loop: core sizes ran from 21 to 26, and not one fell below 21 (0 of 250). Natural scripts, in other words, do something random name systems never do: they isolate their growth into loops of two to four letters. This is the quantitative backbone of our name-structure conjecture, and it is reproducible with one script run.
(b) The English split. The English E5 matrix factors as thirteen linear factors and one irreducible polynomial of degree exactly 13, a spectrum split into equal halves. We generated 100 random 26-letter alphabets of matched shape: none produced such a split (0 of 100). Generic random matrices have one large irreducible factor of degree 20 to 26 and almost no linear factors. The English split is a genuine structural anomaly, not a presentation choice.

6. THE CHALLENGES
I. To the uncatalogued 388. Each is released with its recurrence, matrix and attestation. We ask the community for an adjacency audit: is a sequence’s recurrence family already represented in the OEIS? Our own flagship example was, the Hebrew pair dalet and lamed: they generate 1, 4, 12, 34, 94, 256, 690 …, which is 2•F(2n) − 2^(n−1): an order-3 cousin of two catalogued families, whose sibling F(2n+2) − 2ⁿ is A105693. We had called it missing; the record corrected us, and we print the correction. Where a family is genuinely unrepresented and of independent interest, we support inclusion. Where it is catalogued, we ask only that the census record the correspondence. A reasoned rejection will be published with the same care as a match.

II. To the matched six families. Is the hit rate itself remarkable, or do small integer matrices match the OEIS at high rates regardless? We designed a random-matrix control, density-matched, row-shuffled, and degree-preserving, at match windows from 10 to 40 terms, and released the protocol and code. We have not run it to completion. The interpretation rules are fixed in advance: if real scripts match above all controls, naming structure selects catalogued sequences; if they match at control levels, the census rests on the verified identities and the controls alone; if real beats the density control but not the degree-preserving one, the driver is name length and degree structure. Whichever outcome occurs, we pre-commit to publishing it.

7. WHAT WE CLAIM, AND WHAT WE DO NOT
We present an objective measurement: the first complete census of the integer sequences generated by 36 human writing systems, with two verified structural anomalies (small cores, and the English split) and six exact term-for-term matches to named sequences. We do not claim that ancient scribes intentionally encoded mathematics into letter names, nor that these mathematical matches are surprising in number, or that the uncatalogued 388 are profound. The honest open question is the one the census poses and cannot answer: why does the same handful of polynomials, x²−3x+1 above all, organize naming systems that never met?

VERIFICATION AND MATERIALS
Every sequence was computed to 500 terms in exact BigInt arithmetic from the open matrices, and identities in Section 3 were verified against the full published OEIS entries up to 90 terms. The pre-computed census tables (census.csv, uncatalogued_sequences.csv, census_summary.json) and verification scripts ship directly with the release: audit.py (generates the 402-sequence census), verify_wows.py (reproduces the term-exact OEIS identity checks), baseline_oeis_lookup.py (hit-rate control protocol), and e5_split_test_sage.sage (E5 spectral split null).
Matrices: https://doi.org/10.5281/zenodo.23440579.
Main technical paper: https://doi.org/10.5281/zenodo.23449728.
Appendices: https://doi.org/10.5281/zenodo.23695751.

Where do squared error and cross-entropy actually come from?

Wed, 14 Oct 2026 05:20:00 +0000

Short answer: maximum likelihood. Choose a distribution for the output, then:

Read its parameter as the network's output → output function
Take −log of it → error function

Gaussian (regression)

Output: ŷ = Wᵀh + b (the mean)
Error: −log N(y; ŷ, σ²) → squared error (constants drop out)

Bernoulli (binary classification)

Output: exponentiate + normalize → ŷ = σ(z)
Error: −log P(y) → cross-entropy = softplus((1 − 2y)z)

Why the pairing matters: with cross-entropy, the log cancels the sigmoid's exponential, so ∂J/∂z = σ(z) − y. With squared error, σ′(z) stays in the gradient and goes to ~0 when the model is confidently wrong, so learning stalls.

Full derivations: https://husseinmahdi.xyz/writing/series/math-behind-neural-networks/

Next up: softmax + cross-entropy for k classes.

What Math Actually Buys You: Optimizing a Rock-Paper-Scissors Game in C

Sat, 19 Sep 2026 12:32:40 +0000

I was looking through my old projects and found a couple of Rock-Paper-Scissors games I wrote in C a few years back. Why more than one? Because programming is fun, but also because I was experimenting. We're going to look at both versions and talk about how math actually shows up in code. This will not be some generic "you should know math" lecture, but a before/after comparison grounded in my humble experience.

Why this matters if you're self-taught

If you're a fresh CS student or a self-taught developer, there's a decent chance you don't fully buy that math concepts matter day to day. Fair. Here's how I think about it: programming gives you a lot of room to be creative in how you solve problems, but your creativity is powered by what you actually know. Knowledge is the raw material here and math is one of the biggest sources of that raw material.

Here's an example: if you wanted to write a loop in Rust with unusual control flow, and you didn't know that Rust's while is really just shorthand for the common pattern using loop + if + else + break, you'd spend a long time fighting while to do something it wasn't built for. If you knew that, you'd just build the custom loop you actually need.

Or the other direction: a senior dev once took a buggy 12-line React component I wrote and refactored it into 3 correct lines, because he knew which hooks and methods to reach for. Your imagination still needs building blocks to arrange. Math, at a certain stage, is where a lot of those blocks come from. It gives you a precise, calculable, universal way to reason about and express a problem instead of just poking at it until it works.

Let's look at actual code. The full source code for both implementations is public on GitHub here

Iteration 1: the naive version

Here's the main function of the first version I wrote:

int main(void) {
  srand(time(NULL));
  int random_int = (rand() % ((length_options + 1) - 1)) + 1;

  int option;

  printf("Let's play Rock Paper Scissors!\n");
  printf("First to 3 points wins!\n");

  while ((option != 1 && option != 2 && option != 3) ||
         (player_score != 3 && my_score != 3)) {

    round_number += 1;

    printf("\n===============\n");
    printf("Round %d\n", round_number);

    printScores();
    printOptions();

    scanf("%d", &option);

    if (option == 0 || option > length_options) {
      printf("\nPlease select a number ranging from 1 to 3 according to your "
             "desired option.\n\n");
    } else {
      printf("\nYou picked %s\n", options[option - 1].name);
      printf("I picked %s\n", options[random_int - 1].name);
      declare_round_winner((option - 1), (random_int - 1));
    }
    printf("\n===============\n");
  }

  printScores();
  declare_overall_winner();
  return 0;
}

Quick heads up before I explain anything: there's a bug in this loop condition. option is declared but never given a value before the while check reads it:

while ((option != 1 && option != 2 && option != 3) || ...)

Reading an uninitialized variable in C is undefined behavior. It happens to "work" here because whatever garbage value is sitting in that memory slot almost never equals 1, 2, or 3, so the loop starts anyway. But that's luck, not correctness. If you're newer to C, this is a good example of a bug that won't show up as a crash, it'll just quietly rely on the right garbage value. Moving on.

The supporting pieces are what you'd expect: an Option struct holding a name and value, an array of three options (Rock, Paper, Scissors), score counters, a printScores function, a printOptions function that loops over the array so adding a fourth option later doesn't require touching the print logic, and input validation that re-prompts on an out-of-range choice.

The main focal point for this post is how the winner gets decided:

int check_rules(int player_option, int my_option) {
  switch (player_option) {
  case 0:
    if (my_option == 0) return 0;
    else if (my_option == 1) return 1;
    else return -1;
  case 1:
    if (my_option == 0) return -1;
    else if (my_option == 1) return 0;
    else return 1;
  case 2:
    if (my_option == 0) return 1;
    else if (my_option == 1) return -1;
    else return 0;
  default:
    return 0;
  }
}

This checks every possible value of player_option against every possible value of my_option and returns -1 (loss), 0 (draw), or 1 (win). It's ugly, but it's also the most direct solution I could think of at the time. It also doesn't scale. Let's say you wanted to play the more advanced and respected version of the game: Rock-Paper-Scissors-Lizard-Spock, you'd have to add Lizard and Spock. You'd also have to rewrite every branch. Sheldon wouldn't approve.

Iteration 2: what changed, and why

Instead of guessing which part needed optimizing, I looked at the code and realized the winner-check was the ugliest and least scalable part of it so I wrote out every possible outcome as a table:

	Rock	Paper	Scissors
Rock	Draw	Rock Loss	Rock Win
Paper	Paper Win	Draw	Paper Loss
Scissors	Scissors Loss	Scissors Win	Draw

Then I substituted numbers for the outcomes (Win = 1, Draw = 0, Loss = -1):

	Rock	Paper	Scissors
Rock	0	-1	1
Paper	1	0	-1
Scissors	-1	1	0

That's a lookup table. I originally called this "a matrix," but I want to be more precise here than I was when I first wrote this, because the interesting math isn't that it has a nice grid-looking shape. It's that the values in this grid aren't arbitrary. Notice the pattern. It's skew-symmetric (flip any cell across the diagonal and the sign flips), and it repeats in a cycle. This is called modular arithmetic. If you assign Rock = 0, Paper = 1, Scissors = 2, the outcome of any matchup is:

outcome = (player - opponent + 3) % 3

Where a result of 1 means the player wins, 2 means the player loses, and 0 is a draw (you'd remap those three values to +1/0/-1 to match the table above). That's the math concept doing the work here: a cyclic relationship expressed with the modulo operator, the same operation that underlies clock arithmetic, hashing, and a good chunk of the number theory that shows up in cryptography (RSA leans on modular exponentiation directly). A 3x3 lookup table is one way to encode that relationship.

In code, the lookup table version looks like this:

int rules_matrix[3][3] = {{0, -1, 1}, {1, 0, -1}, {-1, 1, 0}};

int check_rules_matrix(int x, int y) {
  return rules_matrix[x][y];
}

void update_scores(int outcome) {
  switch (outcome) {
  case 1:
    computer_score += 1;
    printf("\nI won this round!\n");
    break;
  case -1:
    player_score += 1;
    printf("\nYou won this round!\n");
    break;
  default:
    printf("\nDraw\n");
    break;
  }
}

void declare_round_winner(int c_option, int p_option) {
  update_scores(check_rules_matrix(c_option, p_option));
}

Determining a winner is now a single array access instead of nine branches. Add Lizard and Spock, and you're extending a 3x3 table to a 5x5 table and updating the options array. No switch statements to rewrite.

Does it actually matter?

I wanted to check the performance claim instead of just asserting it, so I benchmarked both approaches directly, 100 million calls each, isolated from I/O:

#define ITERATIONS 100000000

int check_rules_switch(int player_option, int my_option) {
  switch (player_option) {
  case 0:
    if (my_option == 0) return 0;
    else if (my_option == 1) return 1;
    else return -1;
  case 1:
    if (my_option == 0) return -1;
    else if (my_option == 1) return 0;
    else return 1;
  case 2:
    if (my_option == 0) return 1;
    else if (my_option == 1) return -1;
    else return 0;
  default:
    return 0;
  }
}

static const int rules_matrix[3][3] = {
    { 0, -1,  1},
    { 1,  0, -1},
    {-1,  1,  0}
};

int check_rules_matrix(int x, int y) {
  return rules_matrix[x][y];
}

Results, run three times:

1. Switch/Branching Method: 0.343620 seconds (3.44 ns per call)
2. Matrix Lookup Method:    0.275987 seconds (2.76 ns per call)

3. Switch/Branching Method: 0.342246 seconds (3.42 ns per call)
4. Matrix Lookup Method:    0.272867 seconds (2.73 ns per call)

5. Switch/Branching Method: 0.340185 seconds (3.40 ns per call)
6. Matrix Lookup Method:    0.272581 seconds (2.73 ns per call)

The lookup table wins consistently, by about 0.7 nanoseconds per call, roughly a 20% improvement in this specific isolated benchmark. But let's be clear on what that means. 0.7 nanoseconds is nothing in absolute terms. In a real Rock-Paper-Scissors game bottlenecked by scanf waiting on a human, this difference is completely invisible.

So yeah this isn't exactly going to save your production system (unless that's a specific problem your system has). The main point is that recognizing the modular structure of the problem gave me a solution that was simultaneously simpler to read, easier to extend, and measurably faster, all from the same insight. And that's how math helps. Besides making code faster, it also changes what kind of solution occurs to you in the first place.

This is the fact I keep noticing as I move further into security work. A lot of what looks like "cleverness" in an optimized or exploited system is really just someone noticing the underlying structure before anyone else bothered to look for it.

Addendum: what if you skip the table entirely?

If the outcome is really just modular arithmetic, why store a table at all? You can compute the result directly:

int check_rules_mod(int x, int y) {
  return ((x - y + 4) % 3) - 1;
}

Same return convention as check_rules_matrix (1 if x wins, -1 if y wins, 0 for a draw). I checked this against all 9 possible matchups by brute force and it matches exactly, so correctness isn't in question.

Performance is where this got more interesting than I expected, and where I want to be upfront about the limits of what I actually understand.

While putting this post together, I recompiled the exact same switch-vs-matrix benchmark file from above with the -O2 optimization flag, mostly out of curiosity, and the ranking completely inverted:

1. Switch/Branching Method: 0.119248 seconds (1.19 ns per call)
2. Matrix Lookup Method:    0.133597 seconds (1.34 ns per call)
 
1. Switch/Branching Method: 0.120751 seconds (1.21 ns per call)
2. Matrix Lookup Method:    0.128811 seconds (1.29 ns per call)
 
1. Switch/Branching Method: 0.122600 seconds (1.23 ns per call)
2. Matrix Lookup Method:    0.132499 seconds (1.32 ns per call)

The only thing I changed was adding the build flag, and switch went from consistently losing to consistently winning. I don't yet know enough about what the compiler is actually doing under -O2 to explain that properly, branching, inlining, and instruction-level optimization are a whole subject I haven't put real time into, and I'd rather say that plainly than dress up a guess as an explanation.

I also wanted numbers for the modular version above, not just correctness. Getting a fair three-way comparison meant controlling for whether the compiler inlines each function, which isn't something I know how to force myself yet, so I had AI help write a benchmark harness that pins that down explicitly. I compiled and ran it on my own machine, these are the numbers I got:

All three functions forced to inline (best case):

1. Switch/Branching Method: 1.293 ns per call
2. Matrix Lookup Method:    1.339 ns per call
3. Modular Arithmetic:      1.261 ns per call

All three functions forced to be real function calls:

1. Switch/Branching Method: 2.261 ns per call
2. Matrix Lookup Method:    1.697 ns per call
3. Modular Arithmetic:      1.793 ns per call

Same story as the -O2 flip: which one wins depends on a compiler decision, not on the code itself. Inlined, switch is fastest and mod edges out matrix. Forced into real function calls, matrix takes over and switch falls behind badly. Mod never loses badly either way, but I'm not going to dress that up as "modular arithmetic is the safe choice performance-wise" when I can't yet explain why the ranking moves the way it does.

Consider this a flag rather than a finding: something real is going on here, across two separate build decisions, it's outside what I currently know, and it's on the list for a proper, dedicated post once I've actually built the compiler knowledge to back it up instead of just reporting numbers I can't fully explain.

Cover photo by Antony Hyson Seltran on Unsplash

The Math Behind Neural Networks, Explained Like Nobody Did for Me — Part 1.4

Mon, 07 Sep 2026 17:57:26 +0000

Part 1.4 — Which Loss to Choose, and Why. A calm, sequential guide for anyone entering the field. The article is divided into smaller chapters to make it easier to understand.

Part 1.3 ended on a quiet victory. The mean squared error, which we had simply assumed back in Part 1.1 and optimized in Part 1.2, was no longer an assumption. We had derived it — from a single principle, maximum likelihood, and a single modelling choice, that the model’s output is a Gaussian centred on its prediction. The loss we had trusted for two parts was finally standing on a foundation we could see through. The recipe was built: choose the output distribution, and the cost follows.

But a recipe that produces one dish invites an obvious question about all the others. We chose the Gaussian, and squared error came out. That was a choice — the introduction to Chapter 9 said as much and then set the point aside. This part picks it back up. If a different output distribution is chosen, a different cost comes out, and it predicts a different summary of the data. Squared error was never the only item on the menu; it was the first one we happened to order.

There is also a problem hiding inside the loss we derived, one that Part 1.3 had no reason to expose. In the very common case of a yes-or-no prediction, squared error can go quiet at exactly the wrong moment — its gradient falling nearly to zero while the model is still confidently wrong, leaving gradient descent with nothing to follow. The fix is not to patch squared error but to derive a different cost, cross-entropy, from a different distribution, and watch the problem dissolve on its own. This is where the slope idea from Part 1 returns for the last time, and where the choice of loss and the choice of output finally reveal themselves as one decision, not two.

So this part is about reading the menu that Part 1.3 built. We look at what other distributions give, why the loss you pick quietly decides which statistic your model chases, and why practitioners so often reach past the squared error we worked so hard to justify.

Chapter 10: When the Gradient Lies
We built the general recipe, and we chose the Gaussian, and squared error came out. So we could stop. But the practitioners’ literature contains a quiet recommendation that seems, at first, to contradict everything we just did: for many problems, do not use squared error. Use cross-entropy instead. This chapter explains why, and the explanation reaches all the way back to the slope idea from Part 1.

What Is Actually Being Compared
Putting squared error next to cross-entropy can look like a category mistake, so it is worth being clear about what is being compared. They are the same kind of object — both are cost functions, both are numbers measuring how wrong the model is, both are handed to us by the recipe once we pick an output distribution (Gaussian gives squared error; the binary distribution we will meet in Part 2 gives cross-entropy). So comparing them is fair. The reason they come into conflict is not the costs themselves. It is what sits in front of them.

The conflict appears in a specific and very common situation: a binary classification task, where the model must output a yes-or-no probability. To produce a number between 0 and 1, the output is almost always passed through a sigmoid first. And it is the sigmoid, wedged between the network and the cost, that causes the trouble. As we will see, the sigmoid has flat regions, and when squared error is stacked on top of a sigmoid, those flat regions leak into the gradient and flatten it too. During back-propagation — the backward pass we built in Part 1.2 and will extend across layers later — a flat gradient means the update is negligibly small, so the model barely changes even when it is badly wrong. Cross-entropy is the cost whose shape cancels that flattening. That is the whole subject of this chapter: not “which cost is better in the abstract,” but “which cost survives contact with the sigmoid.”

One note before the mechanics. Below, a term written σ′(z) will appear — the slope of the sigmoid. Do not worry about where it comes from in detail here; it is simply the sigmoid’s own steepness at a point, and it enters through the chain rule exactly as the slope did in Part 1.2. We are using it only to see the effect. The full story of the sigmoid, its slope, and the binary (Bernoulli) distribution that makes cross-entropy the derived cost for this task belongs to Part 2.1, where output units are the main subject. Here we only need to watch what σ′(z) does to the gradient.

Two Reasons a Gradient Can Be Small
Recall from Part 1.2 that training lives or dies by the gradient. If the slope of the loss goes flat, gradient descent has nothing to follow and learning stalls, like standing on a flat plateau in fog with no sense of which way is downhill.

Now here is the subtlety. A gradient can go small for two completely different reasons, and only one of them is benign.

The first is the good kind. In your worked example in Part 1.2, as w approached its true value of 2, the errors shrank and the gradient shrank with them. A small gradient there means you have essentially arrived — take smaller steps. Nothing is wrong.

The second is the disaster. The gradient can go nearly to zero while the model is still badly wrong. When this happens, the small gradient is lying: it whispers “nothing to fix here” at exactly the moment the model is confidently mistaken and most needs a shove. This second case has a name. It is called saturation, and avoiding it is the reason cross-entropy is preferred.

Where Saturation Comes From, With Numbers
To see saturation appear, we need an output that can be confidently wrong. Binary outputs are the clean example, and this is exactly the setting flagged above: the model must answer yes-or-no, so it produces a probability ....... .

To read the full article, please visit the link : https://husseinmahdi.xyz/writing/math-behind-nn-1-4/

or this : https://blog.gopenai.com/the-math-behind-neural-networks-explained-like-nobody-did-for-me-87f299008ffb

Refrences
Goodfellow, I., Bengio, Y., & Courville, A. (2016). Deep Learning. MIT Press. Relevant chapter: Chapter 6 (Deep Feedforward Networks), Section 6.2.1 — Cost Functions. Available free at deeplearningbook.org.

The Math Behind Neural Networks, Part 1.3 — Where the Loss Function Comes From

Tue, 18 Aug 2026 19:57:05 +0000

A calm, sequential guide for anyone entering the field. The article is divided into smaller chapters to make it easier to understand.

Part 1.2 left us with a working method but an unexamined assumption. We had a loss, the mean squared error, and we had turned it into a training procedure through the derivative and gradient descent. We watched the loss fall from 18.67 to 0.297 in a single step and then converge to the true relationship in the data. Everything worked. But we never asked where the mean squared error itself came from. We wrote it down as a reasonable way to measure error — square the gap, average it — and moved on. Because it worked, the question never surfaced.

Look again at how it entered. In Part 1.2, the model gave us a form for the line, ŷ = wx + b, but no way to judge whether a particular guess of w and b was any good. The equation described the model and contained no built-in measure of its quality. Faced with that gap, the article said, in as many words: “So we invented one.” We compared the prediction to the truth across all the data and summarized the gap into a single number. Squaring came along because it was reasonable — it makes every error positive and punishes large misses — not because anything forced it.

Chapter 7: What a Cost Function Really Measures

A Note on Three Names
At the end of Part 1.2 we had a complete loop: predict, measure the loss, compute the gradient, take a step. The loss at the centre of that loop was

A quick word on names first, because this article introduces a third one and I do not want it to look like a third thing. In Part 1.1 we called this the error function. In Part 1.2 we called it the loss. In this part, and in most textbooks, you will also see it called the cost function, written J(θ). These are not three different objects. They are three names for the same idea — a single number that measures how wrong the model is and that training tries to make small. “Cost function” is simply the more general term the literature settles on once the measure is no longer tied to one particular formula, which is exactly the situation this article is about to put us in. Wherever you read “cost” below, you may read “error” or “loss” and lose nothing.

The Assumption We Never Examined
With the naming settled: as the introduction recalled, this measure entered the story as an invention — the reasonable thing we reached for when the model gave us no measure of its own quality. Squaring makes every error positive, so overshooting and undershooting both count as wrong, and it punishes a large miss far more than a small one. These are good properties, and they were enough to justify the formula for a first encounter.

But “good properties” is not the same as “forced.” An invention fills a gap; it does not prove it was the only thing that could have filled it. A reader who accepts squared error should be able to answer the harder question that the invention quietly left open: out of all the ways to measure a gap, why this one? Some of that question we have in fact already answered. In Part 1.1 we asked the most natural competing question — why not the absolute gap |y − ŷ|, which also removes the sign — and we ruled it out for a concrete reason: the absolute value has a sharp corner at zero where its slope jumps from −1 to +1 with no value in between, and gradient descent, which lives or dies by reading a clean slope, receives contradictory signals at exactly the point it is trying to settle into. So the absolute value is not an open door; Part 1.1 already closed it, on grounds of the slope.

What Part 1.1 did not close is the deeper question. Ruling out the absolute value tells us squaring is better-behaved than one rival. It does not tell us that squaring is right — that out of every smooth, well-behaved measure we could have invented, this is the one the problem actually calls for. For that we need to stop justifying squared error from the outside and find the principle that produces it from the inside. This chapter goes looking for that principle.

From a Point Guess to a Distribution
In Part 1.2, the model produced a single number: ŷ = wx + b. Given an input, it committed to one answer. This is the natural picture, and it is also the picture that hides the principle we are looking for.

The more honest picture is this. A model is uncertain. Given an input x, it does not truly believe the answer is exactly one number. It believes the answer is probably near some number, with smaller and smaller chances the further you move away. In other words, the model does not output a point. It outputs a distribution — a spread of belief over all the answers that could occur. We write this distribution as

This part is about where that invention actually came from. Why squared error, and not the plain distance, or the cube? The honest answer is that the mean squared error is not a starting point at all. It is a consequence. It is what you are forced to when you begin from a deeper and more general principle about what it means for a model to be good. In this part we start from that principle, watch it produce a single general recipe for building cost functions, and then watch the mean squared error fall out of that recipe on its own.

Readers of Part 1.1 were promised this. Its closing note mentioned, almost in passing, that minimizing the mean squared error is equivalent to maximum likelihood estimation under the assumption of Gaussian noise. That sentence was a debt. This part pays it: everything below is the unpacking of that one line. Part 1.4 then asks the next question — whether the loss we just derived is the one we should actually use.
....
....

Read the full article at the official link: https://husseinmahdi.xyz/writing/math-behind-nn-1-3/

The Math Behind Neural Networks, Explained Like Nobody Did for Me - Part 1.2

Mon, 27 Jul 2026 18:20:40 +0000

A calm, sequential guide for anyone entering the field, The article will also be divided into smaller chapters to make it easier to understand.

Part 1.2: The Mathematics of Learning

Part 1.1 ended at a precise standing point: we had built a model, ŷ = wx + b, and we had a single number, the mean squared error, that told us how wrong that model was on average. What we did not have was a way to act on that number. A loss of 4.67 tells you the model is wrong; it does not tell you whether to push w up or down, and it does not tell you by how much. Part 1.2 is where that missing piece arrives.

We will introduce the derivative, derive the gradient of the loss with respect to w and b by hand, and then turn those gradients into an actual update rule through gradient descent. By the end of this part, the same three data points from Chapter 2 will be used in a full training example, and you will watch the loss fall step by step until the model converges to the true underlying relationship. The slope idea from Chapter 1 does not change. It simply gets sharpened into the tool that makes learning possible.

Chapter 4: The Derivative — The Slope of the Error

Why a Number Alone Is Not Enough
At the end of Chapter 3 we had a single number, L, that summarized how wrong the model was. With w = 1 and b = 0, the loss was 4.67. We know the goal is to make this number as small as possible. What we do not yet know is how.

A reader might suggest trying different values of w and b until the loss becomes small. With two parameters and a simple dataset, this is not impossible, but consider what it involves. Should w be increased or decreased? By how much? Should b be changed at the same time or held steady? A real neural network has millions of parameters, not two, and trying random combinations would take longer than the age of the universe.

The deeper issue is that the loss value, taken on its own, does not contain a direction. The number 4.67 tells you that you are wrong, but it does not tell you which way is less wrong. If I handed you only the number 4.67 and asked you whether to increase or decrease w, you could not answer. You would have to guess. The loss is a position, not a direction. These are two fundamentally different kinds of information, and you cannot extract one from the other by rearranging the same data. You have to ask a new question.

The Equations Have Been Building Toward This
To see why the derivative is the only thing that fits here, it helps to trace the logic of every equation we have written so far. Each one was forced into existence by a problem the previous one could not solve.

We began with the slope formula:

This worked perfectly when the data lay on a clean line, because the slope could be read off directly from any two points. But real data scatters, and the slope formula stopped applying. Different pairs of points gave different slopes, and none of them represented the whole dataset.

So we wrote a candidate line with unknowns to be learned:

This solved the previous problem by giving us a form for the line, but it created a new one. The values of w and b were unknown, and we had no way to evaluate whether a particular guess was good. The equation describes the model but contains no built-in measure of its quality.

So we invented one. We compared the prediction ŷ to the truth y across all data points and summarized the gap into a single number:

This solved the evaluation problem by giving us one number that measures total error. But it created the deepest problem of all, the one we are now standing at. The loss tells us that we are wrong but not which way to change w or b to be less wrong. The information we need is not contained in L. It is contained in how L changes when w changes, which is a different quantity entirely.

To extract that quantity, we need a new equation, one that asks the loss a question the loss formula on its own never asks: if w were slightly different, by how much and in what direction would L change ? The mathematical object that answers this question is the derivative.

From Slope to Derivative

We already have the tool we need, in a simpler form. In Chapter 1, slope told us how y changes when x changes. The derivative is the same idea applied to a different setting. Instead of asking how y changes with x in the data, we now ask how the loss L changes with the parameters w and b in the model. The variables have changed, but the underlying question — how does one thing change as another changes? — is identical.

There is one refinement. The slope formula in Chapter 1 measured the rate of change between two distinct points. The derivative measures the instantaneous rate of change at a single point, which is what you get when those two points move infinitely close together:

This is not a different concept from slope. It is slope made precise. As the gap between the two points shrinks to zero, the slope of the line connecting them becomes the slope of the curve at that exact point.

Why the Derivative and Nothing Else
It is worth addressing directly why the derivative is the right tool here, rather than some other technique. The honest answer is that the derivative is not the only conceivable approach, but it is the only approach ....... .

To complete the article, you can visit the blogs and view the entire series on : https://husseinmahdi.xyz/writing/series/math-behind-neural-networks/

The Math Behind Neural Networks, Explained Like Nobody Did for Me

Sat, 25 Jul 2026 00:02:30 +0000

A calm, sequential guide for anyone entering the field. The article is divided into smaller chapters to make it easier to understand.

Deep learning can feel overwhelming at first. You encounter words like gradient, derivative, loss function, activation, and backpropagation, and it is rarely clear how they relate to each other or where they come from. This article builds the full picture from the ground up, starting from the simplest idea in mathematics, slope, and showing how that single idea grows into everything that powers a modern neural network. No step is skipped, and no formula appears without explanation.

By the end of Part 1.1, three concepts — slope, regression, and error — will form one continuous idea in your mind. You will understand what slope is and why it matters, what linear regression is trying to do, and what the error function measures. Part 1.2 then continues the journey with the derivative and gradient descent, the tools that turn a measurement of error into an actual improvement. Part 2 goes further still, introducing activation functions, multiple layers, and backpropagation, showing how everything here scales into deep networks.

Chapter 1: Slope — The Foundation of Everything

What Is Slope?

Slope answers one question: how much does the output change when the input changes?

If you drive 100 kilometers in 2 hours, your speed — the rate of change of distance with respect to time — is 50 km/h. That is a slope. If a ramp rises 3 meters over a horizontal distance of 6 meters, its steepness is 3/6 = 0.5. That is also a slope.

Formally, the slope between two points (x₁, y₁) and (x₂, y₂) is defined as:

This is called rise over run. The Greek letter Δ (delta) simply means change in.

A Concrete Example

Consider these three data points:

Taking points (1, 2) and (3, 6):

The slope is 2. Every time x increases by 1, y increases by 2. The relationship is perfectly linear and described by:

In real problems, however, we do not know the slope in advance. We have to discover it from data. That discovery process is called regression.

Chapter 2: Linear Regression — Learning the Slope from Data

From Knowing the Slope to Learning It
In Chapter 1 we had three neat data points that fell perfectly on a line, and we computed the slope directly with a formula. and the question this article exists to answer is how mathematics learns from data that does not fall on a clean line at all.

Real data is not like that. When you collect measurements from the world — house prices against square footage, patient weight against medication dosage, temperature against electricity demand — the points do not land on a single clean line. They scatter. No two points give you the same slope, and no formula can hand you the answer.

This is where regression begins. Instead of computing the slope from two chosen points, we ask a different question: what is the single straight line that best represents all of the scattered points at once ? That line will not pass through every point, but it will come as close as possible to all of them. Finding it means learning its slope and its vertical position from the data itself, rather than reading them off with a formula.

.....................

To read the full article, check out my blog: https://husseinmahdi.xyz/writing/math-behind-nn-1-1/
This is part of the "math-behind-neural-networks" series
Or on GoPenAI: https://blog.gopenai.com/the-math-behind-neural-networks-explained-like-nobody-did-for-me-cda519ef63e8

We Dug Up Our Own Fake-Physics Artifact — and Rebuilt It Into Something You Can Check

Sat, 20 Jun 2026 05:12:06 +0000

Why there is a second post

About six months ago we built and published the original QSOT artifact. The name — Quantum State Over Time — promised a deeper link between quantum evolution and temporal structure than the thing underneath could actually support.

Then last week we published a post-mortem with an uncomfortable title: "We Made a High-Formality, Fake Physics Slop Artifact." A quiet admission that we had been wrong, and that the original claims did not survive scrutiny.

It was not a marketing move and not self-flagellation. It was a confession: we had shipped a repository with a DOI, two LaTeX papers, a project page, release notes, plots, and tests — the full visual grammar of serious science — around a core claim that was hollow underneath.

That post diagnosed the failure. It did not repair it. This is the repair.

If we made the mess, we clean it up.

The repair is called QSOT2. It is smaller, narrower, and far less ambitious than the original — and that is the point: the goal is no longer to look impressive, only to keep the claims we can actually justify.

You do not need to have read the first post. I will rebuild the context and show what changed, using evidence rather than adjectives.

For readers who never met QSOT

QSOT stands for Quantum State Over Time — a real idea from the physics literature (Lie & Fullwood) that treats time inside quantum mechanics as a first-class object rather than an external dial.

Our implementation of that idea — QSOT Compiler v1 — tried to map curved-spacetime backgrounds (Schwarzschild, de Sitter, AdS, Gödel) into single-qubit noise channels, then report whether the channels stayed physically valid, whether curvature showed up as decoherence, and whether quantum-information signals changed between backgrounds.

That is an ambitious sentence. It was ambitious in the wrong order.

The foundations were real — standard quantum-channel mathematics, Kraus operators, CPTP conditions. Those are not in dispute. The problem was everything we stacked on top of them.

What was actually wrong

The original problem was not that the repository looked broken. It was the opposite: it looked credible. The code ran, the paper compiled, the plots looked scientific, and the project carried the surface markers of serious work.

But the chain from claim to evidence was not disciplined enough.

The clearest example was the project's theoretical heart: Kirkwood-Dirac negativity. In the actual run, that number was a placeholder. So was the memory-depth signal. The curved-spacetime metrics were named in the papers, but not executed in the way the prose implied.

The form had outrun the evidence. QSOT2 begins by refusing to let that happen again.

Why dig up our own grave six months later

Two reasons, one of them not flattering.

The honorable one: by 2026 we had built executable verification, reproducibility surfaces, hash-based provenance, and a public ledger. The old artifact stopped feeling like an embarrassment and started feeling like an obligation — we made the mess, we finally had the tools to understand it, so cleaning it was our job.

The other: curiosity. Criticising a bad artifact after the fact is easy. Taking the same domain and producing something tighter, smaller, and able to survive its own tooling is not. We wanted to know whether the newer skill was real. QSOT2 was the test.

What QSOT2 changed — and it was not a new theorem

The most important change in QSOT2 is not a result. It is a boundary.

Boundary first. QSOT2 is not a quantum-gravity result. It is not a first-principles derivation. It is a bounded mathematical-consistency verifier for one implemented phenomenological model.

QSOT v1 tried to be a new-physics paper, a quantum-gravity gesture, a governance platform, and a math verifier at once. QSOT2 refuses all of that and asks one question:

Does the implemented model stay internally consistent — as quantum mechanics and as software — and are its numbers honest about what they are?

Smaller question. Much better question.

1. The math matured by subtraction, not ambition

QSOT2 did not make the model bolder. It made its mathematical status clean, by removing every place the old version could pretend:

the curvature-to-noise map is stated plainly — p = 1 - exp(-alpha * ||Riemann||_F), with alpha a free, dimensionless calibration parameter, not a derived constant;
the curvature inputs are disclosed as non-derived toy proxies, so the product alpha * ||Riemann||_F carries no hidden physical-unit claim;
Kirkwood-Dirac is demoted from "contextuality witness" to a bounded, flat-relative diagnostic;
the memory proxy is demoted from "full reconstruction" to a self-tested one.

The curvature tensors are not smuggled in as derived physics: they are explicitly labelled toy proxies in the artifact (a per-background riemann_is_toy flag), so the model cannot silently upgrade itself into a physical claim.

This is what strengthening looks like when the problem was epistemic inflation, not numerical instability. You do not fix inflation by computing harder. You fix it by removing the claims the math could never support.

2. The code stopped being "simulation" and became the witness

In QSOT2 the code's job is not to simulate. It is constraint enforcement — it fixes what may be claimed, what must be measured, what can be re-run, what gets hashed, and what is allowed to fail.

A paper can write "the axioms hold" for free. QSOT2 instead emits, per run: linearity deviation 1.1e-16, CPTP completeness 1.6e-16, trace preservation 4.4e-16 — all at machine epsilon — across 35 deterministic checks (34 pass / 1 degraded / 0 fail). The rule behind it:

Do not let prose carry a claim that the code cannot witness.

There is an architectural version too: the math layer is forbidden from importing the reporting layer — the separation that was missing in v1 is now enforced by the code, not promised by prose.

3. The negative result is advertised, not hidden

!6.png

The overall verdict is DEGRADED_PASS, on purpose: the flat-baseline KD optimizer does not converge inside its fixed 50-step budget — meaning it was still improving when the budget ran out, not that it diverged, so the reported value remains interpretable within the fixed-budget run.

Instead of rounding up, the run says so — in the verdict, the schema, the README, and the paper. The difference between an artifact that wants to impress and one that wants to be trusted often lives in exactly this footnote.

4. The workflow became a claim-custody pipeline

The workflow ties it together: every claim travels a gated path —

claim → code check → artifact → canonical-LF hash → paper line → DOI.

One command runs the experiment and emits one machine-readable result under a fixed schema with a four-field claim boundary; one command runs 50 tests behind a ≥ 90% coverage gate (currently ~96%); the line is DOI-archived on Zenodo (QSOT2 v0.1.2). None of this makes the model physically true — it makes the artifact auditable.

One detail matters here: the reproducibility claim is not hand-waved. The result is anchored to a canonical-LF SHA-256; the known non-byte-stable field is generated_at, and that exception is disclosed rather than hidden. The sensitivity numbers live in a separate committed sweep artifact, and the paper maps each claim back to a named file and hash.

The paper is the formal boundary record

The paper is not decoration. In the original artifact, formal writing made the work look stronger than the evidence underneath. In QSOT2, the paper has the opposite job: it records the boundary of the claim.

Its title says the scope plainly: A Mathematical-Consistency Verifier for a Phenomenological Curved-Spacetime Quantum-Channel Model. The paper does not present QSOT2 as a quantum-gravity result, a first-principles derivation, or an externally validated physical model. It presents it as an executable internal-consistency check for one implemented ansatz.

The structure follows that boundary. It starts with scope and background, then moves through temporal axiom checks, curvature-noise baselines, the flat-relative KD diagnostic, the TTM-inspired memory proxy, consolidated results, explicit non-claims, and reproducibility.

That order matters. The paper does not ask the reader to trust a polished argument. It asks the reader to follow a constrained chain: what the model claims, what the code checks, what the result reports, what the artifact refuses to claim, and how the run can be reproduced.

The abstract already carries the important limits: the curvature-to-channel mapping is a conceptual ansatz with a free calibration parameter; the curvature norms are non-derived toy proxies; the product alpha * ||Riemann||_F carries no physical-unit claim; and the reference run ends in DEGRADED_PASS for one documented reason, the flat-baseline KD optimizer’s fixed-budget non-convergence.

So the paper is not where QSOT2 becomes more impressive. It is where QSOT2 becomes harder to overclaim.

If the repository is the executable surface, and the public ledger is the receipt surface, the paper is the formal boundary surface: the place where the claim is written down in a form that can be checked against the code, the result artifact, and the hash trail.

The receipt: every v1 failure → a measurable

The honest way to prove a repair is to put the old defect and the new measurement side by side. The three that mattered:

1. Placeholders → bounded diagnostics

v1: KD negativity and non-Markovianity were both exactly 0.0.
QSOT2: kd_delta = +0.1230; self-test nm = 1.41e-4 (must fire on injected backflow) vs. model nm = 0.
Means: reproducible, model-relative comparisons — not proofs of contextuality or curvature-induced decoherence.

2. Named spacetime labels → explicit model inputs

v1: the curved-spacetime metrics were named in the papers, absent from the run.
QSOT2: curvature drives the channel across six backgrounds; purities verified — Schwarzschild 0.99943, de Sitter 0.63607, AdS5 0.67764, Eguchi-Hanson 0.99887.
Means: the behaviour of a phenomenological ansatz — not a derived spacetime result.

3. Asserted axioms → verified axioms

v1: temporal and axiomatic properties were stated, not checked.
QSOT2: five temporal-state axioms verified as algebraic invariants, deviations ≤ 4.4e-16.
Means: the model's quantum mechanics is internally consistent under its assumptions. That is the whole claim.

Read this section as the remediation map. The next question is where that map can be inspected outside this essay.

The public ledger is the receipt surface

The public Flamehaven Verification Ledger is where this repair becomes inspectable outside the essay.

The QSOT2 entry is recorded as EQA-TEST-0058, a verification run dated 2026-06-17: "QSOT2: Mathematical-Consistency Verifier (re-scoped honest successor of the 0057 slop)."

That entry states the result directly: DEGRADED_PASS (34 / 0 / 0 / 1). It also states why: the KD flat-baseline optimizer did not converge within its fixed budget. The limitation is surfaced, not hidden.

The ledger record makes the repair checkable in four directions:

JSON — the raw machine-readable result;
Report — the human-readable verification note;
Repo — the source implementation;
Paper — the formal boundary record.

In about three minutes, a reader can move from the ledger card to the raw JSON, the report, the repository, and the paper, and see the same claim boundary repeated across all of them: model-output consistency only, not external physical validity.

That is the point of the ledger. It is not a marketing page. It is a public verification record for Flamehaven's governance reviews, physics verification runs, and biomedical audit scans. Each published run is meant to be deterministic, locally executed, and inspectable from repository state.

The ledger answers one question: where can the evidence be inspected? The next question is narrower and more important: what exactly does that evidence support?

What QSOT2 can verify — and what it refuses to claim

Stated plainly, because vagueness is where slop hides.

QSOT2 verifies, and proves per run:

the implemented single-qubit channels are CPTP (completeness error at machine epsilon);
evolved states stay valid density matrices (Hermitian, unit-trace, positive semidefinite);
five temporal-state axioms hold to ≤ 4.4e-16;
the reported purities, entropies, and KD-delta are deterministic, reproducible, hash-anchored outputs of the implemented model;
the non-Markovianity detector actually fires on injected backflow before it is trusted to report the model's 0.

QSOT2 does not claim, and says so in the artifact:

that the curvature-to-channel map is physically real;
any first-principles derivation;
any quantum-gravity or external-physical result;
that KD negativity is a contextuality proof.

Those refusals are not a closing disclaimer. They are serialized as a claim_boundary block in every result file the system writes.

Why this is not just "nicer slop"

Here is the test, and you can run it yourself.

Slop is the condition where, if you delete the rhetoric, nothing load-bearing remains. In QSOT v1, if you stripped the LaTeX and the project page, the core claim — KD negativity — collapsed to a placeholder. The formality was load-bearing for the deception.

Apply the same deletion to QSOT2. Strip the prose, the README, this newsletter. What is left:

a machine-readable result with 35 named checks and their pass/degrade status,
numerical deviations at machine epsilon you can recompute,
a four-field boundary that states the scope in the data itself,
byte-deterministic outputs with a SHA-256 you can regenerate,
a DOI you can resolve,
a test suite you can run,
an import boundary the interpreter will enforce whether you read the docs or not.

In other words: remove the rhetoric and QSOT2 is still standing; remove the rhetoric and QSOT v1 was a placeholder. That is the difference between persuasion and verification, and it is the only argument here I actually trust — because it does not depend on trusting me.

The cleanest single proof is the one most products would bury: QSOT2 ships its own failing check in plain sight. Slop hides its failures behind formality. QSOT2 prints its one degraded result on the front of the box.

What this actually felt like

Unpleasant first, then clarifying. We had worked hard on QSOT v1 — that was never in question. The hard part was accepting that effort and legitimacy are not the same thing. You can write clean code around a weak claim and a polished paper around a boundary you never defended, and if AI is accelerating your workflow, it accelerates the self-deception too.

That is why the confession had to be public — and why the confession was not enough on its own. Anyone can say "we got this wrong." The harder move is to say: here is what was wrong, here is how we constrained it, here is the artifact that now withstands inspection. The repair matters more than the confession.

The broader lesson

The lesson is not "don't use AI" — we used it heavily for both artifacts. It is sharper:

When AI lets you produce high-formality output in minutes, the scarce resource is no longer generation. It is claim custody.

What is being claimed? What file carries it? What check fails if it drifts? What survives when you delete the rhetoric? QSOT v1 had abundant generation and almost no custody. QSOT2 inverts that ratio in one narrow domain.

Closing

Six months ago we had something that looked like a scientific success and wasn't. Today we have something smaller, less glamorous, and much harder to fool — including harder for us to fool ourselves with. We trust the second one more. That is the progress.

QSOT v1 was the cautionary tale. QSOT2 is what happened when we treated that failure not as embarrassment, but as engineering input.

QSOT2 — a mathematical-consistency verifier, Open source under MIT (Flamehaven Labs). If you disagree with any of it, use the path the artifact was built to survive: clone it, re-run it, and check the hash.

Physical Keyboard for Typing Math

Sun, 07 Jun 2026 18:55:16 +0000

I built a compact physical keyboard for people who type mathematical and scientific symbols often.

The idea came from a small but repeated frustration: writing math by hand is fast, but typing math on a computer usually means stopping to find the right symbol.

If I need a scientific symbol while writing notes, slides, lab reports, or technical explanations, I do not always want to open a symbol menu, copy from an old document, or switch into a full equation editor.

So I started working on the Nitrax Mathematical Keyboard.

It is a physical math keyboard, not a virtual keyboard, calculator, or generic keypad. The symbols are printed directly on the keys, with blue and gray symbol layers accessed through key combinations.

On Windows, the companion app uses AutoHotkey to send Unicode characters into the active application when Math Mode is enabled.

The goal is not to replace LaTeX or professional equation typesetting. It is for everyday math typing in normal writing workflows, where you just need the symbol now and want to keep writing.

Project link: https://mathematicalkeyboard.com/

I would be interested to hear how other developers would approach the layout problem: would you organize math symbols by category, frequency of use, or memory cues?

Usman Zafar Researcher: Milton. Ontario, Canada

Wed, 27 May 2026 19:29:23 +0000

Over the past several years, I have been building a unified research program focused on one central objective:

creating engineering-grade foundations for governing, stabilizing, auditing, and understanding advanced AI systems.

Today, I’m formally sharing the integrated research portfolio of the ZULFR Measurement Institute — spanning AI governance, humanoid robotics, hybrid human–AI systems, observability engineering, and mathematical architectures for reliable AI.

This research ecosystem has been intentionally structured across archival, implementation, citation, and public research platforms to create a transparent, traceable, and engineering-oriented body of work.

Official Research Identity
Website: www.zulfr.com
Email: (Emails are not allowed)

Research Archives & Publications
Zenodo Research Community:
https://zenodo.org/communities/zulfr/records?q=&l=list&p=1&s=10&sort=newest

SSRN Research Papers:
AI Observability & Hallucination Control Engineering
https://dx.doi.org/10.2139/ssrn.6740280

Hybrid Human–AI Agent Organizations
https://ssrn.com/abstract=6650158

AI Governance & System Architecture Foundations
https://dx.doi.org/10.2139/ssrn.6630121

Engineering & Prototyping Workspace
GitHub Research Workshop:
https://github.com/usman19zafar?tab=repositories

Research Profiles
Google Scholar:
https://scholar.google.ca/citations?user=UU3lozkAAAAJ&hl=en

ResearchGate:
https://www.researchgate.net/profile/Usman-Zafar-27

Core Research Themes

• ZULFR Governance Framework — categorical governance for agentic and embodied AI

• Humanoid Robotics Control Architectures — structural analysis of modern humanoid cognitive-control stacks

• AI Observability & Hallucination Control — data-centric stabilization and interpretability engineering

• Hybrid Human–AI Agent Organizations — mathematical models for future organizational dynamics

• TRUE-100 / TRUE-10 Reliability Systems — auditable and trustworthy AI behavior architectures

This portfolio represents a long-term effort to move AI research toward measurable reliability, structural interpretability, and engineering-grade governance.

I’m especially interested in connecting with researchers, governance engineers, robotics architects, formal systems researchers, and organizations working on advanced AI safety and system reliability.

Key Math Concepts in Data Structures and Algorithms

Sat, 07 Mar 2026 23:13:34 +0000

At the core of data structures and algorithms are fundamental mathematical principles that guide their design and implementation. This article explores key math concepts essential for mastering data structures and algorithms, helping developers write optimized and effective code.

Number Systems

A number system is a structured way of representing numbers using specific symbols and rules. Different number systems are based on different base values (also called the radix).

We are most familiar with the decimal number system, which is used in everyday life. It uses ten digits (0 through 9) to represent all numbers. Because it uses ten distinct digits, its base is 10.

Computers, however, operate using only two digits: 0 and 1. Therefore, they use the binary number system, which has a base of 2. All data inside a computer is ultimately stored and processed in binary form.

The octal number system uses eight digits (0 to 7) so its base is 8. It is used as a more compact way to represent binary numbers, since each octal digit corresponds to a group of three binary digits (bits). Octal is still used in certain areas of computing, such as file permissions in Unix and Linux systems.

The hexadecimal number system uses sixteen symbols: the digits 0–9 and the letters A–F. Because it has sixteen symbols, its base is 16. Each hexadecimal digit corresponds to a group of four binary digits, making it a convenient way to represent memory addresses, machine code, and other low-level data in computers.

The octal number system has a base of 8, which means it uses eight symbols: 0 to 7.
Since 8 = 2³, each octal digit can represent exactly three binary digits (bits). Same goes for hexadecimal number system.

You can learn how to convert between these number systems from this detailed article.

Now, let’s talk about the binary number system. We are familiar with representing positive numbers using unsigned binary. But how do we represent negative numbers? For this, we use the two’s complement method, which is the standard way to represent signed binary numbers.

Two's complement method

Negative of any decimal number is mathematically found by subtracting that number from 0. The same applies to the binary number system. In the signed binary number system, the most significant bit (the leftmost bit) indicates the sign of the number.

See the image below if you are not familiar with the most and least significant bits in the binary representation of a number:

Let’s take the example of decimal 7 whose binary representation is 0111. Its binary number system is stored in 4 bits. Zero can be represented as 0000 (in 4 bits). In 4-bit representation, if a fifth bit is present in the leftmost position, it is discarded due to lack of space. So, we can represent zero as 10000 (the bit 1 will be discarded). Now, 10000 can be written as the sum of 1111 and 1. We can then proceed as follows:

Essentially, the negative of a binary number will be its complement added to 1. This method is called as the two’s complement method.

Bitwise Operators

In the decimal number system, we use arithmetic operators like +, -, *, and / to perform mathematical operations. In computing, numbers are represented in binary, and in addition to arithmetic operators, we also use bitwise operators like &, |, ^, ~, >>, and << to manipulate individual bits. Let’s discuss each of these operators.

AND Operator (&)

This operator performs bit-by-bit AND operation on two values. This means that for each bit in the operands, the resulting bit is set to 1 only if both corresponding bits in the operands are 1; otherwise, it is set to 0.

Observation: The AND operation of any number with 1 gives the least significant bit (LSB) of that number.
Example: 5 & 1 results in 1 because 101 & 001 gives its LSB, which is 1.

OR Operator (|)

This operator performs a bitwise OR operation between two operands, setting each resulting bit to 1 if at least one of the corresponding bits in the operands is 1; otherwise, it is set to 0.

XOR Operator (^)

XOR stands for exclusive OR. This operator performs a bitwise comparison between two operands, setting each resulting bit to 1 if the corresponding bits in the operands are different; otherwise, it is set to 0.

Observations:

The XOR operation on any number with 1, results in a number where the least significant bit (LSB) is flipped.
Example: 3 ^ 1 results in 2 because 11 ^ 01 changes the LSB to 0 in this case.
The XOR operation on any number with 0 results in the same number.
Example: 4 ^ 0 results in 4 because 100 ^ 000 gives 100, which is 4.
The XOR operation on any number with itself results in 0 because there are no differing bits.
Example: 5 ^ 5 results in 0 because 101 ^ 101 gives 0 as there are no bits that differ.

Complement Operator (~)

The complement operator gives the bitwise inverse of a number, flipping each bit from 0 to 1 and from 1 to 0.

Left Shift Operator (<<)

The left shift operator is a bitwise operator that shifts the bits of a number to the left by a specified number of positions. Example: 5 << 1 gives 10 because shifting the bits of 5 (which is 101 in binary) one position to the left results in 1010, which is 10 in decimal. If we shift twice (5 << 2), we will get 20 because shifting the bits of 5 (which is 101 in binary) two positions to the left results in 10100, which is 20 in decimal. Therefore, each left shift operation effectively multiplies the number by 2 for each position shifted. In general, if the number is shifted k times, it is multiplied by 2^k.

Right Shift Operator (>>)

The right shift operator is a bitwise operator that shifts the bits of a number to the right by a specified number of positions. Example: 8 >> 1 gives 4 because shifting the bits of 8 (which is 1000 in binary) one position to the right results in 0100, which is 4 in decimal. If we shift twice (8 >> 2), we would get 2 because shifting the bits of 8 (which is 1000 in binary) two positions to the right results in 0010, which is 2 in decimal. Therefore, each right shift operation effectively divides the number by 2 for each position shifted. In general, if the number is shifted k times, it is divided by 2^k.

Core Number Theory

Prime Number

A prime number is a natural number greater than 1 with exactly two positive divisors: 1 and itself. To determine if a number is prime, we typically check divisibility from 2 up to n−1 since it is always divisible by 1 and itself.

int n = 24;
boolean isPrime = true;
for (int i = 2; i < n; i++) {
    if (n % i == 0) {
        isPrime = false;
        break;
    }
}
if (isPrime) {
    System.out.println("Prime");
} else {
    System.out.println("Not prime");
}

The above algorithm makes a maximum of n - 2 (2 to n-1) checks. So, its time complexity is O(N). Let's see if we can optimise it. If we closely examine the factors of any number, they appear in pairs (one smaller and one larger). Mathematically, we can say that for every divisor d > √n (like d = 6), there exists a corresponding divisor $\frac {n} {d} < \sqrt n$ (like 4). Therefore, checking beyond √n is redundant.

If we look into the above possible pairs of factors of 24, we can see that we're checking divisibility of each pair twice. It is sufficient to check divisibility only up to √n since √24 ≈ 4.89, checking up to 4 is enough. Hence, we can reduce the number of computations from the order of N to √N.

int n = 24;
boolean isPrime = true;
for (int i = 2; i * i <= n; i++) {
    if (n % i == 0) {
        isPrime = false;
        break;
    }
}
if (isPrime) {
    System.out.println("Prime");
} else {
    System.out.println("Not prime");
}

The time complexity of this algorithm is now O(√N).

Prime Numbers in Range

Let's say we need to find prime numbers between two certain numbers. The simplest idea would be to check if each of the numbers between them is prime or not.

public class Main {
    public static void main(String[] args) {
        int n = 50;
        displayAllPrimes(n);
    }
    
    public static void displayAllPrimes(int n){
        for (int i = 2; i <= n; i++) {
            if (isPrime(i)) {
                System.out.print(i + " ");
            }
        }
    }
    
    public static boolean isPrime(int n){
        if (n <= 1) return false;
        for (int i = 2; i * i <= n; i++) {
            if (n % i == 0) return false;
        }
        return true;
    }
}

In the above program, the isPrime() method takes O(√N) to check whether a certain number is prime. The displayAllPrimes() method calls the isPrime() method approximately N times. So, the time complexity of the entire algorithm is O(N√N). If we carefully observe the numbers we're checking for prime, we'll notice that there are a number of redundant checks. For example, if we already know that 2 is a prime number then its multiples won't be prime.

Similarly for the rest of the numbers, the below image shows the multiples of smaller prime numbers we've checked earlier.

The unmarked numbers turn out to be the prime numbers we're finding in that range of 2 to 50. This is known as the Sieve of Eratosthenes.

public class Sieve {
    public static void main(String[] args) {
        int n = 50;
        boolean[] isComposites = new boolean[n+1]; // size is n+1 to include n 
        sieve(n, isComposites);
    }

    public static void sieve(int n, boolean[] isComposite){
        for (int i = 2; i * i <= n; i++) {
            if (!isComposite[i]) {
                for (int j = 2 * i; j <= n; j += i) {
                    isComposite[j] = true;
                }
            }
        }

        for (int i = 2; i <= n; i++) {
            if (!isComposite[i]) {
                System.out.print(i + " ");
            }
        }
    }
}

In the program above, we check for multiples up to √N because large numbers can be factored using smaller numbers' multiples. The number of times the inner loop (the loop responsible for marking the composite numbers) runs for each prime number P is $\frac {N} {P}$. Therefore, total number of times the inner loop runs will be:

Hence, the time complexity of this algorithm is O(N loglog(N)).

Newton Raphson Method

The Newton Raphson method is an iterative method of finding better approximations to the roots of a real-valued function. The best linear approximation to any differential function near the point $x = x_i$ will be its tangent with the equation:

where x_i is the ith iterative approximation of root

The root of the tangent equation will be the next iterative approximation x_{i+1} when it intercepts the x-axis (y = 0).

Now, if we want to find the square root of any number (say n), we can take f(x) = x² - n. The root of that equation will give us the closest approximation of √n.

You can view this animated image from Wikipedia, which visually demonstrates all the iteration of approximated roots of f(x).

Let's try to write a program for finding the approximate square root of any number.

public class NewtonRaphsonSqrt {
    public static void main(String[] args) {
        System.out.println(sqrt(43));
    }

    public static double sqrt(double n) {
        double x = n;
        double root;
        while (true) {
            root = 0.5 * (x + (n/x));

            if (Math.abs(root - x) < 0.5) { // Error threshold, can be adjusted for more precision
                break;
            }
            x = root;
        }
        return root;
    }
}

Reducing the error threshold, currently set at 0.5, will result in a more accurate approximation of the square root.

Modular Arithmetic

It is a system of arithmetic operations for integers where the numbers "wrap around" when exceeding a certain number called as the modulus. For a given integer m ≥ 1, it is called a modulus if the difference of two integers a and b (a - b) is an integer multiple of m i.e. a - b = k*m (where k is an integer). The integers a and b are said to be congruent modulo m and is mathematically denoted by a ≡ b (mod m).

The parentheses mean that (mod m) applies to the entire equation, not just to the right-hand side (here, b). In particular, (a mod m) = (b mod m) is equivalent to a ≡ b (mod m), and this explains why "=" is often used instead of "≡" in this context.

The congruence relation is written as *a = b + k\m**.

Source: Wikipedia

In programming, we don’t write congruences directly. Instead, we use the % operator, which computes the remainder. The % operator is the practical realization of the congruence relation. For example: ≡ (mod m) ⇔ (a % m) == (b % m) in code.

The range of (a % m) is always in the range (\[0, m-1\]) when (m > 0). This ensures the remainder is non-negative, which is crucial for consistent modular arithmetic in programming.

Properties:

Addition Property: When adding two numbers, their remainders modulo (m) add up, but if the sum exceeds (m), subtracting (m) (i.e., taking modulo again) brings it back within the valid range.
Subtraction Property: Subtraction can lead to negative results, so adding (m) before taking modulo ensures the result stays within (\[0, m-1\]).
Multiplication Property: Multiplying the remainders and then taking modulo keeps the product within the modular system, preserving equivalence.
Division Property: Division is not straightforward in modular arithmetic. For division by (b) modulo (m) to be valid, (b) must have a modular inverse modulo (m), which exists only if gcd(b, m) = 1.

Modular multiplicative inverse of an integer b is the solution (which exists only when b and m are coprime) of the equation: ax ≡ 1 (mod m).

Bézout's Identity

It is a theorem which related two arbitrary integers with their greatest common divisor (GCD). Mathematically,

where, x and y are integers.

If gcd(a, b) = d, then every integer linear combination ax + by is a multiple of d.

For example, if a = 3 and b = 16, then 3*(-5) + 16*1 = 1 = gcd(3, 16).
Let's take another example: a = 8 and b = 18. Then, 8*(-2) + 18*1 = 2 = gcd(8, 18).

The coefficients x and y can be found using the Extended Euclidean algorithm and the gcd can be calculated using the Euclidean algorithm.

Euclidean Algorithm

The Euclidean Algorithm is one of the oldest and most efficient methods to compute the greatest common divisor (GCD) of two integers. Since Bézout’s identity relies on the GCD, understanding this algorithm is essential. It's based on the principle that if

Effectively, a is reduced by multiples of b until only the remainder is left. Therefore, gcd(a, b) = gcd(b, a % b).

Let’s compute gcd(514, 106) using the Euclidean Algorithm.

We start by dividing the larger number by the smaller one and continue replacing the pair with (b, a % b) until the remainder becomes zero:

514 = 106*4 + 90 → gcd(514, 106) = gcd(106, 90)
106 = 90*1 + 16 → gcd(106, 90) = gcd(90, 16)
90 = 16*5 + 10 → gcd(90, 16) = gcd(16, 10)
16 = 10*1 + 6 → gcd(16,10) = gcd(10, 6)
10 = 6*1 + 4 → gcd(10, 6) = gcd(6, 4)
6 = 4*1 + 2 → gcd(6, 4) = gcd(4, 2)
4 = 2*2 + 0 → gcd(4, 2) = 2

Therefore, gcd(514, 106) = 2.

public static int gcd(int a, int b) {
    if (a == 0) {
        return b;
    }
    return gcd(b % a, a);
}

We can also calculate the LCM of two numbers using their GCD with the formula:
\[\text{LCM}(a, b) = \frac{|a \times b|}{\text{GCD}(a, b)}\]

public static int lcm(int a, int b) {
    return a * b / gcd(a, b);
}

Extended Euclidean Algorithm

This algorithm is an extension of the Euclidean Algorithm which computes the coefficients of the Bézout's identity. We start with the gcd of the two numbers and eventually represent that as a linear combination of those two numbers.

For example, we have found gcd(514, 106) = 2. We start with the last non-zero remainder step: 6 = 4 + 2 ⇒ 2 = 6 - 4.
Then, from previous steps, we can write 6 = 16 - 10 and 4 = 10 - 6. We'll back-substitute them in the above equation.
∴ 2 = (16-10) - (10 - 6) = 16 - 2*10 + 6 = 16 - 2*10 + (16 - 10) = 2*16 - 3*10
∴ 2 = 2*16 - 3*(90 - 16*5) = 17*16 - 3*90
∴ 2 = 17*(106 - 90) - 3*90 = 17*106 - 20*90
∴ 2 = 17*106 - 20*(514 - 4*106) = (-20)*514 + 97*106

Hence, (-20)*514 + 97*106 = 2 = gcd(514, 106). So, the coefficients (Bézout's coefficients) of Bézout's identity would be -20 and 97.

We can utilise the recursion stack to keep track of the steps performed in Euclidean Algorithm. Below is the code for this algorithm:

static int gcdExtended(int a, int b, int[] xy) {
    if (a == 0) {
        xy[0] = 0; // x
        xy[1] = 1; // y
        return b;
    }

    int[] temp = new int[2];
    int gcd = gcdExtended(b % a, a, temp);

    // Update x and y using results of recursion
    xy[0] = temp[1] - (b / a) * temp[0];
    xy[1] = temp[0];

    return gcd;
}

Conclusion

In this article, we explored fundamental mathematical concepts that are crucial for understanding and implementing data structures and algorithms. We delved into number systems, including binary, octal, and hexadecimal, and discussed how computers represent numbers using the two's complement method for signed integers. We also covered bitwise operators and their applications in manipulating individual bits of data.

⭐ Check out the DSA GitHub repo for more code examples.

Copiloting with AI: Learning with Founderz and ChatGPT

Mon, 02 Feb 2026 06:49:51 +0000

In our daily lives, we constantly face barriers when trying to implement good ideas, often due to a lack of technical knowledge and the time needed to figure out where to start. The AI models available today have brought about a revolution in this regard, accelerating timelines and removing learning obstacles. Thanks to these models, we can do more in less time and delve into highly complex fields like programming, allowing us to bring simple applications that implement good ideas to life.

In this context, I recently completed the Introduction to AI and Prompt Engineering course by Founderz, which is no longer available though you can find more similar courses in their website (https://founderz.com/), taught by Pau García-Millá (Founder and Co-CEO of Founderz), Anna Cejudo (Founder and Co-CEO of Founderz), and Magda Teruel (Client Account Manager at Microsoft). It was easy to follow, very educational, well-structured, and it truly made an impact, offering glimpses of what can be achieved with AI through brief and effective instructions.

The course consisted of short videos, between 5 and 15 minutes long, that explained and developed the idea of AI models as "Copilots" in our daily lives. Pau, Anna, and Magda presented examples of how to "talk" to these "Copilots" and how to use them in our day-to-day tasks, showing some advanced use cases and practical examples of how to turn our project ideas into web applications without knowing how to program, thanks to the good work of our "Copilots." To finish, they proposed that you try creating a basic project yourself with these models based on what you've learned, providing a very interesting feedback mechanism from both themselves and other students.

Besides recommending this kind of courses to anyone who wants to get started with AI models and learn more about having these "Copilots," I'm going to use this post to illustrate one of the key takeaways from the course, focusing on how to create a functional application through a simple conversation with ChatGPT and the right instructions.

The "Aha!" Moment of the Founderz Course

The Founderz course was tremendously educational, and its greatest lesson was presenting AI (in this case, Copilot and ChatGPT) not just as a simple search assistant but as a creation partner (a copilot).

The clearest example of this copilotage is how a language model can help us create structured and functional code from an initial idea through a series of simple instructions. Through several practical cases, it teaches how to create self-contained web applications in a single HTML file, unleashing our ideas to improve our daily lives.

The Challenge: Creating a Useful Tool from Scratch with ChatGPT

To put this skill to the test, we're going to create a learning game for basic math operations aimed at preschool and elementary school children between 5 and 7 years old.

The goal was simple: a webpage that would teach and allow practice of basic mathematical operations (addition, subtraction, multiplication, and division) by learning levels, making it engaging for users.

This is where Prompt Engineering comes into play. It's not about asking ChatGPT to "make me an app," but about acting as a product manager who gives the development team (the AI) clear and detailed specifications.

The Initial Prompt

This was the first prompt I used, inspired by the course's methodology, where I defined the entire structure and functionality I wanted (I encourage anyone to experiment and reproduce it themselves on ChatGPT):

Create a simple web application to practice basic math functions: addition, subtraction, multiplication, and division. The goal is to create a simple application that makes it easier for preschool and elementary school children (between 5 and 7 years old) to learn these operations. The application must:

Start with a learning page that explains the 4 mathematical operations.

Allow the selection of a learning level from 4 levels (preschool 1 & 2, elementary 1 & 2).

Allow the selection of a difficulty level (easy with 1 digit, hard with 2).

Have a "Start Game" button that leads to a screen with operations.

Check if the answer is correct and display a motivating message and an emoticon.

Keep track of correct and incorrect answers.

Have an attractive and responsive design using Tailwind CSS.

Include all HTML, CSS, and JavaScript code in a single file.

ChatGPT processed the request and, in seconds, returned a single block of code containing a fully functional application.

The first result worked quite well, but there's always room for improvement . This is where the true power of conversational AI lies: the ability to iterate and improve thanks to the coherence it can maintain in its results. As a test, I asked for a series of changes to make the application more dynamic and attractive:

It works! Now I want you to make the following changes:

Edit the design to be more attractive with gradient colors and nicer fonts.

Add a 10-second countdown for each operation and a scoring system.

Once the answer is submitted, show the correct/incorrect message for 3 seconds and then move to the next operation.

Display the total score at all times.

After 10 operations, show the final result.

Write the complete code again.

And as if by magic, the AI integrated all the improvements and provided me with the final, polished code. You can see the full conversation and the result here: Math App Prompt on ChatGPT.

The "Magic": Your App Running in 30 Seconds

This is the most rewarding part. To run the application we just created, just follow these steps:

Open a plain text editor (like Notepad on Windows or TextEdit on Mac).
Paste the complete code provided by ChatGPT.
Save the file with any name you like, but make sure the extension is .html (for example: math-game.html).
Double-click the saved file.

And that's it! The file will open in your web browser, and you'll have a fully functional educational application, created by you and your AI copilot.

Conclusion and Next Steps

This experience demonstrates the incredible democratization that AI is bringing to the world of digital creation. It is no longer essential to be an expert programmer to build simple and useful tools. What is now crucial is the ability to think in a structured way and give clear instructions, the essence of Prompt Engineering.

This method is incredibly fast for creating and testing tools. But how can we take it a step further and publish this application so that anyone in the world can use it?

We'll talk about that in one of our next posts, where we'll explore the creation process with Gemini's Code Canvas and its public deployment using GitHub Pages. In the meantime, for those who haven't been trying it out in parallel, you can see the result created here: My math app for kids created with ChatGPT

Sources and Resources:

Founderz: Official site
OpenAI: ChatGPT
App's Page: My math app for kids created with ChatGPT

Inside Netflix’s $1 Billion Algorithm - How Recommendations Predict Your Next Binge

Wed, 13 Aug 2025 04:04:35 +0000

Ever Wonder How Netflix Reads Your Mind? The Secret is Out.

Imagine finishing a show, and Netflix instantly suggests your next obsession. Magic? Coincidence? Neither. It's the silent symphony of algorithms, orchestrated to understand your viewing DNA. At its heart: Matrix Factorization.

This isn't just tech talk. It's your invitation to demystify the system that saves Netflix over a billion dollars annually and shapes entertainment. We'll simplify complex ideas, revealing the 'how' and 'why' behind this multi-billion dollar engine. Get ready to discover the secrets that make Netflix feel like it knows you better than you know yourself. Your mind-reading journey begins now.

Netflix's algorithms analyze every click, pause, and genre to build your unique profile. This deep understanding transforms a vast library into a bespoke storefront, preventing 'analysis paralysis' and guiding you effortlessly through cinematic choices.

Clone the repository with all working codes and demonstration for preacticle overview

Part I: The Netflix Revolution - From DVDs to Data Dominance

1. The Billion-Dollar Algorithm That Reads Your Mind

Netflix's journey from DVD rentals to streaming giant is a testament to data leverage. Their recommendation system saves over $1 billion annually by reducing churn and boosting engagement. This highlights the immense business value of algorithmic prowess.

The $1 Million Prize That Changed Everything

In 2006, Netflix launched the Netflix Prize, offering $1 million to improve their Cinematch system by 10% . This sparked a global research frenzy, popularizing Matrix Factorization and reshaping data science. It proved the power of collective intelligence in solving complex problems.

Why 15,000+ Movies = Analysis Paralysis

With tens of thousands of titles, Netflix needs to guide users. Without algorithms, the sheer volume leads to 'analysis paralysis.' The recommendation system acts as an intelligent filter, curating a personalized, relevant, and effortlessly discoverable experience.

Part II: Matrix Math Made Visual - The Language of Recommendations

4. Matrices: The Fundamental Language of Netflix

At the heart of Netflix’s recommendations is the matrix: a structured grid of numbers. In Netflix, matrices paint a picture of user preferences and movie attributes, forming the data foundation for predicting tastes.

The User-Item Matrix: Your Viewing Fingerprint

Imagine a giant spreadsheet: rows are users, columns are movies. Cells contain your rating. Empty cells mean you haven't watched it. This is the User-Item Matrix.

The Sparsity Problem: The Vast Emptiness

Netflix has millions of users and thousands of titles. Most cells in the User-Item Matrix are empty – this is the sparsity problem. It's hard to recommend when data is missing. Matrix Factorization solves this by finding hidden patterns.

5. The Hidden Factors Revolution: Unveiling Latent Desires

To beat sparsity, recommendation systems uncover hidden factors or latent features. These aren't obvious categories, but abstract dimensions of taste learned from data. For you, a factor might be 'love for dark humor.' For a movie, it's how much it embodies that. By mapping users and movies to these factors, Netflix finds deep similarities, even with scarce ratings. It's like understanding your cinematic soul.

6. Matrix Factorization: The Algorithmic Engine of Prediction

Matrix Factorization breaks the huge, sparse User-Item Matrix (R) into two smaller, dense matrices:

User-Feature Matrix (P): Your personal taste profile across hidden factors.
Movie-Feature Matrix (Q): The movie's 'DNA' in terms of hidden factors.

Multiplying your row from P by a movie's column from Q gives a predicted rating, even if you haven't seen it! We find the best P and Q using Stochastic Gradient Descent (SGD). We start with random numbers, predict, calculate error, and nudge P and Q to reduce that error. Millions of repetitions later, our matrices accurately predict your next favorite show. It's a continuous learning loop.

Part III: Code Your Own Netflix - From Theory to Your Screen

Let's build a simplified Netflix recommender in Python. Our goal: make the algorithm click for you.

Clone the repository with all working codes and demonstration for preacticle overview

7. Building the Foundation: Data Representation and Initialization

We'll use a small dataset of user ratings. Our ratings dictionary captures the sparsity:

# Our simplified user-movie rating data: {user_id: {movie_id: rating}}
ratings = {
    0: {0: 5, 1: 3, 2: 4},          # Alice hasn't rated movie 3
    1: {0: 4, 1: 2, 2: 5},          # Bob hasn't rated movie 3
    2: {1: 4, 2: 2, 3: 5},          # Charlie hasn't rated movie 0
    3: {0: 2, 1: 5, 3: 4},          # David hasn't rated movie 2
    4: {0: 3, 2: 3}                 # Eve hasn't rated movies 1 & 3
}

movies = {
    0: "The Action Hero",
    1: "Romantic Comedy",
    2: "Sci-Fi Epic",
    3: "Drama Thriller",
}

users = {
    0: "Alice",
    1: "Bob",
    2: "Charlie",
    3: "David",
    4: "Eve",
}

print("--- Our Sample Ratings Data ---")
for user_id, user_ratings in ratings.items():
    user_name = users[user_id]
    print(f"User {user_name} (ID: {user_id}):")
    for movie_id, rating in user_ratings.items():
        movie_title = movies[movie_id]
        print(f"  - {movie_title}: {rating} stars")
print("-------------------------------")

Next, we initialize our User-Feature (P) and Movie-Feature (Q) matrices with random numbers. num_factors defines how many hidden dimensions we'll discover.

import numpy as np

num_factors = 2 # How many 'hidden' characteristics to discover
num_users = len(ratings)
num_movies = len(movies)

P = np.random.rand(num_users, num_factors) # User-Feature Matrix
Q = np.random.rand(num_movies, num_factors) # Movie-Feature Matrix

print(f"\n--- Initialized Matrices (Our Blank Slate) ---")
print(f"User-Feature Matrix (P) shape: {P.shape}\n{P}")
print(f"\nMovie-Feature Matrix (Q) shape: {Q.shape}\n{Q}")
print("--------------------------")

8. The Training Pipeline: Teaching the Algorithm to Predict

We train our model using Stochastic Gradient Descent (SGD). For each known rating, we predict, calculate the error, and nudge P and Q to reduce that error. This iterative process, repeated over many 'epochs,' optimizes our matrices.

learning_rate = 0.01 # How big of a 'nudge'
num_epochs = 50      # How many times to go through the dataset

print("\n--- Starting Training (Teaching the Algorithm) ---")

for epoch in range(num_epochs):
    total_absolute_error = 0
    for user_id, user_ratings in ratings.items():
        for movie_id, actual_rating in user_ratings.items():
            predicted_rating = np.dot(P[user_id, :], Q[movie_id, :])
            error = actual_rating - predicted_rating
            total_absolute_error += abs(error)

            P[user_id, :] += learning_rate * error * Q[movie_id, :]
            Q[movie_id, :] += learning_rate * error * P[user_id, :]

    if (epoch + 1) % 10 == 0:
        print(f"Epoch {epoch + 1}/{num_epochs}, Total Absolute Error: {total_absolute_error:.4f}")

print("\n--- Training Complete! Our Algorithm Has Learned! ---")

print(f"\nRefined User-Feature Matrix (P):\n{P}")
print(f"\nRefined Movie-Feature Matrix (Q):\n{Q}")
print("--------------------------")

After training, P and Q capture your viewing patterns. The total_absolute_error shrinks, showing our model getting smarter.

9. Advanced Implementation Patterns: Bias Terms and Regularization

Real-world systems add Bias Terms and Regularization for smarter, more robust models.

Bias Terms: Accounting for Your Quirks and a Movie’s Appeal

Some users rate higher, some lower. Some movies are universally loved. Bias terms account for these tendencies:

Global Mean : Average rating of all movies by all users.
User Bias : How much you rate above/below average.
Movie Bias : How much a movie is rated above/below average.

These biases are learned during training, significantly improving accuracy.

global_mean = np.mean([rating for user_ratings in ratings.values() for rating in user_ratings.values()])
user_biases = np.zeros(num_users)
movie_biases = np.zeros(num_movies)

learning_rate_bias = 0.005
num_epochs_bias = 100

P_biased = P.copy()
Q_biased = Q.copy()

print("\n--- Starting Training with Bias Terms (Getting Even Smarter!) ---")

for epoch in range(num_epochs_bias):
    total_absolute_error_biased = 0
    for user_id, user_ratings in ratings.items():
        for movie_id, actual_rating in user_ratings.items():
            predicted_rating_biased = global_mean + user_biases[user_id] + movie_biases[movie_id] + \
                                      np.dot(P_biased[user_id, :], Q_biased[movie_id, :])

            error_biased = actual_rating - predicted_rating_biased
            total_absolute_error_biased += abs(error_biased)

            P_biased[user_id, :] += learning_rate * error_biased * Q_biased[movie_id, :]
            Q_biased[movie_id, :] += learning_rate * error_biased * P_biased[movie_id, :]
            user_biases[user_id] += learning_rate_bias * error_biased
            movie_biases[movie_id] += learning_rate_bias * error_biased

    if (epoch + 1) % 20 == 0:
        print(f"Epoch {epoch + 1}/{num_epochs_bias}, Total Absolute Error (with biases): {total_absolute_error_biased:.4f}")

print("\n--- Training with Bias Terms Complete! ---")

print(f"\nRefined User-Feature Matrix (P) with Biases:\n{P_biased}")
print(f"\nRefined Movie-Feature Matrix (Q) with Biases:\n{Q_biased}")
print(f"\nUser Biases:\n{user_biases}")
print(f"\nMovie Biases:\n{movie_biases}")
print("--------------------------")

Regularization: Preventing Over-Memorizing

Regularization prevents overfitting (memorizing data instead of learning patterns). It adds a penalty during training, keeping P and Q values small. This forces the model to find simpler, more general patterns, improving predictions on new data.

reg_lambda = 0.1 # Strength of the penalty

P_reg = np.random.rand(num_users, num_factors)
Q_reg = np.random.rand(num_movies, num_factors)
user_biases_reg = np.zeros(num_users)
movie_biases_reg = np.zeros(num_movies)

print("\n--- Starting Training with Bias Terms and Regularization (The Final Polish!) ---")

for epoch in range(num_epochs_bias):
    total_absolute_error_reg = 0
    for user_id, user_ratings in ratings.items():
        for movie_id, actual_rating in user_ratings.items():
            predicted_rating_reg = global_mean + user_biases_reg[user_id] + movie_biases_reg[movie_id] + \
                                   np.dot(P_reg[user_id, :], Q_reg[movie_id, :])

            error_reg = actual_rating - predicted_rating_reg
            total_absolute_error_reg += abs(error_reg)

            P_reg[user_id, :] += learning_rate * (error_reg * Q_reg[movie_id, :] - reg_lambda * P_reg[user_id, :])
            Q_reg[movie_id, :] += learning_rate * (error_reg * P_reg[movie_id, :] - reg_lambda * Q_reg[movie_id, :])
            user_biases_reg[user_id] += learning_rate_bias * (error_reg - reg_lambda * user_biases_reg[user_id])
            movie_biases_reg[movie_id] += learning_rate_bias * (error_reg - reg_lambda * movie_biases_reg[movie_id])

    if (epoch + 1) % 20 == 0:
        print(f"Epoch {epoch + 1}/{num_epochs_bias}, Total Absolute Error (with biases & reg): {total_absolute_error_reg:.4f}")

print("\n--- Training with Bias Terms and Regularization Complete! ---")

print(f"\nRefined User-Feature Matrix (P) with Biases & Reg:\n{P_reg}")
print(f"\nRefined Movie-Feature Matrix (Q) with Biases & Reg:\n{Q_reg}")
print(f"\nUser Biases (Regularized):\n{user_biases_reg}")
print(f"\nMovie Biases (Regularized):\n{movie_biases_reg}")
print("--------------------------")

Regularization ensures our model learns general patterns, performing better on new movies.

While Matrix Factorization is the brain, Hash Tables are the unsung heroes ensuring predictions reach 230 million users in milliseconds. They're fundamental data structures for lightning-fast data storage and retrieval.

What is a Hash Table?

A hash table maps keys to values using a hash function to generate an index for direct, quick access. Imagine a magical librarian instantly telling you the exact shelf number for any book.

Why are Hash Tables Crucial for Netflix?

Netflix needs extreme speed for user profiles, movie data, and recommendations. Hash tables provide:

Blazing Fast Lookups (O(1) Average): Instant retrieval regardless of data size. Critical for real-time recommendations.
Efficient Caching: Backbone of caching, allowing instant fetching of pre-computed recommendations.
Session Management: Quick access to user session info for seamless experience.
Distributed Systems: Efficiently distribute data across servers, minimizing latency.

Interactive Performance Comparison: Hash Table vs. List Search

Compare the speed of a Python dictionary (hash table) vs. a list search:

import time
import random

print("\n--- List Search Performance ---")
large_list = list(range(1_000_000))
search_item_list = random.choice(large_list)

start_time = time.time()
found_list = search_item_list in large_list
end_time = time.time()
print(f"Searching for {search_item_list} in a list of {len(large_list)} items:")
print(f"Found: {found_list}, Time taken: {(end_time - start_time):.6f} seconds")

print("\n--- Dictionary (Hash Table) Lookup Performance ---")
large_dict = {i: f"Value_{i}" for i in range(1_000_000)}
search_key_dict = random.choice(list(large_dict.keys()))

start_time = time.time()
found_dict = search_key_dict in large_dict
end_time = time.time()
print(f"Looking up key {search_key_dict} in a dictionary of {len(large_dict)} items:")
print(f"Found: {found_dict}, Time taken: {(end_time - start_time):.6f} seconds")
print("--------------------------------------------------")

Running this shows dictionary lookups are orders of magnitude faster. This speed is why hash tables are vital for Netflix's scale.

⚽ Can We Predict the Next Premier League Champion with Binomial Probability?

Thu, 07 Aug 2025 17:23:46 +0000

What are the chances your favorite EPL team wins the league next season? Time to let math do the talking!

Idea Behind the Madness

Every football fan has asked it:
"Can my team win the league next season?"

Instead of relying on blind hope, I decided to use binomial probability to calculate each team's chances of taking the crown in the next Premier League season, based entirely on how they performed last time.

We’ll:

Fetch last season’s final standings from an API.
Use binomial distribution to simulate two things:
- The probability of a team repeating its exact win total.
- The probability of a team reaching the typical championship threshold which is ≈27.6 so 28 wins.
Rank them accordingly.

️ Step 1: Fetching EPL Data Using an API

I used the football-data.org API to pull the standings. You’ll need a free API token, save it in a .env file like this:

API_TOKEN=your_football_data_token

Now fetch the standings:

import requests
import os
from dotenv import load_dotenv

load_dotenv()

def fetch_epl_standings():
    token = os.getenv("API_TOKEN")
    if not token:
        raise ValueError("API_TOKEN not found in env")
    
    uri = "http://api.football-data.org/v4/competitions/PL/standings?season=2024"
    headers = { 'X-Auth-Token': token }

    response = requests.get(uri, headers=headers)

    if response.status_code != 200:
        raise Exception(f"API request failed with status code {response.status_code}: {response.text}")

    data = response.json()
    return data["standings"][0]["table"]

standings = fetch_epl_standings()

Convert to DataFrame:

import pandas as pd

data_rows = []
for team in standings:
    data_rows.append({
        "Pos": team["position"],
        "Team": team["team"]["name"],
        "Matches": team["playedGames"],
        "Wins": team["won"],
        "Draws": team["draw"],
        "Losses": team["lost"],
        "Points": team["points"],
        "+/-": team["goalDifference"],
        "Goals": f'{team["goalsFor"]}:{team["goalsAgainst"]}'
    })

df = pd.DataFrame(data_rows)
df.to_csv('epl_standings.csv', index=False)

Step 2: Binomial Probability of Exact Win Count

Now let's calculate the probability of each team repeating the exact number of wins they had last season.

import math

# Loop through each row and calculate binomial probability
for index, row in df.iterrows():
    team = row['Team']
    n = int(row['Matches'])  # total games
    k = int(row['Wins'])     # wins
    p = k / n                # estimated win probability

    try:
        binom_prob = math.comb(n, k) * (p**k) * ((1 - p)**(n - k))
    except OverflowError:
        binom_prob = 0.0

    print(f"{team}: P( {k} wins)  = {binom_prob:.6f}")

Sample Output:

Liverpool FC: P( 25 wins)  = 0.135388
Arsenal FC: P( 20 wins)  = 0.128761
Ipswich Town FC: P( 4 wins)  = 0.206486
Southampton FC: P( 2 wins)  = 0.278054

What These Results Tell Us

Top teams like Liverpool have lower exact probabilities, there's more room for variation when you're near the top.
Lower-table teams tend to have higher repeat chances, but don't celebrate just yet...

Step 3: Probability of Title-Winning Season (≥ 28 Wins)

Next, we model the probability of each team reaching 28 or more wins, a common threshold to win the league.

We'll use the cumulative binomial distribution:

from scipy.stats import binom

def title_probability(wins, matches=38, threshold=28):
    p = wins / matches
    return 1 - binom.cdf(threshold - 1, matches, p)

for index, row in df.iterrows():
    team = row['Team']
    wins = int(row['Wins'])
    prob = title_probability(wins, threshold=28)
    print(f"{team}: P(Wins ≥ 28) = {prob:.6f}")

Sample Output:

Team	P(Wins ≥ 28)
Liverpool FC	19.78%
Manchester City FC	1.54%
Arsenal FC	0.66%
Chelsea FC	0.66%
Newcastle United	0.66%
Manchester United FC	0.00%

Interpretation

Liverpool is most likely to hit 28+ wins based on current form.

City, Chelsea and the others trail behind, possibly due to more draws or inconsistent performances.

Man United? Their chance rounds to zero. Ouch .

United fans, this model says your 11-win season gives you a statistically negligible shot at the title. You might want to pray harder than you code.

⚠️ Limitations

Let’s be honest, binomial probability isn’t a crystal ball. Here's why:

It ignores real-world dynamics: transfers, injuries, managerial changes.
It assumes independent, identically distributed matches (which football is not).
Based on one season, not a large enough sample for deep insight.

But hey, it’s fun and statistically grounded!

Want to Take This Further?

Here’s how you can level up the model:

Use Poisson regression to simulate goals per match.
Integrate Elo ratings or other power metrics.
Run full Monte Carlo simulations of future fixtures.
Track the model live across the season for dynamic probabilities.

Final Thoughts

While this model won’t help you win your fantasy league, it does give a math-driven glimpse into who’s statistically positioned to succeed. Liverpool fans? You have reason to dream. Southampton? Maybe next year...

Football is unpredictable, and that's what makes it beautiful. But every now and then, it's fun to let the math have a shot at calling the game. ⚽

Coder Legion - Recent posts tagged math

The Alphabet as a Sequence Engine: A Census of What Letter Names Generate & What the OEIS Missed.

Where do squared error and cross-entropy actually come from?

What Math Actually Buys You: Optimizing a Rock-Paper-Scissors Game in C

Why this matters if you're self-taught

Iteration 1: the naive version

Iteration 2: what changed, and why

Does it actually matter?

Addendum: what if you skip the table entirely?

The Math Behind Neural Networks, Explained Like Nobody Did for Me — Part 1.4

The Math Behind Neural Networks, Part 1.3 — Where the Loss Function Comes From

Chapter 7: What a Cost Function Really Measures

The Math Behind Neural Networks, Explained Like Nobody Did for Me - Part 1.2

Part 1.2: The Mathematics of Learning

Chapter 4: The Derivative — The Slope of the Error

From Slope to Derivative

The Math Behind Neural Networks, Explained Like Nobody Did for Me

Chapter 1: Slope — The Foundation of Everything

Chapter 2: Linear Regression — Learning the Slope from Data

We Dug Up Our Own Fake-Physics Artifact — and Rebuilt It Into Something You Can Check

Why there is a second post

For readers who never met QSOT

What was actually wrong

Why dig up our own grave six months later

What QSOT2 changed — and it was not a new theorem

1. The math matured by subtraction, not ambition

2. The code stopped being "simulation" and became the witness

3. The negative result is advertised, not hidden

4. The workflow became a claim-custody pipeline

The paper is the formal boundary record

The receipt: every v1 failure → a measurable

The public ledger is the receipt surface

What QSOT2 can verify — and what it refuses to claim

Why this is not just "nicer slop"

What this actually felt like

The broader lesson

Closing

Physical Keyboard for Typing Math

Usman Zafar Researcher: Milton. Ontario, Canada

Key Math Concepts in Data Structures and Algorithms

Number Systems

Two's complement method

Bitwise Operators

AND Operator (&)

OR Operator (|)

XOR Operator (^)

Complement Operator (~)

Left Shift Operator (<<)

Right Shift Operator (>>)

Core Number Theory

Prime Number

Prime Numbers in Range

Newton Raphson Method

Modular Arithmetic

Bézout's Identity

Euclidean Algorithm

Extended Euclidean Algorithm

Conclusion

Copiloting with AI: Learning with Founderz and ChatGPT

The "Aha!" Moment of the Founderz Course

The Challenge: Creating a Useful Tool from Scratch with ChatGPT

The Recipe: The Detailed Prompt (and its Refinement) is Key

The Initial Prompt

The Refinement: The Conversation Continues

The "Magic": Your App Running in 30 Seconds

Conclusion and Next Steps

Sources and Resources:

Inside Netflix’s $1 Billion Algorithm - How Recommendations Predict Your Next Binge

Ever Wonder How Netflix Reads Your Mind? The Secret is Out.

Part I: The Netflix Revolution - From DVDs to Data Dominance

1. The Billion-Dollar Algorithm That Reads Your Mind

The $1 Million Prize That Changed Everything

Why 15,000+ Movies = Analysis Paralysis

Part II: Matrix Math Made Visual - The Language of Recommendations

4. Matrices: The Fundamental Language of Netflix

The User-Item Matrix: Your Viewing Fingerprint

The Sparsity Problem: The Vast Emptiness

5. The Hidden Factors Revolution: Unveiling Latent Desires

6. Matrix Factorization: The Algorithmic Engine of Prediction

Part III: Code Your Own Netflix - From Theory to Your Screen