On 6/6/2022 1:36 PM, Ben wrote:
> wij <wyniijj2@gmail.com> writes:
>
>> Students of average level understand Halting decider cannot exist, as olcott
>> has demonstrated for years (no 'correct' H exists).
>>
>> If H does not exist, what dose "H(P,P)==0" mean?
>
> H as specified in, say, Linz does not exist. But PO's H does and so P
> (which should really be called something like H_Hat) also exists.
> That's why H is wrong about the "halting" of P(P).
>
> Another way to write the proof is to show that every Turing machine gets
> at least one instance wrong -- i.e. that no TM computes the halting
> function. PO's H is just an example of that, and he even tells us that
> it gets the instance representing P(P) wrong.
>

Since you know that

(1) Deciders in computer science compute the mapping from their inputs
to an accept or reject state.

(2) P(P) is not an input to H

Why do you persist in the deception that H must compute the halt status
of P(P) ?

--
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 6/6/22 11:49 PM, olcott wrote:
> On 6/6/2022 1:36 PM, Ben wrote:
>> wij <wyniijj2@gmail.com> writes:
>>
>>> Students of average level understand Halting decider cannot exist, as
>>> olcott
>>> has demonstrated for years (no 'correct' H exists).
>>>
>>> If H does not exist, what dose "H(P,P)==0" mean?
>>
>> H as specified in, say, Linz does not exist.  But PO's H does and so P
>> (which should really be called something like H_Hat) also exists.
>> That's why H is wrong about the "halting" of P(P).
>>
>> Another way to write the proof is to show that every Turing machine gets
>> at least one instance wrong -- i.e. that no TM computes the halting
>> function.  PO's H is just an example of that, and he even tells us that
>> it gets the instance representing P(P) wrong.
>>
>
> Since you know that
>
> (1) Deciders in computer science compute the mapping from their inputs
> to an accept or reject state.
>
> (2) P(P) is not an input to H
>
> Why do you persist in the deception that H must compute the halt status
> of P(P) ?
>

But P(P) IS an input to H via its representation being given to H.

If you want to say that you can't actually give a computation to a
Turing Machine then the Halting Theorem is trivially proven true.

If the domain of inputs to Turing Machines does not include being able
to ask them about the behavior of other Turing Machines applied to
inputs, then no Turing Machine can correctly answer about the Halting
Property of a Turing machine applied to an Input.

Sorry, that claim doesn't hold water, and just shows your ignorance of
the topic.

FAIL.

On Tuesday, June 7, 2022 at 9:17:12 PM UTC+10, Richard Damon wrote:
> On 6/6/22 11:49 PM, olcott wrote:
> > On 6/6/2022 1:36 PM, Ben wrote:
> >> wij <wyni...@gmail.com> writes:
> >>
> >>> Students of average level understand Halting decider cannot exist, as
> >>> olcott
> >>> has demonstrated for years (no 'correct' H exists).
> >>>
> >>> If H does not exist, what dose "H(P,P)==0" mean?
> >>
> >> H as specified in, say, Linz does not exist. But PO's H does and so P
> >> (which should really be called something like H_Hat) also exists.
> >> That's why H is wrong about the "halting" of P(P).
> >>
> >> Another way to write the proof is to show that every Turing machine gets
> >> at least one instance wrong -- i.e. that no TM computes the halting
> >> function. PO's H is just an example of that, and he even tells us that
> >> it gets the instance representing P(P) wrong.
> >>
> >
> > Since you know that
> >
> > (1) Deciders in computer science compute the mapping from their inputs
> > to an accept or reject state.
> >
> > (2) P(P) is not an input to H
> >
> > Why do you persist in the deception that H must compute the halt status
> > of P(P) ?
> >
> But P(P) IS an input to H via its representation being given to H.
>
> If you want to say that you can't actually give a computation to a
> Turing Machine then the Halting Theorem is trivially proven true.
>
> If the domain of inputs to Turing Machines does not include being able
> to ask them about the behavior of other Turing Machines applied to
> inputs, then no Turing Machine can correctly answer about the Halting
> Property of a Turing machine applied to an Input.
>
> Sorry, that claim doesn't hold water, and just shows your ignorance of
> the topic.
>
> FAIL.

PO is RIGHT! The halting proof has a WRONG CONCLUSION that halt(p i) is an impossible function to program.

