<p>[Second major edit since first posting:]</p>

<p>This is a supplement to @CarlMummert's answer, with some slight disagreement or clarification.  (He surely knows more than I do in this area, though, so I may have a misunderstanding.)</p>

<p>In the prefix-free machine that D&amp;H describe, the internal structure of the machine is such that it will simply stop reading when it gets to the end of the prefix-free input.  Whatever is beyond that point will never be read under any condition.  Anything can be on that further part of the tape, and it will make no difference to the behavior of the machine.</p>

<p>One might look at it this way: What sense is there to saying that a sequence of values is "accepted" by the machine when they can never make any difference to the output?</p>

<p>(Or if we do start by thinking that the part of the tape beyond the prefix-free input is also "accepted", then since arbitrary extensions of the prefix-free input are accepted in this sense, we might as well factor them out of what counts as the accepted string, and say that only the prefix-free string is accepted.)</p>

<p>I don't think that prefix-free machines have any special connection to parsing distinct words.  There is nothing in the description of prefix-free machines that suggests that they are supposed to advance beyond the end of a prefix-free input to look for a subsequent input.  That's not how the concept of a Turing machine is typically used; Turing machines just map single inputs to single outputs (even if they code ntuples).  </p>

<p>In another text in the same area as D&amp;H's, <a href="https://homepages.cwi.nl/~paulv/kolmogorov.html" rel="nofollow noreferrer">Li &amp; Vitanyi 2008 3d</a>, p. 7 (section 1.2) explains that one can encode a pair of natural numbers <span class="math-container">$\langle x, y \rangle$</span> as a unique natural number <span class="math-container">$y + (x + y + 1)(x + y)/2$</span>. In chapter 3, L&amp;V describe prefix-free machines in several ways, specifying in a few places (pp. 200, 201, 209) that when a prefix-free machine reads a program string, all operations halt once the last element of the prefix-free string has been read, and the next element is never read.  On page 202, L&amp;V define a universal prefix machine <span class="math-container">$U$</span> whose argument three other arguments using the page 7 encoding (cf. p. 105).  (On the other hand, later on the same page, L&amp;V define the prefix complexity of a pair of strings using a machine <span class="math-container">$V$</span> that reads two prefix-free strings separately and then outputs an encoded version of a pair of outputs.  That is like what I take Carl Mummert to describe, but as I interpret the text, <span class="math-container">$V$</span> is not a prefix-free machine.  It's certainly not one that stops after it reads a complete prefix-free string.)</p>

