On 7/15/2022 11:17 AM, Paul N wrote:
> On Friday, July 15, 2022 at 3:35:47 PM UTC+1, olcott wrote:
>> On 7/15/2022 7:34 AM, Paul N wrote:
>>> On Thursday, July 14, 2022 at 8:56:21 PM UTC+1, 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.
>>>
>>> I see you have now started a new thread on this very subject in both comp.lang.c and comp.lang.c++. You clearly 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).
>>>
>>> Did your expert in any way agree that the "actual behaviour" is different from the behaviour when P(P) is directly executed? Have you found anyone at all who agrees with you on this point?
>> At the time my proof was only written in x86 assembly language and he
>> had no knowledge of x86 assembly language Now it can be understood in C.
>>>
>>>> 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.
>>>
>>> Do you accept that if H were required to report on the behaviour of the direct execution of P(P) then it would not be possible to write such an H?
>> That would require H to be a mind reader and report on something other
>> than the actual behavior of its actual input.
>
> There's no mind involved. If P is a computer program then P(P) is perfectly well defined. Either H can work out what it will do, or it can't.

It is like you ask your wife to go to the store and buy "a dozen eggs"
fully expecting her to understand that what you mean by "a dozen eggs"
is {a half gallon of grape juice}. When she gets back with the eggs you
ask her where is the grape juice?

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.

>
>> I spent about three hours in my reply to you, how much time did you
>> spend three minutes?
>>>
>>>> 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

--
Copyright 2022 Pete Olcott

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