Software engineers of extreme technical competence [ halting problem proof refutation ] V2

[olcott]

#include <stdint.h>
typedef void (*ptr)();

void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}

int main()
{
Output("Input_Halts = ", H(P, P));
}

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(P,P) by H would
never reach the "ret" instruction of P.




#define JMP 0xEB // Simplifed OpCode for all forms of JMP
#define CALL 0xE8 // Simplifed OpCode for all forms of CALL
#define JCC 0x7F // Simplifed OpCode for all forms of Jump on Condition
#define RET 0xC3 // Simplifed OpCode for all forms of Return
#define PUSH 0x68 // Simplifed OpCode for all forms of PUSH

typedef struct Decoded
{
u32 Address;
u32 ESP; // Current value of ESP
u32 TOS; // Current value of Top of Stack
u32 NumBytes;
u32 Simplified_Opcode;
u32 Decode_Target;
} Decoded_Line_Of_Code;

Software engineers with extremely high technical competence will be able
to verify that H correctly determines (in a finite number of steps) that
its complete and correct x86 emulation of its input would never reach
the "ret" instruction of P on this criterion measure basis:

H knows its own machine address and on this basis:
(a) H recognizes that P is calling H with the same arguments that H was
called with at its machine address [0000135d]. The immecdiately
precdding pait of PUSH instructions

(b) There are no instructions in P that could possibly escape this
otherwise infinitely recursive emulation.

(c) H aborts its emulation of P before its call to H is invoked.

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
Begin Simulation Execution Trace Stored at:211e9e
...[000010d2][00211e8a][00211e8e] 55 push ebp
...[000010d3][00211e8a][00211e8e] 8bec mov ebp,esp
...[000010d5][00211e8a][00211e8e] 8b4508 mov eax,[ebp+08]
...[000010d8][00211e86][000010d2] 50 push eax // Push P
...[000010d9][00211e86][000010d2] 8b4d08 mov ecx,[ebp+08]
...[000010dc][00211e82][000010d2] 51 push ecx // Push P
...[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // Call H
Infinitely Recursive Simulation Detected Simulation Stopped

Software engineers with extremely high technical competence could
translate the above criterion measure into working code on the basis of
an the execution_trace list of Decoded_Line_Of_Code of the x86 emulated
first seven instructions of P shown above. It is assumed that P has been
translated into x86 by the Microsoft C compiler, thus having the C
calling conventions.

https://docs.microsoft.com/en-us/cpp/cpp/cdecl?view=msvc-170


--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

[Mr Flibble]

void Px(u32 x)
{
H(x, x);
return;
}

int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}

...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)

It gets the answer wrong, i.e. input has not been decided correctly.
QED.

/Flibble

[Richard Damon]

And, what is your basis for THIS wording, the way you interpret it.

There IS an instruction in the PROGRAM P (which is what halting deciders
are supposed to be looking at), namely in the code for H that decides to
abort (or are you talkinga about the H that doesn't abort and thus fails
to answer?)

> (c) H aborts its emulation of P before its call to H is invoked.

And thus is WRONG.

>
>     machine   stack     stack     machine    assembly
>     address   address   data      code       language
>     ========  ========  ========  =========  =============
> Begin Simulation   Execution Trace Stored at:211e9e
> ...[000010d2][00211e8a][00211e8e] 55         push ebp
> ...[000010d3][00211e8a][00211e8e] 8bec       mov ebp,esp
> ...[000010d5][00211e8a][00211e8e] 8b4508     mov eax,[ebp+08]
> ...[000010d8][00211e86][000010d2] 50         push eax      // Push P
> ...[000010d9][00211e86][000010d2] 8b4d08     mov ecx,[ebp+08]
> ...[000010dc][00211e82][000010d2] 51         push ecx      // Push P
> ...[000010dd][00211e7e][000010e2] e820feffff call 00000f02 // Call H
> Infinitely Recursive Simulation Detected Simulation Stopped
>
> Software engineers with extremely high technical competence could
> translate the above criterion measure into working code on the basis of
> an the execution_trace list of Decoded_Line_Of_Code of the x86 emulated
> first seven instructions of P shown above. It is assumed that P has been
> translated into x86 by the Microsoft C compiler, thus having the C
> calling conventions.
>
> https://docs.microsoft.com/en-us/cpp/cpp/cdecl?view=msvc-170
>
>

Yes, you can code the above definition, and get the same broken decider.

H is WRONG, because H(P,P) is SUPPOSED to tell us if P(P) will halt or
not, but if H(P,P) returns 0, then P(P) will Halt, and thus H is wrong.

