Can software engineers please critique this?

[olcott]

Criterion Measure of a simulating halt decider proving that H(P,P)==0

*The criterion measure for a simulating halt decider SHD*
When the correct partial simulation of the input matches a non-halting
behavior pattern such that it correctly determines that a complete
simulation of the input would never stop running, or reach the final
state of this input then the SHD aborts its simulation and correctly
returns 0.

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

*H and P match the above halting problem relationship to each other*

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.




Halting problem undecidability and infinitely nested simulation (V5)

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

--
Copyright 2022 Pete Olcott

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

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

[olcott]

On 6/12/2022 11:41 AM, olcott wrote:
> Criterion Measure of a simulating halt decider proving that H(P,P)==0
>

*Rewritten for software engineers*

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

[Mr Flibble]

I would advise any "software engineers" to not to critique this because
PO will just end up calling you incompetent, shit for brains, or worse.

/Flibble

[olcott]

You can't even understand the concept of unreachable code.

[Mr Flibble]

I can understand the concept of unreachable code:

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

Now fuck off you fucktarded spunk bucket.

/Flibble

[Mr Flibble]

On Sun, 12 Jun 2022 11:41:06 -0500
olcott <No...@NoWhere.com> wrote:

By your own admission the H you invoke from main() returns a value
whilst the H you invoke from P does not so they are not the same H. A
halt decider, H, must always return a value to its caller for it to
qualify as a halt decider.

/Flibble

[Mr Flibble]

[Freethinker]

qed

[olcott]

I have proven that Flibble does understand unreachable code, that you
ignored this proof is no rebuttal.

[Mr Flibble]

Of course I understand what constitutes unreachable code:

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

All you can do is lie at this point as you've got nothing.

/Flibble

[Freethinker]

I was referring to Flibble's statement having been conclusively proven
by your reply, which now makes it a theorem!

[Juha Nieminen]

olcott <No...@nowhere.com> wrote:
> On 6/12/2022 11:41 AM, olcott wrote:
>> Criterion Measure of a simulating halt decider proving that H(P,P)==0
>>
>
> *Rewritten for software engineers*

When it comes to theoretical computer science, you might want to ask
computer scientists rather than software engineers. *Sometimes* those
two coincide but not nearly always.

[olcott]

I only want this question answered from a software engineering point of
view.

[Albert Arkwright]

On 13/06/2022 22:10, olcott wrote:
>
> I only want this question answered from a software engineering point
> of view.
>

They have told you many times that you were correct all along and you deserve
a Nobel price for your work. This is the opinion of all Software
Engineers on these news groups.

Does this help you to retire peacefully and do something else. How about
going to United States and give lectures about your work. You are a
genius and people would love to hear from you in person about your work.

[olcott]

On 6/13/2022 4:54 PM, Albert Arkwright wrote:
> On 13/06/2022 22:10, olcott wrote:
>>
>> I only want this question answered from a software engineering point
>> of view.
>>
>
> They have told you many times that you were correct all along and you
> deserve a Nobel price for your work. This is the opinion of all Software
> Engineers on these news groups.
>

It must be a careful and sincere point by point analysis.

[olcott]

On 6/13/2022 3:46 PM, Juha Nieminen wrote:

The very weird problem in this case is that software engineering has
caught a very subtle mistake that computer science textbooks have been
making regarding the halting problem. My paper details this mistake in
Appendix I.

Without getting into the details that are outside of the scope of this
forum all that I really need here is a step-by-step confirmation that
H(P,P) correctly determines that the correct x86 emulation of its input
would never reach the "ret" instruction of this input.
*I know that it is already as obvious as Hell*

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

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

[Mut...@dastardlyhq.com]

Software engineer usually implies some form of CS knowledge/training whereas
programmer or worse coder usually means someone self taught or moved over
from another area with no formal training. Though as with most definitions
its various shades of grey.

These days though with every 3rd idiot trying to "code" (ie write some mickey
most HTML/javascript) because they keep getting told it by vested interests
wanting to sell their latest low/no-code software or clueless government types
trying to push unsuitable people into IT we're going to find ever more of
them in the industry with ever lower software standards.

[olcott]

Here are the detailed required credentials:
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.

[Mut...@dastardlyhq.com]

On Tue, 14 Jun 2022 09:23:15 -0500
olcott <No...@NoWhere.com> wrote:
>the x86 programming language

Most people call it assembler. But I guess you have to be different.

[olcott]

Most specifically is the the x86 assembly language contained in the COFF
object files that are generated by the Microsoft C compiler when
executed in 32-bit mode. The x86utm operating system that I wrote takes
a 32-bit mode COFF object file as input.

[Mut...@dastardlyhq.com]

