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

On 6/1/24 10:00 AM, olcott wrote:

On 6/1/2024 3:36 AM, Wasell wrote:

On Fri, 31 May 2024 18:57:57 -0500, in article <v3do66$2ejq2$1@dont-email.me>,
olcott wrote:

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

>
[...]
>

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)
>
*If DD correctly simulated by HH can't possibly reach its own*
*final state then DD correctly simulated by HH is non-halting*

>
You keep using this quote as if it means that the /only/ way a TM
can halt, is if it enters a final state. You never quote the
context:
>
   "A Turing machine is said to halt whenever it reaches a
   configuration for which \delta is not defined; this is possible
   because \delta is a partial function. In fact, we will assume that
   no transitions are defined for any final state, so the Turing
   machine will halt whenever it enters a final state."
     (p. 227 in my copy)
>
This means that a TM /will/ halt if it enters a final state, but it
can also halt in other states. This interpretation is confirmed in
other places in Linz:
>
   "The machine can halt in a nonfinal state or it can enter an
   infinite loop and never halt. [...] we halt in a nonfinal state.
   [...] the machine will halt in the nonfinal state q_0 , since
   \delta(q_0,1) is undefined." (p. 232)
>
   "[...] the computation will halt in a nonfinal state." (p. 233)
>
   "Other input not in the language will also lead to a nonfinal
   halting state" (p. 234)
>
   "[...] that will halt in a nonfinal state q_n if x < y." (p. 237)
>
   etc, etc.
>
Can I expect you to never use this deceptive out-of-context quote
ever again?

 DD correctly simulated by HH remains stuck in recursive simulation
all the time it is simulated even when an infinite number of steps
are simulated.

So, are you admitting that HH just gets stuck and doesn't answer when asked HH(DD,DD)?

 According to the words that you quoted it would be more accurate to
provide a longer definition. I will attempt that yet this may be too
difficult for my short-attention space reviewers.
 "δ is the transition function" (Linz:1990:233) ...
"A Turing machine is said to halt whenever it reaches a
configuration for which δ is not defined; (Linz:1990:234)
 DD correctly simulated by HH never reaches any point where δ
is not defined. My target audience of software engineers may be
dumbfounded by that. Software engineers will not allow false
assumptions to override verified facts.

So,

 DD correctly simulated by HH has behavior that is isomorphic
to Infinite_Recursion simulated by HH.

Only if you admit your HH will never abort its simulation, at which point it us HH that has the behavior isomorphic to Infinite_Recursion.
After all, once DD calls HH, the code never gets back to actually executiong any steps of DD, so the DD outside of HH can't get stuck in the infinite recursion, only the part in HH, which means that it is HH that got caught in the infinite recursion.

 void Infinite_Recursion(u32 N)
{
   Infinite_Recursion(N);
}
 Since the idea of a simulating halt decider is brand new with me
there is not any preexisting literature on simulating halt deciders.

Note, "new to me", it is not "new"

 The above proves that we cannot construe that stopping running
because of stopping being simulated is any kind of halting behavior.
 

Right, but stopping being simulated also does not indicated non-halting behavior.

 Introduction to the Theory of Computation, by Michael Sipser
https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
 On 10/13/2022 11:29:23 AM
MIT Professor Michael Sipser agreed that these verbatim words are correct
(He has neither reviewed nor agreed to anything else in this paper)
 <Sipser agreed>
If simulating halt decider H correctly simulates its input D until H correctly determines that its simulated D would never stop running unless aborted then
 H can abort its simulation of D and correctly report that D specifies a non-halting sequence of configurations.
</Sipser agreed>

So ONLY IF H DOES correctly simulate its input, which means it will never abort its input, can H abort its simulation.
So, you have to figure out how to both SIMULATE FOREVER and abort your simulation,

 Because my reviewers tend to be much more interested in rebuttal (even
when this rebuttal directly contradicts verified facts) I must make
my words unequivocal and clear. Even when make my words unequivocally
prove my point with verified facts they still disagree.
 After three years of discussion with Richard on the one point that DD
correctly simulated by HH never reaches its own final state he finally
admitted that he just doesn't.

When did I recently agree to that?
My earlier agreement years ago was based on "Correct-Simulation" being the canonical (to computaiton theory) definition of Correct Simulation, which means non-aborted.
And since all of that is based on a non-canonical definition of simulation which means that it doesn't actually indicate non-halting, the staement is irrelevent.

 I had to confront him with the x86 machine code of DD to get him to
concede that he doesn't know. This took three years.

And where did I agree to it?

 Prior to confronting him with this machine code he (and two dozen
other people) persistently disagreed with what a correct simulation
is. Now that the machine code is presented no one can get away with
saying that DD correctly simulated by HH can possibly reach its own
machine address of 00001c47 (or any other point where δ is undefined).
 typedef int (*ptr)();  // ptr is pointer to int function in C
00       int HH(ptr p, ptr i);
01       int DD(ptr p)
02       {
03         int Halt_Status = HH(p, p);
04         if (Halt_Status)
05           HERE: goto HERE;
06         return Halt_Status;
07       }
 It is clear that DD correctly simulated by HH using an x86 emulator
cannot possibly reach past its own line 03 for 1 to ∞ steps of correct
simulation.

And I showed that there can exist an HH that can do that unless you add restirctions to what HH is, which you keep on dropping.
And you have a problem of definitions.
Is HH simulating a "templeate" DD, in which case, what does it simulate for the call to HH, since there is no code for HH in the template,
or is HH simulating an instance of the template, DD, in which case each number of steps is a diffferent instance, none of which shows that DD is actually non-halting, just that each one didn't halt yet, but if HH aborts and returns 0, we can show it WILL halt.

 Four experts in the C language concurred with my own expert assessment.
It really is dead obvious to anyone with sufficient knowledge of the C
programming language thus all those that disagree could only be playing
trollish head games.

Fallacy of arguement by authority, particularly using people who clearly don't understand what compuation theory is.

 Finally when confronted with the x86 machine language of DD where lying
would look ridiculously foolish Richard backed down and admitted that
he just doesn't know.

So, do you want to answer the questions about the definition of what you are asking for, or are YOU afraid that if you admit to which one you are using you can be shown to be a liar.

 _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]
 

The above code, if used as the TOTAL definition of what is to be done, i.e DD is just a template, can NOT be simulated past the call HH instruction, and thus your claim of 1 to infinity instructions is a LIE, as it can not be simulated for more than 8 instructions.
If you include a version of HH, then that simulation only applies for that version of H, and that simulation will only proceed for exactly some N steps, and then it WILL be aborted, as that is all that given HH will do,
It has been shown that if you pair that DD with an specific HH, then give that paired description to UTM, it WILL reach a final state if that HH(DD,DD) returns 0.
Thus, that answer can not be correct.
If the arguement is that THIS HH couldn't reach the final state in its simulation, then by the exact same logic, an HH that simulates exactly one step and then aborts, and if that wasn't the ret opcode says the input is non-halting would be just as correct, and thus your "criteria" is basically meaningless.
Different HH's paired to DD give diffferent inputs, so it is INVALID LOGIC to talk about them having meaning for this input.