Technically competent Software engineers can verify this halting problem proof refutation

[olcott]

#include <stdint.h>
#define u32 uint32_t

#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()
[000010d2](01) 55 push ebp
[000010d3](02) 8bec mov ebp,esp
[000010d5](03) 8b4508 mov eax,[ebp+08]
[000010d8](01) 50 push eax
[000010d9](03) 8b4d08 mov ecx,[ebp+08]
[000010dc](01) 51 push ecx
[000010dd](05) e820feffff call 00000f02
[000010e2](03) 83c408 add esp,+08
[000010e5](02) 85c0 test eax,eax
[000010e7](02) 7402 jz 000010eb
[000010e9](02) ebfe jmp 000010e9
[000010eb](01) 5d pop ebp
[000010ec](01) c3 ret
Size in bytes:(0027) [000010ec]

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 because both H and P would remain
stuck in infinitely recursive emulation.

If H does correctly determine that this is the case in a finite number
of steps then H could reject its input on this basis. Here are the
details of exactly how H does this in a finite number of steps.

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;

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[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

// actual fully operational code in the x86utm operating system
u32 H(u32 P, u32 I)
{
HERE:
u32 End_Of_Code;
u32 Address_of_H; // 2022-06-17
u32 code_end = get_code_end(P);
Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
Allocate(sizeof(Decoded_Line_Of_Code));
Registers* master_state = (Registers*)
Allocate(sizeof(Registers));
Registers* slave_state = (Registers*)
Allocate(sizeof(Registers));
u32* slave_stack = Allocate(0x10000); // 64k;
u32 execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) *
1000);

__asm lea eax, HERE // 2022-06-18
__asm sub eax, 6 // 2022-06-18
__asm mov Address_of_H, eax // 2022-06-18
__asm mov eax, END_OF_CODE
__asm mov End_Of_Code, eax

Output("Address_of_H:", Address_of_H); // 2022-06-11
Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);
Output("\nBegin Simulation Execution Trace Stored at:",
execution_trace);
if (Decide_Halting(&execution_trace, &decoded, code_end, &master_state,
&slave_state, &slave_stack, Address_of_H, P, I))
goto END_OF_CODE;
return 0; // Does not halt
END_OF_CODE:
return 1; // Input has normally terminated
}

H knows its own machine address and on this basis it can easily examine
its stored execution_trace of P and determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise infinitely
recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.




Technically competent software engineers may not know this computer
science:

A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.

computation that halts … the Turing machine will halt whenever it enters
a final state. (Linz:1990:234)

The "ret" instruction of P is its final state.

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

[Richard Damon]

Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
was incorrect in its mapping, since the behavior of P(P) is the
DEFINITION of the behavior of H(P,P), especially if that is what P calls
and P is claimed to be built by the Linz template.

So, either P isn't built right, or H isn't built fight, or H is wrong.

[olcott]

Linz and others were aware that: A halt decider must compute the mapping

from its inputs to an accept or reject state on the basis of the actual
behavior that is actually specified by these inputs.

Linz and others made the false assumption that the actual behavior that
is actually specified by the inputs to a simulating halt decider is not
the same as the direct execution of these inputs. They were unaware of
this because no one previously fully examined a simulating halt decider
ever before.

> especially if that is what P calls
> and P is claimed to be built by the Linz template.
>
> So, either P isn't built right, or H isn't built fight, or H is wrong.

[Richard Damon]

"Inputs" don't have "behavior" except by what they represent.

>
> Linz and others made the false assumption that the actual behavior that
> is actually specified by the inputs to a simulating halt decider is not
> the same as the direct execution of these inputs. They were unaware of
> this because no one previously fully examined a simulating halt decider
> ever before.
>

Nope, YOU are the one making the stupid assumption that you get to
change the meaning of the definitions.

All you are doing is CONFIRMING that it is impossible to build a decider
to do the job of a Halt decider, because YOU are claiming you can't even
ask it the question.

If your system can't prhase the question, it can't answer it, so that
shows that there exists a machine that it can't give the corret answer two.

You are reversing the direction of requirements.

H doesn't need to be able to answer for every machine that can be
represented to it, it need to define how to represent every machine that
can exist, and then answer correctly for it.

The domain for H is the representation of ALL possible machines x
representation of ALL possible inputs for that machine.

Yes, if CAN only answer for machines you can represent for it, but if
there is a machine you can't represent, that makes H FAIL, not give H a
"psss" for that input.

You claim that you can't represent that input just PROVES that you
counter is incorrect.

[olcott]

On 6/22/2022 2:55 AM, Malcolm McLean wrote:

> You've dry-run P(P) and it doesn't halt. Additionally the halt decider H
> reports it as non-halting. So it's reasonable to assume that H is correct.
>
> However, when run, P(P) halts. So what are we to conclude? That "the
> actual behaviour that is actually specified by the inputs to a simulating
> halt decider is not the same as the direct execution of these inputs"?

That is an actual immutable verified fact.

> That would have far-reaching consequences. Before going there, maybe
> think up some simpler, alternative explanations and eliminate them.

There are no alternatives to immutable verified facts. H(P,P) halts only
because H(P,P) correctly determines that its input never halts.

Technically competent software engineers would agree. On the basis of
the much more complete details that I provided in my original post.

When P(P) is called from main its behavior depends on the return value
of H. When H is called from main P(P) cannot possibly depend on the
return value of H because the correctly emulated input to H(P,P)
continues to remain stuck in infinite emulation until H aborts it.

[olcott]

On 6/22/2022 7:45 AM, Malcolm McLean wrote:

> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>
>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>> DEFINITION of the behavior of H(P,P),
>>>> Linz and others were aware that: A halt decider must compute the mapping
>>>> from its inputs to an accept or reject state on the basis of the actual
>>>> behavior that is actually specified by these inputs.
>>>> Linz and others made the false assumption that the actual behavior that
>>>> is actually specified by the inputs to a simulating halt decider is not
>>>> the same as the direct execution of these inputs. They were unaware of
>>>> this because no one previously fully examined a simulating halt decider
>>>> ever before.
>>>>> especially if that is what P calls
>>>>> and P is claimed to be built by the Linz template.
>>>>>
>>>>> So, either P isn't built right, or H isn't built fight, or H is wrong.
>>>>
>>> You've dry-run P(P) and it doesn't halt. Additionally the halt decider H
>>> reports it as non-halting. So it's reasonable to assume that H is correct.
>>>
>>> However, when run, P(P) halts. So what are we to conclude? That "the
>>> actual behaviour that is actually specified by the inputs to a simulating
>>> halt decider is not the same as the direct execution of these inputs"?
>> That is an actual immutable verified fact.
>>

> That's your conclusion from your observations and reasoning. You've
> dry-run P(P), and it doesn't halt. You've run H on P(P), and it reports "non-halting".
> You've run P(P), and it halts.
> So one explanation is the one you've given but, as I said, that explanation has
> rather far-reaching consequences. In these circumstances, the sensible
> scientist (or I suppose mathematician, though I'm a scientist and not a
> mathematician) looks for alternative explanations which aren't quite as
> consequential.

That is like looking for alternatives to 5 > 3
5 < 3 wrong, 5 == 3, wrong 5 <= 3 wrong 5 >= 3 correct

>>> That would have far-reaching consequences. Before going there, maybe
>>> think up some simpler, alternative explanations and eliminate them.
>> There are no alternatives to immutable verified facts. H(P,P) halts only
>> because H(P,P) correctly determines that its input never halts.
>>
>> Technically competent software engineers would agree. On the basis of
>> the much more complete details that I provided in my original post.
>>
>> When P(P) is called from main its behavior depends on the return value
>> of H. When H is called from main P(P) cannot possibly depend on the
>> return value of H because the correctly emulated input to H(P,P)
>> continues to remain stuck in infinite emulation until H aborts it.
>>

> That would be one consequence of going with your explanation. We'd have to
> say the behaviour of P(P) differs depending on caller. As I said, try simpler,
> less far-reaching explanations first.

void P(u32 x)

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

H(P,P)==0 is provably correct
H1(P,P)==1 is provably correct.
H1(P,P) reports on the behavior of P(P).

[olcott]

specified by these inputs. The actual behavior of the actual input to
H(P,P) is non halting thus rejecting its input is necessarily correct.

[Jeff Barnett]

On 6/21/2022 8:38 PM, olcott wrote:

<SNIPPED GARBAGE UNRELATED TO MSG SUBJECT>

Peter, you must first identify a competent Software Engineer to do said
verification. There are two problems: The first is that no competent SE
would verify your claims whether or not you shared your crap code with
them. You don't certify a black box from the outside because there are
too many simple errors that wont be caught.

The second is that you have nominated yourself as a competent SE. NOT!!!
You have tried this sham before; it didn't work then and it wont work
now. We are on to you. You told us some of the projects you worked on
and there is a choice of reactions: Assume you lied or assume you did
not and deliberately named projects all of whom were failures. Take your
pick. The truth is that you couldn't even stay employed on government
sponsored make work programs. You know the kind where a manager sends a
WBR* to the personnel office when thy need to increase spending.

Everyone in all the newsgroups you soil with these threads, who has
shown actual competence in SE, Computer Science, or Programming agrees
that you are an incompetent nut. You also showed us one of the worst
written and worst conceived patents we had ever see. If it wasn't for
your learning disabilities and inability to allocate time to useful
sub-projects, you might have done okay. But you have my sympathy; few
are able to overcome nature's limits.

So this thread, like so many others, is dead on arrival.



* Warm Body Requisition. Someone actual showed me such a form used on a
part of Apollo back in the early 1960s. So we see that if you were a
little older there would have been jobs for you but now days, the
requirements are simply too high.
--
Jeff Barnett

[olcott]

On 6/22/2022 10:50 AM, Ben Bacarisse wrote:

> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:

>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>
>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>> DEFINITION of the behavior of H(P,P),
>>>>> Linz and others were aware that: A halt decider must compute the mapping
>>>>> from its inputs to an accept or reject state on the basis of the actual
>>>>> behavior that is actually specified by these inputs.
>>>>> Linz and others made the false assumption that the actual behavior that
>>>>> is actually specified by the inputs to a simulating halt decider is not
>>>>> the same as the direct execution of these inputs. They were unaware of
>>>>> this because no one previously fully examined a simulating halt decider
>>>>> ever before.
>>>>>> especially if that is what P calls
>>>>>> and P is claimed to be built by the Linz template.
>>>>>>
>>>>>> So, either P isn't built right, or H isn't built fight, or H is wrong.
>>>>>
>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt decider H
>>>> reports it as non-halting. So it's reasonable to assume that H is correct.
>>>>
>>>> However, when run, P(P) halts. So what are we to conclude? That "the
>>>> actual behaviour that is actually specified by the inputs to a simulating
>>>> halt decider is not the same as the direct execution of these inputs"?
>>>
>>> That is an actual immutable verified fact.
>>>

>> That's your conclusion from your observations and reasoning. You've
>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>> reports "non-halting". You've run P(P), and it halts. So one
>> explanation is the one you've given but, as I said, that explanation
>> has rather far-reaching consequences.
>

> There is only one explanation. What you call the "dry-run" is not that
> same as the P(P). We've known this since the "line 15 commented out"
> days. There are two computations -- one that is not stopped and one
> that is, the "dry-run" and the run, the "simulation of the input to
> H(P,P)" and P(P). All PO is doing is trying to find words that hide
> what's going on.
>

My words are perfectly clear and correct thus leaving the only possible
rebuttal of changing the words and forming a rebuttal on the basis of
these changed words.

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

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 correctly reject its input on this basis.

[olcott]

On 6/22/2022 12:11 PM, Jeff Barnett wrote:
> On 6/21/2022 8:38 PM, olcott wrote:
>
> <SNIPPED GARBAGE UNRELATED TO MSG SUBJECT>
>
> Peter, you must first identify a competent Software Engineer to do said
> verification. There are two problems: The first is that no competent SE
> would verify your claims whether or not you shared your crap code with
> them. You don't certify a black box from the outside because there are
> too many simple errors that wont be caught.
>

My words are perfectly clear and correct thus leaving the only possible
rebuttal of changing the words and forming a rebuttal on the basis of
these changed words.

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

After 100 reviewers in a dozen forums over a period of one year:
On 6/14/2022 6:47 AM, Paul N wrote:
> Yes, it is clear to us humans watching
> it that the program is repeating itself.
> Thus we can appreciate that it will never
> reach the final "ret" - indeed, it won't
> even get to the infinite loop identified above.

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

Sufficiently competent software engineers will agree that if you cannot
verify that the above reasoning is valid forms sufficient proof that you
are not a sufficiently competent software engineer as defined below:

A software engineer must be an expert in: the C programming language,
the x86 programming language, exactly how C translates into x86 and the
ability to recognize infinite recursion at the x86 assembly language
level. No knowledge of the halting problem is required.

> The second is that you have nominated yourself as a competent SE. NOT!!!

Clueless wonders always use ad hominem personal attacks as their basis
of rebuttal because that is all that they have.

