*Halting problem undecidability and infinitely nested simulation*
When the halt decider bases its halt status decision simulating its
input then the conventional halting problem proof undecidability
counter-example templates can be correctly decided as inputs that never
halt. They will never halt because they specify infinitely nested
simulation to any simulating halt decider.

Because a simulating halt decider must always abort the simulation of
every input that never halts its halt deciding criteria must be adapted.
[ Does the input halt on its input? ] must become [ Does the input halt
without having its simulation aborted? ] This change is required because
every input to a simulating halt decider either halts on its own or
halts because its simulation has been aborted.

The standard pseudo-code halting problem template "proved" that the
halting problem could never be solved on the basis that neither value of
true (halting) nor false (not halting) could be correctly returned to
the confounding input.

// Simplified Linz Ĥ (Linz:1990:319)
void P(u32 x)
{
u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}

int main()
{
u32 Input_Halts = H((u32)P, (u32)P);
Output("Input_Halts = ", Input_Halts);
}

This problem is overcome on the basis that a simulating halt decider
would abort the simulation of its input before ever returning any value
to this input. It aborts the simulation of its input on the basis that
its input specifies what is essentially infinite recursion (infinitely
nested simulation) to any simulating halt decider.

The x86utm operating system was created so that the halting problem
could be examined concretely in the high level language of C and x86.
When examining the halting problem this way every detail can be
explicitly specified. UTM tape elements are 32-bit unsigned integers.

H analyzes the (currently updated) stored execution trace of its x86
emulation of P(P) after it simulates each instruction of input (P, P).
As soon as a non-halting behavior pattern is matched H aborts the
simulation of its input and decides that its input does not halt.

*This is the sound deductive inference (proof) that H(P,P)==0 is correct*

Premise(1) (axiom) Every computation that never halts unless its
simulation is aborted is a computation that never halts. This verified
as true on the basis of the meaning of its words.

Premise(2) (verified fact) The simulation of the input to H(P,P) never
halts without being aborted is a verified fact on the basis of its x86
execution trace. (shown below).

When the simulator determines whether or not it must abort the
simulation of its input based on the behavior of its input the simulator
only acts as an x86 emulator thus has no effect on the behavior of its
input. This allows the simulator to always ignore its own behavior.

Conclusion(3) From the above true premises it necessarily follows that
simulating halt decider H correctly reports that its input: (P,P) never
halts.

Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/3/2021 10:25 AM, wij wrote:
> On Saturday, 3 July 2021 at 23:19:16 UTC+8, olcott wrote:
>> *Halting problem undecidability and infinitely nested simulation*
>> When the halt decider bases its halt status decision simulating its
>> input then the conventional halting problem proof undecidability
>> counter-example templates can be correctly decided as inputs that never
>> halt. They will never halt because they specify infinitely nested
>> simulation to any simulating halt decider.
>>
>> Because a simulating halt decider must always abort the simulation of
>> every input that never halts its halt deciding criteria must be adapted.
>> [ Does the input halt on its input? ] must become [ Does the input halt
>> without having its simulation aborted? ] This change is required because
>> every input to a simulating halt decider either halts on its own or
>> halts because its simulation has been aborted.
>>
>> The standard pseudo-code halting problem template "proved" that the
>> halting problem could never be solved on the basis that neither value of
>> true (halting) nor false (not halting) could be correctly returned to
>> the confounding input.
>>
>> // Simplified Linz Ĥ (Linz:1990:319)
>> void P(u32 x)
>> {
>> u32 Input_Halts = H(x, x);
>> if (Input_Halts)
>> HERE: goto HERE;
>> }
>>
>> int main()
>> {
>> u32 Input_Halts = H((u32)P, (u32)P);
>> Output("Input_Halts = ", Input_Halts);
>> }
>>
>> This problem is overcome on the basis that a simulating halt decider
>> would abort the simulation of its input before ever returning any value
>> to this input. It aborts the simulation of its input on the basis that
>> its input specifies what is essentially infinite recursion (infinitely
>> nested simulation) to any simulating halt decider.
>>
>> The x86utm operating system was created so that the halting problem
>> could be examined concretely in the high level language of C and x86.
>> When examining the halting problem this way every detail can be
>> explicitly specified. UTM tape elements are 32-bit unsigned integers.
>>
>> H analyzes the (currently updated) stored execution trace of its x86
>> emulation of P(P) after it simulates each instruction of input (P, P).
>> As soon as a non-halting behavior pattern is matched H aborts the
>> simulation of its input and decides that its input does not halt.
>>
>> *This is the sound deductive inference (proof) that H(P,P)==0 is correct*
>>
>> Premise(1) (axiom) Every computation that never halts unless its
>> simulation is aborted is a computation that never halts. This verified
>> as true on the basis of the meaning of its words.
>>
>> Premise(2) (verified fact) The simulation of the input to H(P,P) never
>> halts without being aborted is a verified fact on the basis of its x86
>> execution trace. (shown below).
>>
>> When the simulator determines whether or not it must abort the
>> simulation of its input based on the behavior of its input the simulator
>> only acts as an x86 emulator thus has no effect on the behavior of its
>> input. This allows the simulator to always ignore its own behavior.
>>
>> Conclusion(3) From the above true premises it necessarily follows that
>> simulating halt decider H correctly reports that its input: (P,P) never
>> halts.
>>
>>
>>
>>
>> Halting problem undecidability and infinitely nested simulation
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>>
>> --
>> Copyright 2021 Pete Olcott
>>
>> "Great spirits have always encountered violent opposition from mediocre
>> minds." Einstein
>
> In computability theory, the halting problem is the problem of determining, from a description of an arbitrary computer program and an input, whether the program will finish running, or continue to run forever. Alan Turing proved in 1936 that a general algorithm to solve the halting problem for all possible program-input pairs cannot exist.
> https://en.wikipedia.org/wiki/Halting_problem
>

There is a huge gap in the reasoning of the halting problem proofs.
All of the conventional halting problem proofs simply assume that H
must return the correct halt status of P(P) to P. None of these
proofs considered the possibility that a simulating halt decider
would be required to abort its input before ever returning any value
to this input.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/3/2021 10:56 AM, Richard Damon wrote:
> On 7/3/21 11:32 AM, olcott wrote:
>> On 7/3/2021 10:25 AM, wij wrote:
>>>
>>> In computability theory, the halting problem is the problem of
>>> determining, from a description of an arbitrary computer program and
>>> an input, whether the program will finish running, or continue to run
>>> forever. Alan Turing proved in 1936 that a general algorithm to solve
>>> the halting problem for all possible program-input pairs cannot exist.
>>> https://en.wikipedia.org/wiki/Halting_problem
>>>
>>
>> There is a huge gap in the reasoning of the halting problem proofs.
>> All of the conventional halting problem proofs simply assume that H
>> must return the correct halt status of P(P) to P. None of these
>> proofs considered the possibility that a simulating halt decider
>> would be required to abort its input before ever returning any value
>> to this input.
>>
>
> But what does aborting the simulation have to do with returning the
> answer to the caller. THEY ARE DIFFERENT.
>

