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

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*