Op 15.aug.2025 om 14:07 schreef olcott:

On 8/15/2025 6:27 AM, Fred. Zwarts wrote:

Op 14.aug.2025 om 23:29 schreef olcott:

On 8/14/2025 2:00 PM, Kaz Kylheku wrote:

On 2025-08-14, olcott <polcott333@gmail.com> wrote:

On 8/14/2025 1:38 PM, Kaz Kylheku wrote:

The name DD in your scenario, like any other name, must unambiguously >>>>>> refer to a single entity.

Yes that is the great insight that you brought to this
discussion.

Yeah, like six years ago maybe?

DD() specifies a different sequence than
DD correctly simulated by HHH.

If you find it necessary in your narrative to separately refer
to a "directly executed DD" and "simulated DD" because they have
different properties, you're doing something wrong.

_DD()
[00002162] 55         push ebp
[00002163] 8bec       mov ebp,esp
[00002165] 51         push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404     add esp,+04
[00002173] 8945fc     mov [ebp-04],eax
[00002176] 837dfc00   cmp dword [ebp-04],+00
[0000217a] 7402       jz 0000217e
[0000217c] ebfe       jmp 0000217c
[0000217e] 8b45fc     mov eax,[ebp-04]
[00002181] 8be5       mov esp,ebp
[00002183] 5d         pop ebp
[00002184] c3         et
Size in bytes:(0035) [00002184]

You cannot show that DD emulated by HH according
to the definition of the x86 language can possibly
reach its own correctly emulated "ret" instruction
because it cannot.

This is because HHH does not terminate, due to runaway
recursion (involving re-entry of simulation levels).

Neither the emulated DD nor the emulated HHH ever stop
running unless they are aborted.

Both the simulated and the simulating HHH have code to abort after a
finite number of recursions. So, there is no non-termination pattern.
Only a finite recursion.
The 'unless they are aborted' is always met, so the sentence can be
simplified to:
Both the emulated DD and the emulated HHH stop running.

It is not whether or not the input stops running
otherwise HHH would have to say that these two halt.

void Infinite_Recursion()
{
  Infinite_Recursion();
  return;
}

void Infinite_Loop()
{
  HERE: goto HERE;
  return;
}

The actual question is whether or not INPUT_DATA
correctly simulated by HHH can reach its own
simulated "return" statement final halt state
in finite number of steps of correct simulation.

As usual repeated incorrect claims.
As usual also incomplete claims.
The question whether HHH is able to reach the final halt state is not
the full question. The full question is whether HHH is able to reach the
final halt state that the input specifies.
If HHH cannot reach the specified final halt state, it fails.
It has been proven that this final halt state is specified by the code
of the input. HHH does not reach it, so it fails. It has a bug to ignore
the conditional branch instructions. If it would correctly analyse the conditions it would see that in the next cycle the other branch would be followed and the program would halt. But the programmer has made HHH
blind for this, because het has the attitude: close your eyes and
pretend that what you do not see does not exist.
He even seems to think that such an can be used as a proof.

The executed HHH recognizes this
*recursive simulation non-halting behavior pattern*
aborts its simulation and returns 0.

As usual incorrect claims without evidence.
The simulating HHH fails to recognise the finite recursion, because it
ignores the conditional branch instructions in the simulation. Due to
this bug, it aborts the simulation prematurely and erroneously reports
non-termination.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/16/25 7:54 AM, olcott wrote:

On 8/16/2025 3:34 AM, Fred. Zwarts wrote:

Op 15.aug.2025 om 14:07 schreef olcott:

On 8/15/2025 6:27 AM, Fred. Zwarts wrote:

Op 14.aug.2025 om 23:29 schreef olcott:

On 8/14/2025 2:00 PM, Kaz Kylheku wrote:

On 2025-08-14, olcott <polcott333@gmail.com> wrote:

On 8/14/2025 1:38 PM, Kaz Kylheku wrote:

The name DD in your scenario, like any other name, must
unambiguously
refer to a single entity.

Yes that is the great insight that you brought to this
discussion.

Yeah, like six years ago maybe?

DD() specifies a different sequence than
DD correctly simulated by HHH.

If you find it necessary in your narrative to separately refer >>>>>>>> to a "directly executed DD" and "simulated DD" because they have >>>>>>>> different properties, you're doing something wrong.

