On 7/16/22 4:12 PM, olcott wrote:
> On 7/16/2022 2:28 PM, Mike Terry wrote:
>> On 16/07/2022 17:40, Richard Damon wrote:
>>> On 7/16/22 11:54 AM, Mike Terry wrote:
>>>> On 16/07/2022 12:23, Paul N wrote:
>>>>> On Friday, July 15, 2022 at 5:26:49 PM UTC+1, olcott wrote:
>>>>>> 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:
>>>>>>>>> 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.
>>>>>
>>>>> You haven't said in what way a "mind" is involved in the direct
>>>>> execution of P(P).
>>>>>
>>>>>> 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?
>>>>>
>>>>> No, you are the one who is twisting the meaning of words. When I
>>>>> talk about the actual behaviour of P(P) I mean what actually
>>>>> happens when P(P) is executed. That's what the words "actual" and
>>>>> "behaviour" mean.
>>>>>
>>>>> You are using the words "actual behavior" to mean something else
>>>>> which is clearly different. It seems to relate to some sort of
>>>>> simulator, which you simultaneously claim to be correct while
>>>>> acknowledging it produces different results from executing P(P)
>>>>> directly.
>>>>>
>>>>> Can you tell us if that "actual behavior" does actually happen in
>>>>> any circumstances, or is it (despite the name) just a theoretical
>>>>> thing?
>>>>>
>>>>>> 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, where the actual behaviour is the behaviour that actually
>>>>> happens.
>>>>>
>>>>>> It is common knowledge that a correct simulation of a program is a
>>>>>> correct measure of the behavior of this program.
>>>>>
>>>>> Yes, if the simulation is correct. You've insisted numerous times
>>>>> that your own simulator is incorrect.
>>>>
>>>> PO's simulation is correct at the individual instruction level.  His
>>>> H steps the simulation forward a number of steps, and each of those
>>>> steps exactly matches the P(P) calculation steps.  At some point
>>>> before the final P RET instruction, his H decides to stop stepping
>>>> (for whatever reason), so H's simulation is *incomplete*.
>>>>
>>>> That is the only sense in which P(P) and "the simulated input to
>>>> H(P,P)" differ - H simply stops simulating before P(P) terminates.
>>>
>>> But "incomplete" is incorrect if your logic assumes that the
>>> simulation not reaching the final state PROVES non-halting.
>>
>> I don't believe PO thinks that, irrespective of how badly he explains
>> things.  I think he believes that the simulation would never halt
>> *because his never-halting-abort test matched*, NOT simply as a
>> consequence of aborting.  E.g. he seems to understand that a simulator
>> that steps 10 steps then stops regardless, does not imply that the
>> simulated computation does not halt.
>>
>> Although... he doesn't properly understand what halting means, and
>> gets hopelessly confused by various wordings, so discussing any of
>> this with him is quite futile.  Seriously - just don't bother!!
>>
>>> "Simulation" as a word by itself implies complete and correct, and
>>> "Correct Simulation" implies Complete in normal English usage.
>>
>> That's an opinion, and it's one way to go.  To me "simulating" is an
>> /activity/ that H performs - it means calcultating succesive steps of
>> a given computation.  (Without implied /completeness/.)
>>>
>>> Yes, to be very precise we could everywhere say complete and correct
>>> simulation, but that gets wordy.
>>
>> No need - everywhere in these threads where "H simulates..." is used,
>> the meaning is nearly always my interpretation, not yours.  I don't
>> agree yours is the default/correct interpretation - at least it's not
>> the useful one.  In the event that you want to refer to a complete
>> simulation, you can just say "full simulation" or "complete
>> simulation", but that IMO hardly ever arises.  (Or we could make the
>> most common scenario more wordy, by always emphasising "partial
>> simulation".) Anyway, this seems to be a non-issue...
>>
>>>
>>> The key point is that H stops its simulating, AND THEN PRESUMES that
>>> this simulation, if continued correctly, would never halt.
>>
>> Yes, all the regulars here understand this mistake, if not it's
>> origin. BUT THERE IS NO POINT TRYING TO EXPLAIN THE PROBLEM TO PO - HE
>> IS INTELLECTUALLY INCAPABLE OF FOLLOWING ABSTRACT REASONING OR
>> UNDERSTANDING THE REQUIRED CONCEPTS.  Surely you must have come to
>> this conclusion after all this time?
>>
>
> A computation is said to terminate normally when it completes all of its
> steps by reaching its last instruction. It is shown below that P
> essentially calls H in infinite recursion and is rejected by H as
> non-halting on that basis.

Except that it ISN'T infinite recursion if H has code that allows it to
stop its simulation

>
> *Mike doesn't seem to comprehend this*
> *Mike doesn't seem to comprehend this*
> *Mike doesn't seem to comprehend this*
> *Mike doesn't seem to comprehend this*

OLCOTT doesn't understand this

Remember, if main calls H(P,P) and H(P,P) returns 0, then when P(P)
calls H(P,P) then H WILL Return 0 (or H is PROVED not to be the needed
pure function), and when H returns 0 to P, it will Halt.

If P(P) Halts, then H(P,P) returning 0 is NOT the correct answer.

>
> 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));
> }
>
> When simulating halt decider H(P,P) simulates its input it can see that:
> (1) Function H() is called from P().
> (2) With the same arguments to H().
> (3) With no instructions in P preceding its invocation of H(P,P) that
> could escape repeated simulations.

Your repeating this PROVES you are a pathological liar as this rule is
HOT true as you use it.

FAIL

>
> The above shows that the simulated P cannot possibly (reachs it “return”
> instruction and) terminate normally. H(P,P) simulates its input then P
> calls H(P,P) to simulate itself again. When H sees that this otherwise
> infinitely nested simulation would never end it aborts its simulation of
> P and rejects P as non-halting.
>

No, the above shows you do not understand how computers actually work.

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

A bunch of lies based on faulty rules.