Because it is known to be true that a correct pure simulation of the
input by the halt decider would demonstrate the actual behavior of this
input it is known that this is a correct basis for a halt status
decision by the halt decider.

A simulating halt decider need only perform a pure simulation of N steps
of its input until:
(a) Its input halts on its own or
(b) The simulated behavior of its input correctly matches non-halting
behavior patterns conclusively proving that a pure simulation of this
input would never stop running.

[*Olcott 2021 generic halt deciding principle*] Whenever the pure
simulation of the input to simulating halt decider H(x,y) never stops
running unless H aborts its simulation H correctly aborts this
simulation and returns 0 for not halting.

*Computable functions* are the basic objects of study in computability
theory. Computable functions are the formalized analogue of the
intuitive notion of algorithms, in the sense that a function is
computable if there exists an algorithm that can do the job of the
function, i.e. given *an input of the function domain it can return the
corresponding output* https://en.wikipedia.org/wiki/Computable_function

A halt decider is a decider; which is a type of computable function;
which is a type of function; which only applies to its inputs in its domain.

No function is ever accountable for anything besides input parameters in
its domain.

This means that when int main() { P(P); }; has different behavior than
int main() { H(P,P); }; this does not make any difference at all.

*Halting problem undecidability and infinitely nested simulation V2*
https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

olcott <NoOne@NoWhere.com> writes:

> A halt decider is a decider; which is a type of computable function;
> which is a type of function;

No. Several people have tried to explain why this is wrong, but you are
still saying it.

--
Ben.

On 12/11/2021 4:48 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> A halt decider is a decider; which is a type of computable function;
>> which is a type of function;
>
> No. Several people have tried to explain why this is wrong, but you are
> still saying it.
>

You can say that a computable function is not a function and this makes
as much sense as saying that a dog is not a dog.

*Computable functions* are the basic objects of study in computability
theory. Computable functions are the formalized analogue of the
intuitive notion of algorithms, in the sense that a function is
computable if there exists an algorithm that can do the job of the
function, i.e. given *an input of the function domain it can return the
corresponding output* https://en.wikipedia.org/wiki/Computable_function

*Computable functions* only apply to actual inputs in their domain.
Anything that is not an actual input to a computable function is outside
of the scope of this function. In typical functional notation an input
is specified as a list of arguments following the function name: H(P,P)

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

olcott <NoOne@NoWhere.com> writes:

> On 12/11/2021 4:48 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> A halt decider is a decider; which is a type of computable function;
>>> which is a type of function;
>>
>> No. Several people have tried to explain why this is wrong, but you are
>> still saying it.
>
> You can say that a computable function is not a function and this
> makes as much sense as saying that a dog is not a dog.

Agreed. So you still don't know which bit is wrong?

By the way, you can't learn any topic by reading wikipedia. Remember,
it can be edited by people like you.

--
Ben.

On 12/11/2021 5:24 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 12/11/2021 4:48 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> A halt decider is a decider; which is a type of computable function;
>>>> which is a type of function;
>>>
>>> No. Several people have tried to explain why this is wrong, but you are
>>> still saying it.
>>
>> You can say that a computable function is not a function and this
>> makes as much sense as saying that a dog is not a dog.
>
> Agreed. So you still don't know which bit is wrong?
>
> By the way, you can't learn any topic by reading wikipedia. Remember,
> it can be edited by people like you.
>

A function f with domain D is said to be Turing-computable
or just computable if there exists some Turing machine
M = (Q, Σ, Γ, δ, q0, □, F) such that q0 w ⊢* Mqff(w), qf ∈ F
for all w ∈ D (Linz:1990:243)

Begins at start state q0 on input w and transitions to qf as a function
of input w.

We still end up in the same place. A computable function is only
accountable for actual inputs in its domain.

All functions including halt deciders are essentially mappings from
inputs to outputs.

int main() { P(P); } IS NOT AN INPUT THUS OUT-OF-SCOPE.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 2021-12-11 16:10, olcott wrote:
> On 12/11/2021 4:48 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> A halt decider is a decider; which is a type of computable function;
>>> which is a type of function;
>>
>> No.  Several people have tried to explain why this is wrong, but you are
>> still saying it.
>>
>
> You can say that a computable function is not a function and this makes
> as much sense as saying that a dog is not a dog.

No one has claimed that a computable function is not a function. Nor has
anyone claimed that a noncomputable function is not a function.

The claim that has been made is that a Turing Machine is not a function.
Nor is an x86 or C program a function. These are algorithms which
compute a function. An algorithm and the function it computes are *not*
the same thing.

