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.

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

Halting is NOT based on does the simulator need to abort or not, but
does the machine halt, or a complete simulation of it halt.

Your test ends up not looking at the right input, because it changes the
"P" that you are looking at by changing the H it is calling.

That INVALIDATES the test.

You need to test with the ACTUAL INPUT given to the H.

FAIL.

Just shows you are ignorant of what a computation actually is, but we
already knew that.

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

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

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.

When I get a glass or water and dump it on the floor the floor does
become wet, if you disagree then you are untruthful.

--
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 02/09/2022 02:46, Ben Bacarisse wrote:
> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>> I am not boasting:
> Of course you are.

Of course he isn't. He's trolling. Feel free to take him
at face value [as I have occasionally done]; just be aware. Some
of his contributions are nevertheless quite interesting/amusing.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Morel

olcott <polcott2@gmail.com> wrote:

> On 8/31/2022 10:55 AM, Otto J. Makela wrote:
>> However, this very same case shows that H() does return a value, and
>> H() returning a value of 0 for (all?) cases involving itself would
>> also seem to be incorrect.
>
> In every case where the simulation of the input by H would never stop
> running H aborts its simulation and returns 0.

Why would a simulation of H() not return a value, once it had done the
same kind of deduction?

--
/* * * Otto J. Makela <om@iki.fi> * * * * * * * * * */
/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */

Andy Walker <anw@cuboid.co.uk> writes:

> On 02/09/2022 02:46, Ben Bacarisse wrote:
>> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>>> I am not boasting:
>> Of course you are.
>
> Of course he isn't. He's trolling.

Depending on the definition I don't think they need be mutually
exclusive.

Mr Flibble says things that /appear/ to be boasts in order to provoke
responses (rather than, say, posting outrageous political sentiments) so
in that sense his obviously trolling. But does one have to genuinely
believe ones claims to be boasting? I am not sure what the word really
entails.

I'm pretty sure he does not believe what he writes in the totally
committed, self-deluding why that, say, PO does. But belief is not all
or nothing.

--
Ben.

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

>
> When I get a glass or water and dump it on the floor the floor does
> become wet, if you disagree then you are untruthful.
>
>

Which is just a Red Herring, and the fact you seem to think al these
irrelevant examples mean something shows your ignrance.

YOu are just proving that you don't know a thing about what you are
talking about.

On Thursday, September 1, 2022 at 8:59:18 PM UTC+1, olcott wrote:
> It is an easily verified fact when H(P,P) correctly simulates its input
> that this simulated input would never stop running unless H aborts its
> simulation of this input.

On the contrary, if H(P,P) correctly simulates its input then it does halt. Richard has gone through the details several times. Your simulator assumes that H will not abort, so it is inaccurate as H does abort.

> It is also an easily verified fact that halt deciders only compute the
> mapping from finite string inputs to an accept or reject state.
>
> It is also an easily verified fact that P(P) executed from main is not
> an input to H(P,P).

Nonsense. We only need to look at the two arguments supplied to H to see that P(P) is exactly the input to H.

> int sum(int x, int y){ return x + y; }
> Thus all of the "rebuttals" of my work have been essentially based on
> the argument that sum(2,3) does not correctly derive the sum of 5 + 7.

When you say that "P(P) executed from main is not an input to H(P,P)" you are saying the equivalent of "2 and 3 are not the input to sum(2,3) so it would be wrong for sum(2,3) to return 2+3".

Mr Flibble <flibble@reddwarf.jmc.corp> writes:

> On Fri, 02 Sep 2022 02:46:44 +0100
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>> Mr Flibble <flibble@reddwarf.jmc.corp> writes:

>> > I am not boasting:
>>
>> Of course you are. Empty boasting. There's no formal model, no
>> proof, no published paper... Just grandiose claims. It's textbook
>> boasting. It's as if someone said that they have a universal compiler
>> that can compile any programming language with no supporting evidence.
>
> I am working on my universal compiler this weekend actually: there is
> "no supporting evidence" because it isn't finished/released.

To say, as far back as 2019, that your universal compiler /can/ do
something it can't yet do even now (specifically "compile any
programming language") is a classic boast.

--
Ben.

On Fri, 02 Sep 2022 17:07:04 +0100
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>
> > On Fri, 02 Sep 2022 02:46:44 +0100
> > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> >
> >> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>
> >> > I am not boasting:
> >>
> >> Of course you are. Empty boasting. There's no formal model, no
> >> proof, no published paper... Just grandiose claims. It's textbook
> >> boasting. It's as if someone said that they have a universal
> >> compiler that can compile any programming language with no
> >> supporting evidence.
> >
> > I am working on my universal compiler this weekend actually: there
> > is "no supporting evidence" because it isn't finished/released.
>
> To say, as far back as 2019, that your universal compiler /can/ do
> something it can't yet do even now (specifically "compile any
> programming language") is a classic boast.

You are confusing a boast with a statement of fact.

/Flibble

On 9/2/2022 3:45 AM, Otto J. Makela wrote:
> olcott <polcott2@gmail.com> wrote:
>
>> On 8/31/2022 10:55 AM, Otto J. Makela wrote:
>>> However, this very same case shows that H() does return a value, and
>>> H() returning a value of 0 for (all?) cases involving itself would
>>> also seem to be incorrect.
>>
>> In every case where the simulation of the input by H would never stop
>> running H aborts its simulation and returns 0.
>
> Why would a simulation of H() not return a value, once it had done the
> same kind of deduction?
>

