Proving that P(P) != the correct x86 emulation of the input to H(P,P)

[olcott]

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

int main()
{
P(P);
}

_P()
[000012e7](01) 55 push ebp
[000012e8](02) 8bec mov ebp,esp
[000012ea](03) 8b4508 mov eax,[ebp+08]
[000012ed](01) 50 push eax
[000012ee](03) 8b4d08 mov ecx,[ebp+08]
[000012f1](01) 51 push ecx
[000012f2](05) e880feffff call 00001177 // call H
[000012f7](03) 83c408 add esp,+08
[000012fa](02) 85c0 test eax,eax
[000012fc](02) 7402 jz 00001300
[000012fe](02) ebfe jmp 000012fe
[00001300](01) 5d pop ebp
[00001301](01) c3 ret
Size in bytes:(0027) [00001301]

_main()
[00001307](01) 55 push ebp
[00001308](02) 8bec mov ebp,esp
[0000130a](05) 68e7120000 push 000012e7 // push P
[0000130f](05) e8d3ffffff call 000012e7 // call P
[00001314](03) 83c404 add esp,+04
[00001317](02) 33c0 xor eax,eax
[00001319](01) 5d pop ebp
[0000131a](01) c3 ret
Size in bytes:(0020) [0000131a]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00001307][00102190][00000000] 55 push ebp
[00001308][00102190][00000000] 8bec mov ebp,esp
[0000130a][0010218c][000012e7] 68e7120000 push 000012e7 // push P
[0000130f][00102188][00001314] e8d3ffffff call 000012e7 // call P
[000012e7][00102184][00102190] 55 push ebp // enter executed P
[000012e8][00102184][00102190] 8bec mov ebp,esp
[000012ea][00102184][00102190] 8b4508 mov eax,[ebp+08]
[000012ed][00102180][000012e7] 50 push eax // push P
[000012ee][00102180][000012e7] 8b4d08 mov ecx,[ebp+08]
[000012f1][0010217c][000012e7] 51 push ecx // push P
[000012f2][00102178][000012f7] e880feffff call 00001177 // call H

Begin Local Halt Decider Simulation Execution Trace Stored at:212244
[000012e7][00212230][00212234] 55 push ebp // enter emulated P
[000012e8][00212230][00212234] 8bec mov ebp,esp
[000012ea][00212230][00212234] 8b4508 mov eax,[ebp+08]
[000012ed][0021222c][000012e7] 50 push eax // push P
[000012ee][0021222c][000012e7] 8b4d08 mov ecx,[ebp+08]
[000012f1][00212228][000012e7] 51 push ecx // push P
[000012f2][00212224][000012f7] e880feffff call 00001177 // call H
[000012e7][0025cc58][0025cc5c] 55 push ebp // enter emulated P
[000012e8][0025cc58][0025cc5c] 8bec mov ebp,esp
[000012ea][0025cc58][0025cc5c] 8b4508 mov eax,[ebp+08]
[000012ed][0025cc54][000012e7] 50 push eax // push P
[000012ee][0025cc54][000012e7] 8b4d08 mov ecx,[ebp+08]
[000012f1][0025cc50][000012e7] 51 push ecx // push P
[000012f2][0025cc4c][000012f7] e880feffff call 00001177 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction of P repeats this process we know with complete
certainty that the correct and complete emulation of P by H would never
reach its final “ret” instruction, thus never halts.

[000012f7][00102184][00102190] 83c408 add esp,+08
[000012fa][00102184][00102190] 85c0 test eax,eax
[000012fc][00102184][00102190] 7402 jz 00001300
[00001300][00102188][00001314] 5d pop ebp
[00001301][0010218c][000012e7] c3 ret // executed P halts
[00001314][00102190][00000000] 83c404 add esp,+04
[00001317][00102190][00000000] 33c0 xor eax,eax
[00001319][00102194][00100000] 5d pop ebp
[0000131a][00102198][00000000] c3 ret // main() halts
Number of Instructions Executed(15900)

[Mr Flibble]

Only because that is how your simulation detector, S (not H), works by
using an erroneous recursion. If P would have halted (i.e. when being
decided on by a proper halt decider with no recursion) then your S gets
the answer wrong so it is not a halt decider.

/Flibble

[olcott]

In other words you are stupidly saying that when a correct x86 emulation
of the input to H(P,P) reaches the machine address of P [000012f2] where
the machine code specifies that P must call H(P,P) the correct emulation
of P would do something else besides what the x86 machine code at
address [000012f2] specifies.

> If P would have halted (i.e. when being
> decided on by a proper halt decider with no recursion) then your S gets
> the answer wrong so it is not a halt decider.
>
> /Flibble
>

--
Copyright 2022 Pete Olcott

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

[rthiebaud]

Constantly insulting those who disagree with you make you look stupid,
not then.

[olcott]

I have been through this exact same material many hundreds of times with
them and they just don't get it. I am proven to be correct on the basis
of verified facts that are simply beyond their intellectual capacity.

Before I started calling them stupid casual onlookers could far too
easily guess that they are correct and I am incorrect.

Instead of calling them stupid I could say that every competent software
engineer would agree that I am correct and they are incorrect. The
problem with this is that they simply presume that they are competent so
I had to use words that much more sharply draw the distinction.

[Otto J. Makela]

olcott <No...@NoWhere.com> wrote:

> Before I started calling them stupid casual onlookers could far too
> easily guess that they are correct and I am incorrect.

It's good that you started calling them stupid, now casual onlookers no
longer have doubts that they are correct and you are incorrect.

--
/* * * Otto J. Makela <o...@iki.fi> * * * * * * * * * */
/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */

[olcott]

On 6/10/2022 10:07 AM, Otto J. Makela wrote:
> olcott <No...@NoWhere.com> wrote:
>
>> Before I started calling them stupid casual onlookers could far too
>> easily guess that they are correct and I am incorrect.
>
> It's good that you started calling them stupid, now casual onlookers no
> longer have doubts that they are correct and you are incorrect.
>

Sure eveyone knows that a wild guess on the basis of credibility
supersedes and overrides the verified facts.

[Freethinker]

If you have been proven to be correct, why do you keep trying to
convince them that they are wrong? Repeating thousands of times that you
are right and they are wrong will not make you any righter or them any
more wrong. Do you want to make the world a better place? I'm afraid
that is a lost battle.

[olcott]

The issue is that verified facts prove that I am correct yet my
reviewers consistently disagree with easily verified facts.

I need honest and competent reviewer here to verify the software
engineering of my claims. My prior reviewers are either dishonest or
incompetent.

>> Before I started calling them stupid casual onlookers could far too
>> easily guess that they are correct and I am incorrect.
>>
>> Instead of calling them stupid I could say that every competent
>> software engineer would agree that I am correct and they are
>> incorrect. The problem with this is that they simply presume that they
>> are competent so I had to use words that much more sharply draw the
>> distinction.
>>
>>
>>
>>
>>
>

[Richard Damon]

On 6/11/22 10:04 AM, olcott wrote:
>>
>
> The issue is that verified facts prove that I am correct yet my
> reviewers consistently disagree with easily verified facts.
>
> I need honest and competent reviewer here to verify the software
> engineering of my claims. My prior reviewers are either dishonest or
> incompetent.

No, you need to honest with yourself.

"Verified" normally means by an independent source, not yourself. "Self
Verification" isn't really verification. Your claims have NEVER be
"verified", and in fact, you refuse to provide the means to let someone
actualy verify them since the key is the software you claim to have
writen, but won't let anyone else see.

Your claimed "proofs" are full of holes, and when people point them out
you just "cover your ears" and go "Blah-Blah-Blah I can't hear you".

This doesn't make the flaws go away, just proves that you don't care
about truth.

Your whole argument is based on flawed logic and false definitions, but
you refuse to look at them.

[olcott]

On 6/11/2022 11:07 AM, Richard Damon wrote:
> On 6/11/22 10:04 AM, olcott wrote:
>>>
>>
>> The issue is that verified facts prove that I am correct yet my
>> reviewers consistently disagree with easily verified facts.
>>
>> I need honest and competent reviewer here to verify the software
>> engineering of my claims. My prior reviewers are either dishonest or
>> incompetent.
>
> No, you need to honest with yourself.
>
> "Verified" normally means by an independent source, not yourself.