A function is simply a mapping between two sets that meet certain
requirements, namely that each element of the domain maps to only a
single element of the codomain. There is no method associated with a
function; it is simply a mapping between sets.

An algorithm is a *method* for computing a function. It is some purely
mechanical procedure by which we can determine which element of the
codomain each element of the domain maps to.

> *Computable functions* are the basic objects of study in computability
> theory. Computable functions are the formalized analogue of the
> intuitive notion of algorithms, in the sense that a function is
> computable if there exists an algorithm that can do the job of the
> function, i.e. given *an input of the function domain it can return the
> corresponding output* https://en.wikipedia.org/wiki/Computable_function
>
> *Computable functions* only apply to actual inputs in their domain.
> Anything that is not an actual input to a computable function is outside
> of the scope of this function. In typical functional notation an input
> is specified as a list of arguments following the function name: H(P,P)

You're entirely confused here because you refuse to recognize that the
word 'function' as used in mathematics is completely unrelated to the
word 'function' as used by C programmers.

y = 2x is a mathematical function. Here, I'll assume it is a function
over the domain of integers, though a comparable function exists for
reals or other sets of numbers.

This is a computable function, meaning that it is possible to construct
an algorithm for determining the value of y for a given value of x. In
fact, there are numerous different algorithms one can construct as is
true for most computable functions.

The domain of this function is the integers. However, any algorithm,
regardless of whether you're talking about Turing Machines or x86
programs, does *not* accept an integer as its input. It accepts a
*representation* of an integer.

On an x86 machine that will be some string of bits. A string of bits is
*not* an integer; it is a representation. That might be some fixed-width
sequence interpreted as a two's complement value, or, to avoid limiting
the values are algorithm can deal with it might be some unbounded
string, possibly of binary digits, possibly of ASCII digits, possibly of
BCD - Each algorithm might use a different representation. The value
returned by the algorithm also must be represented in some way, and not
necessarily in the same way as the input.

But the crucial thing is that given some representation of some integer
the value it returns must represent that integer multiplied by two.

It does *not* represent 'the input' multiplied by two since a string of
bits isn't a number. A string of bits has no intrinsic interpretation at
all. It makes no sense to talk about the string '1101110101001101'
multiplied by two; only about the integer represented by that string
multiplied by two.

A halt decider is no different. The halting *function* maps the set
computations to yes/no values. A halt *decider* takes an input
representing a computation and either accepts or rejects, but that
decision *must* reflect the computation represented by the input. Then
input string itself is simply a set of symbols with no intrinsic
interpretation. It is only when we interpret those symbols as a
particular computation can we meaningfully ask 'does this halt'?

People frequently talk about a C function (as opposed to a mathematical
function) taking an integer as an input parameter and returning an
integer, but this is just shorthand -- the C function takes a string of
bits which *describes* an integer and returns a string of bits which
describes an integer. The domain of the the function which that C
function computes is still the integers, and the C function is expected
to answer about the integers even though its input parameters are mere
representations. This doesn't somehow put integers 'outside of the
scope' of the algorithm any more than the actual computation P(P) is
'outside the scope' of your halt decider just because its input is a
description rather than an actual computation.

Algorithms necessarily deal with descriptions. But they answer questions
about the things described, not about the descriptions.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

olcott <NoOne@NoWhere.com> writes:

> On 12/11/2021 5:24 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 12/11/2021 4:48 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> A halt decider is a decider; which is a type of computable function;
>>>>> which is a type of function;
>>>>
>>>> No. Several people have tried to explain why this is wrong, but you are
>>>> still saying it.
>>>
>>> You can say that a computable function is not a function and this
>>> makes as much sense as saying that a dog is not a dog.
>>
>> Agreed. So you still don't know which bit is wrong?
>>
>> By the way, you can't learn any topic by reading wikipedia. Remember,
>> it can be edited by people like you.
>
> A function f with domain D is said to be Turing-computable
> or just computable if there exists some Turing machine
> M = (Q, Σ, Γ, δ, q0, □, F) such that q0 w ⊢* Mqff(w), qf ∈ F
> for all w ∈ D (Linz:1990:243)

I've read Linz, thank you. Do you know what was wrong with what you
said yet?

> All functions including halt deciders are essentially mappings from
> inputs to outputs.

There it is again. Can you see it?

--
Ben.

