Re: H(D,D) cannot even be asked about the behavior of D(D) --- Boilerplate Reply

On 6/21/24 9:49 AM, olcott wrote:

On 6/20/2024 10:52 PM, Richard Damon wrote:

On 6/20/24 11:30 PM, olcott wrote:

On 6/20/2024 9:59 PM, Richard Damon wrote:

On 6/20/24 10:46 PM, olcott wrote:

On 6/20/2024 9:38 PM, Richard Damon wrote:

On 6/20/24 10:04 PM, olcott wrote:

On 6/20/2024 8:55 PM, Richard Damon wrote:

On 6/20/24 11:04 AM, olcott wrote:

On 6/20/2024 9:42 AM, Mikko wrote:

On 2024-06-20 05:15:37 +0000, olcott said:
>

On 6/20/2024 12:04 AM, Mikko wrote:

>

Sitll inclear whether you know what "termination analyzer" means.

>

I really don't care what you believe.
It is not about belief.
It is about correct reasoning.

>
No, it is not. It is about language maintenance. If you cannot present
your reasoning in Common Language it does not matter whether your
reasoning is correct.
>

>
I cannot possibly present my reasoning in a convincing way
to people that have already made up their mind and closed it
thus fail to trace through each step of this reasoning looking
for an error and finding none.

>
BNo, we are open to new ideas that have an actual factual
>

>
If you simply leap to the false assumption that I am wrong
yet fail to point out any mistake because there are no mistakes
this will only convince gullible fools that also lack sufficient
technical competence.
>

>
We don't leap from false assumption, we start with DEFINTIONS.
>

>
When it is defined that H(D,D) must report on the behavior
of D(D) yet the finite string D cannot be mapped to the
behavior of D(D) then the definition is wrong.
>
*You seem to think that textbooks are the word of God*
>

>
>
Why do you say it can not be "mapped"
>
Of course it can be mapped by the definition of mapping that decider are supposed to use, as
>

>
You need to show every single freaking step of exactly
DDD correctly emulated by HH0 reaches past its own
machine address [0000209b] or all you have is BULLSHIT!

>
>
No, all *YOU* have is BULL-POOP in your head, as NOWHERE, but in your POOP-filled brain, is there any requirement that the mapping is defined by the steps of the decider. You just have the problem BACKWARDS, like most of your logic.
>

>
_DDD()
[00002093] 55               push ebp
[00002094] 8bec             mov ebp,esp
[00002096] 6893200000       push 00002093 ; push DDD
[0000209b] e853f4ffff       call 000014f3 ; call HH0
[000020a0] 83c404           add esp,+04
[000020a3] 5d               pop ebp
[000020a4] c3               ret
Size in bytes:(0018) [000020a4]
>
There is no mapping to the behavior of DDD correctly emulated
by any x86 emulator based decider that can possibly exist to
the behavior of DDD that reaches past its own machine address
[0000209b] *you have always know this and lied about it*
>
*I truly hope you repent. I don't want you to be condemned to Hell*
>

>
It doesn't need to be simulated by the decider!
>

 The behavior (halting or not) of a finite string of x86
machine code is ruled by the semantics of the x86 language.

Right.

 This behavior is the sequence of state transitions that are
specified by the x86 finite string of machine code within
the semantics of the x86 programming language.

Right.

 When we look at the behavior that DDD specifies this behavior
includes that DDD specifies a recursive simulation of itself.

Nope, ir specifies that it calls a SPECIFIC HH0 that you have defined will simulate its input for so long and then abort.
HH0 is a fixed defined piece of code to ask the question, and since you are claiming HH0 is correct to return 0, we need to verify the DDD that uses that HH0, since that is what HH0 was given.

 People stuck in rebuttal mode hate to go though these steps
because it derails their rebuttal mode with objective facts.

People stuck in their own lies can never see the truth.
The following is NOT a complete definition of the input, if it is, then the "correct behavior" is that the code behavior is UNDEFINED when it accesses information not within itself and thus the question is not valid.

 _DDD()
[00002093] 55               push ebp
[00002094] 8bec             mov ebp,esp
[00002096] 6893200000       push 00002093 ; push DDD
[0000209b] e853f4ffff       call 000014f3 ; call HH0
[000020a0] 83c404           add esp,+04
[000020a3] 5d               pop ebp
[000020a4] c3               ret
Size in bytes:(0018) [000020a4]