novaBBS - comp.theory - Re: Olcott [good summation]

Op 17.aug..2022 om 18:46 schreef Mr Flibble:
> Olcott, which of the following do you think is more likely?
>
> 1) Olcott is correct and everybody else is wrong.
> 2) Olcott is wrong and everybody else is correct.
>
> Which one is more likely hasn't changed for all the years you've been
> attempting to shill your simulating halting decider. I find it amusing
> that I came up with, in less than 24 hours, a simulating halting
> decider that doesn't have the flaws your SHD has.
>
> /Flibble
>

I have been following these discussions for many months now. I have a
strong impression that there is little progress. It seems that people
are running in circles. I am not an expert in this field. Maybe it helps
if a non-expert tries to summarize the discussion. Please, be patient
when correcting me if I make any mistake.

First the problem this is al about:
In computation theory we can denote a program with X and its input with
Y, which together is denoted as X(Y). X(Y) may end (halt) in a finite
number of steps, but another program X and/or input Y may not halt in a
finite number of steps. The question is, is it possible to create a
program H that when given any program X with its input Y can tell in a
finite number of steps whether X(Y) halts or not? In other words, will
H(X,Y) always halt after a finite number of steps with the correct
answer for any X and Y?

I hope that this is a correct formulation of the problem.

The classical proof that it is not possible is the idea that it is
always possible to create a program P that uses H, with itself as input,
but behaves opposite to what H returns. In a C-like language it would be
something like:

void P(ptr x)
{ int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

If there would be a hypothetical non-simulating non-aborting H, which
would always halts with the correct answer, then it is clear that there
would be a contradiction if we ask H about P with H(P,P). Because there
are only three possibilities:
1. If H would return true (halting) in a finite number of steps, then P
would start an endless loop, so H(P,P) does not halt in a finite number
of steps.
2. If H would return false (non-halting) in a finite number of steps,
then P returns immediately, so H returns a wrong result.
3. If H does not return, then it does not return in a finite number of
steps, so it is not the H where the problem asked for.

I think everybody agrees up to this point.

Now Olcott has created a simulating aborting H, which, when given P with
input P [so H(P,P)], creates a trace of the execution and at the point
where P calls H, it uses the following logic: If H were the hypothetical
non-aborting H, then an infinite recursion would happen at this point.
Therefore, Olcott's simulating H aborts the simulation and returns false
(0).

Does everybody still agree up to this point?

Now the opinions diverge.
Olcott thinks that his H gives the correct answer that P would not halt
when P would call the hypothetical non-aborting H, so, it must also be
the correct answer when P actually calls the actual aborting H.

Others have a different opinion and argue that P does not call the
hypothetical non-aborting H, but the actual aborting H, which does not
go in infinite recursion, but returns false in a finite number of steps.
Therefore, H's result is wrong.

Is this a correct summary of the disagreement? If not, please, tell me
where the summary failed. Maybe we can then find the point of divergence
of opinions easier.

On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>> Olcott, which of the following do you think is more likely?
>>
>> 1) Olcott is correct and everybody else is wrong.
>> 2) Olcott is wrong and everybody else is correct.
>>
>> Which one is more likely hasn't changed for all the years you've been
>> attempting to shill your simulating halting decider. I find it amusing
>> that I came up with, in less than 24 hours, a simulating halting
>> decider that doesn't have the flaws your SHD has.
>>
>> /Flibble
>>
>
> I have been following these discussions for many months now. I have a
> strong impression that there is little progress. It seems that people
> are running in circles. I am not an expert in this field. Maybe it helps
> if a non-expert tries to summarize the discussion. Please, be patient
> when correcting me if I make any mistake.
>
> First the problem this is al about:
> In computation theory we can denote a program with X and its input with
> Y, which together is denoted as X(Y). X(Y) may end (halt) in a finite
> number of steps, but another program X and/or input Y may not halt in a
> finite number of steps. The question is, is it possible to create a
> program H that when given any program X with its input Y can tell in a
> finite number of steps whether X(Y) halts or not? In other words, will
> H(X,Y) always halt after a finite number of steps with the correct
> answer for any X and Y?
>
> I hope that this is a correct formulation of the problem.
>
> The classical proof that it is not possible is the idea that it is
> always possible to create a program P that uses H, with itself as input,
> but behaves opposite to what H returns. In a C-like language it would be
> something like:
>
> void P(ptr x)
> {
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return;
> }
>
> If there would be a hypothetical non-simulating non-aborting H, which
> would always halts with the correct answer, then it is clear that there
> would be a contradiction if we ask H about P with H(P,P). Because there
> are only three possibilities:
> 1. If H would return true (halting) in a finite number of steps, then P
> would start an endless loop, so H(P,P) does not halt in a finite number
> of steps.
> 2. If H would return false (non-halting) in a finite number of steps,
> then P returns immediately, so H returns a wrong result.
> 3. If H does not return, then it does not return in a finite number of
> steps, so it is not the H where the problem asked for.
>
> I think everybody agrees up to this point.
>
> Now Olcott has created a simulating aborting H, which, when given P with
> input P [so H(P,P)], creates a trace of the execution and at the point
> where P calls H, it uses the following logic: If H were the hypothetical
> non-aborting H, then an infinite recursion would happen at this point.
> Therefore, Olcott's simulating H aborts the simulation and returns false
> (0).
>
> Does everybody still agree up to this point?
>
> Now the opinions diverge.
> Olcott thinks that his H gives the correct answer that P would not halt
> when P would call the hypothetical non-aborting H, so, it must also be
> the correct answer when P actually calls the actual aborting H.
>

*You did a very good job summing this up*
The key nuance of divergence is that halting means that when H(P,P)
correctly simulates its input that this input would reach the "return"
instruction (final state) of P. H(P,P) correctly determines that its
correct simulation of its input would never reach the "return"
instruction of P.

*computation that halts* … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)

When-so-ever the correct partial simulation of a machine description
correctly matches a correct infinite behavior pattern then it is certain
that this machine description specifies infinite behavior.

In other words the SHD decider correctly predicts that its correct and
complete simulation of its input would never reach the final state of
this input.

*HERE IS THE SIMPLEST CASE OF THAT*
void Infinite_Loop()
{ HERE: goto HERE;
}

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

_Infinite_Loop()
[00001102](01) 55 push ebp
[00001103](02) 8bec mov ebp,esp
[00001105](02) ebfe jmp 00001105
[00001107](01) 5d pop ebp
[00001108](01) c3 ret
Size in bytes:(0007) [00001108]

> Others have a different opinion and argue that P does not call the
> hypothetical non-aborting H, but the actual aborting H, which does not
> go in infinite recursion, but returns false in a finite number of steps.
> Therefore, H's result is wrong.
>
> Is this a correct summary of the disagreement? If not, please, tell me
> where the summary failed. Maybe we can then find the point of divergence
> of opinions easier.
>

--
Copyright 2022 Pete Olcott

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

On Sat, 20 Aug 2022 10:23:58 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
> > Op 17.aug..2022 om 18:46 schreef Mr Flibble:
> >> Olcott, which of the following do you think is more likely?
> >>
> >> 1) Olcott is correct and everybody else is wrong.
> >> 2) Olcott is wrong and everybody else is correct.
> >>
> >> Which one is more likely hasn't changed for all the years you've
> >> been attempting to shill your simulating halting decider. I find
> >> it amusing that I came up with, in less than 24 hours, a
> >> simulating halting decider that doesn't have the flaws your SHD
> >> has.
> >>
> >> /Flibble
> >>
> >
> > I have been following these discussions for many months now. I have
> > a strong impression that there is little progress. It seems that
> > people are running in circles. I am not an expert in this field.
> > Maybe it helps if a non-expert tries to summarize the discussion.
> > Please, be patient when correcting me if I make any mistake.
> >
> > First the problem this is al about:
> > In computation theory we can denote a program with X and its input
> > with Y, which together is denoted as X(Y). X(Y) may end (halt) in a
> > finite number of steps, but another program X and/or input Y may
> > not halt in a finite number of steps. The question is, is it
> > possible to create a program H that when given any program X with
> > its input Y can tell in a finite number of steps whether X(Y) halts
> > or not? In other words, will H(X,Y) always halt after a finite
> > number of steps with the correct answer for any X and Y?
> >
> > I hope that this is a correct formulation of the problem.
> >
> > The classical proof that it is not possible is the idea that it is
> > always possible to create a program P that uses H, with itself as
> > input, but behaves opposite to what H returns. In a C-like language
> > it would be something like:
> >
> > void P(ptr x)
> > {
> > int Halt_Status = H(x, x);
> > if (Halt_Status)
> > HERE: goto HERE;
> > return;
> > }
> >
> > If there would be a hypothetical non-simulating non-aborting H,
> > which would always halts with the correct answer, then it is clear
> > that there would be a contradiction if we ask H about P with
> > H(P,P). Because there are only three possibilities:
> > 1. If H would return true (halting) in a finite number of steps,
> > then P would start an endless loop, so H(P,P) does not halt in a
> > finite number of steps.
> > 2. If H would return false (non-halting) in a finite number of
> > steps, then P returns immediately, so H returns a wrong result.
> > 3. If H does not return, then it does not return in a finite number
> > of steps, so it is not the H where the problem asked for.
> >
> > I think everybody agrees up to this point.
> >
> > Now Olcott has created a simulating aborting H, which, when given P
> > with input P [so H(P,P)], creates a trace of the execution and at
> > the point where P calls H, it uses the following logic: If H were
> > the hypothetical non-aborting H, then an infinite recursion would
> > happen at this point. Therefore, Olcott's simulating H aborts the
> > simulation and returns false (0).
> >
> > Does everybody still agree up to this point?
> >
> > Now the opinions diverge.
> > Olcott thinks that his H gives the correct answer that P would not
> > halt when P would call the hypothetical non-aborting H, so, it must
> > also be the correct answer when P actually calls the actual
> > aborting H.
>
> *You did a very good job summing this up*
> The key nuance of divergence is that halting means that when H(P,P)
> correctly simulates its input that this input would reach the
> "return" instruction (final state) of P. H(P,P) correctly determines
> that its correct simulation of its input would never reach the
> "return" instruction of P.
>
> *computation that halts* … the Turing machine will halt whenever it
> enters a final state. (Linz:1990:234)
>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company. (317-320)
>
> When-so-ever the correct partial simulation of a machine description
> correctly matches a correct infinite behavior pattern then it is
> certain that this machine description specifies infinite behavior.
>
> In other words the SHD decider correctly predicts that its correct
> and complete simulation of its input would never reach the final
> state of this input.
>
> *HERE IS THE SIMPLEST CASE OF THAT*
> void Infinite_Loop()
> {
> HERE: goto HERE;
> }

And here is a case where your H gets the answer wrong:

void Px(void (*x)())
{ (void) H(x, x);
return;
}

Px always halts if H returns to Px (and a valid halt decider must
always return a decision to its caller).

/Flibble

On 8/20/22 11:01 AM, Fred. Zwarts wrote:
> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>> Olcott, which of the following do you think is more likely?
>>
>> 1) Olcott is correct and everybody else is wrong.
>> 2) Olcott is wrong and everybody else is correct.
>>
>> Which one is more likely hasn't changed for all the years you've been
>> attempting to shill your simulating halting decider. I find it amusing
>> that I came up with, in less than 24 hours, a simulating halting
>> decider that doesn't have the flaws your SHD has.
>>
>> /Flibble
>>
>
> I have been following these discussions for many months now. I have a
> strong impression that there is little progress. It seems that people
> are running in circles. I am not an expert in this field. Maybe it helps
> if a non-expert tries to summarize the discussion. Please, be patient
> when correcting me if I make any mistake.
>
> First the problem this is al about:
> In computation theory we can denote a program with X and its input with
> Y, which together is denoted as X(Y). X(Y) may end (halt) in a finite
> number of steps, but another program X and/or input Y may not halt in a
> finite number of steps. The question is, is it possible to create a
> program H that when given any program X with its input Y can tell in a
> finite number of steps whether X(Y) halts or not? In other words, will
> H(X,Y) always halt after a finite number of steps with the correct
> answer for any X and Y?
>
> I hope that this is a correct formulation of the problem.
>
> The classical proof that it is not possible is the idea that it is
> always possible to create a program P that uses H, with itself as input,
> but behaves opposite to what H returns. In a C-like language it would be
> something like:
>
> void P(ptr x)
> {
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return;
> }
>
> If there would be a hypothetical non-simulating non-aborting H, which
> would always halts with the correct answer, then it is clear that there
> would be a contradiction if we ask H about P with H(P,P). Because there
> are only three possibilities:
> 1. If H would return true (halting) in a finite number of steps, then P
> would start an endless loop, so H(P,P) does not halt in a finite number
> of steps.
> 2. If H would return false (non-halting) in a finite number of steps,
> then P returns immediately, so H returns a wrong result.
> 3. If H does not return, then it does not return in a finite number of
> steps, so it is not the H where the problem asked for.
>
> I think everybody agrees up to this point.
>
> Now Olcott has created a simulating aborting H, which, when given P with
> input P [so H(P,P)], creates a trace of the execution and at the point
> where P calls H, it uses the following logic: If H were the hypothetical
> non-aborting H, then an infinite recursion would happen at this point.
> Therefore, Olcott's simulating H aborts the simulation and returns false
> (0).
>
> Does everybody still agree up to this point?
>
> Now the opinions diverge.
> Olcott thinks that his H gives the correct answer that P would not halt
> when P would call the hypothetical non-aborting H, so, it must also be
> the correct answer when P actually calls the actual aborting H.
>
> Others have a different opinion and argue that P does not call the
> hypothetical non-aborting H, but the actual aborting H, which does not
> go in infinite recursion, but returns false in a finite number of steps.
> Therefore, H's result is wrong.
>
> Is this a correct summary of the disagreement? If not, please, tell me
> where the summary failed. Maybe we can then find the point of divergence
> of opinions easier.
>

The key point is the conventional proof doesn't assume a
"Non-simulating" decider, but ANY decider, no matter how it determines
its answer.

The key error of Olcott, is the mistaken idea that just because H
happens to be a simulating Halt Decider, it gets to change the criteria
that it needs to decide on, and rather than being does the computation
the input represents [that is M(x) for a call to H(M,x) ], halt or never
halt, but can we decide instead of on a did "H need to abort its
simulation" criteria, and that this "need" affect EVERY COPY of H that
exists in the world. (He confuses that last point by mashing the code of
the decided program and the decider into a single program and having the
decided program share code with the decider instead of being an
independent copy, as it would need to be to actually implement as Turing
Machines.

Because of this, H is actually deciding on the wrong input, the H that
aborts is actually reporting the results of the input program P built on
the H that doesn't abort, which is a different input then the input
program P built on the H that does abort.

On 8/20/2022 1:32 PM, Mr Flibble wrote:
> On Sat, 20 Aug 2022 10:23:58 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>> Olcott, which of the following do you think is more likely?
>>>>
>>>> 1) Olcott is correct and everybody else is wrong.
>>>> 2) Olcott is wrong and everybody else is correct.
>>>>
>>>> Which one is more likely hasn't changed for all the years you've
>>>> been attempting to shill your simulating halting decider. I find
>>>> it amusing that I came up with, in less than 24 hours, a
>>>> simulating halting decider that doesn't have the flaws your SHD
>>>> has.
>>>>
>>>> /Flibble
>>>>
>>>
>>> I have been following these discussions for many months now. I have
>>> a strong impression that there is little progress. It seems that
>>> people are running in circles. I am not an expert in this field.
>>> Maybe it helps if a non-expert tries to summarize the discussion.
>>> Please, be patient when correcting me if I make any mistake.
>>>
>>> First the problem this is al about:
>>> In computation theory we can denote a program with X and its input
>>> with Y, which together is denoted as X(Y). X(Y) may end (halt) in a
>>> finite number of steps, but another program X and/or input Y may
>>> not halt in a finite number of steps. The question is, is it
>>> possible to create a program H that when given any program X with
>>> its input Y can tell in a finite number of steps whether X(Y) halts
>>> or not? In other words, will H(X,Y) always halt after a finite
>>> number of steps with the correct answer for any X and Y?
>>>
>>> I hope that this is a correct formulation of the problem.
>>>
>>> The classical proof that it is not possible is the idea that it is
>>> always possible to create a program P that uses H, with itself as
>>> input, but behaves opposite to what H returns. In a C-like language
>>> it would be something like:
>>>
>>> void P(ptr x)
>>> {
>>> int Halt_Status = H(x, x);
>>> if (Halt_Status)
>>> HERE: goto HERE;
>>> return;
>>> }
>>>
>>> If there would be a hypothetical non-simulating non-aborting H,
>>> which would always halts with the correct answer, then it is clear
>>> that there would be a contradiction if we ask H about P with
>>> H(P,P). Because there are only three possibilities:
>>> 1. If H would return true (halting) in a finite number of steps,
>>> then P would start an endless loop, so H(P,P) does not halt in a
>>> finite number of steps.
>>> 2. If H would return false (non-halting) in a finite number of
>>> steps, then P returns immediately, so H returns a wrong result.
>>> 3. If H does not return, then it does not return in a finite number
>>> of steps, so it is not the H where the problem asked for.
>>>
>>> I think everybody agrees up to this point.
>>>
>>> Now Olcott has created a simulating aborting H, which, when given P
>>> with input P [so H(P,P)], creates a trace of the execution and at
>>> the point where P calls H, it uses the following logic: If H were
>>> the hypothetical non-aborting H, then an infinite recursion would
>>> happen at this point. Therefore, Olcott's simulating H aborts the
>>> simulation and returns false (0).
>>>
>>> Does everybody still agree up to this point?
>>>
>>> Now the opinions diverge.
>>> Olcott thinks that his H gives the correct answer that P would not
>>> halt when P would call the hypothetical non-aborting H, so, it must
>>> also be the correct answer when P actually calls the actual
>>> aborting H.
>>
>> *You did a very good job summing this up*
>> The key nuance of divergence is that halting means that when H(P,P)
>> correctly simulates its input that this input would reach the
>> "return" instruction (final state) of P. H(P,P) correctly determines
>> that its correct simulation of its input would never reach the
>> "return" instruction of P.
>>
>> *computation that halts* … the Turing machine will halt whenever it
>> enters a final state. (Linz:1990:234)
>>
>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>
>> When-so-ever the correct partial simulation of a machine description
>> correctly matches a correct infinite behavior pattern then it is
>> certain that this machine description specifies infinite behavior.
>>
>> In other words the SHD decider correctly predicts that its correct
>> and complete simulation of its input would never reach the final
>> state of this input.
>>
>> *HERE IS THE SIMPLEST CASE OF THAT*
>> void Infinite_Loop()
>> {
>> HERE: goto HERE;
>> }
>
> And here is a case where your H gets the answer wrong:
>
> void Px(void (*x)())
> {
> (void) H(x, x);
> return;
> }
>
> Px always halts if H returns to Px (and a valid halt decider must
> always return a decision to its caller).
>
> /Flibble
>

This one uses my prior version of H named HH where the infinitely
recursive simulation is easier to see.

void Px(void (*x)())
{ (void) HH(x, x);
return;
}

int main()
{ Output("Input_Halts = ", HH(Px, Px));
}