On 12/11/2021 7:38 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 12/11/2021 5:24 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 12/11/2021 4:48 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> A halt decider is a decider; which is a type of computable function;
>>>>>> which is a type of function;
>>>>>
>>>>> No. Several people have tried to explain why this is wrong, but you are
>>>>> still saying it.
>>>>
>>>> You can say that a computable function is not a function and this
>>>> makes as much sense as saying that a dog is not a dog.
>>>
>>> Agreed. So you still don't know which bit is wrong?
>>>
>>> By the way, you can't learn any topic by reading wikipedia. Remember,
>>> it can be edited by people like you.
>>
>> A function f with domain D is said to be Turing-computable
>> or just computable if there exists some Turing machine
>> M = (Q, Σ, Γ, δ, q0, □, F) such that q0 w ⊢* Mqff(w), qf ∈ F
>> for all w ∈ D (Linz:1990:243)
>
> I've read Linz, thank you. Do you know what was wrong with what you
> said yet?
>
>> All functions including halt deciders are essentially mappings from
>> inputs to outputs.
>
> There it is again. Can you see it?
>

The only thing that matters is that a halt decider is only accountable
for the actual behavior of its actual inputs. When we use conventional
functional notation a halt decider is only accountable for its input
parameters specified as a parameter list after its name.

H(P,P) is not accountable for any P(P) anywhere besides its actual input
parameters. If H can CORRECTLY prove that the pure simulation of its
actual input never stops running then H is necessarily correct and
impossibly incorrect when it returns 0 on this input.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 12/11/2021 7:26 PM, André G. Isaak wrote:
> On 2021-12-11 16:10, olcott wrote:
>> On 12/11/2021 4:48 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> A halt decider is a decider; which is a type of computable function;
>>>> which is a type of function;
>>>
>>> No.  Several people have tried to explain why this is wrong, but you are
>>> still saying it.
>>>
>>
>> You can say that a computable function is not a function and this
>> makes as much sense as saying that a dog is not a dog.
>
> No one has claimed that a computable function is not a function. Nor has
> anyone claimed that a noncomputable function is not a function.
>
> The claim that has been made is that a Turing Machine is not a function.
> Nor is an x86 or C program a function. These are algorithms which
> compute a function. An algorithm and the function it computes are *not*
> the same thing.
>
> A function is simply a mapping between two sets that meet certain
> requirements, namely that each element of the domain maps to only a
> single element of the codomain. There is no method associated with a
> function; it is simply a mapping between sets.
>
> An algorithm is a *method* for computing a function. It is some purely
> mechanical procedure by which we can determine which element of the
> codomain each element of the domain maps to.
>
>
>> *Computable functions* are the basic objects of study in computability
>> theory. Computable functions are the formalized analogue of the
>> intuitive notion of algorithms, in the sense that a function is
>> computable if there exists an algorithm that can do the job of the
>> function, i.e. given *an input of the function domain it can return
>> the corresponding output*
>> https://en.wikipedia.org/wiki/Computable_function
>>
>> *Computable functions* only apply to actual inputs in their domain.
>> Anything that is not an actual input to a computable function is
>> outside of the scope of this function. In typical functional notation
>> an input is specified as a list of arguments following the function
>> name: H(P,P)
>
> You're entirely confused here because you refuse to recognize that the
> word 'function' as used in mathematics is completely unrelated to the
> word 'function' as used by C programmers.
>

It does not make any actual difference, this is an entirely extraneous
detail.

A function f with domain D is said to be Turing-computable
or just computable if there exists some Turing machine
M = (Q, Σ, Γ, δ, q0, □, F) such that q0 w ⊢* Mqff(w), qf ∈ F
for all w ∈ D (Linz:1990:243)

Begins at start state q0 on input w and transitions to qf as a function
of input w.

All computable functions are only accountable for their actual inputs.

H(P,P) is not accountable for any P(P) anywhere besides its actual input
parameters. If H can CORRECTLY prove that the pure simulation of its
actual input never stops running then H is necessarily correct and
impossibly incorrect when it returns 0 on this input.

