Re: Two dozen people were simply wrong --- Try to prove otherwise --- pinned down

On 6/1/24 11:30 AM, olcott wrote:

On 6/1/2024 6:22 AM, Richard Damon wrote:

On 5/31/24 10:40 PM, olcott wrote:

On 5/31/2024 9:25 PM, Richard Damon wrote:

On 5/31/24 10:08 PM, olcott wrote:

On 5/31/2024 8:35 PM, Richard Damon wrote:

On 5/31/24 9:10 PM, olcott wrote:

On 5/31/2024 7:39 PM, Richard Damon wrote:

On 5/31/24 7:57 PM, olcott wrote:

On 5/31/2024 6:33 PM, Richard Damon wrote:

On 5/31/24 6:54 PM, olcott wrote:

On 5/31/2024 5:46 PM, Richard Damon wrote:

On 5/31/24 6:08 PM, olcott wrote:

On 5/31/2024 4:36 PM, Richard Damon wrote:

On 5/31/24 10:10 AM, olcott wrote:

On 5/31/2024 6:16 AM, Richard Damon wrote:

On 5/30/24 11:27 PM, olcott wrote:

Try and show how HH using an x86 emulator can correctly emulate
the following x86 machine code such that DD reaches its own
machine address 00001c47.

>
Why should I, since that isn't what I was saying.
>

>
*To me that looks like you know that*
*you have been busted in a lie and are backing down*

>
no, YOU are LYING RIGHT HERE AND NOW.
>
Prove that I said that the simulation by HH made it there, or admit to being a DAMNED LIAR.
>
What I have been saying is the the DIRECT EXDCUTION of DD, and the CORRECT (and complete) simulation of the input to HH by an actual UTM will get there.
>

>
That has always been the dishonest dodge strawman deception
CHANGE-THE-SUBJECT fake rebuttal regarding
the behavior of DD correctly simulated by pure function HH.

>
But it is your talking about the "correctly simulated by HH" that is the dishonest dodge,

>
Try and show how HH using an x86 emulator can correctly emulate
the following x86 machine code such that DD reaches its own
machine address 00001c47.

>
Never said it could. But haven't looked hard enough to be willing to say it can't, but then, who cares, it doesn't say a thing about the real halting problem, since H's simulation isn't "correct" by a definition that relates simulation to non-halting behavior,
>

>
"...the Turing machine will halt whenever it enters a final state."
Linz(1990:234)

>
Right, and that is talking about runnig the Turing Machine, not simulating a representation of it.
>

>
DD correctly simulated by HH cannot possibly reach its own simulated
final state. This is conclusively proven beyond all possible doubt
by the x86 machine code of DD.

>
Depends on the specification of HH, as has beeen shown.
>

>
You can lie about this and try to get away with changing the subject.
What you cannot do is show that it is not true.

>
But I don't try to claim one side of the other, as it isn't relevent.
>

>
*Showing that it is relevant is a whole other different subject that*
*we can get to as soon as you quit your deception on this subject*

>
But if it isn't relevent, why are we looking at it.
>
It seems you just WANT to waste you time trying to convince people about something they don't care about.
>

>
*Showing that it is relevant is a whole other different subject that*
*we can get to as soon as you quit your deception on this subject*
>
*Showing that it is relevant is a whole other different subject that*
*we can get to as soon as you quit your deception on this subject*
>

>
*If DD correctly simulated by HH can't possibly reach its own*
*final state then DD correctly simulated by HH is non-halting*

Nope, Where did that definition say ANYTHING about one machine simulationg another.
>

>
Trying to get away with saying that you don't "believe in" UTMs
can't possibly fool anyone that knows what UTMs are.
>

>
But I DO beleive in UTMs, and know exact what they do.
>
Your embedded_H can NOT actually be a UTM, or neither H nor embedded_H are deciders.
>
PERIOD,.
>

When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
When embedded_H <is> a UTM then ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H
cannot possibly reach its own simulated final state of ⟨Ĥ.qn⟩. In this
case embedded_H fails to be a decider, however it also proves:

>
And then, while THAT H^ is non-halting, H isn't a decider.
>
>
>

>
that ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach its
own simulated final state of ⟨Ĥ.qn⟩ for any embedded_H based on a UTM
that only simulates some finite sequence of steps.

>
But that only apply *if* embedded_H (and thus H) *IS* a UTM, if it aborts its simuliation, then its
>

>
"...the Turing machine will halt whenever it enters a final state."
Linz(1990:234)
>
⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach its
own simulated final state of ⟨Ĥ.qn⟩

>
And and embedded_H that actually correct simulates the input, by Computaiton Theory definitions is the UTM that, by definition, doesn't abort its simulation.
>

>
*The input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H SPECIFIES non-halting behavior*
*The input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H SPECIFIES non-halting behavior*
*The input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H SPECIFIES non-halting behavior*

>
Only if embedded_H and H are ACTUALLY UTMs,

>
*AS LONG AS 1 to ∞ steps of*
⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach their
own simulated final state of ⟨Ĥ.qn⟩
THEN *The input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H SPECIFIES non-halting behavior*

>
And each of those is of a DIFFERENT input,

>
Every element of the infinite set of embedded_H / ⟨Ĥ⟩ has this same
property

>
But that property is a straw man, the question is does H^ (H^) Halt, or

 *I will not discuss any other points with you until after you either*
(a) Acknowledge that DD correctly simulated by HH and ⟨Ĥ⟩ ⟨Ĥ⟩ correctly
     simulated by embedded_H remain stuck in recursive simulation for
     1 to ∞ of correct simulation or
 (b) Correctly prove otherwise.

And until you answer the question of what that actually means, I will reply WHO CARES.
DO you mean the simulation of the TEMPLATE DD, which means that we CAN'T simulate the call HH as we have no code past point to simulate, and thus your claim is just a LIE.
Or, do you mean a given instance of HH simulating a given instance of DD, at which point we never have the 1 to infinte number of simulatons of THAT INPUT, so your claim is just a LIE.

 *You already know that you can't possibly do that on the basis that*
DD correctly emulated by HH with an x86 emulator cannot possibly
reach past its own machine instruction [00001c2e] in any finite
number of steps of correct emulation.
 

But I have shown it, since you have dropped the requirement that HH is a "pure Function"
And if H is DEFINED to be a pure function, then we KNOW that the results of the call HH by DD must result in the same behavior as the HH that we are using, and thus any logic that says it doesn't return when HH(DD,DD) actually does is wrong.
of course, the error is using the INVALID logic of comparing the simulation of OTHER inputs, INTENTIONALLY DECEPTIVELY called DD also.

_DD()
[00001c22] 55         push ebp
[00001c23] 8bec       mov ebp,esp
[00001c25] 51         push ecx
[00001c26] 8b4508     mov eax,[ebp+08]
[00001c29] 50         push eax        ; push DD 1c22
[00001c2a] 8b4d08     mov ecx,[ebp+08]
[00001c2d] 51         push ecx        ; push DD 1c22
[00001c2e] e80ff7ffff call 00001342   ; call HH
[00001c33] 83c408     add esp,+08
[00001c36] 8945fc     mov [ebp-04],eax
[00001c39] 837dfc00   cmp dword [ebp-04],+00
[00001c3d] 7402       jz 00001c41
[00001c3f] ebfe       jmp 00001c3f
[00001c41] 8b45fc     mov eax,[ebp-04]
[00001c44] 8be5       mov esp,ebp
[00001c46] 5d         pop ebp
[00001c47] c3         ret
Size in bytes:(0038) [00001c47]