[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

[olcott]

You and Richard are insufficiently technically competent at software
engineering not meeting these specs:

A software engineer must be an expert in: the C programming language,
the x86 programming language, exactly how C translates into x86 and the
ability to recognize infinite recursion at the x86 assembly language
level. No knowledge of the halting problem is required.

[olcott]

On 6/22/2022 2:31 PM, Mr Flibble wrote:

You and Richard are insufficiently technically competent at software
engineering not meeting these specs:

A software engineer must be an expert in: the C programming language,
the x86 programming language, exactly how C translates into x86 and the
ability to recognize infinite recursion at the x86 assembly language
level. No knowledge of the halting problem is required.

The proof of your technical incompetence that others can see is that you
only stater dogmatically that I am wrong without pointing out any actual
mistakes.

The proof of the technical incompetence of Richard and Ben is that they
intentionally paraphrase what I said incorrect so that they can use the
strawman deception to form a rebuttal on the basis of this intentionally
incorrect paraphrase.

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

The proof of the technical incompetence of most everyone else is that
they simply provide ad hominem insults as the entire basis of their fake
"rebuttal". That zero rebuttals with any plausible basis have been
presented for many weeks is very encouraging.

[Mr Flibble]

[Mr Flibble]

I cannot speak for Richard but I have 30+ years C++ experience; I also
have C and x86 assembly experience (I once wrote a Zilog Z80A CPU
emulator in 80286 assembly) and I can recognize an infinite recursion;
the problem is that you cannot recognize the fact that the infinite
recursion only manifests as part of your invalid simulation-based
omnishambles: the recursion simply isn't there for a "valid" halt
decider, that being a halt decider that can return an answer in finite
time to ALL invokers: H needs to return an answer to Px to be
considered a valid halt decider.

/Flibble

[olcott]

If you are competent then you already know this is true and lie about it:

Every sufficiently competent software engineer can easily verify that

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.

Otherwise you are incompetent.

> the recursion simply isn't there for a "valid" halt
> decider, that being a halt decider that can return an answer in finite
> time to ALL invokers: H needs to return an answer to Px to be
> considered a valid halt decider.
>
> /Flibble
>

[Mr Flibble]

On Wed, 22 Jun 2022 16:41:43 -0500

Why did you ignore the second part? Again:

The problem is that you cannot recognize the fact that the infinite

recursion only manifests as part of your invalid simulation-based

omnishambles: the recursion simply isn't there for a "valid" halt

[olcott]

It is easily provably correct. That you lack the technical competence to
verify that the x86 emulated behavior of the x86 emulation of the input
to H(P,P) by H precisely matches the behavior specified by P is far less
than no rebuttal at all.

I am not going to keep responding to your nonsense I don't really give a
rat's ass for the woefully incorrect opinion of incompetent people.

> omnishambles: the recursion simply isn't there for a "valid" halt
> decider, that being a halt decider that can return an answer in finite
> time to ALL invokers: H needs to return an answer to Px to be
> considered a valid halt decider.
>
> /Flibble
>

[Jeff Barnett]

On 6/22/2022 12:10 PM, olcott wrote:
> On 6/22/2022 12:11 PM, Jeff Barnett wrote:
>> On 6/21/2022 8:38 PM, olcott wrote:
>>
>> <SNIPPED GARBAGE UNRELATED TO MSG SUBJECT>
>>
>> Peter, you must first identify a competent Software Engineer to do
>> said verification. There are two problems: The first is that no
>> competent SE would verify your claims whether or not you shared your
>> crap code with them. You don't certify a black box from the outside
>> because there are too many simple errors that wont be caught.

> My words are perfectly clear and correct thus leaving the only possible
> rebuttal of changing the words and forming a rebuttal on the basis of
> these changed words.

Your words are not clear even to you. Are you really that stupid? Your
not a Software Engineer, Computer Scientist, or a Programmer of even
modest skills. Sorry. Your accomplishments here on USENET or on the job
are of so trite a nature that no one of any accomplishments in these
areas can allow you pollute newsgroup after newsgroup with the same
repetitive dribble. I think you have invented the "E" version of the
good old "cluster fuck". (That's one innovation you can put on your resume.)

> 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 because both H and P would remain
> stuck in infinitely recursive emulation.

And that's the point. You are neither a competent Software Engineer nor
one who can judge competence. Remember all those employers who told you
the same thing.

> After 100 reviewers in a dozen forums over a period of one year:
> On 6/14/2022 6:47 AM, Paul N wrote:
> > Yes, it is clear to us humans watching
> > it that the program is repeating itself.
> > Thus we can appreciate that it will never
> > reach the final "ret" - indeed, it won't
> > even get to the infinite loop identified above.
>
> If H can determine that this is the case in a finite number of steps
> then H could correctly reject its input on this basis.

Let's give Paul N a little credit but not much; notice that he doesn't
even understand the point of the exercise which is that the *same
function* must be used for both inner and outer purposes.

> Sufficiently competent software engineers will agree that if you cannot
> verify that the above reasoning is valid forms sufficient proof that you
> are not a sufficiently competent software engineer as defined below:

Ass backwards as usual.

> A software engineer must be an expert in: the C programming language,
> the x86 programming language, exactly how C translates into x86 and the
> ability to recognize infinite recursion at the x86 assembly language
> level. No knowledge of the halting problem is required.

That's really a shame for you since you have little knowledge or
competence in anything above. Strangely you need knowledge of the
halting problem to judge whether you have a legit counter example. So as
to what you "need knowledge of", you are once again ass backward.

>> The second is that you have nominated yourself as a competent SE. NOT!!!
>
> Clueless wonders always use ad hominem personal attacks as their basis
> of rebuttal because that is all that they have.

Mine isn't an ad hominem attack: It is based not only on my perception
of your nonsense but 100's of others pointing out glaring repetitive
errors. You on the other hand repeated nonsense, most of it off topic,
and then claim that someone else's competence is lacking.

Let's close by paraphrasing Schopenhauer to describe you Peter:

"Ignorance induces errors no one else could duplicate;
Ignorance + stupidity and ambition induce errors no one could foresee."
--
Jeff Barnett

[olcott]

On 6/22/2022 4:53 PM, Dennis Bush wrote:

> H (if it was constructed correctly) is a computation, and a computation *always* gives the same output for a given input. So it doesn't make sense to say what it "would" do. It either does or does not perform a complete and correct emulation. And because H contains code to abort, and does abort, it does not do a complete emulation.
>
> So the input must be given to a UTM, which by definition does a correct and complete simulation, to see what the actual behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.

Every sufficiently competent software engineer can easily verify that
the complete and correct x86 emulation of the input to H(Px,Px) by H

would never reach the "ret" instruction of Px because both H and Px

would remain stuck in infinitely recursive emulation.

When we assume this non-halting criteria and H does correctly apply this
criteria in a finite number of steps then H(Px,Px) does correctly
determine that its input never halts.

The above proves itself totally true entirely on the basis of the
meaning of its words: AKA it is self-evident truth.

In epistemology (theory of knowledge), a self-evident proposition is a
proposition that is known to be true by understanding its meaning
without proof, and/or by ordinary human reason.
https://en.wikipedia.org/wiki/Self-evidence





Of course because we know your modus operandi we already know that you
are going to intentionally incorrectly paraphrase what I said in an
attempt 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

The strawman deception is quite effective when gullible fools are the
target audience.

[olcott]

All that you have ever provided as rebuttal is some combination of mere
rhetoric that mostly nothing more than pure ad hominem personal attacks.
I known that you have good technical reasoning, yet you have never shown
any of it in any critique of my work.

No one can possibly provide any correct rebuttal to this because it is a
semantic tautology: proven totally true entirely on the basis of the
meaning of its words:

Every sufficiently competent software engineer can easily verify that

the complete and correct x86 emulation of the input to H(Px,Px) by H
would never reach the "ret" instruction of Px because both H and Px

would remain stuck in infinitely recursive emulation.

When we assume this non-halting criteria and H does correctly apply this
criteria in a finite number of steps then H(Px,Px) does correctly
determine that its input never halts.

The above proves itself totally true entirely on the basis of the
meaning of its words: AKA it is self-evident truth.

In epistemology (theory of knowledge), a self-evident proposition is a
proposition that is known to be true by understanding its meaning
without proof, and/or by ordinary human reason.
https://en.wikipedia.org/wiki/Self-evidence

[olcott]

You dishonestly snipped the part that proves that he does know this.

[Mr Flibble]

On Wed, 22 Jun 2022 16:58:24 -0500

Your H doesn't return a value to its invoker, Px in this case, so isn't
a valid halt decider. Valid halt deciders always return a value to
ALL their invokers in finite time with no infinite recursion.

That you repeatedly argue in the form of ad hominem attacks shows you
cannot recognise a logical fallacy or that you are in the wrong. You
completely refuse to tackle the argument as presented.

>
> I am not going to keep responding to your nonsense I don't really
> give a rat's ass for the woefully incorrect opinion of incompetent
> people.

You have yet to actually respond to the argument in a clear and honest
way.

[Richard Damon]

You have this wrong.

A decider must compute the mapping that represents the FUNCTION it is
deciding, there is actually nothing about "behavior" in the definition.

For a HALTING decider, that mapping is based on the HALTING Behavior of
the machine the input REPRESENTS.

Inputs are just strings, and as such don't have behaviors in and of
themselves.

If the behavior the decider sees doesn't match the behavior of the
machine the input is supposed to represent, then either the decider is
misdefined and is generating the wrong behavior, or the input wasn't
constructed properly.

In H(P,P) vs P(P), you have provided both the H and the input
representation, so if the input doesn't represent P(P), it is YOUR mistake.

If H can't be given an input to represents P(P), then H is defective and
not a counter example. If P giving H the wrong parameters, then you P is
defined wrong and not a counter example.

In short, sonce P(P) Halts when H(P,P) returns 0, then H(P,P) returning
0 is NOT a counter example to the halting problem. If somehow you want
to call it a correct answer, it is to the wrong question so doesn't
actually provide the counter example you claim.

You repeating this claim over and over just shows that you have no
understand of what you are talking about.

[olcott]

On 6/22/2022 5:48 PM, Dennis Bush wrote:

> So you just repeated what you said instead of explaining why I'm wrong. In other words you provided no rebuttal, which can only be taken to mean that you have none.

Your entire basis and all of assumptions was incorrect so when I
provided an infallible one to that cannot possibly be correctly refuted
you simply dodged it. That is a smart move for a dishonest person that
is only interested in rebuttal.

I dare you to go back to the prior post and find any error in my
airtight correct reasoning. Another dodge will be construed as a tacit
admission of defeat.

[Richard Damon]

On 6/22/22 1:58 PM, olcott wrote:
>
> My words are perfectly clear and correct thus leaving the only possible
> rebuttal of changing the words and forming a rebuttal on the basis of
> these changed words.

No, they aren't because they don't match the definitons of the problem
you claim to be working on.

Start with wrong definitions, and NOTHING that follows is valid. or correct.

H applied to M, x needs to accept this input if M applied to x reaches a
final state in a finite number of steps and reject this input if M
applied to x will NEVER, after an unbounded number of steps, reach a
final state.

Since when P applied to P uses H applied to P, P and then does the
opposite gets the reject answer from H it Halts, then H applied to P,P
rejecting this input can't be correct.

PERIOD.

DEFINITION.

The fact that you try to twist the requirements and definitions to try
to show something else, just proves that you are either dishonest or
ignorant.

You will NEVER be right, because your ideas are just WRONG.

[olcott]

The provably correct execution trace of Px proves that H cannot possibly
return a value to Px because of the behavior of Px. That this is
over-your-head is no rebuttal what-so-ever.

[olcott]

If you construe this as the actual behavior that the actual input
specifies then this is correct otherwise this is incorrect.

People that actually understand these things deeply on the basis of all
of the deep connected meanings will agree. People that understand these
things only by the rote memorization of what textbooks say may get
confused.

This is computer science that I wrote that is verifiably correct and
clarifies the misconceptions of what a halt decider must do:

A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually

specified by these inputs. Copyright Olcott 2021

[olcott]

On 6/22/2022 6:11 PM, Richard Damon wrote:
> On 6/22/22 1:58 PM, olcott wrote:
>>
>> My words are perfectly clear and correct thus leaving the only
>> possible rebuttal of changing the words and forming a rebuttal on the
>> basis of these changed words.
>
> No, they aren't because they don't match the definitons of the problem
> you claim to be working on.

That is an entirely separate issue that cannot possibly be correctly
addressed until after my words are totally agreed to in the precise
context that they are specified.

[Richard Damon]

If it isn't the acutual behavior, then it just isn't a Halt Decider, but
maybe your POOP decider.

DEFINITIONS, you know.

>
> People that actually understand these things deeply on the basis of all
> of the deep connected meanings will agree. People that understand these
> things only by the rote memorization of what textbooks say may get
> confused.
>
> This is computer science that I wrote that is verifiably correct and
> clarifies the misconceptions of what a halt decider must do:
>
> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior that is actually
> specified by these inputs. Copyright Olcott 2021
>

Which isn't correct unless that actual behavior matches that defined by
the definition of an ACTUAL Halt Decider, which is the behavior of the
machine the input represents.

You don't get to change definitions.


Note, you also don't get to copyright definitions, just your artistic
representation of them.

I guess due to your degree of artistic license you take with
definitions, you might be able to claim copyright on your versions.

After all, they are a work of fiction. (maybe just semi-fiction).

[Richard Damon]

On 6/22/22 8:00 PM, olcott wrote:
> On 6/22/2022 6:11 PM, Richard Damon wrote:
>> On 6/22/22 1:58 PM, olcott wrote:
>>>
>>> My words are perfectly clear and correct thus leaving the only
>>> possible rebuttal of changing the words and forming a rebuttal on the
>>> basis of these changed words.
>>
>> No, they aren't because they don't match the definitons of the problem
>> you claim to be working on.
>
> That is an entirely separate issue that cannot possibly be correctly
> addressed until after my words are totally agreed to in the precise
> context that they are specified.
>

If you start with the wrong definitions, why do people need (or even
want to) agree with them.

Your whole argument STARTS with a misunderstanding of the basic terms,
therefore the full thing is just garbage.

I wll note, that when you get ready to try to publish, the FIRST thing
that the publisher is going to want to see is your list of refences for
where you get your basics from.

The fact that they are just your own misunderstanding of the
fundamentals means you are going to get a foot into the door.

[olcott]

The behavior of P(P) is provably not the actual behavior of the actual
input to H(P,P). That you are insufficiently technically competent to
verify this is far less than no rebuttal at all.

[Richard Damon]

Except that I am probably at least as much of an expert on those fields
as you are. My one problem is that I do have knowledge of the halting
problem, that seems to make me resistant to your lies.

You might have more experiance with x86, but only because I work on a
number of different architectures, but your argument really isn't x86
specific, that is just the case you are working in.

(I was producing 'production' assembly routines 50 years ago, so I have
seen a number of different types of machines)

[olcott]

On 6/22/2022 7:25 PM, Richard Damon wrote:
> On 6/22/22 8:00 PM, olcott wrote:
>> On 6/22/2022 6:11 PM, Richard Damon wrote:
>>> On 6/22/22 1:58 PM, olcott wrote:
>>>>
>>>> My words are perfectly clear and correct thus leaving the only
>>>> possible rebuttal of changing the words and forming a rebuttal on
>>>> the basis of these changed words.
>>>
>>> No, they aren't because they don't match the definitons of the
>>> problem you claim to be working on.
>>
>> That is an entirely separate issue that cannot possibly be correctly
>> addressed until after my words are totally agreed to in the precise
>> context that they are specified.
>>
>
> If you start with the wrong definitions, why do people need (or even
> want to) agree with them.
>

First you agree that my words are perfectly correct within their
specified context then after this we can proceed with your objection
that they do not meet the definitions.

It is required that we have incremental closure on sub-points or full
closure will be impossible to achieve.

[olcott]

First you agree that my words are perfectly correct within their
specified context

The software engineering aspect of this original post

On 6/21/2022 9:38 PM, olcott wrote:

then after this we can proceed with your objection that they do not meet
the definitions.

It is required that we have incremental closure on sub-points or full
closure will be impossible to achieve.

[Richard Damon]

Since you haven't actualy defined you context, and imply that it is the
halting problem, where they can not be correct, that is not possible.

>
> The software engineering aspect of this original post
> On 6/21/2022 9:38 PM, olcott wrote:
>
> then after this we can proceed with your objection that they do not meet
> the definitions.
>
> It is required that we have incremental closure on sub-points or full
> closure will be impossible to achieve.
>

Until you accept accurate definitions, closure is impossible.

To get there, first you need to actually defintely DEFINE what you think
you are saying with something that describes something possible.

For instance, defining H to make decision based on H's complete and
correct emulation requires as a prerequisite that H actual DOES a
complete and correct emulation, which means that it can not EVER abort
its simulation.

So ANY arguement based on H doing both a complete and correct emulation
and also abort its emulation is illogical and ill-defined.
It is just an example of the Liar's paradox, aptly named because it is
being given by a liar.

[Richard Damon]

THen prove it. You know state the established basis in the field that
you start your argument from, and the step by step logic to get to that
answer.

Be prepared to give sources for your claimed "established basises".

Since for the Halting Problem, it is definitional, this will be hard to do.

It may well be that YOUR H shows a different behavior, but that just
shows it isn't actually a Halt Decider.

Remember the Definition:

H applied to M, w must accept if M applied to x halts in a finite number
of steps, and reject if M applied to x will not halt even when taken to
an unbounded number of steps.

DEFINITION.

H^ / P is DEFINED in the Linz proof to be asking H about P applied to
its own input.

Thus if P uses H applied to P, P, then for P to have been built
correctly, that input must refer to P applied to P.

Thus if P(P) isn't what H(P,P) is actually asking about, then either H
or P has been not defined correctly.

YOU FAIL.

You can't claim conformance to the requirements of the proof you are
countering and have H(P,P) not be looking at the behavor of P(P).

Doesn't matter if it is impossible to ask H that, such an impossiblity
is just support for the Theorem you are trying to disprove.

You arguments are just showing you don't even understand that basics of
the problem you have worked on for decades, which shows how much you
have wasted your time.

[olcott]

On 6/22/2022 7:48 PM, Richard Damon wrote:
> On 6/22/22 8:37 PM, olcott wrote:

>> First you agree that my words are perfectly correct within their
>> specified context
>
> Since you haven't actualy defined you context, and imply that it is the
> halting problem, where they can not be correct, that is not possible.
>>

First you agree that these words are 100% correct within the context of
software engineering totally ignoring the context of the halting problem.

[olcott]

I have proved it dozens of times and every fake "rebuttal" simply
ignores the proof.

[Richard Damon]

On 6/22/22 8:34 PM, olcott wrote:
> On 6/22/2022 7:25 PM, Richard Damon wrote:
>> On 6/22/22 8:00 PM, olcott wrote:
>>> On 6/22/2022 6:11 PM, Richard Damon wrote:
>>>> On 6/22/22 1:58 PM, olcott wrote:
>>>>>
>>>>> My words are perfectly clear and correct thus leaving the only
>>>>> possible rebuttal of changing the words and forming a rebuttal on
>>>>> the basis of these changed words.
>>>>
>>>> No, they aren't because they don't match the definitons of the
>>>> problem you claim to be working on.
>>>
>>> That is an entirely separate issue that cannot possibly be correctly
>>> addressed until after my words are totally agreed to in the precise
>>> context that they are specified.
>>>
>>
>> If you start with the wrong definitions, why do people need (or even
>> want to) agree with them.
>>
>
> First you agree that my words are perfectly correct within their
> specified context then after this we can proceed with your objection
> that they do not meet the definitions.
>
> It is required that we have incremental closure on sub-points or full
> closure will be impossible to achieve.
>
>

I will not agree that Falshoods are correct.

IF you make that a precondition, you might as well give up.

The Journal reviews will not accept that either.

You need to break down your first points to show that they actually are
correct. This will require you to CLEARLY define your terms in terms of
what the standard theory uses.

You are hamstringing yourself by moving away from the simplicity of
Turing Macines into stored program machines, as you are going to first
need to show that you can actually properly express the problem in that
space.

Note, the "C Function" P that you show, by itself, is not something that
Computation Theory talks much about, as it doesn't express a complete
algorithm without a PROPER definition of H.

You clearly don't know the field well enough to provide that, since you
haven't yet.

An ACTUAL source code of H, and everything it calls, would be such a
definition, PROVIDED that code obeys the requriements of being a
computation (which is close to, but not identical to, a 'Pure Function'
that you have been talking about).

[Richard Damon]

So, if H actually is a program that does a COMPLETE and correct x86
emulation of its input, then YES, as I have said many time before, this
combination is non-halting.

The fact that you need to keep going back to this, and seem to just be
refusing to accept the conditions under which you have proved it just
shows the problems with your thought process.

> If H does correctly determine that this is the case in a finite number
> of steps then H could reject its input on this basis. Here are the
> details of exactly how H does this in a finite number of steps.

Except that NOW H isn't the H we were just talking about, so you are
just proving that you are either lying or an idiot.

Remember, the first analysis had the CONDITION on it that H did a
COMPLETE and correct x86 emulation.

Once you remove that property form H, that conclusion no long holds and
you are shown to be a lying idiot.

(b) is NOT a correct rule. Thos has been pointed out before, and you
have ignored it.

Your repeating it, without showing a source that claims it, or some
proof that it is correct, just proves that you are mentally incapable of
doing the task.

FAIL.


You appear to have gaslighted yourself into believing you own lies, or
are just a blatant patholgical liar.

If this is the best you have, you need to just give up and accept that
you are NEVER going to be able to establish your false claims to any
level of acceptance.

You might be able to fool a few people, but they are almost certainly
going to realize their error and snap out of it.

Hopefull, some day, you will to.

[olcott]

On 6/22/2022 8:02 PM, Dennis Bush wrote:

> As stated before H (or more accurately Ha) does not perform a complete and correct emulation because it aborts. So by definition it cannot be complete.

I never claimed that H(P,P) performs a complete and correct emulation of
its input so your rebuttal is the strawman deception.

I claimed that H(P,P) correctly predicts that its complete and correct
x86 emulation of its input would never reach the "ret" instruction of P.

[Richard Damon]

Nope, you have claimed it, and given rhetorical arguments.

You don't even seem to understand what a PROOF is, so that may be your
problem.

I haven't once seen you start with a list of ACCEPTED truths in the
field and progressed from there. You ALWAYS throw in something that is
"true by the meaning of the words" that actually isn't because you don't
know the actual meaning of the words, and can't actually quote tem as
they apply to the field.

You don't understand that Natural Language is NOT the source of Truth,
but is actually one of the traps of logic that leads the unwary into error.

Truth comes out of FORMAL meaning and agreement with reality.

[olcott]

That you don't understand what I mean does not mean that it is an
incorrect rule.

Here is an example where P does have instruction that could possibly
escape this otherwise infinitely recursive emulation:


void P(ptr x)
{
static count = 0;
count++;
if count > 3)
return;

if (H(x, x))
HERE: goto HERE;
return;
}

[olcott]

I have provided a complete provably correct execution traces of H(P,P)
and P(P) that conclusively proves that they really do have different
behavior yet people rejected it on the basis that they simply do not
"believe in" the x86 language. This is why I aptly called them
despicable liars.

[Richard Damon]

FALLACY of proof by example. I never said that (b) isn't sometimes true,
just it isn't an always true condition. You fail at elementary logic.

The fundamental problem is you don't understand what is 'P' to
computation theory, it isn't just the 'C Function' but includes
EVERYTHING that P calls, and thus includes H.

Thus, the conditional in H that decides to abort its further emulation
is PART of the program P, and thus the 'No Conditional' condition isn't
satisfied.

You just seem to be too ignorant of the basic to be able to reason.

[olcott]

On 6/22/2022 8:21 PM, Dennis Bush wrote:

> But since H, or more accurately Ha, *can't* do a correct and complete emulation of its input, your point is moot.

_Infinite_Loop()
[00001082](01) 55 push ebp
[00001083](02) 8bec mov ebp,esp
[00001085](02) ebfe jmp 00001085
[00001087](01) 5d pop ebp
[00001088](01) c3 ret
Size in bytes:(0007) [00001088]

Begin Local Halt Decider Simulation Execution Trace Stored at:211e8f
...[00001082][00211e7f][00211e83] 55 push ebp
...[00001083][00211e7f][00211e83] 8bec mov ebp,esp
...[00001085][00211e7f][00211e83] ebfe jmp 00001085
...[00001085][00211e7f][00211e83] ebfe jmp 00001085
Infinite Loop Detected Simulation Stopped

On the basis of this exact same utterly moronic reasoning because H
*can't* do a correct and complete emulation of its input, H cannot
possibly determine that _Infinite_Loop() never halts.

[olcott]

Try and find a valid counter-example. Every attempt at rebuttal that is
not a valid counter-example is one form of deception or another.

[Richard Damon]

P(P)

The conditional that break the loop is in the H that you are excluding
from the 'function' P incorrectly.

I have said this before. You just can't learn it seems.

[Richard Damon]

Nope.

The trace you provide are NOT correct traces, as a CORRECT x86 trace of
the execution of P will show the instructions in H that get exectuted.

Thus, you are PROVEN to have just LIED.

it seems you wouldn't know what Truth was if it bit you, but it seems it
doesn't want to touch you with a 39 1/2 foot pole.

If you want to actually PROVE your claim, what is the FIRST x86
instruction in the execution sequence of the two that produces a
different result from the same input.

Since you have the program, that should be simple for you to find.

I have asked for this before, and you failure to provide it just shows
that you are lying.

[Richard Damon]

You like your herring red don't you.

You LOVE that Fallacy of proof by example.

It isn't said that H can NEVER prove that in input doesn't halt, just
that it can't use the rule you provided because it isn't true.

The above doesn't need to rely on the fact that H 'did' a correct and
complete emulation, so the fact that it didn't doesn't affect things.

You just don't understand the elementary rules of logic.

[olcott]

On 6/22/2022 8:44 PM, Dennis Bush wrote:

> Now who's using the strawman error? Just because H can determine that _Infinite_Loop does not halt doesn't mean that it gets other cases right. B

You just said that H(P,P) cannot correctly predict that the correct and
complete x86 emulation of its input would never reach the "ret"
instruction of P without a compete x86 emulation of its input. I just
proved that is a very stupid thing to say.

[olcott]

That is not any example of (b), thus another mere strawman deception.

[Richard Damon]

No, that isn't what he said. Just shows you can't read.

He said that an H that aborts its simulation can't do a Complete and
Correct emulation of its input.

THis means that any proof based on it doing so is incorrect.

Remember, your logic is that SINCE (1) H does a complete and correct
emulation of its input, and (2) if H does a complete and correct
emulation of its input then P(P) will not halt, we can combine (1) and
(2) to say that P(P) will not Halt.

SInce (1) isn't true, the logic is unsound.

Spelled out fuller:

S1: H does a complete and correct emulation of its input.
S2: P(P) is non-halting.

given deduction: S1 -> S2

Arguement, since S1, and S1 -> S2, then S2

But since if H aborts its simulation to answer, S1 is not true, the
logic doesn't hold.

[Richard Damon]

Why not?

P(P) Halts, if H(P,P) returns 0 which it will do because of the pattern,
but the is no conditional in what you call P that could possible escape
this pattern?

Unless you point out what disquaifies if from being an example, you need
to accept it.

Of course, if you point out WHY it isn't an example, you break your own
arguement.

Remember P(P) Halts BECAUSE H uses an incorrect rule to decide that it
doesn't.

You can't just define that H is correct, you need to define an algorithm
that makes H correct and that can't be just pushed off to something else
needing to do the 'hard' part of deciding.

Of course if someone gives you a machine that decides in finite time if
an input is non-halting, you can build a halt decider that answers in
finite time, but that is just presuming the answer, which is invalid
logic, so you can't just assume it.

ALL the algorithms you have tried to propose fall into that camp, so
none of them have been valid.

[olcott]

Implying that H cannot predict the behavior of the complete and correct
x86 emulation of its input without performing an actual complete emulation.

[olcott]

On 6/22/2022 9:23 PM, Dennis Bush wrote:

> You said that H can predict what *its* correct and complete emulation would do, and I said that doesn't make sense because H does not do correct and complete emulation. What H *must* do is predict what *the* correct and complete emulation, i.e. UTM(P,P), would do. And it fails to do that.

There are no UTM's in software engineering thus yet another strawman
deception.

[Richard Damon]

No, you just don't understand English I guess. (or logic).

Your 'proof' is based on an H that performs a complete and correct emultion.

An H that aborts and answers non-halting is not such an H.

You statement thus has a logical flaw and is invalid.

That you don't understand this is YOUR problem, deal with it.

[Richard Damon]

On 6/22/22 10:46 PM, olcott wrote:
>
> There are no UTM's in software engineering thus yet another strawman
> deception.
>

Then I guess you are admitting to being a liar, since you have used that
term in the past to refer to that operaiton.

You are just digging your grave deeper and deeper.

You seem to be slowly (or not so slowly) losing your mind.

[olcott]

It is not an example of the simulation of the input to H(P,P) at all.

Basically you must adapt P so that when H(P,P) emulates its input it
determines that P never reaches its "ret" instruction and the adapted
emulated P still reaches its "ret" instruction.

[Richard Damon]

Why is P not P?

The code of P calls H, and when H returns 0 it executes its ret
instruction and "halts"

The Question is NOT can H emulate its input to the final state, it is
does the input represent a computation that Halts.

H has given up its claim to being the determination of the correct and
complete emualtion of its input by aborting its emulation.

You claim that this H/P pair matches Linz, thus P MUST be calling H in a
way that asks if P(P) will Halt or not, the the input to H(P,P) MUST
refer to P(P), and thus the correct emulation of it must behave the same
as P(P).

OR, are you admitting that you have been lying all the time?

We have a ground rule that YOU established that we are working in the
context of a Halt Decider and the "impassible program" as defined by Linz.

That established the meaning of the input to H.

You answer seems to be that Truth can't be True because it makes your
proof not work.

That isn't a very good grounds to be working from.

[olcott]

> Why is P not P?
>

It is not a direct rebuttal of my original claim.

This would be a direct rebuttal:
You must adapt P so that when H(P,P) emulates its input it determines

that P never reaches its "ret" instruction and the adapted emulated P
still reaches its "ret" instruction.

[olcott]

Unless you find that at least one input where it gets the wrong answer
you have not refuted me.

[olcott]

On 6/22/2022 9:48 PM, Dennis Bush wrote:

> Now you're just making things up. Of course there are UTMs. Anything that does a correct and complete emulation is a UTM.
>
> Just goes to show how desperate you're getting to make a statement like that.
>

*This change provides cognitive leverage*
I am separately analyzing these things utterly stripped of the baggage
of halting problem or Turing Machine concepts.

It is all a matter of a x86 emulated inputs reaching their "ret"
instructions.

[Richard Damon]

Your problem is I have, but you are just proving that you can't rebut an
idiot, because they won't understand the rebuttal.

One problem you have is your basic premise is incorrect because it is
inconsistent.

Your example shows a case where rule (b) causes you to NOT abort, and
thus not activate the flaw in your logic.

The first problem is that for ANY non-halting input by the classic
definition, like infinite-loop, you current definition, does the
complete and correct emulation by H reach a final state becomes broken,
as if H aborts its simulation, and thus NEVER DID a complete and correct
simulation.

That is like asking did you make a million dollars at your job when you
worked as a programmer in the 1700's?

The question is just based on a false premise. Since H doesn't actually
DO a complete and correct emulation of those inputs, you can't ask about
the results of that emulation. At BEST, you need to be asking about some
OTHER emulator that does, and when do do THAT, se we see that
Simulate(P,P) will halt if H(P,P) returns 0.

Thus, when we FIX that to use a REAL definition of Halting, since the
problem uses that word, we see that P(P) DOES Halt if H(P,P) returns 0,
so it becomes the counter example.

If you actually are trying to say that you get to define things as
impossible, then you have just actually PROVEN that you whole logic
system is just worthless and you haven't proven anything.

I could just as easily say, Lets define Halting as it stops in 3
instructions, after that, it is higher than some can count so that is
close enough to "infinity". By that definition, yes, P(P) is
non-halting, but who cares, that is a broken definition. JUST LIKE YOURS IS.

[olcott]

On 6/23/2022 11:28 AM, Mike Terry wrote:
> On 23/06/2022 13:13, Paul N wrote:
>> On Thursday, June 23, 2022 at 2:20:40 AM UTC+1, olcott wrote:
>>> On 6/22/2022 8:05 PM, Dennis Bush wrote:

>>>> On Wednesday, June 22, 2022 at 8:56:08 PM UTC-4, olcott wrote:
>>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>>>> On 6/22/22 8:37 PM, olcott wrote:
>>
>>>>> #include <stdint.h>
>>>>> #define u32 uint32_t
>>>>>
>>>>> #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));
>>>>> }
>>