> y = 2x is a mathematical function. Here, I'll assume it is a function
> over the domain of integers, though a comparable function exists for
> reals or other sets of numbers.
>
> This is a computable function, meaning that it is possible to construct
> an algorithm for determining the value of y for a given value of x. In
> fact, there are numerous different algorithms one can construct as is
> true for most computable functions.
>
> The domain of this function is the integers. However, any algorithm,
> regardless of whether you're talking about Turing Machines or x86
> programs, does *not* accept an integer as its input. It accepts a
> *representation* of an integer.
>
> On an x86 machine that will be some string of bits. A string of bits is
> *not* an integer; it is a representation. That might be some fixed-width
> sequence interpreted as a two's complement value, or, to avoid limiting
> the values are algorithm can deal with it might be some unbounded
> string, possibly of binary digits, possibly of ASCII digits, possibly of
> BCD - Each algorithm might use a different representation. The value
> returned by the algorithm also must be represented in some way, and not
> necessarily in the same way as the input.
>
> But the crucial thing is that given some representation of some integer
> the value it returns must represent that integer multiplied by two.
>
> It does *not* represent 'the input' multiplied by two since a string of
> bits isn't a number. A string of bits has no intrinsic interpretation at
> all. It makes no sense to talk about the string '1101110101001101'
> multiplied by two; only about the integer represented by that string
> multiplied by two.
>
> A halt decider is no different. The halting *function* maps the set
> computations to yes/no values. A halt *decider* takes an input
> representing a computation and either accepts or rejects, but that
> decision *must* reflect the computation represented by the input. Then
> input string itself is simply a set of symbols with no intrinsic
> interpretation. It is only when we interpret those symbols as a
> particular computation can we meaningfully ask 'does this halt'?
>
> People frequently talk about a C function (as opposed to a mathematical
> function) taking an integer as an input parameter and returning an
> integer, but this is just shorthand -- the C function takes a string of
> bits which *describes* an integer and returns a string of bits which
> describes an integer. The domain of the the function which that C
> function computes is still the integers, and the C function is expected
> to answer about the integers even though its input parameters are mere
> representations. This doesn't somehow put integers 'outside of the
> scope' of the algorithm any more than the actual computation P(P) is
> 'outside the scope' of your halt decider just because its input is a
> description rather than an actual computation.
>
> Algorithms necessarily deal with descriptions. But they answer questions
> about the things described, not about the descriptions.
>
> André
>

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 12/11/21 6:10 PM, olcott wrote:
> On 12/11/2021 4:48 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> A halt decider is a decider; which is a type of computable function;
>>> which is a type of function;
>>
>> No.  Several people have tried to explain why this is wrong, but you are
>> still saying it.
>>
>
> You can say that a computable function is not a function and this makes
> as much sense as saying that a dog is not a dog.

No, a computable function IS a function (Mathematical). A program is NOT
a function (Mathematical), as they are different kind of things.

A Function (Mathematical) is a MAPPING from one set (the domain) to
another set (the range). It isn't 'steps', it is just a map.

A program is called an ALGORITHM, a step by step set of instructions
that process the input and generate an output.

This process COMPUTES a function, but isn't the function.

If an algorithm exists that takes every input in the domain of a
function and computes the proper result in the domain of that function,
then that algorithm is set to COMPUTE that function and the function is
also called Computable.

Note, the algorithm is not 'the function', it computes the function.

You don't seem to get the difference, you must not understand some word
in it.

>
> *Computable functions* are the basic objects of study in computability
> theory. Computable functions are the formalized analogue of the
> intuitive notion of algorithms, in the sense that a function is
> computable if there exists an algorithm that can do the job of the
> function, i.e. given *an input of the function domain it can return the
> corresponding output* https://en.wikipedia.org/wiki/Computable_function

Again, a function is computable if there exists an algorithm that can do
the job of the function. Not IS the function, but can compute the values
of it.

The Algorithms isn't the Function, it is just an algorithm that can
compute the mapping.

>
> *Computable functions* only apply to actual inputs in their domain.
> Anything that is not an actual input to a computable function is outside
> of the scope of this function. In typical functional notation an input
> is specified as a list of arguments following the function name: H(P,P)
>

On 12/11/21 8:45 PM, olcott wrote:
> On 12/11/2021 7:38 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 12/11/2021 5:24 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 12/11/2021 4:48 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> A halt decider is a decider; which is a type of computable function;
>>>>>>> which is a type of function;
>>>>>>
>>>>>> No.  Several people have tried to explain why this is wrong, but
>>>>>> you are
>>>>>> still saying it.
>>>>>
>>>>> You can say that a computable function is not a function and this
>>>>> makes as much sense as saying that a dog is not a dog.
>>>>
>>>> Agreed.  So you still don't know which bit is wrong?
>>>>
>>>> By the way, you can't learn any topic by reading wikipedia.  Remember,
>>>> it can be edited by people like you.
>>>
>>> A function f with domain D is said to be Turing-computable
>>> or just computable if there exists some Turing machine
>>> M = (Q, Σ, Γ, δ, q0, □, F) such that q0 w ⊢* Mqff(w), qf ∈ F
>>> for all w ∈ D (Linz:1990:243)
>>
>> I've read Linz, thank you.  Do you know what was wrong with what you
>> said yet?
>>
>>> All functions including halt deciders are essentially mappings from
>>> inputs to outputs.
>>
>> There it is again.  Can you see it?
>>
>
> The only thing that matters is that a halt decider is only accountable
> for the actual behavior of its actual inputs. When we use conventional
> functional notation a halt decider is only accountable for its input
> parameters specified as a parameter list after its name.
>

