← Latest papers
💻 computer science

Evidence-Tracked Tape Semantics for Probabilistic Computation

This paper introduces an evidence-tracked tape semantics for probabilistic computation that unifies intensional and extensional perspectives through a realizability framework, enabling higher-order logic with uniform evidence transformers to derive sound quantitative laws and support probability-one reasoning via tape-rewiring and pushforward abstractions.

Original authors: Liron Cohen (Ben-Gurion University of the Negev, Beer-Sheva, Israel), Tomer Samara (Ben-Gurion University of the Negev, Beer-Sheva, Israel)

Published 2026-05-12
📖 6 min read🧠 Deep dive

Original authors: Liron Cohen (Ben-Gurion University of the Negev, Beer-Sheva, Israel), Tomer Samara (Ben-Gurion University of the Negev, Beer-Sheva, Israel)

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are trying to understand how a computer program makes decisions when it involves chance, like rolling a die or flipping a coin.

Most computer scientists usually look at these programs from the "outside." They ask: "If I run this program a million times, what is the final distribution of results?" This is like looking at a bag of marbles after you've shaken it and asking, "What percentage are red?" This is called extensional reasoning. It's useful, but it forgets how the marbles got mixed.

This paper proposes a different way to look at things: intensional reasoning. Instead of just looking at the final bag of marbles, the authors imagine the program as a machine that reads from a long, explicit tape of random numbers (like a roll of film or a stream of bits).

Here is a breakdown of their ideas using simple analogies:

1. The "Random Tape" Metaphor

Think of a probabilistic program not as a magic box that generates randomness, but as a deterministic robot reading from a pre-written script.

  • The Script (The Tape): Imagine a very long piece of paper with a sequence of random numbers written on it (0s and 1s).
  • The Robot: The program reads this paper from left to right. If it needs a random number, it reads the next bit. If it needs another, it reads the next one.
  • The Twist: Because the robot reads from a single, physical piece of paper, if it reads a "1" and then uses that same "1" again later, the program knows they are the same. If it reads two different bits, it knows they are different.

This is crucial because in the "outside" view (the bag of marbles), reusing a number and picking two new numbers often look the same statistically. But in the "tape" view, they are completely different actions. This allows the authors to track correlations (how one random choice affects another) much better.

2. The "Evidence Tracker" (The Receipt)

The paper introduces a concept called Evidence-Tracked Semantics.

  • The Analogy: Imagine you are a judge in a court case. Usually, you just decide if a statement is true or false. But here, the authors want a receipt for every proof.
  • How it works: When the authors prove that "Program A leads to Result B," they don't just say "It's true." They produce a specific piece of code (an "evidence transformer") that acts like a translator. This translator takes the "proof" that A works and mechanically transforms it into a "proof" that B works.
  • Why it matters: This makes the logic proof-relevant. It's not just about what is true, but how we know it's true. If you change the way the program reads the tape (rewiring the tape), this "translator" code can be updated to show that the proof still holds, just in a new format.

3. The "Splitting" Trick (Independence)

One of the hardest things to do in probabilistic programming is ensuring two things happen independently.

  • The Problem: If you have one long tape and you run two programs one after the other, they will naturally read from the same tape. They aren't independent; they are sharing the same stream of randomness.
  • The Solution: The authors propose a "Splitter." Imagine taking that single long tape and cutting it in half. The top half goes to Program A, and the bottom half goes to Program B.
  • The Magic: They show that if you have a mathematical rule (a "realizable map") that can split the tape, you can prove that the two programs are now using independent randomness. They can then take a proof made for "two separate tapes" and mathematically "stitch" it back together to prove something about a "single tape" program. This is like proving a rule for two separate dice, and then showing how to apply that rule to a single die that has been split into two faces.

4. From "Tape" to "Law" (The Translation)

The paper builds a bridge between their detailed "tape" view and the standard "law" view (the bag of marbles).

  • The Process:
    1. Intensional Layer: They do all their complex reasoning on the tape, tracking exactly how randomness is used.
    2. The Measure: They decide on a specific way to sample the tape (e.g., "assume every bit is a fair coin flip").
    3. Extraction: They use a mathematical tool (Expectation) to translate their detailed tape proofs into standard numbers (probabilities).
    4. The "Almost Sure" Filter: They introduce a filter that ignores "null sets" (events so rare they have a probability of zero). This is like saying, "If something only happens on a tape that is infinitely unlikely, we can pretend it never happens." This cleans up the math and makes it robust.

5. The "Must" Abstraction

Finally, they look at a specific type of safety check called the "Must" property.

  • The Analogy: Imagine a safety inspector checking a rollercoaster. They don't care if the coaster might crash 1% of the time; they care if it crashes any time it has a non-zero chance of happening.
  • The Result: They show that if a program is proven safe on the "tape" level (meaning it works for almost every possible tape), it translates perfectly into a "Must" safety guarantee on the "law" level. This gives a way to prove that a program will almost certainly terminate or stay safe, without getting bogged down in complex probability numbers.

Summary

In short, this paper builds a new language for talking about random programs.

  • Instead of just guessing the final odds, it treats randomness as a physical resource (a tape) that programs consume.
  • It provides receipts (evidence) for every logical step, allowing us to track how changes in the random source affect the program.
  • It offers tools to split randomness to create independence and stitch it back together.
  • It finally translates these detailed, tape-based proofs into the standard, high-level probability statements we are used to, ensuring that the math is sound and the logic is transparent.

The authors aren't saying this is the only way to do it, but they argue it's a much clearer way to understand how randomness is used inside a program, especially when programs are complex and nested.

Drowning in papers in your field?

Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.

Try Digest →