void P(u32 x)
{ u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}

int main()
{ u32 Input_Halts = H((u32)P, (u32)P);
Output("Input_Halts = ", Input_Halts);
}

When the called is calling H in infinitely nested simulation

IN THE ABOVE C COMPUTATION NOT ANY OTHER COMPUTATION
IN THE ABOVE C COMPUTATION NOT ANY OTHER COMPUTATION
IN THE ABOVE C COMPUTATION NOT ANY OTHER COMPUTATION
IN THE ABOVE C COMPUTATION NOT ANY OTHER COMPUTATION

IN THE ABOVE C COMPUTATION NOT ANY OTHER COMPUTATION
IN THE ABOVE C COMPUTATION NOT ANY OTHER COMPUTATION
IN THE ABOVE C COMPUTATION NOT ANY OTHER COMPUTATION
IN THE ABOVE C COMPUTATION NOT ANY OTHER COMPUTATION

The simulating halt decider H must abort the simulation of its input in
the computation H(P,P) before returning any value to P.

IN THE ABOVE C COMPUTATION NOT ANY OTHER COMPUTATION
IN THE ABOVE C COMPUTATION NOT ANY OTHER COMPUTATION
IN THE ABOVE C COMPUTATION NOT ANY OTHER COMPUTATION
IN THE ABOVE C COMPUTATION NOT ANY OTHER COMPUTATION

IN THE ABOVE C COMPUTATION NOT ANY OTHER COMPUTATION
IN THE ABOVE C COMPUTATION NOT ANY OTHER COMPUTATION
IN THE ABOVE C COMPUTATION NOT ANY OTHER COMPUTATION
IN THE ABOVE C COMPUTATION NOT ANY OTHER COMPUTATION

> You don't seem to be able to understand the fundamental Software
> Engineering concept of execution context.
>
> After H aborts the simulation, it needs to do something. By its
> requriements, it needs to return that answer to its caller.
>

H does return a value of 0 to main(). H does not return any value to the
simulated P that calls H in infinitely nested simulation.

> When it does, it tells that caller that it thinks that P(P) is
> non-Halting, but when it does that to the caller P, that P then halts,
> showing that the answer it gave was wrong.
>

Because a simulating halt decider must always abort the simulation of
every input that never halts its halt deciding criteria must be adapted.

Does the input halt on its input?
must become
Does the input halt without having its simulation aborted?

This change is required because every input to a simulating halt decider
either halts on its own or halts because its simulation has been aborted.

> The FUNDAMENTAL definition of Halting is what the machine does when run
> as a machine with the given input. It is shown that P(P) does Halt (and
> you admit this at times) thus P(P) IS a HALTING computation, by definition.
>

That definition simply ignores simulating halt deciders. The fatal
mistake of the halting problem proofs is they simply ignoring simulating
halt deciders.

> The non-Halting answer is wrong, by definition.
>

The non-halting answer is correct the definition must be adapted.

> Any 'logic' that 'proves' otherwise is by definition wrong or at least
> shows the logic is inconsistent.
>

According to your incorrect reasoning a simulating halt decider must
always report true because all of its inputs either halt own their own
or are aborted.

Because people that are not dumber than a box of rocks do understand
that computations that only halt because they were aborted are
computations that never halt there is agreement that your reasoning is
incorrect.

Ben and Kaz both agree. that computations that only halt because their
simulation was aborted are non-halting computations.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

You are off-topic in comp.lang.c/c++.
Nothing what you say is especially related to C or C++.
Stop posting here.

On 7/3/2021 11:25 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> void P(u32 x)
>> {
>> u32 Input_Halts = H(x, x);
>> if (Input_Halts)
>> HERE: goto HERE;
>> }
>
> For H(P,P) to be correct one of these must apply:
>
> H(P,P) == 0 and P(P) does not halt, or
> H(P,P) != 0 and P(P) halts.
>
> Neither is the case.
>

Superficially it may seem that way until you realize (as you have
already realized) that the halt criteria must be adapted for a
simulating halt decider.

Because a simulating halt decider must always abort the simulation of
every input that never halts its halt deciding criteria must be adapted.

Does the input halt on its input?
must become
Does the input halt without having its simulation aborted?

This change is required because every input to a simulating halt decider
either halts on its own or halts because its simulation has been aborted.

Halting problem undecidability and infinitely nested simulation

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/3/2021 11:28 AM, Bonita Montero wrote:
> You are off-topic in comp.lang.c/c++.
> Nothing what you say is especially related to C or C++.
> Stop posting here.

It is 100% totally related to software engineering in C.
The first 8 pages of my paper are only about software engineering in C.

Halting problem undecidability and infinitely nested simulation

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

> It is 100% totally related to software engineering in C.

It's related to programming in general.
So you shouldn't post in groups related to specific languages.

On 7/3/2021 12:18 PM, Bonita Montero wrote:
>> It is 100% totally related to software engineering in C.
>
> It's related to programming in general.
> So you shouldn't post in groups related to specific languages.
>

It is a specific software engineering problem in the C programming
language. The C source code is provided.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

>>> It is 100% totally related to software engineering in C.
>> It's related to programming in general.
>> So you shouldn't post in groups related to specific languages.

> It is a specific software engineering problem in the C programming
> language. The C source code is provided.

You don't don't discuss any C/C++-specific issues.
comp.theory is the only NG that fits.
Stop posting in comp.lang.c/c++.
You're a off-topic-terrorist.

In article <hKudnUFx1oVw4n39nZ2dnUU7-aPNnZ2d@giganews.com>,
olcott <NoOne@NoWhere.com> wrote:

> Conclusion(3) From the above true premises it necessarily follows that
> simulating halt decider H correctly reports that its input: (P,P) never
> halts.

Number theory conjectures can be written as Turing Machines to
produce a counterexample that halt on a counterexample or do not
halt if the conjecture is true. Assume the halting problem is
decidable, then the conjecture can be decided. But this
contradicts Goedel that number theory has undecidable statements.
Therefore the halting problem is undecidable.

p is prime: P = \p, k. [
k*k>p -> true;
k*k<=p and p mod k = 0 -> false;
k*k<=p and p mod k /= 0 -> P(p, k+1)
]

goldbach conjecture counterexample: E = \n, i, j. [
~P(i, 2) and i<n and j<n -> E(n, i+1, j);
~P(j, 2) and i<n and j<n -> E(n, 2, j+1);
i>=n and j<n -> E(n, 2, j+1);
i>=n and j>=n -> n;
P(i, 2) and P(j, 2) and i<n and j<n and i+j=n -> E(n+2, 2, 2);
P(i, 2) and P(j, 2) and i<n and j<n and i+j/=n -> E(n, i+1, j)
]

