On 8/15/22 10:56 AM, olcott wrote:
> On 8/15/2022 6:50 AM, Richard Damon wrote:
>> On 8/14/22 10:26 PM, olcott wrote:
>>> On 8/14/2022 9:14 PM, Richard Damon wrote:
>>>> On 8/14/22 9:58 PM, olcott wrote:
>>>>> On 8/14/2022 8:52 PM, Richard Damon wrote:
>>>>>> On 8/14/22 9:41 PM, olcott wrote:
>>>>>>> On 8/14/2022 8:30 PM, Richard Damon wrote:
>>>>>>>> On 8/14/22 9:08 PM, olcott wrote:
>>>>>>>>> On 8/14/2022 7:28 PM, Richard Damon wrote:
>>>>>>>>>> On 8/14/22 7:33 PM, olcott wrote:
>>>>>>>>>>> On 8/14/2022 6:29 PM, Richard Damon wrote:
>>>>>>>>>>>> On 8/14/22 6:58 PM, olcott wrote:
>>>>>>>>>>>>> On 8/14/2022 5:16 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 8/14/22 5:52 PM, olcott wrote:
>>>>>>>>>>>>>>> Mr Flibble <flibble@reddwarf.jmc.corp> Wrote in message:r
>>>>>>>>>>>>>>>> On Sun, 14 Aug 2022 14:18:53 -0500olcott
>>>>>>>>>>>>>>>> <NoOne@NoWhere.com> wrote:> On 8/14/2022 2:14 PM, Mr
>>>>>>>>>>>>>>>> Flibble wrote:> > On Sun, 14 Aug 2022 10:14:28 -0500> >
>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:> >   > >> *This is
>>>>>>>>>>>>>>>> refers to H(P,P)==0 where H and P are functions in C*>
>>>>>>>>>>>>>>>> >>> >>       I believe I have learned something valuable
>>>>>>>>>>>>>>>> from you:> >>       that by simulation, and by
>>>>>>>>>>>>>>>> simulations within simulations,> >>       non-halting
>>>>>>>>>>>>>>>> can sometimes be detected, and in particular,> >>
>>>>>>>>>>>>>>>> it can be detected in the program used in the classical>
>>>>>>>>>>>>>>>> >>       proof of incomputability.> >>> >> *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>
>>>>>>>>>>>>>>>> >>  > > > > I am also a computer scientist and I am
>>>>>>>>>>>>>>>> telling you that your> > halting decider reporting
>>>>>>>>>>>>>>>> non-halting when it enters "infinite> > recursion" is an
>>>>>>>>>>>>>>>> ERROR.  There is no infinite recursion in the HP> >
>>>>>>>>>>>>>>>> proofs you are attempting to refute.> > > > /Flibble> >
>>>>>>>>>>>>>>>> > > > 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));> }>
>>>>>>>>>>>>>>>> > If it was true that you are a computer scientist then
>>>>>>>>>>>>>>>> you would > understand that this execution trace is
>>>>>>>>>>>>>>>> correct:> > (a) H(P,P) simulates P(P) that calls a
>>>>>>>>>>>>>>>> simulated H(P,P)> (b) that simulates P(P) that calls a
>>>>>>>>>>>>>>>> simulated H(P,P)> (c) that simulates P(P) that calls a
>>>>>>>>>>>>>>>> simulated H(P,P)> (d) that simulates P(P) that calls a
>>>>>>>>>>>>>>>> simulated H(P,P)...> *Until H aborts its simulation*I am
>>>>>>>>>>>>>>>> a computer scientist and all your trace shows is that H
>>>>>>>>>>>>>>>> (not P) isat the root of your so called "infinite
>>>>>>>>>>>>>>>> recursion" and is the primaryreason why you are
>>>>>>>>>>>>>>>> incorrect to map this recursive behaviour of your Hto a
>>>>>>>>>>>>>>>> halting decision on P of non-halting.> > If you do not
>>>>>>>>>>>>>>>> understand that the above execution trace is correct>
>>>>>>>>>>>>>>>> then this proves that you are not as much as a
>>>>>>>>>>>>>>>> sufficiently competent > software engineer.It seems I
>>>>>>>>>>>>>>>> understand your trace more than you do which makes
>>>>>>>>>>>>>>>> itobvious who is actually lacking in competence
>>>>>>>>>>>>>>>> here./Flibble
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Because H exactly simulates its input and has no control
>>>>>>>>>>>>>>> flow
>>>>>>>>>>>>>>>   behavior of it's own while it is simulating this input
>>>>>>>>>>>>>>> YOU ARE
>>>>>>>>>>>>>>>   BLAMING THE MIRROR FOR WHAT IT REFLECTS.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H does have control low on its own, or it can't stop the
>>>>>>>>>>>>>> simulationg to give an answer.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Because H exactly simulates its input and has no control flow
>>>>>>>>>>>>> behavior of it's own
>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>> YOU ARE BLAMING THE MIRROR FOR WHAT IT REFLECTS.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> So either you are a liar, or just badly confused about
>>>>>>>>>>>>>> what you are saying.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Or you OCD prevents you from paying close enough attention
>>>>>>>>>>>>> to ALL of my words.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Then how does it decide to stop simulating if it has no
>>>>>>>>>>>> control flow before it stops?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> H does not have any effect on the behavior of its simulated P
>>>>>>>>>>> the whole time that H is simulating P, thus any recursive
>>>>>>>>>>> behavior that P demonstrates is behavior of P and not
>>>>>>>>>>> behavior of H.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Nope, the problem is in H, not P.
>>>>>>>>>>
>>>>>>>>>> This H by its actions might not affect the behavior of the
>>>>>>>>>> input it is simulating, but it doesn't correctly determine the
>>>>>>>>>> effect that the copy of H in P will have.
>>>>>>>>>
>>>>>>>>> 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));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> So you disagree with this:
>>>>>>>>>
>>>>>>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>>>>>>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>>>>>>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>>>>>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>>>>>>> *Until H aborts its simulation*
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> That isn't what your H does,
>>>>>>>
>>>>>>> Why do you say that isn't what my H does when you know that it is
>>>>>>> what my H does and you can verify this with the complete system?
>>>>>>>
>>>>>>> https://www.liarparadox.org/2022_07_22.zip
>>>>>>> This is the complete system that compiles under:
>>>>>>>
>>>>>>> Microsoft Visual Studio Community 2017
>>>>>>> https://visualstudio.microsoft.com/vs/older-downloads/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Right, you didn't read what I said you H does, did you?
>>>>>>
>>>>>
>>>>> You said that what I said H does, it does not do, this is incorrect.
>>>>> Then you changed the subject.
>>>>>
>>>>
>>>> You H does NOT get to the step (b) that you have posted, so doesn't
>>>> match you pattern.
>>>>
>>>
>>> One H does not get past step (b)
>>> The other H does not get past step (c) and can be adapted to proceed
>>> any finite number of steps.
>>>
>>> The point is that no correct simulation of the input to H(P,P) by H
>>> ever stops running until H aborts it.
>>>
>>
>> Nope, look at the code you provided.
> Liar
>

Are you saying the code you provided DOESN'T abort the simulation done
by H(P,P) at the point where P(P) calls H(P,P)?