On Tuesday, 2 August 2022 at 22:07:13 UTC+2, Mr Flibble wrote:
> How can it be the same? My solution has THREE outcomes whereas your
> nonsense has FOUR outcomes. Last time I checked 3 != 4.
Can you even count? If you have solved the halting problem then your solution has 4 outcomes!

True
False
Exception
Failure to halt.

On Tue, 2 Aug 2022 13:17:05 -0700 (PDT)
Skep Dick <skepdick22@gmail.com> wrote:

> On Tuesday, 2 August 2022 at 22:07:13 UTC+2, Mr Flibble wrote:
> > How can it be the same? My solution has THREE outcomes whereas your
> > nonsense has FOUR outcomes. Last time I checked 3 != 4.
>
> Can you even count? If you have solved the halting problem then your
> solution has 4 outcomes!
>
> True
> False
> Exception
> Failure to halt.
>

No, there are 3 outcomes:

1) Input halts
2) Input does not halt
3) Input is invalid

/Flibble

On Tuesday, 2 August 2022 at 22:34:30 UTC+2, Mr Flibble wrote:
> On Tue, 2 Aug 2022 13:17:05 -0700 (PDT)
> Skep Dick <skepd...@gmail.com> wrote:
>
> > On Tuesday, 2 August 2022 at 22:07:13 UTC+2, Mr Flibble wrote:
> > > How can it be the same? My solution has THREE outcomes whereas your
> > > nonsense has FOUR outcomes. Last time I checked 3 != 4.
> >
> > Can you even count? If you have solved the halting problem then your
> > solution has 4 outcomes!
> >
> > True
> > False
> > Exception
> > Failure to halt.
> >
> No, there are 3 outcomes:
>
> 1) Input halts
> 2) Input does not halt
> 3) Input is invalid

Why aren’t you counting failure-to-halt as a 4th outcome?

On Tue, 2 Aug 2022 13:42:09 -0700 (PDT)
Skep Dick <skepdick22@gmail.com> wrote:

> On Tuesday, 2 August 2022 at 22:34:30 UTC+2, Mr Flibble wrote:
> > On Tue, 2 Aug 2022 13:17:05 -0700 (PDT)
> > Skep Dick <skepd...@gmail.com> wrote:
> >
> > > On Tuesday, 2 August 2022 at 22:07:13 UTC+2, Mr Flibble wrote:
> > > > How can it be the same? My solution has THREE outcomes whereas
> > > > your nonsense has FOUR outcomes. Last time I checked 3 != 4.
> > >
> > > Can you even count? If you have solved the halting problem then
> > > your solution has 4 outcomes!
> > >
> > > True
> > > False
> > > Exception
> > > Failure to halt.
> > >
> > No, there are 3 outcomes:
> >
> > 1) Input halts
> > 2) Input does not halt
> > 3) Input is invalid
>
> Why aren’t you counting failure-to-halt as a 4th outcome?

There is no 4th outcome.

/Flibble

On Tuesday, 2 August 2022 at 22:45:25 UTC+2, Mr Flibble wrote:
> There is no 4th outcome.

Who says?

On 8/2/2022 12:18 PM, Andy Walker wrote:
> On 02/08/2022 18:54, Jeff Barnett wrote:
>> Once again, the proof shows there is no right answer, but there is
>> one more step to complete the proof: "If there is no right answer for
>> some problems, then an actual decider simply cannot exist." [...]
>
>     Just to be clear, /given/ a program and its input, there /is/ a
> "right answer" to the HP question applied to that program and input.
> What the "usual" proof shows is not that there is no right answer, but
> that no one TM can always find it.
There must be a correct answer in a system that includes us and the
logic we try to use. If you stick to formalities, what you prove is that
there isn't a correct answer (in the "world" the problem is formally
defined in). This is, I believe, just like saying there are statements
that cannot be proven in Peano arithmetic but can be if a higher level
logic is used. All the standard proof shows is that there is no
consistent answer for a problem and that is a contradiction so the (set
of) assumptions are inconsistent.
>> Assume that you have an H(TM,INPUT) that properly returns a value in
>> {halts, pathological, infinite-loop} [...].
>
>     Neither PO nor Flibble has ever given a sensible definition of
> what they mean by "pathological", and of course if they do they will
> fall foul of Rice's Theorem.  Further, there seems somehow to be an
> assumption that "infinite loop" is the only way that a program can
> fail to halt.  If only it was so simple!
If the actual pathologies in this USENET group would accept Rice's
theorem for anything, these discussions would have ceased decades ago.
But where's the fun or the honor of allowing the world to know you've
made errors that no first term student could make and get to the second
term?
--
Jeff Barnett

