This might read like lab notes written after too much espresso, but the math is still correct.

limitless numbers starts from a simple premise: useful numbers do not always fit in 32 or 64 bits, and rounding is not “good enough” when exactness matters.

Most numeric bugs are representation bugs, not theory bugs wearing fake mustaches and passing CI exactly once.

• int overflows silently or wraps
• double cannot represent most decimal fractions exactly
• conversions between types lose information
• two values that look equal in source are not equal in memory

If your problem domain is finance, symbolic transforms, exact ratios, cryptography exercises, protocol math, or generated test vectors, these issues show up fast, usually during demos.

So limitless had one job: exact arithmetic until memory runs out, with a C API that is direct, portable, and small enough to embed without summoning dependency dragons.

One number type, two exact forms

At runtime the type is a tagged union with two modes and zero drama:

• integer: arbitrary-precision signed bigint
• rational: num/den, both bigints, always normalized

The mental model has three rules and no hidden DLC:

1. If a result is an integer, keep it integer.
2. If an operation requires a fraction, promote to rational.
3. If a rational simplifies back to denominator 1, collapse to integer again.

So 6 / 3 stays integer 2, but 7 / 3 becomes exact 7/3. No hidden float conversion, no binary rounding drift, no emergency “why is 0.3 weird” meeting.

This is not “big float.” It is exact integer/rational arithmetic.

The real constraint is invariants, not operators

Adding + - * / is straightforward. Keeping invariants intact after every operation is the real fight:

• denominator is always positive
• zero has one canonical representation
• rational is always reduced (gcd(num, den) = 1)
• outputs are failure-atomic (on error, caller output is unchanged)

If those invariants drift, everything above them starts wobbling like a shopping cart with one broken wheel and a race condition.

So internally the library normalizes aggressively and uses temporary compute-and-swap patterns so error handling is predictable.

Many C libraries stash allocator state globally. Convenient for demos, painful in real use.

limitless uses a per-context model:

• allocator hooks live in limitless_ctx
• no hidden global mutable state
• no mandatory libc dependency if you override alloc/realloc/free
• thread safety is naturally scoped by context ownership

There is also a beginner path:

• limitless_ctx_init_default(&ctx) for quick start
• limitless_ctx_init(&ctx, &alloc) for custom environments

So you can start with defaults, then switch to arena/pool/failing allocators without rewriting API usage or sacrificing sanity.

Big integer magnitude is a little-endian limb array. Yes, “limbs.” Welcome to bigint country.

• limbs are 32-bit by default
• optional 64-bit limb mode is available when supported
• sign is tracked separately from magnitude
• zero is represented canonically (sign=0, used=0)

The little-endian limb layout keeps carry/borrow loops simple and cache-friendly for schoolbook ops.

Rationals are just two bigints with strict normalization rules. Sounds trivial, but keeping that stable across parse/format/ops/conversions is where the complexity piles up.

Division is the key semantic choice and where many libraries quietly betray you.

In many libraries, integer division truncates unless you call a separate rational function. In limitless, limitless_number_div() returns exact math by default, with no truncation jump-scare:

• integer result if divisible
• rational otherwise
• divide-by-zero is explicit LIMITLESS_EDIVZERO

That makes expressions safer because the default is mathematically correct, not “we rounded, crossed fingers, shipped.”

Other operations are standard exact arithmetic with type promotion where needed:

• add/sub/mul across int/rat combinations
• unary neg/abs
• total compare via exact cross-multiply logic

Advanced integer operations

A second layer exposes integer-only helpers for deliberate number wizardry:

• gcd
• pow_u64 (exponentiation by squaring)
• modexp_u64 (modular exponentiation)

These are useful for crypto toy projects, number theory utilities, and parser/generator test fixtures where correctness has to survive contact with reality.

The rules stay strict:

• integer-only APIs reject non-integer values with LIMITLESS_ETYPE
• modulus constraints are validated
• range and invalid states return status codes, not UB

Most numeric libraries do okay on arithmetic and faceplant on conversion edges.

This one spends real effort there, because conversion bugs often become flaky tests that fail only in CI at 2am:

• parse from bases 2..36
• optional base autodetect (0x, 0b, etc.)
• rational text input as numerator/denominator
• formatting with caller buffer and explicit required-length reporting
• integer exports with range checks (to_i64, to_u64)

There are convenience aliases for beginners too:

• from_str() and to_str() as base-10 shortcuts

The formatting API returns LIMITLESS_EBUF when capacity is too small and reports required length so callers can resize safely.

Easy to skip, important in practice, mildly cursed in a very IEEE-754 way.

limitless_number_from_float_exact() and ..._from_double_exact() decode IEEE-754 object representation and construct the exact rational/int value for that bit pattern.