When dealing with objectively verifiable facts and not subjective
judgement calls validation is axiomatic.

The x86 language is a formal mathematical language in that the semantics
specified by programs written in this language have zero ambiguity or
leeway for different subjective interpretation of their meaning.

When I say that this specifies and infinite loop anyone that disagrees
simply objectively incorrect.

_Infinite_Loop()
[00001316](01) 55 push ebp
[00001317](02) 8bec mov ebp,esp
[00001319](02) ebfe jmp 00001319
[0000131b](01) 5d pop ebp
[0000131c](01) c3 ret
Size in bytes:(0007) [0000131c]

All recent rebuttals of my work have taken the form of disagreeing with
the x86 language.

[Mr Flibble]

But you assert the infinite loop is unreachable in P so what is
the point of posting its disassembly here?

/Flibble

[olcott]

Did you notice that the name of the above function is not P?

[Mr Flibble]

On Sat, 11 Jun 2022 12:39:14 -0500

Why post the trace of an infinite loop if the infinite loop in P isn't
reachable? What point are you trying to make? You have already refused
to divulge your algorithm for detecting infinite loops; this trace
provides no insight into your method whatsoever. Either publish source
code or keep shouting into the void.

/Flibble

[olcott]

The point that I just made is that when anyone disagrees with the x86
language then they are necessary incorrect.

The concrete example above shown an infinite loop thus anyone that
disagrees that it is an infinite loop is wrong.

> You have already refused
> to divulge your algorithm for detecting infinite loops;

The algorithm for detecting the above infinite loop is self-evident to
all competent software engineers.

That you cannot begin to imagine what this algorithm is proves your
complete incompetence.

> this trace
> provides no insight into your method whatsoever. Either publish source
> code or keep shouting into the void.
>
> /Flibble
>

[Mr Flibble]

On Sat, 11 Jun 2022 13:01:28 -0500

It isn't self-evident at all. You could be doing naive pattern matching
looking for the emulation of the x86 opcodes "EB FE" or you could be
doing something less naive such as detecting the same machine (CPU/RAM)
state when the same instruction pointer register is set more than once.

>
> That you cannot begin to imagine what this algorithm is proves your
> complete incompetence.

I can imagine several of ways of doing it; why do you refuse to divulge
how you do it? What are you trying to hide?

/Flibble

[olcott]

In other words you expressly acknowledge that you are woefully
incompetent to determine what a correct infinite loop detector would do.

>>
>> That you cannot begin to imagine what this algorithm is proves your
>> complete incompetence.
>
> I can imagine several of ways of doing it; why do you refuse to divulge
> how you do it? What are you trying to hide?
>
> /Flibble
>

Can you imagine one correct way that it can be done?
If you can then this proves that such a way exists.
If you can't then this proves that you are woefully incompetent.

[Mr Flibble]

On Sat, 11 Jun 2022 13:16:17 -0500

The mask is slipping. You've got nothing but smoke and mirrors.

/Flibble

[olcott]

Every competent software engineer here can easily determine the
algorithm for recognizing an infinite loop from the following behavior
pattern. That you cannot do this proves your incompetence.

Begin Local Halt Decider Simulation Execution Trace Stored at:212343
[00001342][00212333][00212337] 55 push ebp
[00001343][00212333][00212337] 8bec mov ebp,esp
[00001345][00212333][00212337] ebfe jmp 00001345
[00001345][00212333][00212337] ebfe jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped

[Mr Flibble]

On Sat, 11 Jun 2022 13:21:25 -0500

Your vacuous meaningless insults reveal more about your character than
anything else. As far as the subject at hand is concerned: all you've
got is smoke and mirrors.

/Flibble

[olcott]

It is an easily objectively verifiable fact that every competent
software engineer can correctly determine the trivial algorithm required
to recognize the above infinite behavior pattern.

> As far as the subject at hand is concerned: all you've
> got is smoke and mirrors.
>
> /Flibble
>
>

[Mr Flibble]

On Sat, 11 Jun 2022 13:28:24 -0500

There are 2^n (n proportional to machine RAM size) different ways of
expressing an infinite loop; the above infinite loop is the most
trivial case and is easily detected however you are not telling us how
you detect the *general* case.

How would you detect the following infinite loop:

void foo()
{
bool stop = false;
while(!stop)
{
stop = FUBAR();
}
}

Where FUBAR can be trivial or complex with or without branching logic
predicated on arbitrary program input that is disguising the fact that
it always returns false?

/Flibble

[Richard Damon]

And yet, when you talk about x86 execution you say that call H doesn't
cause the first instruction of H to execute and be traced.

You logic is inconsitent.

Also, no one has argued that Infinite Loop can't be correctly decided,
as it exactly matchs a well proven pattern. The problem is you think
that just because there is a pattern for Infinite_Loop() that there also
is a pattern for your P().

You just don't seem to understand what is proven and what isn't.

Note also, you aren't allowed to create your own "axioms" in an existing
formal logic to redefine terms.

If you want to actually FORMALLY PROVE your statement, BASED on the
axioms, go ahead. make sure you actually quote the axioms you are using
and if you don't think we will recognize them give you sources.

Note, "Meaning of the Words" and phrases like that are NOT proofs, you
can quote a formal definition and show how something matches it to prove
the definition applies.

For instance, a Halting Machine is a Machine that reaches its final
state. Note, the references the MACHINE itself, not a "simulation" of
said machine, and Turing Machines, once defined don't stop until they
reach a final state.

[olcott]

If you know that the above infinite loop can be easily detected then
everything else is out-of-scope. Any kind of infinite loop at all is
actually out-of-scope, H only needs to correctly detect one specific
case of infinitely nested simulation. I threw in some infinite loops and
some infinite recursion just to make my code a little more robust.

[Richard Damon]

No, you are just committing the fallacy of the Red Herring.

NO ONE said anything against the decision of Infinite_Loop.

>
> The concrete example above shown an infinite loop thus anyone that
> disagrees that it is an infinite loop is wrong.
>

And no one does. So why bring it up except to make your Herring Red?

>> You have already refused
>> to divulge your algorithm for detecting infinite loops;
>
> The algorithm for detecting the above infinite loop is self-evident to
> all competent software engineers.

No one disagrees

>
> That you cannot begin to imagine what this algorithm is proves your
> complete incompetence.

The fact that you can't tell the difference between Infinite_Loop and P
or the agruments about them, just shows your (lack of) mental acuity.

You are stuck in your lies, and digging deeper and deeper holes that are
now very hard for you to get yourself out of.

[Mr Flibble]

On Sat, 11 Jun 2022 13:53:16 -0500

Smoke. And. Mirrors.

/Flibble

[olcott]

When I correct your mistake you simply ignore my correction and make the
exact same mistake many hundreds of times. This proves to me that you
are not capable of an honest dialogue.

[Richard Damon]

YOU don't get to define scope.

Note, there are many ways to detect that Infinite_Loop is non-halting.

NONE of them can be in H to correct detect that P is non-halting, as if
H detects that P is non-halting and return 0, then P(P) becomes halting.

[olcott]

Sure I do, the scope of my research project (my project thus I am the
king of its scope) is to show that one instance of an H and P having the
following relationship is correctly decided as non-halting.

For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own source and its
input to
H and then specifically do the opposite of what H predicts P will
do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem

[Mr Flibble]

On Sat, 11 Jun 2022 14:04:32 -0500

Your H returns the wrong answer if P would have halted so your H is not
a program "that might determine if programs halt" according to what
is in scope of your "research project".

/Flibble

[olcott]

It is an easily verified fact that the correct and complete x86
emulation of the input to H(P,P) would never stop running.

[Richard Damon]

Nope, it has been shown to you, and you have even posted yourself, the
trace of the simulation of the input to H(P,P) that halts when H(P,,P)
returns 0.

Your proof that it doesn't stop running made the assumption that H
doesn't abort and return 0 (which makes it not do a correct and complete
x86 emulation)

Part of the issue is your apparent assumption that H can do both, do a
correct and complete x86 emulation and abort is simulation and return 0
at the same time, which it can't

[olcott]

The simulated P never ever reaches its final state.
You already admitted this thus proving that you are lying now.

[Richard Damon]

Your missing words.

The simulation BY H, can't reach the final state.

If H aborts its simulation, and rejects the input, then THAT P, when
properly simulated will reach its final state.