On Tue, 2 Aug 2022 15:13:56 -0600
Jeff Barnett <jbb@notatt.com> wrote:

> On 8/2/2022 12:18 PM, Andy Walker wrote:
> > On 02/08/2022 18:54, Jeff Barnett wrote:
> >> Once again, the proof shows there is no right answer, but there is
> >> one more step to complete the proof: "If there is no right answer
> >> for some problems, then an actual decider simply cannot exist."
> >> [...]
> >
> >     Just to be clear, /given/ a program and its input, there /is/ a
> > "right answer" to the HP question applied to that program and input.
> > What the "usual" proof shows is not that there is no right answer,
> > but that no one TM can always find it.
>
> There must be a correct answer in a system that includes us and the
> logic we try to use. If you stick to formalities, what you prove is
> that there isn't a correct answer (in the "world" the problem is
> formally defined in). This is, I believe, just like saying there are
> statements that cannot be proven in Peano arithmetic but can be if a
> higher level logic is used. All the standard proof shows is that
> there is no consistent answer for a problem and that is a
> contradiction so the (set of) assumptions are inconsistent.
>
> >> Assume that you have an H(TM,INPUT) that properly returns a value
> >> in {halts, pathological, infinite-loop} [...].
> >
> >     Neither PO nor Flibble has ever given a sensible definition of
> > what they mean by "pathological", and of course if they do they will
> > fall foul of Rice's Theorem.  Further, there seems somehow to be an
> > assumption that "infinite loop" is the only way that a program can
> > fail to halt.  If only it was so simple!
>
> If the actual pathologies in this USENET group would accept Rice's
> theorem for anything, these discussions would have ceased decades
> ago. But where's the fun or the honor of allowing the world to know
> you've made errors that no first term student could make and get to
> the second term?

Errors? You have had the opportunity to point out any errors in my
solution and you have failed to do so. Please explain, if I cannot
get past first time, why I have a BSc (Hons) CompSci degree?

/Flibble

On Tuesday, 2 August 2022 at 23:17:50 UTC+2, Mr Flibble wrote:
> why I have a BSc (Hons) CompSci degree?

You should ask for a refund.

On Tue, 2 Aug 2022 14:20:51 -0700 (PDT)
Skep Dick <skepdick22@gmail.com> wrote:

> On Tuesday, 2 August 2022 at 23:17:50 UTC+2, Mr Flibble wrote:
> > why I have a BSc (Hons) CompSci degree?
>
> You should ask for a refund.

"Consistently ranked in the top 200 universities worldwide, we are a
member of the prestigious Russell Group of the UK's leading research
universities and have a global reach and influence that reflects our
academic heritage as one of the country's largest civic institutions."

/Flibble

On Tuesday, 2 August 2022 at 23:24:02 UTC+2, Mr Flibble wrote:
> On Tue, 2 Aug 2022 14:20:51 -0700 (PDT)
> Skep Dick <skepd...@gmail.com> wrote:
>
> > On Tuesday, 2 August 2022 at 23:17:50 UTC+2, Mr Flibble wrote:
> > > why I have a BSc (Hons) CompSci degree?
> >
> > You should ask for a refund.
> "Consistently ranked in the top 200 universities worldwide, we are a
> member of the prestigious Russell Group of the UK's leading research
> universities and have a global reach and influence that reflects our
> academic heritage as one of the country's largest civic institutions."

All the more reason to ask for a refund.

They gave you a title despite your lack of understanding of the fundamental result in the discipline for which you "qualified".

On Tue, 2 Aug 2022 14:33:30 -0700 (PDT)
Skep Dick <skepdick22@gmail.com> wrote:

> On Tuesday, 2 August 2022 at 23:24:02 UTC+2, Mr Flibble wrote:
> > On Tue, 2 Aug 2022 14:20:51 -0700 (PDT)
> > Skep Dick <skepd...@gmail.com> wrote:
> >
> > > On Tuesday, 2 August 2022 at 23:17:50 UTC+2, Mr Flibble wrote:
> > > > why I have a BSc (Hons) CompSci degree?
> > >
> > > You should ask for a refund.
> > "Consistently ranked in the top 200 universities worldwide, we are
> > a member of the prestigious Russell Group of the UK's leading
> > research universities and have a global reach and influence that
> > reflects our academic heritage as one of the country's largest
> > civic institutions."
>
> All the more reason to ask for a refund.
>
> They gave you a title despite your lack of understanding of the
> fundamental result in the discipline for which you "qualified".