goldbach conjecture: G = \.E(4, 2, 2)

Prove G halts.

ob-langc

#include <stdbool.h>
#include <stdio.h>
#include <stdlib.h>

typedef long long unsigned Integer;

static bool P (Integer p) {
Integer k = 2;
for (; k*k<=p; ++k) if (p%k==0) return false;
return true;
}

static void G (void) {
Integer n = 4, i = 2, j = 2;
for (; ;)
if (i>=n && j>=n) {
printf("%llu counterexample\n", n);
return;
}else if (i>=n) i = 2, ++j;
else if (!P(i)) ++i;
else if (!P(j)) i = 2, ++j;
else if (i+j!=n) ++i;
else {
printf("%llu = %llu+%llu\n", n, i, j);
n += 2; i = j = 2;
}
}

int main (int argc, char **argv) {
G(); return 0;
}

--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
Discordia: not just a religion but also a parody. This post / \
I am an Andrea Doria sockpuppet. insults Islam. Mohammed

On 7/3/2021 1:01 PM, Siri Cruise wrote:
> In article <hKudnUFx1oVw4n39nZ2dnUU7-aPNnZ2d@giganews.com>,
> olcott <NoOne@NoWhere.com> wrote:
>
>> Conclusion(3) From the above true premises it necessarily follows that
>> simulating halt decider H correctly reports that its input: (P,P) never
>> halts.
>
> Number theory conjectures can be written as Turing Machines to
> produce a counterexample that halt on a counterexample or do not
> halt if the conjecture is true. Assume the halting problem is
> decidable, then the conjecture can be decided. But this
> contradicts Goedel that number theory has undecidable statements.
> Therefore the halting problem is undecidable.
>
> p is prime: P = \p, k. [
> k*k>p -> true;
> k*k<=p and p mod k = 0 -> false;
> k*k<=p and p mod k /= 0 -> P(p, k+1)
> ]
>
> goldbach conjecture counterexample: E = \n, i, j. [
> ~P(i, 2) and i<n and j<n -> E(n, i+1, j);
> ~P(j, 2) and i<n and j<n -> E(n, 2, j+1);
> i>=n and j<n -> E(n, 2, j+1);
> i>=n and j>=n -> n;
> P(i, 2) and P(j, 2) and i<n and j<n and i+j=n -> E(n+2, 2, 2);
> P(i, 2) and P(j, 2) and i<n and j<n and i+j/=n -> E(n, i+1, j)
> ]
>
> goldbach conjecture: G = \.E(4, 2, 2)
>
> Prove G halts.
>
>
> ob-langc
>
> #include <stdbool.h>
> #include <stdio.h>
> #include <stdlib.h>
>
> typedef long long unsigned Integer;
>
> static bool P (Integer p) {
> Integer k = 2;
> for (; k*k<=p; ++k) if (p%k==0) return false;
> return true;
> }
>
> static void G (void) {
> Integer n = 4, i = 2, j = 2;
> for (; ;)
> if (i>=n && j>=n) {
> printf("%llu counterexample\n", n);
> return;
> }else if (i>=n) i = 2, ++j;
> else if (!P(i)) ++i;
> else if (!P(j)) i = 2, ++j;
> else if (i+j!=n) ++i;
> else {
> printf("%llu = %llu+%llu\n", n, i, j);
> n += 2; i = j = 2;
> }
> }
>
> int main (int argc, char **argv) {
> G(); return 0;
> }
>

The Goldbach conjecture is not undecidable in the conventional sense in
that we know that both {Yes and No} are the wrong answer. The Goldbach
conjecture is undecided and not undecidable.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/3/2021 1:10 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> Ben and Kaz both agree. that computations that only halt because their
>> simulation was aborted are non-halting computations.
>
> I asked you to confirm that:
>
> || Every computation that halts, for whatever reason, is a halting
> || computation.
>
> Your reply: "OK". However you try to equivocate between the various
> meaning of its/their simulation, you can't avoid this obvious fact.
>

On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> Truism:
>> Every simulation that would never stop unless Halts() stops
>> it at some point specifies infinite execution.
>
> Any algorithm that implements this truism is, of course, a halting
> decider.

Because a simulating halt decider must always abort the simulation of
every input that never halts its halt deciding criteria must be adapted.

Does the input halt on its input? must become
Does the input halt without having its simulation aborted?

This change is required because every input to a simulating halt decider
either halts on its own or halts because it has been aborted.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/3/2021 1:17 PM, Richard Damon wrote:
> On 7/3/21 12:49 PM, olcott wrote:
>> On 7/3/2021 11:25 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>>      void P(u32 x)
>>>>      {
>>>>        u32 Input_Halts = H(x, x);
>>>>        if (Input_Halts)
>>>>          HERE: goto HERE;
>>>>      }
>>>
>>> For H(P,P) to be correct one of these must apply:
>>>
>>>    H(P,P) == 0 and P(P) does not halt, or
>>>    H(P,P) != 0 and P(P) halts.
>>>
>>> Neither is the case.
>>>
>>
>> Superficially it may seem that way until you realize (as you have
>> already realized) that the halt criteria must be adapted for a
>> simulating halt decider.
>>
>
> WHY? The standard definition works perfectly fine? Does P(I) Halt or Not
> when it runs.
>
>> Because a simulating halt decider must always abort the simulation of
>> every input that never halts its halt deciding criteria must be adapted.
>
> But it must CORRECTLY halt. As has been shown, H incorrectly aborts the
> simulation of P because it doesn't take into account that this P WILL
> Halt because H does incorrectly halt its simulation.
>>
>> Does the input halt on its input?
>>   must become
>> Does the input halt without having its simulation aborted?
>>
>> This change is required because every input to a simulating halt decider
>> either halts on its own or halts because its simulation has been aborted.
>
> But if it halts because the contained halt decider does abort its own
> simulation of a copy of P, then it IS a halting computation.
>

This may be simply too difficult for you to understand.

When a simulating halt decider only simulates its input until it detects
that its input exhibits non-halting behavior then

We can know that this simulating halt decider has no effect what-so-ever
on the behavior of this input.

This also means that while a simulating halt decider is examining the
behavior of its input it can safely ignore its own behavior.

When this simulating halt decider does detect an infinite execution
behavior pattern then it can correctly stop simulating its input and
report that its input does not halt.

>>
>> Halting problem undecidability and infinitely nested simulation
>>
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>>
>>
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

Siri Cruise <chine.bleu@yahoo.com> writes:

> Number theory conjectures can be written as Turing Machines...

Please consider trimming newsgroups. I've replied (about PO stuff) in
comp.theory where the main points are topical.

> ob-langc

