Space accounting for a machine reading its input off a work tape #
TM.retargetInput runs a machine M with its input tape relocated to work tape k. That
relocation is exactly what a space bound has to be re-read through: what was M's free input
tape becomes a charged work tape, so the window the retargeted machine needs is M's own space
budget plus the length of the virtual input.
The correspondence is step-by-step (TM.retargetInput_step_commute), so every configuration the
retargeted machine reaches is a wrapped configuration of M — with the real input tape, which it
never consults, drifting only by an idle move. M's bound on its own run therefore transfers.
Main results #
TM.retargetInput_within— a wrapped configuration is inside the window whenM's isTM.retargetInput_keepsWindow_of_reaches— the whole retargeted run stays inside itTM.retargetInputStarted_reaches_iff,TM.retargetInputStarted_keepsWindow_of_reaches— the started wrapper runs the same steps, so the accounting carries overTM.retargetOutput_keepsWindow_of_reaches— redirecting the output onto a work tape costs one cell of windowTM.applyTM_keepsWindow_of_reaches— the two composed: the window of the work-to-work evaluatorTM.applyTM_keepsWindow_of_decidesInSpace— the same from aTM.DecidesInSpacehypothesisTM.liftTM_keepsWindow_of_reaches— adding spare work tapes costs no window
A wrapped configuration sits inside a window as soon as the wrapped M-configuration does:
M's work heads and its relocated input head are all charged against the new budget.
The retargeted run stays inside the window. Every configuration reachable from a wrapped
start is itself wrapped — the step correspondence is exact — so M's bound on its own run is the
only thing needed.
The started wrapper #
The started wrapper keeps the window too. It runs the same steps as TM.retargetInput,
so the accounting of TM.retargetInput_keepsWindow_of_reaches applies verbatim.
Redirecting the output to a work tape #
Redirecting the output onto a work tape costs one cell. The old output tape becomes work
tape n, and the decision convention allows the output head one cell more than the work heads, so
the window grows by exactly that. The real output tape is left parked as a dummy.
The work-to-work evaluator #
The work-to-work evaluator keeps a window. TM.applyTM M is
M retargeted twice — its input read off a work tape, its output written to another — so its
window is M's own decision-space budget, plus the virtual input's length for the relocated
input tape, plus one cell for the relocated output tape. Every quantity is explicit, so a caller
that knows M's polynomial space bound knows this one.
The evaluator's window, from the source machine's space bound alone. Started on the
canonical entry configuration with virtual input y, TM.applyTM M stays inside a window of
|y| + S |y| + 2 — the source's own budget, the relocated input tape, and one cell for the
relocated output. This is the form a caller with a TM.DecidesInSpace hypothesis can use.
Embedding a machine in a larger tape space #
Adding spare work tapes costs no window. TM.liftTM runs a machine unchanged alongside
m extra tapes, which stay parked at cell one throughout, so a configuration of the lifted
machine sits in exactly the window its underlying configuration does. This is how a subroutine is
placed inside a machine with more tapes than it needs.