>>> I claim that H(P,P) correctly predicts that its complete and correct x86
>>> emulation of its input would never reach the "ret" instruction of P.
>>
>> To split this claim down into three parts:
>>
>> You are claiming that H(P,P) terminates.
>> You are claiming that the value returned by H(P,P) is zero/false,
>> indicating that P(P) would not terminate.
>> You are claiming that this result is correct, and that P(P) does
>> indeed not terminate.
>>
>> This is what you are saying, correct?
>>
>> So let's look at P(P). The first thing is does is call H(P,P). This,
>> you have stated many times including just above, terminates. It gives
>> a value zero. Thus the infinite loop is not entered, and the next
>> instruction to be executed is the "return".
>>
>> So P(P) does terminate, contrary to what you claimed.
>>
>
> PO acknowledges that P(P) does terminate, and has posted one of his
> "traces" showing this.  (Note: his traces are not showing x86
> instructions from a single x86 processor - the entries are from multiple
> "logical processors" with some of the processors being simulated - the
> simulation logic (including tests that may decide to terminate the
> simulating activity at some point) is suppressed from the trace, so that
> you won't be "confused"!)
>
> PO claims instead that :
> -   H(P,P) returns 0 (as you say)
> -   P(p) terminates
> -   H(P,P) is "correct" to return 0, even though 0 is the wrong halting
>     problem answer, because H's /simulation/ of P(P) never reaches P's
>     final ret instruction - this is correct, because H only simulates
>     until some internal test matches, at which point it stops
>     simulating P(P), and indeed that happens before P(P) simulation
>     gets as far as the P ret instruction.
> PO has lots of incoherent waffle which serves only to confuse PO into
> believing that H is returning the "correct" answer, when it is obviously
> wrong [from the HP perspective].
>
> Mike.

Hi Mike, I am glad to see you back. I count you as one of my
sufficiently technically qualified reviewers.

The key bottom line that everyone either makes sure to ignore or
directly disagrees with the correct semantics of the x86 language is
that H does correctly predict that its own complete and correct x86
emulation of its input would never reach the "ret" instruction (final
state) of P thus never halts.

computation that halts … the Turing machine will halt whenever it enters
a final state. (Linz:1990:234)

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)

