function HALT( PROG, INP )
IF TOPSTACK > 1
THEN
-PRINT "halt out of scope"
-HALT="halts"
-BREAK
ELSE
..... halting code....

solves the halting problem.

USING KEYBOARD

>HALT(D D) [ENTER]
halts

>D(D) [ENTER]
halt out of scope

D(D) halts as HALT(D D) predicted

Graham Cooper <grahamcooper7@gmail.com> writes:

> function HALT( PROG, INP )
> IF TOPSTACK > 1
> THEN
> -PRINT "halt out of scope"
> -HALT="halts"
> -BREAK
> ELSE
> .... halting code....
>
> solves the halting problem.
>
> USING KEYBOARD
>
>>HALT(D D) [ENTER]
> halts
>
>>D(D) [ENTER]
> halt out of scope
>
> D(D) halts as HALT(D D) predicted

This is a well known trick. (I posted actual C code to do this some
time ago.) To be fair, when PO was being secretive he denied he was
playing such tricks and indeed it turns out he wasn't. He's just
asserting that the wrong answer is the right answer:

Me: do you still assert that H(P,P) == false is the "correct" answer
even though P(P) halts?
PO: Yes that is the correct answer even though P(P) halts.

--
Ben.

On Sunday, February 19, 2023 at 12:16:23 AM UTC+11, Ben Bacarisse wrote:
> Graham Cooper <graham...@gmail.com> writes:
>
> > function HALT( PROG, INP )
> > IF TOPSTACK > 1
> > THEN
> > -PRINT "halt out of scope"
> > -HALT="halts"
> > -BREAK
> > ELSE
> > .... halting code....
> >
> > solves the halting problem.
> >
> > USING KEYBOARD
> >
> >>HALT(D D) [ENTER]
> > halts
> >
> >>D(D) [ENTER]
> > halt out of scope
> >
> > D(D) halts as HALT(D D) predicted
> This is a well known trick. (I posted actual C code to do this some

then why do you reject your own work ?

actually its not a great solution as the program

finiteprimes()
p=3
while halt(nextprime(p))
p=nextprime(p)

is not part of HALT domain

--------------

as
halt( finiteprimes() ) ?

subcalls halt

-------------

Much better to use

HALT(prog inp) ==> {TF?}

and tolerate ? as meaning 'PROGRAM IS JUNK'
IN A WAY ITS STILL TOTAL

On 2/18/23 9:46 AM, Graham Cooper wrote:
> On Sunday, February 19, 2023 at 12:16:23 AM UTC+11, Ben Bacarisse wrote:
>> Graham Cooper <graham...@gmail.com> writes:
>>
>>> function HALT( PROG, INP )
>>> IF TOPSTACK > 1
>>> THEN
>>> -PRINT "halt out of scope"
>>> -HALT="halts"
>>> -BREAK
>>> ELSE
>>> .... halting code....
>>>
>>> solves the halting problem.
>>>
>>> USING KEYBOARD
>>>
>>>> HALT(D D) [ENTER]
>>> halts
>>>
>>>> D(D) [ENTER]
>>> halt out of scope
>>>
>>> D(D) halts as HALT(D D) predicted
>> This is a well known trick. (I posted actual C code to do this some
>
> then why do you reject your own work ?
>
> actually its not a great solution as the program
>
> finiteprimes()
> p=3
> while halt(nextprime(p))
> p=nextprime(p)
>
> is not part of HALT domain

And why not? Halt is supposed to be able to decide on ANY program, and
since Halt itself is a program, it can be part of a program.

You are basically admitting that Halt might have problems with programs
that use halt, so blindly outlaw it.

>
> --------------
>
> as
> halt( finiteprimes() ) ?
>
> subcalls halt
>
> -------------
>
> Much better to use
>
> HALT(prog inp) ==> {TF?}
>
> and tolerate ? as meaning 'PROGRAM IS JUNK'
> IN A WAY ITS STILL TOTAL
>
>
No, it isn't "total" if it is allowed to reject some programs as ones it
can't answer about.

That is a BROKEN definition of "total"

Maybe if you can precisely define what conditions allow for the
answering of the "?" response. The problem is you won't be able to
define it in a way that actually works.

On Sunday, February 19, 2023 at 2:02:54 AM UTC+11, Richard Damon wrote:
> On 2/18/23 9:46 AM, Graham Cooper wrote:
> > On Sunday, February 19, 2023 at 12:16:23 AM UTC+11, Ben Bacarisse wrote:
> >> Graham Cooper <graham...@gmail.com> writes:
> >>
> >>> function HALT( PROG, INP )
> >>> IF TOPSTACK > 1
> >>> THEN
> >>> -PRINT "halt out of scope"
> >>> -HALT="halts"
> >>> -BREAK
> >>> ELSE
> >>> .... halting code....
> >>>
> >>> solves the halting problem.
> >>>
> >>> USING KEYBOARD
> >>>
> >>>> HALT(D D) [ENTER]
> >>> halts
> >>>
> >>>> D(D) [ENTER]
> >>> halt out of scope
> >>>
> >>> D(D) halts as HALT(D D) predicted
> >> This is a well known trick. (I posted actual C code to do this some
> >
> > then why do you reject your own work ?
> >
> > actually its not a great solution as the program
> >
> > finiteprimes()
> > p=3
> > while halt(nextprime(p))
> > p=nextprime(p)
> >
> > is not part of HALT domain
> And why not? Halt is supposed to be able to decide on ANY program, and
> since Halt itself is a program, it can be part of a program.
>
> You are basically admitting that Halt might have problems with programs
> that use halt, so blindly outlaw it.
> >
> > --------------
> >
> > as
> > halt( finiteprimes() ) ?
> >
> > subcalls halt
> >
> > -------------
> >
> > Much better to use
> >
> > HALT(prog inp) ==> {TF?}
> >
> > and tolerate ? as meaning 'PROGRAM IS JUNK'
> > IN A WAY ITS STILL TOTAL
> >
> >
> No, it isn't "total" if it is allowed to reject some programs as ones it
> can't answer about.
>
> That is a BROKEN definition of "total"
>
> Maybe if you can precisely define what conditions allow for the
> answering of the "?" response. The problem is you won't be able to
> define it in a way that actually works.

define PATHOLOGICAL_SELF_REFERENCE(p)
IF
halt(p)=1 -> p-loops
OR
halt(p)=0 -> p-halts
RETURN TRUE

define PATHOLOGICAL_SELF_REFERENCE(p)
IF
halt(p)=1 -> p-loops
AND
halt(p)=0 -> p-halts
RETURN TRUE

On 2/18/23 10:31 AM, Graham Cooper wrote:
> On Sunday, February 19, 2023 at 2:02:54 AM UTC+11, Richard Damon wrote:
>> On 2/18/23 9:46 AM, Graham Cooper wrote:
>>> On Sunday, February 19, 2023 at 12:16:23 AM UTC+11, Ben Bacarisse wrote:
>>>> Graham Cooper <graham...@gmail.com> writes:
>>>>
>>>>> function HALT( PROG, INP )
>>>>> IF TOPSTACK > 1
>>>>> THEN
>>>>> -PRINT "halt out of scope"
>>>>> -HALT="halts"
>>>>> -BREAK
>>>>> ELSE
>>>>> .... halting code....
>>>>>
>>>>> solves the halting problem.
>>>>>
>>>>> USING KEYBOARD
>>>>>
>>>>>> HALT(D D) [ENTER]
>>>>> halts
>>>>>
>>>>>> D(D) [ENTER]
>>>>> halt out of scope
>>>>>
>>>>> D(D) halts as HALT(D D) predicted
>>>> This is a well known trick. (I posted actual C code to do this some
>>>
>>> then why do you reject your own work ?
>>>
>>> actually its not a great solution as the program
>>>
>>> finiteprimes()
>>> p=3
>>> while halt(nextprime(p))
>>> p=nextprime(p)
>>>
>>> is not part of HALT domain
>> And why not? Halt is supposed to be able to decide on ANY program, and
>> since Halt itself is a program, it can be part of a program.
>>
>> You are basically admitting that Halt might have problems with programs
>> that use halt, so blindly outlaw it.
>>>
>>> --------------
>>>
>>> as
>>> halt( finiteprimes() ) ?
>>>
>>> subcalls halt
>>>
>>> -------------
>>>
>>> Much better to use
>>>
>>> HALT(prog inp) ==> {TF?}
>>>
>>> and tolerate ? as meaning 'PROGRAM IS JUNK'
>>> IN A WAY ITS STILL TOTAL
>>>
>>>
>> No, it isn't "total" if it is allowed to reject some programs as ones it
>> can't answer about.
>>
>> That is a BROKEN definition of "total"
>>
>> Maybe if you can precisely define what conditions allow for the
>> answering of the "?" response. The problem is you won't be able to
>> define it in a way that actually works.
>
> define PATHOLOGICAL_SELF_REFERENCE(p)
> IF
> halt(p)=1 -> p-loops
> OR
> halt(p)=0 -> p-halts
> RETURN TRUE
>

Except that can't be defined if you can't actually do Halt Detecting.

So, YOUR definition has gone circular.

Graham Cooper <grahamcooper7@gmail.com> writes:

> On Sunday, February 19, 2023 at 12:16:23 AM UTC+11, Ben Bacarisse wrote:
>> Graham Cooper <graham...@gmail.com> writes:
>>
>> > function HALT( PROG, INP )
>> > IF TOPSTACK > 1
>> > THEN
>> > -PRINT "halt out of scope"
>> > -HALT="halts"
>> > -BREAK
>> > ELSE
>> > .... halting code....
>> >
>> > solves the halting problem.
>> >
>> > USING KEYBOARD
>> >
>> >>HALT(D D) [ENTER]
>> > halts
>> >
>> >>D(D) [ENTER]
>> > halt out of scope
>> >
>> > D(D) halts as HALT(D D) predicted
>> This is a well known trick. (I posted actual C code to do this some
>
> then why do you reject your own work ?

Because it has nothing to do with the halting theorem or its proof.

--
Ben.

On 2/18/2023 1:29 PM, Ben Bacarisse wrote:
> Graham Cooper <grahamcooper7@gmail.com> writes:
>
>> On Sunday, February 19, 2023 at 12:16:23 AM UTC+11, Ben Bacarisse wrote:
>>> Graham Cooper <graham...@gmail.com> writes:
>>>
>>>> function HALT( PROG, INP )
>>>> IF TOPSTACK > 1
>>>> THEN
>>>> -PRINT "halt out of scope"
>>>> -HALT="halts"
>>>> -BREAK
>>>> ELSE
>>>> .... halting code....
>>>>
>>>> solves the halting problem.
>>>>
>>>> USING KEYBOARD
>>>>
>>>>> HALT(D D) [ENTER]
>>>> halts
>>>>
>>>>> D(D) [ENTER]
>>>> halt out of scope
>>>>
>>>> D(D) halts as HALT(D D) predicted
>>> This is a well known trick. (I posted actual C code to do this some
>>
>> then why do you reject your own work ?
>
> Because it has nothing to do with the halting theorem or its proof.
>

int D(int (*x)())
{ int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}

int main()
{ Output("Input_Halts = ", H(D,D));
Output("Input_Halts = ", D(D));
}

*This is a verified fact*
H correctly determines that D correctly simulated by H
cannot possibly reach its own return statement, then H
aborts this simulation and correctly returns 0 for non-halting.

To say that it has literally *nothing to do with the halting theorem* is
an intentionally untruthful statement.

Here is an an example statement that has literally *nothing*
to do with the halting theorem:

*spaghetti sauce on vanilla ice cream tastes great*
Can you see the contrast?

An accurate paraphrase of Ben's statement would say:
"In my opinion Olcott's work does not directly apply to the halting theorem"

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

On Sunday, February 19, 2023 at 7:17:52 AM UTC+11, olcott wrote:
> On 2/18/2023 1:29 PM, Ben Bacarisse wrote:
> > Graham Cooper <graham...@gmail.com> writes:
> >
> >> On Sunday, February 19, 2023 at 12:16:23 AM UTC+11, Ben Bacarisse wrote:
> >>> Graham Cooper <graham...@gmail.com> writes:
> >>>
> >>>> function HALT( PROG, INP )
> >>>> IF TOPSTACK > 1
> >>>> THEN
> >>>> -PRINT "halt out of scope"
> >>>> -HALT="halts"
> >>>> -BREAK
> >>>> ELSE
> >>>> .... halting code....
> >>>>
> >>>> solves the halting problem.
> >>>>
> >>>> USING KEYBOARD
> >>>>
> >>>>> HALT(D D) [ENTER]
> >>>> halts
> >>>>
> >>>>> D(D) [ENTER]
> >>>> halt out of scope
> >>>>
> >>>> D(D) halts as HALT(D D) predicted
> >>> This is a well known trick. (I posted actual C code to do this some
> >>
> >> then why do you reject your own work ?
> >
> > Because it has nothing to do with the halting theorem or its proof.
> >

> To say that it has literally *nothing to do with the halting theorem* is
> an intentionally untruthful statement.
>
> Here is an an example statement that has literally *nothing*
> to do with the halting theorem:
>
> *spaghetti sauce on vanilla ice cream tastes great*
> Can you see the contrast?
>
> An accurate paraphrase of Ben's statement would say:
> "In my opinion Olcott's work does not directly apply to the halting theorem"

AGREED! Ben is a true dyslexic and cant even tell LEFT from RIGHT which shows in his reasoning.

Reading a TOPSTACK value is part of an equivalent model of computation to Turing Machines

On Sunday, February 19, 2023 at 2:02:54 AM UTC+11, Richard Damon wrote:
> On 2/18/23 9:46 AM, Graham Cooper wrote:
> > On Sunday, February 19, 2023 at 12:16:23 AM UTC+11, Ben Bacarisse wrote:
> >> Graham Cooper <graham...@gmail.com> writes:
> >>
> >>> function HALT( PROG, INP )
> >>> IF TOPSTACK > 1
> >>> THEN
> >>> -PRINT "halt out of scope"
> >>> -HALT="halts"
> >>> -BREAK
> >>> ELSE
> >>> .... halting code....
> >>>
> >>> solves the halting problem.
> >>>
> >>> USING KEYBOARD
> >>>
> >>>> HALT(D D) [ENTER]
> >>> halts
> >>>
> >>>> D(D) [ENTER]
> >>> halt out of scope
> >>>
> >>> D(D) halts as HALT(D D) predicted
> >> This is a well known trick. (I posted actual C code to do this some
> >
> > then why do you reject your own work ?
> >
> > actually its not a great solution as the program
> >
> > finiteprimes()
> > p=3
> > while halt(nextprime(p))
> > p=nextprime(p)
> >
> > is not part of HALT domain
> And why not? Halt is supposed to be able to decide on ANY program, and
> since Halt itself is a program, it can be part of a program.
>
> You are basically admitting that Halt might have problems with programs
> that use halt, so blindly outlaw it.

RIGHT! I prefer a ternary output model of HALT
You have shown HALT to be a useful callable function

> >
> > --------------
> >
> > as
> > halt( finiteprimes() ) ?
> >
> > subcalls halt
> >
> > -------------
> >
> > Much better to use
> >
> > HALT(prog inp) ==> {TF?}
> >
> > and tolerate ? as meaning 'PROGRAM IS JUNK'
> > IN A WAY ITS STILL TOTAL
> >
> >
> No, it isn't "total" if it is allowed to reject some programs as ones it
> can't answer about.
>
> That is a BROKEN definition of "total"

Then send D into an INFINITE LOOP by feeding it 'halts'
yet return 'loops' when called from keyboard

function HALT( PROG, INP )
IF TOPSTACK > 1
THEN
-RETURN "halts"
ELSE
..... halting code....
..... if PROG calls Halt return "loops"
.....

On Sunday, February 19, 2023 at 2:47:08 AM UTC+11, Richard Damon wrote:
> On 2/18/23 10:31 AM, Graham Cooper wrote:
> > On Sunday, February 19, 2023 at 2:02:54 AM UTC+11, Richard Damon wrote:
> >> On 2/18/23 9:46 AM, Graham Cooper wrote:
> >>> On Sunday, February 19, 2023 at 12:16:23 AM UTC+11, Ben Bacarisse wrote:
> >>>> Graham Cooper <graham...@gmail.com> writes:
> >>>>
> >>>>> function HALT( PROG, INP )
> >>>>> IF TOPSTACK > 1
> >>>>> THEN
> >>>>> -PRINT "halt out of scope"
> >>>>> -HALT="halts"
> >>>>> -BREAK
> >>>>> ELSE
> >>>>> .... halting code....
> >>>>>
> >>>>> solves the halting problem.
> >>>>>
> >>>>> USING KEYBOARD
> >>>>>
> >>>>>> HALT(D D) [ENTER]
> >>>>> halts
> >>>>>
> >>>>>> D(D) [ENTER]
> >>>>> halt out of scope
> >>>>>
> >>>>> D(D) halts as HALT(D D) predicted
> >>>> This is a well known trick. (I posted actual C code to do this some
> >>>
> >>> then why do you reject your own work ?
> >>>
> >>> actually its not a great solution as the program
> >>>
> >>> finiteprimes()
> >>> p=3
> >>> while halt(nextprime(p))
> >>> p=nextprime(p)
> >>>
> >>> is not part of HALT domain
> >> And why not? Halt is supposed to be able to decide on ANY program, and
> >> since Halt itself is a program, it can be part of a program.
> >>
> >> You are basically admitting that Halt might have problems with programs
> >> that use halt, so blindly outlaw it.
> >>>
> >>> --------------
> >>>
> >>> as
> >>> halt( finiteprimes() ) ?
> >>>
> >>> subcalls halt
> >>>
> >>> -------------
> >>>
> >>> Much better to use
> >>>
> >>> HALT(prog inp) ==> {TF?}
> >>>
> >>> and tolerate ? as meaning 'PROGRAM IS JUNK'
> >>> IN A WAY ITS STILL TOTAL
> >>>
> >>>
> >> No, it isn't "total" if it is allowed to reject some programs as ones it
> >> can't answer about.
> >>
> >> That is a BROKEN definition of "total"
> >>
> >> Maybe if you can precisely define what conditions allow for the
> >> answering of the "?" response. The problem is you won't be able to
> >> define it in a way that actually works.
> >
> > define PATHOLOGICAL_SELF_REFERENCE(p)
> > IF
> > halt(p)=1 -> p-loops
> > OR
> > halt(p)=0 -> p-halts
> > RETURN TRUE
> >
> Except that can't be defined if you can't actually do Halt Detecting.
>
> So, YOUR definition has gone circular.

OK... you can PARSE p without executing halt

define PATHOLOGICAL_SELF_REFERENCE(p)
IF
p:halt(p)=1 -> p-loops
AND
p:halt(p)=0 -> p-halts
RETURN TRUE

On 2/18/23 3:54 PM, Graham Cooper wrote:
> On Sunday, February 19, 2023 at 2:02:54 AM UTC+11, Richard Damon wrote:
>> On 2/18/23 9:46 AM, Graham Cooper wrote:
>>> On Sunday, February 19, 2023 at 12:16:23 AM UTC+11, Ben Bacarisse wrote:
>>>> Graham Cooper <graham...@gmail.com> writes:
>>>>
>>>>> function HALT( PROG, INP )
>>>>> IF TOPSTACK > 1
>>>>> THEN
>>>>> -PRINT "halt out of scope"
>>>>> -HALT="halts"
>>>>> -BREAK
>>>>> ELSE
>>>>> .... halting code....
>>>>>
>>>>> solves the halting problem.
>>>>>
>>>>> USING KEYBOARD
>>>>>
>>>>>> HALT(D D) [ENTER]
>>>>> halts
>>>>>
>>>>>> D(D) [ENTER]
>>>>> halt out of scope
>>>>>
>>>>> D(D) halts as HALT(D D) predicted
>>>> This is a well known trick. (I posted actual C code to do this some
>>>
>>> then why do you reject your own work ?
>>>
>>> actually its not a great solution as the program
>>>
>>> finiteprimes()
>>> p=3
>>> while halt(nextprime(p))
>>> p=nextprime(p)
>>>
>>> is not part of HALT domain
>> And why not? Halt is supposed to be able to decide on ANY program, and
>> since Halt itself is a program, it can be part of a program.
>>
>> You are basically admitting that Halt might have problems with programs
>> that use halt, so blindly outlaw it.
>
>
> RIGHT! I prefer a ternary output model of HALT
> You have shown HALT to be a useful callable function
>
>>>
>>> --------------
>>>
>>> as
>>> halt( finiteprimes() ) ?
>>>
>>> subcalls halt
>>>
>>> -------------
>>>
>>> Much better to use
>>>
>>> HALT(prog inp) ==> {TF?}
>>>
>>> and tolerate ? as meaning 'PROGRAM IS JUNK'
>>> IN A WAY ITS STILL TOTAL
>>>
>>>
>> No, it isn't "total" if it is allowed to reject some programs as ones it
>> can't answer about.
>>
>> That is a BROKEN definition of "total"
>
> Then send D into an INFINITE LOOP by feeding it 'halts'
> yet return 'loops' when called from keyboard

What "Keyboard"?

>
>
> function HALT( PROG, INP )
> IF TOPSTACK > 1
> THEN
> -RETURN "halts"
> ELSE
> .... halting code....
> .... if PROG calls Halt return "loops"
> ....
>
>

So Halts still calls programs that halt as looping, in violation of the
specificaiton, just because it calls halts.

For instance, Halts will says that Halts fails to meet its requirement
to return an answer and halt.

On 2/18/23 4:02 PM, Graham Cooper wrote:
> On Sunday, February 19, 2023 at 2:47:08 AM UTC+11, Richard Damon wrote:
>> On 2/18/23 10:31 AM, Graham Cooper wrote:
>>> On Sunday, February 19, 2023 at 2:02:54 AM UTC+11, Richard Damon wrote:
>>>> On 2/18/23 9:46 AM, Graham Cooper wrote:
>>>>> On Sunday, February 19, 2023 at 12:16:23 AM UTC+11, Ben Bacarisse wrote:
>>>>>> Graham Cooper <graham...@gmail.com> writes:
>>>>>>
>>>>>>> function HALT( PROG, INP )
>>>>>>> IF TOPSTACK > 1
>>>>>>> THEN
>>>>>>> -PRINT "halt out of scope"
>>>>>>> -HALT="halts"
>>>>>>> -BREAK
>>>>>>> ELSE
>>>>>>> .... halting code....
>>>>>>>
>>>>>>> solves the halting problem.
>>>>>>>
>>>>>>> USING KEYBOARD
>>>>>>>
>>>>>>>> HALT(D D) [ENTER]
>>>>>>> halts
>>>>>>>
>>>>>>>> D(D) [ENTER]
>>>>>>> halt out of scope
>>>>>>>
>>>>>>> D(D) halts as HALT(D D) predicted
>>>>>> This is a well known trick. (I posted actual C code to do this some
>>>>>
>>>>> then why do you reject your own work ?
>>>>>
>>>>> actually its not a great solution as the program
>>>>>
>>>>> finiteprimes()
>>>>> p=3
>>>>> while halt(nextprime(p))
>>>>> p=nextprime(p)
>>>>>
>>>>> is not part of HALT domain
>>>> And why not? Halt is supposed to be able to decide on ANY program, and
>>>> since Halt itself is a program, it can be part of a program.
>>>>
>>>> You are basically admitting that Halt might have problems with programs
>>>> that use halt, so blindly outlaw it.
>>>>>
>>>>> --------------
>>>>>
>>>>> as
>>>>> halt( finiteprimes() ) ?
>>>>>
>>>>> subcalls halt
>>>>>
>>>>> -------------
>>>>>
>>>>> Much better to use
>>>>>
>>>>> HALT(prog inp) ==> {TF?}
>>>>>
>>>>> and tolerate ? as meaning 'PROGRAM IS JUNK'
>>>>> IN A WAY ITS STILL TOTAL
>>>>>
>>>>>
>>>> No, it isn't "total" if it is allowed to reject some programs as ones it
>>>> can't answer about.
>>>>
>>>> That is a BROKEN definition of "total"
>>>>
>>>> Maybe if you can precisely define what conditions allow for the
>>>> answering of the "?" response. The problem is you won't be able to
>>>> define it in a way that actually works.
>>>
>>> define PATHOLOGICAL_SELF_REFERENCE(p)
>>> IF
>>> halt(p)=1 -> p-loops
>>> OR
>>> halt(p)=0 -> p-halts
>>> RETURN TRUE
>>>
>> Except that can't be defined if you can't actually do Halt Detecting.
>>
>> So, YOUR definition has gone circular.
>
> OK... you can PARSE p without executing halt
>
>
> define PATHOLOGICAL_SELF_REFERENCE(p)
> IF
> p:halt(p)=1 -> p-loops
> AND
> p:halt(p)=0 -> p-halts
> RETURN TRUE
>

So, you are going to define any program that calls halt as pathological,
or are you going to need to halt detect the code after the calls to halt
to see if it is looping?

IF the latter, you still need to have a halt decider before you can
define your criteria for halt deciding.

On 2/18/23 3:17 PM, olcott wrote:
> On 2/18/2023 1:29 PM, Ben Bacarisse wrote:
>> Graham Cooper <grahamcooper7@gmail.com> writes:
>>
>>> On Sunday, February 19, 2023 at 12:16:23 AM UTC+11, Ben Bacarisse wrote:
>>>> Graham Cooper <graham...@gmail.com> writes:
>>>>
>>>>> function HALT( PROG, INP )
>>>>> IF TOPSTACK > 1
>>>>> THEN
>>>>> -PRINT "halt out of scope"
>>>>> -HALT="halts"
>>>>> -BREAK
>>>>> ELSE
>>>>> .... halting code....
>>>>>
>>>>> solves the halting problem.
>>>>>
>>>>> USING KEYBOARD
>>>>>
>>>>>> HALT(D D) [ENTER]
>>>>> halts
>>>>>
>>>>>> D(D) [ENTER]
>>>>> halt out of scope
>>>>>
>>>>> D(D) halts as HALT(D D) predicted
>>>> This is a well known trick. (I posted actual C code to do this some
>>>
>>> then why do you reject your own work ?
>>
>> Because it has nothing to do with the halting theorem or its proof.
>>
>
> int D(int (*x)())
> {
>   int Halt_Status = H(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return Halt_Status;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H(D,D));
>   Output("Input_Halts = ", D(D));
> }
>
> *This is a verified fact*

No, it isn't, your arguement is based on LIE like that H can be several
different programs at once (your 'Set') and not a specific defined program.

It is based on the lie that H DOES a correct simulation that shows
non-halting behavior, when it aborts before it gets to, but it presumes
that the H it sees is a different program that you decietfully also call H.

> H correctly determines that D correctly simulated by H
> cannot possibly reach its own return statement, then H
> aborts this simulation and correctly returns 0 for non-halting.

No, H determines that if H was a different program, that it isn't, that
the D built from that other H would just simulate forever.

>
> To say that it has literally *nothing to do with the halting theorem* is
> an intentionally untruthful statement.

No, it is a precisely TRUE statement, because Halting has NOTHING to do
with the abilities of the decider. Halting is STRICTLY about the
behavior of the actual machine being described, which you have admitted
does HALT.

Thus ANY statement that a correct halting decider could say
"Non-halting" for that input is just a BANTANT LIE.

>
> Here is an an example statement that has literally *nothing*
> to do with the halting theorem:
>
> *spaghetti sauce on vanilla ice cream tastes great*
> Can you see the contrast?
>
> An accurate paraphrase of Ben's statement would say:
> "In my opinion Olcott's work does not directly apply to the halting
> theorem"
>
>

On 2/18/2023 7:16 AM, Ben Bacarisse wrote:
> Graham Cooper <grahamcooper7@gmail.com> writes:
>
>> function HALT( PROG, INP )
>> IF TOPSTACK > 1
>> THEN
>> -PRINT "halt out of scope"
>> -HALT="halts"
>> -BREAK
>> ELSE
>> .... halting code....
>>
>> solves the halting problem.
>>
>> USING KEYBOARD
>>
>>> HALT(D D) [ENTER]
>> halts
>>
>>> D(D) [ENTER]
>> halt out of scope
>>
>> D(D) halts as HALT(D D) predicted
>
> This is a well known trick. (I posted actual C code to do this some
> time ago.) To be fair, when PO was being secretive he denied he was
> playing such tricks and indeed it turns out he wasn't. He's just
> asserting that the wrong answer is the right answer:
>
> Me: do you still assert that H(P,P) == false is the "correct" answer
> even though P(P) halts?
> PO: Yes that is the correct answer even though P(P) halts.
>

No directly executed P(P) or correctly simulated input to H(P,P) ever
stops running unless H aborts its simulation of P. This fact alone
conclusively proves that H correctly rejects its input P as non-halting.

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

On 2/24/23 4:28 PM, olcott wrote:
> On 2/18/2023 7:16 AM, Ben Bacarisse wrote:
>> Graham Cooper <grahamcooper7@gmail.com> writes:
>>
>>> function HALT( PROG, INP )
>>> IF TOPSTACK > 1
>>> THEN
>>> -PRINT "halt out of scope"
>>> -HALT="halts"
>>> -BREAK
>>> ELSE
>>> .... halting code....
>>>
>>> solves the halting problem.
>>>
>>> USING KEYBOARD
>>>
>>>> HALT(D D) [ENTER]
>>> halts
>>>
>>>> D(D) [ENTER]
>>> halt out of scope
>>>
>>> D(D) halts as HALT(D D) predicted
>>
>> This is a well known trick.  (I posted actual C code to do this some
>> time ago.)  To be fair, when PO was being secretive he denied he was
>> playing such tricks and indeed it turns out he wasn't.  He's just
>> asserting that the wrong answer is the right answer:
>>
>> Me: do you still assert that H(P,P) == false is the "correct" answer
>>      even though P(P) halts?
>> PO: Yes that is the correct answer even though P(P) halts.
>>
>
> No directly executed P(P) or correctly simulated input to H(P,P) ever
> stops running unless H aborts its simulation of P. This fact alone
> conclusively proves that H correctly rejects its input P as non-halting.
>
>

Which is a meaningless statement since every H that answers H(P,P) does
abort its simulation, so your condition is a fantasy.

Since H(P,P) aborts its simulation, the actual machine P(P), which is
what H is actually being axked about, halts.

Remember, In computability theory, the halting problem is the problem of
determining, from a description of an arbitrary computer program and an
input, whether the program will finish running, or continue to run forever.

So it is the behavior of the actual machine that matters, and your
continued focus on the INCOMPLETE simulation by H just shows that you
are using a strawman because you have straw for brains.

------------------------------------
| | | |000010000 000010000| | | | | | | | | | | |
______________________

a BLANK in the tape

On Saturday, February 25, 2023 at 12:11:46 PM UTC+11, Richard Damon wrote:
> On 2/24/23 4:28 PM, olcott wrote:
> > On 2/18/2023 7:16 AM, Ben Bacarisse wrote:
> >> Graham Cooper <graham...@gmail.com> writes:
> >>
> >>> function HALT( PROG, INP )
> >>> IF TOPSTACK > 1
> >>> THEN
> >>> -PRINT "halt out of scope"
> >>> -HALT="halts"
> >>> -BREAK
> >>> ELSE
> >>> .... halting code....
> >>>
> >>> solves the halting problem.
> >>>
> >>> USING KEYBOARD
> >>>
> >>>> HALT(D D) [ENTER]
> >>> halts
> >>>
> >>>> D(D) [ENTER]
> >>> halt out of scope
> >>>
> >>> D(D) halts as HALT(D D) predicted
> >>
> >> This is a well known trick. (I posted actual C code to do this some
> >> time ago.) To be fair, when PO was being secretive he denied he was
> >> playing such tricks and indeed it turns out he wasn't. He's just
> >> asserting that the wrong answer is the right answer:
> >>
> >> Me: do you still assert that H(P,P) == false is the "correct" answer
> >> even though P(P) halts?
> >> PO: Yes that is the correct answer even though P(P) halts.
> >>
> >
> > No directly executed P(P) or correctly simulated input to H(P,P) ever
> > stops running unless H aborts its simulation of P. This fact alone
> > conclusively proves that H correctly rejects its input P as non-halting..
> >
> >
> Which is a meaningless statement since every H that answers H(P,P) does
> abort its simulation, so your condition is a fantasy.
>
> Since H(P,P) aborts its simulation, the actual machine P(P), which is
> what H is actually being axked about, halts.
>
> Remember, In computability theory, the halting problem is the problem of
> determining, from a description of an arbitrary computer program and an
> input, whether the program will finish running, or continue to run forever.
>
> So it is the behavior of the actual machine that matters, and your
> continued focus on the INCOMPLETE simulation by H just shows that you
> are using a strawman because you have straw for brains.

LINZ uses a function to duplicate the input on the TAPE
When D inputs its own number it calculates HALT(D D) exactly
but when HALT(D D)=1 D(D) loops and HALT(D D)=0 D(D) halts
breaking the HALT SPECIFICATION

MAKING HALT TOTAL

1. DEFINE ILLOGICAL_SELF_REFERENCE

ISR(P I)
IF [1 / P:HALT(P I) ] & P(I)-->LOOPS
AND [ 0 / P:HALT(P I) ] & P(I)-->HALTS
RETURN TRUE

Halt performs 2 test cases SUBSTITING 1 and 0 into the examined call of halt

2. DEFINE HALT(P I)

2A. SIMULATE P(I)
2B. IF P() CALLS HALT DO A CHECK
2C. PUT VALUE HALT()=1 AND SIMULATE
2D. PUT VALUE HALT()=0 AND SIMLUATE

3. IF (ISR) RETURN 'FALSE' WHICH MAKES P(I) HALT
3A. PRINT 'PROGRAM ACTUALLY HALTS'

4. DEFINE HALT AS WHAT IT DOES

HALT(P I) INPUTS ANY PROGRAM WITHOUT ISR
AND OUTPUTS TRUE IFF THAT PROGRAM HALTS

HALT() IS TOTAL!

Theres no infinite succession of calls to halt

call 1 halt(d d)

inspect d(d)
find output from d() call to halt
2 test cases
substitute halt(d d) with 0
substitute halt(d d) with 1

for each test case SIMULATE general runs of d(d) through working paths
decide if d(d) halts or not
if [0/halt] --> halts
and [1/halt] --> hangs
then define as ISR
print 'PROGRAM ACTUALLY HALTS'
return 0 [hangs] which makes d() halt

The screen display is always correct!

ALL(P) ALL(I) HALT(P I)=TRUE
IFF
P(I) HALTS ^ !ISR(P)

HALTING PROOF
There is no program that detects infinite loops

ASSUME
H(Prog Inp)=1 <-> Prog(Inp) HALTS
H(Prog Inp)=0 <-> Prog(Inp) LOOPS

function D(x)
if H(x x) D(x)

H(D D)=1 ==> D(d) Loops [CONTRADICTION]
H(D D)=0 ==> D(d) Halts [CONTRADICTION]

CONTRADICTION
There exist programs that HALT(program) gets the wrong answer.

On 3/1/23 6:07 AM, Graham Cooper wrote:
> ------------------------------------
> | | | |000010000 000010000| | | | | | | | | | | |
> ______________________
>
> a BLANK in the tape
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Saturday, February 25, 2023 at 12:11:46 PM UTC+11, Richard Damon wrote:
>> On 2/24/23 4:28 PM, olcott wrote:
>>> On 2/18/2023 7:16 AM, Ben Bacarisse wrote:
>>>> Graham Cooper <graham...@gmail.com> writes:
>>>>
>>>>> function HALT( PROG, INP )
>>>>> IF TOPSTACK > 1
>>>>> THEN
>>>>> -PRINT "halt out of scope"
>>>>> -HALT="halts"
>>>>> -BREAK
>>>>> ELSE
>>>>> .... halting code....
>>>>>
>>>>> solves the halting problem.
>>>>>
>>>>> USING KEYBOARD
>>>>>
>>>>>> HALT(D D) [ENTER]
>>>>> halts
>>>>>
>>>>>> D(D) [ENTER]
>>>>> halt out of scope
>>>>>
>>>>> D(D) halts as HALT(D D) predicted
>>>>
>>>> This is a well known trick. (I posted actual C code to do this some
>>>> time ago.) To be fair, when PO was being secretive he denied he was
>>>> playing such tricks and indeed it turns out he wasn't. He's just
>>>> asserting that the wrong answer is the right answer:
>>>>
>>>> Me: do you still assert that H(P,P) == false is the "correct" answer
>>>> even though P(P) halts?
>>>> PO: Yes that is the correct answer even though P(P) halts.
>>>>
>>>
>>> No directly executed P(P) or correctly simulated input to H(P,P) ever
>>> stops running unless H aborts its simulation of P. This fact alone
>>> conclusively proves that H correctly rejects its input P as non-halting.
>>>
>>>
>> Which is a meaningless statement since every H that answers H(P,P) does
>> abort its simulation, so your condition is a fantasy.
>>
>> Since H(P,P) aborts its simulation, the actual machine P(P), which is
>> what H is actually being axked about, halts.
>>
>> Remember, In computability theory, the halting problem is the problem of
>> determining, from a description of an arbitrary computer program and an
>> input, whether the program will finish running, or continue to run forever.
>>
>> So it is the behavior of the actual machine that matters, and your
>> continued focus on the INCOMPLETE simulation by H just shows that you
>> are using a strawman because you have straw for brains.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> LINZ uses a function to duplicate the input on the TAPE
> When D inputs its own number it calculates HALT(D D) exactly
> but when HALT(D D)=1 D(D) loops and HALT(D D)=0 D(D) halts
> breaking the HALT SPECIFICATION
>
>
> MAKING HALT TOTAL
>
> 1. DEFINE ILLOGICAL_SELF_REFERENCE
>
> ISR(P I)
> IF [1 / P:HALT(P I) ] & P(I)-->LOOPS
> AND [ 0 / P:HALT(P I) ] & P(I)-->HALTS
> RETURN TRUE

So ISR needs a Halt Decider to determine its answer, and Halt needs ISR
first to determine its answer, so your definition gets stuck in an
infinte loop.

You are making the incorrect assumption that you can recognise all
instances of the input using the algorithm of the decider.

>
> Halt performs 2 test cases SUBSTITING 1 and 0 into the examined call of halt
>
> 2. DEFINE HALT(P I)
>
> 2A. SIMULATE P(I)
> 2B. IF P() CALLS HALT DO A CHECK
> 2C. PUT VALUE HALT()=1 AND SIMULATE
> 2D. PUT VALUE HALT()=0 AND SIMLUATE

And if either of these don't halt, how do you answer?

Your Halt Decider needs a Halt Decider, thus gets stuck in an infinite loop.

>
> 3. IF (ISR) RETURN 'FALSE' WHICH MAKES P(I) HALT
> 3A. PRINT 'PROGRAM ACTUALLY HALTS'
>
> 4. DEFINE HALT AS WHAT IT DOES

You don't get to define Halting.

>
> HALT(P I) INPUTS ANY PROGRAM WITHOUT ISR
> AND OUTPUTS TRUE IFF THAT PROGRAM HALTS
>
> HALT() IS TOTAL!
>
>
> Theres no infinite succession of calls to halt
>
> call 1 halt(d d)
>
> inspect d(d)
> find output from d() call to halt

But identifying copies of equivalent computations is also an impossible
problem.

Remember, d is defined to contain a copy of the algorithm of H, not just
call it. There is an unbounded number of ways to express a given
algorithm, so you can't locate them all.

> 2 test cases
> substitute halt(d d) with 0
> substitute halt(d d) with 1
>
> for each test case SIMULATE general runs of d(d) through working paths
> decide if d(d) halts or not

So, your halt decider needs a correct halt decider to determine its answwer.

> if [0/halt] --> halts
> and [1/halt] --> hangs
> then define as ISR
> print 'PROGRAM ACTUALLY HALTS'
> return 0 [hangs] which makes d() halt
>
> The screen display is always correct!

Nope,

>
> ALL(P) ALL(I) HALT(P I)=TRUE
> IFF
> P(I) HALTS ^ !ISR(P)
>
>
>
>
> HALTING PROOF
> There is no program that detects infinite loops
>
> ASSUME
> H(Prog Inp)=1 <-> Prog(Inp) HALTS
> H(Prog Inp)=0 <-> Prog(Inp) LOOPS
>
> function D(x)
> if H(x x) D(x)
>
> H(D D)=1 ==> D(d) Loops [CONTRADICTION]
> H(D D)=0 ==> D(d) Halts [CONTRADICTION]
>
> CONTRADICTION
> There exist programs that HALT(program) gets the wrong answer.
>

Yep, thats the proof.

Since no matter what H(D,D) says, D(D) will do something different.

On 2/18/2023 7:16 AM, Ben Bacarisse wrote:
> Graham Cooper <grahamcooper7@gmail.com> writes:
>
>> function HALT( PROG, INP )
>> IF TOPSTACK > 1
>> THEN
>> -PRINT "halt out of scope"
>> -HALT="halts"
>> -BREAK
>> ELSE
>> .... halting code....
>>
>> solves the halting problem.
>>
>> USING KEYBOARD
>>
>>> HALT(D D) [ENTER]
>> halts
>>
>>> D(D) [ENTER]
>> halt out of scope
>>
>> D(D) halts as HALT(D D) predicted
>
> This is a well known trick. (I posted actual C code to do this some
> time ago.) To be fair, when PO was being secretive he denied he was
> playing such tricks and indeed it turns out he wasn't. He's just
> asserting that the wrong answer is the right answer:
>
> Me: do you still assert that H(P,P) == false is the "correct" answer
> even though P(P) halts?
> PO: Yes that is the correct answer even though P(P) halts.
>

When simulating halt decider H correctly predicts that directly executed
D(D) would remain stuck in recursive simulation (run forever) unless H
aborts its simulation of D this directly applies to the halting theorem
because H correctly determines:

from a description of an arbitrary computer program and an input,
whether the program will finish running, or continue to run forever.

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

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

On 2/18/2023 7:16 AM, Ben Bacarisse wrote:
> Graham Cooper <grahamcooper7@gmail.com> writes:
>
>> function HALT( PROG, INP )
>> IF TOPSTACK > 1
>> THEN
>> -PRINT "halt out of scope"
>> -HALT="halts"
>> -BREAK
>> ELSE
>> .... halting code....
>>
>> solves the halting problem.
>>
>> USING KEYBOARD
>>
>>> HALT(D D) [ENTER]
>> halts
>>
>>> D(D) [ENTER]
>> halt out of scope
>>
>> D(D) halts as HALT(D D) predicted
>
> This is a well known trick. (I posted actual C code to do this some
> time ago.) To be fair, when PO was being secretive he denied he was
> playing such tricks and indeed it turns out he wasn't. He's just
> asserting that the wrong answer is the right answer:
>
> Me: do you still assert that H(P,P) == false is the "correct" answer
> even though P(P) halts?
> PO: Yes that is the correct answer even though P(P) halts.
>

int P(int (*x)())
{ int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}

// P(P) remains stuck in recursive simulation unless H aborts its
simulation of P
int main()
{ P(P);
}

*That (a) proves (b) is a tautology*
(a) If simulating halt decider H correctly simulates its input P until H
correctly determines that its simulated P would never stop running
unless aborted then

(b) H can abort its simulation of P and correctly report that P
specifies a non-halting sequence of configurations.

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

On 3/4/23 12:51 PM, olcott wrote:
> On 2/18/2023 7:16 AM, Ben Bacarisse wrote:
>> Graham Cooper <grahamcooper7@gmail.com> writes:
>>
>>> function HALT( PROG, INP )
>>> IF TOPSTACK > 1
>>> THEN
>>> -PRINT "halt out of scope"
>>> -HALT="halts"
>>> -BREAK
>>> ELSE
>>> .... halting code....
>>>
>>> solves the halting problem.
>>>
>>> USING KEYBOARD
>>>
>>>> HALT(D D) [ENTER]
>>> halts
>>>
>>>> D(D) [ENTER]
>>> halt out of scope
>>>
>>> D(D) halts as HALT(D D) predicted
>>
>> This is a well known trick.  (I posted actual C code to do this some
>> time ago.)  To be fair, when PO was being secretive he denied he was
>> playing such tricks and indeed it turns out he wasn't.  He's just
>> asserting that the wrong answer is the right answer:
>>
>> Me: do you still assert that H(P,P) == false is the "correct" answer
>>      even though P(P) halts?
>> PO: Yes that is the correct answer even though P(P) halts.
>>
>
> When simulating halt decider H correctly predicts that directly executed
> D(D) would remain stuck in recursive simulation (run forever) unless H
> aborts its simulation of D this directly applies to the halting theorem
> because H correctly determines:

No, it shows you don't understand the problem.

There is just ONE H at a time, and ONE D built on it.

If the H that D calls doesn't abort its simulation, H never answer and
isn't a Halt Decider. And the "outer" H will do the same and not be a
decider.

If the H that D calls DOES abort its simulation so it answer, then D
will return, and be non-halting. And the "outer" H will do the same
thing and answer non-halting and not be a correct halt decider.

Thus, you are imagining a FALSE world where H can be both a Simulating
Halt Decider that doesn't abort this simulation and ohe that does.

>
>    from a description of an arbitrary computer program and an input,
>    whether the program will finish running, or continue to run forever.

Right, THE EXACT PROGRAM GIVEN.

That is D built on the H that is giving the answer, which is the H that
does abort its simulat

>
>    For any program H that might determine whether programs halt,
>    a "pathological" program D, called with some input, can pass its
>    own source and its input to H and then specifically do the opposite
>    of what H predicts D will do.
>    https://en.wikipedia.org/wiki/Halting_problem
>

Right, the "pathological" program is impossible for the decider it is
built on to give the correct answer.

On 3/4/23 1:06 PM, olcott wrote:
> On 2/18/2023 7:16 AM, Ben Bacarisse wrote:
>> Graham Cooper <grahamcooper7@gmail.com> writes:
>>
>>> function HALT( PROG, INP )
>>> IF TOPSTACK > 1
>>> THEN
>>> -PRINT "halt out of scope"
>>> -HALT="halts"
>>> -BREAK
>>> ELSE
>>> .... halting code....
>>>
>>> solves the halting problem.
>>>
>>> USING KEYBOARD
>>>
>>>> HALT(D D) [ENTER]
>>> halts
>>>
>>>> D(D) [ENTER]
>>> halt out of scope
>>>
>>> D(D) halts as HALT(D D) predicted
>>
>> This is a well known trick.  (I posted actual C code to do this some
>> time ago.)  To be fair, when PO was being secretive he denied he was
>> playing such tricks and indeed it turns out he wasn't.  He's just
>> asserting that the wrong answer is the right answer:
>>
>> Me: do you still assert that H(P,P) == false is the "correct" answer
>>      even though P(P) halts?
>> PO: Yes that is the correct answer even though P(P) halts.
>>
>
> int P(int (*x)())
> {
>   int Halt_Status = H(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return Halt_Status;
> }
>
> // P(P) remains stuck in recursive simulation unless H aborts its
> simulation of P
> int main()
> {
>   P(P);
> }
>
> *That (a) proves (b) is a tautology*
> (a) If simulating halt decider H correctly simulates its input P until H
> correctly determines that its simulated P would never stop running
> unless aborted then
>
> (b) H can abort its simulation of P and correctly report that P
> specifies a non-halting sequence of configurations.
>

Since "Its simulated P" doesn't require the simulation to actually be
done by H, H can never get to that point, since if at any point H does
decided to abort its simulation and return Non-Halting to its caller
(like P) the correct simulation of the representation of that P will see
this happen, and P then Halt.

Thus H can NEVER correctly determine that the correct simulation of its
input will never halt running if THAT simulation is not aborted.

If you talk about its own, then you hit a paradox, how can H correctly
reason about something that can not happen. The only way the input
represents a D built on an H that does not abort is if H does not abort,
and if that is the case, then H can not abort, or you are just proved to
be a lir.

On 2/18/2023 7:16 AM, Ben Bacarisse wrote:
> Graham Cooper <grahamcooper7@gmail.com> writes:
>
>> function HALT( PROG, INP )
>> IF TOPSTACK > 1
>> THEN
>> -PRINT "halt out of scope"
>> -HALT="halts"
>> -BREAK
>> ELSE
>> .... halting code....
>>
>> solves the halting problem.
>>
>> USING KEYBOARD
>>
>>> HALT(D D) [ENTER]
>> halts
>>
>>> D(D) [ENTER]
>> halt out of scope
>>
>> D(D) halts as HALT(D D) predicted
>
> This is a well known trick. (I posted actual C code to do this some
> time ago.) To be fair, when PO was being secretive he denied he was
> playing such tricks and indeed it turns out he wasn't. He's just
> asserting that the wrong answer is the right answer:
>
> Me: do you still assert that H(P,P) == false is the "correct" answer
> even though P(P) halts?
> PO: Yes that is the correct answer even though P(P) halts.
>

It is a verified fact that P correctly simulated by H can not
possibly reach its own return instruction and halt in any finite
number of simulated steps.

void P(ptr x)
{ int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

H(D,D) is fully operational in the x86utm operating system:
https://github.com/plolcott/x86utm

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

On 4/4/2023 11:32 PM, olcott wrote:
> On 2/18/2023 7:16 AM, Ben Bacarisse wrote:
>> Graham Cooper <grahamcooper7@gmail.com> writes:
>>
>>> function HALT( PROG, INP )
>>> IF TOPSTACK > 1
>>> THEN
>>> -PRINT "halt out of scope"
>>> -HALT="halts"
>>> -BREAK
>>> ELSE
>>> .... halting code....
>>>
>>> solves the halting problem.
>>>
>>> USING KEYBOARD
>>>
>>>> HALT(D D) [ENTER]
>>> halts
>>>
>>>> D(D) [ENTER]
>>> halt out of scope
>>>
>>> D(D) halts as HALT(D D) predicted
>>
>> This is a well known trick.  (I posted actual C code to do this some
>> time ago.)  To be fair, when PO was being secretive he denied he was
>> playing such tricks and indeed it turns out he wasn't.  He's just
>> asserting that the wrong answer is the right answer:
>>
>> Me: do you still assert that H(P,P) == false is the "correct" answer
>>      even though P(P) halts?
>> PO: Yes that is the correct answer even though P(P) halts.
>>
>
> It is a verified fact that P correctly simulated by H can not
> possibly reach its own return instruction and halt in any finite
> number of simulated steps.
>

H does compute the mapping from its input to its own reject state on the
basis of the actual behavior of this input.

> void P(ptr x)
> {
>   int Halt_Status = H(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return;
> }
>
> H(D,D) is fully operational in the x86utm operating system:
> https://github.com/plolcott/x86utm
>

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