On 2/22/23 11:48 AM, olcott wrote:
> On 2/22/2023 10:32 AM, Fritz Feldhase wrote:
>> On Wednesday, February 22, 2023 at 4:16:24 PM UTC+1, olcott wrote:
>>
>>> int D(int (*x)())
>>> {
>>> int Halt_Status = H(x, x);
>>> if (Halt_Status)
>>> HERE: goto HERE;
>>> return Halt_Status;
>>> }
>>>
>>
>> Just a comment: H cannot correctly "determine" the halt status of D(D).
>
> *straw-man*
> An intentionally misrepresented proposition that is set up because it is
> easier to defeat than an opponent's real argument.
>
https://www.lexico.com/en/definition/straw_man
which since 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.
Says that is EXACTLY what your "alternate" criteria is.
>
> You continue to ignore and erase the proof that H does correctly
> recognize the halt status of D. *This is the straw-man deception*
>
LIE.
>
>
> Anyone with sufficient software engineering skill knows that
> *D simulated by H cannot possibly correctly reach its ret instruction*
> Everyone else lacks sufficient software engineering skill or lies
Which just proves that you aren't working on the Halting Problem.
The fact that D(D) halts, and UTM(D,D) Halts, says the correct answer
for a HALT decider is Halting, so since H(D,D) answers non-halting, it
isn't one.
All you have shown is that it might be a correct (but worthless) POOP
decider.
>
> _D()
> [00001d12] 55 push ebp
> [00001d13] 8bec mov ebp,esp
> [00001d15] 51 push ecx
> [00001d16] 8b4508 mov eax,[ebp+08]
> [00001d19] 50 push eax // push D
> [00001d1a] 8b4d08 mov ecx,[ebp+08]
> [00001d1d] 51 push ecx // push D
> [00001d1e] e83ff8ffff call 00001562 // call H
> [00001d23] 83c408 add esp,+08
> [00001d26] 8945fc mov [ebp-04],eax
> [00001d29] 837dfc00 cmp dword [ebp-04],+00
> [00001d2d] 7402 jz 00001d31
> [00001d2f] ebfe jmp 00001d2f
> [00001d31] 8b45fc mov eax,[ebp-04]
> [00001d34] 8be5 mov esp,ebp
> [00001d36] 5d pop ebp
> [00001d37] c3 ret
>
> H simulates D until reaching machine address [00001d1e].
> Which calls H to simulate D again.
Which we KNOW will abort its simulation of its input and return 0, and
thus the actual CORRECT (and complete) simulation of the input will halt.
All you have shown is that H will ALWAYS abort its simulation too early
and by using UNSOUND logic get the wrong answer.
>
> There are two possible behaviors for at this point:
> (a) H continues to simulate D recursively until stack space is
> exhausted.
No, there is ONE possible behavior, the behavior that H has been
programed with.
Since you claim that H WILL abort its simulation and return 0 in this
case, (a) NEVER HAPPENS, and can not be used in the arguemen.
That is just lookling at something that isn't the input to the machine
>
> (b) H aborts the entire simulation sequence at some point between
> machine address [00001d12] and [00001d1e].
Which it does
>
> In both of these cases D correctly simulated by H cannot possibly reach
> the ret instruction at machine address [00001d37].
Right, but the CORRECT (and complete) simulation does, as does the
actual exectution.
Since 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
That means the CORRECT answer is Halting.
You are just working on a different problem and lying about what you are
doing.
>
> Most novices with the halting theorem do not understand that halting
> means reaching a final state and terminating normally.
>
Right, OF THE MACHINE.
An ABORTED simulation does not tell us if the results is Halting or Not,
just like looking at the first mile of a road doesn't tell yoy how long
it is, except that it is at least 1 mile long.
You are just showing that you do not understand what it is you are
talking about.