• finite values become exact numbers
• NaN / Inf are rejected (LIMITLESS_EINVAL)
• 0.1 becomes its exact binary-rational equivalent, not a rounded decimal string

That is useful for debugging cross-language serialization and reproducible numeric tests, especially when two runtimes claim agreement while clearly disagreeing.

C and C++ usability without splitting the core

The core stays strict C (limitless.h), with a C++ wrapper (limitless.hpp) layered on top for convenience.

C side:

• explicit lifecycle
• explicit context
• explicit status handling
• no operator overloading fantasy

C++ side:

• RAII wrapper class
• operator overloads for natural expressions
• primitive-left operators (int + limitless_number, etc.)
• parse/string helpers (parse, str)
• works in no-exception builds

So beginners can write:

limitless_number x = 33424234;
limitless_number y = (x + 3) / 2.3f;

C users keep full control over memory and error flow; C++ users get friendlier syntax without changing the math engine under the hood.

Testing had to be more than unit happy paths

For exact arithmetic, confidence comes from combinatorics and failure injection, not a handful of happy-path tests and a prayer.

Test coverage includes:

• generated deterministic vector matrices (large pairwise op sets)
• parse/format round-trips across multiple bases
• float/double exact import edge sets (normals, subnormals, signs)
• property-style randomized checks
• differential checks against Python fractions.Fraction
• allocator fault injection to force OOM at many allocation sites
• failure-atomic guarantees (out unchanged on failure)
• single-TU and multi-TU include model checks
• C++ wrapper equivalence behavior vs C core

So this is not just “worked on my laptop and one lucky CI run.” It is a correctness envelope exercised continuously across many modes.

Packaging and release shape matter too

A lot of open-source libs stop at “here is a header, good luck” and vibes.

This one also ships consumer paths:

• CMake package target: limitless::limitless
• pkg-config metadata
• Conan recipe
• vcpkg overlay port
• GitHub Actions matrix across OS/compiler families
• coverage and release automation

Not glamorous, but this is what makes a library usable by teams and not only by the author on one machine.

What this is good for (and not good for)

Good fit:

• exact fraction arithmetic
• educational math tooling
• parser/transformation pipelines needing deterministic exactness
• interoperability tests where numeric drift is unacceptable

Bad fit:

• performance-critical floating-point simulation
• vectorized numeric workloads
• cases where approximate real arithmetic is both expected and sufficient

It is a precision-first library, not a throughput-first numeric engine, and that tradeoff is intentional.

Check it out or try it out here (open-source): limitless

Yet another thing:

The basic idea behind superblocks is deceptively simple: take a neighborhood, block through-traffic from cutting through it, and suddenly you have quiet streets where kids can play and people can walk without dodging cars. Barcelona did this and it worked beautifully.

The question is: how do you systematically plan this for an entire city?

It turns out the whole problem is really about graph theory.

A city’s street network is a graph:

• Nodes are intersections
• Edges are streets
• Every edge has properties (road type, capacity, speed limit, one-way, etc.)

When you load OpenStreetMap data for a city, you’re essentially getting a massive weighted graph with tens of thousands of nodes and edges.

The goal of superblock planning is to partition this graph into cells where:

• Through-traffic is impossible within each cell
• Every address remains reachable from the outside

This is a constrained graph partitioning problem.

First you identify the arterial network. These are your primary, secondary, and tertiary roads — the ones designed to carry traffic. They form a subgraph that should remain fully connected and handle all the through-traffic.

Everything else — residential streets, service roads, living streets — becomes candidates for the interior of superblocks.

The arterial network essentially defines the boundaries of your superblocks. If you think of arterials as the edges you’re not allowed to cut, then superblocks are the faces of the planar graph formed by those arterials.

In graph theory terms, you’re finding the minimal cycles in the arterial subgraph, and each cycle bounds a potential superblock.

But here’s where it gets interesting: you can’t just say “everything inside this arterial boundary is a superblock”.

People still need to reach their homes by car. Deliveries need to happen. Emergency vehicles need access. So you need entry points.

The entry point problem is about finding nodes on the boundary where vehicles can enter the superblock interior. The key constraint is the no through-traffic property:

Once you’re inside, you shouldn’t be able to exit from a different entry point without going back out and around on the arterial network.

Mathematically, this means the interior subgraph of each superblock must be partitioned into sectors, where each sector is only reachable from its designated entry point. If you can drive from a north entry to a south entry through the interior, you’ve failed — that’s through-traffic.

To enforce this, you modify the interior graph:

• Modal filters: delete edges from the vehicle graph entirely (cyclists and pedestrians can still use them)
• One-way conversions: change undirected edges to directed edges
• Turn restrictions: keep the edges but forbid certain transitions at nodes

The algorithm tries to find the minimal set of modifications that achieves the no-through-traffic property while keeping all addresses reachable. This is essentially a min-cut problem with reachability constraints.

