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

On 6/2/24 2:39 PM, olcott wrote:

On 6/2/2024 1:24 PM, Fred. Zwarts wrote:

Op 02.jun.2024 om 16:47 schreef olcott:

On 6/2/2024 4:24 AM, Fred. Zwarts wrote:

Op 01.jun.2024 om 23:27 schreef olcott:

On 6/1/2024 4:15 PM, Richard Damon wrote:

On 6/1/24 4:35 PM, olcott wrote:

On 6/1/2024 3:29 PM, Richard Damon wrote:

On 6/1/24 12:46 PM, olcott wrote:

On 6/1/2024 11:33 AM, Richard Damon wrote:

On 6/1/24 12:18 PM, olcott wrote:

On 6/1/2024 11:08 AM, Richard Damon wrote:

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

On 6/1/2024 10:46 AM, Richard Damon wrote:

On 6/1/24 10:00 AM, olcott wrote: >> 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)?
>

>
Every DD correctly simulated by any HH remains stuck in recursive simulation for 1 to ∞ steps of correct simulation.

>
So? Since you definition of "Correct Simulation" is non-canonical, that doesn't mean anything.
>

>
*When the "canonical" definition tries to get away with refuting this*
>
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.

>
No, it doesn't "Refute" that,

>
*Then what I said stands unrefuted*
*Then what I said stands unrefuted*
*Then what I said stands unrefuted*

>
And unproven, and still meaningless.
>

>
*We can't move on to any other point until*
(a) You acknowledge that my above statement about the behavior of the
x86 machine code of DD is irrefutable and applies to the C source code version of DD and applies to the Linz proof.
>
(b) You correctly refute what I said above about the behavior of the
x86 machine code of DD.

>
But why do we care about the fact that all your HH that answer just gave up on their simulation before the actual canonically correct simulation would have reached a final state,

It seems to me (and I may be wrong you may be confused)
That we cannot move on to any other point simply because
you are simply too freaking dishonest.
>
You use moving on to other points to endlessly avoid any
closure on any point.
>

>
>
We can not move on, because you want to base your arguement on falsehoods.
>

>
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       }
08
09       int main()
10       {
11         HH(DD,DD);
12         return 0;
13       }
>
Every DD correctly simulated by any HH of the infinite set of HH/DD
pairs that match the above template never reaches past its own simulated
line 03 in 1 to ∞ steps of correct simulation of DD by HH.

>
Similarly:
Every HH correctly simulated by itself of the infinite set of HH/DD
pairs that match the above template never reaches past its own simulated
return in 1 to ∞ steps of correct simulation of HH by HH.
>

>
DD correctly simulated by HH includes HH correctly simulating itself
simulating DD as an intrinsic aspect of DD correctly simulated by HH.

*It is only the outermost directly executed HH that is required to

halt*

>
It might be possible to use the following criteria to see whether a program halts:
a) The direct executed program halts.
b) The simulation of the program by HH reaches its final state.
>
If you choose a then both DD and HH halt.
If you choose b then neither DD, nor HH halt.
>
Choosing different criteria for different functions only because you need it in your claim would be dishonest.
>

>
When an input DD gets instances of itself HH stuck in recursive
simulation this input is rejected as non-halting.

>
Similarly, when the partial input HH (part of DD) gets instances of itself HH stuck in recursive simulation this partial input is rejected as non-halting.
>
>

 *I always use this same criteria* People here verified that
I really did contact professor Sipser.
 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 this verbatim paragraph is
correct (He has neither reviewed nor agreed to anything else in this paper)
 <Professor 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

And since the ONLY simulation that Professor Sipser would consider correct, would be a simulation that continues until it reaches a final state.
Thus, if H doesn't actually do that, then it is impossible for H to correctly determine that H's simulation would do that, since it won't do a correct simulation.

 H can abort its simulation of D and correctly report that D specifies a
non-halting sequence of configurations.
</Professor Sipser agreed>
 

So, since an H that does abort its simulation, can not have done a correct simulation, you can never actually apply that definition literally.
What CAN be done, and likely what he was thinking, was that if H can look at what would hypothetically happen if THIS INSTANCE of H were actually a UTM, what would it do, this hypothetical can affect the contents of the tape, as the tape is supposed to be a fixed entity, and thus imagining changing THIS H can change the tape.
If you do that, then when we consider that H might abort its simulation and return 0, then at no point can this H presume that its input would never halt, as the simulated H will always have the option at some point in the future of aborting it simulation and returning (just as you imagine actually happening).
For the non-pathological cases, this does allow H to look ahead and see that even if H is defined to abort and return 0, the hypothetical simulation of the input would never stop, so the abort condition is applicable. It just doesn't work for cases where the input uses a copy of the decider that is deciding on it.
And the bigger issue, is that if you actually do build the system properly, it becomes impossible for H to detect that the input uses a copy of H because for non-trivial machines, there can be an infinite number of "representations" created for it, so it becomes an unsolvable semantic problem to detect any copy of yourself inside another machine.