Liste des Groupes | Revenir à theory |
On 6/1/2024 4:15 PM, Richard Damon wrote:But since the simulation was aborted, it doen't say anything about the halting status of the machine being simulated.On 6/1/24 4:35 PM, olcott wrote:typedef int (*ptr)(); // ptr is pointer to int function in COn 6/1/2024 3:29 PM, Richard Damon wrote:>On 6/1/24 12:46 PM, olcott wrote:It seems to me (and I may be wrong you may be confused)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,
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.
>
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.
*THIS PROVES THAT THE INPUT TO H(DD,DD) DOES NOT HALT*No it does not.
*THIS PROVES THAT THE INPUT TO H(DD,DD) DOES NOT HALT*
*THIS PROVES THAT THE INPUT TO H(DD,DD) DOES NOT HALT*
*THIS PROVES THAT THE INPUT TO H(DD,DD) DOES NOT HALT*
The reason why the behavior of D(D) is irrelevant canNope, because you said above that the input to HH(DD,DD) does not halt, and that is a statment about the machine/program DD, not its simulation.
be discussed ONLY AFTER WE GET CLOSURE ON THE ABOVE POINT.
*You have dishonestly dodged every single point for three years*Nope, YOU have made you ignorantly dishonest claims on every point for appparently the last 20 years.
*You have dishonestly dodged every single point for three years*
*You have dishonestly dodged every single point for three years*
*You have dishonestly dodged every single point for three years*
Les messages affichés proviennent d'usenet.