<p>(I'm not sure whether the read-only forward-only behavior that D&amp;H describe in the quoted passage is required for prefix-free machines.  This is part of a question <a href="https://cs.stackexchange.com/questions/118695/why-dont-prefix-free-turing-machines-suffer-from-complexity-dips">I asked in cs.SE</a>.)</p>

CC BY-SA 4.0
2019-12-15T19:11:42.403Z
I think the answer is now confusing because of the conflicting edits coexisting next to each other. In my opinion, it would be better to edit the answer to reflect your latest understanding. If anyone wants to see the history of your answer, they can click on the appropriate link.
Sasho Nikolov
CC BY-SA 4.0
2019-12-15T21:53:59.013Z
OK, thanks @SashoNikolov.  I will edit it as soon as I can.
Mars
CC BY-SA 4.0
2019-12-18T21:34:01.407Z
@SashoNikolov thanks again for pushing me to clarify.  I did some further reading, and now have removed my previous addition, which I think was incorrect, adding additional material about Li & Vitanyi to support my claims.
Mars
CC BY-SA 4.0
2019-12-15T07:19:37.363Z
2019-12-19T07:26:52.000Z
2019-12-19T07:26:52.000Z
Mars
<p>If you were using a self-delimiting machine as described, you have to change your notion of what it means for the machine to accept a string. You want to say that the machine accepts a string $\omega$ if it halts in an accept state <em>with the read head on the last symbol</em>. The idea is to think of the computation as a loop: it first asks whether $\omega\upharpoonright 1$ is in the language, then whether $\omega \upharpoonright 2$ is, and so forth, and it halts if it finds a prefix of $\omega$ in the language or if it runs out of bits of $\omega$. </p>

<p>The point is that if the input tape contains an infinite juxtaposed sequence of nonempty words from the language, the prefix free machine can be used to parse out the individual words from the sequence.  The definition of a prefix-free machine from the book is designed for this sort of application, not for the problem of deciding whether an individual word is in the language. </p>

CC BY-SA 4.0
2019-12-19T12:08:09.750Z
Prefix machines never run out of bits ... the tape is assumed to be infinite.
Peter Shor 
CC BY-SA 3.0
2012-06-04T11:58:49.193Z
2012-06-04T11:58:49.193Z
Carl Mummert
<blockquote>
  <p>A <em>prefix-free function</em> is one whose domain is prefix-free.
  Similarly, a <em>prefix-free (Turing) machine</em> is one whose domain is
  prefix-free. It is usual to consider such a machine as being
  <em>self-demiliting</em>, which means that it has a one-way read head that halts when the machine accepts the string described by the bits read
  so far. The point is that such a machine is forced to accept strings
  without knowing whether there are any more bits written on the input
  tape.</p>
</blockquote>

<p>From Downey and Hirschfeldt, <em>Algorithmic Randomness and Complexity</em>, page 122.</p>

<p>I don't understand why such a device would ensure that the domain of the function is prefix-free. Take a word $\omega$ accepted by the machine. Then, as the next bits won't be read, $\omega \eta$ is also accepted. So $\omega$ and $\omega \eta$ are in the domain, which is not prefix-free.</p>

<p>Where am I wrong ?</p>

CC BY-SA 3.0
2012-06-03T18:14:41.510Z
The question might be more suitable for [cs.se].
Kaveh
CC BY-SA 3.0
2012-06-03T18:57:10.490Z
(the text doesn't say they are the same thing, it says *it is usual to consider* and that means they are essentially the same thing, i.e. they can be converted to each other easily.)
Kaveh
<computability><turing-machines><kolmogorov-complexity><prefix-free-code>
Definition of a prefix-free Turing machine
pintoch
# Definition of a prefix-free Turing machine

(Asked by: username_0 on 2012-06-03)

> A *prefix-free function* is one whose domain is prefix-free.
> Similarly, a *prefix-free (Turing) machine* is one whose domain is
> prefix-free. It is usual to consider such a machine as being
> *self-demiliting*, which means that it has a one-way read head that halts when the machine accepts the string described by the bits read
> so far. The point is that such a machine is forced to accept strings
> without knowing whether there are any more bits written on the input
> tape.

From Downey and Hirschfeldt, *Algorithmic Randomness and Complexity*, page 122.

I don't understand why such a device would ensure that the domain of the function is prefix-free. Take a word $\omega$ accepted by the machine. Then, as the next bits won't be read, $\omega \eta$ is also accepted. So $\omega$ and $\omega \eta$ are in the domain, which is not prefix-free.

Where am I wrong ?

**Tags:** computability, turing-machines, kolmogorov-complexity, prefix-free-code

> **Comments:**
> **username_1**: The question might be more suitable for [cs.se].  
> **username_1**: (the text doesn't say they are the same thing, it says *it is usual to consider* and that means they are essentially the same thing, i.e. they can be converted to each other easily.)  

---

## 2 answers

### Answer by username_4 on 2012-06-04. Score: 9 | Accepted answer

If you were using a self-delimiting machine as described, you have to change your notion of what it means for the machine to accept a string. You want to say that the machine accepts a string $\omega$ if it halts in an accept state *with the read head on the last symbol*. The idea is to think of the computation as a loop: it first asks whether $\omega\upharpoonright 1$ is in the language, then whether $\omega \upharpoonright 2$ is, and so forth, and it halts if it finds a prefix of $\omega$ in the language or if it runs out of bits of $\omega$.

The point is that if the input tape contains an infinite juxtaposed sequence of nonempty words from the language, the prefix free machine can be used to parse out the individual words from the sequence. The definition of a prefix-free machine from the book is designed for this sort of application, not for the problem of deciding whether an individual word is in the language.

> **Comments:**
> **username_5**: Prefix machines never run out of bits ... the tape is assumed to be infinite.  

---

### Answer by username_2 on 2019-12-15. Score: 1

[Second major edit since first posting:]

This is a supplement to @CarlMummert's answer, with some slight disagreement or clarification. (He surely knows more than I do in this area, though, so I may have a misunderstanding.)

In the prefix-free machine that D&H describe, the internal structure of the machine is such that it will simply stop reading when it gets to the end of the prefix-free input. Whatever is beyond that point will never be read under any condition. Anything can be on that further part of the tape, and it will make no difference to the behavior of the machine.

One might look at it this way: What sense is there to saying that a sequence of values is "accepted" by the machine when they can never make any difference to the output?

(Or if we do start by thinking that the part of the tape beyond the prefix-free input is also "accepted", then since arbitrary extensions of the prefix-free input are accepted in this sense, we might as well factor them out of what counts as the accepted string, and say that only the prefix-free string is accepted.)

I don't think that prefix-free machines have any special connection to parsing distinct words. There is nothing in the description of prefix-free machines that suggests that they are supposed to advance beyond the end of a prefix-free input to look for a subsequent input. That's not how the concept of a Turing machine is typically used; Turing machines just map single inputs to single outputs (even if they code ntuples).

In another text in the same area as D&H's, [Li & Vitanyi 2008 3d](https://homepages.cwi.nl/~paulv/kolmogorov.html), p. 7 (section 1.2) explains that one can encode a pair of natural numbers $\langle x, y \rangle$ as a unique natural number $y + (x + y + 1)(x + y)/2$. In chapter 3, L&V describe prefix-free machines in several ways, specifying in a few places (pp. 200, 201, 209) that when a prefix-free machine reads a program string, all operations halt once the last element of the prefix-free string has been read, and the next element is never read. On page 202, L&V define a universal prefix machine $U$ whose argument three other arguments using the page 7 encoding (cf. p. 105). (On the other hand, later on the same page, L&V define the prefix complexity of a pair of strings using a machine $V$ that reads two prefix-free strings separately and then outputs an encoded version of a pair of outputs. That is like what I take username_4 to describe, but as I interpret the text, $V$ is not a prefix-free machine. It's certainly not one that stops after it reads a complete prefix-free string.)

(I'm not sure whether the read-only forward-only behavior that D&H describe in the quoted passage is required for prefix-free machines. This is part of a question [I asked in cs.SE](https://cs.stackexchange.com/questions/118695/why-dont-prefix-free-turing-machines-suffer-from-complexity-dips).)

> **Comments:**
> **username_3**: I think the answer is now confusing because of the conflicting edits coexisting next to each other. In my opinion, it would be better to edit the answer to reflect your latest understanding. If anyone wants to see the history of your answer, they can click on the appropriate link.  
> **username_2**: OK, thanks @SashoNikolov.  I will edit it as soon as I can.  
> **username_2**: @SashoNikolov thanks again for pushing me to clarify.  I did some further reading, and now have removed my previous addition, which I think was incorrect, adding additional material about Li & Vitanyi to support my claims.  

---