My refutation of [Strachey 1965] is novel and so far nobody has
pointed out any serious errors in it. Given that I would say that I do
not show a lack of understanding of a flawed "fundamental result".

/Flibble

On Tuesday, 2 August 2022 at 23:37:37 UTC+2, Mr Flibble wrote:
> My refutation of [Strachey 1965] is novel and so far nobody has
> pointed out any serious errors in it. Given that I would say that I do
> not show a lack of understanding of a flawed "fundamental result".

Many have pointed out your errors.

But your brain seems no more capable than a Turing machine in deciding that the non-trivial property of seriousness.

On Tue, 2 Aug 2022 14:43:32 -0700 (PDT)
Skep Dick <skepdick22@gmail.com> wrote:

> On Tuesday, 2 August 2022 at 23:37:37 UTC+2, Mr Flibble wrote:
> > My refutation of [Strachey 1965] is novel and so far nobody has
> > pointed out any serious errors in it. Given that I would say that I
> > do not show a lack of understanding of a flawed "fundamental
> > result".
>
> Many have pointed out your errors.

You say a lot without actually saying anything.

>
> But your brain seems no more capable than a Turing machine in
> deciding that the non-trivial property of seriousness.

Ditto.

/Flibble

On Tuesday, 2 August 2022 at 23:46:51 UTC+2, Mr Flibble wrote:
> You say a lot without actually saying anything.
I can only explain it to you. I can't understand it for you.

> Ditto.
Then how come I can see the seriousness of your errors and you can't?

On Tue, 2 Aug 2022 14:51:35 -0700 (PDT)
Skep Dick <skepdick22@gmail.com> wrote:

> On Tuesday, 2 August 2022 at 23:46:51 UTC+2, Mr Flibble wrote:
> > You say a lot without actually saying anything.
> I can only explain it to you. I can't understand it for you.
>
> > Ditto.
> Then how come I can see the seriousness of your errors and you can't?

But you are just a troll, incapable of fully grasping the topic under
discussion so can't in fact identify any serious errors at all; if you
could you would but you can't so won't. All you seem to be capable of
is creating really bad analogies in code of what you think is being
discussed.

/Flibble

On Tuesday, 2 August 2022 at 23:58:24 UTC+2, Mr Flibble wrote:
> But you are just a troll, incapable of fully grasping the topic under
> discussion so can't in fact identify any serious errors at all; if you
> could you would but you can't so won't. All you seem to be capable of
> is creating really bad analogies in code of what you think is being
> discussed.

You have nailed your own type-signature perfectly!

On 02/08/2022 22:13, Jeff Barnett wrote:
> [...] All the standard proof shows is that
> there is no consistent answer for a problem and that is a
> contradiction so the (set of) assumptions are inconsistent.

No, that's /not/ what the standard proof shows in relation
to the HP. What it shows is that given any program "H" there are
instances of programs and data that "H" fails with, and therefore
"H" is not a correct halt decider. It doesn't show [and how could
it?] that those instances are in any way inconsistent, pathological
or even difficult to analyse. Any given program+data combination
either halts or fails to halt; there is no third [or fourth!]
possible outcome.

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

On Wednesday, 3 August 2022 at 01:06:16 UTC+2, Andy Walker wrote:
> Any given program+data combination
> either halts or fails to halt; there is no third [or fourth!]
> possible outcome.

That's just a tautology of Classical logic. It's not true constructively.

Semi-decidability is the third possible outcome: you can't decide whether a given program+data combination will halt.

On 8/2/2022 6:06 PM, Andy Walker wrote:
> On 02/08/2022 22:13, Jeff Barnett wrote:
>> [...]  All the standard proof shows is that
>> there is no consistent answer for a problem and that is a
>> contradiction so the (set of) assumptions are inconsistent.
>
>     No, that's /not/ what the standard proof shows in relation
> to the HP.  What it shows is that given any program "H" there are
> instances of programs and data that "H" fails with, and therefore
> "H" is not a correct halt decider.