You make the rooking mistake of conflating different programs because
you call them all the same thing.

The H that doesn't abort, fails because it doesn't answer.

The H that does abort, fails because the P built on it, does halt,
BECAUSE H rejected it.

Your logic just can't seem to handle the conditionals.

[olcott]

The you believe a terminated process continues to execute after it has
been terminated is nuts. No one here believes that a terminated process
keeps running.

[Richard Damon]

And you seem to be mistaken that Halting is about the partially
simulated machine and not the machine itself.

If someone complains that the program you sold them never finishes, and
it turns out they keep on aborting it half way through, you know that
they are actually lying.

Halting is about the ACTUAL execution of the program when unfettered by
external influences, and for that P(P) Halts if H(P,P) returns 0, and
you are just showing your lack of understanding of what that means.

When you don't even know what the basic words mean, it is hard to get
much right.

[olcott]

When the behavior of the complete and correct x86 emulation of an input
is correctly predicted to never stop running then H(P,P)==0 is
necessarily correct.

That you continue to disagree with verified facts make you seem quite nuts.

[Freethinker]

Olcott, you got youself into an infinite loop. I hereby correctly
predict that you'll never halt!
Now try proving me wrong, if you can.

[olcott]

I am almost to the point where I can get official reviews from expert
PhD computer scientists in the field.

The most important aspect of this review can be done by ordinary
competent software engineers in this forum.

[Richard Damon]

Yes, and if H does that, it never returns that 0, so it is still wrong.

You need a consistent and definite behavior for your H, which you
currently lack, and actively refuse to define (so shows you are being
decptive).

Either it DOES a correct and complete emulation, and creates an
non-halting P(P) but fails to give the answer, or

If your H does abort its emulation, so it can return the 0 to say the
input represents a non-halting computaton, also meaning its emulation is
NOT correct and complete, and when it returns the 0, it makes it so that
the correct and complete emulation of the P built from that H will Halt
when H(P,P) returns that 0 to it.

[olcott]

With my latest update H correctly predicts that its complete x86
emulation of P would never stop running before the second emulation even
begins.

[Richard Damon]

Saying it doesn't make it true.

Since, by construction P(P) will Halt if H(P,P) returns 0, what you say
is actually impossible.

Note, if H actually does a complete x86 emulation of its input, and that
is non-halting, it CAN'T return 0 in finite time.

That requries doing infinite work in finite time. So, your claim must be
a lie as it is impossible.

[olcott]

This proves that it is true.

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

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

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

It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction of P repeats this process we can know with complete
certainty that the emulated P never reaches its final “ret” instruction,
thus never halts.

[Richard Damon]

Except that the correct emulation needs to emulate that emulation, not
just start it again.

Since H is a decider, and thus just conditionally emulates its input,
you are using an incorrect transform.

This just proves the limitations of your thinking process.

Yes, if H never aborts its emulation, the emulation goes on forever.

That does NOT mean it is correct to abort its emulation and say it is
non-halting. That is unsound logic, as it had a premise that it would
not abort.

If H does abort is emulation, at ANY point, then a CORRECT emulation of
that input will emulate P calling H, the H doing its stuff and aborting
its emulation, returning to P and P halting. Remember, an aborted
emulation is NEVER a complete and correct emulation.

[Öö Tiib]

On Thursday, 9 June 2022 at 18:46:41 UTC+3, olcott wrote:
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> return;
> }
>
> int main()
> {

> P(P);
> }
>
> _P()
> [000012e7](01) 55 push ebp
> [000012e8](02) 8bec mov ebp,esp
> [000012ea](03) 8b4508 mov eax,[ebp+08]
> [000012ed](01) 50 push eax
> [000012ee](03) 8b4d08 mov ecx,[ebp+08]
> [000012f1](01) 51 push ecx
> [000012f2](05) e880feffff call 00001177 // call H
> [000012f7](03) 83c408 add esp,+08
> [000012fa](02) 85c0 test eax,eax
> [000012fc](02) 7402 jz 00001300
> [000012fe](02) ebfe jmp 000012fe
> [00001300](01) 5d pop ebp
> [00001301](01) c3 ret
> Size in bytes:(0027) [00001301]
>
> _main()
> [00001307](01) 55 push ebp
> [00001308](02) 8bec mov ebp,esp
> [0000130a](05) 68e7120000 push 000012e7 // push P
> [0000130f](05) e8d3ffffff call 000012e7 // call P
> [00001314](03) 83c404 add esp,+04
> [00001317](02) 33c0 xor eax,eax
> [00001319](01) 5d pop ebp
> [0000131a](01) c3 ret
> Size in bytes:(0020) [0000131a]
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> [00001307][00102190][00000000] 55 push ebp
> [00001308][00102190][00000000] 8bec mov ebp,esp
> [0000130a][0010218c][000012e7] 68e7120000 push 000012e7 // push P
> [0000130f][00102188][00001314] e8d3ffffff call 000012e7 // call P
> [000012e7][00102184][00102190] 55 push ebp // enter executed P
> [000012e8][00102184][00102190] 8bec mov ebp,esp
> [000012ea][00102184][00102190] 8b4508 mov eax,[ebp+08]
> [000012ed][00102180][000012e7] 50 push eax // push P
> [000012ee][00102180][000012e7] 8b4d08 mov ecx,[ebp+08]
> [000012f1][0010217c][000012e7] 51 push ecx // push P
> [000012f2][00102178][000012f7] e880feffff call 00001177 // call H
>
> Begin Local Halt Decider Simulation Execution Trace Stored at:212244
> [000012e7][00212230][00212234] 55 push ebp // enter emulated P
> [000012e8][00212230][00212234] 8bec mov ebp,esp
> [000012ea][00212230][00212234] 8b4508 mov eax,[ebp+08]
> [000012ed][0021222c][000012e7] 50 push eax // push P
> [000012ee][0021222c][000012e7] 8b4d08 mov ecx,[ebp+08]
> [000012f1][00212228][000012e7] 51 push ecx // push P
> [000012f2][00212224][000012f7] e880feffff call 00001177 // call H
> [000012e7][0025cc58][0025cc5c] 55 push ebp // enter emulated P
> [000012e8][0025cc58][0025cc5c] 8bec mov ebp,esp
> [000012ea][0025cc58][0025cc5c] 8b4508 mov eax,[ebp+08]
> [000012ed][0025cc54][000012e7] 50 push eax // push P
> [000012ee][0025cc54][000012e7] 8b4d08 mov ecx,[ebp+08]
> [000012f1][0025cc50][000012e7] 51 push ecx // push P
> [000012f2][0025cc4c][000012f7] e880feffff call 00001177 // call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

>
> It is completely obvious that when H(P,P) correctly emulates its input
> that it must emulate the first seven instructions of P. Because the

> seventh instruction of P repeats this process we know with complete
> certainty that the correct and complete emulation of P by H would never
> reach its final “ret” instruction, thus never halts.
>
> [000012f7][00102184][00102190] 83c408 add esp,+08
> [000012fa][00102184][00102190] 85c0 test eax,eax
> [000012fc][00102184][00102190] 7402 jz 00001300
> [00001300][00102188][00001314] 5d pop ebp
> [00001301][0010218c][000012e7] c3 ret // executed P halts
> [00001314][00102190][00000000] 83c404 add esp,+04
> [00001317][00102190][00000000] 33c0 xor eax,eax
> [00001319][00102194][00100000] 5d pop ebp
> [0000131a][00102198][00000000] c3 ret // main() halts
> Number of Instructions Executed(15900)

It is unsure what is your point? Did you prove that on some narrow case
you can show of one infinite loop is not halting? That does not ring any bells.
What you want from us? You have not provided even some meaningful
algorithm to review and so it is uncertain what you want from software
engineers. Should we agree that you are a God? That you may have your
child porn? Whatever. My personal suggestion ... just follow laws of
your local jurisdiction. Our approval or condemnation does not matter.

[olcott]

The above is a sufficient summation of the algorithm to evaluate the
correctness of H(P,P)==0. H uses an x86 emulator to simulate its input.

>>
>>
>
> Except that the correct emulation needs to emulate that emulation, not
> just start it again.
>

The updated version correctly aborts its x86 emulation of P as soon as P
calls H(P,P), thus there are zero nested emulations.