HALT( p , p ) --> "peeks at halt(p,p) and does the opposite"

or merely

HALT( p , p ) --> unknown

Sure it aint perfect ,and Chaitans Omega is UNCOMPUTABLE but halt is possibly programmable.

IN FACT, CHAITANS OMEGA is specifiable by a turing machine with ? non-halting values
making UNKNOWN DIGIT REALS COMPUTABLY COMPLETE

On 6/7/2022 6:30 AM, Malcolm McLean wrote:
> On Tuesday, 7 June 2022 at 12:17:05 UTC+1, richar...@gmail.com wrote:
>> On 6/6/22 11:49 PM, olcott wrote:
>>> On 6/6/2022 1:36 PM, Ben wrote:
>>>> wij <wyni...@gmail.com> writes:
>>>>
>>>>> Students of average level understand Halting decider cannot exist, as
>>>>> olcott
>>>>> has demonstrated for years (no 'correct' H exists).
>>>>>
>>>>> If H does not exist, what dose "H(P,P)==0" mean?
>>>>
>>>> H as specified in, say, Linz does not exist. But PO's H does and so P
>>>> (which should really be called something like H_Hat) also exists.
>>>> That's why H is wrong about the "halting" of P(P).
>>>>
>>>> Another way to write the proof is to show that every Turing machine gets
>>>> at least one instance wrong -- i.e. that no TM computes the halting
>>>> function. PO's H is just an example of that, and he even tells us that
>>>> it gets the instance representing P(P) wrong.
>>>>
>>>
>>> Since you know that
>>>
>>> (1) Deciders in computer science compute the mapping from their inputs
>>> to an accept or reject state.
>>>
>>> (2) P(P) is not an input to H
>>>
>>> Why do you persist in the deception that H must compute the halt status
>>> of P(P) ?
>>>
>> But P(P) IS an input to H via its representation being given to H.
>>
>> If you want to say that you can't actually give a computation to a
>> Turing Machine then the Halting Theorem is trivially proven true.
>>
> x86 is von Neumann architecture. So stored programs can be manipulated
> as data. In PO's system, H is passed a pointer to the actual machine code of
> P. PO is trying to draw a distinction between P when it is called, and P
> when it is passed to H. I think Ben might have been a bit over-pedantic
> with him and he might have misunderstood what Ben was saying.
>
> WIth Turing machines, you can't pass an actual machine. You can only
> provide a description of a machine, on the tape. A Turing machine has
> no access to its own states, and it cannot examine another Turing machine.
> This isn't true of x86 programs.
> The distinction shouldn't be important, but there seems to be some confusion
> somewhere.

A simulating halt decider based on an x86 emulator or a UTM is the same
idea and fundamentally works the same way.

It is the case that P(P) is not and cannot be an input to H(P,P) because
the input to H(P,P) has a pathological self-reference relationship to H
and P(P) has no such relationship.

The correct and complete simulation of the input to HP(P,P) is stuck in
infinitely nested simulation and P(P) halts.

