On 8/14/21 5:57 PM, olcott wrote:
> On 8/14/2021 4:48 PM, Richard Damon wrote:
>> On 8/14/21 5:09 PM, olcott wrote:
>>> On 8/14/2021 4:06 PM, Richard Damon wrote:
>>>> On 8/14/21 4:52 PM, olcott wrote:
>>>>> On 8/14/2021 3:39 PM, Richard Damon wrote:
>>>>>> On 8/14/21 2:33 PM, olcott wrote:
>>>>>>> On 8/14/2021 12:10 PM, Richard Damon wrote:
>>>>>>>> On 8/14/21 12:16 PM, olcott wrote:
>>>>>>>>> On 8/14/2021 11:05 AM, wij wrote:
>>>>>>>>>> On Saturday, 14 August 2021 at 23:18:03 UTC+8, olcott wrote:
>>>>>>>>>>> This exact same analysis always applies to the input to
>>>>>>>>>>> H(P,P) no
>>>>>>>>>>> matter
>>>>>>>>>>> how it is called including this example:
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>> P((u32)P);
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> the Turing machine halting problem. Simply stated, the problem
>>>>>>>>>>> is: given the description of a Turing machine M and an input w,
>>>>>>>>>>> does M, when started in the initial configuration q0w, perform a
>>>>>>>>>>> computation that eventually halts? (Linz:1990:317).
>>>>>>>>>>>
>>>>>>>>>>> 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. https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>
>>>>>>>>>>> Because the halting problem only requires that the (at least
>>>>>>>>>>> partial)
>>>>>>>>>>> halt decider decide its input correctly the fact that the direct
>>>>>>>>>>> invocation of P(P) is not an input to H, means that it is not
>>>>>>>>>>> relevant
>>>>>>>>>>> to the halting problem.
>>>>>>>>>>       I do not know English well, but I (almost every
>>>>>>>>>> programmer) am
>>>>>>>>>> sure
>>>>>>>>>> the halting
>>>>>>>>>> problem means a program H decides whether P(input) will halt or
>>>>>>>>>> not.
>>>>>>>>>> If the quoted texts is read to you differently, it is the
>>>>>>>>>> problem of
>>>>>>>>>> that texts.
>>>>>>>>>> Submit message to the authors.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The quoted texts are accurate. The (at least partial) halt decider
>>>>>>>>> must
>>>>>>>>> only correctly decide the halt status of its input. Computations
>>>>>>>>> that
>>>>>>>>> are not inputs to the halt decider do not pertain to the halting
>>>>>>>>> problem.
>>>>>>>>>
>>>>>>>>
>>>>>>>> This is the point where you use of English is incorrect, and you
>>>>>>>> need to
>>>>>>>> restudy English so you understand what you are saying.
>>>>>>>>
>>>>>>>> *Inputs* are NEVER *Computations* in and of themselves, but are
>>>>>>>> merely
>>>>>>>> the string representations of the ACTUAL Computations.
>>>>>>>>
>>>>>>>> As such, 'inputs' don't halt or be non-halting, only the machines
>>>>>>>> they
>>>>>>>> represent.
>>>>>>> The input "description of an arbitrary computer program" is the
>>>>>>> basis
>>>>>>> for the halt status decision.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> The input is what the program uses to make its decision, the right
>>>>>> answer is what the actual machine does.
>>>>>>
>>>>>
>>>>> Because the input to H(P,P) is at a different point int the execution
>>>>> trace than the P of int main(){ P(P); } it is a different computation
>>>>> having different behavior than the input to H(P,P).
>>>>
>>>> What 'point'. The question is will the computation finish or not.
>>>>
>>> When trying to prove that I do not own a white cat, proof that I do not
>>> own a black dog does not count.
>>>
>>> The two distinctly different computations have different halting
>>> behavior.
>>>
>>
>> Right, so we want to know what the Turing Machine that the input is a
>> representation of does, i.e., what does the ACTUAL machine H^(<H^>)
>> does, which is Halt.
>>
>
> That you can't even keep track of which code is being discussed is why I
>  hardly ever talk to you.
>
>> It doesn't matter that the partial simulation that H did of the machine
>> never reached its final halting state because H stop simulating it
>> before it gets there.
>>
>
> [00000c63][0010171e][00000c68] e8fefcffff  call 00000966 // call H(P,P)
>
> Begin Local Halt Decider Simulation at Machine Address:c36
> [00000c36][002117ca][002117ce] 55          push ebp
> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
> [00000c3c][002117c6][00000c36] 50          push eax       // push P
> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][002117c2][00000c36] 51          push ecx       // push P
> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>
> [00000c36][0025c1f2][0025c1f6] 55          push ebp
> [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
> [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
> [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
> [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
> [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call H(P,P)
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> While H remains in pure simulation mode simulating the input to H(P,P)
> this simulated input never stops running thus conclusively proving that
> when H decides this input never halts it is correct.

If you H nevers stops running, then it never answers.

Remember, H MUST have a defined algorithm. You keep on changing what
your H is, which means the problem keeps reseting. Every time you change
H, you change H^ so ANYTHING you have determened about the pervious H^
needs to be thown out.

If H doesn't abort the simulation, then H(H^,H^) will never return, and
thus H fails. ANYTIME you propose such an H, that will be the result,

If H DOES abort the simulation, so it can answer H(H^,H^) then it must
take into account that the copy of the algorithm of H inside H^ will
also abort its simulation. It will be a fact that the outer simulation
will abort its simulation before the simulated simulation will reach its
final halting state, because the outer simulator is farther in its
simulation than the inner simulator. That doesn't mean that the inner
simulation is non-halting, just that you can't get there with a simple
fixed termination rule.

You logic is just unsound. A simulator that doesn't halt until condition
x is not a pure simulator, PERIOD. Basic DEFINITION.

>
> The other reason is that I have to explain things to you hundreds of
> times before you bother to ever notice what I actually said.

Maybe if you look at the question you are actually answering you will
give real answers. I do see what you are saying, and the problem is you
fill your arguement with false statements which you don't seem to recognize.

IF you would actually try to point out an actual error in what I say,
rather than just saying I don't understand you. I do understand what you
are saying and am pointing out the errors in it. Maybe you are just to
dumb to recognize that you have gas-lighted yourself.

>
>> YOU are the one looking at the black dog when the question is about the
>> white cat.
>>
>> The decider H is asked what will the machine H^(<H^>) will do, as
>> specified by its input <H^> <H^>.
>>
>> We know that the actual machine H^(<H^>) Halts, so the right answer is
>> Halt.
>>
>> We know that H will reply non-halting
>>
>> Thus we know that it is wrong.
>>
>> We know it is wrong because it is based on unsound logic presuming that
>> H is a pure simulator, when it is a simulator that will decide to abort,
>> and thus its logic has a false premise as an input.
>>
>> The fact that H only partially simulates its simulation of <H^> <H^>
>> doesn't actually prove anything, except that it didn't simulate to the
>> point of actually proving anything, and thus it had to just guess, and
>> it guesses wrong.
>>
>
>