On Tue, 14 Jun 2022 10:53:51 -0500
olcott <No...@NoWhere.com> wrote:
>On 6/14/2022 10:26 AM, Mut...@dastardlyhq.com wrote:
>> On Tue, 14 Jun 2022 09:23:15 -0500
>> olcott <No...@NoWhere.com> wrote:
>>> the x86 programming language
>>
>> Most people call it assembler. But I guess you have to be different.
>>
>>
>
>Most specifically is the the x86 assembly language contained in the COFF
>object files that are generated by the Microsoft C compiler when
>executed in 32-bit mode. The x86utm operating system that I wrote takes
>a 32-bit mode COFF object file as input.

Thats not a language, thats machine code.

[olcott]

I adapted the x86 emulator to dis-assemble the machine language so that
all the x86 source in the whole COFF file can be seen. The x86 execution
trace also shows the x86 source-code of every line that is emulated.

[Juha Nieminen]

Mut...@dastardlyhq.com wrote:
>>When it comes to theoretical computer science, you might want to ask
>>computer scientists rather than software engineers. *Sometimes* those
>>two coincide but not nearly always.
>
> Software engineer usually implies some form of CS knowledge/training whereas
> programmer or worse coder usually means someone self taught or moved over
> from another area with no formal training. Though as with most definitions
> its various shades of grey.

I think "software engineer" usually refers to a job title, not an acadmic
title (those would be MSc, PhD, etc.)

It's perfectly possible to be a really competent software engineer and have
absolutely no idea what "computational complexity" means.

[daniel...@gmail.com]

On Tuesday, June 14, 2022 at 12:57:54 PM UTC-4, Juha Nieminen wrote:
>
> It's perfectly possible to be a really competent software engineer and have
> absolutely no idea what "computational complexity" means.

The word "engineer" has unfortunately been much debased in the computer
industry, particularly with that absurd title "Microsoft Solution Engineer".
Real engineers were actually personally responsible for their work.

Daniel

[olcott]

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.

[red floyd]

Please remove comp.lang.c++ from this thread. It is off topic and
clogging up c.l.c++. Thank you.

[Mr Flibble]

On Tue, 14 Jun 2022 11:41:22 -0500

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

> On 6/14/2022 11:00 AM, Mut...@dastardlyhq.com wrote:
> > On Tue, 14 Jun 2022 10:53:51 -0500
> > olcott <No...@NoWhere.com> wrote:
> >> On 6/14/2022 10:26 AM, Mut...@dastardlyhq.com wrote:
> >>> On Tue, 14 Jun 2022 09:23:15 -0500
> >>> olcott <No...@NoWhere.com> wrote:
> >>>> the x86 programming language
> >>>
> >>> Most people call it assembler. But I guess you have to be
> >>> different.
> >>>
> >>>
> >>
> >> Most specifically is the the x86 assembly language contained in
> >> the COFF object files that are generated by the Microsoft C
> >> compiler when executed in 32-bit mode. The x86utm operating system
> >> that I wrote takes a 32-bit mode COFF object file as input.
> >
> > Thats not a language, thats machine code.
> >
>
> I adapted the x86 emulator to dis-assemble the machine language so
> that all the x86 source in the whole COFF file can be seen. The x86
> execution trace also shows the x86 source-code of every line that is
> emulated.

Disassembly isn't source code. Also, it is quite telling when you say
"no knowledge of the halting problem is required": this is correct as
what you have has nothing to do with the halting problem as your H
isn't a halting decider: it is an olcott simulation detector, a fairly
useless widget.

/Flibble

[olcott]

I really need the C/x86 software engineering to be reviewed here.
That is all that I need from this forum.

[Chris Vine]

On Tue, 14 Jun 2022 12:53:16 -0500
olcott <No...@NoWhere.com> wrote:
> On 6/14/2022 12:44 PM, red floyd wrote:
> > On 6/13/2022 1:46 PM, Juha Nieminen wrote:
> >> olcott <No...@nowhere.com> wrote:
> >>> On 6/12/2022 11:41 AM, olcott wrote:
> >>>> Criterion Measure of a simulating halt decider proving that H(P,P)==0
> >>>>
> >>>
> >>> *Rewritten for software engineers*
> >>
> >> When it comes to theoretical computer science, you might want to ask
> >> computer scientists rather than software engineers. *Sometimes* those
> >> two coincide but not nearly always.
> >
> > Please remove comp.lang.c++ from this thread.  It is off topic and
> > clogging up c.l.c++.  Thank you.
>
> I really need the C/x86 software engineering to be reviewed here.
> That is all that I need from this forum.

So "that is all that I need from this forum". Great, you have had your
reviews, you don't agree with them, so you can now go somewhere else.
No point in hanging around.

[olcott]