_DD()
[00002162] 55         push ebp
[00002163] 8bec       mov ebp,esp
[00002165] 51         push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404     add esp,+04
[00002173] 8945fc     mov [ebp-04],eax
[00002176] 837dfc00   cmp dword [ebp-04],+00
[0000217a] 7402       jz 0000217e
[0000217c] ebfe       jmp 0000217c
[0000217e] 8b45fc     mov eax,[ebp-04]
[00002181] 8be5       mov esp,ebp
[00002183] 5d         pop ebp
[00002184] c3         et
Size in bytes:(0035) [00002184]

You cannot show that DD emulated by HH according
to the definition of the x86 language can possibly
reach its own correctly emulated "ret" instruction
because it cannot.

This is because HHH does not terminate, due to runaway
recursion (involving re-entry of simulation levels).

Neither the emulated DD nor the emulated HHH ever stop
running unless they are aborted.

Both the simulated and the simulating HHH have code to abort after a
finite number of recursions. So, there is no non-termination
pattern. Only a finite recursion.
The 'unless they are aborted' is always met, so the sentence can be
simplified to:
Both the emulated DD and the emulated HHH stop running.

It is not whether or not the input stops running
otherwise HHH would have to say that these two halt.

void Infinite_Recursion()
{
   Infinite_Recursion();
   return;
}

void Infinite_Loop()
{
   HERE: goto HERE;
   return;
}

The actual question is whether or not INPUT_DATA
correctly simulated by HHH can reach its own
simulated "return" statement final halt state
in finite number of steps of correct simulation.

As usual repeated incorrect claims.
As usual also incomplete claims.
The question whether HHH is able to reach the final halt state is not
the full question. The full question is whether HHH is able to reach
the final halt state that the input specifies.
If HHH cannot reach the specified final halt state, it fails.
It has been proven that this final halt state is specified by the code
of the input. HHH does not reach it, so it fails. It has a bug to
ignore the conditional branch instructions. If it would correctly
analyse the conditions it would see that in the next cycle the other
branch would be followed and the program would halt. But the
programmer has made HHH blind for this, because het has the attitude:
close your eyes and pretend that what you do not see does not exist.
He even seems to think that such an can be used as a proof.

Maybe you should look at the output of the
first LLM system. Your understanding is totally
incorrect.

<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern: abort simulation and
return 0.
(b) Simulated input reaches its simulated "return" statement: return 1.

Input ignore the actual result of doing the above, where a
non-terminating behavior pattern is what it says, and shows that the
correct simulation of the input (not just by the decider that ends up
not doing it0 would not stop which means you need to add:

(c) Runs forever waiting to find one of the above.

typedef int (*ptr)();
int HHH(ptr P);

int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}

What value should HHH(DD) correctly return?

which assumes that HHH will always return, it should be

What value could HHH(DD) correctly return.

<Input to LLM systems>

https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c

https://chatgpt.com/share/68939ee5-e2f8-8011-837d-438fe8e98b9c

https://grok.com/share/c2hhcmQtMg%3D%3D_810120bb-5ab5-4bf8-af21-
eedd0f09e141

Try the fixed version and tell us what it got wrong?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/08/2025 15:09, olcott wrote:

On 8/16/2025 8:05 AM, dbush wrote:

<snip>

;
That the pattern detected by HHH is in fact NOT a

non-halting behavior

pattern because it exists in the halting computation DD, and

furthermore

than HHH fails to meet the specification that he gave.

That you dishonestly use the strawman error as
your rebuttal merely proves that you are dishonest.

What's dishonest about it? To me it looks like a technical claim.
You say HHH(DD) returns 0 (non-halting) to DD, which DD uses to
halt. dbush is pointing out the contradiction.

That's a technical claim that it seems to me has merit. You may
not agree with it, but calling it dishonest is, frankly, puerile.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/16/25 10:09 AM, olcott wrote:

On 8/16/2025 8:05 AM, dbush wrote:

On 8/16/2025 7:54 AM, olcott wrote:

On 8/16/2025 3:34 AM, Fred. Zwarts wrote:

Op 15.aug.2025 om 14:07 schreef olcott:

On 8/15/2025 6:27 AM, Fred. Zwarts wrote:

Op 14.aug.2025 om 23:29 schreef olcott:

On 8/14/2025 2:00 PM, Kaz Kylheku wrote:

On 2025-08-14, olcott <polcott333@gmail.com> wrote:

On 8/14/2025 1:38 PM, Kaz Kylheku wrote:

The name DD in your scenario, like any other name, must
unambiguously
refer to a single entity.

Yes that is the great insight that you brought to this
discussion.

Yeah, like six years ago maybe?

DD() specifies a different sequence than
DD correctly simulated by HHH.

If you find it necessary in your narrative to separately refer >>>>>>>>>> to a "directly executed DD" and "simulated DD" because they have >>>>>>>>>> different properties, you're doing something wrong.

_DD()
[00002162] 55         push ebp
[00002163] 8bec       mov ebp,esp
[00002165] 51         push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404     add esp,+04
[00002173] 8945fc     mov [ebp-04],eax
[00002176] 837dfc00   cmp dword [ebp-04],+00
[0000217a] 7402       jz 0000217e
[0000217c] ebfe       jmp 0000217c
[0000217e] 8b45fc     mov eax,[ebp-04]
[00002181] 8be5       mov esp,ebp
[00002183] 5d         pop ebp
[00002184] c3         et
Size in bytes:(0035) [00002184]

You cannot show that DD emulated by HH according
to the definition of the x86 language can possibly
reach its own correctly emulated "ret" instruction
because it cannot.

This is because HHH does not terminate, due to runaway
recursion (involving re-entry of simulation levels).

Neither the emulated DD nor the emulated HHH ever stop
running unless they are aborted.

Both the simulated and the simulating HHH have code to abort after >>>>>> a finite number of recursions. So, there is no non-termination
pattern. Only a finite recursion.
The 'unless they are aborted' is always met, so the sentence can
be simplified to:
Both the emulated DD and the emulated HHH stop running.

It is not whether or not the input stops running
otherwise HHH would have to say that these two halt.

void Infinite_Recursion()
{
   Infinite_Recursion();
   return;
}

void Infinite_Loop()
{
   HERE: goto HERE;
   return;
}

The actual question is whether or not INPUT_DATA
correctly simulated by HHH can reach its own
simulated "return" statement final halt state
in finite number of steps of correct simulation.

As usual repeated incorrect claims.
As usual also incomplete claims.
The question whether HHH is able to reach the final halt state is
not the full question. The full question is whether HHH is able to
reach the final halt state that the input specifies.
If HHH cannot reach the specified final halt state, it fails.
It has been proven that this final halt state is specified by the
code of the input. HHH does not reach it, so it fails. It has a bug
to ignore the conditional branch instructions. If it would correctly
analyse the conditions it would see that in the next cycle the other
branch would be followed and the program would halt. But the
programmer has made HHH blind for this, because het has the
attitude: close your eyes and pretend that what you do not see does
not exist.
He even seems to think that such an can be used as a proof.

Maybe you should look at the output of the
first LLM system. Your understanding is totally
incorrect.

<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input until: >>> (a) Detects a non-terminating behavior pattern: abort simulation and
return 0.
(b) Simulated input reaches its simulated "return" statement: return 1.

And HHH fails to meet the above spec as you have admitted on the
record (see below):

On 8/15/2025 11:37 AM, dbush wrote:

On 8/15/2025 10:24 AM, olcott wrote:

On 8/15/2025 7:58 AM, dbush wrote:

On 8/15/2025 8:48 AM, olcott wrote:

<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input
until:
(a) Detects a non-terminating behavior pattern:
;      abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:

return 1.

;
And HHH fails to do so as the pattern it detects exists in the
halting program DD and is therefore not a non-halting behavior

pattern.

;
Failing to explain why this is wrong in your next reply or within

one

hour of your next post in this newsgroup will be taken as your
official on-the-record admission that the pattern HHH detects is NOT >>  >>> a non- halting behavior pattern

;
Let the record show that Peter Olcott made no attempt to explain

why the

above is wrong.  Therefore:
;
Let The Record Show:
;
That Peter Olcott
;
Has *officially* admitted
;
That the pattern detected by HHH is in fact NOT a non-halting behavior >>  > pattern because it exists in the halting computation DD, and

furthermore

than HHH fails to meet the specification that he gave.

That you dishonestly use the strawman error as
your rebuttal merely proves that you are dishonest.

Where is the strawman?

The only strawman I have seen is your claim that you can change the requirements, and then you change them to something that is
self-contradictory.

Sorry, you are just proving you don't know what you are talking about.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)