Right, and the input to H(P,P) is the computation P(P), freely run
independent of H. In your system, that means it is called by main,

> H(P,P) is not accountable for any P(P) anywhere besides its actual input
> parameters. If H can CORRECTLY prove that the pure simulation of its
> actual input never stops running then H is necessarily correct and
> impossibly incorrect when it returns 0 on this input.
>

No, because EVERY P(P) does exactly the same thing, or P isn't an actual
algorithm, and the only way that can happen is if H isn't an actual
algorithm.

H can NOT correctly prove that a pure simulation of its input will never
halt and then abort it and return 0, as any H that does abort its
simuation of P(P) creates a P(P) that will halt BECAUSE the H it calls
will return 0 in finite time.

You H makes the UNSOUND argument that effectively presumes that the
H(P,P) inside P will NEVER return 0, which is disproved by the fact that
the outer H(P,P) does abort its simulation and returns 0.

Either H didn't properly simulate its input, or
H used unsound logic, or
H is not an actual algorithm, or
H has some input besides the ones it is allowed.

You keep on waffling in which way H fails to meet its requirements, but
it is clear that H fails at its job.

This is PROVEN by the fact that H(P,P) says 0 (non-halting) but P(P) halts.

You can try to claim that it is a different P(P), but all that means is
you proof is broken because something wasn't done right, as if H does
meet the requriements, then ALL P(P) will behave the same way.

FAIL.

On 12/11/21 8:49 PM, olcott wrote:

> H(P,P) is not accountable for any P(P) anywhere besides its actual input
> parameters. If H can CORRECTLY prove that the pure simulation of its
> actual input never stops running then H is necessarily correct and
> impossibly incorrect when it returns 0 on this input.
>
>

WRONG, as ALL P(P) behave the same. FAIL.

(Or H fails to be the needed computation)

On 12/11/21 4:23 PM, olcott wrote:
> Because it is known to be true that a correct pure simulation of the
> input by the halt decider would demonstrate the actual behavior of this
> input it is known that this is a correct basis for a halt status
> decision by the halt decider.

Your H(P,P) returns 0
A correct pure simulation UTM(P,P) will Halt, since P(P) Halts, and you
agree to that.

Thus, H(P,P) was wrong.

PERIOD.

>
> A simulating halt decider need only perform a pure simulation of N steps
> of its input until:
> (a) Its input halts on its own or
> (b) The simulated behavior of its input correctly matches non-halting
> behavior patterns conclusively proving that a pure simulation of this
> input would never stop running.

Right, a CORRECT non-halting pattern.

P(P) calling H(P,P) is NOT a correct non-halting pattern if H(P,P) will
abort and return 0 on that pattern.

PERIOD. (since that aborting break what could have been an infinite
recursion, but since it was broken it never was one).

>
> [*Olcott 2021 generic halt deciding principle*] Whenever the pure
> simulation of the input to simulating halt decider H(x,y) never stops
> running unless H aborts its simulation H correctly aborts this
> simulation and returns 0 for not halting.
>

WRONG, It doesn't matter if H(x,y) aborts its simulation or not, just if
UTM(x,y) halts. If UTM(x,y) halts BECAUSE x(y) uses H(x,y), and H(x,y)
aborted its simulation, that still means that UTM(x,y) halted and x(y)
is a halting simulation.

You are adding a condition that is NOT part of the defintion of Halting.

FAIL.

> *Computable functions* are the basic objects of study in computability
> theory. Computable functions are the formalized analogue of the
> intuitive notion of algorithms, in the sense that a function is
> computable if there exists an algorithm that can do the job of the
> function, i.e. given *an input of the function domain it can return the
> corresponding output* https://en.wikipedia.org/wiki/Computable_function
>
> A halt decider is a decider; which is a type of computable function;
> which is a type of function; which only applies to its inputs in its
> domain.

LIE.

>
> No function is ever accountable for anything besides input parameters in
> its domain.

Right, and P(P) MUST be in the domain of H or it fails to meet the
requirements. FAIL.

>
> This means that when int main() { P(P); }; has different behavior than
> int main() { H(P,P); }; this does not make any difference at all.
>

But the program int main() { P(P); } is the MEANING of the
representation P,P given to H.

FAIL.

If it isn't, you system isn't defined right. PERIOD.

You are just full of lies to try to work your way around the truth.

FAIL.

>
> *Halting problem undecidability and infinitely nested simulation V2*
> https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2
>
>
>