On 9/2/22 3:53 PM, olcott wrote:
> On 9/2/2022 2:46 PM, Richard Damon wrote:
>> On 9/2/22 3:38 PM, olcott wrote:
>>> On 9/2/2022 2:28 PM, Richard Damon wrote:
>>>> On 9/2/22 3:11 PM, olcott wrote:
>>>>> On 9/2/2022 1:21 PM, Richard Damon wrote:
>>>>>> On 9/2/22 1:57 PM, olcott wrote:
>>>>>>> On 9/2/2022 7:19 AM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 9/2/22 12:35 AM, olcott wrote:
>>>>>>>>> On 9/1/2022 10:32 PM, Richard Damon wrote:
>>>>>>>>>> On 9/1/22 11:26 PM, olcott wrote:
>>>>>>>>>>> On 9/1/2022 10:23 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 9/1/22 11:18 PM, olcott wrote:
>>>>>>>>>>>>> On 9/1/2022 10:13 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 9/1/22 11:02 PM, olcott wrote:
>>>>>>>>>>>>>>> On 9/1/2022 9:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 9/1/22 8:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 9/1/2022 5:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 9/1/22 10:37 AM, olcott wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Nope, The finite string input to H(P,P) is the
>>>>>>>>>>>>>>>>>> representation of P(P),
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If this was true then when H(P,P) correctly simulates
>>>>>>>>>>>>>>>>> its input this simulation would stop without being
>>>>>>>>>>>>>>>>> aborted.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No, because your definition of H aborts its simulation
>>>>>>>>>>>>>>> Means that empirical testing proves that the simulation
>>>>>>>>>>>>>>> does not otherwise ever stop running.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope, because the "empirical test" you use
>>>>>>>>>>>>>
>>>>>>>>>>>>> is valid, when we are working with real code on real
>>>>>>>>>>>>> machines empirical testing is 100% reliable.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Nope, because your "Empericl Test" isn't designed to the
>>>>>>>>>>>> requirements.
>>>>>>>>>>>
>>>>>>>>>>> The requirements are simply this:
>>>>>>>>>>> Does the simulated input stop running if not aborted?
>>>>>>>>>>> Comment out the abort code and it keeps running thus: NO
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Nope, you changed the input, thus the test is invalid.
>>>>>>>>>>
>>>>>>>>>> FAIL.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No one that knows software engineering is going to buy that
>>>>>>>>> bullshit.
>>>>>>>>>
>>>>>>>>> Every software engineer knows that if simply commenting out the
>>>>>>>>> line of code that does the abort prevents the simulation from
>>>>>>>>> ever stopping that the simulation does not stop without the abort.
>>>>>>>>
>>>>>>>> Nope, and that shows your ignorance. Since you also edited the
>>>>>>>> program under test when you did that, you invalidated the test.
>>>>>>>>
>>>>>>>> You just are proving that you don't know what you are talking about
>>>>>>>>
>>>>>>> You are not going to get away with those weasel words of
>>>>>>> double-talk.
>>>>>>>
>>>>>>> Every competent software engineer will know with correct complete
>>>>>>> certainty that when commenting out the code the does the abort
>>>>>>> causes the the simulation to never stop that it is only the abort
>>>>>>> that stops
>>>>>>> the simulation.
>>>>>>>
>>>>>>
>>>>>> Nope. Since that changes the behavior of the input, it is an
>>>>>> invalid operation.
>>>>> Every competent software engineer will agree with me and disagree
>>>>> with your weasel word double talk.
>>>>>
>>>>
>>>> Name ONE.
>>>>
>>>> Make sure the understand that the input calls the decider, so
>>>> editing the decider changes the input.
>>>>
>>>
>>> Every competent software engineer is going to know that we can test
>>> that X causes Y by removing only X and Y stops happening.
>>>
>>>
>>
>> So, you don't know anyone willing to go on record to support you.
>>
>>
>> Guess that shows how reliable your claim its.
>>
>> FAIL.
>
> So you are claiming that when *only* the line of code that does the
> abort is commented out and this results in the correctly simulated input
> to H(P,P) never stopping that this does not mean that that it is only
> the abort that causes the simulation to stop IS NOT PROVEN ???
>

By Changing H, you have changed P, and thus your experement" showed the
wrong thing,

As I have pointed out, you need to make a COPY of H, and change THAT
COPY ONLY, and ask that to simulate the input.

An alternative, if your system can't handle and alternate H, is to give
H a third parameter, so you can test with the "remove the condition",
while the input still uses the original H.

Your lack of understand abpout this shows your stupidity.

Sorry, but that is just the Truth.

You clearly don't know what a computation is.

FAIL.

On 9/2/2022 3:08 PM, Richard Damon wrote:
> On 9/2/22 3:53 PM, olcott wrote:
>> On 9/2/2022 2:46 PM, Richard Damon wrote:
>>> On 9/2/22 3:38 PM, olcott wrote:
>>>> On 9/2/2022 2:28 PM, Richard Damon wrote:
>>>>> On 9/2/22 3:11 PM, olcott wrote:
>>>>>> On 9/2/2022 1:21 PM, Richard Damon wrote:
>>>>>>> On 9/2/22 1:57 PM, olcott wrote:
>>>>>>>> On 9/2/2022 7:19 AM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 9/2/22 12:35 AM, olcott wrote:
>>>>>>>>>> On 9/1/2022 10:32 PM, Richard Damon wrote:
>>>>>>>>>>> On 9/1/22 11:26 PM, olcott wrote:
>>>>>>>>>>>> On 9/1/2022 10:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 9/1/22 11:18 PM, olcott wrote:
>>>>>>>>>>>>>> On 9/1/2022 10:13 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 9/1/22 11:02 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 9/1/2022 9:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 9/1/22 8:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 9/1/2022 5:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 9/1/22 10:37 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Nope, The finite string input to H(P,P) is the
>>>>>>>>>>>>>>>>>>> representation of P(P),
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If this was true then when H(P,P) correctly simulates
>>>>>>>>>>>>>>>>>> its input this simulation would stop without being
>>>>>>>>>>>>>>>>>> aborted.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No, because your definition of H aborts its simulation
>>>>>>>>>>>>>>>> Means that empirical testing proves that the simulation
>>>>>>>>>>>>>>>> does not otherwise ever stop running.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Nope, because the "empirical test" you use
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> is valid, when we are working with real code on real
>>>>>>>>>>>>>> machines empirical testing is 100% reliable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nope, because your "Empericl Test" isn't designed to the
>>>>>>>>>>>>> requirements.
>>>>>>>>>>>>
>>>>>>>>>>>> The requirements are simply this:
>>>>>>>>>>>> Does the simulated input stop running if not aborted?
>>>>>>>>>>>> Comment out the abort code and it keeps running thus: NO
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Nope, you changed the input, thus the test is invalid.
>>>>>>>>>>>
>>>>>>>>>>> FAIL.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> No one that knows software engineering is going to buy that
>>>>>>>>>> bullshit.
>>>>>>>>>>
>>>>>>>>>> Every software engineer knows that if simply commenting out
>>>>>>>>>> the line of code that does the abort prevents the simulation
>>>>>>>>>> from ever stopping that the simulation does not stop without
>>>>>>>>>> the abort.
>>>>>>>>>
>>>>>>>>> Nope, and that shows your ignorance. Since you also edited the
>>>>>>>>> program under test when you did that, you invalidated the test.
>>>>>>>>>
>>>>>>>>> You just are proving that you don't know what you are talking
>>>>>>>>> about
>>>>>>>>>
>>>>>>>> You are not going to get away with those weasel words of
>>>>>>>> double-talk.
>>>>>>>>
>>>>>>>> Every competent software engineer will know with correct
>>>>>>>> complete certainty that when commenting out the code the does
>>>>>>>> the abort causes the the simulation to never stop that it is
>>>>>>>> only the abort that stops
>>>>>>>> the simulation.
>>>>>>>>
>>>>>>>
>>>>>>> Nope. Since that changes the behavior of the input, it is an
>>>>>>> invalid operation.
>>>>>> Every competent software engineer will agree with me and disagree
>>>>>> with your weasel word double talk.
>>>>>>
>>>>>
>>>>> Name ONE.
>>>>>
>>>>> Make sure the understand that the input calls the decider, so
>>>>> editing the decider changes the input.
>>>>>
>>>>
>>>> Every competent software engineer is going to know that we can test
>>>> that X causes Y by removing only X and Y stops happening.
>>>>
>>>>
>>>
>>> So, you don't know anyone willing to go on record to support you.
>>>
>>>
>>> Guess that shows how reliable your claim its.
>>>
>>> FAIL.
>>
>> So you are claiming that when *only* the line of code that does the
>> abort is commented out and this results in the correctly simulated
>> input to H(P,P) never stopping that this does not mean that that it is
>> only the abort that causes the simulation to stop IS NOT PROVEN ???
>>
>
> By Changing H, you have changed P, and thus your experement" showed the
> wrong thing,
>

(a) I assert that it is a proven fact that H(P,P) stops running when H
is allowed to abort its simulation of P

(b) I assert that it is a proven fact that H(P,P) never stops running
when H is *NOT* allowed to abort its simulation of P

Do you deny that (a) and (b) are true?
(a) YES
(b) Anything else proves that Richard is a liar.

--
Copyright 2022 Pete Olcott

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

On 9/2/2022 3:08 PM, Richard Damon wrote:
> On 9/2/22 3:53 PM, olcott wrote:
>> On 9/2/2022 2:46 PM, Richard Damon wrote:
>>> On 9/2/22 3:38 PM, olcott wrote:
>>>> On 9/2/2022 2:28 PM, Richard Damon wrote:
>>>>> On 9/2/22 3:11 PM, olcott wrote:
>>>>>> On 9/2/2022 1:21 PM, Richard Damon wrote:
>>>>>>> On 9/2/22 1:57 PM, olcott wrote:
>>>>>>>> On 9/2/2022 7:19 AM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 9/2/22 12:35 AM, olcott wrote:
>>>>>>>>>> On 9/1/2022 10:32 PM, Richard Damon wrote:
>>>>>>>>>>> On 9/1/22 11:26 PM, olcott wrote:
>>>>>>>>>>>> On 9/1/2022 10:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 9/1/22 11:18 PM, olcott wrote:
>>>>>>>>>>>>>> On 9/1/2022 10:13 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 9/1/22 11:02 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 9/1/2022 9:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 9/1/22 8:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 9/1/2022 5:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 9/1/22 10:37 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Nope, The finite string input to H(P,P) is the
>>>>>>>>>>>>>>>>>>> representation of P(P),
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If this was true then when H(P,P) correctly simulates
>>>>>>>>>>>>>>>>>> its input this simulation would stop without being
>>>>>>>>>>>>>>>>>> aborted.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No, because your definition of H aborts its simulation
>>>>>>>>>>>>>>>> Means that empirical testing proves that the simulation
>>>>>>>>>>>>>>>> does not otherwise ever stop running.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Nope, because the "empirical test" you use
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> is valid, when we are working with real code on real
>>>>>>>>>>>>>> machines empirical testing is 100% reliable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nope, because your "Empericl Test" isn't designed to the
>>>>>>>>>>>>> requirements.
>>>>>>>>>>>>
>>>>>>>>>>>> The requirements are simply this:
>>>>>>>>>>>> Does the simulated input stop running if not aborted?
>>>>>>>>>>>> Comment out the abort code and it keeps running thus: NO
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Nope, you changed the input, thus the test is invalid.
>>>>>>>>>>>
>>>>>>>>>>> FAIL.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> No one that knows software engineering is going to buy that
>>>>>>>>>> bullshit.
>>>>>>>>>>
>>>>>>>>>> Every software engineer knows that if simply commenting out
>>>>>>>>>> the line of code that does the abort prevents the simulation
>>>>>>>>>> from ever stopping that the simulation does not stop without
>>>>>>>>>> the abort.
>>>>>>>>>
>>>>>>>>> Nope, and that shows your ignorance. Since you also edited the
>>>>>>>>> program under test when you did that, you invalidated the test.
>>>>>>>>>
>>>>>>>>> You just are proving that you don't know what you are talking
>>>>>>>>> about
>>>>>>>>>
>>>>>>>> You are not going to get away with those weasel words of
>>>>>>>> double-talk.
>>>>>>>>
>>>>>>>> Every competent software engineer will know with correct
>>>>>>>> complete certainty that when commenting out the code the does
>>>>>>>> the abort causes the the simulation to never stop that it is
>>>>>>>> only the abort that stops
>>>>>>>> the simulation.
>>>>>>>>
>>>>>>>
>>>>>>> Nope. Since that changes the behavior of the input, it is an
>>>>>>> invalid operation.
>>>>>> Every competent software engineer will agree with me and disagree
>>>>>> with your weasel word double talk.
>>>>>>
>>>>>
>>>>> Name ONE.
>>>>>
>>>>> Make sure the understand that the input calls the decider, so
>>>>> editing the decider changes the input.
>>>>>
>>>>
>>>> Every competent software engineer is going to know that we can test
>>>> that X causes Y by removing only X and Y stops happening.
>>>>
>>>>
>>>
>>> So, you don't know anyone willing to go on record to support you.
>>>
>>>
>>> Guess that shows how reliable your claim its.
>>>
>>> FAIL.
>>
>> So you are claiming that when *only* the line of code that does the
>> abort is commented out and this results in the correctly simulated
>> input to H(P,P) never stopping that this does not mean that that it is
>> only the abort that causes the simulation to stop IS NOT PROVEN ???
>>
>
> By Changing H, you have changed P, and thus your experement" showed the
> wrong thing,
>
(a) I assert that it is a proven fact that H(P,P) stops running when H
is allowed to abort its simulation of P

(b) I assert that it is a proven fact that H(P,P) never stops running
when H is *NOT* allowed to abort its simulation of P

Do you *ACCEPT* that (a) and (b) are true?
(a) YES
(b) Anything else proves that Richard is a liar.

--
Copyright 2022 Pete Olcott

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

On 9/2/22 4:31 PM, olcott wrote:
> On 9/2/2022 3:08 PM, Richard Damon wrote:
>> On 9/2/22 3:53 PM, olcott wrote:
>>> On 9/2/2022 2:46 PM, Richard Damon wrote:
>>>> On 9/2/22 3:38 PM, olcott wrote:
>>>>> On 9/2/2022 2:28 PM, Richard Damon wrote:
>>>>>> On 9/2/22 3:11 PM, olcott wrote:
>>>>>>> On 9/2/2022 1:21 PM, Richard Damon wrote:
>>>>>>>> On 9/2/22 1:57 PM, olcott wrote:
>>>>>>>>> On 9/2/2022 7:19 AM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 9/2/22 12:35 AM, olcott wrote:
>>>>>>>>>>> On 9/1/2022 10:32 PM, Richard Damon wrote:
>>>>>>>>>>>> On 9/1/22 11:26 PM, olcott wrote:
>>>>>>>>>>>>> On 9/1/2022 10:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 9/1/22 11:18 PM, olcott wrote:
>>>>>>>>>>>>>>> On 9/1/2022 10:13 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 9/1/22 11:02 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 9/1/2022 9:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 9/1/22 8:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 9/1/2022 5:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 9/1/22 10:37 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Nope, The finite string input to H(P,P) is the
>>>>>>>>>>>>>>>>>>>> representation of P(P),
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> If this was true then when H(P,P) correctly simulates
>>>>>>>>>>>>>>>>>>> its input this simulation would stop without being
>>>>>>>>>>>>>>>>>>> aborted.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> No, because your definition of H aborts its simulation
>>>>>>>>>>>>>>>>> Means that empirical testing proves that the simulation
>>>>>>>>>>>>>>>>> does not otherwise ever stop running.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nope, because the "empirical test" you use
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> is valid, when we are working with real code on real
>>>>>>>>>>>>>>> machines empirical testing is 100% reliable.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope, because your "Empericl Test" isn't designed to the
>>>>>>>>>>>>>> requirements.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The requirements are simply this:
>>>>>>>>>>>>> Does the simulated input stop running if not aborted?
>>>>>>>>>>>>> Comment out the abort code and it keeps running thus: NO
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Nope, you changed the input, thus the test is invalid.
>>>>>>>>>>>>
>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> No one that knows software engineering is going to buy that
>>>>>>>>>>> bullshit.
>>>>>>>>>>>
>>>>>>>>>>> Every software engineer knows that if simply commenting out
>>>>>>>>>>> the line of code that does the abort prevents the simulation
>>>>>>>>>>> from ever stopping that the simulation does not stop without
>>>>>>>>>>> the abort.
>>>>>>>>>>
>>>>>>>>>> Nope, and that shows your ignorance. Since you also edited the
>>>>>>>>>> program under test when you did that, you invalidated the test.
>>>>>>>>>>
>>>>>>>>>> You just are proving that you don't know what you are talking
>>>>>>>>>> about
>>>>>>>>>>
>>>>>>>>> You are not going to get away with those weasel words of
>>>>>>>>> double-talk.
>>>>>>>>>
>>>>>>>>> Every competent software engineer will know with correct
>>>>>>>>> complete certainty that when commenting out the code the does
>>>>>>>>> the abort causes the the simulation to never stop that it is
>>>>>>>>> only the abort that stops
>>>>>>>>> the simulation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Nope. Since that changes the behavior of the input, it is an
>>>>>>>> invalid operation.
>>>>>>> Every competent software engineer will agree with me and disagree
>>>>>>> with your weasel word double talk.
>>>>>>>
>>>>>>
>>>>>> Name ONE.
>>>>>>
>>>>>> Make sure the understand that the input calls the decider, so
>>>>>> editing the decider changes the input.
>>>>>>
>>>>>
>>>>> Every competent software engineer is going to know that we can test
>>>>> that X causes Y by removing only X and Y stops happening.
>>>>>
>>>>>
>>>>
>>>> So, you don't know anyone willing to go on record to support you.
>>>>
>>>>
>>>> Guess that shows how reliable your claim its.
>>>>
>>>> FAIL.
>>>
>>> So you are claiming that when *only* the line of code that does the
>>> abort is commented out and this results in the correctly simulated
>>> input to H(P,P) never stopping that this does not mean that that it
>>> is only the abort that causes the simulation to stop IS NOT PROVEN ???
>>>
>>
>> By Changing H, you have changed P, and thus your experement" showed
>> the wrong thing,
>>
>
> (a) I assert that it is a proven fact that H(P,P) stops running when H
> is allowed to abort its simulation of P
>
Right.

Because H has been DEFINED to abort its simulation of P (no "allowed" in
there, it HAS to abort its simulation or it isn't the H you have defined)

> (b) I assert that it is a proven fact that H(P,P) never stops running
> when H is *NOT* allowed to abort its simulation of P

Nope, because then it is no longer the H that has been defined.

You can't assert a fact about something that doesn't happen.

YOU HAVE CHANGED P, and thus invalidated your test.
>
> Do you deny that (a) and (b) are true?
> (a) YES
> (b) Anything else proves that Richard is a liar.
>
>

It shows you are an idiot that doesn't know what you are talking about.

If you get pulled over for doing 40 in a 25 mile per hours zone, you
can't claim it was ok if you define a mile to be 10,000 feet.

You H that you built P on has been DEFINIED to abort its simulation,
since you claim that is the H that gives a correct answer.

You can not change that H when doing your test.

Your options:

Give the input to Simulate

Give the input to H', which has been modified as described

On 9/2/2022 3:38 PM, Richard Damon wrote:
> On 9/2/22 4:31 PM, olcott wrote:
>> On 9/2/2022 3:08 PM, Richard Damon wrote:
>>> On 9/2/22 3:53 PM, olcott wrote:
>>>> On 9/2/2022 2:46 PM, Richard Damon wrote:
>>>>> On 9/2/22 3:38 PM, olcott wrote:
>>>>>> On 9/2/2022 2:28 PM, Richard Damon wrote:
>>>>>>> On 9/2/22 3:11 PM, olcott wrote:
>>>>>>>> On 9/2/2022 1:21 PM, Richard Damon wrote:
>>>>>>>>> On 9/2/22 1:57 PM, olcott wrote:
>>>>>>>>>> On 9/2/2022 7:19 AM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 9/2/22 12:35 AM, olcott wrote:
>>>>>>>>>>>> On 9/1/2022 10:32 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 9/1/22 11:26 PM, olcott wrote:
>>>>>>>>>>>>>> On 9/1/2022 10:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 9/1/22 11:18 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 9/1/2022 10:13 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 9/1/22 11:02 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 9/1/2022 9:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 9/1/22 8:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 9/1/2022 5:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 9/1/22 10:37 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Nope, The finite string input to H(P,P) is the
>>>>>>>>>>>>>>>>>>>>> representation of P(P),
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If this was true then when H(P,P) correctly
>>>>>>>>>>>>>>>>>>>> simulates its input this simulation would stop
>>>>>>>>>>>>>>>>>>>> without being aborted.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> No, because your definition of H aborts its simulation
>>>>>>>>>>>>>>>>>> Means that empirical testing proves that the
>>>>>>>>>>>>>>>>>> simulation does not otherwise ever stop running.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Nope, because the "empirical test" you use
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> is valid, when we are working with real code on real
>>>>>>>>>>>>>>>> machines empirical testing is 100% reliable.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Nope, because your "Empericl Test" isn't designed to the
>>>>>>>>>>>>>>> requirements.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The requirements are simply this:
>>>>>>>>>>>>>> Does the simulated input stop running if not aborted?
>>>>>>>>>>>>>> Comment out the abort code and it keeps running thus: NO
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nope, you changed the input, thus the test is invalid.
>>>>>>>>>>>>>
>>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> No one that knows software engineering is going to buy that
>>>>>>>>>>>> bullshit.
>>>>>>>>>>>>
>>>>>>>>>>>> Every software engineer knows that if simply commenting out
>>>>>>>>>>>> the line of code that does the abort prevents the simulation
>>>>>>>>>>>> from ever stopping that the simulation does not stop without
>>>>>>>>>>>> the abort.
>>>>>>>>>>>
>>>>>>>>>>> Nope, and that shows your ignorance. Since you also edited
>>>>>>>>>>> the program under test when you did that, you invalidated the
>>>>>>>>>>> test.
>>>>>>>>>>>
>>>>>>>>>>> You just are proving that you don't know what you are talking
>>>>>>>>>>> about
>>>>>>>>>>>
>>>>>>>>>> You are not going to get away with those weasel words of
>>>>>>>>>> double-talk.
>>>>>>>>>>
>>>>>>>>>> Every competent software engineer will know with correct
>>>>>>>>>> complete certainty that when commenting out the code the does
>>>>>>>>>> the abort causes the the simulation to never stop that it is
>>>>>>>>>> only the abort that stops
>>>>>>>>>> the simulation.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Nope. Since that changes the behavior of the input, it is an
>>>>>>>>> invalid operation.
>>>>>>>> Every competent software engineer will agree with me and
>>>>>>>> disagree with your weasel word double talk.
>>>>>>>>
>>>>>>>
>>>>>>> Name ONE.
>>>>>>>
>>>>>>> Make sure the understand that the input calls the decider, so
>>>>>>> editing the decider changes the input.
>>>>>>>
>>>>>>
>>>>>> Every competent software engineer is going to know that we can
>>>>>> test that X causes Y by removing only X and Y stops happening.
>>>>>>
>>>>>>
>>>>>
>>>>> So, you don't know anyone willing to go on record to support you.
>>>>>
>>>>>
>>>>> Guess that shows how reliable your claim its.
>>>>>
>>>>> FAIL.
>>>>
>>>> So you are claiming that when *only* the line of code that does the
>>>> abort is commented out and this results in the correctly simulated
>>>> input to H(P,P) never stopping that this does not mean that that it
>>>> is only the abort that causes the simulation to stop IS NOT PROVEN ???
>>>>
>>>
>>> By Changing H, you have changed P, and thus your experement" showed
>>> the wrong thing,
>>>
>>
>> (a) I assert that it is a proven fact that H(P,P) stops running when H
>> is allowed to abort its simulation of P
>>
> Right.
>
> Because H has been DEFINED to abort its simulation of P (no "allowed" in
> there, it HAS to abort its simulation or it isn't the H you have defined)
>
>> (b) I assert that it is a proven fact that H(P,P) never stops running
>> when H is *NOT* allowed to abort its simulation of P
>
> Nope, because then it is no longer the H that has been defined.
>

Sure it is. When you comment out a line-of-code in a function the
compiler absolutely will not change the name of this function and you
know this so why lie?

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 9/2/22 4:32 PM, olcott wrote: (again)
> On 9/2/2022 3:08 PM, Richard Damon wrote:
>> On 9/2/22 3:53 PM, olcott wrote >>> So you are claiming that when *only* the line of code that does the
>>> abort is commented out and this results in the correctly simulated
>>> input to H(P,P) never stopping that this does not mean that that it
>>> is only the abort that causes the simulation to stop IS NOT PROVEN ???
>>>
>>
>> By Changing H, you have changed P, and thus your experement" showed
>> the wrong thing,
>>
> (a) I assert that it is a proven fact that H(P,P) stops running when H
> is allowed to abort its simulation of P

Right.

Because H has been DEFINED to abort its simulation of P (no "allowed" in
there, it HAS to abort its simulation or it isn't the H you have defined)

>
> (b) I assert that it is a proven fact that H(P,P) never stops running
> when H is *NOT* allowed to abort its simulation of P

Nope, because then it is no longer the H that has been defined.

You can't assert a fact about something that doesn't happen.

YOU HAVE CHANGED P, and thus invalidated your test.

>
> Do you *ACCEPT* that (a) and (b) are true?
> (a) YES
> (b) Anything else proves that Richard is a liar.
>
>
>

It shows you are an idiot that doesn't know what you are talking about.

If you get pulled over for doing 40 in a 25 mile per hours zone, you
can't claim it was ok if you define a mile to be 10,000 feet.

You H that you built P on has been DEFINIED to abort its simulation,
since you claim that is the H that gives a correct answer.

You can not change that H when doing your test.

Your options:

Give the input to Simulate

Give the input to H', which has been modified as described

Give H a third input that changes its behavior.

Before you change H, you replace the call to H in P with a function that
does what the old H does. (Perhaps just a return 0)

In ALL these case, P must continue to call an H that behaves EXACTLY
like the H that you claim to give the right answer.

You are just proving that you don't know what a computation is.

On 9/2/22 4:46 PM, olcott wrote:
> On 9/2/2022 3:38 PM, Richard Damon wrote:
>> On 9/2/22 4:31 PM, olcott wrote:
>>> On 9/2/2022 3:08 PM, Richard Damon wrote:
>>>> On 9/2/22 3:53 PM, olcott wrote:
>>>>> On 9/2/2022 2:46 PM, Richard Damon wrote:
>>>>>> On 9/2/22 3:38 PM, olcott wrote:
>>>>>>> On 9/2/2022 2:28 PM, Richard Damon wrote:
>>>>>>>> On 9/2/22 3:11 PM, olcott wrote:
>>>>>>>>> On 9/2/2022 1:21 PM, Richard Damon wrote:
>>>>>>>>>> On 9/2/22 1:57 PM, olcott wrote:
>>>>>>>>>>> On 9/2/2022 7:19 AM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 9/2/22 12:35 AM, olcott wrote:
>>>>>>>>>>>>> On 9/1/2022 10:32 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 9/1/22 11:26 PM, olcott wrote:
>>>>>>>>>>>>>>> On 9/1/2022 10:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 9/1/22 11:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 9/1/2022 10:13 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 9/1/22 11:02 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 9/1/2022 9:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 9/1/22 8:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 5:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 10:37 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Nope, The finite string input to H(P,P) is the
>>>>>>>>>>>>>>>>>>>>>> representation of P(P),
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> If this was true then when H(P,P) correctly
>>>>>>>>>>>>>>>>>>>>> simulates its input this simulation would stop
>>>>>>>>>>>>>>>>>>>>> without being aborted.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> No, because your definition of H aborts its simulation
>>>>>>>>>>>>>>>>>>> Means that empirical testing proves that the
>>>>>>>>>>>>>>>>>>> simulation does not otherwise ever stop running.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Nope, because the "empirical test" you use
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> is valid, when we are working with real code on real
>>>>>>>>>>>>>>>>> machines empirical testing is 100% reliable.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nope, because your "Empericl Test" isn't designed to the
>>>>>>>>>>>>>>>> requirements.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The requirements are simply this:
>>>>>>>>>>>>>>> Does the simulated input stop running if not aborted?
>>>>>>>>>>>>>>> Comment out the abort code and it keeps running thus: NO
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope, you changed the input, thus the test is invalid.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> No one that knows software engineering is going to buy that
>>>>>>>>>>>>> bullshit.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Every software engineer knows that if simply commenting out
>>>>>>>>>>>>> the line of code that does the abort prevents the
>>>>>>>>>>>>> simulation from ever stopping that the simulation does not
>>>>>>>>>>>>> stop without the abort.
>>>>>>>>>>>>
>>>>>>>>>>>> Nope, and that shows your ignorance. Since you also edited
>>>>>>>>>>>> the program under test when you did that, you invalidated
>>>>>>>>>>>> the test.
>>>>>>>>>>>>
>>>>>>>>>>>> You just are proving that you don't know what you are
>>>>>>>>>>>> talking about
>>>>>>>>>>>>
>>>>>>>>>>> You are not going to get away with those weasel words of
>>>>>>>>>>> double-talk.
>>>>>>>>>>>
>>>>>>>>>>> Every competent software engineer will know with correct
>>>>>>>>>>> complete certainty that when commenting out the code the does
>>>>>>>>>>> the abort causes the the simulation to never stop that it is
>>>>>>>>>>> only the abort that stops
>>>>>>>>>>> the simulation.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Nope. Since that changes the behavior of the input, it is an
>>>>>>>>>> invalid operation.
>>>>>>>>> Every competent software engineer will agree with me and
>>>>>>>>> disagree with your weasel word double talk.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Name ONE.
>>>>>>>>
>>>>>>>> Make sure the understand that the input calls the decider, so
>>>>>>>> editing the decider changes the input.
>>>>>>>>
>>>>>>>
>>>>>>> Every competent software engineer is going to know that we can
>>>>>>> test that X causes Y by removing only X and Y stops happening.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> So, you don't know anyone willing to go on record to support you.
>>>>>>
>>>>>>
>>>>>> Guess that shows how reliable your claim its.
>>>>>>
>>>>>> FAIL.
>>>>>
>>>>> So you are claiming that when *only* the line of code that does the
>>>>> abort is commented out and this results in the correctly simulated
>>>>> input to H(P,P) never stopping that this does not mean that that it
>>>>> is only the abort that causes the simulation to stop IS NOT PROVEN ???
>>>>>
>>>>
>>>> By Changing H, you have changed P, and thus your experement" showed
>>>> the wrong thing,
>>>>
>>>
>>> (a) I assert that it is a proven fact that H(P,P) stops running when
>>> H is allowed to abort its simulation of P
>>>
>> Right.
>>
>> Because H has been DEFINED to abort its simulation of P (no "allowed"
>> in there, it HAS to abort its simulation or it isn't the H you have
>> defined)
>>
>>> (b) I assert that it is a proven fact that H(P,P) never stops running
>>> when H is *NOT* allowed to abort its simulation of P
>>
>> Nope, because then it is no longer the H that has been defined.
>>
>
> Sure it is. When you comment out a line-of-code in a function the
> compiler absolutely will not change the name of this function and you
> know this so why lie?
>

On 9/2/2022 3:56 PM, Richard Damon wrote:
> On 9/2/22 4:46 PM, olcott wrote:
>> On 9/2/2022 3:38 PM, Richard Damon wrote:
>>> On 9/2/22 4:31 PM, olcott wrote:
>>>> On 9/2/2022 3:08 PM, Richard Damon wrote:
>>>>> On 9/2/22 3:53 PM, olcott wrote:
>>>>>> On 9/2/2022 2:46 PM, Richard Damon wrote:
>>>>>>> On 9/2/22 3:38 PM, olcott wrote:
>>>>>>>> On 9/2/2022 2:28 PM, Richard Damon wrote:
>>>>>>>>> On 9/2/22 3:11 PM, olcott wrote:
>>>>>>>>>> On 9/2/2022 1:21 PM, Richard Damon wrote:
>>>>>>>>>>> On 9/2/22 1:57 PM, olcott wrote:
>>>>>>>>>>>> On 9/2/2022 7:19 AM, Richard Damon wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 9/2/22 12:35 AM, olcott wrote:
>>>>>>>>>>>>>> On 9/1/2022 10:32 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 9/1/22 11:26 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 9/1/2022 10:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 9/1/22 11:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 9/1/2022 10:13 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 9/1/22 11:02 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 9/1/2022 9:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 9/1/22 8:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 5:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 10:37 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Nope, The finite string input to H(P,P) is the
>>>>>>>>>>>>>>>>>>>>>>> representation of P(P),
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> If this was true then when H(P,P) correctly
>>>>>>>>>>>>>>>>>>>>>> simulates its input this simulation would stop
>>>>>>>>>>>>>>>>>>>>>> without being aborted.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> No, because your definition of H aborts its simulation
>>>>>>>>>>>>>>>>>>>> Means that empirical testing proves that the
>>>>>>>>>>>>>>>>>>>> simulation does not otherwise ever stop running.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Nope, because the "empirical test" you use
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> is valid, when we are working with real code on real
>>>>>>>>>>>>>>>>>> machines empirical testing is 100% reliable.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Nope, because your "Empericl Test" isn't designed to
>>>>>>>>>>>>>>>>> the requirements.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The requirements are simply this:
>>>>>>>>>>>>>>>> Does the simulated input stop running if not aborted?
>>>>>>>>>>>>>>>> Comment out the abort code and it keeps running thus: NO
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Nope, you changed the input, thus the test is invalid.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No one that knows software engineering is going to buy
>>>>>>>>>>>>>> that bullshit.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Every software engineer knows that if simply commenting
>>>>>>>>>>>>>> out the line of code that does the abort prevents the
>>>>>>>>>>>>>> simulation from ever stopping that the simulation does not
>>>>>>>>>>>>>> stop without the abort.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nope, and that shows your ignorance. Since you also edited
>>>>>>>>>>>>> the program under test when you did that, you invalidated
>>>>>>>>>>>>> the test.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You just are proving that you don't know what you are
>>>>>>>>>>>>> talking about
>>>>>>>>>>>>>
>>>>>>>>>>>> You are not going to get away with those weasel words of
>>>>>>>>>>>> double-talk.
>>>>>>>>>>>>
>>>>>>>>>>>> Every competent software engineer will know with correct
>>>>>>>>>>>> complete certainty that when commenting out the code the
>>>>>>>>>>>> does the abort causes the the simulation to never stop that
>>>>>>>>>>>> it is only the abort that stops
>>>>>>>>>>>> the simulation.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Nope. Since that changes the behavior of the input, it is an
>>>>>>>>>>> invalid operation.
>>>>>>>>>> Every competent software engineer will agree with me and
>>>>>>>>>> disagree with your weasel word double talk.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Name ONE.
>>>>>>>>>
>>>>>>>>> Make sure the understand that the input calls the decider, so
>>>>>>>>> editing the decider changes the input.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Every competent software engineer is going to know that we can
>>>>>>>> test that X causes Y by removing only X and Y stops happening.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> So, you don't know anyone willing to go on record to support you.
>>>>>>>
>>>>>>>
>>>>>>> Guess that shows how reliable your claim its.
>>>>>>>
>>>>>>> FAIL.
>>>>>>
>>>>>> So you are claiming that when *only* the line of code that does
>>>>>> the abort is commented out and this results in the correctly
>>>>>> simulated input to H(P,P) never stopping that this does not mean
>>>>>> that that it is only the abort that causes the simulation to stop
>>>>>> IS NOT PROVEN ???
>>>>>>
>>>>>
>>>>> By Changing H, you have changed P, and thus your experement" showed
>>>>> the wrong thing,
>>>>>
>>>>
>>>> (a) I assert that it is a proven fact that H(P,P) stops running when
>>>> H is allowed to abort its simulation of P
>>>>
>>> Right.
>>>
>>> Because H has been DEFINED to abort its simulation of P (no "allowed"
>>> in there, it HAS to abort its simulation or it isn't the H you have
>>> defined)
>>>
>>>> (b) I assert that it is a proven fact that H(P,P) never stops
>>>> running when H is *NOT* allowed to abort its simulation of P
>>>
>>> Nope, because then it is no longer the H that has been defined.
>>>
>>
>> Sure it is. When you comment out a line-of-code in a function the
>> compiler absolutely will not change the name of this function and you
>> know this so why lie?
>>
>
> So you claim commenting out a statement doesn't change the behavior of
> the function?

On 9/2/22 5:07 PM, olcott wrote:
> On 9/2/2022 3:56 PM, Richard Damon wrote:
>> On 9/2/22 4:46 PM, olcott wrote:
>>> On 9/2/2022 3:38 PM, Richard Damon wrote:
>>>> On 9/2/22 4:31 PM, olcott wrote:
>>>>> On 9/2/2022 3:08 PM, Richard Damon wrote:
>>>>>> On 9/2/22 3:53 PM, olcott wrote:
>>>>>>> On 9/2/2022 2:46 PM, Richard Damon wrote:
>>>>>>>> On 9/2/22 3:38 PM, olcott wrote:
>>>>>>>>> On 9/2/2022 2:28 PM, Richard Damon wrote:
>>>>>>>>>> On 9/2/22 3:11 PM, olcott wrote:
>>>>>>>>>>> On 9/2/2022 1:21 PM, Richard Damon wrote:
>>>>>>>>>>>> On 9/2/22 1:57 PM, olcott wrote:
>>>>>>>>>>>>> On 9/2/2022 7:19 AM, Richard Damon wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 9/2/22 12:35 AM, olcott wrote:
>>>>>>>>>>>>>>> On 9/1/2022 10:32 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 9/1/22 11:26 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 9/1/2022 10:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 9/1/22 11:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:13 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:02 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 9:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 8:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 5:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 10:37 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Nope, The finite string input to H(P,P) is the
>>>>>>>>>>>>>>>>>>>>>>>> representation of P(P),
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> If this was true then when H(P,P) correctly
>>>>>>>>>>>>>>>>>>>>>>> simulates its input this simulation would stop
>>>>>>>>>>>>>>>>>>>>>>> without being aborted.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> No, because your definition of H aborts its
>>>>>>>>>>>>>>>>>>>>>> simulation
>>>>>>>>>>>>>>>>>>>>> Means that empirical testing proves that the
>>>>>>>>>>>>>>>>>>>>> simulation does not otherwise ever stop running.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Nope, because the "empirical test" you use
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> is valid, when we are working with real code on real
>>>>>>>>>>>>>>>>>>> machines empirical testing is 100% reliable.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Nope, because your "Empericl Test" isn't designed to
>>>>>>>>>>>>>>>>>> the requirements.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The requirements are simply this:
>>>>>>>>>>>>>>>>> Does the simulated input stop running if not aborted?
>>>>>>>>>>>>>>>>> Comment out the abort code and it keeps running thus: NO
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nope, you changed the input, thus the test is invalid.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No one that knows software engineering is going to buy
>>>>>>>>>>>>>>> that bullshit.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Every software engineer knows that if simply commenting
>>>>>>>>>>>>>>> out the line of code that does the abort prevents the
>>>>>>>>>>>>>>> simulation from ever stopping that the simulation does
>>>>>>>>>>>>>>> not stop without the abort.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope, and that shows your ignorance. Since you also edited
>>>>>>>>>>>>>> the program under test when you did that, you invalidated
>>>>>>>>>>>>>> the test.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You just are proving that you don't know what you are
>>>>>>>>>>>>>> talking about
>>>>>>>>>>>>>>
>>>>>>>>>>>>> You are not going to get away with those weasel words of
>>>>>>>>>>>>> double-talk.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Every competent software engineer will know with correct
>>>>>>>>>>>>> complete certainty that when commenting out the code the
>>>>>>>>>>>>> does the abort causes the the simulation to never stop that
>>>>>>>>>>>>> it is only the abort that stops
>>>>>>>>>>>>> the simulation.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Nope. Since that changes the behavior of the input, it is an
>>>>>>>>>>>> invalid operation.
>>>>>>>>>>> Every competent software engineer will agree with me and
>>>>>>>>>>> disagree with your weasel word double talk.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Name ONE.
>>>>>>>>>>
>>>>>>>>>> Make sure the understand that the input calls the decider, so
>>>>>>>>>> editing the decider changes the input.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Every competent software engineer is going to know that we can
>>>>>>>>> test that X causes Y by removing only X and Y stops happening.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> So, you don't know anyone willing to go on record to support you.
>>>>>>>>
>>>>>>>>
>>>>>>>> Guess that shows how reliable your claim its.
>>>>>>>>
>>>>>>>> FAIL.
>>>>>>>
>>>>>>> So you are claiming that when *only* the line of code that does
>>>>>>> the abort is commented out and this results in the correctly
>>>>>>> simulated input to H(P,P) never stopping that this does not mean
>>>>>>> that that it is only the abort that causes the simulation to stop
>>>>>>> IS NOT PROVEN ???
>>>>>>>
>>>>>>
>>>>>> By Changing H, you have changed P, and thus your experement"
>>>>>> showed the wrong thing,
>>>>>>
>>>>>
>>>>> (a) I assert that it is a proven fact that H(P,P) stops running
>>>>> when H is allowed to abort its simulation of P
>>>>>
>>>> Right.
>>>>
>>>> Because H has been DEFINED to abort its simulation of P (no
>>>> "allowed" in there, it HAS to abort its simulation or it isn't the H
>>>> you have defined)
>>>>
>>>>> (b) I assert that it is a proven fact that H(P,P) never stops
>>>>> running when H is *NOT* allowed to abort its simulation of P
>>>>
>>>> Nope, because then it is no longer the H that has been defined.
>>>>
>>>
>>> Sure it is. When you comment out a line-of-code in a function the
>>> compiler absolutely will not change the name of this function and you
>>> know this so why lie?
>>>
>>
>> So you claim commenting out a statement doesn't change the behavior of
>> the function?
>
> When we make one single change to H, removing its ability to abort the
> simulation of its input then this transforms the original H into a pure
> simulator.

On 9/2/2022 4:32 PM, Richard Damon wrote:
>
> On 9/2/22 5:07 PM, olcott wrote:
>> On 9/2/2022 3:56 PM, Richard Damon wrote:
>>> On 9/2/22 4:46 PM, olcott wrote:
>>>> On 9/2/2022 3:38 PM, Richard Damon wrote:
>>>>> On 9/2/22 4:31 PM, olcott wrote:
>>>>>> On 9/2/2022 3:08 PM, Richard Damon wrote:
>>>>>>> On 9/2/22 3:53 PM, olcott wrote:
>>>>>>>> On 9/2/2022 2:46 PM, Richard Damon wrote:
>>>>>>>>> On 9/2/22 3:38 PM, olcott wrote:
>>>>>>>>>> On 9/2/2022 2:28 PM, Richard Damon wrote:
>>>>>>>>>>> On 9/2/22 3:11 PM, olcott wrote:
>>>>>>>>>>>> On 9/2/2022 1:21 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 9/2/22 1:57 PM, olcott wrote:
>>>>>>>>>>>>>> On 9/2/2022 7:19 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 9/2/22 12:35 AM, olcott wrote:
>>>>>>>>>>>>>>>> On 9/1/2022 10:32 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 9/1/22 11:26 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 9/1/2022 10:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 9/1/22 11:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:13 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:02 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 9:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 8:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 5:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 10:37 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Nope, The finite string input to H(P,P) is the
>>>>>>>>>>>>>>>>>>>>>>>>> representation of P(P),
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> If this was true then when H(P,P) correctly
>>>>>>>>>>>>>>>>>>>>>>>> simulates its input this simulation would stop
>>>>>>>>>>>>>>>>>>>>>>>> without being aborted.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> No, because your definition of H aborts its
>>>>>>>>>>>>>>>>>>>>>>> simulation
>>>>>>>>>>>>>>>>>>>>>> Means that empirical testing proves that the
>>>>>>>>>>>>>>>>>>>>>> simulation does not otherwise ever stop running.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Nope, because the "empirical test" you use
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> is valid, when we are working with real code on real
>>>>>>>>>>>>>>>>>>>> machines empirical testing is 100% reliable.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Nope, because your "Empericl Test" isn't designed to
>>>>>>>>>>>>>>>>>>> the requirements.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The requirements are simply this:
>>>>>>>>>>>>>>>>>> Does the simulated input stop running if not aborted?
>>>>>>>>>>>>>>>>>> Comment out the abort code and it keeps running thus: NO
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Nope, you changed the input, thus the test is invalid.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No one that knows software engineering is going to buy
>>>>>>>>>>>>>>>> that bullshit.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Every software engineer knows that if simply commenting
>>>>>>>>>>>>>>>> out the line of code that does the abort prevents the
>>>>>>>>>>>>>>>> simulation from ever stopping that the simulation does
>>>>>>>>>>>>>>>> not stop without the abort.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Nope, and that shows your ignorance. Since you also
>>>>>>>>>>>>>>> edited the program under test when you did that, you
>>>>>>>>>>>>>>> invalidated the test.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You just are proving that you don't know what you are
>>>>>>>>>>>>>>> talking about
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You are not going to get away with those weasel words of
>>>>>>>>>>>>>> double-talk.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Every competent software engineer will know with correct
>>>>>>>>>>>>>> complete certainty that when commenting out the code the
>>>>>>>>>>>>>> does the abort causes the the simulation to never stop
>>>>>>>>>>>>>> that it is only the abort that stops
>>>>>>>>>>>>>> the simulation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nope. Since that changes the behavior of the input, it is
>>>>>>>>>>>>> an invalid operation.
>>>>>>>>>>>> Every competent software engineer will agree with me and
>>>>>>>>>>>> disagree with your weasel word double talk.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Name ONE.
>>>>>>>>>>>
>>>>>>>>>>> Make sure the understand that the input calls the decider, so
>>>>>>>>>>> editing the decider changes the input.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Every competent software engineer is going to know that we can
>>>>>>>>>> test that X causes Y by removing only X and Y stops happening.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So, you don't know anyone willing to go on record to support you.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Guess that shows how reliable your claim its.
>>>>>>>>>
>>>>>>>>> FAIL.
>>>>>>>>
>>>>>>>> So you are claiming that when *only* the line of code that does
>>>>>>>> the abort is commented out and this results in the correctly
>>>>>>>> simulated input to H(P,P) never stopping that this does not mean
>>>>>>>> that that it is only the abort that causes the simulation to
>>>>>>>> stop IS NOT PROVEN ???
>>>>>>>>
>>>>>>>
>>>>>>> By Changing H, you have changed P, and thus your experement"
>>>>>>> showed the wrong thing,
>>>>>>>
>>>>>>
>>>>>> (a) I assert that it is a proven fact that H(P,P) stops running
>>>>>> when H is allowed to abort its simulation of P
>>>>>>
>>>>> Right.
>>>>>
>>>>> Because H has been DEFINED to abort its simulation of P (no
>>>>> "allowed" in there, it HAS to abort its simulation or it isn't the
>>>>> H you have defined)
>>>>>
>>>>>> (b) I assert that it is a proven fact that H(P,P) never stops
>>>>>> running when H is *NOT* allowed to abort its simulation of P
>>>>>
>>>>> Nope, because then it is no longer the H that has been defined.
>>>>>
>>>>
>>>> Sure it is. When you comment out a line-of-code in a function the
>>>> compiler absolutely will not change the name of this function and
>>>> you know this so why lie?
>>>>
>>>
>>> So you claim commenting out a statement doesn't change the behavior
>>> of the function?
>>
>> When we make one single change to H, removing its ability to abort the
>> simulation of its input then this transforms the original H into a
>> pure simulator.
>
> Right, but P is calling the deciderm not the simulator, so you changed P
> which isn't allowed
>
>>
>> Now when we run H(P,P) and it never stops running that conclusively
>> proves that a pure simulation of the input to H(P,P) never stops running.
>>
>>
>
> Right, and you just ran H on a DIFERERNT P, so its answer is irrelevent
> to the original question.

On 9/2/22 5:37 PM, olcott wrote:
> On 9/2/2022 4:32 PM, Richard Damon wrote:
>>
>> On 9/2/22 5:07 PM, olcott wrote:
>>> On 9/2/2022 3:56 PM, Richard Damon wrote:
>>>> On 9/2/22 4:46 PM, olcott wrote:
>>>>> On 9/2/2022 3:38 PM, Richard Damon wrote:
>>>>>> On 9/2/22 4:31 PM, olcott wrote:
>>>>>>> On 9/2/2022 3:08 PM, Richard Damon wrote:
>>>>>>>> On 9/2/22 3:53 PM, olcott wrote:
>>>>>>>>> On 9/2/2022 2:46 PM, Richard Damon wrote:
>>>>>>>>>> On 9/2/22 3:38 PM, olcott wrote:
>>>>>>>>>>> On 9/2/2022 2:28 PM, Richard Damon wrote:
>>>>>>>>>>>> On 9/2/22 3:11 PM, olcott wrote:
>>>>>>>>>>>>> On 9/2/2022 1:21 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 9/2/22 1:57 PM, olcott wrote:
>>>>>>>>>>>>>>> On 9/2/2022 7:19 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 9/2/22 12:35 AM, olcott wrote:
>>>>>>>>>>>>>>>>> On 9/1/2022 10:32 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 9/1/22 11:26 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:13 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:02 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 9:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 8:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 5:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 10:37 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Nope, The finite string input to H(P,P) is the
>>>>>>>>>>>>>>>>>>>>>>>>>> representation of P(P),
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> If this was true then when H(P,P) correctly
>>>>>>>>>>>>>>>>>>>>>>>>> simulates its input this simulation would stop
>>>>>>>>>>>>>>>>>>>>>>>>> without being aborted.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> No, because your definition of H aborts its
>>>>>>>>>>>>>>>>>>>>>>>> simulation
>>>>>>>>>>>>>>>>>>>>>>> Means that empirical testing proves that the
>>>>>>>>>>>>>>>>>>>>>>> simulation does not otherwise ever stop running.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Nope, because the "empirical test" you use
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> is valid, when we are working with real code on
>>>>>>>>>>>>>>>>>>>>> real machines empirical testing is 100% reliable.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Nope, because your "Empericl Test" isn't designed to
>>>>>>>>>>>>>>>>>>>> the requirements.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The requirements are simply this:
>>>>>>>>>>>>>>>>>>> Does the simulated input stop running if not aborted?
>>>>>>>>>>>>>>>>>>> Comment out the abort code and it keeps running thus: NO
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Nope, you changed the input, thus the test is invalid.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No one that knows software engineering is going to buy
>>>>>>>>>>>>>>>>> that bullshit.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Every software engineer knows that if simply commenting
>>>>>>>>>>>>>>>>> out the line of code that does the abort prevents the
>>>>>>>>>>>>>>>>> simulation from ever stopping that the simulation does
>>>>>>>>>>>>>>>>> not stop without the abort.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nope, and that shows your ignorance. Since you also
>>>>>>>>>>>>>>>> edited the program under test when you did that, you
>>>>>>>>>>>>>>>> invalidated the test.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You just are proving that you don't know what you are
>>>>>>>>>>>>>>>> talking about
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You are not going to get away with those weasel words of
>>>>>>>>>>>>>>> double-talk.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Every competent software engineer will know with correct
>>>>>>>>>>>>>>> complete certainty that when commenting out the code the
>>>>>>>>>>>>>>> does the abort causes the the simulation to never stop
>>>>>>>>>>>>>>> that it is only the abort that stops
>>>>>>>>>>>>>>> the simulation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope. Since that changes the behavior of the input, it is
>>>>>>>>>>>>>> an invalid operation.
>>>>>>>>>>>>> Every competent software engineer will agree with me and
>>>>>>>>>>>>> disagree with your weasel word double talk.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Name ONE.
>>>>>>>>>>>>
>>>>>>>>>>>> Make sure the understand that the input calls the decider,
>>>>>>>>>>>> so editing the decider changes the input.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Every competent software engineer is going to know that we
>>>>>>>>>>> can test that X causes Y by removing only X and Y stops
>>>>>>>>>>> happening.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So, you don't know anyone willing to go on record to support you.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Guess that shows how reliable your claim its.
>>>>>>>>>>
>>>>>>>>>> FAIL.
>>>>>>>>>
>>>>>>>>> So you are claiming that when *only* the line of code that does
>>>>>>>>> the abort is commented out and this results in the correctly
>>>>>>>>> simulated input to H(P,P) never stopping that this does not
>>>>>>>>> mean that that it is only the abort that causes the simulation
>>>>>>>>> to stop IS NOT PROVEN ???
>>>>>>>>>
>>>>>>>>
>>>>>>>> By Changing H, you have changed P, and thus your experement"
>>>>>>>> showed the wrong thing,
>>>>>>>>
>>>>>>>
>>>>>>> (a) I assert that it is a proven fact that H(P,P) stops running
>>>>>>> when H is allowed to abort its simulation of P
>>>>>>>
>>>>>> Right.
>>>>>>
>>>>>> Because H has been DEFINED to abort its simulation of P (no
>>>>>> "allowed" in there, it HAS to abort its simulation or it isn't the
>>>>>> H you have defined)
>>>>>>
>>>>>>> (b) I assert that it is a proven fact that H(P,P) never stops
>>>>>>> running when H is *NOT* allowed to abort its simulation of P
>>>>>>
>>>>>> Nope, because then it is no longer the H that has been defined.
>>>>>>
>>>>>
>>>>> Sure it is. When you comment out a line-of-code in a function the
>>>>> compiler absolutely will not change the name of this function and
>>>>> you know this so why lie?
>>>>>
>>>>
>>>> So you claim commenting out a statement doesn't change the behavior
>>>> of the function?
>>>
>>> When we make one single change to H, removing its ability to abort
>>> the simulation of its input then this transforms the original H into
>>> a pure simulator.
>>
>> Right, but P is calling the deciderm not the simulator, so you changed
>> P which isn't allowed
>>
>>>
>>> Now when we run H(P,P) and it never stops running that conclusively
>>> proves that a pure simulation of the input to H(P,P) never stops
>>> running.
>>>
>>>
>>
>> Right, and you just ran H on a DIFERERNT P, so its answer is
>> irrelevent to the original question.
>
> Every competent software engineer knows that my proof is correct.

On 9/2/2022 4:49 PM, Richard Damon wrote:
> On 9/2/22 5:37 PM, olcott wrote:
>> On 9/2/2022 4:32 PM, Richard Damon wrote:
>>>
>>> On 9/2/22 5:07 PM, olcott wrote:
>>>> On 9/2/2022 3:56 PM, Richard Damon wrote:
>>>>> On 9/2/22 4:46 PM, olcott wrote:
>>>>>> On 9/2/2022 3:38 PM, Richard Damon wrote:
>>>>>>> On 9/2/22 4:31 PM, olcott wrote:
>>>>>>>> On 9/2/2022 3:08 PM, Richard Damon wrote:
>>>>>>>>> On 9/2/22 3:53 PM, olcott wrote:
>>>>>>>>>> On 9/2/2022 2:46 PM, Richard Damon wrote:
>>>>>>>>>>> On 9/2/22 3:38 PM, olcott wrote:
>>>>>>>>>>>> On 9/2/2022 2:28 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 9/2/22 3:11 PM, olcott wrote:
>>>>>>>>>>>>>> On 9/2/2022 1:21 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 9/2/22 1:57 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 9/2/2022 7:19 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 9/2/22 12:35 AM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 9/1/2022 10:32 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 9/1/22 11:26 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:13 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:02 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 9:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 8:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 5:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 10:37 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Nope, The finite string input to H(P,P) is
>>>>>>>>>>>>>>>>>>>>>>>>>>> the representation of P(P),
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> If this was true then when H(P,P) correctly
>>>>>>>>>>>>>>>>>>>>>>>>>> simulates its input this simulation would stop
>>>>>>>>>>>>>>>>>>>>>>>>>> without being aborted.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> No, because your definition of H aborts its
>>>>>>>>>>>>>>>>>>>>>>>>> simulation
>>>>>>>>>>>>>>>>>>>>>>>> Means that empirical testing proves that the
>>>>>>>>>>>>>>>>>>>>>>>> simulation does not otherwise ever stop running.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Nope, because the "empirical test" you use
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> is valid, when we are working with real code on
>>>>>>>>>>>>>>>>>>>>>> real machines empirical testing is 100% reliable.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Nope, because your "Empericl Test" isn't designed
>>>>>>>>>>>>>>>>>>>>> to the requirements.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The requirements are simply this:
>>>>>>>>>>>>>>>>>>>> Does the simulated input stop running if not aborted?
>>>>>>>>>>>>>>>>>>>> Comment out the abort code and it keeps running
>>>>>>>>>>>>>>>>>>>> thus: NO
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Nope, you changed the input, thus the test is invalid.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> No one that knows software engineering is going to buy
>>>>>>>>>>>>>>>>>> that bullshit.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Every software engineer knows that if simply
>>>>>>>>>>>>>>>>>> commenting out the line of code that does the abort
>>>>>>>>>>>>>>>>>> prevents the simulation from ever stopping that the
>>>>>>>>>>>>>>>>>> simulation does not stop without the abort.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Nope, and that shows your ignorance. Since you also
>>>>>>>>>>>>>>>>> edited the program under test when you did that, you
>>>>>>>>>>>>>>>>> invalidated the test.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You just are proving that you don't know what you are
>>>>>>>>>>>>>>>>> talking about
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You are not going to get away with those weasel words of
>>>>>>>>>>>>>>>> double-talk.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Every competent software engineer will know with correct
>>>>>>>>>>>>>>>> complete certainty that when commenting out the code the
>>>>>>>>>>>>>>>> does the abort causes the the simulation to never stop
>>>>>>>>>>>>>>>> that it is only the abort that stops
>>>>>>>>>>>>>>>> the simulation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Nope. Since that changes the behavior of the input, it is
>>>>>>>>>>>>>>> an invalid operation.
>>>>>>>>>>>>>> Every competent software engineer will agree with me and
>>>>>>>>>>>>>> disagree with your weasel word double talk.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Name ONE.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Make sure the understand that the input calls the decider,
>>>>>>>>>>>>> so editing the decider changes the input.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Every competent software engineer is going to know that we
>>>>>>>>>>>> can test that X causes Y by removing only X and Y stops
>>>>>>>>>>>> happening.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So, you don't know anyone willing to go on record to support
>>>>>>>>>>> you.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Guess that shows how reliable your claim its.
>>>>>>>>>>>
>>>>>>>>>>> FAIL.
>>>>>>>>>>
>>>>>>>>>> So you are claiming that when *only* the line of code that
>>>>>>>>>> does the abort is commented out and this results in the
>>>>>>>>>> correctly simulated input to H(P,P) never stopping that this
>>>>>>>>>> does not mean that that it is only the abort that causes the
>>>>>>>>>> simulation to stop IS NOT PROVEN ???
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> By Changing H, you have changed P, and thus your experement"
>>>>>>>>> showed the wrong thing,
>>>>>>>>>
>>>>>>>>
>>>>>>>> (a) I assert that it is a proven fact that H(P,P) stops running
>>>>>>>> when H is allowed to abort its simulation of P
>>>>>>>>
>>>>>>> Right.
>>>>>>>
>>>>>>> Because H has been DEFINED to abort its simulation of P (no
>>>>>>> "allowed" in there, it HAS to abort its simulation or it isn't
>>>>>>> the H you have defined)
>>>>>>>
>>>>>>>> (b) I assert that it is a proven fact that H(P,P) never stops
>>>>>>>> running when H is *NOT* allowed to abort its simulation of P
>>>>>>>
>>>>>>> Nope, because then it is no longer the H that has been defined.
>>>>>>>
>>>>>>
>>>>>> Sure it is. When you comment out a line-of-code in a function the
>>>>>> compiler absolutely will not change the name of this function and
>>>>>> you know this so why lie?
>>>>>>
>>>>>
>>>>> So you claim commenting out a statement doesn't change the behavior
>>>>> of the function?
>>>>
>>>> When we make one single change to H, removing its ability to abort
>>>> the simulation of its input then this transforms the original H into
>>>> a pure simulator.
>>>
>>> Right, but P is calling the deciderm not the simulator, so you
>>> changed P which isn't allowed
>>>
>>>>
>>>> Now when we run H(P,P) and it never stops running that conclusively
>>>> proves that a pure simulation of the input to H(P,P) never stops
>>>> running.
>>>>
>>>>
>>>
>>> Right, and you just ran H on a DIFERERNT P, so its answer is
>>> irrelevent to the original question.
>>
>> Every competent software engineer knows that my proof is correct.
>
> FALSE.
>
> Name one.
>
> You are just proven to be a liar.
>
> I have checked with a couple of very competent software engineers I
> know, and none of them agree with you, so you claim is proven false by
> example. You are making the fallacy of Ad Populum without even having
> the populum.
>
>>
>> That you play silly games with naming conventions is just like Zeno's
>> paradox that "proves" it is impossible to cross the room to get to the
>> other side.
>
> Nope, that you call then "silly games with naming conventions" just
> proves you don't understand what you are talking about.
>
>>
>> https://owlcation.com/stem/understanding-and-solving-Zenos-paradox#:~:text=In%20its%20simplest%20form%2C%20Zeno's,before%20reaching%20the%20stationary%20ball.
>>
>
> Red Herring.
>

On 9/2/22 5:56 PM, olcott wrote:
> On 9/2/2022 4:49 PM, Richard Damon wrote:
>> On 9/2/22 5:37 PM, olcott wrote:
>>> On 9/2/2022 4:32 PM, Richard Damon wrote:
>>>>
>>>> On 9/2/22 5:07 PM, olcott wrote:
>>>>> On 9/2/2022 3:56 PM, Richard Damon wrote:
>>>>>> On 9/2/22 4:46 PM, olcott wrote:
>>>>>>> On 9/2/2022 3:38 PM, Richard Damon wrote:
>>>>>>>> On 9/2/22 4:31 PM, olcott wrote:
>>>>>>>>> On 9/2/2022 3:08 PM, Richard Damon wrote:
>>>>>>>>>> On 9/2/22 3:53 PM, olcott wrote:
>>>>>>>>>>> On 9/2/2022 2:46 PM, Richard Damon wrote:
>>>>>>>>>>>> On 9/2/22 3:38 PM, olcott wrote:
>>>>>>>>>>>>> On 9/2/2022 2:28 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 9/2/22 3:11 PM, olcott wrote:
>>>>>>>>>>>>>>> On 9/2/2022 1:21 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 9/2/22 1:57 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 9/2/2022 7:19 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 9/2/22 12:35 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:32 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:26 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:13 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:02 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 9:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 8:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 5:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 10:37 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nope, The finite string input to H(P,P) is
>>>>>>>>>>>>>>>>>>>>>>>>>>>> the representation of P(P),
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> If this was true then when H(P,P) correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates its input this simulation would
>>>>>>>>>>>>>>>>>>>>>>>>>>> stop without being aborted.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> No, because your definition of H aborts its
>>>>>>>>>>>>>>>>>>>>>>>>>> simulation
>>>>>>>>>>>>>>>>>>>>>>>>> Means that empirical testing proves that the
>>>>>>>>>>>>>>>>>>>>>>>>> simulation does not otherwise ever stop running.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Nope, because the "empirical test" you use
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> is valid, when we are working with real code on
>>>>>>>>>>>>>>>>>>>>>>> real machines empirical testing is 100% reliable.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Nope, because your "Empericl Test" isn't designed
>>>>>>>>>>>>>>>>>>>>>> to the requirements.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The requirements are simply this:
>>>>>>>>>>>>>>>>>>>>> Does the simulated input stop running if not aborted?
>>>>>>>>>>>>>>>>>>>>> Comment out the abort code and it keeps running
>>>>>>>>>>>>>>>>>>>>> thus: NO
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Nope, you changed the input, thus the test is invalid.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> No one that knows software engineering is going to
>>>>>>>>>>>>>>>>>>> buy that bullshit.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Every software engineer knows that if simply
>>>>>>>>>>>>>>>>>>> commenting out the line of code that does the abort
>>>>>>>>>>>>>>>>>>> prevents the simulation from ever stopping that the
>>>>>>>>>>>>>>>>>>> simulation does not stop without the abort.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Nope, and that shows your ignorance. Since you also
>>>>>>>>>>>>>>>>>> edited the program under test when you did that, you
>>>>>>>>>>>>>>>>>> invalidated the test.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You just are proving that you don't know what you are
>>>>>>>>>>>>>>>>>> talking about
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You are not going to get away with those weasel words
>>>>>>>>>>>>>>>>> of double-talk.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Every competent software engineer will know with
>>>>>>>>>>>>>>>>> correct complete certainty that when commenting out the
>>>>>>>>>>>>>>>>> code the does the abort causes the the simulation to
>>>>>>>>>>>>>>>>> never stop that it is only the abort that stops
>>>>>>>>>>>>>>>>> the simulation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nope. Since that changes the behavior of the input, it
>>>>>>>>>>>>>>>> is an invalid operation.
>>>>>>>>>>>>>>> Every competent software engineer will agree with me and
>>>>>>>>>>>>>>> disagree with your weasel word double talk.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Name ONE.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Make sure the understand that the input calls the decider,
>>>>>>>>>>>>>> so editing the decider changes the input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Every competent software engineer is going to know that we
>>>>>>>>>>>>> can test that X causes Y by removing only X and Y stops
>>>>>>>>>>>>> happening.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> So, you don't know anyone willing to go on record to support
>>>>>>>>>>>> you.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Guess that shows how reliable your claim its.
>>>>>>>>>>>>
>>>>>>>>>>>> FAIL.
>>>>>>>>>>>
>>>>>>>>>>> So you are claiming that when *only* the line of code that
>>>>>>>>>>> does the abort is commented out and this results in the
>>>>>>>>>>> correctly simulated input to H(P,P) never stopping that this
>>>>>>>>>>> does not mean that that it is only the abort that causes the
>>>>>>>>>>> simulation to stop IS NOT PROVEN ???
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> By Changing H, you have changed P, and thus your experement"
>>>>>>>>>> showed the wrong thing,
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> (a) I assert that it is a proven fact that H(P,P) stops running
>>>>>>>>> when H is allowed to abort its simulation of P
>>>>>>>>>
>>>>>>>> Right.
>>>>>>>>
>>>>>>>> Because H has been DEFINED to abort its simulation of P (no
>>>>>>>> "allowed" in there, it HAS to abort its simulation or it isn't
>>>>>>>> the H you have defined)
>>>>>>>>
>>>>>>>>> (b) I assert that it is a proven fact that H(P,P) never stops
>>>>>>>>> running when H is *NOT* allowed to abort its simulation of P
>>>>>>>>
>>>>>>>> Nope, because then it is no longer the H that has been defined.
>>>>>>>>
>>>>>>>
>>>>>>> Sure it is. When you comment out a line-of-code in a function the
>>>>>>> compiler absolutely will not change the name of this function and
>>>>>>> you know this so why lie?
>>>>>>>
>>>>>>
>>>>>> So you claim commenting out a statement doesn't change the
>>>>>> behavior of the function?
>>>>>
>>>>> When we make one single change to H, removing its ability to abort
>>>>> the simulation of its input then this transforms the original H
>>>>> into a pure simulator.
>>>>
>>>> Right, but P is calling the deciderm not the simulator, so you
>>>> changed P which isn't allowed
>>>>
>>>>>
>>>>> Now when we run H(P,P) and it never stops running that conclusively
>>>>> proves that a pure simulation of the input to H(P,P) never stops
>>>>> running.
>>>>>
>>>>>
>>>>
>>>> Right, and you just ran H on a DIFERERNT P, so its answer is
>>>> irrelevent to the original question.
>>>
>>> Every competent software engineer knows that my proof is correct.
>>
>> FALSE.
>>
>> Name one.
>>
>> You are just proven to be a liar.
>>
>> I have checked with a couple of very competent software engineers I
>> know, and none of them agree with you, so you claim is proven false by
>> example. You are making the fallacy of Ad Populum without even having
>> the populum.
>>
>>>
>>> That you play silly games with naming conventions is just like Zeno's
>>> paradox that "proves" it is impossible to cross the room to get to
>>> the other side.
>>
>> Nope, that you call then "silly games with naming conventions" just
>> proves you don't understand what you are talking about.
>>
>>>
>>> https://owlcation.com/stem/understanding-and-solving-Zenos-paradox#:~:text=In%20its%20simplest%20form%2C%20Zeno's,before%20reaching%20the%20stationary%20ball.
>>>
>>>
>>
>> Red Herring.
>>
>
> Zeno mathematically proved that two items cannot possibly touch thus
> when two items touch the proof is refuted.

On 9/2/2022 5:05 PM, Richard Damon wrote:
> On 9/2/22 5:56 PM, olcott wrote:
>> On 9/2/2022 4:49 PM, Richard Damon wrote:
>>> On 9/2/22 5:37 PM, olcott wrote:
>>>> On 9/2/2022 4:32 PM, Richard Damon wrote:
>>>>>
>>>>> On 9/2/22 5:07 PM, olcott wrote:
>>>>>> On 9/2/2022 3:56 PM, Richard Damon wrote:
>>>>>>> On 9/2/22 4:46 PM, olcott wrote:
>>>>>>>> On 9/2/2022 3:38 PM, Richard Damon wrote:
>>>>>>>>> On 9/2/22 4:31 PM, olcott wrote:
>>>>>>>>>> On 9/2/2022 3:08 PM, Richard Damon wrote:
>>>>>>>>>>> On 9/2/22 3:53 PM, olcott wrote:
>>>>>>>>>>>> On 9/2/2022 2:46 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 9/2/22 3:38 PM, olcott wrote:
>>>>>>>>>>>>>> On 9/2/2022 2:28 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 9/2/22 3:11 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 9/2/2022 1:21 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 9/2/22 1:57 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 9/2/2022 7:19 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 9/2/22 12:35 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:32 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:26 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:13 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:02 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 9:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 8:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 5:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 10:37 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nope, The finite string input to H(P,P) is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the representation of P(P),
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> If this was true then when H(P,P) correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates its input this simulation would
>>>>>>>>>>>>>>>>>>>>>>>>>>>> stop without being aborted.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> No, because your definition of H aborts its
>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation
>>>>>>>>>>>>>>>>>>>>>>>>>> Means that empirical testing proves that the
>>>>>>>>>>>>>>>>>>>>>>>>>> simulation does not otherwise ever stop running.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Nope, because the "empirical test" you use
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> is valid, when we are working with real code on
>>>>>>>>>>>>>>>>>>>>>>>> real machines empirical testing is 100% reliable.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Nope, because your "Empericl Test" isn't designed
>>>>>>>>>>>>>>>>>>>>>>> to the requirements.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The requirements are simply this:
>>>>>>>>>>>>>>>>>>>>>> Does the simulated input stop running if not aborted?
>>>>>>>>>>>>>>>>>>>>>> Comment out the abort code and it keeps running
>>>>>>>>>>>>>>>>>>>>>> thus: NO
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Nope, you changed the input, thus the test is invalid.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> No one that knows software engineering is going to
>>>>>>>>>>>>>>>>>>>> buy that bullshit.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Every software engineer knows that if simply
>>>>>>>>>>>>>>>>>>>> commenting out the line of code that does the abort
>>>>>>>>>>>>>>>>>>>> prevents the simulation from ever stopping that the
>>>>>>>>>>>>>>>>>>>> simulation does not stop without the abort.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Nope, and that shows your ignorance. Since you also
>>>>>>>>>>>>>>>>>>> edited the program under test when you did that, you
>>>>>>>>>>>>>>>>>>> invalidated the test.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> You just are proving that you don't know what you are
>>>>>>>>>>>>>>>>>>> talking about
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You are not going to get away with those weasel words
>>>>>>>>>>>>>>>>>> of double-talk.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Every competent software engineer will know with
>>>>>>>>>>>>>>>>>> correct complete certainty that when commenting out
>>>>>>>>>>>>>>>>>> the code the does the abort causes the the simulation
>>>>>>>>>>>>>>>>>> to never stop that it is only the abort that stops
>>>>>>>>>>>>>>>>>> the simulation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Nope. Since that changes the behavior of the input, it
>>>>>>>>>>>>>>>>> is an invalid operation.
>>>>>>>>>>>>>>>> Every competent software engineer will agree with me and
>>>>>>>>>>>>>>>> disagree with your weasel word double talk.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Name ONE.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Make sure the understand that the input calls the
>>>>>>>>>>>>>>> decider, so editing the decider changes the input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Every competent software engineer is going to know that we
>>>>>>>>>>>>>> can test that X causes Y by removing only X and Y stops
>>>>>>>>>>>>>> happening.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, you don't know anyone willing to go on record to
>>>>>>>>>>>>> support you.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Guess that shows how reliable your claim its.
>>>>>>>>>>>>>
>>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>
>>>>>>>>>>>> So you are claiming that when *only* the line of code that
>>>>>>>>>>>> does the abort is commented out and this results in the
>>>>>>>>>>>> correctly simulated input to H(P,P) never stopping that this
>>>>>>>>>>>> does not mean that that it is only the abort that causes the
>>>>>>>>>>>> simulation to stop IS NOT PROVEN ???
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> By Changing H, you have changed P, and thus your experement"
>>>>>>>>>>> showed the wrong thing,
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> (a) I assert that it is a proven fact that H(P,P) stops
>>>>>>>>>> running when H is allowed to abort its simulation of P
>>>>>>>>>>
>>>>>>>>> Right.
>>>>>>>>>
>>>>>>>>> Because H has been DEFINED to abort its simulation of P (no
>>>>>>>>> "allowed" in there, it HAS to abort its simulation or it isn't
>>>>>>>>> the H you have defined)
>>>>>>>>>
>>>>>>>>>> (b) I assert that it is a proven fact that H(P,P) never stops
>>>>>>>>>> running when H is *NOT* allowed to abort its simulation of P
>>>>>>>>>
>>>>>>>>> Nope, because then it is no longer the H that has been defined.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Sure it is. When you comment out a line-of-code in a function
>>>>>>>> the compiler absolutely will not change the name of this
>>>>>>>> function and you know this so why lie?
>>>>>>>>
>>>>>>>
>>>>>>> So you claim commenting out a statement doesn't change the
>>>>>>> behavior of the function?
>>>>>>
>>>>>> When we make one single change to H, removing its ability to abort
>>>>>> the simulation of its input then this transforms the original H
>>>>>> into a pure simulator.
>>>>>
>>>>> Right, but P is calling the deciderm not the simulator, so you
>>>>> changed P which isn't allowed
>>>>>
>>>>>>
>>>>>> Now when we run H(P,P) and it never stops running that
>>>>>> conclusively proves that a pure simulation of the input to H(P,P)
>>>>>> never stops running.
>>>>>>
>>>>>>
>>>>>
>>>>> Right, and you just ran H on a DIFERERNT P, so its answer is
>>>>> irrelevent to the original question.
>>>>
>>>> Every competent software engineer knows that my proof is correct.
>>>
>>> FALSE.
>>>
>>> Name one.
>>>
>>> You are just proven to be a liar.
>>>
>>> I have checked with a couple of very competent software engineers I
>>> know, and none of them agree with you, so you claim is proven false
>>> by example. You are making the fallacy of Ad Populum without even
>>> having the populum.
>>>
>>>>
>>>> That you play silly games with naming conventions is just like
>>>> Zeno's paradox that "proves" it is impossible to cross the room to
>>>> get to the other side.
>>>
>>> Nope, that you call then "silly games with naming conventions" just
>>> proves you don't understand what you are talking about.
>>>
>>>>
>>>> https://owlcation.com/stem/understanding-and-solving-Zenos-paradox#:~:text=In%20its%20simplest%20form%2C%20Zeno's,before%20reaching%20the%20stationary%20ball.
>>>>
>>>
>>> Red Herring.
>>>
>>
>> Zeno mathematically proved that two items cannot possibly touch thus
>> when two items touch the proof is refuted.
>
> No, Zeno made the error that an infintly long sum might sum to a finite
> value.
>
>>
>> When we make one single change to H, removing its ability to abort the
>> simulation of its input then this transforms the original H into a
>> pure simulator.
>
> Right, which is a DIFFERENT computation, and thus when you processs the
> MODIFIED P that you get from that change you haven't proven anything
> about the original
>
> Your references to Zeno are just a Red Herring Fallacy.
>
>
>>
>> *THIS IS TRUE ON THE BASIS OF THE MEANING OF ITS WORDS*
>
> Nope. You have wrong meanings to the words.
>
>> Now when we run H(P,P) and it never stops running that conclusively
>> proves that a pure simulation of the input to H(P,P) never stops running.
>>
>
> No, because you CAN'T run H and have it never stop running, becaue you
> have DEFINED (by publishing the code for the H you claim is correct).

On 9/2/22 6:21 PM, olcott wrote:
> On 9/2/2022 5:05 PM, Richard Damon wrote:
>> On 9/2/22 5:56 PM, olcott wrote:
>>> On 9/2/2022 4:49 PM, Richard Damon wrote:
>>>> On 9/2/22 5:37 PM, olcott wrote:
>>>>> On 9/2/2022 4:32 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 9/2/22 5:07 PM, olcott wrote:
>>>>>>> On 9/2/2022 3:56 PM, Richard Damon wrote:
>>>>>>>> On 9/2/22 4:46 PM, olcott wrote:
>>>>>>>>> On 9/2/2022 3:38 PM, Richard Damon wrote:
>>>>>>>>>> On 9/2/22 4:31 PM, olcott wrote:
>>>>>>>>>>> On 9/2/2022 3:08 PM, Richard Damon wrote:
>>>>>>>>>>>> On 9/2/22 3:53 PM, olcott wrote:
>>>>>>>>>>>>> On 9/2/2022 2:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 9/2/22 3:38 PM, olcott wrote:
>>>>>>>>>>>>>>> On 9/2/2022 2:28 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 9/2/22 3:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 9/2/2022 1:21 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 9/2/22 1:57 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 9/2/2022 7:19 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 9/2/22 12:35 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:32 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:26 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:13 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:02 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 9:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 8:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 5:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 10:37 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nope, The finite string input to H(P,P) is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the representation of P(P),
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If this was true then when H(P,P) correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates its input this simulation would
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stop without being aborted.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, because your definition of H aborts its
>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>> Means that empirical testing proves that the
>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation does not otherwise ever stop running.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Nope, because the "empirical test" you use
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> is valid, when we are working with real code on
>>>>>>>>>>>>>>>>>>>>>>>>> real machines empirical testing is 100% reliable.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Nope, because your "Empericl Test" isn't
>>>>>>>>>>>>>>>>>>>>>>>> designed to the requirements.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The requirements are simply this:
>>>>>>>>>>>>>>>>>>>>>>> Does the simulated input stop running if not
>>>>>>>>>>>>>>>>>>>>>>> aborted?
>>>>>>>>>>>>>>>>>>>>>>> Comment out the abort code and it keeps running
>>>>>>>>>>>>>>>>>>>>>>> thus: NO
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Nope, you changed the input, thus the test is
>>>>>>>>>>>>>>>>>>>>>> invalid.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> No one that knows software engineering is going to
>>>>>>>>>>>>>>>>>>>>> buy that bullshit.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Every software engineer knows that if simply
>>>>>>>>>>>>>>>>>>>>> commenting out the line of code that does the abort
>>>>>>>>>>>>>>>>>>>>> prevents the simulation from ever stopping that the
>>>>>>>>>>>>>>>>>>>>> simulation does not stop without the abort.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Nope, and that shows your ignorance. Since you also
>>>>>>>>>>>>>>>>>>>> edited the program under test when you did that, you
>>>>>>>>>>>>>>>>>>>> invalidated the test.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You just are proving that you don't know what you
>>>>>>>>>>>>>>>>>>>> are talking about
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> You are not going to get away with those weasel words
>>>>>>>>>>>>>>>>>>> of double-talk.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Every competent software engineer will know with
>>>>>>>>>>>>>>>>>>> correct complete certainty that when commenting out
>>>>>>>>>>>>>>>>>>> the code the does the abort causes the the simulation
>>>>>>>>>>>>>>>>>>> to never stop that it is only the abort that stops
>>>>>>>>>>>>>>>>>>> the simulation.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Nope. Since that changes the behavior of the input, it
>>>>>>>>>>>>>>>>>> is an invalid operation.
>>>>>>>>>>>>>>>>> Every competent software engineer will agree with me
>>>>>>>>>>>>>>>>> and disagree with your weasel word double talk.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Name ONE.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Make sure the understand that the input calls the
>>>>>>>>>>>>>>>> decider, so editing the decider changes the input.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Every competent software engineer is going to know that
>>>>>>>>>>>>>>> we can test that X causes Y by removing only X and Y
>>>>>>>>>>>>>>> stops happening.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, you don't know anyone willing to go on record to
>>>>>>>>>>>>>> support you.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Guess that shows how reliable your claim its.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So you are claiming that when *only* the line of code that
>>>>>>>>>>>>> does the abort is commented out and this results in the
>>>>>>>>>>>>> correctly simulated input to H(P,P) never stopping that
>>>>>>>>>>>>> this does not mean that that it is only the abort that
>>>>>>>>>>>>> causes the simulation to stop IS NOT PROVEN ???
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> By Changing H, you have changed P, and thus your experement"
>>>>>>>>>>>> showed the wrong thing,
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> (a) I assert that it is a proven fact that H(P,P) stops
>>>>>>>>>>> running when H is allowed to abort its simulation of P
>>>>>>>>>>>
>>>>>>>>>> Right.
>>>>>>>>>>
>>>>>>>>>> Because H has been DEFINED to abort its simulation of P (no
>>>>>>>>>> "allowed" in there, it HAS to abort its simulation or it isn't
>>>>>>>>>> the H you have defined)
>>>>>>>>>>
>>>>>>>>>>> (b) I assert that it is a proven fact that H(P,P) never stops
>>>>>>>>>>> running when H is *NOT* allowed to abort its simulation of P
>>>>>>>>>>
>>>>>>>>>> Nope, because then it is no longer the H that has been defined.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Sure it is. When you comment out a line-of-code in a function
>>>>>>>>> the compiler absolutely will not change the name of this
>>>>>>>>> function and you know this so why lie?
>>>>>>>>>
>>>>>>>>
>>>>>>>> So you claim commenting out a statement doesn't change the
>>>>>>>> behavior of the function?
>>>>>>>
>>>>>>> When we make one single change to H, removing its ability to
>>>>>>> abort the simulation of its input then this transforms the
>>>>>>> original H into a pure simulator.
>>>>>>
>>>>>> Right, but P is calling the deciderm not the simulator, so you
>>>>>> changed P which isn't allowed
>>>>>>
>>>>>>>
>>>>>>> Now when we run H(P,P) and it never stops running that
>>>>>>> conclusively proves that a pure simulation of the input to H(P,P)
>>>>>>> never stops running.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Right, and you just ran H on a DIFERERNT P, so its answer is
>>>>>> irrelevent to the original question.
>>>>>
>>>>> Every competent software engineer knows that my proof is correct.
>>>>
>>>> FALSE.
>>>>
>>>> Name one.
>>>>
>>>> You are just proven to be a liar.
>>>>
>>>> I have checked with a couple of very competent software engineers I
>>>> know, and none of them agree with you, so you claim is proven false
>>>> by example. You are making the fallacy of Ad Populum without even
>>>> having the populum.
>>>>
>>>>>
>>>>> That you play silly games with naming conventions is just like
>>>>> Zeno's paradox that "proves" it is impossible to cross the room to
>>>>> get to the other side.
>>>>
>>>> Nope, that you call then "silly games with naming conventions" just
>>>> proves you don't understand what you are talking about.
>>>>
>>>>>
>>>>> https://owlcation.com/stem/understanding-and-solving-Zenos-paradox#:~:text=In%20its%20simplest%20form%2C%20Zeno's,before%20reaching%20the%20stationary%20ball.
>>>>>
>>>>>
>>>>
>>>> Red Herring.
>>>>
>>>
>>> Zeno mathematically proved that two items cannot possibly touch thus
>>> when two items touch the proof is refuted.
>>
>> No, Zeno made the error that an infintly long sum might sum to a
>> finite value.
>>
>>>
>>> When we make one single change to H, removing its ability to abort
>>> the simulation of its input then this transforms the original H into
>>> a pure simulator.
>>
>> Right, which is a DIFFERENT computation, and thus when you processs
>> the MODIFIED P that you get from that change you haven't proven
>> anything about the original
>>
>> Your references to Zeno are just a Red Herring Fallacy.
>>
>>
>>>
>>> *THIS IS TRUE ON THE BASIS OF THE MEANING OF ITS WORDS*
>>
>> Nope. You have wrong meanings to the words.
>>
>>> Now when we run H(P,P) and it never stops running that conclusively
>>> proves that a pure simulation of the input to H(P,P) never stops
>>> running.
>>>
>>
>> No, because you CAN'T run H and have it never stop running, becaue you
>> have DEFINED (by publishing the code for the H you claim is correct).
>
> It is an easily verified fact that the only reason that H(P,P) ever
> stops running is that H aborts the simulation of its input.

On 9/2/2022 5:41 PM, Richard Damon wrote:
> On 9/2/22 6:21 PM, olcott wrote:
>> On 9/2/2022 5:05 PM, Richard Damon wrote:
>>> On 9/2/22 5:56 PM, olcott wrote:
>>>> On 9/2/2022 4:49 PM, Richard Damon wrote:
>>>>> On 9/2/22 5:37 PM, olcott wrote:
>>>>>> On 9/2/2022 4:32 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 9/2/22 5:07 PM, olcott wrote:
>>>>>>>> On 9/2/2022 3:56 PM, Richard Damon wrote:
>>>>>>>>> On 9/2/22 4:46 PM, olcott wrote:
>>>>>>>>>> On 9/2/2022 3:38 PM, Richard Damon wrote:
>>>>>>>>>>> On 9/2/22 4:31 PM, olcott wrote:
>>>>>>>>>>>> On 9/2/2022 3:08 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 9/2/22 3:53 PM, olcott wrote:
>>>>>>>>>>>>>> On 9/2/2022 2:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 9/2/22 3:38 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 9/2/2022 2:28 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 9/2/22 3:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 9/2/2022 1:21 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 9/2/22 1:57 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 9/2/2022 7:19 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 9/2/22 12:35 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:32 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:26 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:13 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:02 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 9:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 8:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 5:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 10:37 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nope, The finite string input to H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is the representation of P(P),
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If this was true then when H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correctly simulates its input this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation would stop without being aborted.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, because your definition of H aborts its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Means that empirical testing proves that the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation does not otherwise ever stop
>>>>>>>>>>>>>>>>>>>>>>>>>>>> running.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Nope, because the "empirical test" you use
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> is valid, when we are working with real code
>>>>>>>>>>>>>>>>>>>>>>>>>> on real machines empirical testing is 100%
>>>>>>>>>>>>>>>>>>>>>>>>>> reliable.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Nope, because your "Empericl Test" isn't
>>>>>>>>>>>>>>>>>>>>>>>>> designed to the requirements.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> The requirements are simply this:
>>>>>>>>>>>>>>>>>>>>>>>> Does the simulated input stop running if not
>>>>>>>>>>>>>>>>>>>>>>>> aborted?
>>>>>>>>>>>>>>>>>>>>>>>> Comment out the abort code and it keeps running
>>>>>>>>>>>>>>>>>>>>>>>> thus: NO
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Nope, you changed the input, thus the test is
>>>>>>>>>>>>>>>>>>>>>>> invalid.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> No one that knows software engineering is going to
>>>>>>>>>>>>>>>>>>>>>> buy that bullshit.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Every software engineer knows that if simply
>>>>>>>>>>>>>>>>>>>>>> commenting out the line of code that does the
>>>>>>>>>>>>>>>>>>>>>> abort prevents the simulation from ever stopping
>>>>>>>>>>>>>>>>>>>>>> that the simulation does not stop without the abort.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Nope, and that shows your ignorance. Since you also
>>>>>>>>>>>>>>>>>>>>> edited the program under test when you did that,
>>>>>>>>>>>>>>>>>>>>> you invalidated the test.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> You just are proving that you don't know what you
>>>>>>>>>>>>>>>>>>>>> are talking about
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You are not going to get away with those weasel
>>>>>>>>>>>>>>>>>>>> words of double-talk.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Every competent software engineer will know with
>>>>>>>>>>>>>>>>>>>> correct complete certainty that when commenting out
>>>>>>>>>>>>>>>>>>>> the code the does the abort causes the the
>>>>>>>>>>>>>>>>>>>> simulation to never stop that it is only the abort
>>>>>>>>>>>>>>>>>>>> that stops
>>>>>>>>>>>>>>>>>>>> the simulation.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Nope. Since that changes the behavior of the input,
>>>>>>>>>>>>>>>>>>> it is an invalid operation.
>>>>>>>>>>>>>>>>>> Every competent software engineer will agree with me
>>>>>>>>>>>>>>>>>> and disagree with your weasel word double talk.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Name ONE.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Make sure the understand that the input calls the
>>>>>>>>>>>>>>>>> decider, so editing the decider changes the input.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Every competent software engineer is going to know that
>>>>>>>>>>>>>>>> we can test that X causes Y by removing only X and Y
>>>>>>>>>>>>>>>> stops happening.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So, you don't know anyone willing to go on record to
>>>>>>>>>>>>>>> support you.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Guess that shows how reliable your claim its.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So you are claiming that when *only* the line of code that
>>>>>>>>>>>>>> does the abort is commented out and this results in the
>>>>>>>>>>>>>> correctly simulated input to H(P,P) never stopping that
>>>>>>>>>>>>>> this does not mean that that it is only the abort that
>>>>>>>>>>>>>> causes the simulation to stop IS NOT PROVEN ???
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> By Changing H, you have changed P, and thus your
>>>>>>>>>>>>> experement" showed the wrong thing,
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> (a) I assert that it is a proven fact that H(P,P) stops
>>>>>>>>>>>> running when H is allowed to abort its simulation of P
>>>>>>>>>>>>
>>>>>>>>>>> Right.
>>>>>>>>>>>
>>>>>>>>>>> Because H has been DEFINED to abort its simulation of P (no
>>>>>>>>>>> "allowed" in there, it HAS to abort its simulation or it
>>>>>>>>>>> isn't the H you have defined)
>>>>>>>>>>>
>>>>>>>>>>>> (b) I assert that it is a proven fact that H(P,P) never
>>>>>>>>>>>> stops running when H is *NOT* allowed to abort its
>>>>>>>>>>>> simulation of P
>>>>>>>>>>>
>>>>>>>>>>> Nope, because then it is no longer the H that has been defined.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Sure it is. When you comment out a line-of-code in a function
>>>>>>>>>> the compiler absolutely will not change the name of this
>>>>>>>>>> function and you know this so why lie?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So you claim commenting out a statement doesn't change the
>>>>>>>>> behavior of the function?
>>>>>>>>
>>>>>>>> When we make one single change to H, removing its ability to
>>>>>>>> abort the simulation of its input then this transforms the
>>>>>>>> original H into a pure simulator.
>>>>>>>
>>>>>>> Right, but P is calling the deciderm not the simulator, so you
>>>>>>> changed P which isn't allowed
>>>>>>>
>>>>>>>>
>>>>>>>> Now when we run H(P,P) and it never stops running that
>>>>>>>> conclusively proves that a pure simulation of the input to
>>>>>>>> H(P,P) never stops running.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Right, and you just ran H on a DIFERERNT P, so its answer is
>>>>>>> irrelevent to the original question.
>>>>>>
>>>>>> Every competent software engineer knows that my proof is correct.
>>>>>
>>>>> FALSE.
>>>>>
>>>>> Name one.
>>>>>
>>>>> You are just proven to be a liar.
>>>>>
>>>>> I have checked with a couple of very competent software engineers I
>>>>> know, and none of them agree with you, so you claim is proven false
>>>>> by example. You are making the fallacy of Ad Populum without even
>>>>> having the populum.
>>>>>
>>>>>>
>>>>>> That you play silly games with naming conventions is just like
>>>>>> Zeno's paradox that "proves" it is impossible to cross the room to
>>>>>> get to the other side.
>>>>>
>>>>> Nope, that you call then "silly games with naming conventions" just
>>>>> proves you don't understand what you are talking about.
>>>>>
>>>>>>
>>>>>> https://owlcation.com/stem/understanding-and-solving-Zenos-paradox#:~:text=In%20its%20simplest%20form%2C%20Zeno's,before%20reaching%20the%20stationary%20ball.
>>>>>>
>>>>>
>>>>> Red Herring.
>>>>>
>>>>
>>>> Zeno mathematically proved that two items cannot possibly touch thus
>>>> when two items touch the proof is refuted.
>>>
>>> No, Zeno made the error that an infintly long sum might sum to a
>>> finite value.
>>>
>>>>
>>>> When we make one single change to H, removing its ability to abort
>>>> the simulation of its input then this transforms the original H into
>>>> a pure simulator.
>>>
>>> Right, which is a DIFFERENT computation, and thus when you processs
>>> the MODIFIED P that you get from that change you haven't proven
>>> anything about the original
>>>
>>> Your references to Zeno are just a Red Herring Fallacy.
>>>
>>>
>>>>
>>>> *THIS IS TRUE ON THE BASIS OF THE MEANING OF ITS WORDS*
>>>
>>> Nope. You have wrong meanings to the words.
>>>
>>>> Now when we run H(P,P) and it never stops running that conclusively
>>>> proves that a pure simulation of the input to H(P,P) never stops
>>>> running.
>>>>
>>>
>>> No, because you CAN'T run H and have it never stop running, becaue
>>> you have DEFINED (by publishing the code for the H you claim is
>>> correct).
>>
>> It is an easily verified fact that the only reason that H(P,P) ever
>> stops running is that H aborts the simulation of its input.
>
> Sort of.
A simulating halt decider is required to correctly predict whether or
not the hypothetical case of its correct and complete simulation of its
input would reach the final state of this input.

On 9/2/22 7:11 PM, olcott wrote:
> On 9/2/2022 5:41 PM, Richard Damon wrote:
>> On 9/2/22 6:21 PM, olcott wrote:
>>> On 9/2/2022 5:05 PM, Richard Damon wrote:
>>>> On 9/2/22 5:56 PM, olcott wrote:
>>>>> On 9/2/2022 4:49 PM, Richard Damon wrote:
>>>>>> On 9/2/22 5:37 PM, olcott wrote:
>>>>>>> On 9/2/2022 4:32 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 9/2/22 5:07 PM, olcott wrote:
>>>>>>>>> On 9/2/2022 3:56 PM, Richard Damon wrote:
>>>>>>>>>> On 9/2/22 4:46 PM, olcott wrote:
>>>>>>>>>>> On 9/2/2022 3:38 PM, Richard Damon wrote:
>>>>>>>>>>>> On 9/2/22 4:31 PM, olcott wrote:
>>>>>>>>>>>>> On 9/2/2022 3:08 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 9/2/22 3:53 PM, olcott wrote:
>>>>>>>>>>>>>>> On 9/2/2022 2:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 9/2/22 3:38 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 9/2/2022 2:28 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 9/2/22 3:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 9/2/2022 1:21 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 9/2/22 1:57 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 9/2/2022 7:19 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 9/2/22 12:35 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:32 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:26 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:13 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:02 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 9:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 8:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 5:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 10:37 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nope, The finite string input to H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is the representation of P(P),
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If this was true then when H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correctly simulates its input this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation would stop without being aborted.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, because your definition of H aborts
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Means that empirical testing proves that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the simulation does not otherwise ever stop
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> running.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nope, because the "empirical test" you use
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> is valid, when we are working with real code
>>>>>>>>>>>>>>>>>>>>>>>>>>> on real machines empirical testing is 100%
>>>>>>>>>>>>>>>>>>>>>>>>>>> reliable.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Nope, because your "Empericl Test" isn't
>>>>>>>>>>>>>>>>>>>>>>>>>> designed to the requirements.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> The requirements are simply this:
>>>>>>>>>>>>>>>>>>>>>>>>> Does the simulated input stop running if not
>>>>>>>>>>>>>>>>>>>>>>>>> aborted?
>>>>>>>>>>>>>>>>>>>>>>>>> Comment out the abort code and it keeps running
>>>>>>>>>>>>>>>>>>>>>>>>> thus: NO
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Nope, you changed the input, thus the test is
>>>>>>>>>>>>>>>>>>>>>>>> invalid.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> No one that knows software engineering is going
>>>>>>>>>>>>>>>>>>>>>>> to buy that bullshit.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Every software engineer knows that if simply
>>>>>>>>>>>>>>>>>>>>>>> commenting out the line of code that does the
>>>>>>>>>>>>>>>>>>>>>>> abort prevents the simulation from ever stopping
>>>>>>>>>>>>>>>>>>>>>>> that the simulation does not stop without the abort.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Nope, and that shows your ignorance. Since you
>>>>>>>>>>>>>>>>>>>>>> also edited the program under test when you did
>>>>>>>>>>>>>>>>>>>>>> that, you invalidated the test.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> You just are proving that you don't know what you
>>>>>>>>>>>>>>>>>>>>>> are talking about
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> You are not going to get away with those weasel
>>>>>>>>>>>>>>>>>>>>> words of double-talk.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Every competent software engineer will know with
>>>>>>>>>>>>>>>>>>>>> correct complete certainty that when commenting out
>>>>>>>>>>>>>>>>>>>>> the code the does the abort causes the the
>>>>>>>>>>>>>>>>>>>>> simulation to never stop that it is only the abort
>>>>>>>>>>>>>>>>>>>>> that stops
>>>>>>>>>>>>>>>>>>>>> the simulation.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Nope. Since that changes the behavior of the input,
>>>>>>>>>>>>>>>>>>>> it is an invalid operation.
>>>>>>>>>>>>>>>>>>> Every competent software engineer will agree with me
>>>>>>>>>>>>>>>>>>> and disagree with your weasel word double talk.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Name ONE.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Make sure the understand that the input calls the
>>>>>>>>>>>>>>>>>> decider, so editing the decider changes the input.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Every competent software engineer is going to know that
>>>>>>>>>>>>>>>>> we can test that X causes Y by removing only X and Y
>>>>>>>>>>>>>>>>> stops happening.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So, you don't know anyone willing to go on record to
>>>>>>>>>>>>>>>> support you.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Guess that shows how reliable your claim its.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So you are claiming that when *only* the line of code
>>>>>>>>>>>>>>> that does the abort is commented out and this results in
>>>>>>>>>>>>>>> the correctly simulated input to H(P,P) never stopping
>>>>>>>>>>>>>>> that this does not mean that that it is only the abort
>>>>>>>>>>>>>>> that causes the simulation to stop IS NOT PROVEN ???
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> By Changing H, you have changed P, and thus your
>>>>>>>>>>>>>> experement" showed the wrong thing,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> (a) I assert that it is a proven fact that H(P,P) stops
>>>>>>>>>>>>> running when H is allowed to abort its simulation of P
>>>>>>>>>>>>>
>>>>>>>>>>>> Right.
>>>>>>>>>>>>
>>>>>>>>>>>> Because H has been DEFINED to abort its simulation of P (no
>>>>>>>>>>>> "allowed" in there, it HAS to abort its simulation or it
>>>>>>>>>>>> isn't the H you have defined)
>>>>>>>>>>>>
>>>>>>>>>>>>> (b) I assert that it is a proven fact that H(P,P) never
>>>>>>>>>>>>> stops running when H is *NOT* allowed to abort its
>>>>>>>>>>>>> simulation of P
>>>>>>>>>>>>
>>>>>>>>>>>> Nope, because then it is no longer the H that has been defined.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Sure it is. When you comment out a line-of-code in a function
>>>>>>>>>>> the compiler absolutely will not change the name of this
>>>>>>>>>>> function and you know this so why lie?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So you claim commenting out a statement doesn't change the
>>>>>>>>>> behavior of the function?
>>>>>>>>>
>>>>>>>>> When we make one single change to H, removing its ability to
>>>>>>>>> abort the simulation of its input then this transforms the
>>>>>>>>> original H into a pure simulator.
>>>>>>>>
>>>>>>>> Right, but P is calling the deciderm not the simulator, so you
>>>>>>>> changed P which isn't allowed
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Now when we run H(P,P) and it never stops running that
>>>>>>>>> conclusively proves that a pure simulation of the input to
>>>>>>>>> H(P,P) never stops running.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Right, and you just ran H on a DIFERERNT P, so its answer is
>>>>>>>> irrelevent to the original question.
>>>>>>>
>>>>>>> Every competent software engineer knows that my proof is correct.
>>>>>>
>>>>>> FALSE.
>>>>>>
>>>>>> Name one.
>>>>>>
>>>>>> You are just proven to be a liar.
>>>>>>
>>>>>> I have checked with a couple of very competent software engineers
>>>>>> I know, and none of them agree with you, so you claim is proven
>>>>>> false by example. You are making the fallacy of Ad Populum without
>>>>>> even having the populum.
>>>>>>
>>>>>>>
>>>>>>> That you play silly games with naming conventions is just like
>>>>>>> Zeno's paradox that "proves" it is impossible to cross the room
>>>>>>> to get to the other side.
>>>>>>
>>>>>> Nope, that you call then "silly games with naming conventions"
>>>>>> just proves you don't understand what you are talking about.
>>>>>>
>>>>>>>
>>>>>>> https://owlcation.com/stem/understanding-and-solving-Zenos-paradox#:~:text=In%20its%20simplest%20form%2C%20Zeno's,before%20reaching%20the%20stationary%20ball.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Red Herring.
>>>>>>
>>>>>
>>>>> Zeno mathematically proved that two items cannot possibly touch
>>>>> thus when two items touch the proof is refuted.
>>>>
>>>> No, Zeno made the error that an infintly long sum might sum to a
>>>> finite value.
>>>>
>>>>>
>>>>> When we make one single change to H, removing its ability to abort
>>>>> the simulation of its input then this transforms the original H
>>>>> into a pure simulator.
>>>>
>>>> Right, which is a DIFFERENT computation, and thus when you processs
>>>> the MODIFIED P that you get from that change you haven't proven
>>>> anything about the original
>>>>
>>>> Your references to Zeno are just a Red Herring Fallacy.
>>>>
>>>>
>>>>>
>>>>> *THIS IS TRUE ON THE BASIS OF THE MEANING OF ITS WORDS*
>>>>
>>>> Nope. You have wrong meanings to the words.
>>>>
>>>>> Now when we run H(P,P) and it never stops running that conclusively
>>>>> proves that a pure simulation of the input to H(P,P) never stops
>>>>> running.
>>>>>
>>>>
>>>> No, because you CAN'T run H and have it never stop running, becaue
>>>> you have DEFINED (by publishing the code for the H you claim is
>>>> correct).
>>>
>>> It is an easily verified fact that the only reason that H(P,P) ever
>>> stops running is that H aborts the simulation of its input.
>>
>> Sort of.
> A simulating halt decider is required to correctly predict whether or
> not the hypothetical case of its correct and complete simulation of its
> input would reach the final state of this input.

On 9/2/2022 6:27 PM, Richard Damon wrote:
>
> On 9/2/22 7:11 PM, olcott wrote:
>> On 9/2/2022 5:41 PM, Richard Damon wrote:
>>> On 9/2/22 6:21 PM, olcott wrote:
>>>> On 9/2/2022 5:05 PM, Richard Damon wrote:
>>>>> On 9/2/22 5:56 PM, olcott wrote:
>>>>>> On 9/2/2022 4:49 PM, Richard Damon wrote:
>>>>>>> On 9/2/22 5:37 PM, olcott wrote:
>>>>>>>> On 9/2/2022 4:32 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 9/2/22 5:07 PM, olcott wrote:
>>>>>>>>>> On 9/2/2022 3:56 PM, Richard Damon wrote:
>>>>>>>>>>> On 9/2/22 4:46 PM, olcott wrote:
>>>>>>>>>>>> On 9/2/2022 3:38 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 9/2/22 4:31 PM, olcott wrote:
>>>>>>>>>>>>>> On 9/2/2022 3:08 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 9/2/22 3:53 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 9/2/2022 2:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 9/2/22 3:38 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 9/2/2022 2:28 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 9/2/22 3:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 9/2/2022 1:21 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 9/2/22 1:57 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 9/2/2022 7:19 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 9/2/22 12:35 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:32 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:26 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:13 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:02 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 9:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 8:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 5:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 10:37 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nope, The finite string input to H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is the representation of P(P),
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If this was true then when H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correctly simulates its input this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation would stop without being
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aborted.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, because your definition of H aborts
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Means that empirical testing proves that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the simulation does not otherwise ever
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stop running.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nope, because the "empirical test" you use
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> is valid, when we are working with real code
>>>>>>>>>>>>>>>>>>>>>>>>>>>> on real machines empirical testing is 100%
>>>>>>>>>>>>>>>>>>>>>>>>>>>> reliable.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Nope, because your "Empericl Test" isn't
>>>>>>>>>>>>>>>>>>>>>>>>>>> designed to the requirements.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> The requirements are simply this:
>>>>>>>>>>>>>>>>>>>>>>>>>> Does the simulated input stop running if not
>>>>>>>>>>>>>>>>>>>>>>>>>> aborted?
>>>>>>>>>>>>>>>>>>>>>>>>>> Comment out the abort code and it keeps
>>>>>>>>>>>>>>>>>>>>>>>>>> running thus: NO
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Nope, you changed the input, thus the test is
>>>>>>>>>>>>>>>>>>>>>>>>> invalid.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> No one that knows software engineering is going
>>>>>>>>>>>>>>>>>>>>>>>> to buy that bullshit.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Every software engineer knows that if simply
>>>>>>>>>>>>>>>>>>>>>>>> commenting out the line of code that does the
>>>>>>>>>>>>>>>>>>>>>>>> abort prevents the simulation from ever stopping
>>>>>>>>>>>>>>>>>>>>>>>> that the simulation does not stop without the
>>>>>>>>>>>>>>>>>>>>>>>> abort.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Nope, and that shows your ignorance. Since you
>>>>>>>>>>>>>>>>>>>>>>> also edited the program under test when you did
>>>>>>>>>>>>>>>>>>>>>>> that, you invalidated the test.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> You just are proving that you don't know what you
>>>>>>>>>>>>>>>>>>>>>>> are talking about
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> You are not going to get away with those weasel
>>>>>>>>>>>>>>>>>>>>>> words of double-talk.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Every competent software engineer will know with
>>>>>>>>>>>>>>>>>>>>>> correct complete certainty that when commenting
>>>>>>>>>>>>>>>>>>>>>> out the code the does the abort causes the the
>>>>>>>>>>>>>>>>>>>>>> simulation to never stop that it is only the abort
>>>>>>>>>>>>>>>>>>>>>> that stops
>>>>>>>>>>>>>>>>>>>>>> the simulation.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Nope. Since that changes the behavior of the input,
>>>>>>>>>>>>>>>>>>>>> it is an invalid operation.
>>>>>>>>>>>>>>>>>>>> Every competent software engineer will agree with me
>>>>>>>>>>>>>>>>>>>> and disagree with your weasel word double talk.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Name ONE.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Make sure the understand that the input calls the
>>>>>>>>>>>>>>>>>>> decider, so editing the decider changes the input.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Every competent software engineer is going to know
>>>>>>>>>>>>>>>>>> that we can test that X causes Y by removing only X
>>>>>>>>>>>>>>>>>> and Y stops happening.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So, you don't know anyone willing to go on record to
>>>>>>>>>>>>>>>>> support you.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Guess that shows how reliable your claim its.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So you are claiming that when *only* the line of code
>>>>>>>>>>>>>>>> that does the abort is commented out and this results in
>>>>>>>>>>>>>>>> the correctly simulated input to H(P,P) never stopping
>>>>>>>>>>>>>>>> that this does not mean that that it is only the abort
>>>>>>>>>>>>>>>> that causes the simulation to stop IS NOT PROVEN ???
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> By Changing H, you have changed P, and thus your
>>>>>>>>>>>>>>> experement" showed the wrong thing,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (a) I assert that it is a proven fact that H(P,P) stops
>>>>>>>>>>>>>> running when H is allowed to abort its simulation of P
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Right.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Because H has been DEFINED to abort its simulation of P (no
>>>>>>>>>>>>> "allowed" in there, it HAS to abort its simulation or it
>>>>>>>>>>>>> isn't the H you have defined)
>>>>>>>>>>>>>
>>>>>>>>>>>>>> (b) I assert that it is a proven fact that H(P,P) never
>>>>>>>>>>>>>> stops running when H is *NOT* allowed to abort its
>>>>>>>>>>>>>> simulation of P
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nope, because then it is no longer the H that has been
>>>>>>>>>>>>> defined.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Sure it is. When you comment out a line-of-code in a
>>>>>>>>>>>> function the compiler absolutely will not change the name of
>>>>>>>>>>>> this function and you know this so why lie?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So you claim commenting out a statement doesn't change the
>>>>>>>>>>> behavior of the function?
>>>>>>>>>>
>>>>>>>>>> When we make one single change to H, removing its ability to
>>>>>>>>>> abort the simulation of its input then this transforms the
>>>>>>>>>> original H into a pure simulator.
>>>>>>>>>
>>>>>>>>> Right, but P is calling the deciderm not the simulator, so you
>>>>>>>>> changed P which isn't allowed
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Now when we run H(P,P) and it never stops running that
>>>>>>>>>> conclusively proves that a pure simulation of the input to
>>>>>>>>>> H(P,P) never stops running.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Right, and you just ran H on a DIFERERNT P, so its answer is
>>>>>>>>> irrelevent to the original question.
>>>>>>>>
>>>>>>>> Every competent software engineer knows that my proof is correct.
>>>>>>>
>>>>>>> FALSE.
>>>>>>>
>>>>>>> Name one.
>>>>>>>
>>>>>>> You are just proven to be a liar.
>>>>>>>
>>>>>>> I have checked with a couple of very competent software engineers
>>>>>>> I know, and none of them agree with you, so you claim is proven
>>>>>>> false by example. You are making the fallacy of Ad Populum
>>>>>>> without even having the populum.
>>>>>>>
>>>>>>>>
>>>>>>>> That you play silly games with naming conventions is just like
>>>>>>>> Zeno's paradox that "proves" it is impossible to cross the room
>>>>>>>> to get to the other side.
>>>>>>>
>>>>>>> Nope, that you call then "silly games with naming conventions"
>>>>>>> just proves you don't understand what you are talking about.
>>>>>>>
>>>>>>>>
>>>>>>>> https://owlcation.com/stem/understanding-and-solving-Zenos-paradox#:~:text=In%20its%20simplest%20form%2C%20Zeno's,before%20reaching%20the%20stationary%20ball.
>>>>>>>>
>>>>>>>
>>>>>>> Red Herring.
>>>>>>>
>>>>>>
>>>>>> Zeno mathematically proved that two items cannot possibly touch
>>>>>> thus when two items touch the proof is refuted.
>>>>>
>>>>> No, Zeno made the error that an infintly long sum might sum to a
>>>>> finite value.
>>>>>
>>>>>>
>>>>>> When we make one single change to H, removing its ability to abort
>>>>>> the simulation of its input then this transforms the original H
>>>>>> into a pure simulator.
>>>>>
>>>>> Right, which is a DIFFERENT computation, and thus when you processs
>>>>> the MODIFIED P that you get from that change you haven't proven
>>>>> anything about the original
>>>>>
>>>>> Your references to Zeno are just a Red Herring Fallacy.
>>>>>
>>>>>
>>>>>>
>>>>>> *THIS IS TRUE ON THE BASIS OF THE MEANING OF ITS WORDS*
>>>>>
>>>>> Nope. You have wrong meanings to the words.
>>>>>
>>>>>> Now when we run H(P,P) and it never stops running that
>>>>>> conclusively proves that a pure simulation of the input to H(P,P)
>>>>>> never stops running.
>>>>>>
>>>>>
>>>>> No, because you CAN'T run H and have it never stop running, becaue
>>>>> you have DEFINED (by publishing the code for the H you claim is
>>>>> correct).
>>>>
>>>> It is an easily verified fact that the only reason that H(P,P) ever
>>>> stops running is that H aborts the simulation of its input.
>>>
>>> Sort of.
>> A simulating halt decider is required to correctly predict whether or
>> not the hypothetical case of its correct and complete simulation of
>> its input would reach the final state of this input.
>
> The your simulating Halt Decider isn't a Halt Decider, so you fail
>
> A Halt Decider is required to decide on the ACTUAL BEHAVIOR of the
> ACTUAL MACHINE that the input represents.
>

On 9/2/22 8:41 PM, olcott wrote:
> On 9/2/2022 6:27 PM, Richard Damon wrote:
>>
>> On 9/2/22 7:11 PM, olcott wrote:
>>> On 9/2/2022 5:41 PM, Richard Damon wrote:
>>>> On 9/2/22 6:21 PM, olcott wrote:
>>>>> On 9/2/2022 5:05 PM, Richard Damon wrote:
>>>>>> On 9/2/22 5:56 PM, olcott wrote:
>>>>>>> On 9/2/2022 4:49 PM, Richard Damon wrote:
>>>>>>>> On 9/2/22 5:37 PM, olcott wrote:
>>>>>>>>> On 9/2/2022 4:32 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 9/2/22 5:07 PM, olcott wrote:
>>>>>>>>>>> On 9/2/2022 3:56 PM, Richard Damon wrote:
>>>>>>>>>>>> On 9/2/22 4:46 PM, olcott wrote:
>>>>>>>>>>>>> On 9/2/2022 3:38 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 9/2/22 4:31 PM, olcott wrote:
>>>>>>>>>>>>>>> On 9/2/2022 3:08 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 9/2/22 3:53 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 9/2/2022 2:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 9/2/22 3:38 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 9/2/2022 2:28 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 9/2/22 3:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 9/2/2022 1:21 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 9/2/22 1:57 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 9/2/2022 7:19 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 9/2/22 12:35 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:32 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:26 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:13 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:02 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 9:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 8:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 5:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 10:37 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nope, The finite string input to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(P,P) is the representation of P(P),
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If this was true then when H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correctly simulates its input this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation would stop without being
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aborted.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, because your definition of H aborts
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Means that empirical testing proves that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the simulation does not otherwise ever
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stop running.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nope, because the "empirical test" you use
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is valid, when we are working with real
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> code on real machines empirical testing is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 100% reliable.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nope, because your "Empericl Test" isn't
>>>>>>>>>>>>>>>>>>>>>>>>>>>> designed to the requirements.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> The requirements are simply this:
>>>>>>>>>>>>>>>>>>>>>>>>>>> Does the simulated input stop running if not
>>>>>>>>>>>>>>>>>>>>>>>>>>> aborted?
>>>>>>>>>>>>>>>>>>>>>>>>>>> Comment out the abort code and it keeps
>>>>>>>>>>>>>>>>>>>>>>>>>>> running thus: NO
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Nope, you changed the input, thus the test is
>>>>>>>>>>>>>>>>>>>>>>>>>> invalid.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> No one that knows software engineering is going
>>>>>>>>>>>>>>>>>>>>>>>>> to buy that bullshit.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Every software engineer knows that if simply
>>>>>>>>>>>>>>>>>>>>>>>>> commenting out the line of code that does the
>>>>>>>>>>>>>>>>>>>>>>>>> abort prevents the simulation from ever
>>>>>>>>>>>>>>>>>>>>>>>>> stopping that the simulation does not stop
>>>>>>>>>>>>>>>>>>>>>>>>> without the abort.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Nope, and that shows your ignorance. Since you
>>>>>>>>>>>>>>>>>>>>>>>> also edited the program under test when you did
>>>>>>>>>>>>>>>>>>>>>>>> that, you invalidated the test.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> You just are proving that you don't know what
>>>>>>>>>>>>>>>>>>>>>>>> you are talking about
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> You are not going to get away with those weasel
>>>>>>>>>>>>>>>>>>>>>>> words of double-talk.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Every competent software engineer will know with
>>>>>>>>>>>>>>>>>>>>>>> correct complete certainty that when commenting
>>>>>>>>>>>>>>>>>>>>>>> out the code the does the abort causes the the
>>>>>>>>>>>>>>>>>>>>>>> simulation to never stop that it is only the
>>>>>>>>>>>>>>>>>>>>>>> abort that stops
>>>>>>>>>>>>>>>>>>>>>>> the simulation.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Nope. Since that changes the behavior of the
>>>>>>>>>>>>>>>>>>>>>> input, it is an invalid operation.
>>>>>>>>>>>>>>>>>>>>> Every competent software engineer will agree with
>>>>>>>>>>>>>>>>>>>>> me and disagree with your weasel word double talk.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Name ONE.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Make sure the understand that the input calls the
>>>>>>>>>>>>>>>>>>>> decider, so editing the decider changes the input.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Every competent software engineer is going to know
>>>>>>>>>>>>>>>>>>> that we can test that X causes Y by removing only X
>>>>>>>>>>>>>>>>>>> and Y stops happening.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> So, you don't know anyone willing to go on record to
>>>>>>>>>>>>>>>>>> support you.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Guess that shows how reliable your claim its.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So you are claiming that when *only* the line of code
>>>>>>>>>>>>>>>>> that does the abort is commented out and this results
>>>>>>>>>>>>>>>>> in the correctly simulated input to H(P,P) never
>>>>>>>>>>>>>>>>> stopping that this does not mean that that it is only
>>>>>>>>>>>>>>>>> the abort that causes the simulation to stop IS NOT
>>>>>>>>>>>>>>>>> PROVEN ???
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> By Changing H, you have changed P, and thus your
>>>>>>>>>>>>>>>> experement" showed the wrong thing,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (a) I assert that it is a proven fact that H(P,P) stops
>>>>>>>>>>>>>>> running when H is allowed to abort its simulation of P
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Right.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Because H has been DEFINED to abort its simulation of P
>>>>>>>>>>>>>> (no "allowed" in there, it HAS to abort its simulation or
>>>>>>>>>>>>>> it isn't the H you have defined)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (b) I assert that it is a proven fact that H(P,P) never
>>>>>>>>>>>>>>> stops running when H is *NOT* allowed to abort its
>>>>>>>>>>>>>>> simulation of P
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope, because then it is no longer the H that has been
>>>>>>>>>>>>>> defined.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sure it is. When you comment out a line-of-code in a
>>>>>>>>>>>>> function the compiler absolutely will not change the name
>>>>>>>>>>>>> of this function and you know this so why lie?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> So you claim commenting out a statement doesn't change the
>>>>>>>>>>>> behavior of the function?
>>>>>>>>>>>
>>>>>>>>>>> When we make one single change to H, removing its ability to
>>>>>>>>>>> abort the simulation of its input then this transforms the
>>>>>>>>>>> original H into a pure simulator.
>>>>>>>>>>
>>>>>>>>>> Right, but P is calling the deciderm not the simulator, so you
>>>>>>>>>> changed P which isn't allowed
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Now when we run H(P,P) and it never stops running that
>>>>>>>>>>> conclusively proves that a pure simulation of the input to
>>>>>>>>>>> H(P,P) never stops running.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Right, and you just ran H on a DIFERERNT P, so its answer is
>>>>>>>>>> irrelevent to the original question.
>>>>>>>>>
>>>>>>>>> Every competent software engineer knows that my proof is correct.
>>>>>>>>
>>>>>>>> FALSE.
>>>>>>>>
>>>>>>>> Name one.
>>>>>>>>
>>>>>>>> You are just proven to be a liar.
>>>>>>>>
>>>>>>>> I have checked with a couple of very competent software
>>>>>>>> engineers I know, and none of them agree with you, so you claim
>>>>>>>> is proven false by example. You are making the fallacy of Ad
>>>>>>>> Populum without even having the populum.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> That you play silly games with naming conventions is just like
>>>>>>>>> Zeno's paradox that "proves" it is impossible to cross the room
>>>>>>>>> to get to the other side.
>>>>>>>>
>>>>>>>> Nope, that you call then "silly games with naming conventions"
>>>>>>>> just proves you don't understand what you are talking about.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://owlcation.com/stem/understanding-and-solving-Zenos-paradox#:~:text=In%20its%20simplest%20form%2C%20Zeno's,before%20reaching%20the%20stationary%20ball.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Red Herring.
>>>>>>>>
>>>>>>>
>>>>>>> Zeno mathematically proved that two items cannot possibly touch
>>>>>>> thus when two items touch the proof is refuted.
>>>>>>
>>>>>> No, Zeno made the error that an infintly long sum might sum to a
>>>>>> finite value.
>>>>>>
>>>>>>>
>>>>>>> When we make one single change to H, removing its ability to
>>>>>>> abort the simulation of its input then this transforms the
>>>>>>> original H into a pure simulator.
>>>>>>
>>>>>> Right, which is a DIFFERENT computation, and thus when you
>>>>>> processs the MODIFIED P that you get from that change you haven't
>>>>>> proven anything about the original
>>>>>>
>>>>>> Your references to Zeno are just a Red Herring Fallacy.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> *THIS IS TRUE ON THE BASIS OF THE MEANING OF ITS WORDS*
>>>>>>
>>>>>> Nope. You have wrong meanings to the words.
>>>>>>
>>>>>>> Now when we run H(P,P) and it never stops running that
>>>>>>> conclusively proves that a pure simulation of the input to H(P,P)
>>>>>>> never stops running.
>>>>>>>
>>>>>>
>>>>>> No, because you CAN'T run H and have it never stop running, becaue
>>>>>> you have DEFINED (by publishing the code for the H you claim is
>>>>>> correct).
>>>>>
>>>>> It is an easily verified fact that the only reason that H(P,P) ever
>>>>> stops running is that H aborts the simulation of its input.
>>>>
>>>> Sort of.
>>> A simulating halt decider is required to correctly predict whether or
>>> not the hypothetical case of its correct and complete simulation of
>>> its input would reach the final state of this input.
>>
>> The your simulating Halt Decider isn't a Halt Decider, so you fail
>>
>> A Halt Decider is required to decide on the ACTUAL BEHAVIOR of the
>> ACTUAL MACHINE that the input represents.
>>
>
> Any misconception of the behavior of the input to H(P,P) is over-ruled
> and superseded by the behavior of the correct and complete simulation of
> this input at the same point in the execution trace as H.
>

On 9/2/2022 7:46 PM, Richard Damon wrote:
>
> On 9/2/22 8:41 PM, olcott wrote:
>> On 9/2/2022 6:27 PM, Richard Damon wrote:
>>>
>>> On 9/2/22 7:11 PM, olcott wrote:
>>>> On 9/2/2022 5:41 PM, Richard Damon wrote:
>>>>> On 9/2/22 6:21 PM, olcott wrote:
>>>>>> On 9/2/2022 5:05 PM, Richard Damon wrote:
>>>>>>> On 9/2/22 5:56 PM, olcott wrote:
>>>>>>>> On 9/2/2022 4:49 PM, Richard Damon wrote:
>>>>>>>>> On 9/2/22 5:37 PM, olcott wrote:
>>>>>>>>>> On 9/2/2022 4:32 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 9/2/22 5:07 PM, olcott wrote:
>>>>>>>>>>>> On 9/2/2022 3:56 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 9/2/22 4:46 PM, olcott wrote:
>>>>>>>>>>>>>> On 9/2/2022 3:38 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 9/2/22 4:31 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 9/2/2022 3:08 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 9/2/22 3:53 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 9/2/2022 2:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 9/2/22 3:38 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 9/2/2022 2:28 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 9/2/22 3:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 9/2/2022 1:21 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 9/2/22 1:57 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 9/2/2022 7:19 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 9/2/22 12:35 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:32 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:26 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:23 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 10:13 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 11:02 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 9:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 8:18 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/2022 5:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/1/22 10:37 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nope, The finite string input to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(P,P) is the representation of P(P),
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If this was true then when H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correctly simulates its input this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation would stop without being
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aborted.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, because your definition of H aborts
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Means that empirical testing proves that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the simulation does not otherwise ever
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stop running.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nope, because the "empirical test" you use
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is valid, when we are working with real
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> code on real machines empirical testing is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 100% reliable.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nope, because your "Empericl Test" isn't
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> designed to the requirements.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> The requirements are simply this:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Does the simulated input stop running if not
>>>>>>>>>>>>>>>>>>>>>>>>>>>> aborted?
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Comment out the abort code and it keeps
>>>>>>>>>>>>>>>>>>>>>>>>>>>> running thus: NO
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Nope, you changed the input, thus the test is
>>>>>>>>>>>>>>>>>>>>>>>>>>> invalid.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> No one that knows software engineering is
>>>>>>>>>>>>>>>>>>>>>>>>>> going to buy that bullshit.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Every software engineer knows that if simply
>>>>>>>>>>>>>>>>>>>>>>>>>> commenting out the line of code that does the
>>>>>>>>>>>>>>>>>>>>>>>>>> abort prevents the simulation from ever
>>>>>>>>>>>>>>>>>>>>>>>>>> stopping that the simulation does not stop
>>>>>>>>>>>>>>>>>>>>>>>>>> without the abort.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Nope, and that shows your ignorance. Since you
>>>>>>>>>>>>>>>>>>>>>>>>> also edited the program under test when you did
>>>>>>>>>>>>>>>>>>>>>>>>> that, you invalidated the test.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> You just are proving that you don't know what
>>>>>>>>>>>>>>>>>>>>>>>>> you are talking about
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> You are not going to get away with those weasel
>>>>>>>>>>>>>>>>>>>>>>>> words of double-talk.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Every competent software engineer will know with
>>>>>>>>>>>>>>>>>>>>>>>> correct complete certainty that when commenting
>>>>>>>>>>>>>>>>>>>>>>>> out the code the does the abort causes the the
>>>>>>>>>>>>>>>>>>>>>>>> simulation to never stop that it is only the
>>>>>>>>>>>>>>>>>>>>>>>> abort that stops
>>>>>>>>>>>>>>>>>>>>>>>> the simulation.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Nope. Since that changes the behavior of the
>>>>>>>>>>>>>>>>>>>>>>> input, it is an invalid operation.
>>>>>>>>>>>>>>>>>>>>>> Every competent software engineer will agree with
>>>>>>>>>>>>>>>>>>>>>> me and disagree with your weasel word double talk.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Name ONE.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Make sure the understand that the input calls the
>>>>>>>>>>>>>>>>>>>>> decider, so editing the decider changes the input.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Every competent software engineer is going to know
>>>>>>>>>>>>>>>>>>>> that we can test that X causes Y by removing only X
>>>>>>>>>>>>>>>>>>>> and Y stops happening.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> So, you don't know anyone willing to go on record to
>>>>>>>>>>>>>>>>>>> support you.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Guess that shows how reliable your claim its.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> FAIL.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> So you are claiming that when *only* the line of code
>>>>>>>>>>>>>>>>>> that does the abort is commented out and this results
>>>>>>>>>>>>>>>>>> in the correctly simulated input to H(P,P) never
>>>>>>>>>>>>>>>>>> stopping that this does not mean that that it is only
>>>>>>>>>>>>>>>>>> the abort that causes the simulation to stop IS NOT
>>>>>>>>>>>>>>>>>> PROVEN ???
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> By Changing H, you have changed P, and thus your
>>>>>>>>>>>>>>>>> experement" showed the wrong thing,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> (a) I assert that it is a proven fact that H(P,P) stops
>>>>>>>>>>>>>>>> running when H is allowed to abort its simulation of P
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Right.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Because H has been DEFINED to abort its simulation of P
>>>>>>>>>>>>>>> (no "allowed" in there, it HAS to abort its simulation or
>>>>>>>>>>>>>>> it isn't the H you have defined)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> (b) I assert that it is a proven fact that H(P,P) never
>>>>>>>>>>>>>>>> stops running when H is *NOT* allowed to abort its
>>>>>>>>>>>>>>>> simulation of P
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Nope, because then it is no longer the H that has been
>>>>>>>>>>>>>>> defined.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sure it is. When you comment out a line-of-code in a
>>>>>>>>>>>>>> function the compiler absolutely will not change the name
>>>>>>>>>>>>>> of this function and you know this so why lie?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> So you claim commenting out a statement doesn't change the
>>>>>>>>>>>>> behavior of the function?
>>>>>>>>>>>>
>>>>>>>>>>>> When we make one single change to H, removing its ability to
>>>>>>>>>>>> abort the simulation of its input then this transforms the
>>>>>>>>>>>> original H into a pure simulator.
>>>>>>>>>>>
>>>>>>>>>>> Right, but P is calling the deciderm not the simulator, so
>>>>>>>>>>> you changed P which isn't allowed
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Now when we run H(P,P) and it never stops running that
>>>>>>>>>>>> conclusively proves that a pure simulation of the input to
>>>>>>>>>>>> H(P,P) never stops running.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Right, and you just ran H on a DIFERERNT P, so its answer is
>>>>>>>>>>> irrelevent to the original question.
>>>>>>>>>>
>>>>>>>>>> Every competent software engineer knows that my proof is correct.
>>>>>>>>>
>>>>>>>>> FALSE.
>>>>>>>>>
>>>>>>>>> Name one.
>>>>>>>>>
>>>>>>>>> You are just proven to be a liar.
>>>>>>>>>
>>>>>>>>> I have checked with a couple of very competent software
>>>>>>>>> engineers I know, and none of them agree with you, so you claim
>>>>>>>>> is proven false by example. You are making the fallacy of Ad
>>>>>>>>> Populum without even having the populum.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That you play silly games with naming conventions is just like
>>>>>>>>>> Zeno's paradox that "proves" it is impossible to cross the
>>>>>>>>>> room to get to the other side.
>>>>>>>>>
>>>>>>>>> Nope, that you call then "silly games with naming conventions"
>>>>>>>>> just proves you don't understand what you are talking about.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://owlcation.com/stem/understanding-and-solving-Zenos-paradox#:~:text=In%20its%20simplest%20form%2C%20Zeno's,before%20reaching%20the%20stationary%20ball.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Red Herring.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Zeno mathematically proved that two items cannot possibly touch
>>>>>>>> thus when two items touch the proof is refuted.
>>>>>>>
>>>>>>> No, Zeno made the error that an infintly long sum might sum to a
>>>>>>> finite value.
>>>>>>>
>>>>>>>>
>>>>>>>> When we make one single change to H, removing its ability to
>>>>>>>> abort the simulation of its input then this transforms the
>>>>>>>> original H into a pure simulator.
>>>>>>>
>>>>>>> Right, which is a DIFFERENT computation, and thus when you
>>>>>>> processs the MODIFIED P that you get from that change you haven't
>>>>>>> proven anything about the original
>>>>>>>
>>>>>>> Your references to Zeno are just a Red Herring Fallacy.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> *THIS IS TRUE ON THE BASIS OF THE MEANING OF ITS WORDS*
>>>>>>>
>>>>>>> Nope. You have wrong meanings to the words.
>>>>>>>
>>>>>>>> Now when we run H(P,P) and it never stops running that
>>>>>>>> conclusively proves that a pure simulation of the input to
>>>>>>>> H(P,P) never stops running.
>>>>>>>>
>>>>>>>
>>>>>>> No, because you CAN'T run H and have it never stop running,
>>>>>>> becaue you have DEFINED (by publishing the code for the H you
>>>>>>> claim is correct).
>>>>>>
>>>>>> It is an easily verified fact that the only reason that H(P,P)
>>>>>> ever stops running is that H aborts the simulation of its input.
>>>>>
>>>>> Sort of.
>>>> A simulating halt decider is required to correctly predict whether
>>>> or not the hypothetical case of its correct and complete simulation
>>>> of its input would reach the final state of this input.
>>>
>>> The your simulating Halt Decider isn't a Halt Decider, so you fail
>>>
>>> A Halt Decider is required to decide on the ACTUAL BEHAVIOR of the
>>> ACTUAL MACHINE that the input represents.
>>>
>>
>> Any misconception of the behavior of the input to H(P,P) is over-ruled
>> and superseded by the behavior of the correct and complete simulation
>> of this input at the same point in the execution trace as H.
>>
>
> WRONG.
>
>> In other words: Does H(P,P) have to abort its simulation of its input
>> to prevent the infinite execution of this input?
>
>
> WRONG
>>
>> Yes ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS
>> ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS
>> ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS
>> ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS
>> ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS
>> ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS ALWAYS
>>
>> Means that this correctly simulated input cannot reach its own final
>> state, thus is non-halting.
>>
>
> WRONG.
>
> If you won't go by the oficial definitions, your H just isn't a Halt
> Decider.
>