--
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 Wednesday, June 8, 2022 at 12:20:21 AM UTC+10, olcott wrote:
> On 6/7/2022 6:30 AM, Malcolm McLean wrote:
> > On Tuesday, 7 June 2022 at 12:17:05 UTC+1, richar...@gmail.com wrote:
> >> On 6/6/22 11:49 PM, olcott wrote:
> >>> On 6/6/2022 1:36 PM, Ben wrote:
> >>>> wij <wyni...@gmail.com> writes:
> >>>>
> >>>>> Students of average level understand Halting decider cannot exist, as
> >>>>> olcott
> >>>>> has demonstrated for years (no 'correct' H exists).
> >>>>>
> >>>>> If H does not exist, what dose "H(P,P)==0" mean?
> >>>>
> >>>> H as specified in, say, Linz does not exist. But PO's H does and so P
> >>>> (which should really be called something like H_Hat) also exists.
> >>>> That's why H is wrong about the "halting" of P(P).
> >>>>
> >>>> Another way to write the proof is to show that every Turing machine gets
> >>>> at least one instance wrong -- i.e. that no TM computes the halting
> >>>> function. PO's H is just an example of that, and he even tells us that
> >>>> it gets the instance representing P(P) wrong.
> >>>>
> >>>
> >>> Since you know that
> >>>
> >>> (1) Deciders in computer science compute the mapping from their inputs
> >>> to an accept or reject state.
> >>>
> >>> (2) P(P) is not an input to H
> >>>
> >>> Why do you persist in the deception that H must compute the halt status
> >>> of P(P) ?
> >>>
> >> But P(P) IS an input to H via its representation being given to H.
> >>
> >> If you want to say that you can't actually give a computation to a
> >> Turing Machine then the Halting Theorem is trivially proven true.
> >>
> > x86 is von Neumann architecture. So stored programs can be manipulated
> > as data. In PO's system, H is passed a pointer to the actual machine code of
> > P. PO is trying to draw a distinction between P when it is called, and P
> > when it is passed to H. I think Ben might have been a bit over-pedantic
> > with him and he might have misunderstood what Ben was saying.
> >
> > WIth Turing machines, you can't pass an actual machine. You can only
> > provide a description of a machine, on the tape. A Turing machine has
> > no access to its own states, and it cannot examine another Turing machine.
> > This isn't true of x86 programs.
> > The distinction shouldn't be important, but there seems to be some confusion
> > somewhere.
>
> A simulating halt decider based on an x86 emulator or a UTM is the same
> idea and fundamentally works the same way.
>
> It is the case that P(P) is not and cannot be an input to H(P,P) because
> the input to H(P,P) has a pathological self-reference relationship to H
> and P(P) has no such relationship.
>
> The correct and complete simulation of the input to HP(P,P) is stuck in
> infinitely nested simulation and P(P) halts.

Right!

function p ( x )
if halt( x x ) then p (x )

p( p )
if halt( p p ) then p ( p )

halt( p p ) ---> "P IS A LOAD OF SHIT"

HALT GETS ITS RIGHT!

So what does halt prove? if halt is a real program then p is a real program
which reads halt(p, _ ) and does the opposite. so SMART HALT has 3 outputs
and says P(P) invalidates itself, but p(p) is a real program that halts or not so
halt is incomplete.

WRONG CONCLUSION 100 YEARS - HALT IS NOT PROGRAMMABLE

RIGHT CONCLUSION - HALT HAS SOME MISSING VALUES

On 6/7/2022 7:12 AM, Graham Cooper wrote:
> On Tuesday, June 7, 2022 at 9:17:12 PM UTC+10, Richard Damon wrote:
>> On 6/6/22 11:49 PM, olcott wrote:
>>> On 6/6/2022 1:36 PM, Ben wrote:
>>>> wij <wyni...@gmail.com> writes:
>>>>
>>>>> Students of average level understand Halting decider cannot exist, as
>>>>> olcott
>>>>> has demonstrated for years (no 'correct' H exists).
>>>>>
>>>>> If H does not exist, what dose "H(P,P)==0" mean?
>>>>
>>>> H as specified in, say, Linz does not exist. But PO's H does and so P
>>>> (which should really be called something like H_Hat) also exists.
>>>> That's why H is wrong about the "halting" of P(P).
>>>>
>>>> Another way to write the proof is to show that every Turing machine gets
>>>> at least one instance wrong -- i.e. that no TM computes the halting
>>>> function. PO's H is just an example of that, and he even tells us that
>>>> it gets the instance representing P(P) wrong.
>>>>
>>>
>>> Since you know that
>>>
>>> (1) Deciders in computer science compute the mapping from their inputs
>>> to an accept or reject state.
>>>
>>> (2) P(P) is not an input to H
>>>
>>> Why do you persist in the deception that H must compute the halt status
>>> of P(P) ?
>>>
>> But P(P) IS an input to H via its representation being given to H.
>>
>> If you want to say that you can't actually give a computation to a
>> Turing Machine then the Halting Theorem is trivially proven true.
>>
>> If the domain of inputs to Turing Machines does not include being able
>> to ask them about the behavior of other Turing Machines applied to
>> inputs, then no Turing Machine can correctly answer about the Halting
>> Property of a Turing machine applied to an Input.
>>
>> Sorry, that claim doesn't hold water, and just shows your ignorance of
>> the topic.
>>
>> FAIL.
>
> PO is RIGHT! The halting proof has a WRONG CONCLUSION that halt(p i) is an impossible function to program.
>
> HALT( p , p ) --> "peeks at halt(p,p) and does the opposite"
>
>
> or merely
>
> HALT( p , p ) --> unknown
>
>
>
> Sure it aint perfect ,and Chaitans Omega is UNCOMPUTABLE but halt is possibly programmable.
>
> IN FACT, CHAITANS OMEGA is specifiable by a turing machine with ? non-halting values
> making UNKNOWN DIGIT REALS COMPUTABLY COMPLETE
>
Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