It might be topical, but C without big nums is not very useful for this
sort of thing!

> #include <stdbool.h>
> #include <stdio.h>
> #include <stdlib.h>
>
> typedef long long unsigned Integer;
>
> static bool P (Integer p) {
> Integer k = 2;
> for (; k*k<=p; ++k) if (p%k==0) return false;
> return true;
> }

This function won't always terminate. For example, if p is a prime
close to ULLONG_MAX, k*k will never be > p.

> static void G (void) {
> Integer n = 4, i = 2, j = 2;
> for (; ;)
> if (i>=n && j>=n) {
> printf("%llu counterexample\n", n);
> return;
> }else if (i>=n) i = 2, ++j;
> else if (!P(i)) ++i;
> else if (!P(j)) i = 2, ++j;
> else if (i+j!=n) ++i;
> else {
> printf("%llu = %llu+%llu\n", n, i, j);
> n += 2; i = j = 2;
> }
> }

And if P were correct (and GC true), this loop would just keep testing
all the number in the range of unsigned long long.

> int main (int argc, char **argv) {
> G(); return 0;
> }

--
Ben.

On 7/3/2021 2:43 PM, Richard Damon wrote:
> On 7/3/21 3:08 PM, olcott wrote:
>> On 7/3/2021 1:17 PM, Richard Damon wrote:
>>> On 7/3/21 12:49 PM, olcott wrote:
>>>> On 7/3/2021 11:25 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>>       void P(u32 x)
>>>>>>       {
>>>>>>         u32 Input_Halts = H(x, x);
>>>>>>         if (Input_Halts)
>>>>>>           HERE: goto HERE;
>>>>>>       }
>>>>>
>>>>> For H(P,P) to be correct one of these must apply:
>>>>>
>>>>>     H(P,P) == 0 and P(P) does not halt, or
>>>>>     H(P,P) != 0 and P(P) halts.
>>>>>
>>>>> Neither is the case.
>>>>>
>>>>
>>>> Superficially it may seem that way until you realize (as you have
>>>> already realized) that the halt criteria must be adapted for a
>>>> simulating halt decider.
>>>>
>>>
>>> WHY? The standard definition works perfectly fine? Does P(I) Halt or Not
>>> when it runs.
>>>
>>>> Because a simulating halt decider must always abort the simulation of
>>>> every input that never halts its halt deciding criteria must be adapted.
>>>
>>> But it must CORRECTLY halt. As has been shown, H incorrectly aborts the
>>> simulation of P because it doesn't take into account that this P WILL
>>> Halt because H does incorrectly halt its simulation.
>>>>
>>>> Does the input halt on its input?
>>>>    must become
>>>> Does the input halt without having its simulation aborted?
>>>>
>>>> This change is required because every input to a simulating halt decider
>>>> either halts on its own or halts because its simulation has been
>>>> aborted.
>>>
>>> But if it halts because the contained halt decider does abort its own
>>> simulation of a copy of P, then it IS a halting computation.
>>>
>>
>> This may be simply too difficult for you to understand.
>>
>> When a simulating halt decider only simulates its input until it detects
>> that its input exhibits non-halting behavior then
>>
>> We can know that this simulating halt decider has no effect what-so-ever
>> on the behavior of this input.
>>
>
> Right, but it DOES have an affect on its caller, which you neglect to
> take into account.
>

If a simulating halt decider H ALWAYS merely simulates its input until
it detects that its input matches an infinite execution behavior pattern
then H can always ignore its own behavior when it is analyzing the halt
status of its input.

Even though you have been very very annoying this last couple of message
exchanges were very very helpful in that they forced me to make my
explanations much much more clear. As a result of this I am very
thankful for your reviews.

> Also, until its decision is actually PROVED correct, then the fact that
> it aborted its simulation does not by itself actually prove that the
> decision was correct and the input was actually non-halting.
>

Of course it doesn't

>> This also means that while a simulating halt decider is examining the
>> behavior of its input it can safely ignore its own behavior.
>
> It can ignore 'its own', but not other instances of itself.

It can always ignore it own behavior and it can do this by screening out
machine address ranges to be ignored. H ignores all of its own behavior
and the behavior or every operating system function.

> If is sees a
> copy of itslef (even if the same exact source code executing at the same
> addresses, but in a different execution context). then because that
> decier CAN AND WILL affect the execution of the machine it is simulating
> (the caller of that copy) it MUST include its behavior.
>

It is only the outer-most H that aborts the simulation of its input
(only the outer H has seen the longest execution trace) and it only does
this after its input has totally proven that it is never ever going to
halt unless it is aborted.

> Fundamentally, you are missing the important Software Engineering
> concept of exectution context. The exact same code executing under
> different contexts needs to be considered as different identities.
>

Not at all. It is a verifiable fact that every H only simulates its
input until its input has proven beyond all possible doubt that it is
never ever going to halt unless aborted by some H.

>>
>> When this simulating halt decider does detect an infinite execution
>> behavior pattern then it can correctly stop simulating its input and
>> report that its input does not halt.
>>
>>
> It has INCORRECTLY detected an infinite execution because it has failed
> to take into account the actions of the copy of H within its simulation.
>

void P(u32 x)
{ u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}

There are no copies. There are nested invocations that all share the
same machine code in the same way that recursive invocations share the
same machine code. Nested simulations are really nothing more than a
slightly more complex case of recursive invocation.

> It is starting by ASSUMING that H doesn't abort its simulation. As soon
> as it decides that maybe it should abort its own simulation, it needs to

H only aborts its simulation after it has 100% perfect proof that it must.

> feed that change of condition back into its logic about what it has
> seen. Since it is contemplating aborting its own simulation, it needs to
> take into account that other copies might do the same. Failure to do so
> leads to faulting reasoning and wrong answers.
>

As soon as the input to H meets the infinite recursion criteria H stops
its simulation.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/3/2021 3:09 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> The Goldbach conjecture is not undecidable in the conventional sense
>> in that we know that both {Yes and No} are the wrong answer.
>
> That is not any of the conventional meanings of undecidable.
>
>> The Goldbach conjecture is undecided and not undecidable.
>
> The conjecture may very well be one of the formally undecidable
> propositions about which Gödel wrote in 1931. You most certainly don't
> know whether or not it is undecidable in this conventional sense of the
> word.
>
> You claim to want to write a paper about this. If you can't lean what
> these technical words mean, you won't get very far. And if you can but
> won't it suggests you are not serious.
>

I have to both know exactly what the conventional term of the art of
undecidable means and be able to show exactly how the philosophical
foundation of such a concept is incoherent.

In the mean time knowing the terminology can be side-stepped as long as
I shown exactly how H does get the right answer in the following
computation:

void P(u32 x)
{ u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}

int main()
{ u32 Input_Halts = H((u32)H, (u32)H);
Output("Input_Halts = ", Input_Halts);
}

