XPost: comp.theory, sci.logic
From: F.Zwarts@HetNet.nl
Op 27.jul.2025 om 01:43 schreef olcott:
> On 7/26/2025 6:35 PM, Richard Damon wrote:
>> On 7/26/25 7:08 PM, olcott wrote:
>>> On 7/26/2025 5:49 PM, olcott wrote:
>>>> On 7/26/2025 2:58 PM, olcott wrote:
>>>>> On 7/26/2025 2:52 PM, Mr Flibble wrote:
>>>>>> On Sat, 26 Jul 2025 14:26:27 -0500, olcott wrote:
>>>>>>
>>>>>>> On 7/26/2025 1:30 PM, Alan Mackenzie wrote:
>>>>>>>> In comp.theory olcott wrote:
>>>>>>>>
>>>>>>>>> The error of all of the halting problem proofs is that they
>>>>>>>>> require a
>>>>>>>>> Turing machine halt decider to report on the behavior of a
>>>>>>>>> directly
>>>>>>>>> executed Turing machine.
>>>>>>>>
>>>>>>>>> It is common knowledge that no Turing machine decider can take
>>>>>>>>> another
>>>>>>>>> directly executing Turing machine as an input, thus the above
>>>>>>>>> requirement is not precisely correct.
>>>>>>>>
>>>>>>>>> When we correct the error of this incorrect requirement it
>>>>>>>>> becomes a
>>>>>>>>> Turing machine decider indirectly reports on the behavior of a
>>>>>>>>> directly executing Turing machine through the proxy of a finite
>>>>>>>>> string
>>>>>>>>> description of this machine.
>>>>>>>>
>>>>>>>>> Now I have proven and corrected the error of all of the halting
>>>>>>>>> problem proofs.
>>>>>>>>
>>>>>>>> No you haven't, the subject matter is too far beyond your
>>>>>>>> intellectual
>>>>>>>> capacity.
>>>>>>>>
>>>>>>>>
>>>>>>> It only seems to you that I lack understanding because you are so
>>>>>>> sure
>>>>>>> that I must be wrong that you make sure to totally ignore the subtle
>>>>>>> nuances of meaning that proves I am correct.
>>>>>>>
>>>>>>> No Turing machine based (at least partial) halt decider can possibly
>>>>>>> *directly* report on the behavior of any directly executing Turing
>>>>>>> machine. The best that any of them can possibly do is indirectly
>>>>>>> report
>>>>>>> on this behavior through the proxy of a finite string machine
>>>>>>> description.
>>>>>>
>>>>>> Partial decidability is not a hard problem.
>>>>>>
>>>>>> /Flibble
>>>>>
>>>>> My point is that all of the halting problem proofs
>>>>> are wrong when they require a Turing machine decider
>>>>> H to report on the behavior of machine M on input i
>>>>> because machine M is not in the domain of any Turing
>>>>> machine decider. Only finite strings such as ⟨M⟩ the
>>>>> Turing machine description of machine M are its
>>>>> domain.
>>>>>
>>>>
>>>> Definition of Turing Machine Ĥ
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
>>>> if Ĥ applied to ⟨Ĥ⟩ halts, and // incorrect
requirement
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>> if Ĥ applied to ⟨Ĥ⟩ does not halt. // incorrect
requirement
>>>>
>>>> (a) Ĥ copies its input ⟨Ĥ⟩
>>>> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> (d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
>>>> (e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
>>>>
>>>> The fact that the correctly simulated input
>>>> specifies recursive simulation prevents the
>>>> simulated ⟨Ĥ⟩ from ever reaching its simulated
>>>> final halt state of ⟨Ĥ.qn⟩, thus specifies non-termination.
>>>>
>>>> This is not contradicted by the fact that
>>>> Ĥ applied to ⟨Ĥ⟩ halts because Ĥ is outside of
>>>> the domain of every Turing machine computed function.
>>>>
>>>
>>> In the atypical case where the behavior of the simulation
>>> of an input to a potential halt decider disagrees with the
>>> behavior of the direct execution of the underlying machine
>>> (because this input calls this same simulating decider) it
>>> is the behavior of the input that rules because deciders
>>> compute the mapping for their inputs.
>>>
>>
>> Nope, just more of your lies.
>>
>> The behavior of an input to a halt decider is DEFINED in all cases to
>> be the behavior of the machine the input represents,
>
> Yet I have conclusively proven otherwise and
> you are too stupid to understand the proof.
That was not a proof, but an assumption with a huge mistake.
>
> You are so stupid that you think you can get
> away with disagreeing with the x86 language.
The x86 language shows that the input specifies a halting program.
If you are unable to see that, you need to study the x86 language
somewhat more.
>
> _DDD()
> [00002192] 55 push ebp
> [00002193] 8bec mov ebp,esp
> [00002195] 6892210000 push 00002192 // push DDD
> [0000219a] e833f4ffff call 000015d2 // call HHH
> [0000219f] 83c404 add esp,+04
> [000021a2] 5d pop ebp
> [000021a3] c3 ret
> Size in bytes:(0018) [000021a3]
You have been told many times that these 18 bytes do not specify the
full input. In fact, they are the least interesting part of the input.
DDD is not needed:
int main() {
return HHH(main);
}
Here is no DDD, but you told us that also in this case HHH produces a
false negative by halting and reporting that it does not halt.
The most interesting part of the input is HHH itself.
It is clear that HHH produces many false negatives when its own code is
part of the input.
>
> DDD simulated by HHH according to the rules of the
> x86 language does not fucking halt you fucking moron.
> If any definition says otherwise then this definition
> is fucked up.
>
I see you have no counter arguments, except swearing and using claims
without any evidence.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