> It doesn't show [and how could
> it?] that those instances are in any way inconsistent, pathological
> or even difficult to analyse.

*So you believe the this Wikipedia article is flat out wrong*?
For any program H that might determine if programs halt, a
"pathological" program P, called with some input, can pass
its own source and its input to H and then specifically do
the opposite of what H predicts P will do.
*No H can exist that handles this case*
https://en.wikipedia.org/wiki/Halting_problem

> Any given program+data combination
> either halts or fails to halt;  there is no third [or fourth!]
> possible outcome.
>

--
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 8/2/2022 11:07 AM, Mikko wrote:
> On 2022-08-01 12:54:04 +0000, olcott said:
>
>> A halt decider must compute the mapping from its inputs to an accept
>> or reject state on the basis of the actual behavior that is actually
>> specified by these inputs.
>
> The halting problem does not require that. It merely says (or implies --
> each author uses different words but they aways mean the same) that
> - if H(M, I) returns false and M(I) halts then H is not a halt decider
> - if H(M, I) returns true and M(I) doesn't halt then H is not a halt
> decider
> - if H(M, I) returns something else then H is not a halt decider
> - if H(M, I) does not return then H is not a halt decider
> - otherwise H is a halt decider
>
> Mikko
>

Because

main()
{ H(P,P);
P(P);
}

If H(P,P) reports on the behavior of a sequence of instructions where P
has been executed first and H has not yet been executed then H is
reporting incorrectly, directly against the verified facts.

--
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 8/2/2022 5:06 PM, Andy Walker wrote:
> On 02/08/2022 22:13, Jeff Barnett wrote:
>> [...]  All the standard proof shows is that
>> there is no consistent answer for a problem and that is a
>> contradiction so the (set of) assumptions are inconsistent.
>
>     No, that's /not/ what the standard proof shows in relation
> to the HP.  What it shows is that given any program "H" there are
> instances of programs and data that "H" fails with, and therefore
> "H" is not a correct halt decider.  It doesn't show [and how could
> it?] that those instances are in any way inconsistent, pathological
> or even difficult to analyse.  Any given program+data combination
> either halts or fails to halt;  there is no third [or fourth!]
> possible outcome.
Try it again. I've said nothing about inconsistent or pathological
instances. What I said and you quoted me above is that the (set of)
assumptions are inconsistent since they lead to contradictions. One such
contradiction is shown in the proof and that is enough. Besides the
assumption that the h, a halt decider, itself always halts there are
many other assumptions including the very definition of TM. I've never
seen a proof that the definition of TM, with or without a halt decider
definition included, are consistent. In fact the Linz proof definitely
shows that there is no correct, consistent value to return. It really
doesn't point out which subset of definitions and axioms contain the
inconsistency.
If you have proved or believe (as I do) that everything before
introducing the formal definition of h is consistent, then we can point
the finger at the introduction of h as the problem source. But the proof
itself only shows that no answer is correct (i.e., any answer is
inconsistent). I think at this point we leap out of FOL and start a
different sort of discussion.
--
Jeff Barnett

On 8/2/2022 1:18 PM, Andy Walker wrote:
> On 02/08/2022 18:54, Jeff Barnett wrote:
>> Once again, the proof shows there is no right answer, but there is
>> one more step to complete the proof: "If there is no right answer for
>> some problems, then an actual decider simply cannot exist." [...]
>
>     Just to be clear, /given/ a program and its input, there /is/ a
> "right answer" to the HP question applied to that program and input.
> What the "usual" proof shows is not that there is no right answer, but
> that no one TM can always find it.
>
>> Assume that you have an H(TM,INPUT) that properly returns a value in
>> {halts, pathological, infinite-loop} [...].
>
>     Neither PO nor Flibble has ever given a sensible definition of
> what they mean by "pathological",

For any program H that might determine if programs halt,
a "pathological" program P, called with some input, can
pass its own source and its input to H and then specifically
do the opposite of what H predicts P will do.
*No H can exist that handles this case*
https://en.wikipedia.org/wiki/Halting_problem

Sipser says the same thing yet does not use the term "pathological".

"Now we construct a new Turing machine D with H as a subroutine.
This new TM calls H to determine what M does when the input to
M is its own description <M>. Once D has determined this information,
it does the opposite."
https://www.liarparadox.org/Sipser_165_167.pdf

