Liste des Groupes | Revenir à theory |
Op 20.aug.2024 om 15:18 schreef olcott:HHHn is free to simulate whichever way its author wants. It is correctOn 8/20/2024 5:29 AM, Fred. Zwarts wrote:Which makes HHHn incorrect, because it should simulate its input, not a hypothetical non-input HHH∞.Op 20.aug.2024 om 06:33 schreef olcott:On 8/19/2024 11:02 PM, Richard Damon wrote:On 8/19/24 11:50 PM, olcott wrote:All of the DDD have identical bytes it is only the HHH that varies.On 8/19/2024 10:32 PM, Richard Damon wrote:So, you only prove that the DDD∞ that calls the HHH∞ is non-halting.On 8/19/24 10:47 PM, olcott wrote:Yes that is correct.*Everything that is not expressly stated below is*Looks like you still have this same condition.
*specified as unspecified*
I thought you said you removed it.
void DDD()But it can't emulate DDD correctly past 4 instructions, since the 5th instruciton to emulate doesn't exist.
{
HHH(DDD);
return;
}
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
*It is a basic fact that DDD emulated by HHH according to*
*the semantics of the x86 language cannot possibly stop*
*running unless aborted* (out of memory error excluded)
And, you can't include the memory that holds HHH, as you mention HHHn below, so that changes, but DDD, so the input doesn't and thus is CAN'T be part of the input.
X = DDD emulated by HHH∞ according to the semantics of the x86 languageAnd neither X or Y are possible.
Y = HHH∞ never aborts its emulation of DDD
Z = DDD never stops running
The above claim boils down to this: (X ∧ Y) ↔ Z
x86utm takes the compiled Halt7.obj file of this c programWhich is irrelevent and a LIE as if HHHn is part of the input, that input needs to be DDDn
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Thus making all of the code of HHH directly available to
DDD and itself. HHH emulates itself emulating DDD.
And, in fact,
Since, you have just explicitly introduced that all of HHHn is available to HHHn when it emulates its input, that DDD must actually be DDDn as it changes.
Thus, your ACTUAL claim needs to be more like:
X = DDD∞ emulated by HHH∞ according to the semantics of the x86 language
Y = HHH∞ never aborts its emulation of DDD∞
Z = DDD∞ never stops running
The above claim boils down to this: (X ∧ Y) ↔ Z
Not any of the other DDDn
But only for DDD∞, not any of the other ones.Your problem is that for any other DDDn / HHHn, you don't have Y so you don't have Z.
void EEE()Nope, HHHn can form a valid inductive proof of the input.
{
HERE: goto HERE;
}
HHHn correctly predicts the behavior of DDD the same
way that HHHn correctly predicts the behavior of EEE.
It can't for DDDn, since when we move to HHHn+1 we no longer have DDDn but DDDn+1, which is a different input.You already agreed that (X ∧ Y) ↔ Z is correct.
Did you do an infinite trace in your mind?
If you can do it and I can do it then HHH canBut HHHn isn't given DDD∞ as its input, so that doesn't matter.
do this same sort of thing. Computations are
not inherently dumber than human minds.
HHHn(DDD) predicts the behavior of HHH∞(DDD).Not all HHH can be at the same memory at the same time.Counter factual. HHH∞ is hypothetical thus takes no memory.
HHH and DDD remains at the same physical machine address locations.
When HHHn is in the memory, then DDD calls HHHn, not HHH∞.HHH∞ is hypothetical thus takes no memory. HHHn(DDD) predicts
When HHHn is doing the simulation, HHHn is in that memory, therefore, it should simulate HHHn, not HHH∞.
They cannot be at the same memory location at the same time, unless you are cheating with the Root variable to switch between HHHn and HHH∞, which causes HHHn to process the non-input HHH∞ instead of the input HHHn.
the behavior of a hypothetical HHH∞(DDD) as described below
Les messages affichés proviennent d'usenet.