Return to Question

EDIT:

The question essentially depends on at least some code for arbitrary $\alpha<\eta$ stabilizing at times $<\omega^L_1$. Unfortunately, since I didn't mention it right at the beginning of the question, this is why it might have seemed confusing.

But my reason for edit is mostly related to the answer and the discussion related to it (and this might be too long for a comment). Given the variable $v$ (in the question), each time when its increase is triggered we can flash the output (for example, in the outline I linked above, this would occur within the "if" condition). In the answer given to the question, what I have called variable $v$, more or less corresponds to the position of "red mark". This flashing is mentioned in the answer (see the last paragraph of the answer) as an example of a program whose output doesn't stabilize at any point $<\omega^L_1$.

There is still something unsettling for me regarding this. Maybe I am imagining things incorrectly (since I haven't thought about it in precise way yet) but the thing that is unsettling for me is the rate/frequency at which the variable $v$ will increase (or alternatively, the position of "red mark").

Because, at a basic thought, it seems that the frequency of this change must be fairly high. Because if $v$ stays constant for too long then a program with empty input (and with access to parameters $<p$ where $p<\omega^L_1$) would be able to halt beyond the supremum of the allowed halting positions. $p$ is a fixed value in the previous sentence. Obviously this isn't allowed, so $v$ can't be staying constant (for long stretches) below $\omega^L_1$.

But obviously above $\omega^L_1$ this is what happens (so it actually stays constant forever). Perhaps there is an easy explanation for this. I will think over it carefully (and possibly post it as a separate question) after thinking about it more closely (i.e. whether it can be made precise or not) and if it seems like a genuine question. In-case there is an easy explanation to this, it would be interesting to read.

EDIT:

The question essentially depends on at least some code for arbitrary $\alpha<\eta$ stabilizing at times $<\omega^L_1$. Unfortunately, since I didn't mention it right at the beginning of the question, this is why it might have seemed confusing.

But my reason for edit is mostly related to the answer and the discussion related to it (and this might be too long for a comment). Given the variable $v$ (in the question), each time when its increase is triggered we can flash the output (for example, in the outline I linked above, this would occur within the "if" condition). In the answer given to the question, what I have called variable $v$, more or less corresponds to the position of "red mark". This flashing is mentioned in the answer (see the last paragraph of the answer) as an example of a program whose output doesn't stabilize at any point $<\omega^L_1$.

There is still something unsettling for me regarding this. Maybe I am imagining things incorrectly (since I haven't thought about it in precise way yet) but the thing that is unsettling for me is the rate/frequency at which the variable $v$ will increase (or alternatively, the position of "red mark").

Because, at a basic thought, it seems that the frequency of this change must be fairly high. Because if $v$ stays constant for too long then a program with empty input (and with access to parameters $<p$ where $p<\omega^L_1$) would be able to halt beyond the supremum of the allowed halting positions. $p$ is a fixed value in the previous sentence. Obviously this isn't allowed, so $v$ can't be staying constant (for long stretches) below $\omega^L_1$.

But obviously above $\omega^L_1$ this is what happens (so it actually stays constant forever). Perhaps there is an easy explanation for this. I will think over it carefully (and possibly post it as a separate question) after thinking about it more closely (i.e. whether it can be made precise or not) and if it seems like a genuine question. In-case there is an easy explanation to this, it would be interesting to read.

I posted this question on MSE (link: Eventual Writability (general)) about 10 days ago. The current version of this question is a highly abridged version of the one posted there.

The question is about eventual writability in the setting of OTM or a similar model. Let's first observe how we might try to generalise the relevant notions. Let's first observe how we might try to define the relevant notions. First consider the notions of "eventually writable real" and "accidentally writable real". If we are talking about OTM then it seems reasonable to designate the initial $\omega$ length of tape and consider this in defining the relevant notions. Similarly, if we have a program that supports a variable (of type list), then we can have a separate (list) variable where the first $\omega$ elements are observed. Also observe that, as in original definition, we want the program to start from empty tape and/or zero/uninitialized variables.

Let's write "accidentally writable" and "eventually writable" as AW and EW respectively. So we have the notions of: (i) AW-real (ii) Sup of AW-ordinal (iii) EW-real (iv) Sup of EW-ordinals. Let's simply use $AW$ and $EW$ to denote (i) and (iii) respectively. We will only be concerned with subsets of $\omega$ so it wouldn't be a problem. Let's use the symbols $\mathcal{A}$ and $\eta$ for the ordinals in (ii) and (iv) respectively. We can say that an ordinal $<\eta$ is eventually writable if its code (in the sense of well-order of $\mathbb{N}$) appears on the output section (of $\omega$-length) never to be changed again.

If the answer to part-(A) below is positive then why can't we set a variable whose value stablizes to $\omega^L_1$ (never to be changed again). And, in that case, then why can't we set a variable whose value stablizes to $\eta$ itself?

For the rest of the post I use $\omega_1$ to mean $\omega^L_1$. For the rest of the question "code for $\alpha$" simply means "well-order of $\mathbb{N}$ (in suitably encoded form) with order-type $\alpha$".

First we assume the access to an onto function $f:Ord \rightarrow AW$. That is, we have a program which when given any arbitrary input $x$ will halt and return a real that belongs to $AW$. Essentially, $f(x)$ corresponds to the "$x$-th time" an AW-real appears on the output (for a program that enumerates all elements of $AW$).

I posted this question on MSE (link: Eventual Writability (general)) about 10 days ago. The current version of this question is a highly abridged version of the one posted there. Let's write "accidentally writable" and "eventually writable" as AW and EW respectively. See definition-3.10 (page-8) here for the definitions. So we have the notions of: (i) AW-real (ii) Sup of AW-ordinal (iii) EW-real (iv) Sup of EW-ordinals. Let's simply use $AW$ and $EW$ to denote (i) and (iii) respectively. Let's use the symbols $\mathcal{A}$ and $\eta$ for the ordinals in (ii) and (iv) respectively.

Why can't we set a variable whose value stablizes to $\omega^L_1$ (never to be changed again). And, in that case, then why can't we set a variable whose value stablizes to $\eta$ itself?

For the rest of the post I use $\omega_1$ to mean $\omega^L_1$. For the rest of the question "code for $\alpha$" simply means "well-order of $\mathbb{N}$ (in suitably encoded form) with order-type $\alpha$". We assume the access to an onto function $f:Ord \rightarrow AW$. That is, we have a program which when given any arbitrary input $x$ will halt and return a real that belongs to $AW$. Essentially, $f(x)$ corresponds to the "$x$-th time" an AW-real appears on the output (for a program that enumerates all elements of $AW$).