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 since H is shown to abort its simulation, there IS no
infinite recursion.

If when main calls H(P,P), then H(P,P) returns 0, and H actully IS a
pure function, than when P(P) calls H(P,P) we KNOW that H will decide to
abort it emulation (as soon as that emulation reaches the next call to
H(P,P), so the recursion depth is *1*, not infinite)
Since H(P,P) will then return 0 to P(P), we know that P(P) will halt and
thus be a halting computation. A computation that terminated normally by
reaching its last instruction (the simulation that was aborted is NOT
the computation we are looking at).

Since P(P) Halts when H(P,P) returns 0, that answer can NOT be the
correct answer.

If you want to go to your claim that the input H(P,P) doesn't actually
refer to P(P), then you need to deal with the fact that then you H isn't
defined right, as P is defined to ask H about itself with its input, and
it did that by calling H(P,P).

>
> *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 UNABLE TO UNDERSTAND THIS.

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

An incorrect rule as has been pointed out in the past, showing that you
seem unable to learn from your mistakes.

You are thus shown to be just talking fairy tales and you whole logic
built on incorrect rules and invalid.

Note, the rule you are thinking of doesn't stop at the call to H but
goes all the way through the code in H, since H has code to abort, and
is shown TO abort its simulation, there is no infintie recursion.

You somehow seem to beleive that 1 == infinitity, which I guess is the
level of your understanding of math. Even primative people tend to be
able to count to 3.

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

Nope. shows that H is using the wrong definition of itself, assume that
H never aborts its simulation when it actually does.

This is classical fallacy of a false premise, and shows the level of
your understanding of logic, about as good as your ability to count.

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

Full of errors previously noted.