Re: Anyone with sufficient knowledge of C knows that DD specifies non-terminating behavior to HHH

On 2025-02-24 23:36:04 +0000, olcott said:

On 2/24/2025 2:47 AM, Mikko wrote:

On 2025-02-23 17:44:25 +0000, olcott said:
 

On 2/23/2025 4:59 AM, Mikko wrote:

On 2025-02-22 16:11:31 +0000, olcott said:
 

On 2/22/2025 3:04 AM, Mikko wrote:

On 2025-02-21 22:35:16 +0000, olcott said:
 

On 2/21/2025 2:18 AM, Mikko wrote:

On 2025-02-20 21:31:44 +0000, olcott said:
 

On 2/20/2025 2:38 AM, Mikko wrote:

On 2025-02-20 00:31:33 +0000, olcott said:
 

On 2/19/2025 3:01 AM, Mikko wrote:

On 2025-02-18 11:26:25 +0000, olcott said:
 

On 2/18/2025 3:24 AM, Mikko wrote:

On 2025-02-17 09:05:42 +0000, Fred. Zwarts said:
 

Op 16.feb.2025 om 23:51 schreef olcott:

On 2/16/2025 4:30 PM, joes wrote:

Am Sun, 16 Feb 2025 15:58:14 -0600 schrieb olcott:

On 2/16/2025 2:02 PM, joes wrote:

Am Sun, 16 Feb 2025 13:24:14 -0600 schrieb olcott:

On 2/16/2025 10:35 AM, joes wrote:

Am Sun, 16 Feb 2025 06:51:12 -0600 schrieb olcott:

On 2/15/2025 2:49 AM, Mikko wrote:

On 2025-02-14 12:40:04 +0000, olcott said:

On 2/14/2025 2:58 AM, Mikko wrote:

On 2025-02-14 00:07:23 +0000, olcott said:

On 2/13/2025 3:20 AM, Mikko wrote:

On 2025-02-13 04:21:34 +0000, olcott said:

On 2/12/2025 4:04 AM, Mikko wrote:

On 2025-02-11 14:41:38 +0000, olcott said:

 

DD  correctly simulated by HHH cannot possibly terminate normally.

 That claim has already shown to be false. Nothing above shows that
HHH does not return 0. If it does DD also returns 0.

When we are referring to the above DD simulated by HHH and not
trying to get away with changing the subject to some other DD
somewhere else

such as one that calls a non-aborting version of HHH
 

then anyone with sufficient knowledge of C programming knows that no
instance of DD shown above simulated by any corresponding instance
of HHH can possibly terminate normally.

Well, then that corresponding (by what?) HHH isn’t a decider.

I am focusing on the isomorphic notion of a termination analyzer.

(There are other deciders that are not termination analysers.)
 

A simulating termination analyzer correctly rejects any input that
must be aborted to prevent its own non-termination.

Yes, in particular itself is not such an input, because we *know* that
it halts, because it is a decider. You can’t have your cake and eat it
too.

I am not even using the confusing term "halts".
Instead I am using in its place "terminates normally".
DD correctly simulated by HHH cannot possibly terminate normally.

What’s confusing about „halts”? I find it clearer as it does not imply
an ambiguous „abnormal termination”. How does HHH simulate DD
terminating abnormally, then? Why doesn’t it terminate abnormally
itself?
You can substitute the term: the input DD to HHH does not need to be
aborted, because the simulated decider terminates.
 

 typedef void (*ptr)();
int HHH(ptr P);
 int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
 int main()
{
  HHH(DD);
}
 Every simulated input that must be aborted to
prevent the non-termination of HHH is stipulated
to be correctly rejected by HHH as non-terminating.
 

A very strange and invalid stipulation.

 It merely means that the words do not have their ordinary meaning.

 Those two comments are not discussed below.
 

Unless HHH(DD) aborts its simulation of DD itself cannot possibly terminate normally.

 That cannot be determined without examination of HHH, which is not in the
scope of OP.

 I have given everyone here all of the complete source
code for a few years

 True but irrelevant. OP did not specify that HHH means that particular
code.
 

 Every post that I have been talking about for two or
more years has referred to variations of that same code.

 OP had a pointer of that code but didn's state that that code is a part
of the problem. OP did not spacify any range for variation.
 

 I have only been talking about variations of the same code
as HHH(DD) for two years. Do you understand that one sentence?

 I understnd the sentence except the word "variations". What is the
range of "variations"?
 

 Good you are being completely reasonable.
There are at least two algorithms the current
one that was also the original one is easiest to
understand. This algorithm essentially spots the
equivalent of infinite recursion. The code provides
all of the details.
 

Anyway OP did not specify that HHH is restricted to those "variations".
Another undefined word of OP is "cannot". About a person it may mean
that one does not do what one wants to do but a program does not want.
 

 HHH is exactly as specified. Assuming otherwise is silly.

 The words "as specified" when nothing is specified are not a good use
of the language.
 

 _DD()
[00002133] 55         push ebp      ; housekeeping
[00002134] 8bec       mov ebp,esp   ; housekeeping
[00002136] 51         push ecx      ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404     add esp,+04
[00002144] 8945fc     mov [ebp-04],eax
[00002147] 837dfc00   cmp dword [ebp-04],+00
[0000214b] 7402       jz 0000214f
[0000214d] ebfe       jmp 0000214d
[0000214f] 8b45fc     mov eax,[ebp-04]
[00002152] 8be5       mov esp,ebp
[00002154] 5d         pop ebp
[00002155] c3         ret
Size in bytes:(0035) [00002155]
 When DD is correctly simulated by HHH according to the behavior
that the above machine code specifies then the call from DD
to HHH(DD) cannot possibly return making it impossible for DD
emulated by HHH to terminate normally.

 That code does not specify whether HHH ever returns or what value
HHH returns if it does.
 

 When HHH is known to emulate the above code with an x86
emulator THEN

Although OP says that HHH simulates it does not specify what is
simulated.

the above machine code specifies then the call from DD
to HHH(DD) cannot possibly return making it impossible for DD
emulated by HHH to terminate normally.

That cannot be inferred from anything OP shows. Anyway, it does not
matter what HHH should return if it does not return it.
--
Mikko