On 7/14/22 3:56 PM, olcott wrote:
> On 7/14/2022 6:42 AM, Paul N wrote:
>> On Wednesday, July 13, 2022 at 8:37:13 PM UTC+1, 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 correctly
>>>> simulates this behaviour then it too will also be the same, but you
>>>> have said numerous times that it does not correctly simulate the
>>>> behaviour.
>>>>
>>> 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++.
>>
>> No it is not. Firstly, you have never posted the code to H so of
>> course we can't verify it.
>
> The latest rewrite of my paper (initially written as a reply to you) can
> be fully understood at the C level with no need to have any access to
> the source-code of H. I will publish all the the source-code very soon,
> yet not until after my work has been validated.
>
> The source-code is correct and complete yet must be refactored to clean
> it up before publication.
>
> *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
>
>
>> Furthermore, you yourself claim that the simulation gives different
>> results from the actual code (you even describe this as "provably" on
>> occasion) so you yourself do not believe that H(P,P) correctly
>> simulates its input.
>
> This is also much more clearly shown in the rewrite of my paper that I
> did a few minutes ago. It can now be seen at the C level that the
> simulation of the input to H(P,P) is correct.
>
> It was very easy to see that the simulation of the input to H(P,P) is
> correct by simply matching the execution trace of the simulated P to its
> x86 source code. I annotated the x86 source-code to make this much
> easier for C programmers. I explain line-by-line exactly how the x86
> code corresponds to its C source.
>
>>
>>> 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.
>>
>> It might move the conversation on if you showed us what the computer
>> scientist said - most helpfully if you quoted verbatim, but you could
>> paraphrase if you're worried about confidentiality or the like. I take
>> it there was more to it than them saying why you were wrong, and you
>> saying that they didn't understand?
>
> This would be disrespecting his privacy. The point is that I now have an
> excellent measure that I have improved my words so much that my work is
> not simply rejected out-of-hand without review even by leading computer
> scientists.
>
>>> 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.
>>
>> No, what I have said is right. You are the one bringing in ideas about
>> simulation.
>>
>
> 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.
>
> It is common knowledge that a correct simulation of a program is a
> correct measure of the behavior of this program.
>
> If we accept that the behavior of the executed P(P) is the behavior that
> H must report on then we are saying that H must report on the behavior
> that is not the actual behavior of its actual 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.
>>
>> Yes.
>>
>>> 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.
>>
>> You've included the word "actual" twice in that sentence and yet you
>> still seem to think that the actual behaviour is not what really
>> happens. How many "actual"s do you need?
>>
>>>  From this is is obvious that the correctly simulated P cannot possibly
>>> terminate normally and the executed P(P) halts.
>>
>> If P(P) halts then a correct simulation of it will also halt.
>
> In the latest revision to my paper it is much more obvious that that
> actual behavior of the actual input is not the same as the behavior of
> the directly executed P(P).
>
> If H is required to report on the behavior of the direct execution of
> P(P) this forces H to report on something besides the actual behavior of
> its actual input.
>

No, because the input P, P exactly specifies all the behavior or P(P).

If H(P,P) doesn't represent P(P), then H just isn't a Halting Decider.

FAIL.

> rewritten a few minutes ago to be much easier to understand:
> *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
>
>
>