On 08/08/2025 01:05, olcott wrote:

On 8/7/2025 6:27 PM, Richard Heathfield wrote:

Let's see how [ChatGPT] copes with olcott's code:

I am testing the assumption that simulating termination
analyzer HHH correctly simulates its input until it:
(a) Detects a non-terminating behavior pattern: abort
simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
return 1.

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

int DD()
{
   int Halt_Status = HHH(DD);

^^^^^^^^^^^^^^^^^^^^^^^^^
<snip>

Yet the real DD() is not an input to HHH

Yeah it is. See quoted code.

<snip>

*Then it completely validates my whole proof*

You clearly skipped over the part where it said you were talking
complete bollocks:

So if HHH predicts “halts”, the actual execution of DD will loop
forever. That means HHH’s prediction was wrong — it said “halts”,
but it doesn’t. So if HHH predicts “loops forever”, DD() actually terminates (returns 0 immediately). Again, prediction is wrong —
it said “nonterminates”, but it halts. In both cases, whatever
HHH returns is falsified by the actual behaviour of DD():

--
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 2025-08-08, olcott <polcott333@gmail.com> wrote:

Would DD correctly simulated by HHH reach its own simulated
"return" statement final halt state?

Listen, in your x86 simulator you had fatal flaws. Your code relied on
the assumption that when the halting test case calls the simulator in
order to obtaint he halting decision, it is calling the original one at
the same address as the one that is doing the outermost deciding.

This is not a requirement in the halting proof. The test case has a
/copy/ of the halting decider.

In your system, the test case can defeat your strategy easily like this: instead of just calling the halting decider (where your simulator then
detects that the decider is running by looking at the instruction
pointer), the test case can make a copy of the function and relocate it
to another address, where it won't be recognized.

You wrongly believe that a halting decider can detect the situation that
the test case is using that same halting decider (and then behaving
opposite).

But this involves an undecidable problem. What problem is that? Namely, determining whether the test case in fact contains exactly the same
decider as the one being applid to it.

This requires calculating the equivalence of two programs.

Calculating the equivalence of two programs is an undecidable problem in computer science, like universal halting. (It is easily shown
undecidable by a reduction to an instance of the halting problem.)

No, you cannot just assume that everything is in one x86 address space,
and that the test case plays right into your hands by executing a JSR to
the address of the halting decider you have provided. Why would
it do that?

Assume that the attacker has a copy of your halting decider and /embeds/
it into the rebellious test case. The attacker doesn't have to embed a
literal image of that halting decider as you have provided it. It can be translated to another language; for instance, the attacker can translate
your decider into a proprietary byte code, and just include it as an
array of byte code instructions executed by a VM they have written. The attacker can keep your x86 code, but randomly permute it so that it
doesn't compare the same as a bit string.

There is simply no way to reliably make the decision "aha! the test case
has invoked a halting decider precisely equivalent to this one, and
behaved in a contradictory manner!"

The "halting decider precisely equivalent to this one" can look like
anything! It can be written in any language, any style, disguised
by endless permutations.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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

On 08/08/2025 14:29, olcott wrote:

On 8/8/2025 12:51 AM, Richard Heathfield wrote:

On 08/08/2025 01:05, olcott wrote:

On 8/7/2025 6:27 PM, Richard Heathfield wrote:

Let's see how [ChatGPT] copes with olcott's code:

I am testing the assumption that simulating termination
analyzer HHH correctly simulates its input until it:
(a) Detects a non-terminating behavior pattern: abort
simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
return 1.

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

int DD()
{
   int Halt_Status = HHH(DD);

       ^^^^^^^^^^^^^^^^^^^^^^^^^
<snip>

Yet the real DD() is not an input to HHH

Yeah it is. See quoted code.

<snip>

*Then it completely validates my whole proof*

You clearly skipped over the part where it said you were
talking complete bollocks:

So if HHH predicts “halts”, the actual execution of DD will
loop forever. That means HHH’s prediction was wrong — it said
“halts”, but it doesn’t. So if HHH predicts “loops forever”,
DD() actually terminates (returns 0 immediately). Again,
prediction is wrong — it said “nonterminates”, but it halts. In
both cases, whatever HHH returns is falsified by the actual
behaviour of DD():

*You have to examine its final analysis*

In the transcript I posted, I posted the whole thing. The whole
thing said bollocks.

https://chatgpt.com/share/68953d9e-6efc-8011-b266-502025818430
Its final analysis agrees with my whole proof.

So we now know that it will cheerfully take either side of the
debate, depending on how you prime it. You therefore cannot
reasonably point to it as supporting your side and *only* your side.

<snip>

--
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 08/08/2025 17:35, olcott wrote:

When I tell it to make sure to test DD correctly
simulated by HHH then ChatGPT 5.0 gets my same answer:

And when I tell it (neutrally) to check that assumption, it says
the assumption is bollocks... which it is.

--
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 08/08/2025 20:24, olcott wrote:

On 8/8/2025 1:26 PM, Richard Heathfield wrote:

On 08/08/2025 17:35, olcott wrote:

When I tell it to make sure to test DD correctly
simulated by HHH then ChatGPT 5.0 gets my same answer:

And when I tell it (neutrally) to check that assumption, it
says the assumption is bollocks... which it is.

Until you tell it to examine the behavior of DD
correctly simulated by HHH as the only basis for
a correct return value.

As we have already established, HHH cannot correctly simulate DD
sufficiently well to establish its return value. The assumption
that it can is flawed, and your failure to realise this is what
has cost you 22 years of bickering.

--
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 08/08/2025 23:17, olcott wrote:

DD emulated by HHH according to the semantics
of the x86 language cannot possibly reach its
own "ret" instruction final halt state.

Let's accept that for a moment, and see where it leads us.

You seem to be saying that HHH establishes that DD can't return.

HHH must therefore return 0 (false means it doesn't halt).

HHH assigns this to Halt_Status:


so... Halt_Status = 0;

if(Halt_Status)

fails, so we fall past the if and land on:

return Halt_Status;

So DD returns after all, so HHH got it wrong.

Accepting that HHH is correct proves that HHH is incorrect.
Therefore the acceptance was erroneous.

This is not rocket science. To understand this requires no
mystical insight into magical x86 recursive bollocks. You just
have to be able to follow along with your finger. So why can't you?

--
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 08/08/2025 23:33, olcott wrote:

On 8/8/2025 5:31 PM, Richard Heathfield wrote:

<snip>

if(Halt_Status)

*is unreachable from DD correctly simulated by HHH*

Are you saying HHH never returns to its caller? If so, you have
nothing.

--
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)