On 2/22/23 12:06 PM, olcott wrote:
> On 2/22/2023 10:41 AM, Fritz Feldhase wrote:
>> On Wednesday, February 22, 2023 at 4:18:56 AM UTC+1, olcott wrote:
>>> On 2/21/2023 9:11 PM, Fritz Feldhase wrote:
>>>>>
>>>>> H(D,D) cannot report on the [halting] behavior of D(D)
>>>>>
>>>> Huh?! What?!
>>>>
>>> H(D,D) cannot possibly report on the behavior of non inputs.
>>
>> Huh?! Since when is your program/function D a "non input". What does
>> this even mean?
>>
>> Just invented a new term (weasel word) to say something silly?
>>
>
> int sum (int x, int y) { return x + y; }
> sum(3,4) cannot return the sum of 7 + 5 and would be wrong to do so.
Right, just like Halt(D,D) can't return non-halting when D(D) Halts.
>
> Simulating halt decider H is not allowed to analyze the behavior of the
> directly executed D(D) for the same reason that sum(3,4) is not allowed
> to return the sum of 5 + 7.
Why not? That the problem it is supposed to be deciding.
sum of3,3) is 3+4 just as Ha;lt(D,D) is supposed to answer if D(D) Halts.
>
> >>
> >
> > Just a comment: H cannot correctly "determine" the halt status of D(D).
>
> H is not allowed to "determine" the halt status of D(D).
Why not, what is it supposed to do, guess? Maybe you don't know what
determine means.
>
> All deciders compute the mapping from their inputs
> All deciders compute the mapping from their inputs
> All deciders compute the mapping from their inputs
>
Right, and to be a Foo decider, it needs to compute the Foo map.
> *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
>
> You continue to ignore and erase the proof that H does correctly
> determine the halt status of D. *This is the straw-man deception*
>
I haven't erased anything.
Remember, teh DEFINITION of a Halt Decider comes from:
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.
So the answer/mapping that a Halt Decider is supposed to determine is
the behavior of the ACUTUAL machine.
Since D(D) Halts, the CORRECT answer for H(D,D) is Halting, so the fact
it says Non-Halting shows it to be incorrect as a Halt Decider.
It might "Correctly" answer some other question, but that just makes it
s correct POOP decider, not a Halt Decider.
>
>
> 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 isn't the question.
It has also been shown that the CORRECT SIMULATION 0f this input by a
simulator that actually completes its job shows that it does halt.
This just shows that H always just gives up too soon, and thus its
conclusion is incorrect. You can argue whether this is due to an
incorrect simulation, or incorrrctly determining, but it IS INCORRECT.
> _D()
> [00001d12] 55 push ebp
> [00001d13] 8bec mov ebp,esp
> [00001d15] 51 push ecx
> [00001d16] 8b4508 mov eax,[ebp+08] // move 1st argument to eax
> [00001d19] 50 push eax // push D
> [00001d1a] 8b4d08 mov ecx,[ebp+08] // move 1st argument to ecx
> [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
>
> When D correctly simulated by H reaches machine address [00001d1e] H can
> simulate D again endlessly or abort the entire recursive chain of
> simulations before any of them pass machine address [00001d1e].
Nope, since H DOES abort its simulation at this point, you can't use
arguements about what whould happen when it doesn't.
That is just the fallacy of using a false premise.
>
> *Are you clueless about how the x86 language works*
> [00001d16] mov eax,[ebp+08] // move 1st argument to eax
> [00001d19] push eax // push D
> [00001d1a] mov ecx,[ebp+08] // move 1st argument to ecx
> [00001d1d] push ecx // push D
> [00001d1e] call 00001562 // call H
> This is the same thing as this C: H(D,D);
>
>
???
So you know how to write a call instruction.
DO you understand what this does?
It calls an H that WILL abort its simulation and return 0, at least that
is what all the code you have provided that has an H that supposedly
"Correctly" returns 0 for H(D,D)
You don't seem to understand how computers actually work.
Since we have established that H(D,D) returns 0, the only thing that a
correct simulation of that code sequence can indicate is that eventually
we will get to the the next instruction with a 0 in the eax register.
Anything else is just proved to be an incorrect simulation.