Path: ...!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: DDD correctly emulated by HHH is correctly rejected as
 non-halting.
Date: Wed, 17 Jul 2024 16:02:45 +0200
Organization: A noiseless patient Spider
Lines: 177
Message-ID: <v78iu5$1rnr3$4@dont-email.me>
References: <v760db$19j7l$10@dont-email.me> <v77tsg$1oeb3$1@dont-email.me>
 <v78hdd$1rc43$9@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 17 Jul 2024 16:02:46 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="1fdd4e182586bca308b558ff6626f471";
	logging-data="1957731"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18/CqcrDdT5omxAFtl9TSdi"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:sLjJaeugZibgsaydVLXdVVTCSCc=
In-Reply-To: <v78hdd$1rc43$9@dont-email.me>
Content-Language: en-GB
Bytes: 8492

Op 17.jul.2024 om 15:36 schreef olcott:
> On 7/17/2024 3:03 AM, Mikko wrote:
>> On 2024-07-16 14:34:19 +0000, olcott said:
>>
>>> On 7/16/2024 2:10 AM, Mikko wrote:
>>>> On 2024-07-15 13:21:35 +0000, olcott said:
>>>>
>>>>> On 7/15/2024 2:52 AM, Mikko wrote:
>>>>>> On 2024-07-14 14:44:27 +0000, olcott said:
>>>>>>
>>>>>>> On 7/14/2024 3:48 AM, Mikko wrote:
>>>>>>>> On 2024-07-13 12:19:36 +0000, olcott said:
>>>>>>>>
>>>>>>>>> On 7/13/2024 2:55 AM, Mikko wrote:
>>>>>>>>>> On 2024-07-12 13:28:15 +0000, olcott said:
>>>>>>>>>>
>>>>>>>>>>> On 7/12/2024 3:27 AM, Mikko wrote:
>>>>>>>>>>>> On 2024-07-11 14:02:52 +0000, olcott said:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 7/11/2024 1:22 AM, Mikko wrote:
>>>>>>>>>>>>>> On 2024-07-10 15:03:46 +0000, olcott said:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>> int HHH(ptr P);
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> void DDD()
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>    HHH(DDD);
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>    HHH(DDD);
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We stipulate that the only measure of a correct emulation
>>>>>>>>>>>>>>> is the semantics of the x86 programming language. By this
>>>>>>>>>>>>>>> measure when 1 to ∞ steps of DDD are correctly emulated by
>>>>>>>>>>>>>>> each pure function x86 emulator HHH (of the infinite set
>>>>>>>>>>>>>>> of every HHH that can possibly exist) then DDD cannot
>>>>>>>>>>>>>>> possibly reach past its own machine address of 0000216b
>>>>>>>>>>>>>>> and halt.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For every instruction that the C compiler generates the 
>>>>>>>>>>>>>> x86 language
>>>>>>>>>>>>>> specifies an unambiguous meaning, leaving no room for "can".
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> then DDD cannot possibly reach past its own machine
>>>>>>>>>>>>> address of 0000216b and halt.
>>>>>>>>>>>>
>>>>>>>>>>>> As I already said, there is not room for "can". That means 
>>>>>>>>>>>> there is
>>>>>>>>>>>> no room for "cannot", either. The x86 semantics of the 
>>>>>>>>>>>> unshown code
>>>>>>>>>>>> determines unambigously what happens.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Of an infinite set behavior X exists for at least one element
>>>>>>>>>>> or behavior X does not exist for at least one element.
>>>>>>>>>>> Of the infinite set of HHH/DDD pairs zero DDD elements halt.
>>>>>>>>>>
>>>>>>>>>> That is so far from the Common Language that I can't parse.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *This proves that every rebuttal is wrong somewhere*
>>>>>>>>> No DDD instance of each HHH/DDD pair of the infinite set of
>>>>>>>>> every HHH/DDD pair ever reaches past its own machine address of
>>>>>>>>> 0000216b and halts thus proving that every HHH is correct to
>>>>>>>>> reject its input DDD as non-halting.
>>>>>>>>
>>>>>>>> Here you attempt to use the same name for a constant programs 
>>>>>>>> and univesally
>>>>>>>> quantifed variable with a poorly specified range. That is a form 
>>>>>>>> of a well
>>>>>>>> known mistake called the "fallacy of equivocation".
>>>>>>>
>>>>>>> I incorporated your suggestion in my paper.
>>>>>>> DDD is a fixed constant finite string that calls its
>>>>>>> HHH at the same fixed constant machine address.
>>>>>>
>>>>>> That does not make sense. Which HHH does that DDD call? Which HHH
>>>>>> is at that fixed machine address?
>>>>>>
>>>>>
>>>>> HHH₁ to HHH∞ forming an infinite set of HHH/DDD pairs
>>>>>
>>>>> HHH₁/DDD₁ to HHH∞/DDD∞ is another way to specify this
>>>>> infinite set of HHH/DDD pairs.
>>>>
>>>> You should not say "another way" before you have one way. What you
>>>> presented earlier is not a way as it did not make sense.
>>>
>>> DDD itself is a single immutable finite string have the exactly
>>> same instructions at the exact same machine addresses.
>>
>> That string does not specify what the call to an address outside of the
>> string does and whether it returns.
> 
> It need not do that. It specifies the address of HHH and the empirical
> behavior of DDD correctly emulated by HHH shows this behavior.
> 
> Also it is stipulated that HHH is an infinite set of x86 emulators
> that correctly emulate 1,2,3...∞ instructions of DDD.