I have had only one accurate and honest review, every other reply was
one excuse or another for refusing to make a review, just like you are
doing.

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.

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

[Chris Vine]

On Tue, 14 Jun 2022 14:57:03 -0500
olcott <No...@NoWhere.com> wrote:
> I have had only one accurate and honest review, every other reply was
> one excuse or another for refusing to make a review, just like you are
> doing.

Here's a review, which I believe to be accurate and honest, namely that
you are suffering from an obsessive disorder. One effect is that it is
not possible to discuss anything with you: you are incapable of
accepting any view but your own. And I mean "incapable" - your mental
apparatus does not allow it to you.

[olcott]

If that was true then the one reviewer that did review my work correctly
would not have been able to do this.

[Freethinker]

Which "mental apparatus" do you mean? I would go to the extent of saying
this is by far the craziest I have seen in my life. It even surpasses
Bonita.

[olcott]

It is crazy to say that requesting a review of this material is crazy:

[Chris Vine]

On Tue, 14 Jun 2022 15:27:02 -0500
olcott <No...@NoWhere.com> wrote:
> On 6/14/2022 3:04 PM, Chris Vine wrote:
> > On Tue, 14 Jun 2022 14:57:03 -0500
> > olcott <No...@NoWhere.com> wrote:
> >> I have had only one accurate and honest review, every other reply was
> >> one excuse or another for refusing to make a review, just like you are
> >> doing.
> >
> > Here's a review, which I believe to be accurate and honest, namely that
> > you are suffering from an obsessive disorder. One effect is that it is
> > not possible to discuss anything with you: you are incapable of
> > accepting any view but your own. And I mean "incapable" - your mental
> > apparatus does not allow it to you.
>
> If that was true then the one reviewer that did review my work correctly
> would not have been able to do this.

One thing puzzling about you is your inability to sustain a logical
argument. Whatever mental disorder you may or may not have does not
mean that someone might think your arguments are right. Nor does the
fact that someone might think that your arguments are right mean that
they are right nor that you have no obsessive disorder.

Out of interest, who is this mystery person who has reviewed your work
correctly?

[Chris M. Thomasson]

Perhaps Dr Feelgood reviewed his work?

https://youtu.be/trGX3ET3jTQ

Humm... At least it might of been a Doctor...

[olcott]

If it was not for jackass replies such as the I would not have needed to
overwhelm this forum with my messages.

If three people would have provided accurate and honest reviews I would
have been done right there after four total messages.

This could have occurred on comp.theory a year ago.

That it took a year dozens of forums and one hundred reviewers and many
thousands of messages before one person would provide one accurate
review of a perfectly reasonable question multiplied rather than
dissipated my persistence.

[Chris Vine]

On Tue, 14 Jun 2022 20:55:16 -0500

That's not how obsessive disorders work. I doubt that anything will
dissipate your persistence, while there are people who disagree with
you.

But you have not answered the question. Who is the mystery person who

[olcott]

Every competent software engineer here knows that when H(P,P) correctly
emulates its input with an x86 emulator that the correct and complete
emulation would never reach the "ret" instruction of P. No one can
possibly show otherwise because it is an easily verifiable fact.

[Mike Terry]

I'm hoisting the name "Paul N" up the flagpole to see if anyone salutes!

Perhaps his post in this newsgroup Tue, 14 Jun 2022 11:47:35 (UTC). It seems about right timing for
when PO started talking about it, and there's PO's response:

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

It's not clear whether Paul actually does agree with that - but remember that PO is absolutely
desperate for any sign of someone agreeing with him on anything, and he is well known for
misinterpretting what other people are saying and plastering it over the newsgroup. (He's done it
to me more than once...)

Or perhaps Paul does agree, it doesn't really matter - it could be like when PO went to one of the
x86 newsgroups with a somewhat similar trace and asked the guys there what's going on with his
program? Note: zero context provided! PO could well have been some programming newbe who's never
seen a loop before! And deliberately no explanation as to what the trace was - it looks like an x86
processor trace, but of course it's not; it's some kind of merged emulation trace where the
successive calls to H ARE BY DIFFERENT x86 processors each with their own state!! So anyway,
someone there suggests "...your program is looping..." and that's enough for PO - one of his claims
verified! :)

Or maybe it's not Paul, it's just my guess. (I don't see it mattering who the person is - PO loves
his appeals to 3rd party authorities, thinking that means he's "won" some bit of his argument, so
nobody's allowed to discuss that anymore! Nobody else accepts that of course.)

Mike.

[olcott]

It is dead obvious to every competent software engineer that the correct
and complete x86 emulation of the input to H(P,P) would never reach its
"ret" instruction.

I am redirecting all messages back to comp.theory

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

[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx

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