If H(P,P) doesn't return an answer, it fails to be a decider, and thus
also wrong.

[olcott]

the complete and correct x86 emulation of the input to H(Px,Px) by H
would never reach the "ret" instruction of P because both H and P would
remain stuck in infinitely recursive emulation.

If H can determine that this is the case in a finite number of steps
then H could reject its input on this basis.

If you can't form a correct rebuttal in terms of the actual software
engineering of the *exact words specified above* then that would prove
that you are insufficiently technically competent on this point.

If you incorrectly paraphrase what I said and form a rebuttal to this
incorrect paraphrase then sufficiently technically competent software
engineers would know that you are trying to get away with the strawman
deception.

straw man
An intentionally misrepresented proposition that is set up because it is
easier to defeat than an opponent's real argument.
https://www.lexico.com/en/definition/straw_man

[olcott]

never reach the "ret" instruction of P because both H and P would remain
stuck in infinitely recursive emulation.

If H can determine that this is the case in a finite number of steps
then H could reject its input on this basis.

If you can't form a correct rebuttal in terms of the actual software
engineering of the *exact words specified above* then that would prove
that you are insufficiently technically competent on this point.

If you incorrectly paraphrase what I said and form a rebuttal to this
incorrect paraphrase then sufficiently technically competent software
engineers would know that you are trying to get away with the strawman
deception.

straw man
An intentionally misrepresented proposition that is set up because it is
easier to defeat than an opponent's real argument.
https://www.lexico.com/en/definition/straw_man

[Richard Damon]

Well, if H does a complete and

>
> If H can determine that this is the case in a finite number of steps
> then H could reject its input on this basis.

*IF* which it can't.

Note, if H can stop its emulation, it isn't the H that would do the
complete and correct emulation, now is it?

So, it doesn't matter that this H can determine that some other "H" got
stuck, thats just its not quite a twin.

>
> If you can't form a correct rebuttal in terms of the actual software
> engineering of the *exact words specified above* then that would prove
> that you are insufficiently technically competent on this point.

YOU can't make a correct argument.

>
> If you incorrectly paraphrase what I said and form a rebuttal to this
> incorrect paraphrase then sufficiently technically competent software
> engineers would know that you are trying to get away with the strawman
> deception.

Since your whole arguement is based on an incorrect paraphrase of the
original problem, you are one to talk.

H(M,x) must accept its input if M(x) Halts, and Reject only if M(x)
never will Halt.

P(P) Halts if H(P,P) rejects it (returns 0) so H(P,P) rejecting is
incorrect.

DEFINITION.

IF you want to claim that H(P,P) doesn't refer to P(P), then your P is
defined wrong, since P needs to be asking H about P(P).

So. somewhere you are just lying that you are following the requirements
of the proof you are refuting.

I think the issue is you just don't understand about requireents.

[Richard Damon]

Yes *IF* H just does a complete and correct emulation of its input, the
P(P) will never return, but neither does H(P,P) so it can't answer. THis
is NOT the H you are claiming about, so it is just more red herring.

>
> If H can determine that this is the case in a finite number of steps
> then H could reject its input on this basis.

WHich you can't prove, since if H does reject the input, then the input
is Halting, and you can't actually validly prove something that isn't true.

>
> If you can't form a correct rebuttal in terms of the actual software
> engineering of the *exact words specified above* then that would prove
> that you are insufficiently technically competent on this point.

Since your *EXACT* words are nonsense, postulating an impossible machine
that both complete emulates a non-halting machine and also returning and
answer in finte time, you words refute themselves.

That prove that you are the technically incompetent one in this arguement.

Please explaim how H can do both an infinte number of steps of emulaton
and also return an answer after a finite number of steps?

That says that you have found a finite number bigger than an unbounded
number.

>
> If you incorrectly paraphrase what I said and form a rebuttal to this
> incorrect paraphrase then sufficiently technically competent software
> engineers would know that you are trying to get away with the strawman
> deception.

Well, since YOU started with the incorrect paraphrase, maybe you should
take your own advise.

The halting problem NEVER mentions that the test depends on what the
instance of the decider does, only what the machine the input represents.

>
> straw man
> An intentionally misrepresented proposition that is set up because it is
> easier to defeat than an opponent's real argument.
> https://www.lexico.com/en/definition/straw_man
>
>
>

Yep, you make a lot of scarecrows in your arguements, and then stuff
them with red herring.

Remember the definition:

H(M,x) must Accept its input if M(x) halts and Reject its input if M(x)
will never halt.

P needs to ask H about P(P) and do the opposite.

Since this isn't what you claim to do, and in fact claim that it CAN'T
be, you are just not working on the Halting Problem.