It is self-evident that a simulator cannot simulate an infinite set.
So, you are talking about an infinite set of simulations, each of which 
is incorrect, because each of them abort one cycle too soon.
So, the simulation invariant is: The simulation is incorrect.
An infinite amount of evidence that the simulation is incorrect is 
sufficient proof that the simulation is incorrect.

> 
> _DDD()
> [00002163] 55         push ebp      ; housekeeping
> [00002164] 8bec       mov ebp,esp   ; housekeeping
> [00002166] 6863210000 push 00002163 ; push DDD
> [0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
> [00002170] 83c404     add esp,+04
> [00002173] 5d         pop ebp
> [00002174] c3         ret
> Size in bytes:(0018) [00002174]
> 
> *THIS IS SELF EVIDENT THUS DISAGREEMENT IS INCORRECT*
> DDD emulated by any pure function HHH according to the
> semantic meaning of its x86 instructions never stops
> running unless aborted.

But HHH is programmed to abort after N cyles, so the 'unless abort' is 
misleading. The simulated HHH is programmed exactly the same way, so it 
is incorrect to abort it, when only N-1 cycles have been simulated.
It is *self-evident* that the simulation of an halting function is 
incorrect, unless simulated up to the end.

DDD is a misleading and unneeded complication. It is easy to eliminate DDD:

        int main() {
          return HHH(main);
        }

This has the same problem. This proves that the problem is not in DDD, 
but in HHH, which halts when it aborts the simulation, but it decides 
that the simulation of itself does not halt.

HHH is unable to decide about finite recursions.

void Finite_Recursion (int N) {
   if (N > 0) Finite_Recursion (N - 1);
}

It decides after N recursions that there is an infinite recursion, which 
is incorrect.

Your HHH is programmed to abort the simulation after N cycles of 
recursive simulations. Therefore, it is incorrect to abort the 
simulation of HHH when the simulated HHH has performed only N-1 cycles, 
because that changes the behaviour of HHH.
Since the simulated HHH always runs one cycle behind the simulating HHH, 
it is clear that HHH can never simulate enough cycles for a correct 
simulation, as is required by the x86 language.
Therefore, the simulation is incorrect according to the criteria you 
stipulated.
The conclusion is simple:
HHH cannot possibly simulate itself correctly.

No matter how much you want it to be correct, or how many times you 
repeat that it is correct, it does not change the fact that such a 
simulation is incorrect, because it is unable to reach the end.
Your own claim that the simulated HHH does not reach its end confirms 
it. The trace you have shown also proves that HHH cannot reach the end 
of its own simulation. So, your own claims prove that it is true that 
HHH cannot possibly simulate itself up to the end, which makes the 
simulation incorrect.

Sipser would agree that this incorrect simulation cannot be used to 
detect a non-halting behaviour.