_Px()
[000010b2](01) 55 push ebp
[000010b3](02) 8bec mov ebp,esp
[000010b5](03) 8b4508 mov eax,[ebp+08]
[000010b8](01) 50 push eax
[000010b9](03) 8b4d08 mov ecx,[ebp+08]
[000010bc](01) 51 push ecx
[000010bd](05) e8e0fbffff call 00000ca2
[000010c2](03) 83c408 add esp,+08
[000010c5](01) 5d pop ebp
[000010c6](01) c3 ret
Size in bytes:(0021) [000010c6]

_main()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](05) 68b2100000 push 000010b2
[000010da](05) 68b2100000 push 000010b2
[000010df](05) e8befbffff call 00000ca2
[000010e4](03) 83c408 add esp,+08
[000010e7](01) 50 push eax
[000010e8](05) 6863040000 push 00000463
[000010ed](05) e890f3ffff call 00000482
[000010f2](03) 83c408 add esp,+08
[000010f5](02) 33c0 xor eax,eax
[000010f7](01) 5d pop ebp
[000010f8](01) c3 ret
Size in bytes:(0039) [000010f8]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000010d2][00101b8d][00000000] 55 push ebp
[000010d3][00101b8d][00000000] 8bec mov ebp,esp
[000010d5][00101b89][000010b2] 68b2100000 push 000010b2
[000010da][00101b85][000010b2] 68b2100000 push 000010b2
[000010df][00101b81][000010e4] e8befbffff call 00000ca2
New slave_stack at:101c31

Begin Local Halt Decider Simulation Execution Trace Stored at:111c39
[000010b2][00111c25][00111c29] 55 push ebp
[000010b3][00111c25][00111c29] 8bec mov ebp,esp
[000010b5][00111c25][00111c29] 8b4508 mov eax,[ebp+08]
[000010b8][00111c21][000010b2] 50 push eax // push Px
[000010b9][00111c21][000010b2] 8b4d08 mov ecx,[ebp+08]
[000010bc][00111c1d][000010b2] 51 push ecx // push Px
[000010bd][00111c19][000010c2] e8e0fbffff call 00000ca2 // call HH
New slave_stack at:14c659
[000010b2][0015c64d][0015c651] 55 push ebp
[000010b3][0015c64d][0015c651] 8bec mov ebp,esp
[000010b5][0015c64d][0015c651] 8b4508 mov eax,[ebp+08]
[000010b8][0015c649][000010b2] 50 push eax // push Px
[000010b9][0015c649][000010b2] 8b4d08 mov ecx,[ebp+08]
[000010bc][0015c645][000010b2] 51 push ecx // push Px
[000010bd][0015c641][000010c2] e8e0fbffff call 00000ca2 // call HH
*Local Halt Decider: Infinite Recursion Detected Simulation Stopped*

*When HH(Px,Px) simulates its input it sees that*
(1) Function HH(Px,Px) is called twice in sequence from the same machine
address of Px().
(2) With the same arguments to HH(Px,Px).
(3) With no control flow instructions between the invocation of Px() and
its call to HH(Px,Px) that could possibly escape repeated simulations.

[000010e4][00101b8d][00000000] 83c408 add esp,+08
[000010e7][00101b89][00000000] 50 push eax
[000010e8][00101b85][00000463] 6863040000 push 00000463
[000010ed][00101b85][00000463] e890f3ffff call 00000482
Input_Halts = 0
[000010f2][00101b8d][00000000] 83c408 add esp,+08
[000010f5][00101b8d][00000000] 33c0 xor eax,eax
[000010f7][00101b91][00000018] 5d pop ebp
[000010f8][00101b95][00000000] c3 ret
Number of Instructions Executed(15322) == 229 Pages

Click here to read the complete article

On Sat, 20 Aug 2022 13:50:15 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 8/20/2022 1:32 PM, Mr Flibble wrote:
> > On Sat, 20 Aug 2022 10:23:58 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
> >>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
> >>>> Olcott, which of the following do you think is more likely?
> >>>>
> >>>> 1) Olcott is correct and everybody else is wrong.
> >>>> 2) Olcott is wrong and everybody else is correct.
> >>>>
> >>>> Which one is more likely hasn't changed for all the years you've
> >>>> been attempting to shill your simulating halting decider. I find
> >>>> it amusing that I came up with, in less than 24 hours, a
> >>>> simulating halting decider that doesn't have the flaws your SHD
> >>>> has.
> >>>>
> >>>> /Flibble
> >>>>
> >>>
> >>> I have been following these discussions for many months now. I
> >>> have a strong impression that there is little progress. It seems
> >>> that people are running in circles. I am not an expert in this
> >>> field. Maybe it helps if a non-expert tries to summarize the
> >>> discussion. Please, be patient when correcting me if I make any
> >>> mistake.
> >>>
> >>> First the problem this is al about:
> >>> In computation theory we can denote a program with X and its input
> >>> with Y, which together is denoted as X(Y). X(Y) may end (halt) in
> >>> a finite number of steps, but another program X and/or input Y may
> >>> not halt in a finite number of steps. The question is, is it
> >>> possible to create a program H that when given any program X with
> >>> its input Y can tell in a finite number of steps whether X(Y)
> >>> halts or not? In other words, will H(X,Y) always halt after a
> >>> finite number of steps with the correct answer for any X and Y?
> >>>
> >>> I hope that this is a correct formulation of the problem.
> >>>
> >>> The classical proof that it is not possible is the idea that it is
> >>> always possible to create a program P that uses H, with itself as
> >>> input, but behaves opposite to what H returns. In a C-like
> >>> language it would be something like:
> >>>
> >>> void P(ptr x)
> >>> {
> >>> int Halt_Status = H(x, x);
> >>> if (Halt_Status)
> >>> HERE: goto HERE;
> >>> return;
> >>> }
> >>>
> >>> If there would be a hypothetical non-simulating non-aborting H,
> >>> which would always halts with the correct answer, then it is clear
> >>> that there would be a contradiction if we ask H about P with
> >>> H(P,P). Because there are only three possibilities:
> >>> 1. If H would return true (halting) in a finite number of steps,
> >>> then P would start an endless loop, so H(P,P) does not halt in a
> >>> finite number of steps.
> >>> 2. If H would return false (non-halting) in a finite number of
> >>> steps, then P returns immediately, so H returns a wrong result.
> >>> 3. If H does not return, then it does not return in a finite
> >>> number of steps, so it is not the H where the problem asked for.
> >>>
> >>> I think everybody agrees up to this point.
> >>>
> >>> Now Olcott has created a simulating aborting H, which, when given
> >>> P with input P [so H(P,P)], creates a trace of the execution and
> >>> at the point where P calls H, it uses the following logic: If H
> >>> were the hypothetical non-aborting H, then an infinite recursion
> >>> would happen at this point. Therefore, Olcott's simulating H
> >>> aborts the simulation and returns false (0).
> >>>
> >>> Does everybody still agree up to this point?
> >>>
> >>> Now the opinions diverge.
> >>> Olcott thinks that his H gives the correct answer that P would not
> >>> halt when P would call the hypothetical non-aborting H, so, it
> >>> must also be the correct answer when P actually calls the actual
> >>> aborting H.
> >>
> >> *You did a very good job summing this up*
> >> The key nuance of divergence is that halting means that when H(P,P)
> >> correctly simulates its input that this input would reach the
> >> "return" instruction (final state) of P. H(P,P) correctly
> >> determines that its correct simulation of its input would never
> >> reach the "return" instruction of P.
> >>
> >> *computation that halts* … the Turing machine will halt whenever it
> >> enters a final state. (Linz:1990:234)
> >>
> >> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> >> Lexington/Toronto: D. C. Heath and Company. (317-320)
> >>
> >> When-so-ever the correct partial simulation of a machine
> >> description correctly matches a correct infinite behavior pattern
> >> then it is certain that this machine description specifies
> >> infinite behavior.
> >>
> >> In other words the SHD decider correctly predicts that its correct
> >> and complete simulation of its input would never reach the final
> >> state of this input.
> >>
> >> *HERE IS THE SIMPLEST CASE OF THAT*
> >> void Infinite_Loop()
> >> {
> >> HERE: goto HERE;
> >> }
> >
> > And here is a case where your H gets the answer wrong:
> >
> > void Px(void (*x)())
> > {
> > (void) H(x, x);
> > return;
> > }
> >
> > Px always halts if H returns to Px (and a valid halt decider must
> > always return a decision to its caller).
> >
> > /Flibble
> >
>
>
> This one uses my prior version of H named HH where the infinitely
> recursive simulation is easier to see.
>
> void Px(void (*x)())
> {
> (void) HH(x, x);
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", HH(Px, Px));
> }
>
> _Px()
> [000010b2](01) 55 push ebp
> [000010b3](02) 8bec mov ebp,esp
> [000010b5](03) 8b4508 mov eax,[ebp+08]
> [000010b8](01) 50 push eax
> [000010b9](03) 8b4d08 mov ecx,[ebp+08]
> [000010bc](01) 51 push ecx
> [000010bd](05) e8e0fbffff call 00000ca2
> [000010c2](03) 83c408 add esp,+08
> [000010c5](01) 5d pop ebp
> [000010c6](01) c3 ret
> Size in bytes:(0021) [000010c6]
>
> _main()
> [000010d2](01) 55 push ebp
> [000010d3](02) 8bec mov ebp,esp
> [000010d5](05) 68b2100000 push 000010b2
> [000010da](05) 68b2100000 push 000010b2
> [000010df](05) e8befbffff call 00000ca2
> [000010e4](03) 83c408 add esp,+08
> [000010e7](01) 50 push eax
> [000010e8](05) 6863040000 push 00000463
> [000010ed](05) e890f3ffff call 00000482
> [000010f2](03) 83c408 add esp,+08
> [000010f5](02) 33c0 xor eax,eax
> [000010f7](01) 5d pop ebp
> [000010f8](01) c3 ret
> Size in bytes:(0039) [000010f8]
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= ============> [000010d2][00101b8d][00000000] 55 push ebp
> [000010d3][00101b8d][00000000] 8bec mov ebp,esp
> [000010d5][00101b89][000010b2] 68b2100000 push 000010b2
> [000010da][00101b85][000010b2] 68b2100000 push 000010b2
> [000010df][00101b81][000010e4] e8befbffff call 00000ca2
> New slave_stack at:101c31
>
> Begin Local Halt Decider Simulation Execution Trace Stored at:111c39
> [000010b2][00111c25][00111c29] 55 push ebp
> [000010b3][00111c25][00111c29] 8bec mov ebp,esp
> [000010b5][00111c25][00111c29] 8b4508 mov eax,[ebp+08]
> [000010b8][00111c21][000010b2] 50 push eax // push
> Px [000010b9][00111c21][000010b2] 8b4d08 mov ecx,[ebp+08]
> [000010bc][00111c1d][000010b2] 51 push ecx // push
> Px [000010bd][00111c19][000010c2] e8e0fbffff call 00000ca2 //
> call HH New slave_stack at:14c659
> [000010b2][0015c64d][0015c651] 55 push ebp
> [000010b3][0015c64d][0015c651] 8bec mov ebp,esp
> [000010b5][0015c64d][0015c651] 8b4508 mov eax,[ebp+08]
> [000010b8][0015c649][000010b2] 50 push eax // push
> Px [000010b9][0015c649][000010b2] 8b4d08 mov ecx,[ebp+08]
> [000010bc][0015c645][000010b2] 51 push ecx // push
> Px [000010bd][0015c641][000010c2] e8e0fbffff call 00000ca2 //
> call HH *Local Halt Decider: Infinite Recursion Detected Simulation
> Stopped*
>
> *When HH(Px,Px) simulates its input it sees that*
> (1) Function HH(Px,Px) is called twice in sequence from the same
> machine address of Px().
> (2) With the same arguments to HH(Px,Px).
> (3) With no control flow instructions between the invocation of Px()
> and its call to HH(Px,Px) that could possibly escape repeated
> simulations.
>
> [000010e4][00101b8d][00000000] 83c408 add esp,+08
> [000010e7][00101b89][00000000] 50 push eax
> [000010e8][00101b85][00000463] 6863040000 push 00000463
> [000010ed][00101b85][00000463] e890f3ffff call 00000482
> Input_Halts = 0
> [000010f2][00101b8d][00000000] 83c408 add esp,+08
> [000010f5][00101b8d][00000000] 33c0 xor eax,eax
> [000010f7][00101b91][00000018] 5d pop ebp
> [000010f8][00101b95][00000000] c3 ret
> Number of Instructions Executed(15322) == 229 Pages

Click here to read the complete article

