Incremental computation

Incremental computation updates a result after its inputs change by reusing previous work and updating the parts that depend on the change. An execution monitor can use it to revise filled quantity as corrections arrive without scanning the entire fill ledger for each correction. The updated result should agree with a fresh calculation on the same inputs under the same rules. Acar et al., An Experimental Analysis of Self-Adjusting Computation

Three confirmed buy fills for one instrument contribute 4, 7 and 9 shares, for a total of 20. A correction replaces fill B's 7 shares with 3. The incremental update retracts the old contribution and adds the new one.

A full recomputation sums the current records, $4+3+9=16$ shares. The incremental update only needs the saved total and the two versions of B's quantity. If the correction supplies only the new value, the old quantity must come from retained state or an authoritative record. Budiu et al., DBSP, §§4.1 and 7.2

The dependency boundary is the set of results that could change. If the correction also changes the fill's timestamp across a reporting boundary, the old day's total loses the old contribution and the new day's total gains the replacement. Any report that reads those totals must be updated or marked stale until it is rebuilt. A change to the reporting rule itself, such as the session cutoff, can invalidate much more history than a single fill correction. Acar et al., An Experimental Analysis of Self-Adjusting Computation, §2.1

In stream processing, a correction can be delivered again after a restart. Blindly applying the same change of $-4$ shares twice leaves 12 shares. Idempotent application means another delivery of the same logical correction leaves the total at 16. One design gives the correction its own stable ID, distinct from the ID of fill B, and commits the updated fill, total and processed ID together. This assumes corrections for a fill arrive in version order, or that the update verifies the version it is replacing before applying the change. Checkpoint-based replay can also preserve state by restoring it with the matching input position. Apache Flink, Stateful Stream Processing

The SelfMadeQuant Live Execution Monitoring lesson applies the same replay check to an execution ledger and reconciles filled quantity with outstanding orders. The preview is public, and the full lesson requires membership.

A sum takes a fixed number of arithmetic operations for one replacement once the old and new quantities are available. A saved maximum alone cannot tell you the next maximum when the largest fill is withdrawn. That update needs more state, such as an ordered collection of active values, or a rescan. Budiu et al., DBSP, §7.2