To provide context for other reviewers I created the x86utm operating
system so that I could show a simulating halt decider halt decider C
function that correctly decides the halt status of another C function P
where H and P have the halting problem relationship as shown in the next
paragraph.

For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own source and its
input to
H and then specifically do the opposite of what H predicts P will
do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem

Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

[Richard Damon]

HOW IS SOMETHING WRONG ABLE TO PROVE ANYTHING?

>>>
>>>
>>
>> Except that the correct emulation needs to emulate that emulation, not
>> just start it again.
>>
>
> The updated version correctly aborts its x86 emulation of P as soon as P
> calls H(P,P), thus there are zero nested emulations.

BUT IT USES A WRONG RULE. P calling H(P,P) is NOT proof of non-halting.

What PROOF do you have that it is correct? It is just another of your
FALSE presumptions.

You can prove all sorts of stuff if you are allowed false premises.

>
> To provide context for other reviewers I created the x86utm operating
> system so that I could show a simulating halt decider halt decider C
> function that correctly decides the halt status of another C function P
> where H and P have the halting problem relationship as shown in the next
> paragraph.
>
>      For any program H that might determine if programs halt, a
> "pathological"
>      program P, called with some input, can pass its own source and its
> input to
>      H and then specifically do the opposite of what H predicts P will
> do. No H
>      can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem
>
>
> Halting problem undecidability and infinitely nested simulation (V5)
>
> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>
>
>
>

It is FALSE that P(P) calling H(P,P) proves non-halting.

From your definitions, we KNOW that H(P,P) is going to return 0, thus P
calling H(P,P) is NOT going to create infinite behavior.

The fact that it is still shown that P(P) Halts when H(P,P) returns 0
means that H(P,P) returning 0 is still wrong.

That is still fundamentally the question, and H still fails it.

[olcott]

That something is beyond your intellectual capacity is zero evidence
what-so-ever that it is false. Only competent software engineers can
validate my claim.

> From your definitions, we KNOW that H(P,P) is going to return 0, thus P
> calling H(P,P) is NOT going to create infinite behavior.
>
> The fact that it is still shown that P(P) Halts when H(P,P) returns 0
> means that H(P,P) returning 0 is still wrong.
>
> That is still fundamentally the question, and H still fails it.

[Mr Flibble]

On Sun, 12 Jun 2022 09:53:25 -0500

Everybody else is stupid and you are correct. Mate, you are a tool.

/Flibble

[olcott]

Only you and Richard.

[Richard Damon]

What, do you deny that when P(P) calls H(P,P) and it returns the 0 to it
that P hatis? If so, then you have lied that you built P correctly.

IF H(P,P) doesn't return the 0, then you have lied about what H does, or
that it is actually the needed computation.

The ONLY case where P(P) calling H(P,P) is actually non-halting is the
case where H(P,P) never aborts its simulation, EVER, and such an H can't
return 0 for H(P,P), so you lie that H is correct returning a value it
never returns.

Which LIE will you admit to? Or are there more than one of them?

FAIL.

You wouldn't know a proof if it bit you, you certainly have never
actually produced a correct one (at least that I have seen)

[Mr Flibble]

I agree Olcott is a liar: he keeps repeating the lie that I don't know
what unreachable code is.

Is there any point trying to continue to debate with a pathological
liar?

/Flibble

[Richard Damon]

So, everyone else who says you are wrong is right, and you admit to
being actually wrong?

You can't stand what I say, because I apparently can detect the core
flaws in your arguments and directly challenge them.

Your whole strategy is based on flawed logic, in part because you just
won't admit that there IS a core logic you need to follow.

This is because your basic idea about what is Truth is flawed an
inconsistent, but you just can't hear that.

[olcott]

On 6/12/2022 12:33 PM, Richard Damon wrote:
>
> On 6/12/22 12:57 PM, olcott wrote:
>> On 6/12/2022 11:55 AM, Mr Flibble wrote:
>>> On Sun, 12 Jun 2022 09:53:25 -0500
>>> olcott <No...@NoWhere.com> wrote:
>>>
>>>> On 6/12/2022 7:02 AM, Richard Damon wrote:
>>>>>
>>>>>
>>>>> It is FALSE that P(P) calling H(P,P) proves non-halting.
>>>>
>>>> That something is beyond your intellectual capacity is zero evidence
>>>> what-so-ever that it is false. Only competent software engineers can
>>>> validate my claim.
>>>
>>> Everybody else is stupid and you are correct. Mate, you are a tool.
>>>
>>> /Flibble
>>>
>>
>> Only you and Richard.
>>
>
> So, everyone else who says you are wrong is right, and you admit to
> being actually wrong?

Everyone else is sufficiently competent to explain their reasoning and
not directly contradict verifiable facts except for this one issue:

A halt decider must compute the mapping from its input finite strings to
an accept or reject state based on the actual behavior that is actually
specified by this input.

The problem where is that although I have proved that the correct and
complete x86 emulation of the inputs to H(P,P) would never stop running
they still believe that H should report that its input halts on the
basis of an entirely different sequence of instructions specified by the
execution of P(P).

[olcott]

On 6/12/2022 12:33 PM, Richard Damon wrote:
>

This is the core logic:

The criterion measure for a simulating halt decider (SHD)
When the correct partial x86 emulation of the input matches a
non-halting behavior pattern such that it correctly determines that a
complete emulation of the input would never stop running, or reach its
“ret” instruction then the SHD aborts its emulation and correctly
returns 0.

> This is because your basic idea about what is Truth is flawed an
> inconsistent, but you just can't hear that.

[Freethinker]

If you want to have even more fun, try with Trump.

[olcott]

I saved a copy of this in case it ever comes up again.

Below proves that you do not know that every instruction after
[0000135d] is unreachable when you suggest that modifying the opcode at
unreachable address 00001369 would change the behavior.

from comp.theory
On 6/9/2022 12:46 PM, Mr Flibble wrote:

> On Thu, 9 Jun 2022 12:39:32 -0500
> olcott <No...@NoWhere.com> wrote:
>> _P()
>> [00001352](01) 55 push ebp
>> [00001353](02) 8bec mov ebp,esp
>> [00001355](03) 8b4508 mov eax,[ebp+08]
>> [00001358](01) 50 push eax // push P
>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>> [0000135c](01) 51 push ecx // push P
>> [0000135d](05) e840feffff call 000011a2 // call H
>> [00001362](03) 83c408 add esp,+08
>> [00001365](02) 85c0 test eax,eax
>> [00001367](02) 7402 jz 0000136b
>> [00001369](02) ebfe jmp 00001369
>> [0000136b](01) 5d pop ebp
>> [0000136c](01) c3 ret
>> Size in bytes:(0027) [0000136c]
>>
>> It is completely obvious that when H(P,P) correctly emulates its
>> input that it must emulate the first seven instructions of P. Because

>> the seventh instruction of P repeats this process we know with
>> complete certainty that the correct and complete emulation of P by H

>> would never reach its final “ret” instruction, thus never halts.
>
> We are going around and around and around in circles. I will try again:
>
> If you replace the opcodes "EB FE" at 00001369 with the opcodes "90 90"
> then your H gets the answer wrong: P should have halted.
>
> /Flibble

[Richard Damon]

If 00001362 is unreachable, that meas that H(P,P) never returns, so your
H fails to be a decider, and your H never returns the 0 that you say it
correctly returns so you are caught in a lie.

It seems you like to have your H be different functions at different
times in your argument, which isn't allowed.

H needs to be a Computation (which is sort of like your Pure Function)
ant that means that all calls to it do the same thing.

If you want to argue differently, please show the first divergence
between two invocations of the identical code, with identical inputs to
calls of the identical code with identical arguments for code that only
access its arguments and things derived from those arguements.

You need to show an ACTUAL deterministic step that starts with exactly
equal inputs and gets two different results.

Either your H is actually taking some input other than its direct
inputs, and thus not a computation (or a Pure Function) or,

H actually does return the same to main an P and your H is proved
incorrect, or