> and of course if they do they will
> fall foul of Rice's Theorem.

It is my possibly incorrect understanding that Rice is anchored in the
halting problem such that when the HP proofs are correctly refuted this
refutation causes Rice to fail in that Rice could be reduced to the
refuted HP.

> Further, there seems somehow to be an
> assumption that "infinite loop" is the only way that a program can
> fail to halt.  If only it was so simple!
>

--
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 8/2/2022 1:56 PM, Mikko wrote:
> On 2022-08-02 18:44:24 +0000, Mr Flibble said:
>
>> On Tue, 2 Aug 2022 21:41:54 +0300
>> Mikko <mikko.levanto@iki.fi> wrote:
>>
>>> On 2022-08-02 16:11:54 +0000, Mr Flibble said:
>>>
>>>> On Tue, 2 Aug 2022 19:07:33 +0300
>>>> Mikko <mikko.levanto@iki.fi> wrote:
>>>>
>>>>> On 2022-08-01 12:54:04 +0000, olcott said:
>>>>>
>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>> accept or reject state on the basis of the actual behavior that is
>>>>>> actually specified by these inputs.
>>>>>
>>>>> The halting problem does not require that. It merely says (or
>>>>> implies -- each author uses different words but they aways mean
>>>>> the same) that
>>>>> - if H(M, I) returns false and M(I) halts then H is not a halt
>>>>> decider
>>>>> - if H(M, I) returns true and M(I) doesn't halt then H is not a
>>>>> halt decider
>>>>> - if H(M, I) returns something else then H is not a halt decider
>>>>> - if H(M, I) does not return then H is not a halt decider
>>>>> - otherwise H is a halt decider
>>>>
>>>> I can add to that (my key insight):
>>>>
>>>> - if H(M, I) doesn't signal an exception on pathological
>>>> ("Impossible Program") input then H is not a halt decider.
>>>
>>> No, you can't. The problem definition is what it is and you
>>> can't add anything to it, and it says or at least imlies that
>>> if H(M, I) signals an exception it is not a halt decider.
>>
>> Yes I can and I have. I have extended the definition of a halt decider.
>>
>> /Flibble
>
> If there is two conflicting definitions for the same term the definition
> published earlier is the valid one.
>
> Mikko
>

>
main()
{ H(P,P);
P(P);
}

If H(P,P) reports on the behavior of a sequence of instructions where P
has been executed first and H has not yet been executed then H is
reporting incorrectly, directly against the verified facts.

