Re: Title: A Structural Analysis of the Standard Halting Problem Proof

On 7/21/25 5:49 PM, olcott wrote:

On 7/21/2025 3:58 PM, Alan Mackenzie wrote:

[ Followup-To: set ]
>
In comp.theory olcott <polcott333@gmail.com> wrote:

On 7/21/2025 10:52 AM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 7/21/2025 9:40 AM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 7/21/2025 4:06 AM, Mikko wrote:

On 2025-07-20 11:48:37 +0000, Mr Flibble said:

>

On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:

>

[ .... ]

>

Your problem is you don't understand the meaning of the words you are
using.

>

This is an ad hominem attack, not argumentation.

>

It is also honest and truthful, which is not as common as it should.

>
>

It is also honest and truthful that people
that deny verified facts are either liars
or lack sufficient technical competence.

>

What you call "verified facts" are generally nothing of the kind.  They
are merely things, often false, you would like to be true.

>
>
>

*One key example of a denied verified fact is when Joes said*

>

On 7/18/2025 3:49 AM, joes wrote:

very obvious that HHH cannot simulate
DDD past the call to HHH.

>

Joes is quite right, here, as has been said to you many times over by
several people.

>

HHH(DDD) does emulate itself emulating DDD

>

You will have a get out clause from the vagueness of your language, which
could be construed to mean practically anything.

>

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

>

void DDD()
{
   HHH(DDD);
   return;
}

>

int main()
{
   HHH(DDD);
}

>

Not at all. HHH does emulate the x86 machine code
of DDD pointed to by P. That is does this according
to the semantics of the x86 language conclusively
proves that this emulation is correct.

>
That's nauseatingly overstretching things into another lie.  Whatever HHH
might do is far short of sufficient "conclusively to prove" that the
emulation is correct.  To prove that is likely impossible in principle,
that's even assuming you could define "correct" coherently.
>

 [00002192] 55             push ebp
[00002193] 8bec           mov ebp,esp
[00002195] 6892210000     push 00002192
[0000219a] e833f4ffff     call 000015d2  // call HHH
[0000219f] 83c404         add esp,+04
[000021a2] 5d             pop ebp
[000021a3] c3             ret
Size in bytes:(0018) [000021a3]

Which isn't a program, you need to include the code for HHH.
That error means this input isn't runnable or simulatable as is.

 x86utm is a multi-tasking operating system (that I wrote)
that allows any C function to execute any other C function
in debug step mode. HHH and DDD have their own virtual
registers and stack.

NO they don't, the HHH that DDD calls use the same set, as that HHH is part of the program DDD.

 When HHH emulates the first instruction of DDD it
emulates pushing the DDD ebp base pointer onto the
DDD stack.

Right, but it can't emulated the call HHH and the following instruciton using just that input.
Thus, you LIE about what the input is.

 *That is a 100% concrete example of correct emulation*

Nope, it is just PARTIAL correct emulation, as it missed the last part of the instruction, which is to execute/simulate the next one.

 Exactly how is it that you could have construed this
as impossible in principle?
 

The "impossible" part is for HHH to simulate the code of HHH per the x86 lamgage without it being part of its input.
OR for it to be different than the code of the HHH that DDD was built to call and be at the same address (thus, if you can simulate the code of HHH, it is ALWAYS the same code for a given "input" DDD, and there is no "infinite set of HHHs" that see the same DDD, they each see a DIFFERENT one, and thus you can't compare the results.