If you can actually prove this possible, you have assured your fame on
the level of Russel (but this isn't going to happen).

[Ben Bacarisse]

Mr Flibble <fli...@reddwarf.jmc> writes:
> On Sun, 12 Jun 2022 13:26:18 -0400
> Richard Damon <Ric...@Damon-Family.org> wrote:

<cut>

> Is there any point trying to continue to debate with a pathological
> liar?

Can I urge anyone who still wants to reply to add

Followup-To: comp.theory

to the header (as I have done here) or, ideally, simply ignore PO's
off-topic posts here? The same context is posted in several other
groups so I am not suggesting you don't reply if you feel the need.

And, since I am already posting, were all 390 lines of quoted material
really germane to your (or Richard's) point?

--
Ben.

[Mr Flibble]

On Sun, 12 Jun 2022 14:17:08 -0500

That isn't proof that I don't know what unreachable code is (as I do);
it is proof that P would have halted if the code *was* reachable if H
returned a value: the fact that H doesn't return a value means H is not
a halt decider; which was my actual point. You can't have a H that
returns a value in one context and not in another and at the same time
claim it is the same H (or that H is a halt decider).

/Flibble

[olcott]

It is proof that you are unable to correctly assess one instance of
unreachable code thus do not understand the concept of unreachable code
sufficiently well.

> it is proof that P would have halted if the code *was* reachable if H

If pigs fly then maybe they have wings?

> returned a value: the fact that H doesn't return a value means H is not

When H(P,P) is called from main() then its correctly emulated input
cannot possibly ever reach any point beyond [0000135d] no matter what H
does.

> a halt decider; which was my actual point. You can't have a H that
> returns a value in one context and not in another and at the same time
> claim it is the same H (or that H is a halt decider).

Like Richard you seem to honestly believe that an aborted emulation
continues to execute after it has been aborted and is incorrect if it
does not continue to execute.

[olcott]

This discussion is confined to the software engineering aspects of a
pair of C functions. It is confined to these two forums because the
people in other other forums have proven to not have sufficient
technical competence in software engineering.

[Mr Flibble]

On Sun, 12 Jun 2022 15:04:09 -0500

No, I fully understand what unreachable code is, the problem is your
inability to comprehend English, to follow a simple argument and not
to pathologically lie when you have exhausted all other avenues of
reasonable (or in your case unreasonable) debate.

Some forms of unreachable code:

// Early return
void foo()
{
return;
bar(); // unreachable
}

// Recursion
void foo(int n)
{
if (n == 42)
throw 42;
foo(n+1);
bar(); // unreachable
}

// Exception
void foo()
{
throw 42;
bar(); // unreachable
}

// Process termination
void foo()
{
std::exit(0);
bar(); // unreachable
}

I bet I have just come up with more forms of unreachable code than you
could have, haven't I, dear? I can think of others but I think I have
made my point.

Now either apologize or fuck off.

/Flibble

[olcott]

It is a very common dishonest tactic to change the subject for the
purpose of fake rebuttal.

Do you now understand that every address after [0000135d] is unreachable
by the correctly emulated input to H(P,P)?

(You did not understand this previously)

[Mr Flibble]

On Sun, 12 Jun 2022 15:52:47 -0500

I did understand it previously; I understood that your H when called
from P never returns a value to P so:

a) the goto statement is never reached;
b) H is not a halt decider; and,
c) if your H did return a value (of 0) to P and the goto statement was
replaced with a return statement then your H would get the answer wrong.

/Flibble

[olcott]

Pigs don't fly.

> b) H is not a halt decider; and,
> c) if your H did return a value (of 0) to P and the goto statement was

If Pigs do fly...

> replaced with a return statement then your H would get the answer wrong.
>
> /Flibble
>

[Richard Damon]

So, you admit that H(P,P) NEVER returns so the code is unrachable>

Then

>
>> it is proof that P would have halted if the code *was* reachable if H
>
> If pigs fly then maybe they have wings?
>
>> returned a value: the fact that H doesn't return a value means H is not
>
> When H(P,P) is called from main() then its correctly emulated input
> cannot possibly ever reach any point beyond [0000135d] no matter what H
> does.

All calls of H(P,P) need to act the same, or you are proved to have lied
that H is a computation. You have failed to provide any proof that you
claim of the impossible is possible, so repeating the claim is an
admission of lying.

>
>> a halt decider; which was my actual point. You can't have a H that
>> returns a value in one context and not in another and at the same time
>> claim it is the same H (or that H is a halt decider).
>
> Like Richard you seem to honestly believe that an aborted emulation
> continues to execute after it has been aborted and is incorrect if it
> does not continue to execute.
>

Who is talking about aborted emulations?

You have made claims of CORRECT emulations, which by definition don't
abort or otherwise stop until the program they are emulating reaches its
final state.

You seem to have a problem on this. You must be too stupid to understand
the meaning of the words you misuse.

[Richard Damon]

On 6/12/22 2:20 PM, olcott wrote:
> On 6/12/2022 12:33 PM, Richard Damon wrote:
>>
>> On 6/12/22 12:57 PM, olcott wrote:
>>> On 6/12/2022 11:55 AM, Mr Flibble wrote:
>>>> On Sun, 12 Jun 2022 09:53:25 -0500
>>>> olcott <No...@NoWhere.com> wrote:
>>>>
>>>>> On 6/12/2022 7:02 AM, Richard Damon wrote:
>>>>>>
>>>>>>
>>>>>> It is FALSE that P(P) calling H(P,P) proves non-halting.
>>>>>
>>>>> That something is beyond your intellectual capacity is zero evidence
>>>>> what-so-ever that it is false. Only competent software engineers can
>>>>> validate my claim.
>>>>
>>>> Everybody else is stupid and you are correct. Mate, you are a tool.
>>>>
>>>> /Flibble
>>>>
>>>
>>> Only you and Richard.
>>>
>>
>> So, everyone else who says you are wrong is right, and you admit to
>> being actually wrong?
>
> Everyone else is sufficiently competent to explain their reasoning and
> not directly contradict verifiable facts except for this one issue:
>
> A halt decider must compute the mapping from its input finite strings to
> an accept or reject state based on the actual behavior that is actually
> specified by this input.

Which IS the behavior of P(P) unless your H isn't a Halt decider or P
wasn't built to the instructions.

Remember, P is given a representation of itself, and is to ask H to
decide on the machine that its was given a representation of (that would
be P) when applied to the description it was given, that would result in
P(P).

If this can't be given to H, then H just fails to be the needed decider,
since this is a valid input to ask H, if this isn't the right way to ask
it, then P was designed wrong.

>
> The problem where is that although I have proved that the correct and
> complete x86 emulation of the inputs to H(P,P) would never stop running
> they still believe that H should report that its input halts on the
> basis of an entirely different sequence of instructions specified by the
> execution of P(P).
>

No, you haven't. You have only proved that when H actually does the
complete and correct emulation itself, that this happens, but then H
never stops its emulation, and thus can never give the answer to the
call in main.

If you change H to abort and then return the answer, you now have a
different H, and since H is part of P, a different P, so you previous
analysis is not valid. The fact that you claim they are the same string
of bytes, just shows the flaw in your design. You string doesn't
actually define the behavior of the program.

When we look at the behavior of the P based on the H that does abort,
and thus doesn't do a complete and correct emulation of its input, when
we do that complete and correct emulation of the input (without changing
the H that the P uses) we see that P(P) Halts as it calls H(P,P) which
emulates for awhile, then aborts its emualtion and returns the answer to
the P that called it which halts.

I have explained this to you MANY times, and you still don't understand
it. You are either a pathological liar or have a mental deficiency.

Note, you have NEVER showed an actual error in this, only claimes of
impossibvle behaviors that you have yet to show how they can happen, so
are just more lies until they can be proven.

YOU FAIL.

[Richard Damon]

Except that this can't happen in the emulation of P(P), since any
pattern that the SHD might detect in this emulation that it decides is a
correct non-halting pattern, if it does abort its simulation and returns
0, then the actual correct and complete emulation of this input will
emulate that call to H(,P) which will emulate its input until it sees
the pattern, stop its emulation and return to its calling P which will
then halt, showing that the pattern was not actually correct.

This is a common fault with many of your arguments, you don't know how
to test if something actually exists.

[Keith Thompson]

Richard Damon <Ric...@Damon-Family.org> writes:
> On 6/12/22 4:04 PM, olcott wrote:

[479 lines deleted]

Richard, olcott has already taken over comp.theory. Please don't
help him take over comp.lang.c and comp.lang.c++. Please remove
them from the Newsgroups: header line when you post a followup.

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[olcott]