In the halting problem there exists TM/input pairs such that TM X cannot
return the correct halt status to input I.

Since there is no existing term-of-the-art for this case I will call it
an incorrect question.

An incorrect question Q is
(a) Question / decision problem Q
(b) Posed to (person / TM) X
(c) About (subject matter / input) I
(d) Such that the answer A to Q posed to X about I has no
correct value from the set of {yes,no} / {true,false}

When P asks H whether or not itself will halt on its input neither true
nor false is a correct halt status that H can return to P.

When Bill asks person X that has never been married:
Have you stopped beating your wife?

There is no value from the set {yes, no} that X can provide that
correctly answers Bill's question.

All undecidable decision problems are only "undecidable" because they
are based on incorrect questions.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/3/2021 3:20 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/3/2021 11:25 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> void P(u32 x)
>>>> {
>>>> u32 Input_Halts = H(x, x);
>>>> if (Input_Halts)
>>>> HERE: goto HERE;
>>>> }
>>> For H(P,P) to be correct one of these must apply:
>>>
>>> H(P,P) == 0 and P(P) does not halt, or
>>> H(P,P) != 0 and P(P) halts.
>>>
>>> Neither is the case.
>>
>> Superficially it may seem that way until you realize (as you have
>> already realized) that the halt criteria must be adapted for a
>> simulating halt decider.
>
> The two criteria I gave are for the halting problem. No one is
> interested in your "other kind of halting". It seems you agree that H
> is wrong about the input given above as far as the criterion of actual
> halting goes.
>

Because a simulating halt decider must always abort the simulation of
every input that never halts its halt deciding criteria must be adapted.

Does the input halt on its input?
must become
Does the input halt without having its simulation aborted?

This change is required because every input to a simulating halt decider
either halts on its own or halts because its simulation has been aborted.

Apparently only a simulating halt decider can correctly decide the
otherwise impossible inputs.

If you can significantly help me to get these ideas understood you can
be cited in my paper along with Kaz) as one of my two most important
reviewers. If you are the key to getting these ideas understood and
accepted you will be cited as my most important reviewer.

Whomever is the key to getting these ideas understood and accepted will
be cited as my most important reviewer.

Edsger W. Dijkstra merely wrote a letter to the editor of the CACM and
won the Turing award four years later.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/3/2021 4:58 PM, Richard Damon wrote:
> On 7/3/21 4:37 PM, olcott wrote:
>> On 7/3/2021 2:43 PM, Richard Damon wrote:
>>> On 7/3/21 3:08 PM, olcott wrote:
>>>> On 7/3/2021 1:17 PM, Richard Damon wrote:
>>>>> On 7/3/21 12:49 PM, olcott wrote:
>>>>>> On 7/3/2021 11:25 AM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>>        void P(u32 x)
>>>>>>>>        {
>>>>>>>>          u32 Input_Halts = H(x, x);
>>>>>>>>          if (Input_Halts)
>>>>>>>>            HERE: goto HERE;
>>>>>>>>        }
>>>>>>>
>>>>>>> For H(P,P) to be correct one of these must apply:
>>>>>>>
>>>>>>>      H(P,P) == 0 and P(P) does not halt, or
>>>>>>>      H(P,P) != 0 and P(P) halts.
>>>>>>>
>>>>>>> Neither is the case.
>>>>>>>
>>>>>>
>>>>>> Superficially it may seem that way until you realize (as you have
>>>>>> already realized) that the halt criteria must be adapted for a
>>>>>> simulating halt decider.
>>>>>>
>>>>>
>>>>> WHY? The standard definition works perfectly fine? Does P(I) Halt or
>>>>> Not
>>>>> when it runs.
>>>>>
>>>>>> Because a simulating halt decider must always abort the simulation of
>>>>>> every input that never halts its halt deciding criteria must be
>>>>>> adapted.
>>>>>
>>>>> But it must CORRECTLY halt. As has been shown, H incorrectly aborts the
>>>>> simulation of P because it doesn't take into account that this P WILL
>>>>> Halt because H does incorrectly halt its simulation.
>>>>>>
>>>>>> Does the input halt on its input?
>>>>>>     must become
>>>>>> Does the input halt without having its simulation aborted?
>>>>>>
>>>>>> This change is required because every input to a simulating halt
>>>>>> decider
>>>>>> either halts on its own or halts because its simulation has been
>>>>>> aborted.
>>>>>
>>>>> But if it halts because the contained halt decider does abort its own
>>>>> simulation of a copy of P, then it IS a halting computation.
>>>>>
>>>>
>>>> This may be simply too difficult for you to understand.
>>>>
>>>> When a simulating halt decider only simulates its input until it detects
>>>> that its input exhibits non-halting behavior then
>>>>
>>>> We can know that this simulating halt decider has no effect what-so-ever
>>>> on the behavior of this input.
>>>>
>>>
>>> Right, but it DOES have an affect on its caller, which you neglect to
>>> take into account.
>>>
>>
>> If a simulating halt decider H ALWAYS merely simulates its input until
>> it detects that its input matches an infinite execution behavior pattern
>> then H can always ignore its own behavior when it is analyzing the halt
>> status of its input.
>
> No it can't. Because the fact that H does abort it simulation does
> affect the code that we simulated CALLING that H.
>