--
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 6/7/2022 10:07 AM, Graham Cooper wrote:
> On Wednesday, June 8, 2022 at 12:20:21 AM UTC+10, olcott wrote:
>> On 6/7/2022 6:30 AM, Malcolm McLean wrote:
>>> On Tuesday, 7 June 2022 at 12:17:05 UTC+1, richar...@gmail.com wrote:
>>>> On 6/6/22 11:49 PM, olcott wrote:
>>>>> On 6/6/2022 1:36 PM, Ben wrote:
>>>>>> wij <wyni...@gmail.com> writes:
>>>>>>
>>>>>>> Students of average level understand Halting decider cannot exist, as
>>>>>>> olcott
>>>>>>> has demonstrated for years (no 'correct' H exists).
>>>>>>>
>>>>>>> If H does not exist, what dose "H(P,P)==0" mean?
>>>>>>
>>>>>> H as specified in, say, Linz does not exist. But PO's H does and so P
>>>>>> (which should really be called something like H_Hat) also exists.
>>>>>> That's why H is wrong about the "halting" of P(P).
>>>>>>
>>>>>> Another way to write the proof is to show that every Turing machine gets
>>>>>> at least one instance wrong -- i.e. that no TM computes the halting
>>>>>> function. PO's H is just an example of that, and he even tells us that
>>>>>> it gets the instance representing P(P) wrong.
>>>>>>
>>>>>
>>>>> Since you know that
>>>>>
>>>>> (1) Deciders in computer science compute the mapping from their inputs
>>>>> to an accept or reject state.
>>>>>
>>>>> (2) P(P) is not an input to H
>>>>>
>>>>> Why do you persist in the deception that H must compute the halt status
>>>>> of P(P) ?
>>>>>
>>>> But P(P) IS an input to H via its representation being given to H.
>>>>
>>>> If you want to say that you can't actually give a computation to a
>>>> Turing Machine then the Halting Theorem is trivially proven true.
>>>>
>>> x86 is von Neumann architecture. So stored programs can be manipulated
>>> as data. In PO's system, H is passed a pointer to the actual machine code of
>>> P. PO is trying to draw a distinction between P when it is called, and P
>>> when it is passed to H. I think Ben might have been a bit over-pedantic
>>> with him and he might have misunderstood what Ben was saying.
>>>
>>> WIth Turing machines, you can't pass an actual machine. You can only
>>> provide a description of a machine, on the tape. A Turing machine has
>>> no access to its own states, and it cannot examine another Turing machine.
>>> This isn't true of x86 programs.
>>> The distinction shouldn't be important, but there seems to be some confusion
>>> somewhere.
>>
>> A simulating halt decider based on an x86 emulator or a UTM is the same
>> idea and fundamentally works the same way.
>>
>> It is the case that P(P) is not and cannot be an input to H(P,P) because
>> the input to H(P,P) has a pathological self-reference relationship to H
>> and P(P) has no such relationship.
>>
>> The correct and complete simulation of the input to HP(P,P) is stuck in
>> infinitely nested simulation and P(P) halts.
>
>
> Right!
>
> function p ( x )
> if halt( x x ) then p (x )
>
>
> p( p )
> if halt( p p ) then p ( p )
>
>
> halt( p p ) ---> "P IS A LOAD OF SHIT"
>
>
> HALT GETS ITS RIGHT!
>
>
>
> So what does halt prove? if halt is a real program then p is a real program
> which reads halt(p, _ ) and does the opposite.

The brand new idea that I derived since 2016 is that when we apply a
simulating halt decider to the conventional HP "impossible" input this
input never reaches the contradictory part because it is stuck in
infinitely nested simulation. This provides the basis for H to simply
correctly reject its input as non-halting.

H and P are fully encoded and run in the x86utm operating system.

Please see my paper for the details:
Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

> so SMART HALT has 3 outputs
> and says P(P) invalidates itself, but p(p) is a real program that halts or not so
> halt is incomplete.
>
> WRONG CONCLUSION 100 YEARS - HALT IS NOT PROGRAMMABLE
>
> RIGHT CONCLUSION - HALT HAS SOME MISSING VALUES