On 8/20/2022 1:32 PM, Richard Damon wrote:
> On 8/20/22 11:01 AM, Fred. Zwarts wrote:
>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>> Olcott, which of the following do you think is more likely?
>>>
>>> 1) Olcott is correct and everybody else is wrong.
>>> 2) Olcott is wrong and everybody else is correct.
>>>
>>> Which one is more likely hasn't changed for all the years you've been
>>> attempting to shill your simulating halting decider. I find it amusing
>>> that I came up with, in less than 24 hours, a simulating halting
>>> decider that doesn't have the flaws your SHD has.
>>>
>>> /Flibble
>>>
>>
>> I have been following these discussions for many months now. I have a
>> strong impression that there is little progress. It seems that people
>> are running in circles. I am not an expert in this field. Maybe it
>> helps if a non-expert tries to summarize the discussion. Please, be
>> patient when correcting me if I make any mistake.
>>
>> First the problem this is al about:
>> In computation theory we can denote a program with X and its input
>> with Y, which together is denoted as X(Y). X(Y) may end (halt) in a
>> finite number of steps, but another program X and/or input Y may not
>> halt in a finite number of steps. The question is, is it possible to
>> create a program H that when given any program X with its input Y can
>> tell in a finite number of steps whether X(Y) halts or not? In other
>> words, will H(X,Y) always halt after a finite number of steps with the
>> correct answer for any X and Y?
>>
>> I hope that this is a correct formulation of the problem.
>>
>> The classical proof that it is not possible is the idea that it is
>> always possible to create a program P that uses H, with itself as
>> input, but behaves opposite to what H returns. In a C-like language it
>> would be something like:
>>
>> void P(ptr x)
>> {
>>    int Halt_Status = H(x, x);
>>    if (Halt_Status)
>>      HERE: goto HERE;
>>    return;
>> }
>>
>> If there would be a hypothetical non-simulating non-aborting H, which
>> would always halts with the correct answer, then it is clear that
>> there would be a contradiction if we ask H about P with H(P,P).
>> Because there are only three possibilities:
>> 1. If H would return true (halting) in a finite number of steps, then
>> P would start an endless loop, so H(P,P) does not halt in a finite
>> number of steps.
>> 2. If H would return false (non-halting) in a finite number of steps,
>> then P returns immediately, so H returns a wrong result.
>> 3. If H does not return, then it does not return in a finite number of
>> steps, so it is not the H where the problem asked for.
>>
>> I think everybody agrees up to this point.
>>
>> Now Olcott has created a simulating aborting H, which, when given P
>> with input P [so H(P,P)], creates a trace of the execution and at the
>> point where P calls H, it uses the following logic: If H were the
>> hypothetical non-aborting H, then an infinite recursion would happen
>> at this point. Therefore, Olcott's simulating H aborts the simulation
>> and returns false (0).
>>
>> Does everybody still agree up to this point?
>>
>> Now the opinions diverge.
>> Olcott thinks that his H gives the correct answer that P would not
>> halt when P would call the hypothetical non-aborting H, so, it must
>> also be the correct answer when P actually calls the actual aborting H.
>>
>> Others have a different opinion and argue that P does not call the
>> hypothetical non-aborting H, but the actual aborting H, which does not
>> go in infinite recursion, but returns false in a finite number of
>> steps. Therefore, H's result is wrong.
>>
>> Is this a correct summary of the disagreement? If not, please, tell me
>> where the summary failed. Maybe we can then find the point of
>> divergence of opinions easier.
>>
>
> The key point is the conventional proof doesn't assume a
> "Non-simulating" decider, but ANY decider, no matter how it determines
> its answer.
>
> The key error of Olcott, is the mistaken idea that just because H
> happens to be a simulating Halt Decider, it gets to change the criteria
> that it needs to decide on, and rather than being does the computation
> the input represents [that is M(x) for a call to H(M,x) ], halt or never
> halt, but can we decide instead of on a did "H need to abort its
> simulation" criteria, and that this "need" affect EVERY COPY of H that
> exists in the world. (He confuses that last point by mashing the code of
> the decided program and the decider into a single program and having the
> decided program share code with the decider instead of being an
> independent copy, as it would need to be to actually implement as Turing
> Machines.
>
> Because of this, H is actually deciding on the wrong input, the H that
> aborts is actually reporting the results of the input program P built on
> the H that doesn't abort, which is a different input then the input
> program P built on the H that does abort.

It is common knowledge that the correct and complete simulation of a
machine description always provides the actual behavior specified by
this machine description.

That you and others reject this when it is applied to my simulating halt
decider implicitly rejects the notion of a UTM. Since you and others do
accept the notion of a UTM, I have just proven that your reasoning is
incoherent and/or inconsistent.

Whenever the simulating halt decider correctly predicts that its correct
and complete simulation of its input would never reach the final state
of this input, then the SHD is correct to reject its input as non-halting.

*HERE IS THE SIMPLEST CASE OF THAT*
void Infinite_Loop()
{ HERE: goto HERE;
}

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

_Infinite_Loop()
[00001102](01) 55 push ebp
[00001103](02) 8bec mov ebp,esp
[00001105](02) ebfe jmp 00001105
[00001107](01) 5d pop ebp
[00001108](01) c3 ret
Size in bytes:(0007) [00001108]

--
Copyright 2022 Pete Olcott

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

On 8/20/2022 1:52 PM, Mr Flibble wrote:
> On Sat, 20 Aug 2022 13:50:15 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 8/20/2022 1:32 PM, Mr Flibble wrote:
>>> On Sat, 20 Aug 2022 10:23:58 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
>>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>>>> Olcott, which of the following do you think is more likely?
>>>>>>
>>>>>> 1) Olcott is correct and everybody else is wrong.
>>>>>> 2) Olcott is wrong and everybody else is correct.
>>>>>>
>>>>>> Which one is more likely hasn't changed for all the years you've
>>>>>> been attempting to shill your simulating halting decider. I find
>>>>>> it amusing that I came up with, in less than 24 hours, a
>>>>>> simulating halting decider that doesn't have the flaws your SHD
>>>>>> has.
>>>>>>
>>>>>> /Flibble
>>>>>>
>>>>>
>>>>> I have been following these discussions for many months now. I
>>>>> have a strong impression that there is little progress. It seems
>>>>> that people are running in circles. I am not an expert in this
>>>>> field. Maybe it helps if a non-expert tries to summarize the
>>>>> discussion. Please, be patient when correcting me if I make any
>>>>> mistake.
>>>>>
>>>>> First the problem this is al about:
>>>>> In computation theory we can denote a program with X and its input
>>>>> with Y, which together is denoted as X(Y). X(Y) may end (halt) in
>>>>> a finite number of steps, but another program X and/or input Y may
>>>>> not halt in a finite number of steps. The question is, is it
>>>>> possible to create a program H that when given any program X with
>>>>> its input Y can tell in a finite number of steps whether X(Y)
>>>>> halts or not? In other words, will H(X,Y) always halt after a
>>>>> finite number of steps with the correct answer for any X and Y?
>>>>>
>>>>> I hope that this is a correct formulation of the problem.
>>>>>
>>>>> The classical proof that it is not possible is the idea that it is
>>>>> always possible to create a program P that uses H, with itself as
>>>>> input, but behaves opposite to what H returns. In a C-like
>>>>> language it would be something like:
>>>>>
>>>>> void P(ptr x)
>>>>> {
>>>>> int Halt_Status = H(x, x);
>>>>> if (Halt_Status)
>>>>> HERE: goto HERE;
>>>>> return;
>>>>> }
>>>>>
>>>>> If there would be a hypothetical non-simulating non-aborting H,
>>>>> which would always halts with the correct answer, then it is clear
>>>>> that there would be a contradiction if we ask H about P with
>>>>> H(P,P). Because there are only three possibilities:
>>>>> 1. If H would return true (halting) in a finite number of steps,
>>>>> then P would start an endless loop, so H(P,P) does not halt in a
>>>>> finite number of steps.
>>>>> 2. If H would return false (non-halting) in a finite number of
>>>>> steps, then P returns immediately, so H returns a wrong result.
>>>>> 3. If H does not return, then it does not return in a finite
>>>>> number of steps, so it is not the H where the problem asked for.
>>>>>
>>>>> I think everybody agrees up to this point.
>>>>>
>>>>> Now Olcott has created a simulating aborting H, which, when given
>>>>> P with input P [so H(P,P)], creates a trace of the execution and
>>>>> at the point where P calls H, it uses the following logic: If H
>>>>> were the hypothetical non-aborting H, then an infinite recursion
>>>>> would happen at this point. Therefore, Olcott's simulating H
>>>>> aborts the simulation and returns false (0).
>>>>>
>>>>> Does everybody still agree up to this point?
>>>>>
>>>>> Now the opinions diverge.
>>>>> Olcott thinks that his H gives the correct answer that P would not
>>>>> halt when P would call the hypothetical non-aborting H, so, it
>>>>> must also be the correct answer when P actually calls the actual
>>>>> aborting H.
>>>>
>>>> *You did a very good job summing this up*
>>>> The key nuance of divergence is that halting means that when H(P,P)
>>>> correctly simulates its input that this input would reach the
>>>> "return" instruction (final state) of P. H(P,P) correctly
>>>> determines that its correct simulation of its input would never
>>>> reach the "return" instruction of P.
>>>>
>>>> *computation that halts* … the Turing machine will halt whenever it
>>>> enters a final state. (Linz:1990:234)
>>>>
>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>
>>>> When-so-ever the correct partial simulation of a machine
>>>> description correctly matches a correct infinite behavior pattern
>>>> then it is certain that this machine description specifies
>>>> infinite behavior.
>>>>
>>>> In other words the SHD decider correctly predicts that its correct
>>>> and complete simulation of its input would never reach the final
>>>> state of this input.
>>>>
>>>> *HERE IS THE SIMPLEST CASE OF THAT*
>>>> void Infinite_Loop()
>>>> {
>>>> HERE: goto HERE;
>>>> }
>>>
>>> And here is a case where your H gets the answer wrong:
>>>
>>> void Px(void (*x)())
>>> {
>>> (void) H(x, x);
>>> return;
>>> }
>>>
>>> Px always halts if H returns to Px (and a valid halt decider must
>>> always return a decision to its caller).
>>>
>>> /Flibble
>>>
>>
>>
>> This one uses my prior version of H named HH where the infinitely
>> recursive simulation is easier to see.
>>
>> void Px(void (*x)())
>> {
>> (void) HH(x, x);
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", HH(Px, Px));
>> }
>>
>> _Px()
>> [000010b2](01) 55 push ebp
>> [000010b3](02) 8bec mov ebp,esp
>> [000010b5](03) 8b4508 mov eax,[ebp+08]
>> [000010b8](01) 50 push eax
>> [000010b9](03) 8b4d08 mov ecx,[ebp+08]
>> [000010bc](01) 51 push ecx
>> [000010bd](05) e8e0fbffff call 00000ca2
>> [000010c2](03) 83c408 add esp,+08
>> [000010c5](01) 5d pop ebp
>> [000010c6](01) c3 ret
>> Size in bytes:(0021) [000010c6]
>>
>> _main()
>> [000010d2](01) 55 push ebp
>> [000010d3](02) 8bec mov ebp,esp
>> [000010d5](05) 68b2100000 push 000010b2
>> [000010da](05) 68b2100000 push 000010b2
>> [000010df](05) e8befbffff call 00000ca2
>> [000010e4](03) 83c408 add esp,+08
>> [000010e7](01) 50 push eax
>> [000010e8](05) 6863040000 push 00000463
>> [000010ed](05) e890f3ffff call 00000482
>> [000010f2](03) 83c408 add esp,+08
>> [000010f5](02) 33c0 xor eax,eax
>> [000010f7](01) 5d pop ebp
>> [000010f8](01) c3 ret
>> Size in bytes:(0039) [000010f8]
>>
>> machine stack stack machine assembly
>> address address data code language
>> ======== ======== ======== ========= =============
>> [000010d2][00101b8d][00000000] 55 push ebp
>> [000010d3][00101b8d][00000000] 8bec mov ebp,esp
>> [000010d5][00101b89][000010b2] 68b2100000 push 000010b2
>> [000010da][00101b85][000010b2] 68b2100000 push 000010b2
>> [000010df][00101b81][000010e4] e8befbffff call 00000ca2
>> New slave_stack at:101c31
>>
>> Begin Local Halt Decider Simulation Execution Trace Stored at:111c39
>> [000010b2][00111c25][00111c29] 55 push ebp
>> [000010b3][00111c25][00111c29] 8bec mov ebp,esp
>> [000010b5][00111c25][00111c29] 8b4508 mov eax,[ebp+08]
>> [000010b8][00111c21][000010b2] 50 push eax // push
>> Px [000010b9][00111c21][000010b2] 8b4d08 mov ecx,[ebp+08]
>> [000010bc][00111c1d][000010b2] 51 push ecx // push
>> Px [000010bd][00111c19][000010c2] e8e0fbffff call 00000ca2 //
>> call HH New slave_stack at:14c659
>> [000010b2][0015c64d][0015c651] 55 push ebp
>> [000010b3][0015c64d][0015c651] 8bec mov ebp,esp
>> [000010b5][0015c64d][0015c651] 8b4508 mov eax,[ebp+08]
>> [000010b8][0015c649][000010b2] 50 push eax // push
>> Px [000010b9][0015c649][000010b2] 8b4d08 mov ecx,[ebp+08]
>> [000010bc][0015c645][000010b2] 51 push ecx // push
>> Px [000010bd][0015c641][000010c2] e8e0fbffff call 00000ca2 //
>> call HH *Local Halt Decider: Infinite Recursion Detected Simulation
>> Stopped*
>>
>> *When HH(Px,Px) simulates its input it sees that*
>> (1) Function HH(Px,Px) is called twice in sequence from the same
>> machine address of Px().
>> (2) With the same arguments to HH(Px,Px).
>> (3) With no control flow instructions between the invocation of Px()
>> and its call to HH(Px,Px) that could possibly escape repeated
>> simulations.
>>
>> [000010e4][00101b8d][00000000] 83c408 add esp,+08
>> [000010e7][00101b89][00000000] 50 push eax
>> [000010e8][00101b85][00000463] 6863040000 push 00000463
>> [000010ed][00101b85][00000463] e890f3ffff call 00000482
>> Input_Halts = 0
>> [000010f2][00101b8d][00000000] 83c408 add esp,+08
>> [000010f5][00101b8d][00000000] 33c0 xor eax,eax
>> [000010f7][00101b91][00000018] 5d pop ebp
>> [000010f8][00101b95][00000000] c3 ret
>> Number of Instructions Executed(15322) == 229 Pages
>
> All your trace is doing is confirming that H gets the answer wrong, Px
> halts. Until you resolve this false positive you do not have a valid
> SHD.
>
> /Flibble
>

Click here to read the complete article

On Sat, 20 Aug 2022 14:06:32 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 8/20/2022 1:52 PM, Mr Flibble wrote:
> > On Sat, 20 Aug 2022 13:50:15 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 8/20/2022 1:32 PM, Mr Flibble wrote:
> >>> On Sat, 20 Aug 2022 10:23:58 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
> >>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
> >>>>>> Olcott, which of the following do you think is more likely?
> >>>>>>
> >>>>>> 1) Olcott is correct and everybody else is wrong.
> >>>>>> 2) Olcott is wrong and everybody else is correct.
> >>>>>>
> >>>>>> Which one is more likely hasn't changed for all the years
> >>>>>> you've been attempting to shill your simulating halting
> >>>>>> decider. I find it amusing that I came up with, in less than
> >>>>>> 24 hours, a simulating halting decider that doesn't have the
> >>>>>> flaws your SHD has.
> >>>>>>
> >>>>>> /Flibble
> >>>>>>
> >>>>>
> >>>>> I have been following these discussions for many months now. I
> >>>>> have a strong impression that there is little progress. It seems
> >>>>> that people are running in circles. I am not an expert in this
> >>>>> field. Maybe it helps if a non-expert tries to summarize the
> >>>>> discussion. Please, be patient when correcting me if I make any
> >>>>> mistake.
> >>>>>
> >>>>> First the problem this is al about:
> >>>>> In computation theory we can denote a program with X and its
> >>>>> input with Y, which together is denoted as X(Y). X(Y) may end
> >>>>> (halt) in a finite number of steps, but another program X
> >>>>> and/or input Y may not halt in a finite number of steps. The
> >>>>> question is, is it possible to create a program H that when
> >>>>> given any program X with its input Y can tell in a finite
> >>>>> number of steps whether X(Y) halts or not? In other words, will
> >>>>> H(X,Y) always halt after a finite number of steps with the
> >>>>> correct answer for any X and Y?
> >>>>>
> >>>>> I hope that this is a correct formulation of the problem.
> >>>>>
> >>>>> The classical proof that it is not possible is the idea that it
> >>>>> is always possible to create a program P that uses H, with
> >>>>> itself as input, but behaves opposite to what H returns. In a
> >>>>> C-like language it would be something like:
> >>>>>
> >>>>> void P(ptr x)
> >>>>> {
> >>>>> int Halt_Status = H(x, x);
> >>>>> if (Halt_Status)
> >>>>> HERE: goto HERE;
> >>>>> return;
> >>>>> }
> >>>>>
> >>>>> If there would be a hypothetical non-simulating non-aborting H,
> >>>>> which would always halts with the correct answer, then it is
> >>>>> clear that there would be a contradiction if we ask H about P
> >>>>> with H(P,P). Because there are only three possibilities:
> >>>>> 1. If H would return true (halting) in a finite number of steps,
> >>>>> then P would start an endless loop, so H(P,P) does not halt in a
> >>>>> finite number of steps.
> >>>>> 2. If H would return false (non-halting) in a finite number of
> >>>>> steps, then P returns immediately, so H returns a wrong result.
> >>>>> 3. If H does not return, then it does not return in a finite
> >>>>> number of steps, so it is not the H where the problem asked for.
> >>>>>
> >>>>> I think everybody agrees up to this point.
> >>>>>
> >>>>> Now Olcott has created a simulating aborting H, which, when
> >>>>> given P with input P [so H(P,P)], creates a trace of the
> >>>>> execution and at the point where P calls H, it uses the
> >>>>> following logic: If H were the hypothetical non-aborting H,
> >>>>> then an infinite recursion would happen at this point.
> >>>>> Therefore, Olcott's simulating H aborts the simulation and
> >>>>> returns false (0).
> >>>>>
> >>>>> Does everybody still agree up to this point?
> >>>>>
> >>>>> Now the opinions diverge.
> >>>>> Olcott thinks that his H gives the correct answer that P would
> >>>>> not halt when P would call the hypothetical non-aborting H, so,
> >>>>> it must also be the correct answer when P actually calls the
> >>>>> actual aborting H.
> >>>>
> >>>> *You did a very good job summing this up*
> >>>> The key nuance of divergence is that halting means that when
> >>>> H(P,P) correctly simulates its input that this input would reach
> >>>> the "return" instruction (final state) of P. H(P,P) correctly
> >>>> determines that its correct simulation of its input would never
> >>>> reach the "return" instruction of P.
> >>>>
> >>>> *computation that halts* … the Turing machine will halt whenever
> >>>> it enters a final state. (Linz:1990:234)
> >>>>
> >>>> Linz, Peter 1990. An Introduction to Formal Languages and
> >>>> Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)
> >>>>
> >>>> When-so-ever the correct partial simulation of a machine
> >>>> description correctly matches a correct infinite behavior pattern
> >>>> then it is certain that this machine description specifies
> >>>> infinite behavior.
> >>>>
> >>>> In other words the SHD decider correctly predicts that its
> >>>> correct and complete simulation of its input would never reach
> >>>> the final state of this input.
> >>>>
> >>>> *HERE IS THE SIMPLEST CASE OF THAT*
> >>>> void Infinite_Loop()
> >>>> {
> >>>> HERE: goto HERE;
> >>>> }
> >>>
> >>> And here is a case where your H gets the answer wrong:
> >>>
> >>> void Px(void (*x)())
> >>> {
> >>> (void) H(x, x);
> >>> return;
> >>> }
> >>>
> >>> Px always halts if H returns to Px (and a valid halt decider must
> >>> always return a decision to its caller).
> >>>
> >>> /Flibble
> >>>
> >>
> >>
> >> This one uses my prior version of H named HH where the infinitely
> >> recursive simulation is easier to see.
> >>
> >> void Px(void (*x)())
> >> {
> >> (void) HH(x, x);
> >> return;
> >> }
> >>
> >> int main()
> >> {
> >> Output("Input_Halts = ", HH(Px, Px));
> >> }
> >>
> >> _Px()
> >> [000010b2](01) 55 push ebp
> >> [000010b3](02) 8bec mov ebp,esp
> >> [000010b5](03) 8b4508 mov eax,[ebp+08]
> >> [000010b8](01) 50 push eax
> >> [000010b9](03) 8b4d08 mov ecx,[ebp+08]
> >> [000010bc](01) 51 push ecx
> >> [000010bd](05) e8e0fbffff call 00000ca2
> >> [000010c2](03) 83c408 add esp,+08
> >> [000010c5](01) 5d pop ebp
> >> [000010c6](01) c3 ret
> >> Size in bytes:(0021) [000010c6]
> >>
> >> _main()
> >> [000010d2](01) 55 push ebp
> >> [000010d3](02) 8bec mov ebp,esp
> >> [000010d5](05) 68b2100000 push 000010b2
> >> [000010da](05) 68b2100000 push 000010b2
> >> [000010df](05) e8befbffff call 00000ca2
> >> [000010e4](03) 83c408 add esp,+08
> >> [000010e7](01) 50 push eax
> >> [000010e8](05) 6863040000 push 00000463
> >> [000010ed](05) e890f3ffff call 00000482
> >> [000010f2](03) 83c408 add esp,+08
> >> [000010f5](02) 33c0 xor eax,eax
> >> [000010f7](01) 5d pop ebp
> >> [000010f8](01) c3 ret
> >> Size in bytes:(0039) [000010f8]
> >>
> >> machine stack stack machine assembly
> >> address address data code language
> >> ======== ======== ======== ========= ============> >> [000010d2][00101b8d][00000000] 55 push ebp
> >> [000010d3][00101b8d][00000000] 8bec mov ebp,esp
> >> [000010d5][00101b89][000010b2] 68b2100000 push 000010b2
> >> [000010da][00101b85][000010b2] 68b2100000 push 000010b2
> >> [000010df][00101b81][000010e4] e8befbffff call 00000ca2
> >> New slave_stack at:101c31
> >>
> >> Begin Local Halt Decider Simulation Execution Trace Stored
> >> at:111c39 [000010b2][00111c25][00111c29] 55 push ebp
> >> [000010b3][00111c25][00111c29] 8bec mov ebp,esp
> >> [000010b5][00111c25][00111c29] 8b4508 mov eax,[ebp+08]
> >> [000010b8][00111c21][000010b2] 50 push eax //
> >> push Px [000010b9][00111c21][000010b2] 8b4d08 mov
> >> ecx,[ebp+08] [000010bc][00111c1d][000010b2] 51 push
> >> ecx // push Px [000010bd][00111c19][000010c2] e8e0fbffff
> >> call 00000ca2 // call HH New slave_stack at:14c659
> >> [000010b2][0015c64d][0015c651] 55 push ebp
> >> [000010b3][0015c64d][0015c651] 8bec mov ebp,esp
> >> [000010b5][0015c64d][0015c651] 8b4508 mov eax,[ebp+08]
> >> [000010b8][0015c649][000010b2] 50 push eax //
> >> push Px [000010b9][0015c649][000010b2] 8b4d08 mov
> >> ecx,[ebp+08] [000010bc][0015c645][000010b2] 51 push
> >> ecx // push Px [000010bd][0015c641][000010c2] e8e0fbffff
> >> call 00000ca2 // call HH *Local Halt Decider: Infinite Recursion
> >> Detected Simulation Stopped*
> >>
> >> *When HH(Px,Px) simulates its input it sees that*
> >> (1) Function HH(Px,Px) is called twice in sequence from the same
> >> machine address of Px().
> >> (2) With the same arguments to HH(Px,Px).
> >> (3) With no control flow instructions between the invocation of
> >> Px() and its call to HH(Px,Px) that could possibly escape repeated
> >> simulations.
> >>
> >> [000010e4][00101b8d][00000000] 83c408 add esp,+08
> >> [000010e7][00101b89][00000000] 50 push eax
> >> [000010e8][00101b85][00000463] 6863040000 push 00000463
> >> [000010ed][00101b85][00000463] e890f3ffff call 00000482
> >> Input_Halts = 0
> >> [000010f2][00101b8d][00000000] 83c408 add esp,+08
> >> [000010f5][00101b8d][00000000] 33c0 xor eax,eax
> >> [000010f7][00101b91][00000018] 5d pop ebp
> >> [000010f8][00101b95][00000000] c3 ret
> >> Number of Instructions Executed(15322) == 229 Pages
> >
> > All your trace is doing is confirming that H gets the answer wrong,
> > Px halts. Until you resolve this false positive you do not have a
> > valid SHD.
> >
> > /Flibble
> >
>
> void Px(void (*x)())
> {
> (void) HH(x, x);
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", HH(Px, Px));
> }
>
> Because HH is a simulating halt decider (SHD) it continues to perform
> a pure x86 emulation of its input until it correctly matches a
> non-halting behavior pattern proving that the simulated input would
> never reach its own final state.
>
> (a) HH(Px,Px) simulates Px(Px) that calls a simulated HH(Px,Px)
> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
> *Until HH aborts its simulation*
>
> All those having sufficient software engineering technical competence
> can see this.

Click here to read the complete article

On 8/20/2022 2:09 PM, Mr Flibble wrote:
> On Sat, 20 Aug 2022 14:06:32 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 8/20/2022 1:52 PM, Mr Flibble wrote:
>>> On Sat, 20 Aug 2022 13:50:15 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 8/20/2022 1:32 PM, Mr Flibble wrote:
>>>>> On Sat, 20 Aug 2022 10:23:58 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
>>>>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>>>>>> Olcott, which of the following do you think is more likely?
>>>>>>>>
>>>>>>>> 1) Olcott is correct and everybody else is wrong.
>>>>>>>> 2) Olcott is wrong and everybody else is correct.
>>>>>>>>
>>>>>>>> Which one is more likely hasn't changed for all the years
>>>>>>>> you've been attempting to shill your simulating halting
>>>>>>>> decider. I find it amusing that I came up with, in less than
>>>>>>>> 24 hours, a simulating halting decider that doesn't have the
>>>>>>>> flaws your SHD has.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>
>>>>>>> I have been following these discussions for many months now. I
>>>>>>> have a strong impression that there is little progress. It seems
>>>>>>> that people are running in circles. I am not an expert in this
>>>>>>> field. Maybe it helps if a non-expert tries to summarize the
>>>>>>> discussion. Please, be patient when correcting me if I make any
>>>>>>> mistake.
>>>>>>>
>>>>>>> First the problem this is al about:
>>>>>>> In computation theory we can denote a program with X and its
>>>>>>> input with Y, which together is denoted as X(Y). X(Y) may end
>>>>>>> (halt) in a finite number of steps, but another program X
>>>>>>> and/or input Y may not halt in a finite number of steps. The
>>>>>>> question is, is it possible to create a program H that when
>>>>>>> given any program X with its input Y can tell in a finite
>>>>>>> number of steps whether X(Y) halts or not? In other words, will
>>>>>>> H(X,Y) always halt after a finite number of steps with the
>>>>>>> correct answer for any X and Y?
>>>>>>>
>>>>>>> I hope that this is a correct formulation of the problem.
>>>>>>>
>>>>>>> The classical proof that it is not possible is the idea that it
>>>>>>> is always possible to create a program P that uses H, with
>>>>>>> itself as input, but behaves opposite to what H returns. In a
>>>>>>> C-like language it would be something like:
>>>>>>>
>>>>>>> void P(ptr x)
>>>>>>> {
>>>>>>> int Halt_Status = H(x, x);
>>>>>>> if (Halt_Status)
>>>>>>> HERE: goto HERE;
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> If there would be a hypothetical non-simulating non-aborting H,
>>>>>>> which would always halts with the correct answer, then it is
>>>>>>> clear that there would be a contradiction if we ask H about P
>>>>>>> with H(P,P). Because there are only three possibilities:
>>>>>>> 1. If H would return true (halting) in a finite number of steps,
>>>>>>> then P would start an endless loop, so H(P,P) does not halt in a
>>>>>>> finite number of steps.
>>>>>>> 2. If H would return false (non-halting) in a finite number of
>>>>>>> steps, then P returns immediately, so H returns a wrong result.
>>>>>>> 3. If H does not return, then it does not return in a finite
>>>>>>> number of steps, so it is not the H where the problem asked for.
>>>>>>>
>>>>>>> I think everybody agrees up to this point.
>>>>>>>
>>>>>>> Now Olcott has created a simulating aborting H, which, when
>>>>>>> given P with input P [so H(P,P)], creates a trace of the
>>>>>>> execution and at the point where P calls H, it uses the
>>>>>>> following logic: If H were the hypothetical non-aborting H,
>>>>>>> then an infinite recursion would happen at this point.
>>>>>>> Therefore, Olcott's simulating H aborts the simulation and
>>>>>>> returns false (0).
>>>>>>>
>>>>>>> Does everybody still agree up to this point?
>>>>>>>
>>>>>>> Now the opinions diverge.
>>>>>>> Olcott thinks that his H gives the correct answer that P would
>>>>>>> not halt when P would call the hypothetical non-aborting H, so,
>>>>>>> it must also be the correct answer when P actually calls the
>>>>>>> actual aborting H.
>>>>>>
>>>>>> *You did a very good job summing this up*
>>>>>> The key nuance of divergence is that halting means that when
>>>>>> H(P,P) correctly simulates its input that this input would reach
>>>>>> the "return" instruction (final state) of P. H(P,P) correctly
>>>>>> determines that its correct simulation of its input would never
>>>>>> reach the "return" instruction of P.
>>>>>>
>>>>>> *computation that halts* … the Turing machine will halt whenever
>>>>>> it enters a final state. (Linz:1990:234)
>>>>>>
>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>> Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>
>>>>>> When-so-ever the correct partial simulation of a machine
>>>>>> description correctly matches a correct infinite behavior pattern
>>>>>> then it is certain that this machine description specifies
>>>>>> infinite behavior.
>>>>>>
>>>>>> In other words the SHD decider correctly predicts that its
>>>>>> correct and complete simulation of its input would never reach
>>>>>> the final state of this input.
>>>>>>
>>>>>> *HERE IS THE SIMPLEST CASE OF THAT*
>>>>>> void Infinite_Loop()
>>>>>> {
>>>>>> HERE: goto HERE;
>>>>>> }
>>>>>
>>>>> And here is a case where your H gets the answer wrong:
>>>>>
>>>>> void Px(void (*x)())
>>>>> {
>>>>> (void) H(x, x);
>>>>> return;
>>>>> }
>>>>>
>>>>> Px always halts if H returns to Px (and a valid halt decider must
>>>>> always return a decision to its caller).
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>>
>>>> This one uses my prior version of H named HH where the infinitely
>>>> recursive simulation is easier to see.
>>>>
>>>> void Px(void (*x)())
>>>> {
>>>> (void) HH(x, x);
>>>> return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", HH(Px, Px));
>>>> }
>>>>
>>>> _Px()
>>>> [000010b2](01) 55 push ebp
>>>> [000010b3](02) 8bec mov ebp,esp
>>>> [000010b5](03) 8b4508 mov eax,[ebp+08]
>>>> [000010b8](01) 50 push eax
>>>> [000010b9](03) 8b4d08 mov ecx,[ebp+08]
>>>> [000010bc](01) 51 push ecx
>>>> [000010bd](05) e8e0fbffff call 00000ca2
>>>> [000010c2](03) 83c408 add esp,+08
>>>> [000010c5](01) 5d pop ebp
>>>> [000010c6](01) c3 ret
>>>> Size in bytes:(0021) [000010c6]
>>>>
>>>> _main()
>>>> [000010d2](01) 55 push ebp
>>>> [000010d3](02) 8bec mov ebp,esp
>>>> [000010d5](05) 68b2100000 push 000010b2
>>>> [000010da](05) 68b2100000 push 000010b2
>>>> [000010df](05) e8befbffff call 00000ca2
>>>> [000010e4](03) 83c408 add esp,+08
>>>> [000010e7](01) 50 push eax
>>>> [000010e8](05) 6863040000 push 00000463
>>>> [000010ed](05) e890f3ffff call 00000482
>>>> [000010f2](03) 83c408 add esp,+08
>>>> [000010f5](02) 33c0 xor eax,eax
>>>> [000010f7](01) 5d pop ebp
>>>> [000010f8](01) c3 ret
>>>> Size in bytes:(0039) [000010f8]
>>>>
>>>> machine stack stack machine assembly
>>>> address address data code language
>>>> ======== ======== ======== ========= =============
>>>> [000010d2][00101b8d][00000000] 55 push ebp
>>>> [000010d3][00101b8d][00000000] 8bec mov ebp,esp
>>>> [000010d5][00101b89][000010b2] 68b2100000 push 000010b2
>>>> [000010da][00101b85][000010b2] 68b2100000 push 000010b2
>>>> [000010df][00101b81][000010e4] e8befbffff call 00000ca2
>>>> New slave_stack at:101c31
>>>>
>>>> Begin Local Halt Decider Simulation Execution Trace Stored
>>>> at:111c39 [000010b2][00111c25][00111c29] 55 push ebp
>>>> [000010b3][00111c25][00111c29] 8bec mov ebp,esp
>>>> [000010b5][00111c25][00111c29] 8b4508 mov eax,[ebp+08]
>>>> [000010b8][00111c21][000010b2] 50 push eax //
>>>> push Px [000010b9][00111c21][000010b2] 8b4d08 mov
>>>> ecx,[ebp+08] [000010bc][00111c1d][000010b2] 51 push
>>>> ecx // push Px [000010bd][00111c19][000010c2] e8e0fbffff
>>>> call 00000ca2 // call HH New slave_stack at:14c659
>>>> [000010b2][0015c64d][0015c651] 55 push ebp
>>>> [000010b3][0015c64d][0015c651] 8bec mov ebp,esp
>>>> [000010b5][0015c64d][0015c651] 8b4508 mov eax,[ebp+08]
>>>> [000010b8][0015c649][000010b2] 50 push eax //
>>>> push Px [000010b9][0015c649][000010b2] 8b4d08 mov
>>>> ecx,[ebp+08] [000010bc][0015c645][000010b2] 51 push
>>>> ecx // push Px [000010bd][0015c641][000010c2] e8e0fbffff
>>>> call 00000ca2 // call HH *Local Halt Decider: Infinite Recursion
>>>> Detected Simulation Stopped*
>>>>
>>>> *When HH(Px,Px) simulates its input it sees that*
>>>> (1) Function HH(Px,Px) is called twice in sequence from the same
>>>> machine address of Px().
>>>> (2) With the same arguments to HH(Px,Px).
>>>> (3) With no control flow instructions between the invocation of
>>>> Px() and its call to HH(Px,Px) that could possibly escape repeated
>>>> simulations.
>>>>
>>>> [000010e4][00101b8d][00000000] 83c408 add esp,+08
>>>> [000010e7][00101b89][00000000] 50 push eax
>>>> [000010e8][00101b85][00000463] 6863040000 push 00000463
>>>> [000010ed][00101b85][00000463] e890f3ffff call 00000482
>>>> Input_Halts = 0
>>>> [000010f2][00101b8d][00000000] 83c408 add esp,+08
>>>> [000010f5][00101b8d][00000000] 33c0 xor eax,eax
>>>> [000010f7][00101b91][00000018] 5d pop ebp
>>>> [000010f8][00101b95][00000000] c3 ret
>>>> Number of Instructions Executed(15322) == 229 Pages
>>>
>>> All your trace is doing is confirming that H gets the answer wrong,
>>> Px halts. Until you resolve this false positive you do not have a
>>> valid SHD.
>>>
>>> /Flibble
>>>
>>
>> void Px(void (*x)())
>> {
>> (void) HH(x, x);
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", HH(Px, Px));
>> }
>>
>> Because HH is a simulating halt decider (SHD) it continues to perform
>> a pure x86 emulation of its input until it correctly matches a
>> non-halting behavior pattern proving that the simulated input would
>> never reach its own final state.
>>
>> (a) HH(Px,Px) simulates Px(Px) that calls a simulated HH(Px,Px)
>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>> *Until HH aborts its simulation*
>>
>> All those having sufficient software engineering technical competence
>> can see this.
>
> Px always halts if H is a valid halt decider. Your H is not a valid
> halt decider.
>
> /Flibble
>

Click here to read the complete article

On 8/20/22 3:00 PM, olcott wrote:
> On 8/20/2022 1:32 PM, Richard Damon wrote:
>> On 8/20/22 11:01 AM, Fred. Zwarts wrote:
>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>> Olcott, which of the following do you think is more likely?
>>>>
>>>> 1) Olcott is correct and everybody else is wrong.
>>>> 2) Olcott is wrong and everybody else is correct.
>>>>
>>>> Which one is more likely hasn't changed for all the years you've been
>>>> attempting to shill your simulating halting decider. I find it amusing
>>>> that I came up with, in less than 24 hours, a simulating halting
>>>> decider that doesn't have the flaws your SHD has.
>>>>
>>>> /Flibble
>>>>
>>>
>>> I have been following these discussions for many months now. I have a
>>> strong impression that there is little progress. It seems that people
>>> are running in circles. I am not an expert in this field. Maybe it
>>> helps if a non-expert tries to summarize the discussion. Please, be
>>> patient when correcting me if I make any mistake.
>>>
>>> First the problem this is al about:
>>> In computation theory we can denote a program with X and its input
>>> with Y, which together is denoted as X(Y). X(Y) may end (halt) in a
>>> finite number of steps, but another program X and/or input Y may not
>>> halt in a finite number of steps. The question is, is it possible to
>>> create a program H that when given any program X with its input Y can
>>> tell in a finite number of steps whether X(Y) halts or not? In other
>>> words, will H(X,Y) always halt after a finite number of steps with
>>> the correct answer for any X and Y?
>>>
>>> I hope that this is a correct formulation of the problem.
>>>
>>> The classical proof that it is not possible is the idea that it is
>>> always possible to create a program P that uses H, with itself as
>>> input, but behaves opposite to what H returns. In a C-like language
>>> it would be something like:
>>>
>>> void P(ptr x)
>>> {
>>>    int Halt_Status = H(x, x);
>>>    if (Halt_Status)
>>>      HERE: goto HERE;
>>>    return;
>>> }
>>>
>>> If there would be a hypothetical non-simulating non-aborting H, which
>>> would always halts with the correct answer, then it is clear that
>>> there would be a contradiction if we ask H about P with H(P,P).
>>> Because there are only three possibilities:
>>> 1. If H would return true (halting) in a finite number of steps, then
>>> P would start an endless loop, so H(P,P) does not halt in a finite
>>> number of steps.
>>> 2. If H would return false (non-halting) in a finite number of steps,
>>> then P returns immediately, so H returns a wrong result.
>>> 3. If H does not return, then it does not return in a finite number
>>> of steps, so it is not the H where the problem asked for.
>>>
>>> I think everybody agrees up to this point.
>>>
>>> Now Olcott has created a simulating aborting H, which, when given P
>>> with input P [so H(P,P)], creates a trace of the execution and at the
>>> point where P calls H, it uses the following logic: If H were the
>>> hypothetical non-aborting H, then an infinite recursion would happen
>>> at this point. Therefore, Olcott's simulating H aborts the simulation
>>> and returns false (0).
>>>
>>> Does everybody still agree up to this point?
>>>
>>> Now the opinions diverge.
>>> Olcott thinks that his H gives the correct answer that P would not
>>> halt when P would call the hypothetical non-aborting H, so, it must
>>> also be the correct answer when P actually calls the actual aborting H.
>>>
>>> Others have a different opinion and argue that P does not call the
>>> hypothetical non-aborting H, but the actual aborting H, which does
>>> not go in infinite recursion, but returns false in a finite number of
>>> steps. Therefore, H's result is wrong.
>>>
>>> Is this a correct summary of the disagreement? If not, please, tell
>>> me where the summary failed. Maybe we can then find the point of
>>> divergence of opinions easier.
>>>
>>
>> The key point is the conventional proof doesn't assume a
>> "Non-simulating" decider, but ANY decider, no matter how it determines
>> its answer.
>>
>> The key error of Olcott, is the mistaken idea that just because H
>> happens to be a simulating Halt Decider, it gets to change the
>> criteria that it needs to decide on, and rather than being does the
>> computation the input represents [that is M(x) for a call to H(M,x) ],
>> halt or never halt, but can we decide instead of on a did "H need to
>> abort its simulation" criteria, and that this "need" affect EVERY COPY
>> of H that exists in the world. (He confuses that last point by mashing
>> the code of the decided program and the decider into a single program
>> and having the decided program share code with the decider instead of
>> being an independent copy, as it would need to be to actually
>> implement as Turing Machines.
>>
>> Because of this, H is actually deciding on the wrong input, the H that
>> aborts is actually reporting the results of the input program P built
>> on the H that doesn't abort, which is a different input then the input
>> program P built on the H that does abort.
>
>
> It is common knowledge that the correct and complete simulation of a
> machine description always provides the actual behavior specified by
> this machine description.

Right. COMPLETE.

The H that answers non-halting does NOT do a COMPLETE simulation of its
input.

If that input is given to a UTM equivalent, the COMPLETE simulation of
that input (which still calls H) will Halt.

THUS, H was wrong.

>
> That you and others reject this when it is applied to my simulating halt
> decider implicitly rejects the notion of a UTM. Since you and others do
> accept the notion of a UTM, I have just proven that your reasoning is
> incoherent and/or inconsistent.

Becaue you have no H that answers non-Halting that also has a COMPLETE
simulation of its input that will not halt even after an unbounded
number of steps.

>
> Whenever the simulating halt decider correctly predicts that its correct
> and complete simulation of its input would never reach the final state
> of this input, then the SHD is correct to reject its input as non-halting.

FALSE.

IF it doesn't actually DO a complete simulation, talking about what the
complete simulation it would do is MEANINGLESS.

You H is answering about a different input then the one given to it.

>
> *HERE IS THE SIMPLEST CASE OF THAT*
> void Infinite_Loop()
> {
> HERE: goto HERE;
> }
>
> int main()
> {
> Output("Input_Halts = ", H0((u32)Infinite_Loop));
> }
>
> _Infinite_Loop()
> [00001102](01) 55         push ebp
> [00001103](02) 8bec       mov ebp,esp
> [00001105](02) ebfe       jmp 00001105
> [00001107](01) 5d         pop ebp
> [00001108](01) c3         ret
> Size in bytes:(0007) [00001108]
>
>
>

Red Herring.

Fallacy of Proof by Exampe.

On 8/20/22 2:50 PM, olcott wrote:
> On 8/20/2022 1:32 PM, Mr Flibble wrote:
>> On Sat, 20 Aug 2022 10:23:58 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>>> Olcott, which of the following do you think is more likely?
>>>>>
>>>>> 1) Olcott is correct and everybody else is wrong.
>>>>> 2) Olcott is wrong and everybody else is correct.
>>>>>
>>>>> Which one is more likely hasn't changed for all the years you've
>>>>> been attempting to shill your simulating halting decider. I find
>>>>> it amusing that I came up with, in less than 24 hours, a
>>>>> simulating halting decider that doesn't have the flaws your SHD
>>>>> has.
>>>>>
>>>>> /Flibble
>>>>
>>>> I have been following these discussions for many months now. I have
>>>> a strong impression that there is little progress. It seems that
>>>> people are running in circles. I am not an expert in this field.
>>>> Maybe it helps if a non-expert tries to summarize the discussion.
>>>> Please, be patient when correcting me if I make any mistake.
>>>>
>>>> First the problem this is al about:
>>>> In computation theory we can denote a program with X and its input
>>>> with Y, which together is denoted as X(Y). X(Y) may end (halt) in a
>>>> finite number of steps, but another program X and/or input Y may
>>>> not halt in a finite number of steps. The question is, is it
>>>> possible to create a program H that when given any program X with
>>>> its input Y can tell in a finite number of steps whether X(Y) halts
>>>> or not? In other words, will H(X,Y) always halt after a finite
>>>> number of steps with the correct answer for any X and Y?
>>>>
>>>> I hope that this is a correct formulation of the problem.
>>>>
>>>> The classical proof that it is not possible is the idea that it is
>>>> always possible to create a program P that uses H, with itself as
>>>> input, but behaves opposite to what H returns. In a C-like language
>>>> it would be something like:
>>>>
>>>> void P(ptr x)
>>>> {
>>>> int Halt_Status = H(x, x);
>>>> if (Halt_Status)
>>>>     HERE: goto HERE;
>>>> return;
>>>> }
>>>>
>>>> If there would be a hypothetical non-simulating non-aborting H,
>>>> which would always halts with the correct answer, then it is clear
>>>> that there would be a contradiction if we ask H about P with
>>>> H(P,P). Because there are only three possibilities:
>>>> 1. If H would return true (halting) in a finite number of steps,
>>>> then P would start an endless loop, so H(P,P) does not halt in a
>>>> finite number of steps.
>>>> 2. If H would return false (non-halting) in a finite number of
>>>> steps, then P returns immediately, so H returns a wrong result.
>>>> 3. If H does not return, then it does not return in a finite number
>>>> of steps, so it is not the H where the problem asked for.
>>>>
>>>> I think everybody agrees up to this point.
>>>>
>>>> Now Olcott has created a simulating aborting H, which, when given P
>>>> with input P [so H(P,P)], creates a trace of the execution and at
>>>> the point where P calls H, it uses the following logic: If H were
>>>> the hypothetical non-aborting H, then an infinite recursion would
>>>> happen at this point. Therefore, Olcott's simulating H aborts the
>>>> simulation and returns false (0).
>>>>
>>>> Does everybody still agree up to this point?
>>>>
>>>> Now the opinions diverge.
>>>> Olcott thinks that his H gives the correct answer that P would not
>>>> halt when P would call the hypothetical non-aborting H, so, it must
>>>> also be the correct answer when P actually calls the actual
>>>> aborting H.
>>>
>>> *You did a very good job summing this up*
>>> The key nuance of divergence is that halting means that when H(P,P)
>>> correctly simulates its input that this input would reach the
>>> "return" instruction (final state) of P. H(P,P) correctly determines
>>> that its correct simulation of its input would never reach the
>>> "return" instruction of P.
>>>
>>> *computation that halts* … the Turing machine will halt whenever it
>>> enters a final state. (Linz:1990:234)
>>>
>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>
>>> When-so-ever the correct partial simulation of a machine description
>>> correctly matches a correct infinite behavior pattern then it is
>>> certain that this machine description specifies infinite behavior.
>>>
>>> In other words the SHD decider correctly predicts that its correct
>>> and complete simulation of its input would never reach the final
>>> state of this input.
>>>
>>> *HERE IS THE SIMPLEST CASE OF THAT*
>>> void Infinite_Loop()
>>> {
>>>     HERE: goto HERE;
>>> }
>>
>> And here is a case where your H gets the answer wrong:
>>
>> void Px(void (*x)())
>> {
>>     (void) H(x, x);
>>     return;
>> }
>>
>> Px always halts if H returns to Px (and a valid halt decider must
>> always return a decision to its caller).
>>
>> /Flibble
>>
>
>
> This one uses my prior version of H named HH where the infinitely
> recursive simulation is easier to see.
>
> void Px(void (*x)())
> {
> (void) HH(x, x);
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", HH(Px, Px));
> }
>
> _Px()
> [000010b2](01) 55             push ebp
> [000010b3](02) 8bec           mov ebp,esp
> [000010b5](03) 8b4508         mov eax,[ebp+08]
> [000010b8](01) 50             push eax
> [000010b9](03) 8b4d08         mov ecx,[ebp+08]
> [000010bc](01) 51             push ecx
> [000010bd](05) e8e0fbffff     call 00000ca2
> [000010c2](03) 83c408         add esp,+08
> [000010c5](01) 5d             pop ebp
> [000010c6](01) c3             ret
> Size in bytes:(0021) [000010c6]
>
> _main()
> [000010d2](01) 55             push ebp
> [000010d3](02) 8bec           mov ebp,esp
> [000010d5](05) 68b2100000     push 000010b2
> [000010da](05) 68b2100000     push 000010b2
> [000010df](05) e8befbffff     call 00000ca2
> [000010e4](03) 83c408         add esp,+08
> [000010e7](01) 50             push eax
> [000010e8](05) 6863040000     push 00000463
> [000010ed](05) e890f3ffff     call 00000482
> [000010f2](03) 83c408         add esp,+08
> [000010f5](02) 33c0           xor eax,eax
> [000010f7](01) 5d             pop ebp
> [000010f8](01) c3             ret
> Size in bytes:(0039) [000010f8]
>
> machine   stack     stack     machine    assembly
> address   address   data      code       language
> ======== ======== ======== ========= =============
> [000010d2][00101b8d][00000000] 55             push ebp
> [000010d3][00101b8d][00000000] 8bec           mov ebp,esp
> [000010d5][00101b89][000010b2] 68b2100000     push 000010b2
> [000010da][00101b85][000010b2] 68b2100000     push 000010b2
> [000010df][00101b81][000010e4] e8befbffff     call 00000ca2
> New slave_stack at:101c31
>
> Begin Local Halt Decider Simulation   Execution Trace Stored at:111c39
> [000010b2][00111c25][00111c29] 55             push ebp
> [000010b3][00111c25][00111c29] 8bec           mov ebp,esp
> [000010b5][00111c25][00111c29] 8b4508         mov eax,[ebp+08]
> [000010b8][00111c21][000010b2] 50             push eax       // push Px
> [000010b9][00111c21][000010b2] 8b4d08         mov ecx,[ebp+08]
> [000010bc][00111c1d][000010b2] 51             push ecx       // push Px
> [000010bd][00111c19][000010c2] e8e0fbffff     call 00000ca2 // call HH
> New slave_stack at:14c659
> [000010b2][0015c64d][0015c651] 55             push ebp
> [000010b3][0015c64d][0015c651] 8bec           mov ebp,esp
> [000010b5][0015c64d][0015c651] 8b4508         mov eax,[ebp+08]
> [000010b8][0015c649][000010b2] 50             push eax       // push Px
> [000010b9][0015c649][000010b2] 8b4d08         mov ecx,[ebp+08]
> [000010bc][0015c645][000010b2] 51             push ecx       // push Px
> [000010bd][0015c641][000010c2] e8e0fbffff     call 00000ca2 // call HH
> *Local Halt Decider: Infinite Recursion Detected Simulation Stopped*
>
> *When HH(Px,Px) simulates its input it sees that*
> (1) Function HH(Px,Px) is called twice in sequence from the same machine
> address of Px().
> (2) With the same arguments to HH(Px,Px).
> (3) With no control flow instructions between the invocation of Px() and
> its call to HH(Px,Px) that could possibly escape repeated simulations.

Click here to read the complete article

On Sat, 20 Aug 2022 14:18:28 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 8/20/2022 2:09 PM, Mr Flibble wrote:
> > On Sat, 20 Aug 2022 14:06:32 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 8/20/2022 1:52 PM, Mr Flibble wrote:
> >>> On Sat, 20 Aug 2022 13:50:15 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 8/20/2022 1:32 PM, Mr Flibble wrote:
> >>>>> On Sat, 20 Aug 2022 10:23:58 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
> >>>>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
> >>>>>>>> Olcott, which of the following do you think is more likely?
> >>>>>>>>
> >>>>>>>> 1) Olcott is correct and everybody else is wrong.
> >>>>>>>> 2) Olcott is wrong and everybody else is correct.
> >>>>>>>>
> >>>>>>>> Which one is more likely hasn't changed for all the years
> >>>>>>>> you've been attempting to shill your simulating halting
> >>>>>>>> decider. I find it amusing that I came up with, in less than
> >>>>>>>> 24 hours, a simulating halting decider that doesn't have the
> >>>>>>>> flaws your SHD has.
> >>>>>>>>
> >>>>>>>> /Flibble
> >>>>>>>>
> >>>>>>>
> >>>>>>> I have been following these discussions for many months now. I
> >>>>>>> have a strong impression that there is little progress. It
> >>>>>>> seems that people are running in circles. I am not an expert
> >>>>>>> in this field. Maybe it helps if a non-expert tries to
> >>>>>>> summarize the discussion. Please, be patient when correcting
> >>>>>>> me if I make any mistake.
> >>>>>>>
> >>>>>>> First the problem this is al about:
> >>>>>>> In computation theory we can denote a program with X and its
> >>>>>>> input with Y, which together is denoted as X(Y). X(Y) may end
> >>>>>>> (halt) in a finite number of steps, but another program X
> >>>>>>> and/or input Y may not halt in a finite number of steps. The
> >>>>>>> question is, is it possible to create a program H that when
> >>>>>>> given any program X with its input Y can tell in a finite
> >>>>>>> number of steps whether X(Y) halts or not? In other words,
> >>>>>>> will H(X,Y) always halt after a finite number of steps with
> >>>>>>> the correct answer for any X and Y?
> >>>>>>>
> >>>>>>> I hope that this is a correct formulation of the problem.
> >>>>>>>
> >>>>>>> The classical proof that it is not possible is the idea that
> >>>>>>> it is always possible to create a program P that uses H, with
> >>>>>>> itself as input, but behaves opposite to what H returns. In a
> >>>>>>> C-like language it would be something like:
> >>>>>>>
> >>>>>>> void P(ptr x)
> >>>>>>> {
> >>>>>>> int Halt_Status = H(x, x);
> >>>>>>> if (Halt_Status)
> >>>>>>> HERE: goto HERE;
> >>>>>>> return;
> >>>>>>> }
> >>>>>>>
> >>>>>>> If there would be a hypothetical non-simulating non-aborting
> >>>>>>> H, which would always halts with the correct answer, then it
> >>>>>>> is clear that there would be a contradiction if we ask H
> >>>>>>> about P with H(P,P). Because there are only three
> >>>>>>> possibilities: 1. If H would return true (halting) in a
> >>>>>>> finite number of steps, then P would start an endless loop,
> >>>>>>> so H(P,P) does not halt in a finite number of steps.
> >>>>>>> 2. If H would return false (non-halting) in a finite number of
> >>>>>>> steps, then P returns immediately, so H returns a wrong
> >>>>>>> result. 3. If H does not return, then it does not return in a
> >>>>>>> finite number of steps, so it is not the H where the problem
> >>>>>>> asked for.
> >>>>>>>
> >>>>>>> I think everybody agrees up to this point.
> >>>>>>>
> >>>>>>> Now Olcott has created a simulating aborting H, which, when
> >>>>>>> given P with input P [so H(P,P)], creates a trace of the
> >>>>>>> execution and at the point where P calls H, it uses the
> >>>>>>> following logic: If H were the hypothetical non-aborting H,
> >>>>>>> then an infinite recursion would happen at this point.
> >>>>>>> Therefore, Olcott's simulating H aborts the simulation and
> >>>>>>> returns false (0).
> >>>>>>>
> >>>>>>> Does everybody still agree up to this point?
> >>>>>>>
> >>>>>>> Now the opinions diverge.
> >>>>>>> Olcott thinks that his H gives the correct answer that P would
> >>>>>>> not halt when P would call the hypothetical non-aborting H,
> >>>>>>> so, it must also be the correct answer when P actually calls
> >>>>>>> the actual aborting H.
> >>>>>>
> >>>>>> *You did a very good job summing this up*
> >>>>>> The key nuance of divergence is that halting means that when
> >>>>>> H(P,P) correctly simulates its input that this input would
> >>>>>> reach the "return" instruction (final state) of P. H(P,P)
> >>>>>> correctly determines that its correct simulation of its input
> >>>>>> would never reach the "return" instruction of P.
> >>>>>>
> >>>>>> *computation that halts* … the Turing machine will halt
> >>>>>> whenever it enters a final state. (Linz:1990:234)
> >>>>>>
> >>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
> >>>>>> Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)
> >>>>>>
> >>>>>> When-so-ever the correct partial simulation of a machine
> >>>>>> description correctly matches a correct infinite behavior
> >>>>>> pattern then it is certain that this machine description
> >>>>>> specifies infinite behavior.
> >>>>>>
> >>>>>> In other words the SHD decider correctly predicts that its
> >>>>>> correct and complete simulation of its input would never reach
> >>>>>> the final state of this input.
> >>>>>>
> >>>>>> *HERE IS THE SIMPLEST CASE OF THAT*
> >>>>>> void Infinite_Loop()
> >>>>>> {
> >>>>>> HERE: goto HERE;
> >>>>>> }
> >>>>>
> >>>>> And here is a case where your H gets the answer wrong:
> >>>>>
> >>>>> void Px(void (*x)())
> >>>>> {
> >>>>> (void) H(x, x);
> >>>>> return;
> >>>>> }
> >>>>>
> >>>>> Px always halts if H returns to Px (and a valid halt decider
> >>>>> must always return a decision to its caller).
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>>
> >>>> This one uses my prior version of H named HH where the infinitely
> >>>> recursive simulation is easier to see.
> >>>>
> >>>> void Px(void (*x)())
> >>>> {
> >>>> (void) HH(x, x);
> >>>> return;
> >>>> }
> >>>>
> >>>> int main()
> >>>> {
> >>>> Output("Input_Halts = ", HH(Px, Px));
> >>>> }
> >>>>
> >>>> _Px()
> >>>> [000010b2](01) 55 push ebp
> >>>> [000010b3](02) 8bec mov ebp,esp
> >>>> [000010b5](03) 8b4508 mov eax,[ebp+08]
> >>>> [000010b8](01) 50 push eax
> >>>> [000010b9](03) 8b4d08 mov ecx,[ebp+08]
> >>>> [000010bc](01) 51 push ecx
> >>>> [000010bd](05) e8e0fbffff call 00000ca2
> >>>> [000010c2](03) 83c408 add esp,+08
> >>>> [000010c5](01) 5d pop ebp
> >>>> [000010c6](01) c3 ret
> >>>> Size in bytes:(0021) [000010c6]
> >>>>
> >>>> _main()
> >>>> [000010d2](01) 55 push ebp
> >>>> [000010d3](02) 8bec mov ebp,esp
> >>>> [000010d5](05) 68b2100000 push 000010b2
> >>>> [000010da](05) 68b2100000 push 000010b2
> >>>> [000010df](05) e8befbffff call 00000ca2
> >>>> [000010e4](03) 83c408 add esp,+08
> >>>> [000010e7](01) 50 push eax
> >>>> [000010e8](05) 6863040000 push 00000463
> >>>> [000010ed](05) e890f3ffff call 00000482
> >>>> [000010f2](03) 83c408 add esp,+08
> >>>> [000010f5](02) 33c0 xor eax,eax
> >>>> [000010f7](01) 5d pop ebp
> >>>> [000010f8](01) c3 ret
> >>>> Size in bytes:(0039) [000010f8]
> >>>>
> >>>> machine stack stack machine assembly
> >>>> address address data code language
> >>>> ======== ======== ======== ========= ============> >>>> [000010d2][00101b8d][00000000] 55 push ebp
> >>>> [000010d3][00101b8d][00000000] 8bec mov ebp,esp
> >>>> [000010d5][00101b89][000010b2] 68b2100000 push 000010b2
> >>>> [000010da][00101b85][000010b2] 68b2100000 push 000010b2
> >>>> [000010df][00101b81][000010e4] e8befbffff call 00000ca2
> >>>> New slave_stack at:101c31
> >>>>
> >>>> Begin Local Halt Decider Simulation Execution Trace Stored
> >>>> at:111c39 [000010b2][00111c25][00111c29] 55 push ebp
> >>>> [000010b3][00111c25][00111c29] 8bec mov ebp,esp
> >>>> [000010b5][00111c25][00111c29] 8b4508 mov eax,[ebp+08]
> >>>> [000010b8][00111c21][000010b2] 50 push eax //
> >>>> push Px [000010b9][00111c21][000010b2] 8b4d08 mov
> >>>> ecx,[ebp+08] [000010bc][00111c1d][000010b2] 51 push
> >>>> ecx // push Px [000010bd][00111c19][000010c2] e8e0fbffff
> >>>> call 00000ca2 // call HH New slave_stack at:14c659
> >>>> [000010b2][0015c64d][0015c651] 55 push ebp
> >>>> [000010b3][0015c64d][0015c651] 8bec mov ebp,esp
> >>>> [000010b5][0015c64d][0015c651] 8b4508 mov eax,[ebp+08]
> >>>> [000010b8][0015c649][000010b2] 50 push eax //
> >>>> push Px [000010b9][0015c649][000010b2] 8b4d08 mov
> >>>> ecx,[ebp+08] [000010bc][0015c645][000010b2] 51 push
> >>>> ecx // push Px [000010bd][0015c641][000010c2] e8e0fbffff
> >>>> call 00000ca2 // call HH *Local Halt Decider: Infinite Recursion
> >>>> Detected Simulation Stopped*
> >>>>
> >>>> *When HH(Px,Px) simulates its input it sees that*
> >>>> (1) Function HH(Px,Px) is called twice in sequence from the same
> >>>> machine address of Px().
> >>>> (2) With the same arguments to HH(Px,Px).
> >>>> (3) With no control flow instructions between the invocation of
> >>>> Px() and its call to HH(Px,Px) that could possibly escape
> >>>> repeated simulations.
> >>>>
> >>>> [000010e4][00101b8d][00000000] 83c408 add esp,+08
> >>>> [000010e7][00101b89][00000000] 50 push eax
> >>>> [000010e8][00101b85][00000463] 6863040000 push 00000463
> >>>> [000010ed][00101b85][00000463] e890f3ffff call 00000482
> >>>> Input_Halts = 0
> >>>> [000010f2][00101b8d][00000000] 83c408 add esp,+08
> >>>> [000010f5][00101b8d][00000000] 33c0 xor eax,eax
> >>>> [000010f7][00101b91][00000018] 5d pop ebp
> >>>> [000010f8][00101b95][00000000] c3 ret
> >>>> Number of Instructions Executed(15322) == 229 Pages
> >>>
> >>> All your trace is doing is confirming that H gets the answer
> >>> wrong, Px halts. Until you resolve this false positive you do not
> >>> have a valid SHD.
> >>>
> >>> /Flibble
> >>>
> >>
> >> void Px(void (*x)())
> >> {
> >> (void) HH(x, x);
> >> return;
> >> }
> >>
> >> int main()
> >> {
> >> Output("Input_Halts = ", HH(Px, Px));
> >> }
> >>
> >> Because HH is a simulating halt decider (SHD) it continues to
> >> perform a pure x86 emulation of its input until it correctly
> >> matches a non-halting behavior pattern proving that the simulated
> >> input would never reach its own final state.
> >>
> >> (a) HH(Px,Px) simulates Px(Px) that calls a simulated HH(Px,Px)
> >> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
> >> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
> >> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
> >> *Until HH aborts its simulation*
> >>
> >> All those having sufficient software engineering technical
> >> competence can see this.
> >
> > Px always halts if H is a valid halt decider. Your H is not a valid
> > halt decider.
> >
> > /Flibble
> >
>
> You can make dogmatic statements** like that to try and hide your
> ignorance of software engineering yet are not fooling anyone that
> actually has sufficient technical competence in software engineering.
>
> ** Utterly bereft of any supporting reasoning.

Click here to read the complete article

On 8/20/22 3:06 PM, olcott wrote:
> On 8/20/2022 1:52 PM, Mr Flibble wrote:
>> On Sat, 20 Aug 2022 13:50:15 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 8/20/2022 1:32 PM, Mr Flibble wrote:
>>>> On Sat, 20 Aug 2022 10:23:58 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>> On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
>>>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>>>>> Olcott, which of the following do you think is more likely?
>>>>>>>
>>>>>>> 1) Olcott is correct and everybody else is wrong.
>>>>>>> 2) Olcott is wrong and everybody else is correct.
>>>>>>>
>>>>>>> Which one is more likely hasn't changed for all the years you've
>>>>>>> been attempting to shill your simulating halting decider. I find
>>>>>>> it amusing that I came up with, in less than 24 hours, a
>>>>>>> simulating halting decider that doesn't have the flaws your SHD
>>>>>>> has.
>>>>>>>
>>>>>>> /Flibble
>>>>>>
>>>>>> I have been following these discussions for many months now. I
>>>>>> have a strong impression that there is little progress. It seems
>>>>>> that people are running in circles. I am not an expert in this
>>>>>> field. Maybe it helps if a non-expert tries to summarize the
>>>>>> discussion. Please, be patient when correcting me if I make any
>>>>>> mistake.
>>>>>>
>>>>>> First the problem this is al about:
>>>>>> In computation theory we can denote a program with X and its input
>>>>>> with Y, which together is denoted as X(Y). X(Y) may end (halt) in
>>>>>> a finite number of steps, but another program X and/or input Y may
>>>>>> not halt in a finite number of steps. The question is, is it
>>>>>> possible to create a program H that when given any program X with
>>>>>> its input Y can tell in a finite number of steps whether X(Y)
>>>>>> halts or not? In other words, will H(X,Y) always halt after a
>>>>>> finite number of steps with the correct answer for any X and Y?
>>>>>>
>>>>>> I hope that this is a correct formulation of the problem.
>>>>>>
>>>>>> The classical proof that it is not possible is the idea that it is
>>>>>> always possible to create a program P that uses H, with itself as
>>>>>> input, but behaves opposite to what H returns. In a C-like
>>>>>> language it would be something like:
>>>>>>
>>>>>> void P(ptr x)
>>>>>> {
>>>>>>    int Halt_Status = H(x, x);
>>>>>>    if (Halt_Status)
>>>>>>        HERE: goto HERE;
>>>>>>    return;
>>>>>> }
>>>>>>
>>>>>> If there would be a hypothetical non-simulating non-aborting H,
>>>>>> which would always halts with the correct answer, then it is clear
>>>>>> that there would be a contradiction if we ask H about P with
>>>>>> H(P,P). Because there are only three possibilities:
>>>>>> 1. If H would return true (halting) in a finite number of steps,
>>>>>> then P would start an endless loop, so H(P,P) does not halt in a
>>>>>> finite number of steps.
>>>>>> 2. If H would return false (non-halting) in a finite number of
>>>>>> steps, then P returns immediately, so H returns a wrong result.
>>>>>> 3. If H does not return, then it does not return in a finite
>>>>>> number of steps, so it is not the H where the problem asked for.
>>>>>>
>>>>>> I think everybody agrees up to this point.
>>>>>>
>>>>>> Now Olcott has created a simulating aborting H, which, when given
>>>>>> P with input P [so H(P,P)], creates a trace of the execution and
>>>>>> at the point where P calls H, it uses the following logic: If H
>>>>>> were the hypothetical non-aborting H, then an infinite recursion
>>>>>> would happen at this point. Therefore, Olcott's simulating H
>>>>>> aborts the simulation and returns false (0).
>>>>>>
>>>>>> Does everybody still agree up to this point?
>>>>>>
>>>>>> Now the opinions diverge.
>>>>>> Olcott thinks that his H gives the correct answer that P would not
>>>>>> halt when P would call the hypothetical non-aborting H, so, it
>>>>>> must also be the correct answer when P actually calls the actual
>>>>>> aborting H.
>>>>>
>>>>> *You did a very good job summing this up*
>>>>> The key nuance of divergence is that halting means that when H(P,P)
>>>>> correctly simulates its input that this input would reach the
>>>>> "return" instruction (final state) of P. H(P,P) correctly
>>>>> determines that its correct simulation of its input would never
>>>>> reach the "return" instruction of P.
>>>>>
>>>>> *computation that halts* … the Turing machine will halt whenever it
>>>>> enters a final state. (Linz:1990:234)
>>>>>
>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>
>>>>> When-so-ever the correct partial simulation of a machine
>>>>> description correctly matches a correct infinite behavior pattern
>>>>> then it is certain that this machine description specifies
>>>>> infinite behavior.
>>>>>
>>>>> In other words the SHD decider correctly predicts that its correct
>>>>> and complete simulation of its input would never reach the final
>>>>> state of this input.
>>>>>
>>>>> *HERE IS THE SIMPLEST CASE OF THAT*
>>>>> void Infinite_Loop()
>>>>> {
>>>>>      HERE: goto HERE;
>>>>> }
>>>>
>>>> And here is a case where your H gets the answer wrong:
>>>>
>>>> void Px(void (*x)())
>>>> {
>>>>     (void) H(x, x);
>>>>     return;
>>>> }
>>>>
>>>> Px always halts if H returns to Px (and a valid halt decider must
>>>> always return a decision to its caller).
>>>>
>>>> /Flibble
>>>
>>>
>>> This one uses my prior version of H named HH where the infinitely
>>> recursive simulation is easier to see.
>>>
>>> void Px(void (*x)())
>>> {
>>>     (void) HH(x, x);
>>>     return;
>>> }
>>>
>>> int main()
>>> {
>>>     Output("Input_Halts = ", HH(Px, Px));
>>> }
>>>
>>> _Px()
>>> [000010b2](01) 55             push ebp
>>> [000010b3](02) 8bec           mov ebp,esp
>>> [000010b5](03) 8b4508         mov eax,[ebp+08]
>>> [000010b8](01) 50             push eax
>>> [000010b9](03) 8b4d08         mov ecx,[ebp+08]
>>> [000010bc](01) 51             push ecx
>>> [000010bd](05) e8e0fbffff     call 00000ca2
>>> [000010c2](03) 83c408         add esp,+08
>>> [000010c5](01) 5d             pop ebp
>>> [000010c6](01) c3             ret
>>> Size in bytes:(0021) [000010c6]
>>>
>>> _main()
>>> [000010d2](01) 55             push ebp
>>> [000010d3](02) 8bec           mov ebp,esp
>>> [000010d5](05) 68b2100000     push 000010b2
>>> [000010da](05) 68b2100000     push 000010b2
>>> [000010df](05) e8befbffff     call 00000ca2
>>> [000010e4](03) 83c408         add esp,+08
>>> [000010e7](01) 50             push eax
>>> [000010e8](05) 6863040000     push 00000463
>>> [000010ed](05) e890f3ffff     call 00000482
>>> [000010f2](03) 83c408         add esp,+08
>>> [000010f5](02) 33c0           xor eax,eax
>>> [000010f7](01) 5d             pop ebp
>>> [000010f8](01) c3             ret
>>> Size in bytes:(0039) [000010f8]
>>>
>>>    machine   stack     stack     machine    assembly
>>>    address   address   data      code       language
>>>    ======== ======== ======== ========= =============
>>> [000010d2][00101b8d][00000000] 55             push ebp
>>> [000010d3][00101b8d][00000000] 8bec           mov ebp,esp
>>> [000010d5][00101b89][000010b2] 68b2100000     push 000010b2
>>> [000010da][00101b85][000010b2] 68b2100000     push 000010b2
>>> [000010df][00101b81][000010e4] e8befbffff     call 00000ca2
>>> New slave_stack at:101c31
>>>
>>> Begin Local Halt Decider Simulation   Execution Trace Stored at:111c39
>>> [000010b2][00111c25][00111c29] 55             push ebp
>>> [000010b3][00111c25][00111c29] 8bec           mov ebp,esp
>>> [000010b5][00111c25][00111c29] 8b4508         mov eax,[ebp+08]
>>> [000010b8][00111c21][000010b2] 50             push eax       // push
>>> Px [000010b9][00111c21][000010b2] 8b4d08         mov ecx,[ebp+08]
>>> [000010bc][00111c1d][000010b2] 51             push ecx       // push
>>> Px [000010bd][00111c19][000010c2] e8e0fbffff     call 00000ca2 //
>>> call HH New slave_stack at:14c659
>>> [000010b2][0015c64d][0015c651] 55             push ebp
>>> [000010b3][0015c64d][0015c651] 8bec           mov ebp,esp
>>> [000010b5][0015c64d][0015c651] 8b4508         mov eax,[ebp+08]
>>> [000010b8][0015c649][000010b2] 50             push eax       // push
>>> Px [000010b9][0015c649][000010b2] 8b4d08         mov ecx,[ebp+08]
>>> [000010bc][0015c645][000010b2] 51             push ecx       // push
>>> Px [000010bd][0015c641][000010c2] e8e0fbffff     call 00000ca2 //
>>> call HH *Local Halt Decider: Infinite Recursion Detected Simulation
>>> Stopped*
>>>
>>> *When HH(Px,Px) simulates its input it sees that*
>>> (1) Function HH(Px,Px) is called twice in sequence from the same
>>> machine address of Px().
>>> (2) With the same arguments to HH(Px,Px).
>>> (3) With no control flow instructions between the invocation of Px()
>>> and its call to HH(Px,Px) that could possibly escape repeated
>>> simulations.
>>>
>>> [000010e4][00101b8d][00000000] 83c408         add esp,+08
>>> [000010e7][00101b89][00000000] 50             push eax
>>> [000010e8][00101b85][00000463] 6863040000     push 00000463
>>> [000010ed][00101b85][00000463] e890f3ffff     call 00000482
>>> Input_Halts = 0
>>> [000010f2][00101b8d][00000000] 83c408         add esp,+08
>>> [000010f5][00101b8d][00000000] 33c0           xor eax,eax
>>> [000010f7][00101b91][00000018] 5d             pop ebp
>>> [000010f8][00101b95][00000000] c3             ret
>>> Number of Instructions Executed(15322) == 229 Pages
>>
>> All your trace is doing is confirming that H gets the answer wrong, Px
>> halts. Until you resolve this false positive you do not have a valid
>> SHD.
>>
>> /Flibble
>>
>
> void Px(void (*x)())
> {
> (void) HH(x, x);
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", HH(Px, Px));
> }
>
> Because HH is a simulating halt decider (SHD) it continues to perform a
> pure x86 emulation of its input until it correctly matches a non-halting
> behavior pattern proving that the simulated input would never reach its
> own final state.
>
> (a) HH(Px,Px) simulates Px(Px) that calls a simulated HH(Px,Px)
> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
> *Until HH aborts its simulation*
>
> All those having sufficient software engineering technical competence
> can see this.
>

Click here to read the complete article

On 8/20/2022 2:32 PM, Richard Damon wrote:
>
> On 8/20/22 3:06 PM, olcott wrote:
>> On 8/20/2022 1:52 PM, Mr Flibble wrote:
>>> On Sat, 20 Aug 2022 13:50:15 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 8/20/2022 1:32 PM, Mr Flibble wrote:
>>>>> On Sat, 20 Aug 2022 10:23:58 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>> On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
>>>>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>>>>>> Olcott, which of the following do you think is more likely?
>>>>>>>>
>>>>>>>> 1) Olcott is correct and everybody else is wrong.
>>>>>>>> 2) Olcott is wrong and everybody else is correct.
>>>>>>>>
>>>>>>>> Which one is more likely hasn't changed for all the years you've
>>>>>>>> been attempting to shill your simulating halting decider. I find
>>>>>>>> it amusing that I came up with, in less than 24 hours, a
>>>>>>>> simulating halting decider that doesn't have the flaws your SHD
>>>>>>>> has.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>
>>>>>>> I have been following these discussions for many months now. I
>>>>>>> have a strong impression that there is little progress. It seems
>>>>>>> that people are running in circles. I am not an expert in this
>>>>>>> field. Maybe it helps if a non-expert tries to summarize the
>>>>>>> discussion. Please, be patient when correcting me if I make any
>>>>>>> mistake.
>>>>>>>
>>>>>>> First the problem this is al about:
>>>>>>> In computation theory we can denote a program with X and its input
>>>>>>> with Y, which together is denoted as X(Y). X(Y) may end (halt) in
>>>>>>> a finite number of steps, but another program X and/or input Y may
>>>>>>> not halt in a finite number of steps. The question is, is it
>>>>>>> possible to create a program H that when given any program X with
>>>>>>> its input Y can tell in a finite number of steps whether X(Y)
>>>>>>> halts or not? In other words, will H(X,Y) always halt after a
>>>>>>> finite number of steps with the correct answer for any X and Y?
>>>>>>>
>>>>>>> I hope that this is a correct formulation of the problem.
>>>>>>>
>>>>>>> The classical proof that it is not possible is the idea that it is
>>>>>>> always possible to create a program P that uses H, with itself as
>>>>>>> input, but behaves opposite to what H returns. In a C-like
>>>>>>> language it would be something like:
>>>>>>>
>>>>>>> void P(ptr x)
>>>>>>> {
>>>>>>>    int Halt_Status = H(x, x);
>>>>>>>    if (Halt_Status)
>>>>>>>        HERE: goto HERE;
>>>>>>>    return;
>>>>>>> }
>>>>>>>
>>>>>>> If there would be a hypothetical non-simulating non-aborting H,
>>>>>>> which would always halts with the correct answer, then it is clear
>>>>>>> that there would be a contradiction if we ask H about P with
>>>>>>> H(P,P). Because there are only three possibilities:
>>>>>>> 1. If H would return true (halting) in a finite number of steps,
>>>>>>> then P would start an endless loop, so H(P,P) does not halt in a
>>>>>>> finite number of steps.
>>>>>>> 2. If H would return false (non-halting) in a finite number of
>>>>>>> steps, then P returns immediately, so H returns a wrong result.
>>>>>>> 3. If H does not return, then it does not return in a finite
>>>>>>> number of steps, so it is not the H where the problem asked for.
>>>>>>>
>>>>>>> I think everybody agrees up to this point.
>>>>>>>
>>>>>>> Now Olcott has created a simulating aborting H, which, when given
>>>>>>> P with input P [so H(P,P)], creates a trace of the execution and
>>>>>>> at the point where P calls H, it uses the following logic: If H
>>>>>>> were the hypothetical non-aborting H, then an infinite recursion
>>>>>>> would happen at this point. Therefore, Olcott's simulating H
>>>>>>> aborts the simulation and returns false (0).
>>>>>>>
>>>>>>> Does everybody still agree up to this point?
>>>>>>>
>>>>>>> Now the opinions diverge.
>>>>>>> Olcott thinks that his H gives the correct answer that P would not
>>>>>>> halt when P would call the hypothetical non-aborting H, so, it
>>>>>>> must also be the correct answer when P actually calls the actual
>>>>>>> aborting H.
>>>>>>
>>>>>> *You did a very good job summing this up*
>>>>>> The key nuance of divergence is that halting means that when H(P,P)
>>>>>> correctly simulates its input that this input would reach the
>>>>>> "return" instruction (final state) of P. H(P,P) correctly
>>>>>> determines that its correct simulation of its input would never
>>>>>> reach the "return" instruction of P.
>>>>>>
>>>>>> *computation that halts* … the Turing machine will halt whenever it
>>>>>> enters a final state. (Linz:1990:234)
>>>>>>
>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>
>>>>>> When-so-ever the correct partial simulation of a machine
>>>>>> description correctly matches a correct infinite behavior pattern
>>>>>> then it is certain that this machine description specifies
>>>>>> infinite behavior.
>>>>>>
>>>>>> In other words the SHD decider correctly predicts that its correct
>>>>>> and complete simulation of its input would never reach the final
>>>>>> state of this input.
>>>>>>
>>>>>> *HERE IS THE SIMPLEST CASE OF THAT*
>>>>>> void Infinite_Loop()
>>>>>> {
>>>>>>      HERE: goto HERE;
>>>>>> }
>>>>>
>>>>> And here is a case where your H gets the answer wrong:
>>>>>
>>>>> void Px(void (*x)())
>>>>> {
>>>>>     (void) H(x, x);
>>>>>     return;
>>>>> }
>>>>>
>>>>> Px always halts if H returns to Px (and a valid halt decider must
>>>>> always return a decision to its caller).
>>>>>
>>>>> /Flibble
>>>>
>>>>
>>>> This one uses my prior version of H named HH where the infinitely
>>>> recursive simulation is easier to see.
>>>>
>>>> void Px(void (*x)())
>>>> {
>>>>     (void) HH(x, x);
>>>>     return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>     Output("Input_Halts = ", HH(Px, Px));
>>>> }
>>>>
>>>> _Px()
>>>> [000010b2](01) 55             push ebp
>>>> [000010b3](02) 8bec           mov ebp,esp
>>>> [000010b5](03) 8b4508         mov eax,[ebp+08]
>>>> [000010b8](01) 50             push eax
>>>> [000010b9](03) 8b4d08         mov ecx,[ebp+08]
>>>> [000010bc](01) 51             push ecx
>>>> [000010bd](05) e8e0fbffff     call 00000ca2
>>>> [000010c2](03) 83c408         add esp,+08
>>>> [000010c5](01) 5d             pop ebp
>>>> [000010c6](01) c3             ret
>>>> Size in bytes:(0021) [000010c6]
>>>>
>>>> _main()
>>>> [000010d2](01) 55             push ebp
>>>> [000010d3](02) 8bec           mov ebp,esp
>>>> [000010d5](05) 68b2100000     push 000010b2
>>>> [000010da](05) 68b2100000     push 000010b2
>>>> [000010df](05) e8befbffff     call 00000ca2
>>>> [000010e4](03) 83c408         add esp,+08
>>>> [000010e7](01) 50             push eax
>>>> [000010e8](05) 6863040000     push 00000463
>>>> [000010ed](05) e890f3ffff     call 00000482
>>>> [000010f2](03) 83c408         add esp,+08
>>>> [000010f5](02) 33c0           xor eax,eax
>>>> [000010f7](01) 5d             pop ebp
>>>> [000010f8](01) c3             ret
>>>> Size in bytes:(0039) [000010f8]
>>>>
>>>>    machine   stack     stack     machine    assembly
>>>>    address   address   data      code       language
>>>>    ======== ======== ======== ========= =============
>>>> [000010d2][00101b8d][00000000] 55             push ebp
>>>> [000010d3][00101b8d][00000000] 8bec           mov ebp,esp
>>>> [000010d5][00101b89][000010b2] 68b2100000     push 000010b2
>>>> [000010da][00101b85][000010b2] 68b2100000     push 000010b2
>>>> [000010df][00101b81][000010e4] e8befbffff     call 00000ca2
>>>> New slave_stack at:101c31
>>>>
>>>> Begin Local Halt Decider Simulation   Execution Trace Stored at:111c39
>>>> [000010b2][00111c25][00111c29] 55             push ebp
>>>> [000010b3][00111c25][00111c29] 8bec           mov ebp,esp
>>>> [000010b5][00111c25][00111c29] 8b4508         mov eax,[ebp+08]
>>>> [000010b8][00111c21][000010b2] 50             push eax       // push
>>>> Px [000010b9][00111c21][000010b2] 8b4d08         mov ecx,[ebp+08]
>>>> [000010bc][00111c1d][000010b2] 51             push ecx       // push
>>>> Px [000010bd][00111c19][000010c2] e8e0fbffff     call 00000ca2 //
>>>> call HH New slave_stack at:14c659
>>>> [000010b2][0015c64d][0015c651] 55             push ebp
>>>> [000010b3][0015c64d][0015c651] 8bec           mov ebp,esp
>>>> [000010b5][0015c64d][0015c651] 8b4508         mov eax,[ebp+08]
>>>> [000010b8][0015c649][000010b2] 50             push eax       // push
>>>> Px [000010b9][0015c649][000010b2] 8b4d08         mov ecx,[ebp+08]
>>>> [000010bc][0015c645][000010b2] 51             push ecx       // push
>>>> Px [000010bd][0015c641][000010c2] e8e0fbffff     call 00000ca2 //
>>>> call HH *Local Halt Decider: Infinite Recursion Detected Simulation
>>>> Stopped*
>>>>
>>>> *When HH(Px,Px) simulates its input it sees that*
>>>> (1) Function HH(Px,Px) is called twice in sequence from the same
>>>> machine address of Px().
>>>> (2) With the same arguments to HH(Px,Px).
>>>> (3) With no control flow instructions between the invocation of Px()
>>>> and its call to HH(Px,Px) that could possibly escape repeated
>>>> simulations.
>>>>
>>>> [000010e4][00101b8d][00000000] 83c408         add esp,+08
>>>> [000010e7][00101b89][00000000] 50             push eax
>>>> [000010e8][00101b85][00000463] 6863040000     push 00000463
>>>> [000010ed][00101b85][00000463] e890f3ffff     call 00000482
>>>> Input_Halts = 0
>>>> [000010f2][00101b8d][00000000] 83c408         add esp,+08
>>>> [000010f5][00101b8d][00000000] 33c0           xor eax,eax
>>>> [000010f7][00101b91][00000018] 5d             pop ebp
>>>> [000010f8][00101b95][00000000] c3             ret
>>>> Number of Instructions Executed(15322) == 229 Pages
>>>
>>> All your trace is doing is confirming that H gets the answer wrong, Px
>>> halts. Until you resolve this false positive you do not have a valid
>>> SHD.
>>>
>>> /Flibble
>>>
>>
>> void Px(void (*x)())
>> {
>>    (void) HH(x, x);
>>    return;
>> }
>>
>> int main()
>> {
>>    Output("Input_Halts = ", HH(Px, Px));
>> }
>>
>> Because HH is a simulating halt decider (SHD) it continues to perform
>> a pure x86 emulation of its input until it correctly matches a
>> non-halting behavior pattern proving that the simulated input would
>> never reach its own final state.
>>
>> (a) HH(Px,Px) simulates Px(Px) that calls a simulated HH(Px,Px)
>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>> *Until HH aborts its simulation*
>>
>> All those having sufficient software engineering technical competence
>> can see this.
>>
>
> And the correct and complete simulation of the input to HH(Px,Px) is
>
> (a) Simulate Px(Px) that calls a sumulated HH(Px,Px)
> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
> (e) that simulates Px(Px) that calls a simulated HH(Px,Px)
>
> *Until the SIMULATED HH from (a) abort ITS simulate.
> (f) returns 0 to the simulated Px(Px) from (a)
> (g) which returns, and thus Halts.
>
> Thus, the COMPLETE simulation of the input to HH, which we agree shows
> the actual behavior of the input to HH, comes to a Halt
>
> The HH(Px,Px) returning 0 is INCORRECT.

Click here to read the complete article

Op 20.aug..2022 om 17:23 schreef olcott:
> On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>> Olcott, which of the following do you think is more likely?
>>>
>>> 1) Olcott is correct and everybody else is wrong.
>>> 2) Olcott is wrong and everybody else is correct.
>>>
>>> Which one is more likely hasn't changed for all the years you've been
>>> attempting to shill your simulating halting decider. I find it amusing
>>> that I came up with, in less than 24 hours, a simulating halting
>>> decider that doesn't have the flaws your SHD has.
>>>
>>> /Flibble
>>>
>>
>> I have been following these discussions for many months now. I have a
>> strong impression that there is little progress. It seems that people
>> are running in circles. I am not an expert in this field. Maybe it
>> helps if a non-expert tries to summarize the discussion. Please, be
>> patient when correcting me if I make any mistake.
>>
>> First the problem this is al about:
>> In computation theory we can denote a program with X and its input
>> with Y, which together is denoted as X(Y). X(Y) may end (halt) in a
>> finite number of steps, but another program X and/or input Y may not
>> halt in a finite number of steps. The question is, is it possible to
>> create a program H that when given any program X with its input Y can
>> tell in a finite number of steps whether X(Y) halts or not? In other
>> words, will H(X,Y) always halt after a finite number of steps with the
>> correct answer for any X and Y?
>>
>> I hope that this is a correct formulation of the problem.
>>
>> The classical proof that it is not possible is the idea that it is
>> always possible to create a program P that uses H, with itself as
>> input, but behaves opposite to what H returns. In a C-like language it
>> would be something like:
>>
>> void P(ptr x)
>> {
>>    int Halt_Status = H(x, x);
>>    if (Halt_Status)
>>      HERE: goto HERE;
>>    return;
>> }
>>
>> If there would be a hypothetical non-simulating non-aborting H, which
>> would always halts with the correct answer, then it is clear that
>> there would be a contradiction if we ask H about P with H(P,P).
>> Because there are only three possibilities:
>> 1. If H would return true (halting) in a finite number of steps, then
>> P would start an endless loop, so H(P,P) does not halt in a finite
>> number of steps.
>> 2. If H would return false (non-halting) in a finite number of steps,
>> then P returns immediately, so H returns a wrong result.
>> 3. If H does not return, then it does not return in a finite number of
>> steps, so it is not the H where the problem asked for.
>>
>> I think everybody agrees up to this point.
>>
>> Now Olcott has created a simulating aborting H, which, when given P
>> with input P [so H(P,P)], creates a trace of the execution and at the
>> point where P calls H, it uses the following logic: If H were the
>> hypothetical non-aborting H, then an infinite recursion would happen
>> at this point. Therefore, Olcott's simulating H aborts the simulation
>> and returns false (0).
>>
>> Does everybody still agree up to this point?
>>
>> Now the opinions diverge.
>> Olcott thinks that his H gives the correct answer that P would not
>> halt when P would call the hypothetical non-aborting H, so, it must
>> also be the correct answer when P actually calls the actual aborting H.
>>
>
> *You did a very good job summing this up* > The key nuance of divergence is that halting means that when H(P,P)
> correctly simulates its input that this input would reach the "return"
> instruction (final state) of P. H(P,P) correctly determines that its
> correct simulation of its input would never reach the "return"
> instruction of P.
>

Thanks for the confirmation, because I was not completely sure about my
last sentence above. But I am glad that I understood you correctly that
your aborting H answers the question for P calling the hypothetical
non-aborting H.

You derive the final answer (for P calling the actual aborting H)
indirectly from the first answer, because it cannot be answered
directly, as it would not reach the return instruction.

On 8/20/2022 2:27 PM, Richard Damon wrote:
>
> On 8/20/22 3:00 PM, olcott wrote:
>> On 8/20/2022 1:32 PM, Richard Damon wrote:
>>> On 8/20/22 11:01 AM, Fred. Zwarts wrote:
>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>>> Olcott, which of the following do you think is more likely?
>>>>>
>>>>> 1) Olcott is correct and everybody else is wrong.
>>>>> 2) Olcott is wrong and everybody else is correct.
>>>>>
>>>>> Which one is more likely hasn't changed for all the years you've been
>>>>> attempting to shill your simulating halting decider. I find it
>>>>> amusing
>>>>> that I came up with, in less than 24 hours, a simulating halting
>>>>> decider that doesn't have the flaws your SHD has.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> I have been following these discussions for many months now. I have
>>>> a strong impression that there is little progress. It seems that
>>>> people are running in circles. I am not an expert in this field.
>>>> Maybe it helps if a non-expert tries to summarize the discussion.
>>>> Please, be patient when correcting me if I make any mistake.
>>>>
>>>> First the problem this is al about:
>>>> In computation theory we can denote a program with X and its input
>>>> with Y, which together is denoted as X(Y). X(Y) may end (halt) in a
>>>> finite number of steps, but another program X and/or input Y may not
>>>> halt in a finite number of steps. The question is, is it possible to
>>>> create a program H that when given any program X with its input Y
>>>> can tell in a finite number of steps whether X(Y) halts or not? In
>>>> other words, will H(X,Y) always halt after a finite number of steps
>>>> with the correct answer for any X and Y?
>>>>
>>>> I hope that this is a correct formulation of the problem.
>>>>
>>>> The classical proof that it is not possible is the idea that it is
>>>> always possible to create a program P that uses H, with itself as
>>>> input, but behaves opposite to what H returns. In a C-like language
>>>> it would be something like:
>>>>
>>>> void P(ptr x)
>>>> {
>>>>    int Halt_Status = H(x, x);
>>>>    if (Halt_Status)
>>>>      HERE: goto HERE;
>>>>    return;
>>>> }
>>>>
>>>> If there would be a hypothetical non-simulating non-aborting H,
>>>> which would always halts with the correct answer, then it is clear
>>>> that there would be a contradiction if we ask H about P with H(P,P).
>>>> Because there are only three possibilities:
>>>> 1. If H would return true (halting) in a finite number of steps,
>>>> then P would start an endless loop, so H(P,P) does not halt in a
>>>> finite number of steps.
>>>> 2. If H would return false (non-halting) in a finite number of
>>>> steps, then P returns immediately, so H returns a wrong result.
>>>> 3. If H does not return, then it does not return in a finite number
>>>> of steps, so it is not the H where the problem asked for.
>>>>
>>>> I think everybody agrees up to this point.
>>>>
>>>> Now Olcott has created a simulating aborting H, which, when given P
>>>> with input P [so H(P,P)], creates a trace of the execution and at
>>>> the point where P calls H, it uses the following logic: If H were
>>>> the hypothetical non-aborting H, then an infinite recursion would
>>>> happen at this point. Therefore, Olcott's simulating H aborts the
>>>> simulation and returns false (0).
>>>>
>>>> Does everybody still agree up to this point?
>>>>
>>>> Now the opinions diverge.
>>>> Olcott thinks that his H gives the correct answer that P would not
>>>> halt when P would call the hypothetical non-aborting H, so, it must
>>>> also be the correct answer when P actually calls the actual aborting H.
>>>>
>>>> Others have a different opinion and argue that P does not call the
>>>> hypothetical non-aborting H, but the actual aborting H, which does
>>>> not go in infinite recursion, but returns false in a finite number
>>>> of steps. Therefore, H's result is wrong.
>>>>
>>>> Is this a correct summary of the disagreement? If not, please, tell
>>>> me where the summary failed. Maybe we can then find the point of
>>>> divergence of opinions easier.
>>>>
>>>
>>> The key point is the conventional proof doesn't assume a
>>> "Non-simulating" decider, but ANY decider, no matter how it
>>> determines its answer.
>>>
>>> The key error of Olcott, is the mistaken idea that just because H
>>> happens to be a simulating Halt Decider, it gets to change the
>>> criteria that it needs to decide on, and rather than being does the
>>> computation the input represents [that is M(x) for a call to H(M,x)
>>> ], halt or never halt, but can we decide instead of on a did "H need
>>> to abort its simulation" criteria, and that this "need" affect EVERY
>>> COPY of H that exists in the world. (He confuses that last point by
>>> mashing the code of the decided program and the decider into a single
>>> program and having the decided program share code with the decider
>>> instead of being an independent copy, as it would need to be to
>>> actually implement as Turing Machines.
>>>
>>> Because of this, H is actually deciding on the wrong input, the H
>>> that aborts is actually reporting the results of the input program P
>>> built on the H that doesn't abort, which is a different input then
>>> the input program P built on the H that does abort.
>>
>>
>> It is common knowledge that the correct and complete simulation of a
>> machine description always provides the actual behavior specified by
>> this machine description.
>
> Right. COMPLETE.
>
> The H that answers non-halting does NOT do a COMPLETE simulation of its
> input.
>
> If that input is given to a UTM equivalent, the COMPLETE simulation of
> that input (which still calls H) will Halt.
>
> THUS, H was wrong.
>
>>
>> That you and others reject this when it is applied to my simulating
>> halt decider implicitly rejects the notion of a UTM. Since you and
>> others do accept the notion of a UTM, I have just proven that your
>> reasoning is incoherent and/or inconsistent.
>
> Becaue you have no H that answers non-Halting that also has a COMPLETE
> simulation of its input that will not halt even after an unbounded
> number of steps.
>
>>
>> Whenever the simulating halt decider correctly predicts that its
>> correct and complete simulation of its input would never reach the
>> final state of this input, then the SHD is correct to reject its input
>> as non-halting.
>
> FALSE.
>
> IF it doesn't actually DO a complete simulation, talking about what the
> complete simulation it would do is MEANINGLESS.
>
> You H is answering about a different input then the one given to it.
>
>>
>> *HERE IS THE SIMPLEST CASE OF THAT*
>> void Infinite_Loop()
>> {
>>    HERE: goto HERE;
>> }
>>
>> int main()
>> {
>>    Output("Input_Halts = ", H0((u32)Infinite_Loop));
>> }
>>
>> _Infinite_Loop()
>> [00001102](01) 55         push ebp
>> [00001103](02) 8bec       mov ebp,esp
>> [00001105](02) ebfe       jmp 00001105
>> [00001107](01) 5d         pop ebp
>> [00001108](01) c3         ret
>> Size in bytes:(0007) [00001108]
>>
>>
>>
>
> Red Herring.
>
> Fallacy of Proof by Exampe.

When-so-ever a simulating halt decider (SHD) correctly performs a
partial simulation of its input and the behavior of this partial
simulation correctly matches a non-halting behavior pattern then the
SHD halt decider can correctly report non-halting.

A non-halting behavior pattern is correct when-so-ever matching this
behavior pattern proves that the correct and complete simulation of the
input by SHD would never reach the final state of this simulated input.

Click here to read the complete article

On 8/20/2022 3:00 PM, Fred. Zwarts wrote:
> Op 20.aug..2022 om 17:23 schreef olcott:
>> On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>> Olcott, which of the following do you think is more likely?
>>>>
>>>> 1) Olcott is correct and everybody else is wrong.
>>>> 2) Olcott is wrong and everybody else is correct.
>>>>
>>>> Which one is more likely hasn't changed for all the years you've been
>>>> attempting to shill your simulating halting decider. I find it amusing
>>>> that I came up with, in less than 24 hours, a simulating halting
>>>> decider that doesn't have the flaws your SHD has.
>>>>
>>>> /Flibble
>>>>
>>>
>>> I have been following these discussions for many months now. I have a
>>> strong impression that there is little progress. It seems that people
>>> are running in circles. I am not an expert in this field. Maybe it
>>> helps if a non-expert tries to summarize the discussion. Please, be
>>> patient when correcting me if I make any mistake.
>>>
>>> First the problem this is al about:
>>> In computation theory we can denote a program with X and its input
>>> with Y, which together is denoted as X(Y). X(Y) may end (halt) in a
>>> finite number of steps, but another program X and/or input Y may not
>>> halt in a finite number of steps. The question is, is it possible to
>>> create a program H that when given any program X with its input Y can
>>> tell in a finite number of steps whether X(Y) halts or not? In other
>>> words, will H(X,Y) always halt after a finite number of steps with
>>> the correct answer for any X and Y?
>>>
>>> I hope that this is a correct formulation of the problem.
>>>
>>> The classical proof that it is not possible is the idea that it is
>>> always possible to create a program P that uses H, with itself as
>>> input, but behaves opposite to what H returns. In a C-like language
>>> it would be something like:
>>>
>>> void P(ptr x)
>>> {
>>>    int Halt_Status = H(x, x);
>>>    if (Halt_Status)
>>>      HERE: goto HERE;
>>>    return;
>>> }
>>>
>>> If there would be a hypothetical non-simulating non-aborting H, which
>>> would always halts with the correct answer, then it is clear that
>>> there would be a contradiction if we ask H about P with H(P,P).
>>> Because there are only three possibilities:
>>> 1. If H would return true (halting) in a finite number of steps, then
>>> P would start an endless loop, so H(P,P) does not halt in a finite
>>> number of steps.
>>> 2. If H would return false (non-halting) in a finite number of steps,
>>> then P returns immediately, so H returns a wrong result.
>>> 3. If H does not return, then it does not return in a finite number
>>> of steps, so it is not the H where the problem asked for.
>>>
>>> I think everybody agrees up to this point.
>>>
>>> Now Olcott has created a simulating aborting H, which, when given P
>>> with input P [so H(P,P)], creates a trace of the execution and at the
>>> point where P calls H, it uses the following logic: If H were the
>>> hypothetical non-aborting H, then an infinite recursion would happen
>>> at this point. Therefore, Olcott's simulating H aborts the simulation
>>> and returns false (0).
>>>
>>> Does everybody still agree up to this point?
>>>
>>> Now the opinions diverge.
>>> Olcott thinks that his H gives the correct answer that P would not
>>> halt when P would call the hypothetical non-aborting H, so, it must
>>> also be the correct answer when P actually calls the actual aborting H.
>>>
>>
>> *You did a very good job summing this up* > The key nuance of
>> divergence is that halting means that when H(P,P)
>> correctly simulates its input that this input would reach the "return"
>> instruction (final state) of P. H(P,P) correctly determines that its
>> correct simulation of its input would never reach the "return"
>> instruction of P.
>>
>
> Thanks for the confirmation, because I was not completely sure about my
> last sentence above. But I am glad that I understood you correctly that
> your aborting H answers the question for P calling the hypothetical
> non-aborting H.
>
> You derive the final answer (for P calling the actual aborting H)
> indirectly from the first answer, because it cannot be answered
> directly, as it would not reach the return instruction.
>

*Here is my newly revised clearer explanation*

*computation that halts* … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)

The above system equally applies to all non-halting inputs explicitly
including the pathological input defined below:

*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.

For any program H that might determine if programs halt, a
"pathological" program P, called with some input, can pass its own
source and its input to H and then specifically do the opposite of
what H predicts P will do. *No H can exist that handles this case*
https://en.wikipedia.org/wiki/Halting_problem

*Linz, Peter 1990*. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)

*Two more inputs that are correctly decided using this same system*

void Infinite_Loop()
{ HERE: goto HERE;
}

void Infinite_Recursion(int N)
{ Infinite_Recursion(N);
}

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

On Sat, 20 Aug 2022 15:20:41 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 8/20/2022 3:00 PM, Fred. Zwarts wrote:
> > Op 20.aug..2022 om 17:23 schreef olcott:
> >> On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
> >>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
> >>>> Olcott, which of the following do you think is more likely?
> >>>>
> >>>> 1) Olcott is correct and everybody else is wrong.
> >>>> 2) Olcott is wrong and everybody else is correct.
> >>>>
> >>>> Which one is more likely hasn't changed for all the years you've
> >>>> been attempting to shill your simulating halting decider. I
> >>>> find it amusing that I came up with, in less than 24 hours, a
> >>>> simulating halting decider that doesn't have the flaws your SHD
> >>>> has.
> >>>>
> >>>> /Flibble
> >>>>
> >>>
> >>> I have been following these discussions for many months now. I
> >>> have a strong impression that there is little progress. It seems
> >>> that people are running in circles. I am not an expert in this
> >>> field. Maybe it helps if a non-expert tries to summarize the
> >>> discussion. Please, be patient when correcting me if I make any
> >>> mistake.
> >>>
> >>> First the problem this is al about:
> >>> In computation theory we can denote a program with X and its
> >>> input with Y, which together is denoted as X(Y). X(Y) may end
> >>> (halt) in a finite number of steps, but another program X and/or
> >>> input Y may not halt in a finite number of steps. The question
> >>> is, is it possible to create a program H that when given any
> >>> program X with its input Y can tell in a finite number of steps
> >>> whether X(Y) halts or not? In other words, will H(X,Y) always
> >>> halt after a finite number of steps with the correct answer for
> >>> any X and Y?
> >>>
> >>> I hope that this is a correct formulation of the problem.
> >>>
> >>> The classical proof that it is not possible is the idea that it
> >>> is always possible to create a program P that uses H, with itself
> >>> as input, but behaves opposite to what H returns. In a C-like
> >>> language it would be something like:
> >>>
> >>> void P(ptr x)
> >>> {
> >>>    int Halt_Status = H(x, x);
> >>>    if (Halt_Status)
> >>>      HERE: goto HERE;
> >>>    return;
> >>> }
> >>>
> >>> If there would be a hypothetical non-simulating non-aborting H,
> >>> which would always halts with the correct answer, then it is
> >>> clear that there would be a contradiction if we ask H about P
> >>> with H(P,P). Because there are only three possibilities:
> >>> 1. If H would return true (halting) in a finite number of steps,
> >>> then P would start an endless loop, so H(P,P) does not halt in a
> >>> finite number of steps.
> >>> 2. If H would return false (non-halting) in a finite number of
> >>> steps, then P returns immediately, so H returns a wrong result.
> >>> 3. If H does not return, then it does not return in a finite
> >>> number of steps, so it is not the H where the problem asked for.
> >>>
> >>> I think everybody agrees up to this point.
> >>>
> >>> Now Olcott has created a simulating aborting H, which, when given
> >>> P with input P [so H(P,P)], creates a trace of the execution and
> >>> at the point where P calls H, it uses the following logic: If H
> >>> were the hypothetical non-aborting H, then an infinite recursion
> >>> would happen at this point. Therefore, Olcott's simulating H
> >>> aborts the simulation and returns false (0).
> >>>
> >>> Does everybody still agree up to this point?
> >>>
> >>> Now the opinions diverge.
> >>> Olcott thinks that his H gives the correct answer that P would
> >>> not halt when P would call the hypothetical non-aborting H, so,
> >>> it must also be the correct answer when P actually calls the
> >>> actual aborting H.
> >>
> >> *You did a very good job summing this up* > The key nuance of
> >> divergence is that halting means that when H(P,P)
> >> correctly simulates its input that this input would reach the
> >> "return" instruction (final state) of P. H(P,P) correctly
> >> determines that its correct simulation of its input would never
> >> reach the "return" instruction of P.
> >>
> >
> > Thanks for the confirmation, because I was not completely sure
> > about my last sentence above. But I am glad that I understood you
> > correctly that your aborting H answers the question for P calling
> > the hypothetical non-aborting H.
> >
> > You derive the final answer (for P calling the actual aborting H)
> > indirectly from the first answer, because it cannot be answered
> > directly, as it would not reach the return instruction.
> >
>
> *Here is my newly revised clearer explanation*
>
> When-so-ever a simulating halt decider (SHD) correctly performs a
> partial simulation of its input and the behavior of this partial
> simulation correctly matches a non-halting behavior pattern then the
> SHD halt decider can correctly report non-halting.
>
> *computation that halts* … the Turing machine will halt whenever it
> enters a final state. (Linz:1990:234)
>
> A non-halting behavior pattern is correct when-so-ever matching this
> behavior pattern proves that the correct and complete simulation of
> the input by SHD would never reach the final state of this simulated
> input.
>
> The above system equally applies to all non-halting inputs explicitly
> including the pathological input defined below:
>
> *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.
>
> For any program H that might determine if programs halt, a
> "pathological" program P, called with some input, can pass its
> own source and its input to H and then specifically do the opposite of
> what H predicts P will do. *No H can exist that handles this
> case* https://en.wikipedia.org/wiki/Halting_problem
>
> *Linz, Peter 1990*. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company. (317-320)
>
> *Two more inputs that are correctly decided using this same system*
>
> void Infinite_Loop()
> {
> HERE: goto HERE;
> }
>
> void Infinite_Recursion(int N)
> {
> Infinite_Recursion(N);
> }

Your halting decider gets the answer wrong for Px ergo it is
invalid.

/Flibble

"Fred. Zwarts" <F.Zwarts@KVI.nl> writes:

> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>> Olcott, which of the following do you think is more likely?
>> 1) Olcott is correct and everybody else is wrong.
>> 2) Olcott is wrong and everybody else is correct.
>> Which one is more likely hasn't changed for all the years you've been
>> attempting to shill your simulating halting decider. I find it amusing
>> that I came up with, in less than 24 hours, a simulating halting
>> decider that doesn't have the flaws your SHD has.
>> /Flibble
>>
>
> I have been following these discussions for many months now. I have a
> strong impression that there is little progress. It seems that people
> are running in circles. I am not an expert in this field. Maybe it
> helps if a non-expert tries to summarize the discussion. Please, be
> patient when correcting me if I make any mistake.
>
> First the problem this is al about: In computation theory we can
> denote a program with X and its input with Y, which together is
> denoted as X(Y). X(Y) may end (halt) in a finite number of steps, but
> another program X and/or input Y may not halt in a finite number of
> steps. The question is, is it possible to create a program H that when
> given any program X with its input Y can tell in a finite number of
> steps whether X(Y) halts or not? In other words, will H(X,Y) always
> halt after a finite number of steps with the correct answer for any X
> and Y?
>
> I hope that this is a correct formulation of the problem.

Yes, that's a reasonable summary. PO knows that no such H is possible
so he is just pushing two silly arguments: (a) that H(X,Y) == false for
at least one X and Y where X(Y) halts is correct, despite it being
clearly wrong; and (b) that even specifying that H(X,Y) must answer
about X(Y), rather than something else that he's made up, is wrong.

Both objections are risible, yet that have managed to generate a lot of
posts!

The fuel for all the debate comes from the fact that PO has wisely
abandoned talking about Turing machines because there was not enough
room for confusion. After all, formal models of computation are
designed to facilitate clear and un-ambiguous proofs.

> The classical proof that it is not possible is the idea that it is
> always possible to create a program P that uses H, with itself as
> input, but behaves opposite to what H returns. In a C-like language it
> would be something like:
>
> void P(ptr x)
> {
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return;
> }
>
> If there would be a hypothetical non-simulating non-aborting H, which
> would always halts with the correct answer, then it is clear that
> there would be a contradiction if we ask H about P with
> H(P,P). Because there are only three possibilities:
> 1. If H would return true (halting) in a finite number of steps, then
> P would start an endless loop, so H(P,P) does not halt in a finite
> number of steps.
> 2. If H would return false (non-halting) in a finite number of steps,
> then P returns immediately, so H returns a wrong result.
> 3. If H does not return, then it does not return in a finite number of
> steps, so it is not the H where the problem asked for.
>
> I think everybody agrees up to this point.

No. PO rejects the very definition of the problem he is pretending to
care about. There is absolutely no dispute about the facts that (1)
H(P,P) == false and (2) P(P) halts.

Every post in reply to PO should start and stop with that fact. There
is nothing else to talk about.

> Now Olcott has created a simulating aborting H, which, when given P
> with input P [so H(P,P)], creates a trace of the execution and at the
> point where P calls H, it uses the following logic: If H were the
> hypothetical non-aborting H, then an infinite recursion would happen
> at this point. Therefore, Olcott's simulating H aborts the simulation
> and returns false (0).
>
> Does everybody still agree up to this point?

That's his ruse, yes, but you should not be colluding with the idea that
what "would happen if" is in any way relevant to the halting problem.
He's been trying to sneak this trick past credulous readers for years in
many different disguises. P(P) halts, but it wouldn't if... is not
maths but junk. 33 would be prime if it weren't divisible by 3 and 11.

> Now the opinions diverge.

They diverged long before this! PO rejects the very idea that a halt
decider might tell up what we want to know: that H(X,Y) == false if, and
only if, X(Y) does not halt.

> Olcott thinks that his H gives the correct answer that P would not
> halt when P would call the hypothetical non-aborting H, so, it must
> also be the correct answer when P actually calls the actual aborting
> H.

He may think that. I doubt his mind is that clear. After years of
coming up with ever more obscure what to justify the wrong answer, he
has toughly confused himself.

Someone my think that but, as you can see from your definition of the
halting problem at the top of this post, H is wrong, not by virtue of
anything it does, but because it simply does not meet the definition of
a halt decider (even if it's only in this one instance).

> Is this a correct summary of the disagreement? If not, please, tell me
> where the summary failed. Maybe we can then find the point of
> divergence of opinions easier.

You won't even get PO to agree to your problem definition because he
does not dispute the fact (and we not have the source code to see for
ourselves) that H(P,P) == false even though P(P) halts. These
undisputed facts should, in my opinion, be the start and end of every
reply to PO.

--
Ben.

On 8/20/2022 3:53 PM, Ben Bacarisse wrote:
> "Fred. Zwarts" <F.Zwarts@KVI.nl> writes:
>
>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>> Olcott, which of the following do you think is more likely?
>>> 1) Olcott is correct and everybody else is wrong.
>>> 2) Olcott is wrong and everybody else is correct.
>>> Which one is more likely hasn't changed for all the years you've been
>>> attempting to shill your simulating halting decider. I find it amusing
>>> that I came up with, in less than 24 hours, a simulating halting
>>> decider that doesn't have the flaws your SHD has.
>>> /Flibble
>>>
>>
>> I have been following these discussions for many months now. I have a
>> strong impression that there is little progress. It seems that people
>> are running in circles. I am not an expert in this field. Maybe it
>> helps if a non-expert tries to summarize the discussion. Please, be
>> patient when correcting me if I make any mistake.
>>
>> First the problem this is al about: In computation theory we can
>> denote a program with X and its input with Y, which together is
>> denoted as X(Y). X(Y) may end (halt) in a finite number of steps, but
>> another program X and/or input Y may not halt in a finite number of
>> steps. The question is, is it possible to create a program H that when
>> given any program X with its input Y can tell in a finite number of
>> steps whether X(Y) halts or not? In other words, will H(X,Y) always
>> halt after a finite number of steps with the correct answer for any X
>> and Y?
>>
>> I hope that this is a correct formulation of the problem.
>
> Yes, that's a reasonable summary. PO knows that no such H is possible
> so he is just pushing two silly arguments: (a) that H(X,Y) == false for
> at least one X and Y where X(Y) halts is correct, despite it being
> clearly wrong; and (b) that even specifying that H(X,Y) must answer
> about X(Y), rather than something else that he's made up, is wrong.
>
> Both objections are risible, yet that have managed to generate a lot of
> posts!
>
> The fuel for all the debate comes from the fact that PO has wisely
> abandoned talking about Turing machines because there was not enough
> room for confusion. After all, formal models of computation are
> designed to facilitate clear and un-ambiguous proofs.
>
>> The classical proof that it is not possible is the idea that it is
>> always possible to create a program P that uses H, with itself as
>> input, but behaves opposite to what H returns. In a C-like language it
>> would be something like:
>>
>> void P(ptr x)
>> {
>> int Halt_Status = H(x, x);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return;
>> }
>>
>> If there would be a hypothetical non-simulating non-aborting H, which
>> would always halts with the correct answer, then it is clear that
>> there would be a contradiction if we ask H about P with
>> H(P,P). Because there are only three possibilities:
>> 1. If H would return true (halting) in a finite number of steps, then
>> P would start an endless loop, so H(P,P) does not halt in a finite
>> number of steps.
>> 2. If H would return false (non-halting) in a finite number of steps,
>> then P returns immediately, so H returns a wrong result.
>> 3. If H does not return, then it does not return in a finite number of
>> steps, so it is not the H where the problem asked for.
>>
>> I think everybody agrees up to this point.
>
> No. PO rejects the very definition of the problem he is pretending to
> care about. There is absolutely no dispute about the facts that (1)
> H(P,P) == false and (2) P(P) halts.
>
> Every post in reply to PO should start and stop with that fact. There
> is nothing else to talk about.
>
>> Now Olcott has created a simulating aborting H, which, when given P
>> with input P [so H(P,P)], creates a trace of the execution and at the
>> point where P calls H, it uses the following logic: If H were the
>> hypothetical non-aborting H, then an infinite recursion would happen
>> at this point. Therefore, Olcott's simulating H aborts the simulation
>> and returns false (0).
>>
>> Does everybody still agree up to this point?
>
> That's his ruse, yes, but you should not be colluding with the idea that
> what "would happen if" is in any way relevant to the halting problem.
> He's been trying to sneak this trick past credulous readers for years in
> many different disguises. P(P) halts, but it wouldn't if... is not
> maths but junk. 33 would be prime if it weren't divisible by 3 and 11.
>
>> Now the opinions diverge.
>
> They diverged long before this! PO rejects the very idea that a halt
> decider might tell up what we want to know: that H(X,Y) == false if, and
> only if, X(Y) does not halt.
>
>> Olcott thinks that his H gives the correct answer that P would not
>> halt when P would call the hypothetical non-aborting H, so, it must
>> also be the correct answer when P actually calls the actual aborting
>> H.
>
> He may think that. I doubt his mind is that clear. After years of
> coming up with ever more obscure what to justify the wrong answer, he
> has toughly confused himself.
>
>> Others have a different opinion and argue that P does not call the
>> hypothetical non-aborting H, but the actual aborting H, which does not
>> go in infinite recursion, but returns false in a finite number of
>> steps. Therefore, H's result is wrong.
>
> Someone my think that but, as you can see from your definition of the
> halting problem at the top of this post, H is wrong, not by virtue of
> anything it does, but because it simply does not meet the definition of
> a halt decider (even if it's only in this one instance).
>
>> Is this a correct summary of the disagreement? If not, please, tell me
>> where the summary failed. Maybe we can then find the point of
>> divergence of opinions easier.
>
> You won't even get PO to agree to your problem definition because he
> does not dispute the fact (and we not have the source code to see for
> ourselves) that H(P,P) == false even though P(P) halts. These
> undisputed facts should, in my opinion, be the start and end of every
> reply to PO.
>

It is common knowledge that the correct and complete simulation of a
machine description always provides the actual behavior specified by
this machine description.

*NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS NO ERROR*

When-so-ever a simulating halt decider (SHD) correctly performs a
partial simulation of its input and the behavior of this partial
simulation correctly matches a non-halting behavior pattern then the SHD
halt decider can correctly report non-halting.

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

/* Halley */ (Halley's comment.)

devel / comp.theory / Re: Olcott [good summation]

Subject	Author
Olcott	Mr Flibble
Olcott	olcott
Olcott	Mr Flibble
Olcott	Jeff Barnett
Olcott	Otto J. Makela
Olcott	olcott
Olcott	Fred. Zwarts
Olcott [good summation]	olcott
Olcott [good summation]	Mr Flibble
Olcott [good summation]	olcott
Olcott [good summation]	Mr Flibble
Olcott [good summation]	olcott
Olcott [good summation]	Mr Flibble
Olcott [good summation]	olcott
Olcott [good summation]	Mr Flibble
Olcott [good summation]	Richard Damon
Olcott [good summation]	olcott
Olcott [good summation]	Richard Damon
Olcott [good summation]	olcott
Olcott [good summation]	Richard Damon
Olcott [good summation]	olcott
Olcott [good summation]	Richard Damon
Olcott [good summation]	olcott
Olcott [good summation]	Richard Damon
Olcott [good summation]	olcott
Olcott [good summation]	Richard Damon
Olcott [good summation]	olcott
Olcott [good summation]	Richard Damon
Olcott [good summation]	olcott
Olcott [good summation]	Richard Damon
Olcott [good summation]	olcott
Olcott [good summation]	Richard Damon
Olcott [good summation]	olcott
Olcott [good summation]	Richard Damon
Olcott [good summation]	olcott
Olcott [good summation]	Richard Damon
Olcott [good summation]	dklei...@gmail.com
Olcott [good summation]	Richard Damon
Olcott [good summation]	olcott
Olcott [good summation]	dklei...@gmail.com
Olcott [good summation]	Ben Bacarisse
Olcott [good summation]	olcott
Olcott [good summation]	Richard Damon
Olcott [good summation]	olcott
Olcott [good summation]	Richard Damon
Olcott [good summation]	Jeff Barnett
Olcott [good summation]	Richard Damon
Olcott [good summation]	Fred. Zwarts
Olcott [good summation]	olcott
Olcott [good summation]	Mr Flibble
Olcott [good summation]	Richard Damon
Olcott [good summation]	Mikko
Olcott [good summation]	Richard Damon
Olcott [good summation]	Mikko
Olcott [good summation]	Richard Damon
Olcott [good summation]	olcott
Olcott [good summation]	Mikko
Olcott [good summation]	Richard Damon
Olcott [good summation]	Mikko
Olcott [good summation]	olcott
Olcott [good summation]	olcott
Olcott	Richard Damon
Olcott	olcott
Olcott	Richard Damon
Olcott	olcott
Olcott	Richard Damon
Olcott	olcott
Olcott	Richard Damon
Olcott	Ben Bacarisse
Olcott [ Ben is wrong ]	olcott
Olcott [ Ben is wrong ]	Richard Damon
Olcott [ Ben is wrong ]	Shvili, the Kookologist
Olcott [ Ben is wrong ]	olcott
Olcott [ Ben is wrong ]	Shvili, the Kookologist
Olcott [ Ben is wrong ]	Richard Damon
Olcott [ Ben contradicts himself ]	olcott
Olcott [ Ben contradicts himself ]	Richard Damon
Olcott [ Ben contradicts himself ]	olcott
Olcott [ Ben contradicts himself ]	Richard Damon
Olcott [ Ben contradicts himself ]	olcott
Olcott [ Ben contradicts himself ]	Richard Damon
Olcott [ Ben contradicts himself ]	olcott
Olcott [ Ben contradicts himself ]	Mr Flibble
Olcott [ Ben contradicts himself ]	olcott
Olcott [ Ben contradicts himself ]	Mr Flibble
Olcott [ Ben contradicts himself ]	olcott
Olcott [ Ben contradicts himself ]	Mr Flibble
Olcott [ Ben contradicts himself ]	olcott
Olcott [ Ben contradicts himself ]	Mr Flibble
Olcott [ Ben contradicts himself ]	olcott
Olcott [ Ben contradicts himself ]	Mr Flibble
Olcott [ Ben contradicts himself ]	olcott
Olcott [ Ben contradicts himself ]	Mr Flibble
Olcott [ Ben contradicts himself ]	olcott
Olcott [ Ben contradicts himself ]	Richard Damon
Olcott [ Ben contradicts himself ]	Skep Dick
Olcott [ Ben contradicts himself ]	Richard Damon
Olcott [ Ben contradicts himself ]	olcott
Olcott [ Ben contradicts himself ]	Richard Damon
Olcott [ Ben contradicts himself ] [ SHD defined ]	olcott
Olcott [ Ben contradicts himself ] [ SHD defined ]	Richard Damon
Olcott	Paul N
Olcott [ Ben is wrong ]	Shvili, the Kookologist
Olcott	Mikko