No H ever aborts any P until after some P have proved beyond all
possible doubt that it will never halt unless aborted. Until some P does
prove this every H only acts as an x86 emulator and nothing more.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On Sat, 3 Jul 2021 17:20:39 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/3/2021 4:58 PM, Richard Damon wrote:
> > On 7/3/21 4:37 PM, olcott wrote:
> >> On 7/3/2021 2:43 PM, Richard Damon wrote:
> >>> On 7/3/21 3:08 PM, olcott wrote:
> >>>> On 7/3/2021 1:17 PM, Richard Damon wrote:
> >>>>> On 7/3/21 12:49 PM, olcott wrote:
> >>>>>> On 7/3/2021 11:25 AM, Ben Bacarisse wrote:
> >>>>>>> olcott <NoOne@NoWhere.com> writes:
> >>>>>>>
> >>>>>>>>        void P(u32 x)
> >>>>>>>>        {
> >>>>>>>>          u32 Input_Halts = H(x, x);
> >>>>>>>>          if (Input_Halts)
> >>>>>>>>            HERE: goto HERE;
> >>>>>>>>        }
> >>>>>>>
> >>>>>>> For H(P,P) to be correct one of these must apply:
> >>>>>>>
> >>>>>>>      H(P,P) == 0 and P(P) does not halt, or
> >>>>>>>      H(P,P) != 0 and P(P) halts.
> >>>>>>>
> >>>>>>> Neither is the case.
> >>>>>>>
> >>>>>>
> >>>>>> Superficially it may seem that way until you realize (as you
> >>>>>> have already realized) that the halt criteria must be adapted
> >>>>>> for a simulating halt decider.
> >>>>>>
> >>>>>
> >>>>> WHY? The standard definition works perfectly fine? Does P(I)
> >>>>> Halt or Not
> >>>>> when it runs.
> >>>>>
> >>>>>> Because a simulating halt decider must always abort the
> >>>>>> simulation of every input that never halts its halt deciding
> >>>>>> criteria must be adapted.
> >>>>>
> >>>>> But it must CORRECTLY halt. As has been shown, H incorrectly
> >>>>> aborts the simulation of P because it doesn't take into account
> >>>>> that this P WILL Halt because H does incorrectly halt its
> >>>>> simulation.
> >>>>>>
> >>>>>> Does the input halt on its input?
> >>>>>>     must become
> >>>>>> Does the input halt without having its simulation aborted?
> >>>>>>
> >>>>>> This change is required because every input to a simulating
> >>>>>> halt decider
> >>>>>> either halts on its own or halts because its simulation has
> >>>>>> been aborted.
> >>>>>
> >>>>> But if it halts because the contained halt decider does abort
> >>>>> its own simulation of a copy of P, then it IS a halting
> >>>>> computation.
> >>>>
> >>>> This may be simply too difficult for you to understand.
> >>>>
> >>>> When a simulating halt decider only simulates its input until it
> >>>> detects that its input exhibits non-halting behavior then
> >>>>
> >>>> We can know that this simulating halt decider has no effect
> >>>> what-so-ever on the behavior of this input.
> >>>>
> >>>
> >>> Right, but it DOES have an affect on its caller, which you
> >>> neglect to take into account.
> >>>
> >>
> >> If a simulating halt decider H ALWAYS merely simulates its input
> >> until it detects that its input matches an infinite execution
> >> behavior pattern then H can always ignore its own behavior when it
> >> is analyzing the halt status of its input.
> >
> > No it can't. Because the fact that H does abort it simulation does
> > affect the code that we simulated CALLING that H.
> >
>
> No H ever aborts any P until after some P have proved beyond all
> possible doubt that it will never halt unless aborted. Until some P
> does prove this every H only acts as an x86 emulator and nothing more.

But you can only decide it will never halt for uninteresting trivial
cases: until you decider can handle an arbitrary algorithm predicated
on arbitrary program input you've got nothing.

/Flibble

On 7/3/2021 5:57 PM, Mr Flibble wrote:
> On Sat, 3 Jul 2021 17:20:39 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/3/2021 4:58 PM, Richard Damon wrote:
>>> On 7/3/21 4:37 PM, olcott wrote:
>>>> On 7/3/2021 2:43 PM, Richard Damon wrote:
>>>>> On 7/3/21 3:08 PM, olcott wrote:
>>>>>> On 7/3/2021 1:17 PM, Richard Damon wrote:
>>>>>>> On 7/3/21 12:49 PM, olcott wrote:
>>>>>>>> On 7/3/2021 11:25 AM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>>        void P(u32 x)
>>>>>>>>>>        {
>>>>>>>>>>          u32 Input_Halts = H(x, x);
>>>>>>>>>>          if (Input_Halts)
>>>>>>>>>>            HERE: goto HERE;
>>>>>>>>>>        }
>>>>>>>>>
>>>>>>>>> For H(P,P) to be correct one of these must apply:
>>>>>>>>>
>>>>>>>>>      H(P,P) == 0 and P(P) does not halt, or
>>>>>>>>>      H(P,P) != 0 and P(P) halts.
>>>>>>>>>
>>>>>>>>> Neither is the case.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Superficially it may seem that way until you realize (as you
>>>>>>>> have already realized) that the halt criteria must be adapted
>>>>>>>> for a simulating halt decider.
>>>>>>>>
>>>>>>>
>>>>>>> WHY? The standard definition works perfectly fine? Does P(I)
>>>>>>> Halt or Not
>>>>>>> when it runs.
>>>>>>>
>>>>>>>> Because a simulating halt decider must always abort the
>>>>>>>> simulation of every input that never halts its halt deciding
>>>>>>>> criteria must be adapted.
>>>>>>>
>>>>>>> But it must CORRECTLY halt. As has been shown, H incorrectly
>>>>>>> aborts the simulation of P because it doesn't take into account
>>>>>>> that this P WILL Halt because H does incorrectly halt its
>>>>>>> simulation.
>>>>>>>>
>>>>>>>> Does the input halt on its input?
>>>>>>>>     must become
>>>>>>>> Does the input halt without having its simulation aborted?
>>>>>>>>
>>>>>>>> This change is required because every input to a simulating
>>>>>>>> halt decider
>>>>>>>> either halts on its own or halts because its simulation has
>>>>>>>> been aborted.
>>>>>>>
>>>>>>> But if it halts because the contained halt decider does abort
>>>>>>> its own simulation of a copy of P, then it IS a halting
>>>>>>> computation.
>>>>>>
>>>>>> This may be simply too difficult for you to understand.
>>>>>>
>>>>>> When a simulating halt decider only simulates its input until it
>>>>>> detects that its input exhibits non-halting behavior then
>>>>>>
>>>>>> We can know that this simulating halt decider has no effect
>>>>>> what-so-ever on the behavior of this input.
>>>>>>
>>>>>
>>>>> Right, but it DOES have an affect on its caller, which you
>>>>> neglect to take into account.
>>>>>
>>>>
>>>> If a simulating halt decider H ALWAYS merely simulates its input
>>>> until it detects that its input matches an infinite execution
>>>> behavior pattern then H can always ignore its own behavior when it
>>>> is analyzing the halt status of its input.
>>>
>>> No it can't. Because the fact that H does abort it simulation does
>>> affect the code that we simulated CALLING that H.
>>>
>>
>> No H ever aborts any P until after some P have proved beyond all
>> possible doubt that it will never halt unless aborted. Until some P
>> does prove this every H only acts as an x86 emulator and nothing more.
>
> But you can only decide it will never halt for uninteresting trivial
> cases: until you decider can handle an arbitrary algorithm predicated
> on arbitrary program input you've got nothing.
>
> /Flibble
>
>

The same input that you are calling "trivial" is the same input that all
the conventional halting problem proofs call "impossible".

// Simplified Linz Ĥ (Linz:1990:319)
void P(u32 x)
{ u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}

int main()
{ u32 Input_Halts = H((u32)P, (u32)P);
Output("Input_Halts = ", Input_Halts);
}