--
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 6/7/22 10:20 AM, olcott wrote:
> On 6/7/2022 6:30 AM, Malcolm McLean wrote:
>> On Tuesday, 7 June 2022 at 12:17:05 UTC+1, richar...@gmail.com wrote:
>>> On 6/6/22 11:49 PM, olcott wrote:
>>>> On 6/6/2022 1:36 PM, Ben wrote:
>>>>> wij <wyni...@gmail.com> writes:
>>>>>
>>>>>> Students of average level understand Halting decider cannot exist, as
>>>>>> olcott
>>>>>> has demonstrated for years (no 'correct' H exists).
>>>>>>
>>>>>> If H does not exist, what dose "H(P,P)==0" mean?
>>>>>
>>>>> H as specified in, say, Linz does not exist.  But PO's H does and so P
>>>>> (which should really be called something like H_Hat) also exists.
>>>>> That's why H is wrong about the "halting" of P(P).
>>>>>
>>>>> Another way to write the proof is to show that every Turing machine
>>>>> gets
>>>>> at least one instance wrong -- i.e. that no TM computes the halting
>>>>> function.  PO's H is just an example of that, and he even tells us
>>>>> that
>>>>> it gets the instance representing P(P) wrong.
>>>>>
>>>>
>>>> Since you know that
>>>>
>>>> (1) Deciders in computer science compute the mapping from their inputs
>>>> to an accept or reject state.
>>>>
>>>> (2) P(P) is not an input to H
>>>>
>>>> Why do you persist in the deception that H must compute the halt status
>>>> of P(P) ?
>>>>
>>> But P(P) IS an input to H via its representation being given to H.
>>>
>>> If you want to say that you can't actually give a computation to a
>>> Turing Machine then the Halting Theorem is trivially proven true.
>>>
>> x86 is von Neumann architecture. So stored programs can be manipulated
>> as data. In PO's system, H is passed a pointer to the actual machine
>> code of
>> P.  PO is trying to draw a distinction between P when it is called, and P
>> when it is passed to H. I think Ben might have been a bit over-pedantic
>> with him and he might have misunderstood what Ben was saying.
>>
>> WIth Turing machines, you can't pass an actual machine. You can only
>> provide a description of  a machine, on the tape. A Turing machine has
>> no access to its own states, and it cannot examine another Turing
>> machine.
>> This isn't true of x86 programs.
>> The distinction shouldn't be important, but there seems to be some
>> confusion
>> somewhere.
>
> A simulating halt decider based on an x86 emulator or a UTM is the same
> idea and fundamentally works the same way.
>
> It is the case that P(P) is not and cannot be an input to H(P,P) because
> the input to H(P,P) has a pathological self-reference relationship to H
> and P(P) has no such relationship.

Maybe in your construction of H/P you have created an actual
self-reference BECAUSE You have built H and P incorrectly.

In the ACTUAL H / H^ case, there is NO SELF-reference because nothing is
built to actually refer to itself.

H is a decider that can take in a description of any machine and an input

H^ is a machine that can take in a description of any machine.

NONE of this code EVER actually refers to itself.

When we build the input, the representation of H^, that doesn't ACTUALLY
"refer" to H^, but is just a description of it. There is NOTHING in that
input that tells H^ or H that this input "refers" to either of those.

So, the fact that you claim that H(P,P) has a "pathological
self-reference" says that you must have built something wrong, and the
obvious part of that is that you didn't build P with the COPY of H as
required, and in fact P calling the H that is deciding it actually makes
the problem DIFFERENT than the pattern described, and breaks the rules
of forming computations, you no longer have two distinct machines and an
input, the H deciding, the P whose representation is being decided on
and the copy of the representaiton of P that is the input to the P.

THAT makes the "self-reference" and makes your setup incorrect.

The fact that you can't see this just shows the level of your understand
of even the basics of Computer Science.

>
> The correct and complete simulation of the input to HP(P,P) is stuck in
> infinitely nested simulation and P(P) halts.
>

Only if H(P,P) never aborts, and if it never aborts it never answers and
thus is wrong.

ALL H(P,P) need to behave the same, so somewhere you are lying when you
say that H(P,P) actually returns a 0 and also creates an infinitely
nested simulation.