this On 6/13/2022 2:40 AM, Keith Thompson wrote:
> Richard Damon <Ric...@Damon-Family.org> writes:
>> On 6/12/22 4:04 PM, olcott wrote:
> [479 lines deleted]
>
> Richard, olcott has already taken over comp.theory. Please don't
> help him take over comp.lang.c and comp.lang.c++. Please remove
> them from the Newsgroups: header line when you post a followup.
>

If the people in comp.theory were not so incompetent at software
engineering I would not be here. As soon as the software engineering
aspects of H(P,P)==0 are fully addressed I will have no need to be here.

The people in comp.theory are so utterly incompetent at software
engineering that many dozens of them could never begin to understand
this simple execution trace. I have spent a year talking to dozens of
people about this and none of them can do the simple software
engineering correctly.

Richard was so woefully incompetent that he still keeps saying that when
H(P,P) aborts the x86 emulation of its input and returns 0 that this
aborted input continues to execute until it reaches its "ret" instruction.

#include <stdint.h>
#define u32 uint32_t

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

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

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

_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6852130000 push 00001352 // push P
[0000137a](05) 6852130000 push 00001352 // push P
[0000137f](05) e81efeffff call 000011a2 // call H
[00001384](03) 83c408 add esp,+08
[00001387](01) 50 push eax
[00001388](05) 6823040000 push 00000423 // "Input_Halts = "
[0000138d](05) e8e0f0ffff call 00000472 // call Output
[00001392](03) 83c408 add esp,+08
[00001395](02) 33c0 xor eax,eax
[00001397](01) 5d pop ebp
[00001398](01) c3 ret
Size in bytes:(0039) [00001398]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[00001372][0010229e][00000000] 55 push ebp
...[00001373][0010229e][00000000] 8bec mov ebp,esp
...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H

Begin Local Halt Decider Simulation Execution Trace Stored at:212352

// H emulates the first seven instructions of P
...[00001352][0021233e][00212342] 55 push ebp // enter P
...[00001353][0021233e][00212342] 8bec mov ebp,esp
...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
...[00001358][0021233a][00001352] 50 push eax // push P
...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][00212336][00001352] 51 push ecx // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

// The emulated H emulates the first seven instructions of P
...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
...[00001358][0025cd62][00001352] 50 push eax // push P
...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][0025cd5e][00001352] 51 push ecx // push P
...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction of P repeats this process we can know with complete
certainty that the emulated P never reaches its final “ret” instruction,
thus never halts.

...[00001384][0010229e][00000000] 83c408 add esp,+08
...[00001387][0010229a][00000000] 50 push eax
...[00001388][00102296][00000423] 6823040000 push 00000423 //
"Input_Halts = "
---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
Input_Halts = 0
...[00001392][0010229e][00000000] 83c408 add esp,+08
...[00001395][0010229e][00000000] 33c0 xor eax,eax
...[00001397][001022a2][00100000] 5d pop ebp
...[00001398][001022a6][00000004] c3 ret
Number_of_User_Instructions(1)
Number of Instructions Executed(15892) = 237 pages

The criterion measure for a simulating halt decider (SHD)
When the correct partial x86 emulation of the input matches a
non-halting behavior pattern such that it correctly determines that a
complete emulation of the input would never stop running, or reach its
“ret” instruction then the SHD aborts its emulation and correctly
returns 0.

[olcott]

I only need software engineers to confirm that H(P,P)==0 on the basis
that the correctly emulated P meets the above criteria.

Once this is done I will have no need for feedback from
comp.lang.c++ or comp.lang.c

[Mr Flibble]

We can all agree on S(P,P)==0 where S is a simulation detector (not a
halt decider).

/Flibble

[olcott]

No, Richard still believes that the correctly emulated input to H(P,P)
reaches its "ret" instruction as soon as its emulation has been aborted
and H returns 0.

[Mike Terry]

On 12/06/2022 03:19, Öö Tiib wrote:

> On Thursday, 9 June 2022 at 18:46:41 UTC+3, olcott wrote:
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> return;
>> }
>>
>> int main()
>> {

>> P(P);
>> }
>>
>> _P()
>> [000012e7](01) 55 push ebp
>> [000012e8](02) 8bec mov ebp,esp
>> [000012ea](03) 8b4508 mov eax,[ebp+08]
>> [000012ed](01) 50 push eax
>> [000012ee](03) 8b4d08 mov ecx,[ebp+08]
>> [000012f1](01) 51 push ecx
>> [000012f2](05) e880feffff call 00001177 // call H
>> [000012f7](03) 83c408 add esp,+08
>> [000012fa](02) 85c0 test eax,eax
>> [000012fc](02) 7402 jz 00001300
>> [000012fe](02) ebfe jmp 000012fe
>> [00001300](01) 5d pop ebp
>> [00001301](01) c3 ret
>> Size in bytes:(0027) [00001301]
>>
>> _main()
>> [00001307](01) 55 push ebp
>> [00001308](02) 8bec mov ebp,esp
>> [0000130a](05) 68e7120000 push 000012e7 // push P
>> [0000130f](05) e8d3ffffff call 000012e7 // call P
>> [00001314](03) 83c404 add esp,+04
>> [00001317](02) 33c0 xor eax,eax
>> [00001319](01) 5d pop ebp
>> [0000131a](01) c3 ret
>> Size in bytes:(0020) [0000131a]

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

>> [00001307][00102190][00000000] 55 push ebp
>> [00001308][00102190][00000000] 8bec mov ebp,esp
>> [0000130a][0010218c][000012e7] 68e7120000 push 000012e7 // push P
>> [0000130f][00102188][00001314] e8d3ffffff call 000012e7 // call P
>> [000012e7][00102184][00102190] 55 push ebp // enter executed P
>> [000012e8][00102184][00102190] 8bec mov ebp,esp
>> [000012ea][00102184][00102190] 8b4508 mov eax,[ebp+08]
>> [000012ed][00102180][000012e7] 50 push eax // push P
>> [000012ee][00102180][000012e7] 8b4d08 mov ecx,[ebp+08]
>> [000012f1][0010217c][000012e7] 51 push ecx // push P
>> [000012f2][00102178][000012f7] e880feffff call 00001177 // call H
>>
>> Begin Local Halt Decider Simulation Execution Trace Stored at:212244
>> [000012e7][00212230][00212234] 55 push ebp // enter emulated P
>> [000012e8][00212230][00212234] 8bec mov ebp,esp
>> [000012ea][00212230][00212234] 8b4508 mov eax,[ebp+08]
>> [000012ed][0021222c][000012e7] 50 push eax // push P
>> [000012ee][0021222c][000012e7] 8b4d08 mov ecx,[ebp+08]
>> [000012f1][00212228][000012e7] 51 push ecx // push P
>> [000012f2][00212224][000012f7] e880feffff call 00001177 // call H
>> [000012e7][0025cc58][0025cc5c] 55 push ebp // enter emulated P
>> [000012e8][0025cc58][0025cc5c] 8bec mov ebp,esp
>> [000012ea][0025cc58][0025cc5c] 8b4508 mov eax,[ebp+08]
>> [000012ed][0025cc54][000012e7] 50 push eax // push P
>> [000012ee][0025cc54][000012e7] 8b4d08 mov ecx,[ebp+08]
>> [000012f1][0025cc50][000012e7] 51 push ecx // push P
>> [000012f2][0025cc4c][000012f7] e880feffff call 00001177 // call H

>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>
>> It is completely obvious that when H(P,P) correctly emulates its input
>> that it must emulate the first seven instructions of P. Because the

>> seventh instruction of P repeats this process we know with complete
>> certainty that the correct and complete emulation of P by H would never

>> reach its final “ret” instruction, thus never halts.
>>
>> [000012f7][00102184][00102190] 83c408 add esp,+08
>> [000012fa][00102184][00102190] 85c0 test eax,eax
>> [000012fc][00102184][00102190] 7402 jz 00001300
>> [00001300][00102188][00001314] 5d pop ebp
>> [00001301][0010218c][000012e7] c3 ret // executed P halts
>> [00001314][00102190][00000000] 83c404 add esp,+04
>> [00001317][00102190][00000000] 33c0 xor eax,eax
>> [00001319][00102194][00100000] 5d pop ebp
>> [0000131a][00102198][00000000] c3 ret // main() halts
>> Number of Instructions Executed(15900)
>
> It is unsure what is your point? Did you prove that on some narrow case
> you can show of one infinite loop is not halting? That does not ring any bells.
> What you want from us? You have not provided even some meaningful
> algorithm to review and so it is uncertain what you want from software
> engineers. Should we agree that you are a God? That you may have your
> child porn? Whatever. My personal suggestion ... just follow laws of
> your local jurisdiction. Our approval or condemnation does not matter.
>