--
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 8/1/2022 8:40 PM, Dennis Bush wrote:
> On Monday, August 1, 2022 at 9:37:49 PM UTC-4, olcott wrote:
>> On 8/1/2022 8:17 PM, Dennis Bush wrote:
>>> On Monday, August 1, 2022 at 9:06:00 PM UTC-4, olcott wrote:
>>>> On 8/1/2022 7:50 PM, Dennis Bush wrote:
>>>>> On Monday, August 1, 2022 at 8:42:08 PM UTC-4, olcott wrote:
>>>>>> On 8/1/2022 7:36 PM, Dennis Bush wrote:
>>>>>>> On Monday, August 1, 2022 at 8:27:22 PM UTC-4, olcott wrote:
>>>>>>>> On 8/1/2022 7:16 PM, Dennis Bush wrote:
>>>>>>>>> On Monday, August 1, 2022 at 7:54:32 PM UTC-4, olcott wrote:
>>>>>>>>>> On 8/1/2022 6:06 PM, Dennis Bush wrote:
>>>>>>>>>>> On Monday, August 1, 2022 at 6:34:37 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 7/31/2022 9:30 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 7/31/22 10:00 PM, olcott wrote:
>>>>>>>>>>>>>> On 7/31/2022 8:36 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 7/31/22 9:26 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 7/31/2022 8:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 7/31/22 8:53 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 7/31/2022 1:43 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>> On Sunday, July 31, 2022 at 2:40:02 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 7/31/22 2:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 12:44 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 1:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (1) When H is a simulating halt decider that correctly
>>>>>>>>>>>>>>>>>>>>>>>> simulates its input with an x86 emulator, the simulation
>>>>>>>>>>>>>>>>>>>>>>>> will never
>>>>>>>>>>>>>>>>>>>>>>>> stop running until H(P,P) aborts its emulation of its input:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> (1) Executed H(P,P) simulates its input with an x86
>>>>>>>>>>>>>>>>>>>>>>>> emulator.
>>>>>>>>>>>>>>>>>>>>>>>> (2) Emulated P calls emulated H(P,P) to do this again.
>>>>>>>>>>>>>>>>>>>>>>>> (3) Emulated H(P,P) simulates its input with an x86
>>>>>>>>>>>>>>>>>>>>>>>> emulator.
>>>>>>>>>>>>>>>>>>>>>>>> (4) Emulated P calls emulated H(P,P) to do this again.
>>>>>>>>>>>>>>>>>>>>>>>> (5) Emulated H(P,P) simulates its input with an x86
>>>>>>>>>>>>>>>>>>>>>>>> emulator...
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> This is what happens if H doesn't abort its simulation. If H
>>>>>>>>>>>>>>>>>>>>>>> ever
>>>>>>>>>>>>>>>>>>>>>>> does abort its simulation, this is NOT what happens.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Good, I agree.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Note, an H that simulates until it can CORRECTLY determine
>>>>>>>>>>>>>>>>>>>>>>> that its
>>>>>>>>>>>>>>>>>>>>>>> input is non-halting, will match this pattern, because it
>>>>>>>>>>>>>>>>>>>>>>> will NEVER
>>>>>>>>>>>>>>>>>>>>>>> in finite time be able to actually correctly prove the input is
>>>>>>>>>>>>>>>>>>>>>>> non-halting, as ANY pattern that is defined (incorrectly) as
>>>>>>>>>>>>>>>>>>>>>>> non-halting, if it is seen by H in the simulation, and H
>>>>>>>>>>>>>>>>>>>>>>> stops its
>>>>>>>>>>>>>>>>>>>>>>> simulation and returns 0, causes the actual program P(P) to
>>>>>>>>>>>>>>>>>>>>>>> Halt.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Since that is the actual meaning of the question H(P,P) if H is
>>>>>>>>>>>>>>>>>>>>>>> actually a Halt Decider, that proves that H is incorrect to
>>>>>>>>>>>>>>>>>>>>>>> return 0
>>>>>>>>>>>>>>>>>>>>>>> from H(P,P) to say that P(P) is non-halting, since it is
>>>>>>>>>>>>>>>>>>>>>>> Halting.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> If you want to repeat you LIE that the input to H(P,P)
>>>>>>>>>>>>>>>>>>>>>>> generate a
>>>>>>>>>>>>>>>>>>>>>>> different sequence of configurations that P(P), please
>>>>>>>>>>>>>>>>>>>>>>> provide the
>>>>>>>>>>>>>>>>>>>>>>> FIRST configuration in the sequence that is different, and is
>>>>>>>>>>>>>>>>>>>>>>> actually the result of a CORRECT simulation of the input.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Note, the implication that H(P,P) seeing a call to H(P,P) is
>>>>>>>>>>>>>>>>>>>>>>> "proof"
>>>>>>>>>>>>>>>>>>>>>>> that its input is non-halting is proved incorrect and
>>>>>>>>>>>>>>>>>>>>>>> invalid, and
>>>>>>>>>>>>>>>>>>>>>>> your "proof" of this is based on assuming it, and thus falls
>>>>>>>>>>>>>>>>>>>>>>> into the
>>>>>>>>>>>>>>>>>>>>>>> fallacy of the assumption of the conclusion.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (2) Furthermore the input to H(P,P) that is correctly
>>>>>>>>>>>>>>>>>>>>>>>> simulated by H cannot possibly reach its own "ret" instruction
>>>>>>>>>>>>>>>>>>>>>>>> whether or not H aborts its simulation.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> No, that is only true if H doesn't abort its simuation.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> So you believe that when H aborts its simulation this causes the
>>>>>>>>>>>>>>>>>>>>>> simulated P to reach its "ret" instruction even after it has been
>>>>>>>>>>>>>>>>>>>>>> aborted before reaching this instruction?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Unless you reverse your position technically competent
>>>>>>>>>>>>>>>>>>>>>> reviewers will
>>>>>>>>>>>>>>>>>>>>>> understand that you are not a sufficiently technically competent
>>>>>>>>>>>>>>>>>>>>>> reviewer.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation, then a correct and complete
>>>>>>>>>>>>>>>>>>>>>>> simulation of
>>>>>>>>>>>>>>>>>>>>>>> the input will reach the return instruction.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation of P then the simulated P that is
>>>>>>>>>>>>>>>>>>>>>> no longer
>>>>>>>>>>>>>>>>>>>>>> running will continue several more execution steps and reach
>>>>>>>>>>>>>>>>>>>>>> its "ret"
>>>>>>>>>>>>>>>>>>>>>> instruction even though it has been forced to stop running
>>>>>>>>>>>>>>>>>>>>>> before ever
>>>>>>>>>>>>>>>>>>>>>> reaching the "ret" instruction.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> No, it causes the ACTUAL P, and the correct and COMPLETE
>>>>>>>>>>>>>>>>>>>>> simulation of
>>>>>>>>>>>>>>>>>>>>> the input to H(P,P) to reach the return instruction.
>>>>>>>>>>>>>>>>>>>> There is only a simulated P in the following:
>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>> So you agree that the input to H(P,P) that is correctly
>>>>>>>>>>>>>>>>>>>> simulated by H
>>>>>>>>>>>>>>>>>>>> cannot possibly reach the "ret" instruction of this simulated P
>>>>>>>>>>>>>>>>>>>> whether
>>>>>>>>>>>>>>>>>>>> or not H aborts its simulation or not?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Yes, I agree that there is no implementation of the function H
>>>>>>>>>>>>>>>>>>> that can simulate the function call P(P) to a final state. Which
>>>>>>>>>>>>>>>>>>> has nothing to do with the requirements of a halt decider.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> In other words you are saying that this is incorrect:
>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>>>>>>>>>>>>>> accept or reject state on the basis of the actual behavior that is
>>>>>>>>>>>>>>>>>> actually specified by these inputs.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No, just that the "Actual Behvior" is determined by the actual
>>>>>>>>>>>>>>>>> behavior of the program the input represents,
>>>>>>>>>>>>>>>> In other words you do not believe that the correct simulation of an
>>>>>>>>>>>>>>>> input necessarily has the exact same sequence of instructions that
>>>>>>>>>>>>>>>> are specified by this input, thus you reject the concept of UTM
>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No. a COMPLETE and correct simulation will recreate the behavior of
>>>>>>>>>>>>>>> the input. The COMPLETE part is important.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Not at all, as long as the partial simulation correctly matches any
>>>>>>>>>>>>>> correct infinite behavior pattern then there is no need to wait until
>>>>>>>>>>>>>> the end of time to see that an infinite loop never halts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> But the pattern is only a CORRECT infinite behavior pattern if the
>>>>>>>>>>>>> PROGRAM, this is P(P), gets into infinite recursion, which it doesn't if
>>>>>>>>>>>>> H(P,P) aborts its simulation.
>>>>>>>>>>>> So then you agree the H(P,P) does correctly determine the halt status of
>>>>>>>>>>>> its input, yet disagree that H is supposed to examine its input instead
>>>>>>>>>>>> it must examine the behavior of the non-input P(P) ?
>>>>>>>>>>>
>>>>>>>>>>> Sure, Ha(Pa,Pa) reports the halt status of "its input".
>>>>>>>>>> I count that as a huge breakthrough when 99% of of reviewers reject
>>>>>>>>>> everything that I say out-of-hand without even looking at it and
>>>>>>>>>> the remaining 1% are so laser focused on finding fault that they hardly
>>>>>>>>>> pay any attention to what I say.
>>>>>>>>>
>>>>>>>>> But is seems you're reading comprehension is failing you again. I know that when you say "H(P,P) does correctly determine the halt status of its input", what you really mean is "there is no implementation of the function H that can simulate the function call P(P) to a final state". And that is true, and is what I was agreeing about. That become more clear with what I said next:
>>>>>>>>>
>>>>>>>>>>> But that's apparently not the same as the halt status of the machine the input represents, specifically Pa(Pa), as per the definition of the function a halt decider is required to compute:
>>>>>>>>>>>
>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Where I point out you're answering the wrong question.
>>>>>>>>>
>>>>>>>>> Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. And everything that follows from here down is bunk because it depends on the wrong answer being right.
>>>>>>>>>
>>>>>>>>>> The behavior of directly executed P(P) is NOT the same behavior
>>>>>>>>>> as when H(P,P) correctly simulates its input because the execution
>>>>>>>>>> order of P(P) first is reversed when H(P,P) is invoked first.
>>>>>>>>>> void P(ptr x)
>>>>>>>>>> {
>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>> if (Halt_Status)
>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>> return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>> P(P);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> When P calls H(P,P) this is essentially the first call of
>>>>>>>>>> infinite recursion. When H(P,P) simulates its input this
>>>>>>>>>> is essentially the second call of infinite recursion.
>>>>>>>>>>
>>>>>>>>>> H can see the infinite recursion specified by its input and
>>>>>>>>>> aborts its simulation on that basis. As with all infinite
>>>>>>>>>> recursion when any call is aborted the whole sequence stops.
>>>>>>>>>> In this case when H(P,P) aborts its simulation it returns to
>>>>>>>>>> its caller.
>>>>>>>>>>
>>>>>>>>>> The input to H(P,P) is infinitely recursive (as proven by the fact
>>>>>>>>>> the the simulation never stops unless aborted) therefore H did
>>>>>>>>>> correctly determine the halt status of this input.
>>>>>>>>>>
>>>>>>>>>> That is was supposed to determine the halt status of a non-input
>>>>>>>>>> seems absurd and is rejected on the basis that software engineering
>>>>>>>>>> won't allow it.
>>>>>>>>>
>>>>>>>>> If determining the halt status of a non-input seems so absurd, why do you claim that Ha(Pa,Pa) must report the halt status of Pn(Pn)?
>>>>>>>>>
>>>>>>>> You know that never said anything like that:
>>>>>>>>
>>>>>>>> Try and find a date-and-time stamped quote of me
>>>>>>>> saying anything like that.
>>>>>>>
>>>>>>> That's precisely what the comment I've been quoting is saying:
>>>>>>>
>>>>>>> On Saturday, July 30, 2022 at 4:09:34 PM UTC-4, olcott wrote:
>>>>>>>> H(P,P) is asking would the input that I correctly emulate ever reach its
>>>>>>>> "ret" instruction (final state) if I never stopped emulating it?
>>>>>>>
>>>>>>> If Ha never stops emulating, then it is no longer Ha. It is Hn. That also means that Pa is no longer Pa since it's now calling Hn. It is now Pn.
>>>>>>>
>>>>>>> So by postulating that Ha has different behavior, you change the input. So the above is EXACTLY saying that Ha(Pa,Pa) must report on the behavior of Pn(Pn).
>>>>>> You did it incorrectly it must be Ha(Pa,Pa) and Hn(Pn,Pn).
>>>>>
>>>>> No, it was correct. If Ha(Pa,Pa) predicts what its input will do if its implementation is Hn, then Ha(Pa,Pa) is predicting the behavior of Pn(Pn). UTM(Pn,Pn) by definition has the same behavior of Pn(Pn), and given the
>>>>> of Hn it is essentially the same as a UTM.
>>>>>
>>>>>> A simulating halt decider is always correct to abort the simulation of
>>>>>> any input that it correctly predicts would never otherwise never stop
>>>>>> running.
>>>>>
>>>>> A simulating halt decider, like any halt decider, is required to map the halting function:
>>>>>
>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>
>>>> Yet in the case of H and P that would require a software function to
>>>> return the result of analyzing a non-input which from a software
>>>> engineering perspective is pure nonsense.
>>>
>>> You don't get to change the question.
>> When the question is WRONG, I do get to change the question.
>
> Are you saying that it's impossible for a function H to implement the following specification?
>
> H(X,Y)==1 if and only if X(Y) halts, and
> H(X,Y)==0 if and only if X(Y) does not halt

On 8/2/2022 1:41 AM, Skep Dick wrote:
> On Tuesday, 2 August 2022 at 03:50:20 UTC+2, olcott wrote:
>
>> int main()
>> {
>> H(P,P); // H is invoked first
>> P(P); // P is invoked first
>> }
>>
>> Thus the input to H(P,P) specifies a different sequence of instructions
>> than the direct execution of P(P).
>
> No, it doesn’t.
>
> A(B) means “apply A to B”
> B(A(C))) means “Apply B to (apply A to C))”
> B(A,C) means the same thing as B(A(C))
>
> Currying. You don’t understand it.
>
> https://en.wikipedia.org/wiki/Currying

main()
{ H(P,P);
P(P);
}

If H(P,P) reports on the behavior of a sequence of instructions where P
has been executed first and H has not yet been executed then H is
reporting incorrectly, directly against the verified facts.

--
Copyright 2022 Pete Olcott

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