For each superblock, you compute which nodes are reachable from which entry points after applying the modifications:

• If a node becomes unreachable from all entries, the modification set is too aggressive.
• If a node is reachable from multiple entry points in different sectors, the modification set isn’t aggressive enough (through-traffic is still possible).

The reachability check is just breadth-first search from each entry point, respecting directed edges and modal filters. You mark which nodes each entry can reach, and then verify two things:

1. Every interior node is reached by at least one entry.
2. No interior node is reached by entries from different sectors (unless they share a boundary, which gets complicated).

Sector assignment itself uses angular partitioning: compute the centroid of the superblock polygon, then assign each entry point to a sector based on its angle from the centroid.

Four sectors give you north/east/south/west. Eight sectors add the diagonals. The idea is that entries on opposite sides of the superblock should be in different sectors, so traffic between them has to use the arterial network.

Validating the constraint globally is a graph connectivity problem. After all modifications, you build the “can I get from A to B” relation for all pairs of entry points:

• If entry A and entry B are in different sectors, there should be no path between them through the interior.
• If they’re in the same sector, there should be a path (so addresses in that sector are reachable).

You’re essentially checking that the interior graph has been decomposed into the right number of connected components.

The routing part is also pure graph theory. Given an origin and destination, find the shortest path that respects superblock constraints:

• If both points are on the arterial network, it’s standard Dijkstra or A*.
• If one or both are inside superblocks, you first route to the appropriate entry point, then across arterials, then from the destination’s entry point to the destination.

The cost function penalizes interior travel to encourage using arterials.

Traffic estimation without real data uses graph-theoretic heuristics:

• Edge betweenness centrality measures how many shortest paths pass through each edge (high betweenness means high traffic).
• You can also simulate flow by assuming trips are generated proportionally to residential density and attracted proportionally to commercial density, then computing shortest paths between all origin-destination pairs. The fraction of paths using each edge estimates its load.

The whole system is basically a pipeline:

1. Load the OSM graph.
2. Extract the arterial subgraph.
3. Find the faces (superblock candidates).
4. Compute entry points for each face.
5. Find minimal modifications to enforce the sector constraint.
6. Validate reachability.
7. Provide routing that respects the new structure.

What makes it tractable is that real street networks have useful properties:

• They’re roughly planar (streets rarely cross without intersections).
• They have hierarchical structure (arterials form a coarse grid, local streets fill in).
• Superblocks are spatially local, so you can process them independently.
• The modification search space is bounded: you’re only considering edges in the interior, and most interiors have maybe 20–50 edges.

The output is a transformed graph where through-traffic is structurally impossible, not just discouraged. You’re not relying on signs or enforcement — the network topology itself prevents it. That’s the mathematical elegance of the superblock concept.

Check it out or try it out here (it’s open-source, so contributions welcomed): Superblocker

I’m pretty enthusiatic about world-models and especially JEPA (and V-JEPA), so I started small prediction engine, that predicts the next few frames based on the imput stream’s current frame, visualizes the latent space (and its movement) and creates a guess about motion. I’m planning to use this in a car to build up a driving world-model.

A world model is an AI system that learns to predict what will happen next. Unlike traditional computer vision models that just classify images, world models understand dynamics how things move, change, and evolve over time.

This is exactly what you need for robotics, autonomous vehicles, or any AI that needs to act in the real world. Before taking an action, you want to ask: “What will happen if I do X?”

I made a thing: It is a Riemann Zeta function convergence explorer with a 3D surface view. You can open it here: Riemann Zeta explorer. It lets you sweep the complex plane domain, pick presets (critical strip, first zeros, near the pole), and toggle layers like the critical line, known zeros, reference planes, and divergence region. There are also modes to compare analytic continuation against Dirichlet partial sums or prime zeta partials, plus error and relative error views.

Enjoy!

GTD with this.

So, this is getting better. I’ve always wanted to be able to just casually drop any thought here and however the markdown post are working fine, it is a bit hard to just e.g. post something from my phone. But with a custom GitHub action that accepts all the necessary data to create a new MD file and then pushes and updates the site: 🔥.

This post was sent from my phone via GitHub actions

ENKAIDU.

Currently listening to this episode:

A Threads post embedded right here:

Instagram embedding with Markdown! So, I promise this won’t be a meme site, I just try this out. I consider this progress.

View on Instagram

I’m happy to announce that this site can handle two posts together. Can it handle three? Come back later to find out!

So, I decided to make a bloggish landingish page. A brutalist corner of the internet where I’ll share thoughts on research, random ideas, and whatever else crosses my mind. I tried some kind of weird fusion of OpenVibe, Threads etc., but I think it’ll be better if I just post things here and maybe share to other platforms.

I’m not very good at this, so improvements are on their way.

Follow via RSS if that’s your thing.