The computation structure is stable. HST reads it once and keeps it.
Speeding up compute with HST
HST routes only the tiles that moved, then returns an exact result or falls back when the update is no longer local. Hierarchical Sparse Transform helps changing systems avoid repeating work they already know.
Tell us what changes in your system, what must remain exact, and how often the structure around it stays put. That is usually enough to give a first-fit estimate quickly — and the fit test asks it in six questions.
Grid
64 × 32
Changed tiles
—
Motion density
—
Tiles reused
—
The idea
Most systems do not start over because everything changed.
Cameras, books, grids, rankings, and scoring systems usually move in pieces. A few inputs change. The structure around them stays familiar.
HST is built for that shape: keep the reusable work, update the changed state, and fall back to the exact path when the change is no longer local.
A small input moves. HST finds the affected boundary, not the full domain.
Exact routes match full recompute; approximate routes report error and fall back when required.
Local update streams can avoid broad sparse traversal when the dirty region stays small.
HST keeps the long pole small by reusing what is already known.
Measured against sparse baselines with matrix size, touched work, runtime, and relative error reported.
The operating loop
From changed state to exact answer, without paying for the unchanged middle.
HST sits between the source system and the expensive compute path. It watches the delta, maps the dependency boundary, updates the necessary region, and hands the result back through the interface teams already understand.
-
01
Capture the delta
New frame, new event, changed sparse row, or updated grid cell.
-
02
Find the boundary
The math layer asks which dependencies actually moved.
-
03
Reuse the known work
Stable state remains cached, structured, and cheap.
-
04
Return the result
Exact mode preserves correctness; budgeted mode prioritizes impact.
Use cases for HST
HST is the math layer that sits between full recomputation systems and changing workloads.
HST treats each input as a sparse edit. It builds dependency boundaries, updates only the impacted region with fast local math, and stitches in a mathematically exact result when needed. Think: an intermediate layer that absorbs local change before a global system pays full cost.
Model the fit
Choose the workload shape. Watch where HST inserts itself.
Sparse kernels are a direct fit: replace the familiar call, keep the workflow intact, and use HST to avoid low-impact memory traffic.
Mode
Exact sparse call
Pressure point
Memory traffic
Streaming input systems
Many event updates are local. HST tracks changed columns and routes the sparse delta through affected operator regions.
Stateful compute pipelines
HST keeps prior state available, applies A dx against the fixed operator, and reports the route used.
Simulation and scoring workloads
When a state cell changes, HST identifies the operator support touched by that delta and checks error against exact baselines.
Search and ranking refresh loops
Small ranking deltas can be propagated through sparse operator edges without rescoring cold regions.
Physics, vision, and CV pipelines
HST sits as the boundary-aware math function between frames, so unchanged regions remain frozen and cheap.
Deployment
HST links into the process that already owns the state.
There is no server, no port, and no round trip. HST ships as an embedded library that you link into the service already holding the dense state, and you call it like any other function. That is not a packaging preference; it is what the latency arithmetic forces. The delta kernel does its work in roughly 0.002 ms. The cheapest network hop we measured — loopback HTTP on the same machine — costs 1.75 to 4.55 ms. Any transport in front of the kernel is three orders of magnitude larger than the thing it is transporting, so the transport becomes the entire runtime and the speedup disappears.
One library, one header
Link libhstcore against your binary. It exposes an opaque C ABI, so it binds from C, C++, and anything with an FFI, without pulling our build system into yours.
Build the operator once, apply deltas many times
You compile the fixed operator once and keep the handle. Each step you hand it the changed columns and it writes the result into your buffer. The state never leaves your address space because it never moves at all.
Offline, Ed25519-signed
The library validates a signed license file at open time and fails closed. There is no activation call, no telemetry beacon, and nothing to allowlist at your egress.
HST runs entirely inside your process boundary and never calls home. Whether it helps you at all depends on the shape of your workload, not on how you deploy it — the fit test is the faster way to find out.
Compare notes
Bring the workload shape and deployment plan.
HorneSci is strongest in fixed-topology physical networks — grid EMS/DMS models, utility and sensor hierarchies, data-center telemetry trees — where the operator holds still and only the inputs move. Bring your workload profile (what changes, how often, and how local it is), your exactness requirements, and the trace you would want us to measure against. The fit test is the fastest way to find out whether the call is worth either of our time.
Boundary
If everything changes, HST should say so.
The product is strongest when updates are local. When they are not, the answer should be boring and honest: use the exact route.