Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Fred. Zwarts" <F.Zwarts@HetNet.nl>
Newsgroups: comp.theory
Subject: Re: Anyone that disagrees with this is not telling the truth --- V5
Date: Wed, 21 Aug 2024 09:59:46 +0200
Organization: A noiseless patient Spider
Lines: 140
Message-ID: <va46pi$3piab$1@dont-email.me>
References: <va104l$376ed$4@dont-email.me>
 <cd375f68f97a737988bab8c1332b7802509ff6ea@i2pn2.org>
 <va13po$376ed$7@dont-email.me>
 <d42e5d30ea5f1c067283cb04d8a7293e2117188e@i2pn2.org>
 <va16bg$38gbh$1@dont-email.me> <va1r6b$3bau7$2@dont-email.me>
 <va2542$3cvgv$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 21 Aug 2024 09:59:47 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c35bd23cdeef2c979c84d642c8787936";
	logging-data="3983691"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18dDDIkJG+WYEJ1j6hvzzJJ"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:VELOra3K7kuffkF9gTadnV7RSu4=
In-Reply-To: <va2542$3cvgv$3@dont-email.me>
Content-Language: en-GB
Bytes: 6337

Op 20.aug.2024 om 15:18 schreef olcott:
> On 8/20/2024 5:29 AM, Fred. Zwarts wrote:
>> 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:
>>>>> 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*
>>>>>>> *specified as unspecified*
>>>>>>
>>>>>> Looks like you still have this same condition.
>>>>>>
>>>>>> I thought you said you removed it.
>>>>>>
>>>>>>>
>>>>>>> void DDD()
>>>>>>> {
>>>>>>>    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)
>>>>>>
>>>>>> But it can't emulate DDD correctly past 4 instructions, since the 
>>>>>> 5th 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.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>
>>>>>> And neither X or Y are possible.
>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>
>>>>>
>>>>> Yes that is correct.
>>>>
>>>> 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.
>>>>>>
>>>>>>>
>>>>>>> void EEE()
>>>>>>> {
>>>>>>>    HERE: goto HERE;
>>>>>>> }
>>>>>>>
>>>>>>> HHHn correctly predicts the behavior of DDD the same
>>>>>>> way that HHHn correctly predicts the behavior of EEE.
>>>>>>>
>>>>>>
>>>>>> Nope, HHHn can form a valid inductive proof of the input.
>>>>>>
>>>>>
>>>>>> 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?
>>>>
>>>> But only for DDD∞, not any of the other ones.
>>>>
>>>>>
>>>>> If you can do it and I can do it then HHH can
>>>>> do this same sort of thing. Computations are
>>>>> not inherently dumber than human minds.
>>>>>
>>>>
>>>> But HHHn isn't given DDD∞ as its input, so that doesn't matter.
>>>>
>>>
>>> All of the DDD have identical bytes it is only the HHH that varies.
>>> 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∞.
>> 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.
> 
> HHH∞ is hypothetical thus takes no memory. HHHn(DDD) predicts
> the behavior of a hypothetical HHH∞(DDD) as described below
Which makes HHHn incorrect, because it should simulate its input, not a 
hypothetical non-input HHH∞.