[olcott]

On 6/23/2022 7:13 AM, Paul N wrote:
> On Thursday, June 23, 2022 at 2:20:40 AM UTC+1, olcott wrote:
>> On 6/22/2022 8:05 PM, Dennis Bush wrote:
>>> On Wednesday, June 22, 2022 at 8:56:08 PM UTC-4, olcott wrote:
>>>> On 6/22/2022 7:48 PM, Richard Damon wrote:
>>>>> On 6/22/22 8:37 PM, olcott wrote:
>
>>>> #include <stdint.h>
>>>> #define u32 uint32_t
>>>>
>>>> #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));
>>>> }
>
>> I claim that H(P,P) correctly predicts that its complete and correct x86
>> emulation of its input would never reach the "ret" instruction of P.
>
> To split this claim down into three parts:
>
> You are claiming that H(P,P) terminates.

Yes

> You are claiming that the value returned by H(P,P) is zero/false, indicating that P(P) would not terminate.

No. zero/false indicates that
H(P,P) does correctly determine that its correct and complete x86

emulation of its input would never reach the "ret" instruction of P.

As shown below because P(P) depends on the return value of H(P,P) it has
different behavior than the correctly emulated input to H(P,P).

The correctly emulated input to H(P,P) is stuck in recursive emulation
that never gets to the point of receiving a return value from H, thus
lacks the dependency of the executed P(P). This causes it to have
different behavior than the executed P(P) having this dependency.

> You are claiming that this result is correct, and that P(P) does indeed not terminate.
>
> This is what you are saying, correct?
>
> So let's look at P(P). The first thing is does is call H(P,P). This, you have stated many times including just above, terminates. It gives a value zero. Thus the infinite loop is not entered, and the next instruction to be executed is the "return".
>
> So P(P) does terminate, contrary to what you claimed.

To fully understand this code a software engineer must be an expert in:

the C programming language, the x86 programming language, exactly how C
translates into x86 and the ability to recognize infinite recursion at
the x86 assembly language level. No knowledge of the halting problem is
required.

The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does
correctly determine that its correct and complete x86 emulation of its

input would never reach the "ret" instruction of P.

In computer science terminology this means that complete and correct
emulation P by H would never reach its final state and halt.

void P(u32 x)

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

int main()
{

P(P);
}

_P()
[000011f0](01) 55 push ebp
[000011f1](02) 8bec mov ebp,esp
[000011f3](03) 8b4508 mov eax,[ebp+08]
[000011f6](01) 50 push eax
[000011f7](03) 8b4d08 mov ecx,[ebp+08]
[000011fa](01) 51 push ecx
[000011fb](05) e820feffff call 00001020
[00001200](03) 83c408 add esp,+08
[00001203](02) 85c0 test eax,eax
[00001205](02) 7402 jz 00001209
[00001207](02) ebfe jmp 00001207
[00001209](01) 5d pop ebp
[0000120a](01) c3 ret
Size in bytes:(0027) [0000120a]

_main()
[00001210](01) 55 push ebp
[00001211](02) 8bec mov ebp,esp
[00001213](05) 68f0110000 push 000011f0
[00001218](05) e8d3ffffff call 000011f0
[0000121d](03) 83c404 add esp,+04
[00001220](02) 33c0 xor eax,eax
[00001222](01) 5d pop ebp
[00001223](01) c3 ret
Size in bytes:(0020) [00001223]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============