In the larger picture it does not matter, but also PO has said that if someone here agrees with him
he'll go away! So people who have been asking PO to stop posting here have an obvious way forward:
just say "Peter, you're quite right, we agree with you" and they'll get exactly what they want.


Mike.
(ps, it wouldn't work if I said it - he wouldn't believe me, and also I just couldn't bring myself
to do it.)

[olcott]

On 6/13/2022 12:14 PM, Mike Terry wrote:
> Mike.
> (ps, it wouldn't work if I said it - he wouldn't believe me, and also I
> just couldn't bring myself to do it.)
>
>

In other words you disagree that the following x86 emulation of the
input to H(P,P) meets this criterion measure:

The criterion measure for a simulating halt decider (SHD)
When the correct partial x86 emulation of the input matches a
non-halting behavior pattern such that it correctly determines that a
complete emulation of the input would never stop running, or reach its
“ret” instruction then the SHD aborts its emulation and correctly
returns 0.

#include <stdint.h>
#define u32 uint32_t

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

int main()
{

Output("Input_Halts = ", H((u32)P, (u32)P));
}

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp

[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P

[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp

[0000136c](01) c3 ret

Size in bytes:(0027) [0000136c]

_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6852130000 push 00001352 // push P
[0000137a](05) 6852130000 push 00001352 // push P
[0000137f](05) e81efeffff call 000011a2 // call H
[00001384](03) 83c408 add esp,+08
[00001387](01) 50 push eax
[00001388](05) 6823040000 push 00000423 // "Input_Halts = "
[0000138d](05) e8e0f0ffff call 00000472 // call Output
[00001392](03) 83c408 add esp,+08
[00001395](02) 33c0 xor eax,eax
[00001397](01) 5d pop ebp

[00001398](01) c3 ret
Size in bytes:(0039) [00001398]

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

...[00001372][0010229e][00000000] 55 push ebp
...[00001373][0010229e][00000000] 8bec mov ebp,esp
...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P

...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H

Begin Local Halt Decider Simulation Execution Trace Stored at:212352

// H emulates the first seven instructions of P

...[00001352][0021233e][00212342] 55 push ebp // enter P

...[00001353][0021233e][00212342] 8bec mov ebp,esp
...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]

...[00001358][0021233a][00001352] 50 push eax // push P

...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]

...[0000135c][00212336][00001352] 51 push ecx // push P

...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

// The emulated H emulates the first seven instructions of P

...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P

...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]

...[00001358][0025cd62][00001352] 50 push eax // push P

...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]

...[0000135c][0025cd5e][00001352] 51 push ecx // push P
...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H

Local Halt Decider: Infinite Recursion Detected Simulation Stopped

It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the

seventh instruction of P repeats this process we can know with complete
certainty that the emulated P never reaches its final “ret” instruction,
thus never halts.

...[00001384][0010229e][00000000] 83c408 add esp,+08
...[00001387][0010229a][00000000] 50 push eax
...[00001388][00102296][00000423] 6823040000 push 00000423 //
"Input_Halts = "
---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
Input_Halts = 0
...[00001392][0010229e][00000000] 83c408 add esp,+08
...[00001395][0010229e][00000000] 33c0 xor eax,eax
...[00001397][001022a2][00100000] 5d pop ebp
...[00001398][001022a6][00000004] c3 ret

Number of Instructions Executed(15892) = 237 pages

[Richard Damon]