A simulating halt decider must abort the simulation of every otherwise
non-terminating input. It does this by correctly recognizing
non-terminating behavior patterns.

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

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

The fact that I JUST said that same thing to the same statement, with no
"rebuttal" of that fact, says that either you are a pathological liar,
totalubg uignorant, or learning disable. (or maybe you just can't read
big words)

Sorry, you argument is invalid, and you are shown to have FAILED.

Please point out where I am actually wrong.

Or provide an ACTUAL copetent software engineer, who has been FULLY
breifed on all the details, like that the input function CALLS the
function being modified, that is willing to go ON RECORD as having
agreed with your.

This is basically the Fallacy ad Populum, where the populum don't
actually agree with your arguemnt.

Sorry, you FAIL.

On 9/2/22 1:14 PM, olcott wrote:
> On 9/2/2022 3:45 AM, Otto J. Makela wrote:
>> olcott <polcott2@gmail.com> wrote:
>>
>>> On 8/31/2022 10:55 AM, Otto J. Makela wrote:
>>>> However, this very same case shows that H() does return a value, and
>>>> H() returning a value of 0 for (all?) cases involving itself would
>>>> also seem to be incorrect.
>>>
>>> In every case where the simulation of the input by H would never stop
>>> running H aborts its simulation and returns 0.
>>
>> Why would a simulation of H() not return a value, once it had done the
>> same kind of deduction?
>>
>
> A simulating halt decider must abort the simulation of every otherwise
> non-terminating input. It does this by correctly recognizing
> non-terminating behavior patterns.
>

Too bad you decider has false positives.

On 9/2/2022 7:52 AM, Paul N wrote:
> On Thursday, September 1, 2022 at 8:59:18 PM UTC+1, olcott wrote:
>> It is an easily verified fact when H(P,P) correctly simulates its input
>> that this simulated input would never stop running unless H aborts its
>> simulation of this input.
>
> On the contrary, if H(P,P) correctly simulates its input then it does halt. Richard has gone through the details several times. Your simulator assumes that H will not abort, so it is inaccurate as H does abort.

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.

--
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 2:28 PM, olcott wrote:
> On 9/2/2022 7:52 AM, Paul N wrote:
>> On Thursday, September 1, 2022 at 8:59:18 PM UTC+1, olcott wrote:
>>> It is an easily verified fact when H(P,P) correctly simulates its input
>>> that this simulated input would never stop running unless H aborts its
>>> simulation of this input.
>>
>> On the contrary, if H(P,P) correctly simulates its input then it does
>> halt. Richard has gone through the details several times. Your
>> simulator assumes that H will not abort, so it is inaccurate as H does
>> abort.
>
> 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.
>

Name ONE. (Not you).

Note, replacing the call of H(P,P) in main, with a call to Hfixed(P,P)
where Hfixed omites the erroneous halting pattern, (while H still calles
its DEFIECTIVE P) shows that Hfxed(P,P) correctly answers Halting.

Thus, H was wrong to abort.

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.

--
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 1:21 PM, Richard Damon wrote:
> On 9/2/22 1:14 PM, olcott wrote:
>> On 9/2/2022 3:45 AM, Otto J. Makela wrote:
>>> olcott <polcott2@gmail.com> wrote:
>>>
>>>> On 8/31/2022 10:55 AM, Otto J. Makela wrote:
>>>>> However, this very same case shows that H() does return a value, and
>>>>> H() returning a value of 0 for (all?) cases involving itself would
>>>>> also seem to be incorrect.
>>>>
>>>> In every case where the simulation of the input by H would never stop
>>>> running H aborts its simulation and returns 0.
>>>
>>> Why would a simulation of H() not return a value, once it had done the
>>> same kind of deduction?
>>>
>>
>> A simulating halt decider must abort the simulation of every otherwise
>> non-terminating input. It does this by correctly recognizing
>> non-terminating behavior patterns.
>>
>
> Too bad you decider has false positives.

When-so-ever the input simulated by H would never stop running unless
aborted conclusively proves that the correct and complete simulation of
this input never halts.

No weasel word double talk can possibly show otherwise because my words
are verified as completely true entirely based on their meaning.

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

I have asked this previously, and you haven't answered, which implies
your claim is invalid.

FAIL.

You are just showing your ignorance and desperation.

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.

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

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

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

Mr Flibble <flibble@reddwarf.jmc.corp> writes:

> On Fri, 02 Sep 2022 17:07:04 +0100
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>>
>> > On Fri, 02 Sep 2022 02:46:44 +0100
>> > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> >
>> >> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>>
>> >> > I am not boasting:
>> >>
>> >> Of course you are. Empty boasting. There's no formal model, no
>> >> proof, no published paper... Just grandiose claims. It's textbook
>> >> boasting. It's as if someone said that they have a universal
>> >> compiler that can compile any programming language with no
>> >> supporting evidence.
>> >
>> > I am working on my universal compiler this weekend actually: there
>> > is "no supporting evidence" because it isn't finished/released.
>>
>> To say, as far back as 2019, that your universal compiler /can/ do
>> something it can't yet do even now (specifically "compile any
>> programming language") is a classic boast.
>
> You are confusing a boast with a statement of fact.

Now that /is/ a plain troll! Bravo!

--
Ben.