On 3/2/25 4:11 PM, olcott wrote:

On 3/2/2025 2:40 PM, Andy Walker wrote:

   http://www.cuboid.me.uk/anw/G12FCO/lect18.html

[start at the third paragraph], published in 1996, wherein is the proof
that a simulating halt decider can no more exist than any other halt
decider

[the third paragraph]
For these cases, we can turn to our second weapon -- emulation. We want
to know whether a program halts, so we try it. If it halts, then we know
the answer. If it doesn't halt, then `it must be in a loop', so we
monitor its state and `detect the loop'. Sadly, although this is in one
sense correct, it is a false dichotomy. At any given moment as the
emulation proceeds, we are in one of not two but three states: the
program has halted, or it is looping, or it is still running and has not
yet entered a loop. It's the third case that kills us -- we just have to
keep going, and wait for one of the other two things to happen. The
trouble is that it may be that neither of them ever happens -- which is
why `it must be in a loop' was in quotes above.

_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]

That analysis is derived from an incorrect perspective.
DD emulated by HHH according to the behavior that DD
specifies cannot possibly reach its own "ret" instruction
and terminate normally.

But YOUR perspective is the incorrect one, as it is againt the definitions.

Halting is a property of the Machine, and its direct execution, not can
it be emulated by a decider.

This process computes the mapping from the actual input
(not any other damn thing) finite string to the non
terminating behavior that this finite specifies when
it calls its own emulator in recursive emulation.

And the MAPPING is DEFINED to be input -> 1 if UTM(input) halts, and
input -> 0 if UTM(input) does not halt.

If your HHH isn't a UTM, and a UTM BY DEFINITION EXACTLY reproduces the behavior of the input, thus can't halt if the input is non-halting, then
its emulation doesn't matter.

Another different instance that does not call its own
emulator in recursive emulation is not the same damn thing.

Which means you don't understand the fundamental property that all
copies of a computation (program + input) do exactly the same thing, as
they are not allowed to depend on anything other than there code and the
input.

Your problem is that your DD isn't a program, as it doesn't include all
its code, and you "Decider" isn't either, as it looks at memory other
than that provided by the input, namely to see what HHH is.

Thus, your whole premsis is built on LIES and ERRORS.

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

On 02/03/2025 21:11, olcott wrote:

On 3/2/2025 2:40 PM, Andy Walker wrote:

   http://www.cuboid.me.uk/anw/G12FCO/lect18.html
[start at the third paragraph], [...]

[the third paragraph]

[Note that I said "start at ...", not "look only at ...".]

_DD()
[00002133] 55         push ebp      ; housekeeping

[...]

Not interested; sorry. I was concerned only to point out that
the idea of a "simulating halt decider", or any similar phrase, was not
new in 2004, but has been well-known for many [at least 60] years. If
you choose to waste your remaining time on this planet trying to do the impossible, go ahead. I shan't be joining you, so this will be my last contribution to the debate unless something interesting crops up. "DD"
and "HHH" and similar aren't in the least bit interesting to me; I'm astonished that others are so fascinated, but that's up to them.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Forbes

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

Op 03.mrt.2025 om 01:57 schreef olcott:

On 3/2/2025 6:19 PM, Andy Walker wrote:

On 02/03/2025 21:11, olcott wrote:

On 3/2/2025 2:40 PM, Andy Walker wrote:

   http://www.cuboid.me.uk/anw/G12FCO/lect18.html
[start at the third paragraph], [...]

[the third paragraph]

     [Note that I said "start at ...", not "look only at ...".]

_DD()
[00002133] 55         push ebp      ; housekeeping

[...]

     Not interested;  sorry.  I was concerned only to point out that >> the idea of a "simulating halt decider", or any similar phrase, was not
new in 2004, but has been well-known for many [at least 60] years.  If
you choose to waste your remaining time on this planet trying to do the
impossible, go ahead.  I shan't be joining you, so this will be my last
contribution to the debate unless something interesting crops up.  "DD"
and "HHH" and similar aren't in the least bit interesting to me;  I'm
astonished that others are so fascinated, but that's up to them.

Lots of people rejected the idea of simulation as an
option so you made no actually relevant point at all.

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

The new thing that I discovered is that DD emulated
by HHH cannot possibly reach the self-contradictory
portion thus cannot possibly thwart a correct termination
status decision.

And Olcott thought it was a clever idea to use a simulator that gets
stuck in recursively simulating itself, so that it could not even reach
the self-contradictory part.
Olcott did (does) not realise that such an HHH can only report about its
own behaviour, not that of its input.

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

Am Mon, 03 Mar 2025 08:27:16 -0600 schrieb olcott:

On 3/3/2025 2:55 AM, Fred. Zwarts wrote:

Op 03.mrt.2025 om 01:57 schreef olcott:

On 3/2/2025 6:19 PM, Andy Walker wrote:

On 02/03/2025 21:11, olcott wrote:

On 3/2/2025 2:40 PM, Andy Walker wrote:

   http://www.cuboid.me.uk/anw/G12FCO/lect18.html
[start at the third paragraph], [...]

     Not interested;  sorry.  I was concerned only to point out >>>>      that
the idea of a "simulating halt decider", or any similar phrase, was
not new in 2004, but has been well-known for many [at least 60]
years.  If you choose to waste your remaining time on this planet
trying to do the impossible, go ahead.  I shan't be joining you, so
this will be my last contribution to the debate unless something
interesting crops up.  "DD"
and "HHH" and similar aren't in the least bit interesting to me;  I'm >>>> astonished that others are so fascinated, but that's up to them.

Lots of people rejected the idea of simulation as an option so you
made no actually relevant point at all.
The new thing that I discovered is that DD emulated by HHH cannot
possibly reach the self-contradictory portion thus cannot possibly
thwart a correct termination status decision.