Halting problem undecidability and infinitely nested simulation

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/3/2021 6:04 PM, Richard Damon wrote:
> On 7/3/21 6:20 PM, olcott wrote:
>> On 7/3/2021 4:58 PM, Richard Damon wrote:
>>> On 7/3/21 4:37 PM, olcott wrote:
>
>>>> If a simulating halt decider H ALWAYS merely simulates its input until
>>>> it detects that its input matches an infinite execution behavior pattern
>>>> then H can always ignore its own behavior when it is analyzing the halt
>>>> status of its input.
>>>
>>> No it can't. Because the fact that H does abort it simulation does
>>> affect the code that we simulated CALLING that H.
>>>
>>
>> No H ever aborts any P until after some P have proved beyond all
>> possible doubt that it will never halt unless aborted. Until some P does
>> prove this every H only acts as an x86 emulator and nothing more.
>>
>>
>
> You CLAIM this, but you actual have no proof that it is.
>
> Your proof shows that unless SOME H abort the chain, not THIS H abort
> the chain.
>

As long as every H only acts as a pure x86 emulator until some P
exhibits behavior that would never halt unless aborted by some H then
entirely on the basis of the meaning of these words when this H (that
sees the never halting behavior) aborts that P it correctly decides that
P does not halt.

I think that you are smart enough to verify that the above reasoning is
correct.

You may not be technically proficient enough to verify that the above
reasoning is indeed the case.

If one is an expert at both C programming and x86 assembly language
programming then the above reasoning can be verified as what is actually
occurring.

It is very easy to see by the execution trace of P compared to the
assembly language source-code of P that H is perfectly simulating P.

Halting problem undecidability and infinitely nested simulation

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/3/2021 7:06 PM, Richard Damon wrote:
> On 7/3/21 7:34 PM, olcott wrote:
>> On 7/3/2021 6:04 PM, Richard Damon wrote:
>>> On 7/3/21 6:20 PM, olcott wrote:
>>>> On 7/3/2021 4:58 PM, Richard Damon wrote:
>>>>> On 7/3/21 4:37 PM, olcott wrote:
>>>
>>>>>> If a simulating halt decider H ALWAYS merely simulates its input until
>>>>>> it detects that its input matches an infinite execution behavior
>>>>>> pattern
>>>>>> then H can always ignore its own behavior when it is analyzing the
>>>>>> halt
>>>>>> status of its input.
>>>>>
>>>>> No it can't. Because the fact that H does abort it simulation does
>>>>> affect the code that we simulated CALLING that H.
>>>>>
>>>>
>>>> No H ever aborts any P until after some P have proved beyond all
>>>> possible doubt that it will never halt unless aborted. Until some P does
>>>> prove this every H only acts as an x86 emulator and nothing more.
>>>>
>>>>
>>>
>>> You CLAIM this, but you actual have no proof that it is.
>>>
>>> Your proof shows that unless SOME H abort the chain, not THIS H abort
>>> the chain.
>>>
>>
>> As long as every H only acts as a pure x86 emulator until some P
>> exhibits behavior that would never halt unless aborted by some H then
>> entirely on the basis of the meaning of these words when this H (that
>> sees the never halting behavior) aborts that P it correctly decides that
>> P does not halt.
>
> That is A FALSE statement by the meaning of the words. SO THERE.
>
> The only instance of H that you can possibly make that claim for is the
> top level H which isn't called by P. Any H that is called by a P because
> its actions DO affect the behavior of that P that calles it, MUST have
> that behavior looked at as it affect the P that the top level H is
> looking at.
>

I went too fast for you. I will break it down to simpler steps.

No H has any effect on any computation what-so-ever until some H
determines that some P would never halt unless aborted.

> PURE MEANING OF THE WORDS.
>
> PROVE OTHERWISE.
>
> Show ANYONE else with a reputation who agrees with your statement.
>
> You confuse the different instances of H and P, and thus come to wrong
> conclusions.
>
>>
>> I think that you are smart enough to verify that the above reasoning is
>> correct.
>>
>> You may not be technically proficient enough to verify that the above
>> reasoning is indeed the case.
>
> YOU are the one not technically proficient enough to understand.
>
> You show ZERO understanding of what a Turing Machine actually is.
> You show ZERO understanding of what Computation Theory is about.
> You show minimal understanding of Software Engineering principles.
>
>>
>> If one is an expert at both C programming and x86 assembly language
>> programming then the above reasoning can be verified as what is actually
>> occurring.
>
> Being one, I say BUNK. You statement is wrong.
>
>>
>> It is very easy to see by the execution trace of P compared to the
>> assembly language source-code of P that H is perfectly simulating P.
>
> You mean you INCORRECT traces?
>
> FAIL.
>
>>
>> Halting problem undecidability and infinitely nested simulation
>>
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>>
>>
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/3/2021 7:23 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/3/2021 3:20 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/3/2021 11:25 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> void P(u32 x)
>>>>>> {
>>>>>> u32 Input_Halts = H(x, x);
>>>>>> if (Input_Halts)
>>>>>> HERE: goto HERE;
>>>>>> }
>>>>> For H(P,P) to be correct one of these must apply:
>>>>>
>>>>> H(P,P) == 0 and P(P) does not halt, or
>>>>> H(P,P) != 0 and P(P) halts.
>>>>>
>>>>> Neither is the case.
>>>>
>>>> Superficially it may seem that way until you realize (as you have
>>>> already realized) that the halt criteria must be adapted for a
>>>> simulating halt decider.
>>>>
>>> The two criteria I gave are for the halting problem. No one is
>>> interested in your "other kind of halting". It seems you agree that H
>>> is wrong about the input given above as far as the criterion of actual
>>> halting goes.
>>
>> Because a simulating halt decider must always abort the simulation of
>> every input that never halts its halt deciding criteria must be
>> adapted.
>
> If you "adapted" the criterion for being a prime number you could
> "refute" many more theorems.
>

You already agreed that this adaptation of the halt status criteria is
correct:

