Liste des Groupes | Revenir à theory |
On 8/20/2024 3:45 AM, joes wrote:Except that HHHn can't emulate DDD onlyu DDDn since if it includes the HHH that it calls, which is HHHn, you have different inputs for each HHHn, and thus the proper name for it is DDDnAm Mon, 19 Aug 2024 23:33:52 -0500 schrieb olcott:*The following criteria only means*On 8/19/2024 11:02 PM, Richard Damon wrote:>On 8/19/24 11:50 PM, olcott wrote:On 8/19/2024 10:32 PM, Richard Damon wrote:On 8/19/24 10:47 PM, olcott wrote:*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.Changing the code, but not the address, constitutes a change._DDD()But it can't emulate DDD correctly past 4 instructions, since the 5th
[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]
instruciton to emulate doesn't exist.
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.
>>>Yes that is correct.x86utm takes the compiled Halt7.obj file of this c program>
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.
Which is irrelevent and a LIE as if HHHn is part of the input, that
input needs to be DDDn
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
>
So, you only prove that the DDD∞ that calls the HHH∞ is non-halting.
Not any of the other DDDn>Your problem is that for any other DDDn / HHHn, you don't have Y so
you don't have Z.>>You already agreed that (X ∧ Y) ↔ Z is correct.HHHn correctly predicts the behavior of DDD the same way that HHHnNope, HHHn can form a valid inductive proof of the input.
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.
>
Did you do an infinite trace in your mind?
But only for DDD∞, not any of the other ones.The bytes of HHH are part of DDD.All of the DDD have identical bytes it is only the HHH that varies.If you can do it and I can do it then HHH can do this same sort ofBut HHHn isn't given DDD∞ as its input, so that doesn't matter.
thing. Computations are not inherently dumber than human minds.
>
>
HHHn(DDD) predicts the behavior of HHH∞(DDD).
It does this same same way that HHHn(EEE)
predicts the behavior of HHH∞(EEE).
>
HHHn(DDD) correctly predicts the behavior of HHH∞(EEE) and HHH∞(DDD)
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>Right, correctly determine for the input, an dthat means ALL the input, and this EXACGT input.
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
Les messages affichés proviennent d'usenet.