On Thursday, 14 July 2022 at 03:37:13 UTC+8, olcott wrote:
> On 7/13/2022 1:03 PM, Paul N wrote:
> > On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:
> >> On 7/13/2022 10:02 AM, Paul N wrote:
> >>> Firstly, this subject matter is not relevant in comp.lang.c or comp.lang.c++, so please stop posting any of it there. If I see any more posts of this sort in either of those newsgroups I shall assume that, regardless of the merits of your argument, you are very rude.
> >>>
> >>> On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote:
> >>>> *CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
> >>>>
> >>>> I rewrote this question so that a software engineer of ordinary skill
> >>>> can easily verify that the simulated P does call H in what is
> >>>> essentially infinite recursion. **This simplification is the result of
> >>>> an extensive review (23 emails) by a leading computer scientist over the
> >>>> weekend.**
> >>>
> >>>> Does H(P,P) correctly determine the halt status of the halting problem's
> >>>> pathological input?
> >>>
> >>>> The following H and P have the above specified pathological relationship
> >>>> to each other.
> >>>>
> >>>> typedef void (*ptr)();
> >>>> int H(ptr p, ptr i);
> >>>>
> >>>> void P(ptr x)
> >>>> {
> >>>> if (H(x, x))
> >>>> HERE: goto HERE;
> >>>> return;
> >>>> }
> >>>>
> >>>> int main()
> >>>> {
> >>>> Output("Input_Halts = ", H(P, P));
> >>>> }
> >>>>
> >>>> Simulating halt decider H detects that its simulated input is
> >>>> essentially calling H in infinite recursion. H aborts its simulation on
> >>>> this basis and rejects this input as non-halting.
> >>>
> >>> Thus it is an incorrect assessment, as we'll see below.
> >>>
> >>>> *Once this halt deciding principle is accepted*
> >>>> A halt decider must compute the mapping from its inputs to an accept or
> >>>> reject state on the basis of the actual behavior that is actually
> >>>> specified by these inputs.
> >>>
> >>> Again, emphasis on "actual behaviour".
> >>>
> >>>> *Then (by logical necessity) this is understood to implement that*
> >>>> Every simulating halt decider that correctly simulates its input until
> >>>> it correctly predicts that this simulated input would never terminate
> >>>> normally, correctly rejects this input as non-halting.
> >>>
> >>> You have stated numerous times that a program that "correctly simulates its input" can have different results. Thus it is not clear what you mean by the phrase. There is no logical necessity to accept anything about a correct simulation which does not simulate correctly.
> >>>
> >>>> *The execution trace of function P() simulated by function H() shows*
> >>>> (1) Function H() is called from P().
> >>>> (2) With the same parameters to H().
> >>>> (3) With no instructions in P() that could possibly escape this
> >>>> infinitely recursive simulation.
> >>>
> >>> Ah, but there are instructions in H which escape from the infinite recursion. You've said numerous times that there are. See only a few lines up.. If you pretend that they are somehow not there, you are not correctly simulating H and hence not correctly simulating P which calls it.
> >>>
> >>>> This proves that H(P,P) correctly predicts that its correctly simulated
> >>>> input would never terminate normally.
> >>>
> >>> As you've said above, in capitals and with asterisks, changing the subject is not a rebuttal. You're trying to change the subject from the actual behaviour of P(P) to some sort of "simulated" behaviour of P(P) which you have said yourself is different.
> >> Welcome back.
> >>
> >> When H(P,P) correctly simulates its input this is the ultimate measure
> >> of the actual behavior specified by this input.
> >
> > No, the actual behaviour is the actual behaviour! If H correctlky simulates this behaviour then it too will also be the same, but you have siad numerous times that it does not correctly simulate the behavoutr.
> >
> It is an easily verified fact that H(P,P) correctly simulates its input
> to everyone having sufficient knowledge of the x86 assembly language
> which currently seems to be hardy no one besides me. Back in the 1986
> when I began my career about 10% of all programmers had familiarity
> with the x86 language. This is the language that MSDOS and versions
> of MS Windows prior to Windows NT were written in. Windows NT switched
> to mostly C/C++.
>
> The 23 emails that I had with a leading computer scientist made that
> very clear. Because of this I re-framed my explanation so that any
> expert C programmer that totally understands infinite recursion would be
> able to see that infinitely nested simulation is essentially the same
> thing.
>
> The next important point that requires one to have top software
> engineering skills that allowed me to transform H into a pure thus
> computable function: Infinitely nested simulation can be detected the
> first time that the simulated input calls the simulator with its same
> arguments. Infinite recursion requires seeing two such calls in a row.
> This change allowed me to discard the need for static local memory and
> do everything in local memory.
> >> A security guard at the front door is only required to validate people
> >> coming in the front door the actual behavior of the actual input to H(P,P).
> >>
> >> This same security guard is not required to validate people coming in
> >> the back door the direct execution of P(P). Unless a computation is
> >> specified as an actual input to H it is not in the domain of the
> >> computable function that H implements.
> >
> > H takes two arguments. The first is a program to be considered and the second is the input that could be supplied to that program. H is required to decide, correctly, whether the program would halt given that input, ie whether M(X) would halt.
> No this a very long standing misconception. H is required to determine
> whether or not its correct simulation of its input would ever reach the
> normal termination of this input.
>
> Since no one ever bothered to think through the application of a
> simulating halt decider to the HP's impossible inputs they always stated
> the requirements incorrectly never realizing their mistake.
> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior that is actually
> specified by these inputs.
> In the H/P concrete example it is easily proven that the actual behavior
> of the actual input to H(P,P) is not the behavior of the directly
> executed P(P). The best proof of this is the x86 execution trace of each
> that precisely corresponds to what the x86 source code of P specifies.
>
> From this is is obvious that the correctly simulated P cannot possibly
> terminate normally and the executed P(P) halts.
>
> Those lacking knowledge of the x86 language can understand that this
> first halt deciding principle is necessarily correct:
>
> *When this halt deciding principle understood to be correct*
> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior that is actually
> specified by these inputs.
> And this second halt deciding principle follows from the first one by
> logical necessity.
>
> *Then (by logical necessity) this implements that principle*
> Every simulating halt decider that correctly simulates its input until
> it correctly predicts that this simulated input would never terminate
> normally, correctly rejects this input as non-halting.
>
> >
> > If a program M would halt given input X, then H(M, X) is required to be non-zero.
> > If a program M would not halt given input X, then H(M, X) is required to be zero.
> >
> This is a misconception that can only be true if the halt decider is
> required to report on something besides the actual behavior of its
> actual input.
>
> The ultimate measure of the actual behavior of the actual input is the
> provable correct simulation of this input by the simulating halt decider.
>
> To assume that this behavior must be the same as the directly executed
> P(P) after it has been conclusively proven to not be that same as an
> established fact is at least a little nutty.
>
> That people unequivocally state that I must be wrong entirely on the
> basis that they lack sufficient understanding of the x86 language to
> understand my proof is a worst case example of the ad ignorantiam logic
> error.
> > If for some combination M, X the function H(M, X) gives the wrong answer, then it is not a halt decider. If particular, if H(M, X) = 0 but M(X) does halt, then the answer is wrong. You can't get out of it by arguing that M(X) is "direct" and H(M, X) is a "correct simulation", whatever that might mean. The answer needs to relate to the actual behaviour, as you yourself have said numerous times.
> >
> > Thus if P(P) halts, H(P, P) is required to be non-zero. If P(P) does not halt, H(P, P) is required to be zero. Anything else is the wrong answer.
> >
> > When we calculate H(P, P), we are supplying P as the first argument and so P is specified as an actual input to H. And we are interested in the actual behaviour of P, the actual input. There is no "back door" by which you can say that P(P) is not the function and input we are talking about.
> >
> >>> To summarise, if H(P, P) terminates (which you have never denied), then there are at most four possibilities:
> >>>
> >>> A) H(P, P) returns 0 and P(P) terminates.
> >>> B) H(P, P) returns non-zero and P(P) terminates.
> >>> C) H(P, P) returns 0 and P(P) does not terminate.
> >>> D) H(P, P) returns non-zero and P(P) does not terminate.
> >>>
> >>> B and C are clearly not possible from the definition of P. In A and D, H produces the wrong answer.
> >
> >> A1) H(P, P) returns 0 because it correctly determines that the input
> >> that it correctly simulates would never terminate normally.
> >
> > No, that is not a correct answer. You have said numerous times that P(P) terminates.
> >
> >> A2) Directly executed P(P) halts because of (A)
> --
> Copyright 2022 Pete Olcott
>
> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer

Halting problem https://en.wikipedia.org/wiki/Halting_problem
....the halting problem is the problem of determining, from a description of an arbitrary
computer program and an input, whether the program will finish running, or continue to run forever.

The property that an arbitrary program P will finish running or not is determined by
running P as an independent program (or implemented as a TM. this is the real
meaning of P), not interpreted through any random "simulating halt decider"..

POOH::= ...H is required to determine whether or not its correct simulation of
its input would ever reach the normal termination of this input.
.... the actual behavior of the actual input to H(P,P) is not the behavior of
the directly executed P(P).
(Note: This is just one of several versions of POOH)

GUR had revealed several times, even God can not solve the Halting Problem.
Your "exhaustive trial" is amazing. But by now, I think no one can provide more
useful info. for you to 'plagiarism' to revise/finish your patent.
Surrender my GUR, you might be saved from your Lake Of Fire (plus stoned).