And Olcott thought it was a clever idea to use a simulator that gets
stuck in recursively simulating itself, so that it could not even reach
the self-contradictory part.

HHH has no idea that it is emulating itself emulating DD.
HHH does see that its emulation of DD does match the infinite recursion behavior pattern.

Olcott did (does) not realise that such an HHH can only report about
its own behaviour, not that of its input.

HHH sees DD call the same function with the same params twice in
sequence and HHH also sees that there are no conditional branch
instructions between the invocation of DD and its call to HHH(DD).

It should also see that there is an abort.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

Op 03.mrt.2025 om 15:27 schreef olcott:

On 3/3/2025 2:55 AM, Fred. Zwarts wrote:

Op 03.mrt.2025 om 01:57 schreef olcott:

On 3/2/2025 6:19 PM, Andy Walker wrote:

On 02/03/2025 21:11, olcott wrote:

On 3/2/2025 2:40 PM, Andy Walker wrote:

   http://www.cuboid.me.uk/anw/G12FCO/lect18.html
[start at the third paragraph], [...]

[the third paragraph]

     [Note that I said "start at ...", not "look only at ...".]

_DD()
[00002133] 55         push ebp      ; housekeeping

[...]

     Not interested;  sorry.  I was concerned only to point out that
the idea of a "simulating halt decider", or any similar phrase, was not >>>> new in 2004, but has been well-known for many [at least 60] years.  If >>>> you choose to waste your remaining time on this planet trying to do the >>>> impossible, go ahead.  I shan't be joining you, so this will be my last >>>> contribution to the debate unless something interesting crops up.  "DD" >>>> and "HHH" and similar aren't in the least bit interesting to me;  I'm >>>> astonished that others are so fascinated, but that's up to them.

Lots of people rejected the idea of simulation as an
option so you made no actually relevant point at all.

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

The new thing that I discovered is that DD emulated
by HHH cannot possibly reach the self-contradictory
portion thus cannot possibly thwart a correct termination
status decision.

And Olcott thought it was a clever idea to use a simulator that gets
stuck in recursively simulating itself, so that it could not even
reach the self-contradictory part.

HHH has no idea that it is emulating itself emulating DD.
HHH  does see that its emulation of DD does match the
infinite recursion behavior pattern.

In fact it does, if it didn't it could not assume infinite recursion

Olcott did (does) not realise that such an HHH can only report about
its own behaviour, not that of its input.

HHH sees DD call the same function with the same params
twice in sequence and HHH also sees that there are no
conditional branch instructions between the invocation
of DD and its call to HHH(DD).

But the programmer of HHH forgot to count the conditional branch
instructions inside HHH called by DD up to the start of the inner
simulation of DD, so he made a mistake about the behaviour of the DD.
The direct execution and a correct simulator takes into account those conditional branch instruction. That is why HHH differs: it misses the
correct behaviour of the function called by DD.

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

On 3/3/25 9:27 AM, olcott wrote:

On 3/3/2025 2:55 AM, Fred. Zwarts wrote:

Op 03.mrt.2025 om 01:57 schreef olcott:

On 3/2/2025 6:19 PM, Andy Walker wrote:

On 02/03/2025 21:11, olcott wrote:

On 3/2/2025 2:40 PM, Andy Walker wrote:

   http://www.cuboid.me.uk/anw/G12FCO/lect18.html
[start at the third paragraph], [...]

[the third paragraph]

     [Note that I said "start at ...", not "look only at ...".]

_DD()
[00002133] 55         push ebp      ; housekeeping

[...]

     Not interested;  sorry.  I was concerned only to point out that
the idea of a "simulating halt decider", or any similar phrase, was not >>>> new in 2004, but has been well-known for many [at least 60] years.  If >>>> you choose to waste your remaining time on this planet trying to do the >>>> impossible, go ahead.  I shan't be joining you, so this will be my last >>>> contribution to the debate unless something interesting crops up.  "DD" >>>> and "HHH" and similar aren't in the least bit interesting to me;  I'm >>>> astonished that others are so fascinated, but that's up to them.

Lots of people rejected the idea of simulation as an
option so you made no actually relevant point at all.

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

The new thing that I discovered is that DD emulated
by HHH cannot possibly reach the self-contradictory
portion thus cannot possibly thwart a correct termination
status decision.

And Olcott thought it was a clever idea to use a simulator that gets
stuck in recursively simulating itself, so that it could not even
reach the self-contradictory part.

HHH has no idea that it is emulating itself emulating DD.
HHH  does see that its emulation of DD does match the
infinite recursion behavior pattern.

Exfept it doesn't, since there WERE conditional instruction along the
emulated path.

Also, HHH never CALLS DD, it emulates it, so unless you can prove that
this HHH is a correct emulator that never aborts (which you can't since
it will) you can't even claim infinite recursive emulation.

Sorry, your logic is just based on LIES.

Olcott did (does) not realise that such an HHH can only report about
its own behaviour, not that of its input.

HHH sees DD call the same function with the same params
twice in sequence and HHH also sees that there are no
conditional branch instructions between the invocation
of DD and its call to HHH(DD).

Which is irrelevent. Remember you said that HHH doesn't know that it is
calling itself, so it doesn't know that HHH is an emulator, and thus it
never sees HHH CALL DD, so we

This is all right in the code. https://github.com/plolcott/x86utm/blob/master/Halt7.c

u32 Needs_To_Be_Aborted_Trace_HH(Decoded_Line_Of_Code*
                                 execution_trace,
                                 Decoded_Line_Of_Code
                                 *current)

Which has false patterns in it, which have been pointed out and ignored, proving you just don't care about the truth.

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