[00001210][00101fba][00000000] 55 push ebp
[00001211][00101fba][00000000] 8bec mov ebp,esp
[00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P
[00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P
[000011f0][00101fae][00101fba] 55 push ebp // enter executed P
[000011f1][00101fae][00101fba] 8bec mov ebp,esp
[000011f3][00101fae][00101fba] 8b4508 mov eax,[ebp+08]
[000011f6][00101faa][000011f0] 50 push eax // push P
[000011f7][00101faa][000011f0] 8b4d08 mov ecx,[ebp+08]
[000011fa][00101fa6][000011f0] 51 push ecx // push P
[000011fb][00101fa2][00001200] e820feffff call 00001020 // call H

Begin Simulation Execution Trace Stored at:21206e
Address_of_H:1020
[000011f0][0021205a][0021205e] 55 push ebp // enter emulated P
[000011f1][0021205a][0021205e] 8bec mov ebp,esp
[000011f3][0021205a][0021205e] 8b4508 mov eax,[ebp+08]
[000011f6][00212056][000011f0] 50 push eax // push P
[000011f7][00212056][000011f0] 8b4d08 mov ecx,[ebp+08]
[000011fa][00212052][000011f0] 51 push ecx // push P
[000011fb][0021204e][00001200] e820feffff call 00001020 // call H

Infinitely Recursive Simulation Detected Simulation Stopped

H knows its own machine address and on this basis it can easily examine

its stored execution_trace of P (see above) to determine:

(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise infinitely
recursive emulation.

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

[00001200][00101fae][00101fba] 83c408 add esp,+08 // return to
executed P
[00001203][00101fae][00101fba] 85c0 test eax,eax
[00001205][00101fae][00101fba] 7402 jz 00001209
[00001209][00101fb2][0000121d] 5d pop ebp
[0000120a][00101fb6][000011f0] c3 ret // return from
executed P
[0000121d][00101fba][00000000] 83c404 add esp,+04
[00001220][00101fba][00000000] 33c0 xor eax,eax
[00001222][00101fbe][00100000] 5d pop ebp
[00001223][00101fc2][00000000] c3 ret // ret from main
Number of Instructions Executed(878) / 67 = 13 pages

[olcott]

On 6/23/2022 7:20 AM, Paul N wrote:
> On Wednesday, June 22, 2022 at 11:10:50 PM UTC+1, Jeff Barnett wrote:
>> On 6/22/2022 12:10 PM, olcott wrote:
>>> On 6/22/2022 12:11 PM, Jeff Barnett wrote:
>>>> On 6/21/2022 8:38 PM, olcott wrote:
>>> After 100 reviewers in a dozen forums over a period of one year:
>>> On 6/14/2022 6:47 AM, Paul N wrote:
>>>> Yes, it is clear to us humans watching
>>>> it that the program is repeating itself.
>>>> Thus we can appreciate that it will never
>>>> reach the final "ret" - indeed, it won't
>>>> even get to the infinite loop identified above.
>>>
>>> If H can determine that this is the case in a finite number of steps
>>> then H could correctly reject its input on this basis.
>> Let's give Paul N a little credit but not much; notice that he doesn't
>> even understand the point of the exercise which is that the *same
>> function* must be used for both inner and outer purposes.
>
> Olcott has snipped part of the post where I did briefly address this. However, he did say that his purpose in posting to comp.lang.c and comp.lang.c++ was simply to check the language aspects of his posts, and they did seem OK on that basis. I've just put a post here on comp.theory addressing the more theoretical points, which hopefully will be more to your liking; if you disagree with the points I've made there then probably best to reply to that post directly.

I have already addressed your other post completely and I stuck with
pure software engineering terms and concepts conclusively proving that
the dependency relationship that P(P) has on H(P,P) causes its behavior
to be quite different than the complete and correct x86 emulation of the
input to H(P,P) that has no such dependency relationship.

The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction of P.

In computer science terminology this means that complete and correct
emulation P by H would never reach its final state and halt.

[olcott]

On 6/23/2022 3:19 AM, Malcolm McLean wrote:
> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:

>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>>> DEFINITION of the behavior of H(P,P),

>>>>>> Linz and others were aware that: A halt decider must compute the mapping

>>>>>> from its inputs to an accept or reject state on the basis of the actual
>>>>>> behavior that is actually specified by these inputs.

>>>>>> Linz and others made the false assumption that the actual behavior that
>>>>>> is actually specified by the inputs to a simulating halt decider is not
>>>>>> the same as the direct execution of these inputs. They were unaware of
>>>>>> this because no one previously fully examined a simulating halt decider
>>>>>> ever before.
>>>>>>> especially if that is what P calls
>>>>>>> and P is claimed to be built by the Linz template.
>>>>>>>
>>>>>>> So, either P isn't built right, or H isn't built fight, or H is wrong.
>>>>>>
>>>>> You've dry-run P(P) and it doesn't halt. Additionally the halt decider H
>>>>> reports it as non-halting. So it's reasonable to assume that H is correct.
>>>>>
>>>>> However, when run, P(P) halts. So what are we to conclude? That "the
>>>>> actual behaviour that is actually specified by the inputs to a simulating
>>>>> halt decider is not the same as the direct execution of these inputs"?
>>>>
>>>> That is an actual immutable verified fact.
>>>>
>>> That's your conclusion from your observations and reasoning. You've
>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
>>> reports "non-halting". You've run P(P), and it halts. So one
>>> explanation is the one you've given but, as I said, that explanation
>>> has rather far-reaching consequences.

>> There is only one explanation. What you call the "dry-run" is not that
>> same as the P(P). We've known this since the "line 15 commented out"
>> days. There are two computations -- one that is not stopped and one
>> that is, the "dry-run" and the run, the "simulation of the input to
>> H(P,P)" and P(P). All PO is doing is trying to find words that hide
>> what's going on.
>>
> I'm a scientists, not a mathematician.
> The example I always use is that you are doing an energy budget for tigers.
> You work how much they use on running about, lactating, maintaining their
> body temperature, and so on.
>
> Now let's say that you find that all results are within a few percentage points
> of a similar budget done for lions. You'd instantly accept this data.
>
> Now let's say that the results are wildly different from a previous budget done
> for lions. You wouldn't just accept that data. You'd check. You'd want to
> understand the reasons tigers spend far less energy on movement than lions.
>
> Now let's say that the result show that tigers use more energy than they
> take in food. Would you instantly conclude that the law of conservation of
> energy must be incorrect?
>
> The third is what PO is doing.

I rewrote this up so that sufficiently competent software engineers
would be able to confirm that the following is correct:

To fully understand this code a software engineer must be an expert in:
the C programming language, the x86 programming language, exactly how C
translates into x86 and the ability to recognize infinite recursion at
the x86 assembly language level. No knowledge of the halting problem is
required.

The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction of P.

In computer science terminology this means that complete and correct
emulation P by H would never reach its final state and halt.

The dependency relationship that P(P) has on H(P,P) causes its behavior

to be quite different than the complete and correct x86 emulation of the
input to H(P,P) that has no such dependency relationship.

As shown below because P(P) depends on the return value of H(P,P) it has
different behavior than the correctly emulated input to H(P,P).

The correctly emulated input to H(P,P) remains stuck in recursive

emulation that never gets to the point of receiving a return value from
H, thus lacks the dependency of the executed P(P).

[000011fb][0021204e][00001200] e820feffff call 00001020 // call emulated H

Infinitely Recursive Simulation Detected Simulation Stopped

H knows its own machine address and on this basis it can easily examine
its stored execution_trace of P (see above) to determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise infinitely
recursive emulation.
(c) H aborts its emulation of P before its call to H is emulated.

[00001200][00101fae][00101fba] 83c408 add esp,+08 // return to
executed P
[00001203][00101fae][00101fba] 85c0 test eax,eax
[00001205][00101fae][00101fba] 7402 jz 00001209
[00001209][00101fb2][0000121d] 5d pop ebp
[0000120a][00101fb6][000011f0] c3 ret // return from
executed P
[0000121d][00101fba][00000000] 83c404 add esp,+04
[00001220][00101fba][00000000] 33c0 xor eax,eax
[00001222][00101fbe][00100000] 5d pop ebp
[00001223][00101fc2][00000000] c3 ret // ret from main
Number of Instructions Executed(878) / 67 = 13 pages

[Mr Flibble]

Here:

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

return;
}

int main()
{

[olcott]

To fully understand this code a software engineer must be an expert in:
the C programming language, the x86 programming language, exactly how C
translates into x86 and the ability to recognize infinite recursion at
the x86 assembly language level. No knowledge of the halting problem is
required.

The ordinary semantics of standard C and the conventional x86 language

are the entire semantics required to conclusively prove that H(Px,Px)

does correctly determine that its correct and complete x86 emulation of

its input would never reach the "ret" instruction of Px.

It is always the case that whenever anyone disagrees with verifiable
facts (as you have just done) that they are necessarily always incorrect.

[Mr Flibble]

On Thu, 23 Jun 2022 14:56:26 -0500

Nope. You are incorrect and your H is incorrect: Px should always halt
if H is a valid halt decider that returns to its invoker: Px (i.e. not
main).

/Flibble

[Richard Damon]

(b) is invalid, so H is not correct.

H's criteria of being defined to deside on ITS OWN compelete and correct
emulation is basicaly saying that cats that are dog can bark, thus there
exists cats that bark.

ANY simulating decider H that somehow decides that its input is
non-halting and stops its simulations doesn't do a complete and correct
simulation, and thus it is WRONG to say that was a basis for its decision.

Until you can show how a simulator can simulate an unbounded number of
steps (aka infinite number) in a finite number of steps, you have an
impossible premise.

That means you need to find a computation system that can do infinite
work in finite time for your arguement to be valid.

YOU FAIL.

[olcott]

On 6/23/2022 6:55 PM, dklei...@gmail.com wrote:

> And what exactly was your original claim?

H is always correct when it determines that an emulated input specifies
infinitely nested emulation whenever H matches the (a)(b)(c) criteria to
the behavior of this input.

Obviously a rebuttal would be to find a case where H is incorrect under
these exact same conditions.

[Richard Damon]

No, it doesn't, because what it shows is that a mythological machine was
correct. The machine described is one that SIMULTANOUSLY does a complete
and correct emulation of its input, while ALSO stopping in finite time
to return the non-halting answer.

Since it claims the input is non-halting, that means it emulated that
full infinite behavior in only a finite number of steps.

That is just a Fairy Tale.

It is the same as showing that some cats bark because you have a cat
that is a dog that barks. Since there is no cat that is a dog, you don't
have an entity to be the "some".

Since there is no H that does both a complete and correct emulation and
also at the same time returns a correct non-halting answer, you don't
actually have an H.

Yor failure to understand this problem shouw your lack of understand of
the field.

[olcott]

Because of this reply after I have corrected you hundreds of times I
have blocked you and all of your messages have been erased.

[Richard Damon]

Plugging your ears and saying "I can't hear you" doesn't make you correct.

It just makes it certain that if you ever get to trying to publish, you
are going to have a FATAL error in your paper and remove any chance of
paper getting accepted. They may not even answer enough to give you a
rejection.

Note, you may be able to make it so YOU don't see what I say, but
everyone else does, and the mere fact that you are ignoring a "voice of
reason" will taint others opinion of you.

[olcott]

On 6/24/2022 2:53 AM, Malcolm McLean wrote:

>> I have no idea what parts of this analogy map to the current situation.
>> PO has no contradictory results about anything. There's no conflict
>> with any established facts in anything he is doing.
>>
> He's dry-run P(P) and established that it doesn't halt. He's invoked H on it
> and H reports that it doesn't halt. He's run P(P) and it halts.
>
> So something odd is going on there that needs an explanation.

I already fully addressed that in my reply to you yesterday. P(P) has a
dependency relationship on the return value of H(P,P) that the correctly
emulated input to H(P,P) does not have. This changes their behavior
relative to each other.

[Richard Damon]

So, Since the behavior of P(P) depends on H, when you change the behavor
of H, you have invaldated anything you have learned about P.

Thus changing H from doing a pure complete and correct emulation of its
input to one that Halt decides it an no longer does a complete emulation
of it, you now have a DIFFERENT P, even though you didn't touch the
source code of the C function P.

The CORRECTLY emulated input to H(P,P), being the representation of the
computation P(P) has exactly that same dependency.

Rememember, P has been defined to be the Linz "impossible program",
which is DEFINED to ask H about itself applied to its input, so if
H(P,P) doesn't refer to P(P), then your P isn't the required function.

FAIL.

[olcott]

On 6/24/2022 8:34 AM, Malcolm McLean wrote:

> I can see an alternative explanation. I was going to say "it is obvious" but
> no-one else has stepped in to point it out. Maybe because it's too obvious
> and they want to give other posters a chance.


The provably correct execution trace proves that the complete and

correct x86 emulation of the input to H(P,P) by H would never reach the

"ret" instruction (final state) of P, thus never halts. It is also
proven that H does determine this in a finite number of states.

The provably correct execution trace of P(P) proves that the it halts.

Because it is a fact that the actual input to H(P,P) has actual behavior
that never halts then H must report on this behavior and cannot report
on any other behavior.

If you need to verify that you have a white dog in your living room
checking for a black cat in you kitchen is the wrong criteria.

If you need to verify that an input to a halt decider reaches its final
state it must be the actual behavior of this actual input. P(P) is
provably not the actual behavior of the actual input on the basis of the
ordinary semantics of the x86 language as shown in the two provably
correct execution traces.

To fully understand this code a software engineer must be an expert in:
the C programming language, the x86 programming language, exactly how C
translates into x86 and the ability to recognize infinite recursion at
the x86 assembly language level. No knowledge of the halting problem is
required.

The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction of P.

In computer science terminology this means that complete and correct
emulation P by H would never reach its final state and halt.

The dependency relationship that P(P) has on H(P,P) causes its behavior
to be quite different than the complete and correct x86 emulation of the
input to H(P,P) that has no such dependency relationship.

As shown below because P(P) depends on the return value of H(P,P) it has
different behavior than the correctly emulated input to H(P,P).

The correctly emulated input to H(P,P) remains stuck in recursive
emulation that never gets to the point of receiving a return value from
H, thus lacks the dependency of the executed P(P).

void P(u32 x)

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

int main()
{

P(P);
}

_P()
[000011f0](01) 55 push ebp
[000011f1](02) 8bec mov ebp,esp

[000011f3](03) 8b4508 mov eax,[ebp+08]

[000011f6](01) 50 push eax

[000011f7](03) 8b4d08 mov ecx,[ebp+08]

[000011fa](01) 51 push ecx
[000011fb](05) e820feffff call 00001020
[00001200](03) 83c408 add esp,+08
[00001203](02) 85c0 test eax,eax
[00001205](02) 7402 jz 00001209
[00001207](02) ebfe jmp 00001207
[00001209](01) 5d pop ebp

[0000120a](01) c3 ret

Size in bytes:(0027) [0000120a]

_main()
[00001210](01) 55 push ebp
[00001211](02) 8bec mov ebp,esp
[00001213](05) 68f0110000 push 000011f0
[00001218](05) e8d3ffffff call 000011f0
[0000121d](03) 83c404 add esp,+04
[00001220](02) 33c0 xor eax,eax
[00001222](01) 5d pop ebp

[00001223](01) c3 ret
Size in bytes:(0020) [00001223]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============

[00001210][00101fba][00000000] 55 push ebp
[00001211][00101fba][00000000] 8bec mov ebp,esp
[00001213][00101fb6][000011f0] 68f0110000 push 000011f0 // push P
[00001218][00101fb2][0000121d] e8d3ffffff call 000011f0 // call P
[000011f0][00101fae][00101fba] 55 push ebp // enter executed P
[000011f1][00101fae][00101fba] 8bec mov ebp,esp
[000011f3][00101fae][00101fba] 8b4508 mov eax,[ebp+08]

[000011f6][00101faa][000011f0] 50 push eax // push P

[000011f7][00101faa][000011f0] 8b4d08 mov ecx,[ebp+08]

[000011fa][00101fa6][000011f0] 51 push ecx // push P

[000011fb][00101fa2][00001200] e820feffff call 00001020 // call H

Begin Simulation Execution Trace Stored at:21206e

Address_of_H:1020
[000011f0][0021205a][0021205e] 55 push ebp // enter emulated P
[000011f1][0021205a][0021205e] 8bec mov ebp,esp
[000011f3][0021205a][0021205e] 8b4508 mov eax,[ebp+08]

[000011f6][00212056][000011f0] 50 push eax // push P

[000011f7][00212056][000011f0] 8b4d08 mov ecx,[ebp+08]

[000011fa][00212052][000011f0] 51 push ecx // push P
[000011fb][0021204e][00001200] e820feffff call 00001020 // call emulated H

Infinitely Recursive Simulation Detected Simulation Stopped

H knows its own machine address and on this basis it can easily

examine its stored execution_trace of P (see above) to determine:

(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise infinitely
recursive emulation.

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

[00001200][00101fae][00101fba] 83c408 add esp,+08 // return to
executed P
[00001203][00101fae][00101fba] 85c0 test eax,eax
[00001205][00101fae][00101fba] 7402 jz 00001209
[00001209][00101fb2][0000121d] 5d pop ebp
[0000120a][00101fb6][000011f0] c3 ret // return from
executed P
[0000121d][00101fba][00000000] 83c404 add esp,+04
[00001220][00101fba][00000000] 33c0 xor eax,eax
[00001222][00101fbe][00100000] 5d pop ebp
[00001223][00101fc2][00000000] c3 ret // ret from main
Number of Instructions Executed(878) / 67 = 13 pages

[olcott]

On 6/24/2022 8:34 AM, Malcolm McLean wrote:
> On Friday, 24 June 2022 at 14:07:19 UTC+1, olcott wrote:

> I can see an alternative explanation. I was going to say "it is obvious" but
> no-one else has stepped in to point it out. Maybe because it's too obvious
> and they want to give other posters a chance.

To what exact extent do you have this mandatory prerequisite knowledge?

To fully understand this code a software engineer must be an expert in:
the C programming language, the x86 programming language, exactly how C
translates into x86 and the ability to recognize infinite recursion at
the x86 assembly language level.

The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction of P.

The halt decider and its input are written in C compiled with a
Microsoft C compiler that generates a standard COFF object file. This
file is the input to the x86utm operating system that runs on both
Microsoft Windows and Linux.

[Richard Damon]

No, it doesn't because you don't seem to understand what correct x86
emulation MEANS.

Correct x86 emulation of a call instruction means the emulation now
continues at the x86 instruction at the target of the call, and thus the
correct x86 emualtion of the call H needs to be followed by the
emulation of the actual x86 assembly code of H. PERIOD.

What you are doing ISN'T x86 emulation at all, so all you are doing is
showing you are a liar.

Now, maybe part of the problem is that H isn't a halt decider and the
input 'P' isn't actually a description of the computation of P to be
decided on, so the 'behavior' of that input isn't the same as P(P) but
then you are just shown to be lying that you are working on the halting
problem and have defined H and P per the theorem you are claiming to be
working on.

Note, to actually define the input as a representation of the
computation P. it needs to include the x86 assembly of H as part of it,
so the fact that you say it doesn't just says your emulator is not
actually doing a correct emulation of its input at all.

>
> The provably correct execution trace of P(P) proves that the it halts.
>
> Because it is a fact that the actual input to H(P,P) has actual behavior
> that never halts then H must report on this behavior and cannot report
> on any other behavior.
>

Only if you define H to not do an accurate emulation of its input, or it
fails to return an answer.

> If you need to verify that you have a white dog in your living room
> checking for a black cat in you kitchen is the wrong criteria.

And that is the problem that YOU do. H needs to be EITHER a complete and
correct emulator, or a machine tha can abort its emulation to return an
answer when given a non-halting input.

YOU are the one looking at the black cat for what's happening when the
question is about the white dog.

Yea, the black cat, the H that does a complete emulation, creates a P
that is none-halting, but when the white dog looks at the P built on IT,
you are giving it the P built on the white cat instead, and thus get the
wrong answer.

>
> If you need to verify that an input to a halt decider reaches its final
> state it must be the actual behavior of this actual input. P(P) is
> provably not the actual behavior of the actual input on the basis of the
> ordinary semantics of the x86 language as shown in the two provably
> correct execution traces.
>

Right, and since that behavior is defined by a complete and correct
behavior, and a halt decider that aborts is simulation of its input
doesn't do that, you can't ask about the impossible case of what it does
with its input, because it isn't what is defined as the actual behavior.

If you try to define it that way, then you have LIED that P is corret,
because P MUST ask H about P(P), so if H(P,P) doesn't do that, P is
defined wrong.

If P can't ask H about P(P), then H is proved to be incomplete and
unable to give the correct answer to a question that it won't let you
answer.

>
>
> To fully understand this code a software engineer must be an expert in:
> the C programming language, the x86 programming language, exactly how C
> translates into x86 and the ability to recognize infinite recursion at
> the x86 assembly language level. No knowledge of the halting problem is
> required.

Nope, That is your problem, knowledge of the Halting Problem IS
required, because you need to make sure your terms are defined correctly.

You have proved that YOU don't have that knowledge, and you "proof" is
shown to be incorret.

>
> The ordinary semantics of standard C and the conventional x86 language
> are the entire semantics required to conclusively prove that H(P,P) does
> correctly determine that its correct and complete x86 emulation of its
> input would never reach the "ret" instruction of P.
>

Nope, not per the

> In computer science terminology this means that complete and correct
> emulation P by H would never reach its final state and halt.

You are missing, H never DOES a complete and correct emulation of its
input when it answers non-halting, and thus has no basis to say it is
correct. You have reached a paradox.

>
> The dependency relationship that P(P) has on H(P,P) causes its behavior
> to be quite different than the complete and correct x86 emulation of the
> input to H(P,P) that has no such dependency relationship.

Nope. the input to H(P,P) DOES have a dependency on the behavior of
H(P,P) since is uses that as part of its code.

All you are doing is admitting that you are not correctly emulating the
call H instruction, and thus fail.

>
> As shown below because P(P) depends on the return value of H(P,P) it has
> different behavior than the correctly emulated input to H(P,P).
>
> The correctly emulated input to H(P,P) remains stuck in recursive
> emulation that never gets to the point of receiving a return value from
> H, thus lacks the dependency of the executed P(P).

because you aren't CORRECTLY emulating the input as an x86 representation.

FAIL.

[olcott]

On 6/24/2022 11:09 AM, Malcolm McLean wrote:

> I'm a C programmer and I have done machine code programming, though not
> with the x86 chip. But I'd dispute your requirements.


THIS IS THE STIPULATED SOFTWARE ENGINEERING REQUIREMENTS THUS
DISAGREEMENT IS INHERENTLY INCORRECT.

From a purely software engineering perspective H is correctly defined
to correctly determine that its correct and complete x86 emulation of
its input would never reach the "ret" instruction of this input and it
is proven that H does do this correctly in a finite number of steps.

> To re-tread the analogy,
> our measurements show that tigers use more energy than they take in.
> Now you could construct an very complicated explanation for that using
> advanced quantum mechanics and other concepts. And you do need to have
> a rudimentary understanding of physics to see where the difficulty lies.

> But you don't need more than the rudimentary understanding to suggest the
> alternative explanation, and to realise that it is overwhelmingly more likely.

It seems that you may be saying that it is OK to disbelieve verified
facts some of the time. I vehemently disagree and this position could
cause both the end of Democracy in the USA and the extinction of
humanity in the world through lack of climate change action.

Ordinary software engineering conclusively proves that all of my claims
that I just stated are easily verified as factually correct.

Anyone that disagrees with claims that are verified as factually correct
is either insufficiently technically competent or less than totally
honest. Someone that refuses to acknowledge that claims are correct when
they know that these claims are correct is less than totally honest.

I believe that you are as honest as you can be and the issue is that you
have a lack of sufficient understanding.

[Richard Damon]

YOU CAN'T "STIPULATE" correctness.

ARGUEMENT FATALLY FLAWED.

[olcott]

From a purely software engineering perspective H(P,P) is required to

to correctly determine that its correct and complete x86 emulation of

its input would never reach the "ret" instruction of this input and H
must do this in a finite number of steps.

It is proven that H does meet this requirement.

[olcott]

On 6/24/2022 12:29 PM, Malcolm McLean wrote:

> Let's say we do our measurements on tigers. They come back
> average calorie intake (prey) 2000 calories.
> average outgoings
> stored fat 100 calories
> metabolism (body temperature) 1500 calories
> movement 500 calories
> lactation 200 calories.
>
> these are averaged over a long period.
>
> Now what is your conclusion?

The measurements are inaccurate as can occur with all empirical science
that relies on physical observation. It is also the case the all
empirical science utterly relies on a possibly false fundamental
assumption that is discussed at length as the problem of induction.
https://en.wikipedia.org/wiki/Problem_of_induction

On the other hand when we look at the analytic side of the analytic /
synthetic distinction:
https://en.wikipedia.org/wiki/Analytic%E2%80%93synthetic_distinction

We can verify that an expression of language is totally true entirely on
the basis of its meaning. This proves that your analogy is not apt.

From a purely software engineering perspective H(P,P) is required to to

correctly determine that its correct and complete x86 emulation of its

input would never reach the "ret" instruction of this input and H must
do this in a finite number of steps.

The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does
correctly determine that its correct and complete x86 emulation of its

input would never reach the "ret" instruction (final state) of this
input thus never halts.

>>
>> I believe that you are as honest as you can be and the issue is that you
>> have a lack of sufficient understanding.
>>

> See if you can work out the tiger example first.

[olcott]

On 6/22/2022 9:23 PM, Dennis Bush wrote:
> On Wednesday, June 22, 2022 at 10:15:11 PM UTC-4, olcott wrote:
>> On 6/22/2022 8:44 PM, Dennis Bush wrote:
>>> On Wednesday, June 22, 2022 at 9:38:03 PM UTC-4, olcott wrote:
>>>> On 6/22/2022 8:21 PM, Dennis Bush wrote:
>>>>> On Wednesday, June 22, 2022 at 9:17:02 PM UTC-4, olcott wrote:
>>>>>> On 6/22/2022 8:02 PM, Dennis Bush wrote:
>>>>>>> On Wednesday, June 22, 2022 at 7:11:35 PM UTC-4, olcott wrote:
>>>>>>>> On 6/22/2022 5:48 PM, Dennis Bush wrote:
>>>>>>>>> On Wednesday, June 22, 2022 at 6:22:56 PM UTC-4, olcott wrote:
>>>>>>>>>> On 6/22/2022 4:53 PM, Dennis Bush wrote:
>>>>>>>>>>> On Wednesday, June 22, 2022 at 5:41:51 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 6/22/2022 4:20 PM, Mr Flibble wrote:

>>>>>>>>>>>>> On Wed, 22 Jun 2022 15:27:01 -0500
>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 6/22/2022 2:31 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On Tue, 21 Jun 2022 21:38:56 -0500
>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>>>>>> #define u32 uint32_t
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> #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()
>>>>>>>>>>>>>>>> [000010d2](01) 55 push ebp
>>>>>>>>>>>>>>>> [000010d3](02) 8bec mov ebp,esp

>>>>>>>>>>>>>>>> [000010d5](03) 8b4508 mov eax,[ebp+08]

>>>>>>>>>>>>>>>> [000010d8](01) 50 push eax

>>>>>>>>>>>>>>>> [000010d9](03) 8b4d08 mov ecx,[ebp+08]

>>>>>>>>>>>>>>>> [000010dc](01) 51 push ecx
>>>>>>>>>>>>>>>> [000010dd](05) e820feffff call 00000f02
>>>>>>>>>>>>>>>> [000010e2](03) 83c408 add esp,+08
>>>>>>>>>>>>>>>> [000010e5](02) 85c0 test eax,eax
>>>>>>>>>>>>>>>> [000010e7](02) 7402 jz 000010eb
>>>>>>>>>>>>>>>> [000010e9](02) ebfe jmp 000010e9
>>>>>>>>>>>>>>>> [000010eb](01) 5d pop ebp

>>>>>>>>>>>>>>>> [000010ec](01) c3 ret

>>>>>>>>>>>>>>>> Size in bytes:(0027) [000010ec]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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 because both H
>>>>>>>>>>>>>>>> and P would remain stuck in infinitely recursive emulation.
>>>>>>>>>>>>>>>>

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

>>>>>>>>>>>>>>>> are the details of exactly how H does this in a finite number of
>>>>>>>>>>>>>>>> steps.
>>>>>>>>>>>>>>>>

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

>>>>>>>>>>>>>>>> machine stack stack machine assembly
>>>>>>>>>>>>>>>> address address data code language
>>>>>>>>>>>>>>>> ======== ======== ======== ========= =============

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

>>>>>>>>>>>>>>>> // actual fully operational code in the x86utm operating system
>>>>>>>>>>>>>>>> u32 H(u32 P, u32 I)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> HERE:
>>>>>>>>>>>>>>>> u32 End_Of_Code;
>>>>>>>>>>>>>>>> u32 Address_of_H; // 2022-06-17
>>>>>>>>>>>>>>>> u32 code_end = get_code_end(P);
>>>>>>>>>>>>>>>> Decoded_Line_Of_Code *decoded = (Decoded_Line_Of_Code*)
>>>>>>>>>>>>>>>> Allocate(sizeof(Decoded_Line_Of_Code));
>>>>>>>>>>>>>>>> Registers* master_state = (Registers*)
>>>>>>>>>>>>>>>> Allocate(sizeof(Registers));
>>>>>>>>>>>>>>>> Registers* slave_state = (Registers*)
>>>>>>>>>>>>>>>> Allocate(sizeof(Registers));
>>>>>>>>>>>>>>>> u32* slave_stack = Allocate(0x10000); // 64k;
>>>>>>>>>>>>>>>> u32 execution_trace =
>>>>>>>>>>>>>>>> (u32)Allocate(sizeof(Decoded_Line_Of_Code)
>>>>>>>>>>>>>>>> * 1000);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> __asm lea eax, HERE // 2022-06-18
>>>>>>>>>>>>>>>> __asm sub eax, 6 // 2022-06-18
>>>>>>>>>>>>>>>> __asm mov Address_of_H, eax // 2022-06-18
>>>>>>>>>>>>>>>> __asm mov eax, END_OF_CODE
>>>>>>>>>>>>>>>> __asm mov End_Of_Code, eax
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Output("Address_of_H:", Address_of_H); // 2022-06-11
>>>>>>>>>>>>>>>> Init_slave_state(P, I, End_Of_Code, slave_state, slave_stack);

>>>>>>>>>>>>>>>> Output("\nBegin Simulation Execution Trace Stored at:",

>>>>>>>>>>>>>>>> execution_trace);
>>>>>>>>>>>>>>>> if (Decide_Halting(&execution_trace, &decoded, code_end,
>>>>>>>>>>>>>>>> &master_state, &slave_state, &slave_stack, Address_of_H, P, I))
>>>>>>>>>>>>>>>> goto END_OF_CODE;
>>>>>>>>>>>>>>>> return 0; // Does not halt
>>>>>>>>>>>>>>>> END_OF_CODE:
>>>>>>>>>>>>>>>> return 1; // Input has normally terminated
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>> H knows its own machine address and on this basis it can easily

>>>>>>>>>>>>>>>> examine its stored execution_trace of P and determine:

>>>>>>>>>>>>>>>> (a) P is calling H with the same arguments that H was called with.
>>>>>>>>>>>>>>>> (b) No instructions in P could possibly escape this otherwise
>>>>>>>>>>>>>>>> infinitely recursive emulation.

>>>>>>>>>>>>>>>> (c) H aborts its emulation of P before its call to H is invoked.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Technically competent software engineers may not know this computer
>>>>>>>>>>>>>>>> science:
>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>>>>>>>>>>>> accept or reject state on the basis of the actual behavior that is
>>>>>>>>>>>>>>>> actually specified by these inputs.
>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>> computation that halts … the Turing machine will halt whenever it
>>>>>>>>>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>> The "ret" instruction of P is its final state.
>>>>>>>>>>>>>>>>

>>>>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>

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

>>>>>>>>>>>>>> You and Richard are insufficiently technically competent at software
>>>>>>>>>>>>>> engineering not meeting these specs:
>>>>>>>>>>>>>>

>>>>>>>>>>>>>> A software engineer must be an expert in: the C programming language,

>>>>>>>>>>>>>> the x86 programming language, exactly how C translates into x86 and
>>>>>>>>>>>>>> the ability to recognize infinite recursion at the x86 assembly

>>>>>>>>>>>>>> language level. No knowledge of the halting problem is required.
>>>>>>>>>>>>>

>>>>>>>>>>>>> I cannot speak for Richard but I have 30+ years C++ experience; I also
>>>>>>>>>>>>> have C and x86 assembly experience (I once wrote a Zilog Z80A CPU
>>>>>>>>>>>>> emulator in 80286 assembly) and I can recognize an infinite recursion;
>>>>>>>>>>>>> the problem is that you cannot recognize the fact that the infinite
>>>>>>>>>>>>> recursion only manifests as part of your invalid simulation-based
>>>>>>>>>>>>> omnishambles:
>>>>>>>>>>>> If you are competent then you already know this is true and lie about it:

>>>>>>>>>>>> Every sufficiently competent software engineer can easily verify that
>>>>>>>>>>>> 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.
>>>>>>>>>>>

>>>>>>>>>>> H (if it was constructed correctly) is a computation, and a computation *always* gives the same output for a given input. So it doesn't make sense to say what it "would" do. It either does or does not perform a complete and correct emulation. And because H contains code to abort, and does abort, it does not do a complete emulation.
>>>>>>>>>>>
>>>>>>>>>>> So the input must be given to a UTM, which by definition does a correct and complete simulation, to see what the actual behavior is. UTM(Px,Px) halts, therefore H(Px,Px)==0 is wrong.
>>>>>>>>>>
>>>>>>>>>> Every sufficiently competent software engineer can easily verify that
>>>>>>>>>> the complete and correct x86 emulation of the input to H(Px,Px) by H
>>>>>>>>>> would never reach the "ret" instruction of Px because both H and Px

>>>>>>>>>> would remain stuck in infinitely recursive emulation.
>>>>>>>>>

>>>>>>>>> So you just repeated what you said instead of explaining why I'm wrong. In other words you provided no rebuttal, which can only be taken to mean that you have none.
>>>>>>>> Your entire basis and all of assumptions was incorrect so when I
>>>>>>>> provided an infallible one to that cannot possibly be correctly refuted
>>>>>>>> you simply dodged it. That is a smart move for a dishonest person that
>>>>>>>> is only interested in rebuttal.
>>>>>>>>
>>>>>>>> I dare you to go back to the prior post and find any error in my
>>>>>>>> airtight correct reasoning. Another dodge will be construed as a tacit
>>>>>>>> admission of defeat.
>>>>>>>
>>>>>>> As stated before H (or more accurately Ha) does not perform a complete and correct emulation because it aborts. So by definition it cannot be complete.
>>>>>> I never claimed that H(P,P) performs a complete and correct emulation of
>>>>>> its input so your rebuttal is the strawman deception.
>>>>>>

>>>>>> I claimed that H(P,P) correctly predicts that its complete and correct

>>>>>> x86 emulation of its input would never reach the "ret" instruction of P.
>>>>>

>>>>> But since H, or more accurately Ha, *can't* do a correct and complete emulation of its input, your point is moot.
>>>> _Infinite_Loop()
>>>> [00001082](01) 55 push ebp
>>>> [00001083](02) 8bec mov ebp,esp
>>>> [00001085](02) ebfe jmp 00001085
>>>> [00001087](01) 5d pop ebp
>>>> [00001088](01) c3 ret
>>>> Size in bytes:(0007) [00001088]
>>>>
>>>> Begin Local Halt Decider Simulation Execution Trace Stored at:211e8f
>>>> ...[00001082][00211e7f][00211e83] 55 push ebp
>>>> ...[00001083][00211e7f][00211e83] 8bec mov ebp,esp
>>>> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085
>>>> ...[00001085][00211e7f][00211e83] ebfe jmp 00001085
>>>> Infinite Loop Detected Simulation Stopped
>>>>
>>>> On the basis of this exact same utterly moronic reasoning because H
>>>> *can't* do a correct and complete emulation of its input, H cannot
>>>> possibly determine that _Infinite_Loop() never halts.
>>>
>>> Now who's using the strawman error? Just because H can determine that _Infinite_Loop does not halt doesn't mean that it gets other cases right. B

>> You just said that H(P,P) cannot correctly predict that the correct and

>> complete x86 emulation of its input would never reach the "ret"

>> instruction of P without a compete x86 emulation of its input. I just
>> proved that is a very stupid thing to say.
>
> You said that H can predict what *its* correct and complete emulation would do, and I said that doesn't make sense because H does not do correct and complete emulation. What H *must* do is predict what *the* correct and complete emulation, i.e. UTM(P,P), would do. And it fails to do that.

From a purely software engineering perspective H(P,P) is required to to
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction of this input and H must
do this in a finite number of steps.

The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does
correctly determine that its correct and complete x86 emulation of its

input would never reach the "ret" instruction.

That you disagree with easily verified software engineering when you
already know that this software engineering is correct speaks loads
about your character.

The only computer science that need be added to this is that the "ret"
instruction is the final state of P and that a sequence of
configurations that cannot possibly reach its final state is a
non-halting sequence.

[Richard Damon]

STIPULTING that something is correct is inherently incorrect.

>
> From a purely software engineering perspective H(P,P) is required to
> to correctly determine that its correct and complete x86 emulation of
> its input would never reach the "ret" instruction of this input and H
> must do this in a finite number of steps.
>
> It is proven that H does meet this requirement.

No, because you said *ITS* correct and complete x86 emulation was
showing something when it didn't do one. Thus, H has FAILED to meet its
requirements.

Until you can show how H can do a COMPLETE emulation of a non-halting
input in finite time (not just 'prove' that it doesn't halt, that wasn't
the requrement, it was DO the emulation) your H just fails to meet you
software specifications for it.

Note, a Halt Decider isn't normally required to do a complete emulation
of its input, but that is because it isn't also the test of its answer
being correct, that is done by the INDEPENDENT running or complete
emulation of the input, which allow the decider to correct answer at
least some non-halting inputs. (Because it can find patterns that are
proven to be non-halting for the test machine).

Your removal of the allowance of a separate test operation, that CAN be
infinite in operation while the decider stays finite in operation dooms
your decider to either not meet its requriment to show non-halting, or
not meet its requirement to answer in finite time.

Note, your H fails to meet YOUR requirements when deciding on
Infinite_Loop, even though it can give the correct answer by the normal
requirements, because it never showed by its own complete and correct
emulation that the input doesn't halt (only by referencing another
emulation that does, which isn't YOUR stated requirement).

[Richard Damon]

And your fundamental problem is that Halting is defined based on
MACHINES, i.e the actual computation itself.

"Inputs" are just strings of symbols and don't have any behavior by them
selves.

If H(P.P) doesn't represent the computation P(P), then you haven't
designed you P by the rules, so your arguement is invalid.

If P CAN'T ask H about P(P), then your H just admitted defeat.

Since H(P,P) doesn't match the bahavior of P(P), either H is just wrong,
or your problem doesn't match the required setup and you are proved to
be either a liar or incompetent.

Take your choice on how you want to be wrong.

[olcott]

On 6/24/2022 2:34 PM, Malcolm McLean wrote:

> Exactly. You've got it. Either the measurements are inaccurate, or the
> theory that energy is conserved is wrong.

>> On the other hand when we look at the analytic side of the analytic /
>> synthetic distinction:
>> https://en.wikipedia.org/wiki/Analytic%E2%80%93synthetic_distinction
>>
>> We can verify that an expression of language is totally true entirely on
>> the basis of its meaning. This proves that your analogy is not apt.
>>

> I'm not sure about this.

>>
>> From a purely software engineering perspective H(P,P) is required to to
>> correctly determine that its correct and complete x86 emulation of its
>> input would never reach the "ret" instruction of this input and H must
>> do this in a finite number of steps.
>> The ordinary semantics of standard C and the conventional x86 language
>> are the entire semantics required to conclusively prove that H(P,P) does
>> correctly determine that its correct and complete x86 emulation of its
>> input would never reach the "ret" instruction (final state) of this
>> input thus never halts.
>>

> So you've dry-run P(P) and determined that it doesn't halt. Just as our
> hypothetical ecologists measured the tigers' energy budget.
> What is the obvious conclusion?

From a purely software engineering perspective H(P,P) is required to to
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction of this input and H must
do this in a finite number of steps.

The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction (final state) of this
input thus never halts.

THERE IS NO POSSIBLE WAY AROUND THIS.

[olcott]

On 6/24/2022 3:05 PM, Paul N wrote:

> You say that "H(P,P) is required to to correctly determine that its correct and complete x86 emulation of its input would never reach the "ret" instruction of this input". You seem to be assuming that H does an emulation of P, that this emulation includes emulating the call to H, that this call to H would start emulating the call to P, etc, etc, and so the call to P does not terminate.
>

Thanks for continuing to review this.

No assumptions two years of software development derived fully
operational software that conclusively proves this.

> However, you have said yourself that H does not work like that. You have said "H must do this in a finite number of steps" and have said that H (whose source code you have never actually shown) detects the looping and halts, returning a value.

>

From a purely software engineering perspective H(P,P) is required to to
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction of this input and H must
do this in a finite number of steps.

The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does
correctly determine that its correct and complete x86 emulation of its

input would never reach the "ret" instruction (final state) of this
input thus never halts.

> Thus H does not keep calling P over and over again, or getting deeper and deeper into emulation. It halts. Thus P also halts.

The computer science term "halts" only includes terminated normally by
reaching its final instruction.

computation that halts … the Turing machine will halt whenever it enters
a final state. (Linz:1990:234)

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)

[olcott]

On 6/24/2022 3:25 PM, Malcolm McLean wrote:

> On Friday, 24 June 2022 at 20:42:56 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>
>>>>> On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>
>>>>>>> On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
>>>>>>>> On 6/22/2022 2:55 AM, Malcolm McLean wrote:
>>>>>>>>> On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
>>>>>>>>>> On 6/21/2022 9:52 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
>>>>>>>>>>> was incorrect in its mapping, since the behavior of P(P) is the
>>>>>>>>>>> DEFINITION of the behavior of H(P,P),

>>>>>>>>>> Linz and others were aware that: A halt decider must compute the mapping

>>>>>>>>>> from its inputs to an accept or reject state on the basis of the actual
>>>>>>>>>> behavior that is actually specified by these inputs.

>> Then I don't know what you mean by "dry-run" and what needs an
>> explanation (for me) is your description of what he's doing. Nothing in
>> what PO is doing needs to be explained as far as I can see.
>>
> "Dry run" means that a human programmer looks at the code, and determines
> what it does, without actually executing it.
> It's a very important technique, because it's not always practical or even
> possible to run a debugger. Even where a debugger is available, often
> dry-running will reveal bugs in a fraction of the time.
> In this case, PO has dry run P(P). That is, he has looked at the source, and
> worked out what it will do. Which is to run an infinite sequence of nested
> emulations. So it won't halt. H(P,P) also reports "non-halting". So this is
> powerful evidence that H is correct.

Great!

> However when he actually executes P(P) on hardware, it terminates.
> Something isn't right.

None-the-less when everyone in the entire universe disagrees with a
verified fact then they are all necessarily incorrect.

The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction (final state) of this
input thus never halts.

> PO's explanation is that P(P) has different correct behaviour when run and
> when emulated by H.

It is very easily proven as an established fact that the correctly
emulated input to H(P,P) would never halt and P(P) halts.

> I can think of an obvious alternative explanation which is much simpler and
> much less far-reaching in its implications. However despite a lot of coaxing,
> no-one else seems to have arrived at it.

I think that most of my reviewers are only interested in rebuttal at the
expense of an actual honest dialogue. You are certainly the exception to
this.

[Richard Damon]

Except, of course, that the "Dry-run" didn't evalute H as what H
actually ends up being, but by what H was specifed to be, that is a
comptation that completely em

>> However when he actually executes P(P) on hardware, it terminates.
>> Something isn't right.
>
> None-the-less when everyone in the entire universe disagrees with a
> verified fact then they are all necessarily incorrect.
>
> The ordinary semantics of standard C and the conventional x86 language
> are the entire semantics required to conclusively prove that H(P,P) does
> correctly determine that its correct and complete x86 emulation of its
> input would never reach the "ret" instruction (final state) of this
> input thus never halts.
>
>> PO's explanation is that P(P) has different correct behaviour when run
>> and
>> when emulated by H.
>
> It is very easily proven as an established fact that the correctly
> emulated input to H(P,P) would never halt and P(P) halts.

Only if you accept that P isn't requred to be the H^ of Linz.

Remember, THAT machine, by definition, makes a call that asks H to
evalute what it will do when applie to its input.

If H(P,P) doesn't mean that, then P isn't the impossible program example
of Linz but something else, so we haven't countered his example.

[olcott]

> OK. So what value does it have in this case? Do you think PO is
> competent to "dry run" any code at all?
>
> Going back, now, to what you think needs to be resolved:

>
> | He's dry-run P(P) and established that it doesn't halt. He's invoked H
> | on it and H reports that it doesn't halt. He's run P(P) and it halts.
>

> The obvious conclusion is that PO's dry run (if he has indeed done such
> a thing) is incorrect. Anyone who eyeballs some case and concludes that
> it does not do what it down when actually run has just made a mistake.
> Do you think it's interesting to find out what mistake PO has made when
> guessing what the code does? If so have fun trying to get the code from
> him...
>
> The more interesting (at least at one time) is fact that H is not
> correct since, by definition, H(X,Y) should report on the "halting" of
> the call X(Y).

>
>> It's a very important technique, because it's not always practical or even
>> possible to run a debugger. Even where a debugger is available, often
>> dry-running will reveal bugs in a fraction of the time.
>

> In this case, we have the undisputed fact that P(P) halts, so there's
> really no value in a "dry run" from a debugging perspective.

>
>> In this case, PO has dry run P(P).
>

> And, if that is indeed what he's done (and I don't think it is) he knows
> he's made some mistake in his "dry run".

>
>> That is, he has looked at the source, and
>> worked out what it will do.
>

> But, I hope you agree, he's made some mistake or he's been lying when re
> reports that P(P) halts.

>
>> Which is to run an infinite sequence of nested
>> emulations. So it won't halt.
>

> The execution of P(P) does not represent an infinite sequence of nested
> simulations. We know that because P(P) halts.

>
>> H(P,P) also reports "non-halting". So this is
>> powerful evidence that H is correct.
>

> Eh? How is some code eyeballing more compelling evidence than the 100%
> undisputed fact that P(P) halts? How is the opinion of someone who
> can't write a parity checking TM powerful evidence of anything?

>
>> However when he actually executes P(P) on hardware, it terminates.
>> Something isn't right.
>

> Yes.

>
>> PO's explanation is that P(P) has different correct behaviour when run and
>> when emulated by H.
>

> That can't be an explanation of anything because, according to you, he
> is wrong about the dry run of P(P) and an actual run of P(P). Both the
> dry run and the actual run must take account of the fact that H is
> (partially) emulating P(P).

>
>> I can think of an obvious alternative explanation which is much
>> simpler and much less far-reaching in its implications. However
>> despite a lot of coaxing, no-one else seems to have arrived at it.
>

> There is nothing here with any far-reaching implications and since I've
> never shared your explanation, I'm not going to look for an alternative.
>
> I don't think he's done a "dry run" at all. He knows P(P) halts so he's
> relying on sophistry. H "aborts" so P never reaches its "ret"
> instruction. That's why P(P) and "the simulation of the inputs to
> H(P,P)" are different. 18 years of work for what? An H that, on the
> basis of his own words, obviously gets the wrong answer.

>

The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does
correctly determine that its correct and complete x86 emulation of its
input would never reach the "ret" instruction (final state) of this
input thus never halts.

That your understanding of the semantics of the x86 language is
insufficient to directly confirm this is less than no rebuttal at all.

[olcott]

On 6/24/2022 5:23 PM, Ben Bacarisse wrote:
> Paul N <gw7...@aol.com> writes:
>
>> You say that "H(P,P) is required to to correctly determine that its

>> correct and complete x86 emulation of its input would never reach the

>> "ret" instruction of this input".
>
> Can I just check that you know this is not what H is supposed to do? PO
> has been searching for some from of words that can stir up enough mud
> that the fact that H is wrong can be to some extent obscured. He seems
> to have hit pay dirt with this latest phrasing.
>
> Everyone seem happy to talk to PO on his own terms (and that's fine --
> it's what he posts for), but in the C-function version of the problem,
> H(X,Y) != 0 if and only if X(Y) "halts". I lost interest when he
> stopped talking about this problem which he knows in not decidable.
>

It is common knowledge (in computer science) that a halt decider must
compute the mapping from actual its inputs to an accept or reject state
on the basis of the actual behavior that is actually specified by its
actual inputs.

The ordinary semantics of standard C and the conventional x86 language
are the entire semantics required to conclusively prove that H(P,P) does
correctly determine that its correct and complete x86 emulation of its

input would never reach the "ret" instruction (final state) of this
input thus never halts.

THERE IS NO ESCAPE FROM THIS BECAUSE IT IS A TAUTOLOGY.

[olcott]

On 6/24/2022 6:58 PM, dklei...@gmail.com wrote:

> I assume the semantics of C are defined by the 1989 Standard. The
> semantics of x86 assembly language are described (not actually
> authoritatively defined) in other documents. The mapping of C onto
> the assembly language is far from unique (every compiler could be
> different) PO appears to using a version of Microsoft's C# compiler.
>

The COFF object file generated by most any Microsoft C compiler.
I used Visual Studio 2017 Community Edition.

x86 Instruction Set Reference: https://c9x.me/x86/

> Then we must define how a Turing machine is emulated by a C
> program. All that is needed of C is the struct concept and
> assignment. In that case using C seems unadvisable.
>

No we don't need this at all. We only need to know that a C function
that is a pure function of its inputs is Turing equivalent.

https://en.wikipedia.org/wiki/Pure_function

By not using C my five page halt decider becomes hundreds of thousands
of indecipherable pages of TM description.

[Richard Damon]

It needs bit more, because function, as defined by C, that are not
"leaf" functions are not, in themselves, complete definitions of a
computation, and need to include the code (at least at the abstract
machine level) of any function they call.

THus, P needs to include an ACCURATE model of H to be able to be
converted into a Turing Machine, which means you need to fix which
version of H it is calling.

Does C call the H that IS a complete and correct emulator, and tus gets
P(P) into non-halting behavior, but also doesn't answer, so fails to be
a Halting Decider, or does C call the H that DOES abort its emulaton and
return 0, making P(P) a Halting Computation and H return the wrong answer.

Your arguement has H being both of these at the same time, which is
impossible.

[Richard Damon]

Wrong. If H(P,P) does the correct and complete x86 emulation of its
input, i9t never gives an answer for H(P,P).

Maybe in your mind it makes the dertemination but not return it, but
that isn't the defintion of a decider determinng.

If H(P,P) does make a determination about its simulation of H(P,P) being
non-halting, it does so based on unsound logic, as your logic has it
presume that H DOES a complete and correct emulation, but if it makes
such a determination and returns the non-halting answer, it never did a
complete and correct emulation, so the premise it based its logic on is
refuted.

[olcott]

On 6/24/2022 11:01 PM, Malcolm McLean wrote:

> On Friday, 24 June 2022 at 23:16:30 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> "Dry run" means that a human programmer looks at the code, and determines
>>> what it does, without actually executing it.
>>

>> Going back, now, to what you think needs to be resolved:
>> | He's dry-run P(P) and established that it doesn't halt. He's invoked H
>> | on it and H reports that it doesn't halt. He's run P(P) and it halts.
>> The obvious conclusion is that PO's dry run (if he has indeed done such
>> a thing) is incorrect.
>>

> Exactly.
> We do our little energy budget on tigers, and find that tigers spend more energy
> than they take in. Well potentially this is dynamite. One explanation is that the
> law of conservation of energy is wrong.
> Except, before we countenance that explanation, we need to rule out a much
> simpler explanation. Which is that our measurements are wrong.
>
> Similarly, PO has worked out what he thinks P(P) should be doing, by dry-running
> it, and then actually run P(P) and obtained a different result. He also found that H
> agreed with the dry run. It's hard to paraphrase his conclusion, but it is extensive
> and far-reaching in its implications. The behaviour of code when run is different
> from the correct behaviour of the code when simulated. If that's true, then it has
> similar implications for computer science that disproving the conservation law
> has for physics.
>
> But the obvious explanation is that the dry-run was incorrect. Lots of people have
> suggested why it is incorrect. But they can't actually see the code. PO needs to
> understand that no-one will accept the complicated, far-reaching explanation,
> until the simple explanation has been ruled out.

I already proved that the dry run is correct.

[olcott]

On 6/24/2022 11:50 PM, dklei...@gmail.com wrote:

> You are jumping too far in one step. What I am asking is equivalent to:
> Given a Turing Machine how do its steps map into C and thence into x86?
> No C functions are involved.
>

I have written this up several ways that boil down to C maps to a RASP
machine that maps to a TM.
https://en.wikipedia.org/wiki/Random-access_stored-program_machine

The bottom line is that when a C function is a pure function of its
inputs then it is TM equivalent computation.

>> By not using C my five page halt decider becomes hundreds of thousands
>> of indecipherable pages of TM description.
>

> That would depend on the answer to my question.