On 8/15/22 7:36 PM, olcott wrote:
> On 8/15/2022 5:47 PM, Richard Damon wrote:
>> 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)?
>>
>>
>
> The algorithm implemented by H:
> The correct simulation by H(P,P), never stops running until H aborts it.

No, the algorithm implemented by your H is to abort the simulation of
P(P) as soon as it calls H(P,P). That is EXACTLY what the code you have
published for your H does.

>
> The exact point in the execution trace of the correct simulation of the
> input to H(P,P) where the simulation is aborted is an implementation
> detail that is separate from this algorithm.
>

WRONG. The actual alrgorith INCLUDES the choice of that detail,
otherwise it isn't an actual ALGORITM, it is just a algorithm TEMPLATE.

Until you SPECIFY that "detail", you don't have an actual H.

Is that you problem, you don't understand that in Computation Theory,
and algorithm is the COMPLETE specification of the steps needd to carry
out the computaiton?

You can't just say "Until it proves ....", you need to specify EXACTLY
HOW it proves that. That means the EXACT pattern set that H uses.

You are just showing how little you understand what you are talking about.