Path: ...!feed.opticnetworks.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Mikko <mikko.levanto@iki.fi>
Newsgroups: comp.theory
Subject: Re: 195 page execution trace of DDD correctly simulated by HH0
Date: Fri, 28 Jun 2024 10:17:09 +0300
Organization: -
Lines: 164
Message-ID: <v5lo1l$3843b$1@dont-email.me>
References: <v4vrfg$2793f$1@dont-email.me> <v58m12$8mmo$1@dont-email.me> <v59797$brmn$1@dont-email.me> <v5b7nv$qvrb$1@dont-email.me> <v5btf3$v0vb$4@dont-email.me> <v5chru$10816$1@i2pn2.org> <v5cn01$149dc$1@dont-email.me> <v5ebvr$1hs89$1@dont-email.me> <v5efod$1ikpr$1@dont-email.me> <v5ejau$1iq57$1@dont-email.me> <v5eup8$1lar1$2@dont-email.me> <v5gidq$221q3$1@dont-email.me> <v5h34g$24jbd$4@dont-email.me> <v5j15p$2k7r0$1@dont-email.me> <v5k688$2qsdr$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 28 Jun 2024 09:17:09 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="74a859aff79fb97670624b29cb98c2a3";
	logging-data="3412075"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19O4CA7ZhWV7lwhOpg9+hR+"
User-Agent: Unison/2.2
Cancel-Lock: sha1:2thGakXVJI2ITEp9Y2GmNigHCs8=
Bytes: 8289

On 2024-06-27 17:07:20 +0000, olcott said:

> On 6/27/2024 1:34 AM, Mikko wrote:
>> On 2024-06-26 12:55:43 +0000, olcott said:
>> 
>>> On 6/26/2024 3:10 AM, Mikko wrote:
>>>> On 2024-06-25 17:29:12 +0000, olcott said:
>>>> 
>>>>> On 6/25/2024 9:13 AM, Fred. Zwarts wrote:
>>>>>> Op 25.jun.2024 om 15:12 schreef olcott:
>>>>>>> On 6/25/2024 7:08 AM, Fred. Zwarts wrote:
>>>>>>>> Op 24.jun.2024 om 23:04 schreef olcott:
>>>>>>>>> On 6/24/2024 2:36 PM, joes wrote:
>>>>>>>>>> Am Mon, 24 Jun 2024 08:48:19 -0500 schrieb olcott:
>>>>>>>>>>> On 6/24/2024 2:37 AM, Mikko wrote:
>>>>>>>>>>>> On 2024-06-23 13:17:27 +0000, olcott said:
>>>>>>>>>>>>> On 6/23/2024 3:22 AM, Mikko wrote:
>>>>>>>>>>>>>> That code is not from the mentined trace file. In that file _DDD()
>>>>>>>>>>>>>> is at the addresses 2093..20a4. According to the trace no instruction
>>>>>>>>>>>>>> at the address is executed (because that address points to the last
>>>>>>>>>>>>>> byte of a three byte instruction.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> In order to make my examples I must edit the code and this changes the
>>>>>>>>>>>>> addresses of some functions.
>>>>>>>>>>>> 
>>>>>>>>>>>> Why do you need to make an example when you already have one in the
>>>>>>>>>>>> file mentioned in the subject line?
>>>>>>>>>>>> 
>>>>>>>>>>> I had to make a few more examples such as HH1(DD,DD)
>>>>>>>>>> AFACT HH1 is the same as HH0, right? What happens when HH1 tries to
>>>>>>>>>> simulate a function DD1 that only calls HH1?
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> typedef uint32_t u32;
>>>>>>>>> u32 H(u32 P, u32 I);
>>>>>>>>> 
>>>>>>>>> int P(u32 x)
>>>>>>>>> {
>>>>>>>>>    int Halt_Status = H(x, x);
>>>>>>>>>    if (Halt_Status)
>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>    return Halt_Status;
>>>>>>>>> }
>>>>>>>>> 
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>>    H(P,P);
>>>>>>>>> }
>>>>>>>>> 
>>>>>>>>> I am going to have to go through my code and standardize my names.
>>>>>>>>> H(P,P) was the original name. Then I had to make a one parameter
>>>>>>>>> version, a version that is identical to H, except P does not call
>>>>>>>>> it and then versions using different algorithms. People have never
>>>>>>>>> been able to understand the different algorithm.
>>>>>>>>> 
>>>>>>>>> typedef void (*ptr)();
>>>>>>>>> typedef int (*ptr2)();
>>>>>>>>> int  HH(ptr2 P, ptr2 I); // used with int D(ptr2 P) that calls HH
>>>>>>>>> int HH1(ptr2 P, ptr2 I); // used with int D(ptr2 P) that calls HH
>>>>>>>>> int  HHH(ptr P);         // used with void DDD() that calls HHH
>>>>>>>>> int HHH1(ptr P);         // used with void DDD() that calls HHH
>>>>>>>>> 
>>>>>>>>> *The different algorithm version has been deprecated*
>>>>>>>>> int  H(ptr2 , ptr2 I);  // used with int D(ptr2 P) that calls H
>>>>>>>>> int H1(ptr2 P, ptr2 I); // used with int D(ptr2 P) that calls H
>>>>>>>>> 
>>>>>>>>> *It is much easier for people to see the infinite recursion*
>>>>>>>>> *behavior pattern when they see it actually cycle through the*
>>>>>>>>> *same instructions twice*
>>>>>>>> 
>>>>>>>> Twice is not equal to infinitely. When will you see that?
>>>>>>>> It is strange that you call that an infinite recursion, when H aborts 
>>>>>>>> after two cycles and the simulated H cannot reach its own abort 
>>>>>>>> operation, because it is aborted when it had only one more cycle to go.
>>>>>>>> None of the aborted simulations would cycle more than twice, so 
>>>>>>>> infinite recursion is not seen for an H that aborts the simulation of 
>>>>>>>> itself.
>>>>>>> 
>>>>>>> typedef void (*ptr)();
>>>>>>> int H0(ptr P);
>>>>>>> 
>>>>>>> void DDD()
>>>>>>> {
>>>>>>>    H0(DDD);
>>>>>>> }
>>>>>>> 
>>>>>>> int main()
>>>>>>> {
>>>>>>>    H0(DDD);
>>>>>>> }
>>>>>>> 
>>>>>>> _DDD()
>>>>>>> [00002172] 55               push ebp      ; housekeeping
>>>>>>> [00002173] 8bec             mov ebp,esp   ; housekeeping
>>>>>>> [00002175] 6872210000       push 00002172 ; push DDD
>>>>>>> [0000217a] e853f4ffff       call 000015d2 ; call H0(DDD)
>>>>>>> [0000217f] 83c404           add esp,+04
>>>>>>> [00002182] 5d               pop ebp
>>>>>>> [00002183] c3               ret
>>>>>>> Size in bytes:(0018) [00002183]
>>>>>>> 
>>>>>>> The call from DDD to H0(DDD) when DDD is correctly emulated
>>>>>>> by H0 cannot possibly return.
>>>>>> 
>>>>>> Contradictio in terminis. The fact that the simulated H0 does not 
>>>>>> return shows that the simulation is incorrect.
>>>>> 
>>>>> void Infinite_Recursion()
>>>>> {
>>>>>    Infinite_Recursion();
>>>>> }
>>>>> 
>>>>> Ah so you simply *DON'T BELIEVE IN* infinite recursion where a
>>>>> correct simulating termination analyzer would be required to
>>>>> abort its simulation to correctly report non-terminating behavior.
>>>>> That seems quite dumb of you.
>>>>> 
>>>>>> The simulated H0 does not return, because it is aborted one cycle too 
>>>>>> soon. One cycle later it would return.
>>>>> 
>>>>> Complete lack of sufficient software engineering skill.
>>>> 
>>>> The relevant area of software engineering is testing. The usual attitude of
>>>> software engineers is that a program is accpted when it has been sufficiently
>>>> tested and passed all tests. Consequently, an important part of sofware work
>>>> is the design of tests.
>>>> 
>>>> In the current context the program to be tested is a halting decider.
>>> 
>>> *NO IT IS NOT. H0 IS ONLY AN X86 EMULATOR*
>>> After you quit lying about the behavior of DDD correctly
>>> emulated by H0 then we can move on to the next point.
>> 
>> This discussion is about HH0. The larger context of this discussion is
>> halting deiders and proofs of non-existence of halting deciders.
>> 
>> You have not disagreed with anyting I said, so if you say that I lied
>> then you reveal that you lied.
>> 
> Until you agree with this we cannot move on to the next
> and final point that proves I am correct. Proving that
> point may possibly take longer than the rest of my life
> so let's not delay this OK?
> 
> [00002172] 55               push ebp      ; housekeeping
> [00002173] 8bec             mov ebp,esp   ; housekeeping
> [00002175] 6872210000       push 00002172 ; push DDD
> [0000217a] e853f4ffff       call 000015d2 ; call H0(DDD)
> [0000217f] 83c404           add esp,+04
> [00002182] 5d               pop ebp
> [00002183] c3               ret
> Size in bytes:(0018) [00002183]
> 
> The call from DDD to H0(DDD) when DDD is correctly emulated
> by x86 emulator H0 cannot possibly return.

If it is too hard to prove that H0 has the properties you claim
then an agreement is unlikely. Perhaps you should Δ instead and
just assume it has the properties you consider essential. The
full proof of your claim does not need much more.

-- 
Mikko