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

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.