On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> Truism:
>> Every simulation that would never stop unless Halts() stops
>> it at some point specifies infinite execution.
>
> Any algorithm that implements this truism is, of course, a halting
> decider.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/3/2021 9:13 PM, Richard Damon wrote:
> On 7/3/21 9:41 PM, olcott wrote:
>> On 7/3/2021 8:21 PM, Richard Damon wrote:
>>> On 7/3/21 8:26 PM, olcott wrote:
>>>> On 7/3/2021 7:06 PM, Richard Damon wrote:
>>>>> On 7/3/21 7:34 PM, olcott wrote:
>>>>>> On 7/3/2021 6:04 PM, Richard Damon wrote:
>>>>>>> On 7/3/21 6:20 PM, olcott wrote:
>>>>>>>> On 7/3/2021 4:58 PM, Richard Damon wrote:
>>>>>>>>> On 7/3/21 4:37 PM, olcott wrote:
>>>>>>>
>>>>>>>>>> If a simulating halt decider H ALWAYS merely simulates its input
>>>>>>>>>> until
>>>>>>>>>> it detects that its input matches an infinite execution behavior
>>>>>>>>>> pattern
>>>>>>>>>> then H can always ignore its own behavior when it is analyzing the
>>>>>>>>>> halt
>>>>>>>>>> status of its input.
>>>>>>>>>
>>>>>>>>> No it can't. Because the fact that H does abort it simulation does
>>>>>>>>> affect the code that we simulated CALLING that H.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No H ever aborts any P until after some P have proved beyond all
>>>>>>>> possible doubt that it will never halt unless aborted. Until some P
>>>>>>>> does
>>>>>>>> prove this every H only acts as an x86 emulator and nothing more.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> You CLAIM this, but you actual have no proof that it is.
>>>>>>>
>>>>>>> Your proof shows that unless SOME H abort the chain, not THIS H abort
>>>>>>> the chain.
>>>>>>>
>>>>>>
>>>>>> As long as every H only acts as a pure x86 emulator until some P
>>>>>> exhibits behavior that would never halt unless aborted by some H then
>>>>>> entirely on the basis of the meaning of these words when this H (that
>>>>>> sees the never halting behavior) aborts that P it correctly decides
>>>>>> that
>>>>>> P does not halt.
>>>>>
>>>>> That is A FALSE statement by the meaning of the words. SO THERE.
>>>>>
>>>>> The only instance of H that you can possibly make that claim for is the
>>>>> top level H which isn't called by P. Any H that is called by a P
>>>>> because
>>>>> its actions DO affect the behavior of that P that calles it, MUST have
>>>>> that behavior looked at as it affect the P that the top level H is
>>>>> looking at.
>>>>>
>>>>
>>>> I went too fast for you. I will break it down to simpler steps.
>>>>
>>>> No H has any effect on any computation what-so-ever until some H
>>>> determines that some P would never halt unless aborted.
>>>
>>> So, the fact that some H has reached its programmed decision to abort
>>
>> Is 100% totally irrelevant to what I just said.
>> I am ONLY talking about the execution before this point.
>>
>
> If the actual behavior of the system is 100% totally irrelevent to what
> you are saying then THAT'S your problem.
No the problem is that your attention span is very very short so I
cannot possibly expect you to be able to follow more than one single
point at a time.

Do you understand that H cannot possibly have any effect what-so-ever on
the behavior of P until after the behavior of P proves that it will
never halt unless it is aborted?

We cannot move to the next point until AFTER you understand this point.
It usually takes you at least a month to understand one single point
because your mind keeps scattering over many other points not directly
related to this one single point.

I took it as dishonestly it might actually be a neurological abnormality.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/3/2021 10:24 PM, Richard Damon wrote:
> On 7/3/21 10:22 PM, olcott wrote:
>> On 7/3/2021 9:13 PM, Richard Damon wrote:
>>> On 7/3/21 9:41 PM, olcott wrote:
>>>> On 7/3/2021 8:21 PM, Richard Damon wrote:
>>>>> On 7/3/21 8:26 PM, olcott wrote:
>>>>>> On 7/3/2021 7:06 PM, Richard Damon wrote:
>>>>>>> On 7/3/21 7:34 PM, olcott wrote:
>>>>>>>> On 7/3/2021 6:04 PM, Richard Damon wrote:
>>>>>>>>> On 7/3/21 6:20 PM, olcott wrote:
>>>>>>>>>> On 7/3/2021 4:58 PM, Richard Damon wrote:
>>>>>>>>>>> On 7/3/21 4:37 PM, olcott wrote:
>>>>>>>>>
>>>>>>>>>>>> If a simulating halt decider H ALWAYS merely simulates its input
>>>>>>>>>>>> until
>>>>>>>>>>>> it detects that its input matches an infinite execution behavior
>>>>>>>>>>>> pattern
>>>>>>>>>>>> then H can always ignore its own behavior when it is
>>>>>>>>>>>> analyzing the
>>>>>>>>>>>> halt
>>>>>>>>>>>> status of its input.
>>>>>>>>>>>
>>>>>>>>>>> No it can't. Because the fact that H does abort it simulation
>>>>>>>>>>> does
>>>>>>>>>>> affect the code that we simulated CALLING that H.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> No H ever aborts any P until after some P have proved beyond all
>>>>>>>>>> possible doubt that it will never halt unless aborted. Until
>>>>>>>>>> some P
>>>>>>>>>> does
>>>>>>>>>> prove this every H only acts as an x86 emulator and nothing more.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You CLAIM this, but you actual have no proof that it is.
>>>>>>>>>
>>>>>>>>> Your proof shows that unless SOME H abort the chain, not THIS H
>>>>>>>>> abort
>>>>>>>>> the chain.
>>>>>>>>>
>>>>>>>>
>>>>>>>> As long as every H only acts as a pure x86 emulator until some P
>>>>>>>> exhibits behavior that would never halt unless aborted by some H
>>>>>>>> then
>>>>>>>> entirely on the basis of the meaning of these words when this H
>>>>>>>> (that
>>>>>>>> sees the never halting behavior) aborts that P it correctly decides
>>>>>>>> that
>>>>>>>> P does not halt.
>>>>>>>
>>>>>>> That is A FALSE statement by the meaning of the words. SO THERE.
>>>>>>>
>>>>>>> The only instance of H that you can possibly make that claim for
>>>>>>> is the
>>>>>>> top level H which isn't called by P. Any H that is called by a P
>>>>>>> because
>>>>>>> its actions DO affect the behavior of that P that calles it, MUST
>>>>>>> have
>>>>>>> that behavior looked at as it affect the P that the top level H is
>>>>>>> looking at.
>>>>>>>
>>>>>>
>>>>>> I went too fast for you. I will break it down to simpler steps.
>>>>>>
>>>>>> No H has any effect on any computation what-so-ever until some H
>>>>>> determines that some P would never halt unless aborted.
>>>>>
>>>>> So, the fact that some H has reached its programmed decision to abort
>>>>
>>>> Is 100% totally irrelevant to what I just said.
>>>> I am ONLY talking about the execution before this point.
>>>>
>>>
>>> If the actual behavior of the system is 100% totally irrelevent to what
>>> you are saying then THAT'S your problem.
>> No the problem is that your attention span is very very short so I
>> cannot possibly expect you to be able to follow more than one single
>> point at a time.
>
> Maybe my 'problem' is that I see to well and won't let a falsehood go
> past me. Your 'Proof' never gets off the ground, because you insist on
> alwasys starting with false premises that are 'close' to truths, and I
> shut you down before you can try to hide that rotten root.
>
>>
>> Do you understand that H cannot possibly have any effect what-so-ever on
>> the behavior of P until after the behavior of P proves that it will
>> never halt unless it is aborted?
>
> But since H will have an effect on the behavior of the calling P after
> it decides, that effect needs to be considered in 'proving' what it will
> do.

Not really not at all. P has already proved that it will never halt
unless H aborts it. Once P has done this then this proves that the not
halting decision of H is necessarily correct.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein