On 8/21/22 9:44 PM, olcott wrote:
> On 8/21/2022 8:12 PM, Richard Damon wrote:
>>
>> On 8/21/22 8:48 PM, olcott wrote:
>>> On 8/21/2022 1:09 PM, Richard Damon wrote:
>>>> On 8/21/22 9:30 AM, olcott wrote:
>>>>> On 8/21/2022 4:00 AM, Mikko wrote:
>>>>>> On 2022-08-20 15:01:34 +0000, Fred. Zwarts said:
>>>>>>
>>>>>>> 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?
>>>>>>
>>>>>> In the classical formulation X and H are Turing machines. Y is a
>>>>>> finite
>>>>>> string of symbols from some finite set. H(X,Y) denotes a
>>>>>> computation where
>>>>>> H is given a finite string that represents X and Y so that each
>>>>>> can be
>>>>>> reconstructed.
>>>>>>
>>>>>>> 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;
>>>>>>> }
>>>>>>
>>>>>> Roughly so but both P and H take a single string as argument:
>>>>>>
>>>>>> void P(string x)
>>>>>> {
>>>>>>   string arg = pair(x, x);
>>>>>>   boolean Halt_Status = H(arg);
>>>>>>   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.
>>>>>>
>>>>>> With Turing machines the possibilities are:
>>>>>> 1. H halts with the answer true.
>>>>>> 2. H halts with the answer false.
>>>>>> 3. H halts but answers neither true nor false.
>>>>>> 4. H does not halt.
>>>>>>
>>>>>> If 3 or 4 happens then H is not a halt decider, i.e., not a solution
>>>>>> to the problem. If H(P, P) halts with the answer true then P(P) does
>>>>>> not halt so H is not a halt decider. If H(P, P) halts with the
>>>>>> answer false then P(P) halts so H is not a halt decider.
>>>>>>
>>>>>> The restriction to non-simulating non-aborting H is not necessary.
>>>>>> The requirements are the same anyway.
>>>>>>
>>>>>>> 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?
>>>>>>
>>>>>> Yes, and everybody also agrees that P(P) halts.
>>>>>>
>>>>>
>>>>> It is common knowledge that the correct and complete simulation of
>>>>> a machine description always provides the actual behavior specified
>>>>> by this machine description.
>>>>>
>>>>> The correct and complete simulation by H(P,P) of its input would
>>>>> never reach its final state and halt, thus the input to H(P,P)
>>>>> specifies a non-halting sequence of instructions.
>>>
>>>> Which might make some sense, until we notice that the only H that
>>>> actually does a correct and complete simulation of its input, is the
>>>> H that doesn't abort its simulation and thus never answers so fails
>>>> to be a Halt Decider.
>>> *YOU JUST AREN'T BRIGHT ENOUGH TO COMPREHEND THIS*
>>> 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.
>>
>> What is the CORRECT non-halting pattern that the simulation of P(P)
>> correctly matched.
>>
>
> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
> (b) that simulates P(P) that calls a simulated H(P,P)
> (c) that simulates P(P) that calls a simulated H(P,P)
> (d) that simulates P(P) that calls a simulated H(P,P)...
> *Until H aborts its simulation*
>
>

Which isn't a correct non-halting pattern if H ever actually get to the
abort, and if it doesn't, then the input never matched the pattern and H
fails to answer.

The key is that that ACTUAL correct simulation of that input would then be:

(@) Simulate(P,P) simulates P(P) that calls a simulated H(P,P)
(a) that simulates P(P) that calls a simulated H(P,P)
(b) that simulates P(P) that calls a simulated H(P,P)
(c) that simulates P(P) that calls a simulated H(P,P)
(d) that simulates P(P) that calls a simulated H(P,P)...
*Until the H simulated in step (@) aborts its simulation*
(e) That simulated H returns 0 to the simulate P(P) in (@)
(f) That simulated P(P) returns and thus halts.

What step of that simulation is incorrect?

Which x86 instruction did it not simulate correctly?

Remember, you just provided in YOUR (a) - (d) a claimed correct exection
trace of H(P,P), so that trace is a correct part of the simulation of
the P(P) that calls that H(P,P)

If you disagree, prove otherwise and point out the ACTUAL INSTRUCTION
that the above doesn't match

PUT UP OR SHUT UP or be proved a liar.

Note, in your pattern, the beginning

"(a) H(P,P) simulates" isn't actually part of the simulation of the
input, as a correct simultion of an input is independent of what
simulates it, it just matters what rules have been defined for the
simulation.

You have fully defined that by stating it is an x86 simulation of the
code of P that has been provided. (Which must include the code of H, or
it doesn't actually specify the computation).