On 6/13/22 2:45 PM, olcott wrote:
> On 6/13/2022 12:14 PM, Mike Terry wrote:
>> Mike.
>> (ps, it wouldn't work if I said it - he wouldn't believe me, and also
>> I just couldn't bring myself to do it.)
>>
>>
>
> In other words you disagree that the following x86 emulation of the
> input to H(P,P) meets this criterion measure:
>
> The criterion measure for a simulating halt decider (SHD)
> When the correct partial x86 emulation of the input matches a
> non-halting behavior pattern such that it correctly determines that a
> complete emulation of the input would never stop running, or reach its
> “ret” instruction then the SHD aborts its emulation and correctly
> returns 0.

You keep on missing that no such pattern exists in the emulation of
P(P), as if H has a pattern that is seees in P(P) and aborts its
simulation because of that, then when P(P) calls H(P,P) that H will
emulate for a while, abort its emulation, and then return 0 to P which
will Halt.

Thus the P(P) when built with an H with that pattern shows that the
pattern is not a correct non-halting behavior pattern, as a program with
that pattern halts.

So, a SHD based on that rule will just emulate for ever, doing a correct
and complete emulatin, but not giving the 0 answers, because if at any
finite point in time it aborts, it changes P to be Halting.

FAIL.

[olcott]

On 6/13/2022 7:40 PM, Richard Damon wrote:
> On 6/13/22 2:45 PM, olcott wrote:
>> On 6/13/2022 12:14 PM, Mike Terry wrote:
>>> Mike.
>>> (ps, it wouldn't work if I said it - he wouldn't believe me, and also
>>> I just couldn't bring myself to do it.)
>>>
>>>
>>
>> In other words you disagree that the following x86 emulation of the
>> input to H(P,P) meets this criterion measure:
>>
>> The criterion measure for a simulating halt decider (SHD)
>> When the correct partial x86 emulation of the input matches a
>> non-halting behavior pattern such that it correctly determines that a
>> complete emulation of the input would never stop running, or reach its
>> “ret” instruction then the SHD aborts its emulation and correctly
>> returns 0.
>
> You keep on missing that no such pattern exists in the emulation of
> P(P),

Even Flibble see the pattern.

[Richard Damon]

On 6/13/22 8:47 PM, olcott wrote:
> On 6/13/2022 7:40 PM, Richard Damon wrote:
>> On 6/13/22 2:45 PM, olcott wrote:
>>> On 6/13/2022 12:14 PM, Mike Terry wrote:
>>>> Mike.
>>>> (ps, it wouldn't work if I said it - he wouldn't believe me, and
>>>> also I just couldn't bring myself to do it.)
>>>>
>>>>
>>>
>>> In other words you disagree that the following x86 emulation of the
>>> input to H(P,P) meets this criterion measure:
>>>
>>> The criterion measure for a simulating halt decider (SHD)
>>> When the correct partial x86 emulation of the input matches a
>>> non-halting behavior pattern such that it correctly determines that a
>>> complete emulation of the input would never stop running, or reach
>>> its “ret” instruction then the SHD aborts its emulation and correctly
>>> returns 0.
>>
>> You keep on missing that no such pattern exists in the emulation of P(P),
>
> Even Flibble see the pattern.
>
>

Can you point to the message where he actually says that? (since he
realized that halt decider doesn't actually need to simulate its input,
only does it by choise in your case)

[Paul N]

OK, I'll bite. Apologies to all those who would rather this conversation was not here.

Firstly, I think it needs to be said that the Halting Problem only applies to an infinite machine. If a computer has only a finite number of states (as so many of them do) and moves between them at a constant rate, then a suitable emulator could work out whether a program terminates simply by looking for a repeated state. Either the program terminates, or after N states you must be back to a state you have already had, where N is the number of possible states. This may be where Mr Olcott is going wrong.

This is a conditional jump past the next instruction

> [00001369](02) ebfe jmp 00001369

Yes, if the program gets to this line, it will go into an infinite loop. We can't tell just from this code whether or not this will happen, as it is dependent on the jump above which is dependent on H, which you haven't shown us (at least not in this post), so the code itself does not answer the question.

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. But does the computer itself know this? If the emulator simply emulates the instructions given, it will not realise that it is doing the same thing over and over again. If it does look out for this, spotting a repeated state, then it can tell that the program under consideration will not halt. The answer to whether it spots this lies in the emulator, which you haven't shown the code for.

However, an emulator which does this is not accurately emulating the program in question. The emulator is stopping and saying it has found an infinite loop, whereas the program itself would do no such thing and would run forever. Thus their behaviours are different.

You say that you have come to comp.lang.c and comp.lang.c++ is to check the points which relate to the language. I think what I have written above is probably about as much as you will be able to get from these groups. Your understanding of the language points appears to be correct.

[olcott]

H knows this and returns 0 on the basis.

> If the emulator simply emulates the instructions given, it will not realise that it is doing the same thing over and over again.

H has code that recognizes infinite behavior patterns.

> If it does look out for this, spotting a repeated state, then it can tell that the program under consideration will not halt. The answer to whether it spots this lies in the emulator, which you haven't shown the code for.
>

I have re-engineered the code to make it a pure function of its inputs.
Not knowing how to do this prevented me from publishing the code.

I have updated the algorithm so that it is a pure function of its
inputs. As soon as P calls H for the first time, H (knowing its own
machine address) is able to look though the prior execution trace and
see that P is calling H with the same arguments that it was called
with and there are no instructions in P that would break this cycle.

> However, an emulator which does this is not accurately emulating the program in question. The emulator is stopping and saying it has found an infinite loop, whereas the program itself would do no such thing and would run forever. Thus their behaviours are different.
>

The criterion measure for a simulating halt decider (SHD)
When the correct partial x86 emulation of the input matches a
non-halting behavior pattern such that it correctly determines that a
complete emulation of the input would never stop running, or reach its
“ret” instruction then the SHD aborts its emulation and correctly
returns 0.

> You say that you have come to comp.lang.c and comp.lang.c++ is to check the points which relate to the language. I think what I have written above is probably about as much as you will be able to get from these groups. Your understanding of the language points appears to be correct.

Yes you did a very excellent job thanks.
Thus you agree that H(P,P)==0 is correct.

[Mut...@dastardlyhq.com]

On Tue, 14 Jun 2022 04:47:35 -0700 (PDT)
Paul N <gw7...@aol.com> wrote:
>OK, I'll bite. Apologies to all those who would rather this conversation wa=
>s not here.
>
>Firstly, I think it needs to be said that the Halting Problem only applies =
>to an infinite machine. If a computer has only a finite number of states (a=
>s so many of them do) and moves between them at a constant rate, then a sui=
>table emulator could work out whether a program terminates simply by lookin=
>g for a repeated state. Either the program terminates, or after N states yo=
>u must be back to a state you have already had, where N is the number of po=

That only holds if there's no external input which cannot be known in advance
that can affect its state.

[olcott]

P is the input to H and P is the input to P.
H uses a very powerful open source x86 emulator top emulate its input.

The criterion measure for a simulating halt decider (SHD)
When the correct partial x86 emulation of the input matches a
non-halting behavior pattern such that it correctly determines that a
complete emulation of the input would never stop running, or reach its
“ret” instruction then the SHD aborts its emulation and correctly
returns 0.

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

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

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

[00001369](02) ebfe jmp 00001369

[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

[Juha Nieminen]

Paul N <gw7...@aol.com> wrote:
> Firstly, I think it needs to be said that the Halting Problem only
> applies to an infinite machine. If a computer has only a finite
> number of states (as so many of them do) and moves between them at a
> constant rate, then a suitable emulator could work out whether a
> program terminates simply by looking for a repeated state. Either
> the program terminates, or after N states you must be back to a
> state you have already had, where N is the number of possible
> states. This may be where Mr Olcott is going wrong.

It is my understanding that whenever a question is posed about an algorithm
or program in theoretical computer science, failure states caused by the
running environment (eg. running out of RAM) are not part of the scenario,
because that's irrelevant to the question at hand. In other words, we can
always assume there's no external factor interfering with the program.

For example, if the question is what's the computational complexity of a
particular sorting algorithm, the question always assumes that the running
environment doesn't pose any physical limits (eg. on memory amount). The
question becomes a bit meaningless if we had to assume some upper limit
in the running environment.

Rather obviously the famous Halting Problem isn't asking if a program will
halt or run forever in an x86-64 PC with 32 GB of RAM. That would make the
question meaningless.

Likewise if we are asking "does a program testing the Collatz conjecture
eventually end when it finds a counter-example?" we are not asking
"does the program eventually end with an 'out of memory' error because
it's being run in a computer with limited RAM?"

Incidentally, if the halting problem were answerable, that would
automatically solve some of the biggest mathematical conjectures
out there (like the Collatz conjecture).

[olcott]

There is a difference between undecidable:
Neither Boolean value is correct because the decision problem is
self-contradictory

and undecided: The decision problem requires information that is
currently unavailable.

[Keith Thompson]

Paul N <gw7...@aol.com> writes:
> OK, I'll bite. Apologies to all those who would rather this conversation was not here.

olcott dominates comp.theory. You can interact with him there. You can
also see multiple years of his posting history.

[olcott]

On 6/14/2022 12:12 PM, Keith Thompson wrote:
> Paul N <gw7...@aol.com> writes:
>> OK, I'll bite. Apologies to all those who would rather this conversation was not here.
>
> olcott dominates comp.theory. You can interact with him there. You can
> also see multiple years of his posting history.
>

The people on comp.theory are unable to critique my work an the basis of
software engineering:

To fully understand this paper 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.

[Albert Arkwright]

On 14/06/2022 18:21, olcott wrote:
>
> The people on comp.theory are unable to critique my work an the basis
> of software engineering:
>
>
>
>
>

They are too smart for you. They have known you for years and you are on
their kill-file for too long. It is a matter of time that C and C++
programmers will come to understand you more here and kill-file you
after they have reported you to "ab...@giganews.com". Enough is enough
and there is a limit how much they can take your crap.

[olcott]

Only people that baselessly reject what I say out-of-hand without review
come to that conclusion. Anyone that correctly reviews my claim
validates that it is correct.

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.

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

void P(ptr x)

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

int main()
{

Output("Input_Halts = ", H(P, P));

}

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

[00001369](02) ebfe jmp 00001369

[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the

seventh instruction of P repeats this process we know with complete

certainty that the correct and complete emulation of P by H would never
reach the final “ret” instruction of P, thus never halts.

[Richard Damon]

And the emulation is shown to be incorrect here, as a call 000011a2
should be followed by the instruction at 000011a2.

>>>
>>> // The emulated H emulates the first seven instructions of P

Which is done CONDITIONALLY, and thus the detection of infinite
recursion is incorrect.
The emulated H will abort its own emulation too, so the CORRECT
emulation of the input to H (which doesn't abort as H does, but still
has the input call the H that does) will see the input halt.

Which is incorrect, since the code in H that P calls is part of the
PROGRAM P, and does contain the needed code to break the loop.

THus, your H does NOT "Correct" emulate its input, since it should know
that that point that the call to H(P,P) will return a 0, since that is
what it is about to do.

>
>> However, an emulator which does this is not accurately emulating the
>> program in question. The emulator is stopping and saying it has found
>> an infinite loop, whereas the program itself would do no such thing
>> and would run forever. Thus their behaviours are different.
>>
>
> The criterion measure for a simulating halt decider (SHD)
> When the correct partial x86 emulation of the input matches a
> non-halting behavior pattern such that it correctly determines that a
> complete emulation of the input would never stop running, or reach its
> “ret” instruction then the SHD aborts its emulation and correctly
> returns 0.
>

Right, a CORRECT EMULATION of the input, even when the SHD doesn't do a
correct emulation because it stops part way (which is not correct).

Note also, the pattern you THINK in a non-halting behavior pattern is
proved to NOT be a non-halting behavior pattern, as a correct emulation
of the input will see P(P) call H(P,P) and then H(P,P) detecting that
pattern and returning 0 to the calling P(P) which then halts.

[olcott]

On 6/14/2022 6:47 AM, Paul N wrote:

*I have been very sick in the hospital since Monday*

This is probably the last question that I need to ask here:

*No one else will give me an honest answer to this*
Now we need to determine if H(P,P) correctly reports that its input
would never reach its "return" instruction.

The infinite simulation detector has been adapted from the infinite
recursion detector.

typedef void (*ptr)();
int H(ptr p, ptr i); // simulating halt decider

void P(ptr x)
{
int Halt_Status = H(x, x);
if (Halt_Status)

HERE: goto HERE;
return;
}

int main()
{

Output("Input_Halts = ", H(P, P));
}


*Halting problem proofs refuted on the basis of software engineering* ?
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering