On 3/15/22 3:44 PM, olcott wrote:
> On 3/15/2022 1:58 PM, Jeff Barnett wrote:
>> On 3/15/2022 10:11 AM, olcott wrote:
>>> On 3/15/2022 10:44 AM, Malcolm McLean wrote:
>>
>>     <MAJOR SNIP>
>>
>>>> So how would you describe a compiler which is "bootstrapped", i.e.
>>>> fed its own
>>>> source code?
>>>
>>> A compiler that is fed its own source-code is not the same because
>>> the compiler does not execute this source-code.
>> This is one of your best Peter. Along the way you've had 100s of
>> messages that have said that simulation as a basis for a Halting
>> Problem solution is hopeless. Of course you pay no attention because
>> it's unlikely you understood what you were being told. So here you are
>> looping back over years of the same bone headed approach.
>>
>> Let's start with a few basics:
>>
>> Nothing executes source code; even an interpreter ingests it first.
>>
>
> A compiler the compiles its own source-code is nothing at all like
> executing this source code.
>
> An interpreter that interprets source code can be reasonably construed
> as running this source code.
>
> When a BASIC programmer says that they ran their program they do not
> provide all of the tedious details of the technical intermediate steps.
>

And it is posssible to write a BASIC interpreter in BASIC and run it in
itself.

It isn't actually a good model of the problem, as you need some other
BASIC interpreter at the bottom to get things going, but the H/H^ loop
can be started at either point, and we can PROVE that what ever answer
(if any) that the H applied to <H^> <H^> part of the loop gives will
disagree with the behavior of the H^ applied to <H^> part, and thus H
fails to be the needed Halt Decider.

On 3/15/22 10:51 AM, olcott wrote:
> On 3/15/2022 6:35 AM, Malcolm McLean wrote:
>> On Tuesday, 15 March 2022 at 04:04:06 UTC, André G. Isaak wrote:
>>> On 2022-03-14 21:07, olcott wrote:
>>>> On 3/14/2022 9:05 PM, André G. Isaak wrote:
>>>>> On 2022-03-14 20:02, olcott wrote:
>>>>>
>>>>> <snip nonresponsive post>
>>>>>
>>>>> Again, I'll repeat the question which you dishonestly snipped rather
>>>>> than answering. I won't bother putting it in all caps or repeating it
>>>>> five times.
>>>>>
>>>>> How does one encode Ĥ applied to ⟨Ĥ⟩ as a string which can be passed
>>>>> to Ĥ if that computation is in fact different from ⟨Ĥ⟩ ⟨Ĥ⟩?
>>>>>
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> The ⟨Ĥ⟩ ⟨Ĥ⟩ above is inherently exactly one level of indirect reference
>>>> away from Ĥ ⟨Ĥ⟩ above, thus making it utterly impossible to pass this
>>>> exact same Ĥ ⟨Ĥ⟩ as an input to embedded_H.
>>> There are no 'levels of indirection' when discussing Turing Machines.
>>>
>>> If there is no way to encode Ĥ ⟨Ĥ⟩ such that it can be given as an input
>>> to your decider, then your decider is broken since it must be able to
>>> provide an answer for *every* computation, including Ĥ ⟨Ĥ⟩.
>>>
>> Though that would actually be a genuine contribution to computer science.
>> If you could devise a language such that a large subset of halting and
>> non-halting machines could be described, but not machines for which the
>> halting status is difficult or impossible for a predefined halt
>> decider to determine.
>
> André does not seem to be able to comprehend that a Turing machine
> decider cannot possibly have its own self or an encoding of its own self
> as its input. The closest thing possible that it can have is an encoding
> of another different instance of itself.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> In the case above ⟨Ĥ⟩ ⟨Ĥ⟩ is exactly one level of indirect reference
> away from Ĥ applied to ⟨Ĥ⟩. The copy of H embedded at Ĥ.qx is not
> deciding the halt status of its own self (the exact same instance) it is
> deciding the halt status of a different instance.
>
> That neither André, Ben nor Richard can comprehend this does not
> indicate that I am incorrect.
>

And you don't understand that ALL instances of the same computation
behave exactly the same.

If you can prove otherwise with an ACTUAL EXAMPLE (not just hand waving
words, actually encoded Turing Machine and input) then you can make
yourself famous.

The fact that you fail to provide this example is just proof that you
don't actually have a proof of this Fairy Dust Powered Unicorn existing,
but are just assuming it can be done out of ignorance of the Truth.

On 3/15/2022 8:47 PM, Richard Damon wrote:
> On 3/15/22 9:15 PM, olcott wrote:
>> On 3/15/2022 3:24 PM, André G. Isaak wrote:
>>> On 2022-03-15 08:51, olcott wrote:
>>>> On 3/15/2022 6:35 AM, Malcolm McLean wrote:
>>>>> On Tuesday, 15 March 2022 at 04:04:06 UTC, André G. Isaak wrote:
>>>>>> On 2022-03-14 21:07, olcott wrote:
>>>>>>> On 3/14/2022 9:05 PM, André G. Isaak wrote:
>>>>>>>> On 2022-03-14 20:02, olcott wrote:
>>>>>>>>
>>>>>>>> <snip nonresponsive post>
>>>>>>>>
>>>>>>>> Again, I'll repeat the question which you dishonestly snipped
>>>>>>>> rather
>>>>>>>> than answering. I won't bother putting it in all caps or
>>>>>>>> repeating it
>>>>>>>> five times.
>>>>>>>>
>>>>>>>> How does one encode Ĥ applied to ⟨Ĥ⟩ as a string which can be
>>>>>>>> passed
>>>>>>>> to Ĥ if that computation is in fact different from ⟨Ĥ⟩ ⟨Ĥ⟩?
>>>>>>>>
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>
>>>>>>> The ⟨Ĥ⟩ ⟨Ĥ⟩ above is inherently exactly one level of indirect
>>>>>>> reference
>>>>>>> away from Ĥ ⟨Ĥ⟩ above, thus making it utterly impossible to pass
>>>>>>> this
>>>>>>> exact same Ĥ ⟨Ĥ⟩ as an input to embedded_H.
>>>>>> There are no 'levels of indirection' when discussing Turing Machines.
>>>>>>
>>>>>> If there is no way to encode Ĥ ⟨Ĥ⟩ such that it can be given as an
>>>>>> input
>>>>>> to your decider, then your decider is broken since it must be able to
>>>>>> provide an answer for *every* computation, including Ĥ ⟨Ĥ⟩.
>>>>>>
>>>>> Though that would actually be a genuine contribution to computer
>>>>> science.
>>>>> If you could devise a language such that a large subset of halting and
>>>>> non-halting machines could be described, but not machines for which
>>>>> the
>>>>> halting status is difficult or impossible for a predefined halt
>>>>> decider to determine.
>>>>
>>>> André does not seem to be able to comprehend that a Turing machine
>>>> decider cannot possibly have its own self or an encoding of its own
>>>> self as its input. The closest thing possible that it can have is an
>>>> encoding of another different instance of itself.
>>>
>>> Computations don't have different instances. What would it even mean
>>> to 'instantiate' a computation?
>>>
>>> André
>>>
>>
>> Back to the key point:
>>
>> That ⟨Ĥ⟩ ⟨Ĥ⟩ finite strings specify non-halting behavior when
>> correctly simulated by the UTM within embedded_H is the same as these
>> finite strings specifying non-halting behavior when correctly
>> interpreted by a BASIC in interpreter.
>>
>> 10 PRINT "Hello, World!"
>> 20 goto 10
>> 30 END
>>
>> When Ĥ is applied to ⟨Ĥ⟩
>>    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>
>> Then these steps would keep repeating:
>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>>    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩
>> ⟨Ĥ5⟩...
>>
>> The above repeating pattern shows that the correctly simulated input
>> to embedded_H would never reach its final state of ⟨Ĥ⟩.qn conclusively
>> proving that this simulated input never halts. This enables embedded_H
>> to abort its simulation and correctly transition to Ĥ.qn.
>>
>>
>
> But that infinite behavor only occurs if the embedded_H NEVER aborts its
> simulation and thus it fails at the requirement to GIVE the answer.
>

correctly simulated input to embedded_H would never reach its final
state of ⟨Ĥ⟩.qn

correctly simulated input to embedded_H would never reach its final
state of ⟨Ĥ⟩.qn

correctly simulated input to embedded_H would never reach its final
state of ⟨Ĥ⟩.qn

correctly simulated input to embedded_H would never reach its final
state of ⟨Ĥ⟩.qn

--
Copyright 2021 Pete Olcott

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

On 3/15/22 10:29 PM, olcott wrote:
> On 3/15/2022 8:47 PM, Richard Damon wrote:
>> On 3/15/22 9:15 PM, olcott wrote:
>>> On 3/15/2022 3:24 PM, André G. Isaak wrote:
>>>> On 2022-03-15 08:51, olcott wrote:
>>>>> On 3/15/2022 6:35 AM, Malcolm McLean wrote:
>>>>>> On Tuesday, 15 March 2022 at 04:04:06 UTC, André G. Isaak wrote:
>>>>>>> On 2022-03-14 21:07, olcott wrote:
>>>>>>>> On 3/14/2022 9:05 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-03-14 20:02, olcott wrote:
>>>>>>>>>
>>>>>>>>> <snip nonresponsive post>
>>>>>>>>>
>>>>>>>>> Again, I'll repeat the question which you dishonestly snipped
>>>>>>>>> rather
>>>>>>>>> than answering. I won't bother putting it in all caps or
>>>>>>>>> repeating it
>>>>>>>>> five times.
>>>>>>>>>
>>>>>>>>> How does one encode Ĥ applied to ⟨Ĥ⟩ as a string which can be
>>>>>>>>> passed
>>>>>>>>> to Ĥ if that computation is in fact different from ⟨Ĥ⟩ ⟨Ĥ⟩?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>
>>>>>>>> The ⟨Ĥ⟩ ⟨Ĥ⟩ above is inherently exactly one level of indirect
>>>>>>>> reference
>>>>>>>> away from Ĥ ⟨Ĥ⟩ above, thus making it utterly impossible to pass
>>>>>>>> this
>>>>>>>> exact same Ĥ ⟨Ĥ⟩ as an input to embedded_H.
>>>>>>> There are no 'levels of indirection' when discussing Turing
>>>>>>> Machines.
>>>>>>>
>>>>>>> If there is no way to encode Ĥ ⟨Ĥ⟩ such that it can be given as
>>>>>>> an input
>>>>>>> to your decider, then your decider is broken since it must be
>>>>>>> able to
>>>>>>> provide an answer for *every* computation, including Ĥ ⟨Ĥ⟩.
>>>>>>>
>>>>>> Though that would actually be a genuine contribution to computer
>>>>>> science.
>>>>>> If you could devise a language such that a large subset of halting
>>>>>> and
>>>>>> non-halting machines could be described, but not machines for
>>>>>> which the
>>>>>> halting status is difficult or impossible for a predefined halt
>>>>>> decider to determine.
>>>>>
>>>>> André does not seem to be able to comprehend that a Turing machine
>>>>> decider cannot possibly have its own self or an encoding of its own
>>>>> self as its input. The closest thing possible that it can have is
>>>>> an encoding of another different instance of itself.
>>>>
>>>> Computations don't have different instances. What would it even mean
>>>> to 'instantiate' a computation?
>>>>
>>>> André
>>>>
>>>
>>> Back to the key point:
>>>
>>> That ⟨Ĥ⟩ ⟨Ĥ⟩ finite strings specify non-halting behavior when
>>> correctly simulated by the UTM within embedded_H is the same as these
>>> finite strings specifying non-halting behavior when correctly
>>> interpreted by a BASIC in interpreter.
>>>
>>> 10 PRINT "Hello, World!"
>>> 20 goto 10
>>> 30 END
>>>
>>> When Ĥ is applied to ⟨Ĥ⟩
>>>    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>
>>> Then these steps would keep repeating:
>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>>>    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩
>>> ⟨Ĥ5⟩...
>>>
>>> The above repeating pattern shows that the correctly simulated input
>>> to embedded_H would never reach its final state of ⟨Ĥ⟩.qn
>>> conclusively proving that this simulated input never halts. This
>>> enables embedded_H to abort its simulation and correctly transition
>>> to Ĥ.qn.
>>>
>>>
>>
>> But that infinite behavor only occurs if the embedded_H NEVER aborts
>> its simulation and thus it fails at the requirement to GIVE the answer.
>>
>
> correctly simulated input to embedded_H would never reach its final
> state of ⟨Ĥ⟩.qn
>
> correctly simulated input to embedded_H would never reach its final
> state of ⟨Ĥ⟩.qn
>
> correctly simulated input to embedded_H would never reach its final
> state of ⟨Ĥ⟩.qn
>
> correctly simulated input to embedded_H would never reach its final
> state of ⟨Ĥ⟩.qn
>
>

Which only happens if embedded_H never aborts its simulation, and thus
fails to give the 'right' answer, but maybe dies with the truth, so it
is still WRONG.

Remember, H^ has a copy of embedded_H, so it KNOWS what embedded_H is
going to do, so can act in a contrary manner. If any copy of embedded_H
aborts its simulation and goes to H.Qn, then EVERY copy of it does it
also, so EVERY copy of H^ sees that behavior and Halts.

In particular, the outermost H^ does this, so it PROVES that it is a
Halting Computation, and H was WRONG.

On 3/15/2022 9:38 PM, Richard Damon wrote:
> On 3/15/22 10:29 PM, olcott wrote:
>> On 3/15/2022 8:47 PM, Richard Damon wrote:
>>> On 3/15/22 9:15 PM, olcott wrote:
>>>> On 3/15/2022 3:24 PM, André G. Isaak wrote:
>>>>> On 2022-03-15 08:51, olcott wrote:
>>>>>> On 3/15/2022 6:35 AM, Malcolm McLean wrote:
>>>>>>> On Tuesday, 15 March 2022 at 04:04:06 UTC, André G. Isaak wrote:
>>>>>>>> On 2022-03-14 21:07, olcott wrote:
>>>>>>>>> On 3/14/2022 9:05 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-03-14 20:02, olcott wrote:
>>>>>>>>>>
>>>>>>>>>> <snip nonresponsive post>
>>>>>>>>>>
>>>>>>>>>> Again, I'll repeat the question which you dishonestly snipped
>>>>>>>>>> rather
>>>>>>>>>> than answering. I won't bother putting it in all caps or
>>>>>>>>>> repeating it
>>>>>>>>>> five times.
>>>>>>>>>>
>>>>>>>>>> How does one encode Ĥ applied to ⟨Ĥ⟩ as a string which can be
>>>>>>>>>> passed
>>>>>>>>>> to Ĥ if that computation is in fact different from ⟨Ĥ⟩ ⟨Ĥ⟩?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>
>>>>>>>>> The ⟨Ĥ⟩ ⟨Ĥ⟩ above is inherently exactly one level of indirect
>>>>>>>>> reference
>>>>>>>>> away from Ĥ ⟨Ĥ⟩ above, thus making it utterly impossible to
>>>>>>>>> pass this
>>>>>>>>> exact same Ĥ ⟨Ĥ⟩ as an input to embedded_H.
>>>>>>>> There are no 'levels of indirection' when discussing Turing
>>>>>>>> Machines.
>>>>>>>>
>>>>>>>> If there is no way to encode Ĥ ⟨Ĥ⟩ such that it can be given as
>>>>>>>> an input
>>>>>>>> to your decider, then your decider is broken since it must be
>>>>>>>> able to
>>>>>>>> provide an answer for *every* computation, including Ĥ ⟨Ĥ⟩.
>>>>>>>>
>>>>>>> Though that would actually be a genuine contribution to computer
>>>>>>> science.
>>>>>>> If you could devise a language such that a large subset of
>>>>>>> halting and
>>>>>>> non-halting machines could be described, but not machines for
>>>>>>> which the
>>>>>>> halting status is difficult or impossible for a predefined halt
>>>>>>> decider to determine.
>>>>>>
>>>>>> André does not seem to be able to comprehend that a Turing machine
>>>>>> decider cannot possibly have its own self or an encoding of its
>>>>>> own self as its input. The closest thing possible that it can have
>>>>>> is an encoding of another different instance of itself.
>>>>>
>>>>> Computations don't have different instances. What would it even
>>>>> mean to 'instantiate' a computation?
>>>>>
>>>>> André
>>>>>
>>>>
>>>> Back to the key point:
>>>>
>>>> That ⟨Ĥ⟩ ⟨Ĥ⟩ finite strings specify non-halting behavior when
>>>> correctly simulated by the UTM within embedded_H is the same as
>>>> these finite strings specifying non-halting behavior when correctly
>>>> interpreted by a BASIC in interpreter.
>>>>
>>>> 10 PRINT "Hello, World!"
>>>> 20 goto 10
>>>> 30 END
>>>>
>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>
>>>> Then these steps would keep repeating:
>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>>>>    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩
>>>> ⟨Ĥ5⟩...
>>>>
>>>> The above repeating pattern shows that the correctly simulated input
>>>> to embedded_H would never reach its final state of ⟨Ĥ⟩.qn
>>>> conclusively proving that this simulated input never halts. This
>>>> enables embedded_H to abort its simulation and correctly transition
>>>> to Ĥ.qn.
>>>>
>>>>
>>>
>>> But that infinite behavor only occurs if the embedded_H NEVER aborts
>>> its simulation and thus it fails at the requirement to GIVE the answer.
>>>
>>
>> correctly simulated input to embedded_H would never reach its final
>> state of ⟨Ĥ⟩.qn
>>
>> correctly simulated input to embedded_H would never reach its final
>> state of ⟨Ĥ⟩.qn
>>
>> correctly simulated input to embedded_H would never reach its final
>> state of ⟨Ĥ⟩.qn
>>
>> correctly simulated input to embedded_H would never reach its final
>> state of ⟨Ĥ⟩.qn
>>
>>
>
> Which only happens if embedded_H never aborts its simulation,
No idiot it happens no matter what !
No idiot it happens no matter what !
No idiot it happens no matter what !
No idiot it happens no matter what !
No idiot it happens no matter what !

--
Copyright 2021 Pete Olcott

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

On 3/15/22 10:43 PM, olcott wrote:
> On 3/15/2022 9:38 PM, Richard Damon wrote:
>> On 3/15/22 10:29 PM, olcott wrote:
>>> On 3/15/2022 8:47 PM, Richard Damon wrote:
>>>> On 3/15/22 9:15 PM, olcott wrote:
>>>>> On 3/15/2022 3:24 PM, André G. Isaak wrote:
>>>>>> On 2022-03-15 08:51, olcott wrote:
>>>>>>> On 3/15/2022 6:35 AM, Malcolm McLean wrote:
>>>>>>>> On Tuesday, 15 March 2022 at 04:04:06 UTC, André G. Isaak wrote:
>>>>>>>>> On 2022-03-14 21:07, olcott wrote:
>>>>>>>>>> On 3/14/2022 9:05 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2022-03-14 20:02, olcott wrote:
>>>>>>>>>>>
>>>>>>>>>>> <snip nonresponsive post>
>>>>>>>>>>>
>>>>>>>>>>> Again, I'll repeat the question which you dishonestly snipped
>>>>>>>>>>> rather
>>>>>>>>>>> than answering. I won't bother putting it in all caps or
>>>>>>>>>>> repeating it
>>>>>>>>>>> five times.
>>>>>>>>>>>
>>>>>>>>>>> How does one encode Ĥ applied to ⟨Ĥ⟩ as a string which can be
>>>>>>>>>>> passed
>>>>>>>>>>> to Ĥ if that computation is in fact different from ⟨Ĥ⟩ ⟨Ĥ⟩?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>
>>>>>>>>>> The ⟨Ĥ⟩ ⟨Ĥ⟩ above is inherently exactly one level of indirect
>>>>>>>>>> reference
>>>>>>>>>> away from Ĥ ⟨Ĥ⟩ above, thus making it utterly impossible to
>>>>>>>>>> pass this
>>>>>>>>>> exact same Ĥ ⟨Ĥ⟩ as an input to embedded_H.
>>>>>>>>> There are no 'levels of indirection' when discussing Turing
>>>>>>>>> Machines.
>>>>>>>>>
>>>>>>>>> If there is no way to encode Ĥ ⟨Ĥ⟩ such that it can be given as
>>>>>>>>> an input
>>>>>>>>> to your decider, then your decider is broken since it must be
>>>>>>>>> able to
>>>>>>>>> provide an answer for *every* computation, including Ĥ ⟨Ĥ⟩.
>>>>>>>>>
>>>>>>>> Though that would actually be a genuine contribution to computer
>>>>>>>> science.
>>>>>>>> If you could devise a language such that a large subset of
>>>>>>>> halting and
>>>>>>>> non-halting machines could be described, but not machines for
>>>>>>>> which the
>>>>>>>> halting status is difficult or impossible for a predefined halt
>>>>>>>> decider to determine.
>>>>>>>
>>>>>>> André does not seem to be able to comprehend that a Turing
>>>>>>> machine decider cannot possibly have its own self or an encoding
>>>>>>> of its own self as its input. The closest thing possible that it
>>>>>>> can have is an encoding of another different instance of itself.
>>>>>>
>>>>>> Computations don't have different instances. What would it even
>>>>>> mean to 'instantiate' a computation?
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> Back to the key point:
>>>>>
>>>>> That ⟨Ĥ⟩ ⟨Ĥ⟩ finite strings specify non-halting behavior when
>>>>> correctly simulated by the UTM within embedded_H is the same as
>>>>> these finite strings specifying non-halting behavior when correctly
>>>>> interpreted by a BASIC in interpreter.
>>>>>
>>>>> 10 PRINT "Hello, World!"
>>>>> 20 goto 10
>>>>> 30 END
>>>>>
>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>
>>>>> Then these steps would keep repeating:
>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩
>>>>> ⟨Ĥ3⟩
>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩
>>>>> ⟨Ĥ4⟩
>>>>>    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩
>>>>> ⟨Ĥ5⟩...
>>>>>
>>>>> The above repeating pattern shows that the correctly simulated
>>>>> input to embedded_H would never reach its final state of ⟨Ĥ⟩.qn
>>>>> conclusively proving that this simulated input never halts. This
>>>>> enables embedded_H to abort its simulation and correctly transition
>>>>> to Ĥ.qn.
>>>>>
>>>>>
>>>>
>>>> But that infinite behavor only occurs if the embedded_H NEVER aborts
>>>> its simulation and thus it fails at the requirement to GIVE the answer.
>>>>
>>>
>>> correctly simulated input to embedded_H would never reach its final
>>> state of ⟨Ĥ⟩.qn
>>>
>>> correctly simulated input to embedded_H would never reach its final
>>> state of ⟨Ĥ⟩.qn
>>>
>>> correctly simulated input to embedded_H would never reach its final
>>> state of ⟨Ĥ⟩.qn
>>>
>>> correctly simulated input to embedded_H would never reach its final
>>> state of ⟨Ĥ⟩.qn
>>>
>>>
>>
>> Which only happens if embedded_H never aborts its simulation,
> No idiot it happens no matter what !
> No idiot it happens no matter what !
> No idiot it happens no matter what !
> No idiot it happens no matter what !
> No idiot it happens no matter what !
>

Nope, unless you can prove that two copies of the exact same algorithm
given the exact same data can give differerent results (by showing an
ACTUAL example that does it) it is proven otherwise and you are proved
to be just a pathological liar.

If ANY copy of embedded_H applied to <H^> <H^> goes to Qn, then the top
level embedded_H will also go to Qn and the H^ that it is embedded in
goes to H^.Qn and HALT, and NOT infinite pattern occurs.

Just Denying what is proven before your eyes proves that you are either
a pathological liar or delusional and have lost all grasp of the truth.

Please try to show where my proof is wrong.

Show how an H^ built on an embedded_H that aborts its simulation of <H^>
<H^> doesn't halt, or prove that two identical copies of a machine can
behave differently when given identical information. (Since you claim it
happens in this case too)

Failure to do this just proves you are lying.

On 3/15/2022 10:02 PM, Richard Damon wrote:
> On 3/15/22 10:43 PM, olcott wrote:
>> On 3/15/2022 9:38 PM, Richard Damon wrote:
>>> On 3/15/22 10:29 PM, olcott wrote:
>>>> On 3/15/2022 8:47 PM, Richard Damon wrote:
>>>>> On 3/15/22 9:15 PM, olcott wrote:
>>>>>> On 3/15/2022 3:24 PM, André G. Isaak wrote:
>>>>>>> On 2022-03-15 08:51, olcott wrote:
>>>>>>>> On 3/15/2022 6:35 AM, Malcolm McLean wrote:
>>>>>>>>> On Tuesday, 15 March 2022 at 04:04:06 UTC, André G. Isaak wrote:
>>>>>>>>>> On 2022-03-14 21:07, olcott wrote:
>>>>>>>>>>> On 3/14/2022 9:05 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2022-03-14 20:02, olcott wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> <snip nonresponsive post>
>>>>>>>>>>>>
>>>>>>>>>>>> Again, I'll repeat the question which you dishonestly
>>>>>>>>>>>> snipped rather
>>>>>>>>>>>> than answering. I won't bother putting it in all caps or
>>>>>>>>>>>> repeating it
>>>>>>>>>>>> five times.
>>>>>>>>>>>>
>>>>>>>>>>>> How does one encode Ĥ applied to ⟨Ĥ⟩ as a string which can
>>>>>>>>>>>> be passed
>>>>>>>>>>>> to Ĥ if that computation is in fact different from ⟨Ĥ⟩ ⟨Ĥ⟩?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>
>>>>>>>>>>> The ⟨Ĥ⟩ ⟨Ĥ⟩ above is inherently exactly one level of indirect
>>>>>>>>>>> reference
>>>>>>>>>>> away from Ĥ ⟨Ĥ⟩ above, thus making it utterly impossible to
>>>>>>>>>>> pass this
>>>>>>>>>>> exact same Ĥ ⟨Ĥ⟩ as an input to embedded_H.
>>>>>>>>>> There are no 'levels of indirection' when discussing Turing
>>>>>>>>>> Machines.
>>>>>>>>>>
>>>>>>>>>> If there is no way to encode Ĥ ⟨Ĥ⟩ such that it can be given
>>>>>>>>>> as an input
>>>>>>>>>> to your decider, then your decider is broken since it must be
>>>>>>>>>> able to
>>>>>>>>>> provide an answer for *every* computation, including Ĥ ⟨Ĥ⟩.
>>>>>>>>>>
>>>>>>>>> Though that would actually be a genuine contribution to
>>>>>>>>> computer science.
>>>>>>>>> If you could devise a language such that a large subset of
>>>>>>>>> halting and
>>>>>>>>> non-halting machines could be described, but not machines for
>>>>>>>>> which the
>>>>>>>>> halting status is difficult or impossible for a predefined halt
>>>>>>>>> decider to determine.
>>>>>>>>
>>>>>>>> André does not seem to be able to comprehend that a Turing
>>>>>>>> machine decider cannot possibly have its own self or an encoding
>>>>>>>> of its own self as its input. The closest thing possible that it
>>>>>>>> can have is an encoding of another different instance of itself.
>>>>>>>
>>>>>>> Computations don't have different instances. What would it even
>>>>>>> mean to 'instantiate' a computation?
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>
>>>>>> Back to the key point:
>>>>>>
>>>>>> That ⟨Ĥ⟩ ⟨Ĥ⟩ finite strings specify non-halting behavior when
>>>>>> correctly simulated by the UTM within embedded_H is the same as
>>>>>> these finite strings specifying non-halting behavior when
>>>>>> correctly interpreted by a BASIC in interpreter.
>>>>>>
>>>>>> 10 PRINT "Hello, World!"
>>>>>> 20 goto 10
>>>>>> 30 END
>>>>>>
>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩
>>>>>> ⟨Ĥ2⟩
>>>>>>
>>>>>> Then these steps would keep repeating:
>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩
>>>>>> ⟨Ĥ3⟩
>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩
>>>>>> ⟨Ĥ4⟩
>>>>>>    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩
>>>>>> ⟨Ĥ5⟩...
>>>>>>
>>>>>> The above repeating pattern shows that the correctly simulated
>>>>>> input to embedded_H would never reach its final state of ⟨Ĥ⟩.qn
>>>>>> conclusively proving that this simulated input never halts. This
>>>>>> enables embedded_H to abort its simulation and correctly
>>>>>> transition to Ĥ.qn.
>>>>>>
>>>>>>
>>>>>
>>>>> But that infinite behavor only occurs if the embedded_H NEVER
>>>>> aborts its simulation and thus it fails at the requirement to GIVE
>>>>> the answer.
>>>>>
>>>>
>>>> correctly simulated input to embedded_H would never reach its final
>>>> state of ⟨Ĥ⟩.qn
>>>>
>>>> correctly simulated input to embedded_H would never reach its final
>>>> state of ⟨Ĥ⟩.qn
>>>>
>>>> correctly simulated input to embedded_H would never reach its final
>>>> state of ⟨Ĥ⟩.qn
>>>>
>>>> correctly simulated input to embedded_H would never reach its final
>>>> state of ⟨Ĥ⟩.qn
>>>>
>>>>
>>>
>>> Which only happens if embedded_H never aborts its simulation,
>> No idiot it happens no matter what !
>> No idiot it happens no matter what !
>> No idiot it happens no matter what !
>> No idiot it happens no matter what !
>> No idiot it happens no matter what !
>>
>
> Nope, unless you can prove that two copies of the exact same algorithm
> given the exact same data can give differerent results (by showing an
> ACTUAL example that does it) it is proven otherwise and you are proved
> to be just a pathological liar.
This conclusively proves that I am correct.
Saying that you simply don't believe it is not any rebuttal!

When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

Then these steps would keep repeating:
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

The above repeating pattern shows that the correctly simulated input to
embedded_H would never reach its final state of ⟨Ĥ⟩.qn conclusively
proving that this simulated input never halts. This enables embedded_H
to abort its simulation and correctly transition to Ĥ.qn.

--
Copyright 2021 Pete Olcott

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

On 3/15/2022 4:02 PM, olcott wrote:
> On 3/15/2022 4:48 PM, Jeff Barnett wrote:
>> On 3/15/2022 1:44 PM, olcott wrote:
>>> On 3/15/2022 1:58 PM, Jeff Barnett wrote:
>>>> On 3/15/2022 10:11 AM, olcott wrote:
>>>>> On 3/15/2022 10:44 AM, Malcolm McLean wrote:
>>>>
>>>>     <MAJOR SNIP>
>>>>
>>>>>> So how would you describe a compiler which is "bootstrapped", i.e.
>>>>>> fed its own
>>>>>> source code?
>>>>>
>>>>> A compiler that is fed its own source-code is not the same because
>>>>> the compiler does not execute this source-code.
>>>> This is one of your best Peter. Along the way you've had 100s of
>>>> messages that have said that simulation as a basis for a Halting
>>>> Problem solution is hopeless. Of course you pay no attention because
>>>> it's unlikely you understood what you were being told. So here you
>>>> are looping back over years of the same bone headed approach.
>>>>
>>>> Let's start with a few basics:
>>>>
>>>> Nothing executes source code; even an interpreter ingests it first.
>>>>
>>>
>>> A compiler the compiles its own source-code is nothing at all like
>>> executing this source code.
>>
>> You really do have rocks in your head. Think for at least 2 seconds
>> before responding and getting it all wrong. The mistakes you are
>> making with the above statement are so basic that I hardly know where
>> to start. As I've been told many times it's harder to teach
>> Kindergarten than grad students. And in this instance, with you, we
>> have a sixty year old crawling around in diapers.
>>
>>> An interpreter that interprets source code can be reasonably
>>> construed as running this source code.
>>
>> Perhaps. The issue is it really doesn't know that it is it's own
>> source code, does it? And, in fact, neither it nor any observer is
>> aware of any vicious self reference. Only a dunce would worry about
>> it. You do worry don't you?
>
> In other words you are saying that no one is bright enough to be able to
> detect what is essentially infinite recursion.
You soiled your diapers again. I said nothing of the sort. I will say it
now though, nobody is intelligent enough to systematically (by
algorithm) spot infinite recursion. God can't do it either. It's not
theoretically possible. Only an ignorant nitwit would not know that and
prattle on for years about it.
By the way, if you think either you or a program you write can spot
infinite recursion in, say, a year I'd love to make a sizable bet that
you can not. In the past several of us have proposed such test cases to
you. You haven't tried any of them. In fact you clipped these problem
descriptions out of the original messages when you responded.
It's amazing that you make the same mistakes over and over again. If you
could spot the infinite recursion/iteration in that small mind of yours
you would be doing something more sane with your time.
--
Jeff Barnett

On 3/15/22 11:32 PM, olcott wrote:
> On 3/15/2022 10:02 PM, Richard Damon wrote:
>> On 3/15/22 10:43 PM, olcott wrote:
>>> On 3/15/2022 9:38 PM, Richard Damon wrote:
>>>> On 3/15/22 10:29 PM, olcott wrote:
>>>>> On 3/15/2022 8:47 PM, Richard Damon wrote:
>>>>>> On 3/15/22 9:15 PM, olcott wrote:
>>>>>>> On 3/15/2022 3:24 PM, André G. Isaak wrote:
>>>>>>>> On 2022-03-15 08:51, olcott wrote:
>>>>>>>>> On 3/15/2022 6:35 AM, Malcolm McLean wrote:
>>>>>>>>>> On Tuesday, 15 March 2022 at 04:04:06 UTC, André G. Isaak wrote:
>>>>>>>>>>> On 2022-03-14 21:07, olcott wrote:
>>>>>>>>>>>> On 3/14/2022 9:05 PM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2022-03-14 20:02, olcott wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> <snip nonresponsive post>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Again, I'll repeat the question which you dishonestly
>>>>>>>>>>>>> snipped rather
>>>>>>>>>>>>> than answering. I won't bother putting it in all caps or
>>>>>>>>>>>>> repeating it
>>>>>>>>>>>>> five times.
>>>>>>>>>>>>>
>>>>>>>>>>>>> How does one encode Ĥ applied to ⟨Ĥ⟩ as a string which can
>>>>>>>>>>>>> be passed
>>>>>>>>>>>>> to Ĥ if that computation is in fact different from ⟨Ĥ⟩ ⟨Ĥ⟩?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>
>>>>>>>>>>>> The ⟨Ĥ⟩ ⟨Ĥ⟩ above is inherently exactly one level of
>>>>>>>>>>>> indirect reference
>>>>>>>>>>>> away from Ĥ ⟨Ĥ⟩ above, thus making it utterly impossible to
>>>>>>>>>>>> pass this
>>>>>>>>>>>> exact same Ĥ ⟨Ĥ⟩ as an input to embedded_H.
>>>>>>>>>>> There are no 'levels of indirection' when discussing Turing
>>>>>>>>>>> Machines.
>>>>>>>>>>>
>>>>>>>>>>> If there is no way to encode Ĥ ⟨Ĥ⟩ such that it can be given
>>>>>>>>>>> as an input
>>>>>>>>>>> to your decider, then your decider is broken since it must be
>>>>>>>>>>> able to
>>>>>>>>>>> provide an answer for *every* computation, including Ĥ ⟨Ĥ⟩.
>>>>>>>>>>>
>>>>>>>>>> Though that would actually be a genuine contribution to
>>>>>>>>>> computer science.
>>>>>>>>>> If you could devise a language such that a large subset of
>>>>>>>>>> halting and
>>>>>>>>>> non-halting machines could be described, but not machines for
>>>>>>>>>> which the
>>>>>>>>>> halting status is difficult or impossible for a predefined
>>>>>>>>>> halt decider to determine.
>>>>>>>>>
>>>>>>>>> André does not seem to be able to comprehend that a Turing
>>>>>>>>> machine decider cannot possibly have its own self or an
>>>>>>>>> encoding of its own self as its input. The closest thing
>>>>>>>>> possible that it can have is an encoding of another different
>>>>>>>>> instance of itself.
>>>>>>>>
>>>>>>>> Computations don't have different instances. What would it even
>>>>>>>> mean to 'instantiate' a computation?
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>
>>>>>>> Back to the key point:
>>>>>>>
>>>>>>> That ⟨Ĥ⟩ ⟨Ĥ⟩ finite strings specify non-halting behavior when
>>>>>>> correctly simulated by the UTM within embedded_H is the same as
>>>>>>> these finite strings specifying non-halting behavior when
>>>>>>> correctly interpreted by a BASIC in interpreter.
>>>>>>>
>>>>>>> 10 PRINT "Hello, World!"
>>>>>>> 20 goto 10
>>>>>>> 30 END
>>>>>>>
>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩
>>>>>>> ⟨Ĥ2⟩
>>>>>>>
>>>>>>> Then these steps would keep repeating:
>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates
>>>>>>> ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates
>>>>>>> ⟨Ĥ3⟩ ⟨Ĥ4⟩
>>>>>>>    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates
>>>>>>> ⟨Ĥ4⟩ ⟨Ĥ5⟩...
>>>>>>>
>>>>>>> The above repeating pattern shows that the correctly simulated
>>>>>>> input to embedded_H would never reach its final state of ⟨Ĥ⟩.qn
>>>>>>> conclusively proving that this simulated input never halts. This
>>>>>>> enables embedded_H to abort its simulation and correctly
>>>>>>> transition to Ĥ.qn.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> But that infinite behavor only occurs if the embedded_H NEVER
>>>>>> aborts its simulation and thus it fails at the requirement to GIVE
>>>>>> the answer.
>>>>>>
>>>>>
>>>>> correctly simulated input to embedded_H would never reach its final
>>>>> state of ⟨Ĥ⟩.qn
>>>>>
>>>>> correctly simulated input to embedded_H would never reach its final
>>>>> state of ⟨Ĥ⟩.qn
>>>>>
>>>>> correctly simulated input to embedded_H would never reach its final
>>>>> state of ⟨Ĥ⟩.qn
>>>>>
>>>>> correctly simulated input to embedded_H would never reach its final
>>>>> state of ⟨Ĥ⟩.qn
>>>>>
>>>>>
>>>>
>>>> Which only happens if embedded_H never aborts its simulation,
>>> No idiot it happens no matter what !
>>> No idiot it happens no matter what !
>>> No idiot it happens no matter what !
>>> No idiot it happens no matter what !
>>> No idiot it happens no matter what !
>>>
>>
>> Nope, unless you can prove that two copies of the exact same algorithm
>> given the exact same data can give differerent results (by showing an
>> ACTUAL example that does it) it is proven otherwise and you are proved
>> to be just a pathological liar.
> This conclusively proves that I am correct.
> Saying that you simply don't believe it is not any rebuttal!
>
> When Ĥ is applied to ⟨Ĥ⟩
>   Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>
> Then these steps would keep repeating:
>   Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>   Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>   Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
>
> The above repeating pattern shows that the correctly simulated input to
> embedded_H would never reach its final state of ⟨Ĥ⟩.qn conclusively
> proving that this simulated input never halts. This enables embedded_H
> to abort its simulation and correctly transition to Ĥ.qn.
>

Nope, smae mistake. Just proves that you can't prove you claim and also
that you like to LIE by improper clipping.

On 3/16/2022 2:21 AM, Jeff Barnett wrote:
> On 3/15/2022 4:02 PM, olcott wrote:
>> On 3/15/2022 4:48 PM, Jeff Barnett wrote:
>>> On 3/15/2022 1:44 PM, olcott wrote:
>>>> On 3/15/2022 1:58 PM, Jeff Barnett wrote:
>>>>> On 3/15/2022 10:11 AM, olcott wrote:
>>>>>> On 3/15/2022 10:44 AM, Malcolm McLean wrote:
>>>>>
>>>>>     <MAJOR SNIP>
>>>>>
>>>>>>> So how would you describe a compiler which is "bootstrapped",
>>>>>>> i.e. fed its own
>>>>>>> source code?
>>>>>>
>>>>>> A compiler that is fed its own source-code is not the same because
>>>>>> the compiler does not execute this source-code.
>>>>> This is one of your best Peter. Along the way you've had 100s of
>>>>> messages that have said that simulation as a basis for a Halting
>>>>> Problem solution is hopeless. Of course you pay no attention
>>>>> because it's unlikely you understood what you were being told. So
>>>>> here you are looping back over years of the same bone headed approach.
>>>>>
>>>>> Let's start with a few basics:
>>>>>
>>>>> Nothing executes source code; even an interpreter ingests it first.
>>>>>
>>>>
>>>> A compiler the compiles its own source-code is nothing at all like
>>>> executing this source code.
>>>
>>> You really do have rocks in your head. Think for at least 2 seconds
>>> before responding and getting it all wrong. The mistakes you are
>>> making with the above statement are so basic that I hardly know where
>>> to start. As I've been told many times it's harder to teach
>>> Kindergarten than grad students. And in this instance, with you, we
>>> have a sixty year old crawling around in diapers.
>>>
>>>> An interpreter that interprets source code can be reasonably
>>>> construed as running this source code.
>>>
>>> Perhaps. The issue is it really doesn't know that it is it's own
>>> source code, does it? And, in fact, neither it nor any observer is
>>> aware of any vicious self reference. Only a dunce would worry about
>>> it. You do worry don't you?
>>
>> In other words you are saying that no one is bright enough to be able
>> to detect what is essentially infinite recursion.
> You soiled your diapers again. I said nothing of the sort. I will say it
> now though, nobody is intelligent enough to systematically (by
> algorithm) spot infinite recursion. God can't do it either. It's not
> theoretically possible. Only an ignorant nitwit would not know that and
> prattle on for years about it.
>

I already have a group of many experts that concur that infinite
recursion can be detected and the criterion measure by which it is
correctly detected.

> By the way, if you think either you or a program you write can spot
> infinite recursion in, say, a year I'd love to make a sizable bet that
> you can not. In the past several of us have proposed such test cases to
> you. You haven't tried any of them. In fact you clipped these problem
> descriptions out of the original messages when you responded.
>
> It's amazing that you make the same mistakes over and over again. If you
> could spot the infinite recursion/iteration in that small mind of yours
> you would be doing something more sane with your time.

--
Copyright 2021 Pete Olcott

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

On 3/16/2022 6:05 AM, Richard Damon wrote:
> On 3/15/22 11:32 PM, olcott wrote:
>> On 3/15/2022 10:02 PM, Richard Damon wrote:
>>> On 3/15/22 10:43 PM, olcott wrote:
>>>> On 3/15/2022 9:38 PM, Richard Damon wrote:
>>>>> On 3/15/22 10:29 PM, olcott wrote:
>>>>>> On 3/15/2022 8:47 PM, Richard Damon wrote:
>>>>>>> On 3/15/22 9:15 PM, olcott wrote:
>>>>>>>> On 3/15/2022 3:24 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-03-15 08:51, olcott wrote:
>>>>>>>>>> On 3/15/2022 6:35 AM, Malcolm McLean wrote:
>>>>>>>>>>> On Tuesday, 15 March 2022 at 04:04:06 UTC, André G. Isaak wrote:
>>>>>>>>>>>> On 2022-03-14 21:07, olcott wrote:
>>>>>>>>>>>>> On 3/14/2022 9:05 PM, André G. Isaak wrote:
>>>>>>>>>>>>>> On 2022-03-14 20:02, olcott wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <snip nonresponsive post>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Again, I'll repeat the question which you dishonestly
>>>>>>>>>>>>>> snipped rather
>>>>>>>>>>>>>> than answering. I won't bother putting it in all caps or
>>>>>>>>>>>>>> repeating it
>>>>>>>>>>>>>> five times.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> How does one encode Ĥ applied to ⟨Ĥ⟩ as a string which can
>>>>>>>>>>>>>> be passed
>>>>>>>>>>>>>> to Ĥ if that computation is in fact different from ⟨Ĥ⟩ ⟨Ĥ⟩?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>
>>>>>>>>>>>>> The ⟨Ĥ⟩ ⟨Ĥ⟩ above is inherently exactly one level of
>>>>>>>>>>>>> indirect reference
>>>>>>>>>>>>> away from Ĥ ⟨Ĥ⟩ above, thus making it utterly impossible to
>>>>>>>>>>>>> pass this
>>>>>>>>>>>>> exact same Ĥ ⟨Ĥ⟩ as an input to embedded_H.
>>>>>>>>>>>> There are no 'levels of indirection' when discussing Turing
>>>>>>>>>>>> Machines.
>>>>>>>>>>>>
>>>>>>>>>>>> If there is no way to encode Ĥ ⟨Ĥ⟩ such that it can be given
>>>>>>>>>>>> as an input
>>>>>>>>>>>> to your decider, then your decider is broken since it must
>>>>>>>>>>>> be able to
>>>>>>>>>>>> provide an answer for *every* computation, including Ĥ ⟨Ĥ⟩.
>>>>>>>>>>>>
>>>>>>>>>>> Though that would actually be a genuine contribution to
>>>>>>>>>>> computer science.
>>>>>>>>>>> If you could devise a language such that a large subset of
>>>>>>>>>>> halting and
>>>>>>>>>>> non-halting machines could be described, but not machines for
>>>>>>>>>>> which the
>>>>>>>>>>> halting status is difficult or impossible for a predefined
>>>>>>>>>>> halt decider to determine.
>>>>>>>>>>
>>>>>>>>>> André does not seem to be able to comprehend that a Turing
>>>>>>>>>> machine decider cannot possibly have its own self or an
>>>>>>>>>> encoding of its own self as its input. The closest thing
>>>>>>>>>> possible that it can have is an encoding of another different
>>>>>>>>>> instance of itself.
>>>>>>>>>
>>>>>>>>> Computations don't have different instances. What would it even
>>>>>>>>> mean to 'instantiate' a computation?
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>>
>>>>>>>>
>>>>>>>> Back to the key point:
>>>>>>>>
>>>>>>>> That ⟨Ĥ⟩ ⟨Ĥ⟩ finite strings specify non-halting behavior when
>>>>>>>> correctly simulated by the UTM within embedded_H is the same as
>>>>>>>> these finite strings specifying non-halting behavior when
>>>>>>>> correctly interpreted by a BASIC in interpreter.
>>>>>>>>
>>>>>>>> 10 PRINT "Hello, World!"
>>>>>>>> 20 goto 10
>>>>>>>> 30 END
>>>>>>>>
>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates
>>>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>
>>>>>>>> Then these steps would keep repeating:
>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates
>>>>>>>> ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates
>>>>>>>> ⟨Ĥ3⟩ ⟨Ĥ4⟩
>>>>>>>>    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates
>>>>>>>> ⟨Ĥ4⟩ ⟨Ĥ5⟩...
>>>>>>>>
>>>>>>>> The above repeating pattern shows that the correctly simulated
>>>>>>>> input to embedded_H would never reach its final state of ⟨Ĥ⟩.qn
>>>>>>>> conclusively proving that this simulated input never halts. This
>>>>>>>> enables embedded_H to abort its simulation and correctly
>>>>>>>> transition to Ĥ.qn.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> But that infinite behavor only occurs if the embedded_H NEVER
>>>>>>> aborts its simulation and thus it fails at the requirement to
>>>>>>> GIVE the answer.
>>>>>>>
>>>>>>
>>>>>> correctly simulated input to embedded_H would never reach its
>>>>>> final state of ⟨Ĥ⟩.qn
>>>>>>
>>>>>> correctly simulated input to embedded_H would never reach its
>>>>>> final state of ⟨Ĥ⟩.qn
>>>>>>
>>>>>> correctly simulated input to embedded_H would never reach its
>>>>>> final state of ⟨Ĥ⟩.qn
>>>>>>
>>>>>> correctly simulated input to embedded_H would never reach its
>>>>>> final state of ⟨Ĥ⟩.qn
>>>>>>
>>>>>>
>>>>>
>>>>> Which only happens if embedded_H never aborts its simulation,
>>>> No idiot it happens no matter what !
>>>> No idiot it happens no matter what !
>>>> No idiot it happens no matter what !
>>>> No idiot it happens no matter what !
>>>> No idiot it happens no matter what !
>>>>
>>>
>>> Nope, unless you can prove that two copies of the exact same
>>> algorithm given the exact same data can give differerent results (by
>>> showing an ACTUAL example that does it) it is proven otherwise and
>>> you are proved to be just a pathological liar.
>> This conclusively proves that I am correct.
>> Saying that you simply don't believe it is not any rebuttal!
>>
>> When Ĥ is applied to ⟨Ĥ⟩
>>    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>
>> Then these steps would keep repeating:
>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>>    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩
>> ⟨Ĥ5⟩...
>>
>> The above repeating pattern shows that the correctly simulated input
>> to embedded_H would never reach its final state of ⟨Ĥ⟩.qn conclusively
>> proving that this simulated input never halts. This enables embedded_H
>> to abort its simulation and correctly transition to Ĥ.qn.
>>
>
> Nope, smae mistake. Just proves that you can't prove you claim and also
> that you like to LIE by improper clipping.
>
> Note, you OMITTED the challenge, (Quoted below), so you are obviously
> being INTENTIONAL about your failure:
>
>>
>> If ANY copy of embedded_H applied to <H^> <H^> goes to Qn, then the
>> top level embedded_H will also go to Qn and the H^ that it is embedded
>> in goes to H^.Qn and HALT, and NOT infinite pattern occurs.
>>
>> Just Denying what is proven before your eyes proves that you are
>> either a pathological liar or delusional and have lost all grasp of
>> the truth.
>>
>> Please try to show where my proof is wrong.
>>
>> Show how an H^ built on an embedded_H that aborts its simulation of
>> <H^> <H^> doesn't halt, or prove that two identical copies of a
>> machine can behave differently when given identical information.
>> (Since you claim it happens in this case too)
>>
>> Failure to do this just proves you are lying.
>

On Wednesday, 16 March 2022 at 14:16:07 UTC, olcott wrote:
> On 3/16/2022 2:21 AM, Jeff Barnett wrote:
> > On 3/15/2022 4:02 PM, olcott wrote:
> >> On 3/15/2022 4:48 PM, Jeff Barnett wrote:
> >>> On 3/15/2022 1:44 PM, olcott wrote:
> >>>> On 3/15/2022 1:58 PM, Jeff Barnett wrote:
> >>>>> On 3/15/2022 10:11 AM, olcott wrote:
> >>>>>> On 3/15/2022 10:44 AM, Malcolm McLean wrote:
> >>>>>
> >>>>> <MAJOR SNIP>
> >>>>>
> >>>>>>> So how would you describe a compiler which is "bootstrapped",
> >>>>>>> i.e. fed its own
> >>>>>>> source code?
> >>>>>>
> >>>>>> A compiler that is fed its own source-code is not the same because
> >>>>>> the compiler does not execute this source-code.
> >>>>> This is one of your best Peter. Along the way you've had 100s of
> >>>>> messages that have said that simulation as a basis for a Halting
> >>>>> Problem solution is hopeless. Of course you pay no attention
> >>>>> because it's unlikely you understood what you were being told. So
> >>>>> here you are looping back over years of the same bone headed approach.
> >>>>>
> >>>>> Let's start with a few basics:
> >>>>>
> >>>>> Nothing executes source code; even an interpreter ingests it first.
> >>>>>
> >>>>
> >>>> A compiler the compiles its own source-code is nothing at all like
> >>>> executing this source code.
> >>>
> >>> You really do have rocks in your head. Think for at least 2 seconds
> >>> before responding and getting it all wrong. The mistakes you are
> >>> making with the above statement are so basic that I hardly know where
> >>> to start. As I've been told many times it's harder to teach
> >>> Kindergarten than grad students. And in this instance, with you, we
> >>> have a sixty year old crawling around in diapers.
> >>>
> >>>> An interpreter that interprets source code can be reasonably
> >>>> construed as running this source code.
> >>>
> >>> Perhaps. The issue is it really doesn't know that it is it's own
> >>> source code, does it? And, in fact, neither it nor any observer is
> >>> aware of any vicious self reference. Only a dunce would worry about
> >>> it. You do worry don't you?
> >>
> >> In other words you are saying that no one is bright enough to be able
> >> to detect what is essentially infinite recursion.
> > You soiled your diapers again. I said nothing of the sort. I will say it
> > now though, nobody is intelligent enough to systematically (by
> > algorithm) spot infinite recursion. God can't do it either. It's not
> > theoretically possible. Only an ignorant nitwit would not know that and
> > prattle on for years about it.
> >
> I already have a group of many experts that concur that infinite
> recursion can be detected and the criterion measure by which it is
> correctly detected.
>
It can often be detected.
In real programs which are basically imperative, with a small amount of recursion,
written by human programmers, infinite recursion can usually be detected quite easily.

However it's possible to recast famous open problems in mathematics as
recursive routines which either eventualy return or never return, depending on
whether the conjecture is true or false. Of course you can't detect infinite
recursion in these cases by using a simple toolkit of pattern matching.

On 3/16/2022 11:06 AM, Malcolm McLean wrote:
> On Wednesday, 16 March 2022 at 14:16:07 UTC, olcott wrote:
>> On 3/16/2022 2:21 AM, Jeff Barnett wrote:
>>> On 3/15/2022 4:02 PM, olcott wrote:
>>>> On 3/15/2022 4:48 PM, Jeff Barnett wrote:
>>>>> On 3/15/2022 1:44 PM, olcott wrote:
>>>>>> On 3/15/2022 1:58 PM, Jeff Barnett wrote:
>>>>>>> On 3/15/2022 10:11 AM, olcott wrote:
>>>>>>>> On 3/15/2022 10:44 AM, Malcolm McLean wrote:
>>>>>>>
>>>>>>> <MAJOR SNIP>
>>>>>>>
>>>>>>>>> So how would you describe a compiler which is "bootstrapped",
>>>>>>>>> i.e. fed its own
>>>>>>>>> source code?
>>>>>>>>
>>>>>>>> A compiler that is fed its own source-code is not the same because
>>>>>>>> the compiler does not execute this source-code.
>>>>>>> This is one of your best Peter. Along the way you've had 100s of
>>>>>>> messages that have said that simulation as a basis for a Halting
>>>>>>> Problem solution is hopeless. Of course you pay no attention
>>>>>>> because it's unlikely you understood what you were being told. So
>>>>>>> here you are looping back over years of the same bone headed approach.
>>>>>>>
>>>>>>> Let's start with a few basics:
>>>>>>>
>>>>>>> Nothing executes source code; even an interpreter ingests it first.
>>>>>>>
>>>>>>
>>>>>> A compiler the compiles its own source-code is nothing at all like
>>>>>> executing this source code.
>>>>>
>>>>> You really do have rocks in your head. Think for at least 2 seconds
>>>>> before responding and getting it all wrong. The mistakes you are
>>>>> making with the above statement are so basic that I hardly know where
>>>>> to start. As I've been told many times it's harder to teach
>>>>> Kindergarten than grad students. And in this instance, with you, we
>>>>> have a sixty year old crawling around in diapers.
>>>>>
>>>>>> An interpreter that interprets source code can be reasonably
>>>>>> construed as running this source code.
>>>>>
>>>>> Perhaps. The issue is it really doesn't know that it is it's own
>>>>> source code, does it? And, in fact, neither it nor any observer is
>>>>> aware of any vicious self reference. Only a dunce would worry about
>>>>> it. You do worry don't you?
>>>>
>>>> In other words you are saying that no one is bright enough to be able
>>>> to detect what is essentially infinite recursion.
>>> You soiled your diapers again. I said nothing of the sort. I will say it
>>> now though, nobody is intelligent enough to systematically (by
>>> algorithm) spot infinite recursion. God can't do it either. It's not
>>> theoretically possible. Only an ignorant nitwit would not know that and
>>> prattle on for years about it.
>>>
>> I already have a group of many experts that concur that infinite
>> recursion can be detected and the criterion measure by which it is
>> correctly detected.
>>
> It can often be detected.
> In real programs which are basically imperative, with a small amount of recursion,
> written by human programmers, infinite recursion can usually be detected quite easily.
>
> However it's possible to recast famous open problems in mathematics as
> recursive routines which either eventualy return or never return, depending on
> whether the conjecture is true or false. Of course you can't detect infinite
> recursion in these cases by using a simple toolkit of pattern matching.

Currently undecidable because a proof is currently unknown is not the
same as "undecidable" because of self contradiction such as the Liar
Paradox (Upon which the Tarski Undefinability Theorem is based).

--
Copyright 2021 Pete Olcott

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

On Wednesday, 16 March 2022 at 16:17:38 UTC, olcott wrote:
> On 3/16/2022 11:06 AM, Malcolm McLean wrote:
> > On Wednesday, 16 March 2022 at 14:16:07 UTC, olcott wrote:
> >> On 3/16/2022 2:21 AM, Jeff Barnett wrote:
> >>> On 3/15/2022 4:02 PM, olcott wrote:
> >>>> On 3/15/2022 4:48 PM, Jeff Barnett wrote:
> >>>>> On 3/15/2022 1:44 PM, olcott wrote:
> >>>>>> On 3/15/2022 1:58 PM, Jeff Barnett wrote:
> >>>>>>> On 3/15/2022 10:11 AM, olcott wrote:
> >>>>>>>> On 3/15/2022 10:44 AM, Malcolm McLean wrote:
> >>>>>>>
> >>>>>>> <MAJOR SNIP>
> >>>>>>>
> >>>>>>>>> So how would you describe a compiler which is "bootstrapped",
> >>>>>>>>> i.e. fed its own
> >>>>>>>>> source code?
> >>>>>>>>
> >>>>>>>> A compiler that is fed its own source-code is not the same because
> >>>>>>>> the compiler does not execute this source-code.
> >>>>>>> This is one of your best Peter. Along the way you've had 100s of
> >>>>>>> messages that have said that simulation as a basis for a Halting
> >>>>>>> Problem solution is hopeless. Of course you pay no attention
> >>>>>>> because it's unlikely you understood what you were being told. So
> >>>>>>> here you are looping back over years of the same bone headed approach.
> >>>>>>>
> >>>>>>> Let's start with a few basics:
> >>>>>>>
> >>>>>>> Nothing executes source code; even an interpreter ingests it first.
> >>>>>>>
> >>>>>>
> >>>>>> A compiler the compiles its own source-code is nothing at all like
> >>>>>> executing this source code.
> >>>>>
> >>>>> You really do have rocks in your head. Think for at least 2 seconds
> >>>>> before responding and getting it all wrong. The mistakes you are
> >>>>> making with the above statement are so basic that I hardly know where
> >>>>> to start. As I've been told many times it's harder to teach
> >>>>> Kindergarten than grad students. And in this instance, with you, we
> >>>>> have a sixty year old crawling around in diapers.
> >>>>>
> >>>>>> An interpreter that interprets source code can be reasonably
> >>>>>> construed as running this source code.
> >>>>>
> >>>>> Perhaps. The issue is it really doesn't know that it is it's own
> >>>>> source code, does it? And, in fact, neither it nor any observer is
> >>>>> aware of any vicious self reference. Only a dunce would worry about
> >>>>> it. You do worry don't you?
> >>>>
> >>>> In other words you are saying that no one is bright enough to be able
> >>>> to detect what is essentially infinite recursion.
> >>> You soiled your diapers again. I said nothing of the sort. I will say it
> >>> now though, nobody is intelligent enough to systematically (by
> >>> algorithm) spot infinite recursion. God can't do it either. It's not
> >>> theoretically possible. Only an ignorant nitwit would not know that and
> >>> prattle on for years about it.
> >>>
> >> I already have a group of many experts that concur that infinite
> >> recursion can be detected and the criterion measure by which it is
> >> correctly detected.
> >>
> > It can often be detected.
> > In real programs which are basically imperative, with a small amount of recursion,
> > written by human programmers, infinite recursion can usually be detected quite easily.
> >
> > However it's possible to recast famous open problems in mathematics as
> > recursive routines which either eventualy return or never return, depending on
> > whether the conjecture is true or false. Of course you can't detect infinite
> > recursion in these cases by using a simple toolkit of pattern matching.
> Currently undecidable because a proof is currently unknown is not the
> same as "undecidable" because of self contradiction such as the Liar
> Paradox (Upon which the Tarski Undefinability Theorem is based).
>
That's right. For example Goldbach's conjecture is that every even number above
two is the sum of two primes. If you have a universal infinite recursion detector,
it would be easy to prove or disprove this conjecture by writing a function which
terminates when it finds a counterexample, and running it through the detector.
But of course we can't write a universal infinite recursion detector.

What you might be able to do is write a special purpose detector, and prove or
disprove the conjecture that way. But you can't do that by using a few simple
techniques, or it would have been done already. What's more likely is that
the conjecture will be solved by mathematical techniques, and then you could
dectect functions which enumerate the conjecture, and decide them based on
prior knowledge. However that's difficult to do, and not really of much interest
to anyone.

On 16/03/2022 14:15, olcott wrote:
> On 3/16/2022 2:21 AM, Jeff Barnett wrote:
>> On 3/15/2022 4:02 PM, olcott wrote:
>>> On 3/15/2022 4:48 PM, Jeff Barnett wrote:
>>>> On 3/15/2022 1:44 PM, olcott wrote:
>>>>> On 3/15/2022 1:58 PM, Jeff Barnett wrote:
>>>>>> On 3/15/2022 10:11 AM, olcott wrote:
>>>>>>> On 3/15/2022 10:44 AM, Malcolm McLean wrote:
>>>>>>
>>>>>>     <MAJOR SNIP>
>>>>>>
>>>>>>>> So how would you describe a compiler which is "bootstrapped", i.e. fed its own
>>>>>>>> source code?
>>>>>>>
>>>>>>> A compiler that is fed its own source-code is not the same because the compiler does not
>>>>>>> execute this source-code.
>>>>>> This is one of your best Peter. Along the way you've had 100s of messages that have said that
>>>>>> simulation as a basis for a Halting Problem solution is hopeless. Of course you pay no
>>>>>> attention because it's unlikely you understood what you were being told. So here you are
>>>>>> looping back over years of the same bone headed approach.
>>>>>>
>>>>>> Let's start with a few basics:
>>>>>>
>>>>>> Nothing executes source code; even an interpreter ingests it first.
>>>>>>
>>>>>
>>>>> A compiler the compiles its own source-code is nothing at all like executing this source code.
>>>>
>>>> You really do have rocks in your head. Think for at least 2 seconds before responding and
>>>> getting it all wrong. The mistakes you are making with the above statement are so basic that I
>>>> hardly know where to start. As I've been told many times it's harder to teach Kindergarten than
>>>> grad students. And in this instance, with you, we have a sixty year old crawling around in diapers.
>>>>
>>>>> An interpreter that interprets source code can be reasonably construed as running this source
>>>>> code.
>>>>
>>>> Perhaps. The issue is it really doesn't know that it is it's own source code, does it? And, in
>>>> fact, neither it nor any observer is aware of any vicious self reference. Only a dunce would
>>>> worry about it. You do worry don't you?
>>>
>>> In other words you are saying that no one is bright enough to be able to detect what is
>>> essentially infinite recursion.
>> You soiled your diapers again. I said nothing of the sort. I will say it now though, nobody is
>> intelligent enough to systematically (by algorithm) spot infinite recursion. God can't do it
>> either. It's not theoretically possible. Only an ignorant nitwit would not know that and prattle
>> on for years about it.
>>
>
> I already have a group of many experts that concur that infinite recursion can be detected and the
> criterion measure by which it is correctly detected.

I'm afraid that you lack the intellect to understand exactly what other people are saying on
technical issues. How many times have you quoted me (and others here) as supporting something
you've claimed, whereas it turns out you had just misunderstood some remark that had been made?
[Answer: lots of times!]

You also have a habit of going elsewhere, and "tricking" the people there into "agreeing" with some
claim you've made here by not properly explaining the full context of your claim. Then you come
back here selectively quoting some "expert" to suggest he is supporting you. [Like when you went to
the x86 group and showed them your "trace" asking them if they could see what's going on, and got
one of them to say "it's looping...". You failed to mention the trace was not the "processor trace"
they would naturally expect, and that there was simulation involved, and that your trace was in fact
some kind of "merged simulation trace", and that you were using this trace to disprove the Halting
Problem theorem.]

It's been pointed out to you many times that algorithms exhist that can identify /some/ infinite
loops/recursions as such, but no algorithm detects ALL non-halting behaviour.

And specifically, your test (looking for more than one call to a particular address etc.) is
/unsound/ when you try to use it on your "merged simulation" trace. No expert would say otherwise
if they had been given the full context, so probably you've just tricked someone again...

Mike.

On 3/16/2022 11:40 AM, Malcolm McLean wrote:
> On Wednesday, 16 March 2022 at 16:17:38 UTC, olcott wrote:
>> On 3/16/2022 11:06 AM, Malcolm McLean wrote:
>>> On Wednesday, 16 March 2022 at 14:16:07 UTC, olcott wrote:
>>>> On 3/16/2022 2:21 AM, Jeff Barnett wrote:
>>>>> On 3/15/2022 4:02 PM, olcott wrote:
>>>>>> On 3/15/2022 4:48 PM, Jeff Barnett wrote:
>>>>>>> On 3/15/2022 1:44 PM, olcott wrote:
>>>>>>>> On 3/15/2022 1:58 PM, Jeff Barnett wrote:
>>>>>>>>> On 3/15/2022 10:11 AM, olcott wrote:
>>>>>>>>>> On 3/15/2022 10:44 AM, Malcolm McLean wrote:
>>>>>>>>>
>>>>>>>>> <MAJOR SNIP>
>>>>>>>>>
>>>>>>>>>>> So how would you describe a compiler which is "bootstrapped",
>>>>>>>>>>> i.e. fed its own
>>>>>>>>>>> source code?
>>>>>>>>>>
>>>>>>>>>> A compiler that is fed its own source-code is not the same because
>>>>>>>>>> the compiler does not execute this source-code.
>>>>>>>>> This is one of your best Peter. Along the way you've had 100s of
>>>>>>>>> messages that have said that simulation as a basis for a Halting
>>>>>>>>> Problem solution is hopeless. Of course you pay no attention
>>>>>>>>> because it's unlikely you understood what you were being told. So
>>>>>>>>> here you are looping back over years of the same bone headed approach.
>>>>>>>>>
>>>>>>>>> Let's start with a few basics:
>>>>>>>>>
>>>>>>>>> Nothing executes source code; even an interpreter ingests it first.
>>>>>>>>>
>>>>>>>>
>>>>>>>> A compiler the compiles its own source-code is nothing at all like
>>>>>>>> executing this source code.
>>>>>>>
>>>>>>> You really do have rocks in your head. Think for at least 2 seconds
>>>>>>> before responding and getting it all wrong. The mistakes you are
>>>>>>> making with the above statement are so basic that I hardly know where
>>>>>>> to start. As I've been told many times it's harder to teach
>>>>>>> Kindergarten than grad students. And in this instance, with you, we
>>>>>>> have a sixty year old crawling around in diapers.
>>>>>>>
>>>>>>>> An interpreter that interprets source code can be reasonably
>>>>>>>> construed as running this source code.
>>>>>>>
>>>>>>> Perhaps. The issue is it really doesn't know that it is it's own
>>>>>>> source code, does it? And, in fact, neither it nor any observer is
>>>>>>> aware of any vicious self reference. Only a dunce would worry about
>>>>>>> it. You do worry don't you?
>>>>>>
>>>>>> In other words you are saying that no one is bright enough to be able
>>>>>> to detect what is essentially infinite recursion.
>>>>> You soiled your diapers again. I said nothing of the sort. I will say it
>>>>> now though, nobody is intelligent enough to systematically (by
>>>>> algorithm) spot infinite recursion. God can't do it either. It's not
>>>>> theoretically possible. Only an ignorant nitwit would not know that and
>>>>> prattle on for years about it.
>>>>>
>>>> I already have a group of many experts that concur that infinite
>>>> recursion can be detected and the criterion measure by which it is
>>>> correctly detected.
>>>>
>>> It can often be detected.
>>> In real programs which are basically imperative, with a small amount of recursion,
>>> written by human programmers, infinite recursion can usually be detected quite easily.
>>>
>>> However it's possible to recast famous open problems in mathematics as
>>> recursive routines which either eventualy return or never return, depending on
>>> whether the conjecture is true or false. Of course you can't detect infinite
>>> recursion in these cases by using a simple toolkit of pattern matching.
>> Currently undecidable because a proof is currently unknown is not the
>> same as "undecidable" because of self contradiction such as the Liar
>> Paradox (Upon which the Tarski Undefinability Theorem is based).
>>
> That's right. For example Goldbach's conjecture is that every even number above
> two is the sum of two primes. If you have a universal infinite recursion detector,
> it would be easy to prove or disprove this conjecture by writing a function which
> terminates when it finds a counterexample, and running it through the detector.
> But of course we can't write a universal infinite recursion detector.
>

It does not need to be universal to defeat the halting problem proof
counter-example templates. This refutes this whole class of halting
problem proofs.

> What you might be able to do is write a special purpose detector, and prove or
> disprove the conjecture that way. But you can't do that by using a few simple
> techniques, or it would have been done already. What's more likely is that
> the conjecture will be solved by mathematical techniques, and then you could
> dectect functions which enumerate the conjecture, and decide them based on
> prior knowledge. However that's difficult to do, and not really of much interest
> to anyone.

--
Copyright 2021 Pete Olcott

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

On 3/16/2022 12:04 PM, Mike Terry wrote:
> On 16/03/2022 14:15, olcott wrote:
>> On 3/16/2022 2:21 AM, Jeff Barnett wrote:
>>> On 3/15/2022 4:02 PM, olcott wrote:
>>>> On 3/15/2022 4:48 PM, Jeff Barnett wrote:
>>>>> On 3/15/2022 1:44 PM, olcott wrote:
>>>>>> On 3/15/2022 1:58 PM, Jeff Barnett wrote:
>>>>>>> On 3/15/2022 10:11 AM, olcott wrote:
>>>>>>>> On 3/15/2022 10:44 AM, Malcolm McLean wrote:
>>>>>>>
>>>>>>>     <MAJOR SNIP>
>>>>>>>
>>>>>>>>> So how would you describe a compiler which is "bootstrapped",
>>>>>>>>> i.e. fed its own
>>>>>>>>> source code?
>>>>>>>>
>>>>>>>> A compiler that is fed its own source-code is not the same
>>>>>>>> because the compiler does not execute this source-code.
>>>>>>> This is one of your best Peter. Along the way you've had 100s of
>>>>>>> messages that have said that simulation as a basis for a Halting
>>>>>>> Problem solution is hopeless. Of course you pay no attention
>>>>>>> because it's unlikely you understood what you were being told. So
>>>>>>> here you are looping back over years of the same bone headed
>>>>>>> approach.
>>>>>>>
>>>>>>> Let's start with a few basics:
>>>>>>>
>>>>>>> Nothing executes source code; even an interpreter ingests it first.
>>>>>>>
>>>>>>
>>>>>> A compiler the compiles its own source-code is nothing at all like
>>>>>> executing this source code.
>>>>>
>>>>> You really do have rocks in your head. Think for at least 2 seconds
>>>>> before responding and getting it all wrong. The mistakes you are
>>>>> making with the above statement are so basic that I hardly know
>>>>> where to start. As I've been told many times it's harder to teach
>>>>> Kindergarten than grad students. And in this instance, with you, we
>>>>> have a sixty year old crawling around in diapers.
>>>>>
>>>>>> An interpreter that interprets source code can be reasonably
>>>>>> construed as running this source code.
>>>>>
>>>>> Perhaps. The issue is it really doesn't know that it is it's own
>>>>> source code, does it? And, in fact, neither it nor any observer is
>>>>> aware of any vicious self reference. Only a dunce would worry about
>>>>> it. You do worry don't you?
>>>>
>>>> In other words you are saying that no one is bright enough to be
>>>> able to detect what is essentially infinite recursion.
>>> You soiled your diapers again. I said nothing of the sort. I will say
>>> it now though, nobody is intelligent enough to systematically (by
>>> algorithm) spot infinite recursion. God can't do it either. It's not
>>> theoretically possible. Only an ignorant nitwit would not know that
>>> and prattle on for years about it.
>>>
>>
>> I already have a group of many experts that concur that infinite
>> recursion can be detected and the criterion measure by which it is
>> correctly detected.
>
> I'm afraid that you lack the intellect to understand exactly what other
> people are saying on technical issues.  How many times have you quoted
> me (and others here) as supporting something you've claimed, whereas it
> turns out you had just misunderstood some remark that had been made?
> [Answer: lots of times!]
>
> You also have a habit of going elsewhere, and "tricking" the people
> there into "agreeing" with some claim you've made here by not properly
> explaining the full context of your claim.  Then you come back here
> selectively quoting some "expert" to suggest he is supporting you.
> [Like when you went to the x86 group and showed them your "trace" asking
> them if they could see what's going on, and got one of them to say "it's
> looping...".  You failed to mention the trace was not the "processor
> trace" they would naturally expect, and that there was simulation
> involved, and that your trace was in fact some kind of "merged
> simulation trace", and that you were using this trace to disprove the
> Halting Problem theorem.]
>
> It's been pointed out to you many times that algorithms exhist that can
> identify /some/ infinite loops/recursions as such, but no algorithm
> detects ALL non-halting behaviour.
>
> And specifically, your test (looking for more than one call to a
> particular address etc.) is /unsound/ when you try to use it on your
> "merged simulation" trace.  No expert would say otherwise if they had
> been given the full context, so probably you've just tricked someone
> again...
>
>
> Mike.

None-the-less is is self-evident that the input presented to the copy of
the Linz H embedded at Ĥ.qx does specify infinitely nested simulation to
simulating halt decider embedded_H thus proving that a transition to
Ĥ.qn by embedded_H would be correct.

H.q0 ⟨M⟩ w ⊢* H.qy ----- iff UTM( ⟨M⟩, w ) reaches the final state of M
H.q0 ⟨M⟩ w ⊢* H.qn ----- iff UTM( ⟨M⟩, w ) would never reach the final
state of M

Simulating halt decider H performs a pure simulation of its input as if
it was a UTM unless and until it detects an infinitely repeating
pattern. Then it aborts the simulation of its input and transitions to
its final reject state. Otherwise H transitions to its accept state when
its simulation ends.

The following simplifies the syntax for the definition of the Linz
Turing machine Ĥ, it is now a single machine with a single start state.
A copy of Linz H is embedded at Ĥ.qx.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final
state.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
final state.

https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3

--
Copyright 2021 Pete Olcott

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

On 16/03/2022 17:20, olcott wrote:
> On 3/16/2022 12:04 PM, Mike Terry wrote:
>> On 16/03/2022 14:15, olcott wrote:
>>> On 3/16/2022 2:21 AM, Jeff Barnett wrote:
>>>> On 3/15/2022 4:02 PM, olcott wrote:
>>>>> On 3/15/2022 4:48 PM, Jeff Barnett wrote:
>>>>>> On 3/15/2022 1:44 PM, olcott wrote:
>>>>>>> On 3/15/2022 1:58 PM, Jeff Barnett wrote:
>>>>>>>> On 3/15/2022 10:11 AM, olcott wrote:
>>>>>>>>> On 3/15/2022 10:44 AM, Malcolm McLean wrote:
>>>>>>>>
>>>>>>>>     <MAJOR SNIP>
>>>>>>>>
>>>>>>>>>> So how would you describe a compiler which is "bootstrapped", i.e. fed its own
>>>>>>>>>> source code?
>>>>>>>>>
>>>>>>>>> A compiler that is fed its own source-code is not the same because the compiler does not
>>>>>>>>> execute this source-code.
>>>>>>>> This is one of your best Peter. Along the way you've had 100s of messages that have said
>>>>>>>> that simulation as a basis for a Halting Problem solution is hopeless. Of course you pay no
>>>>>>>> attention because it's unlikely you understood what you were being told. So here you are
>>>>>>>> looping back over years of the same bone headed approach.
>>>>>>>>
>>>>>>>> Let's start with a few basics:
>>>>>>>>
>>>>>>>> Nothing executes source code; even an interpreter ingests it first.
>>>>>>>>
>>>>>>>
>>>>>>> A compiler the compiles its own source-code is nothing at all like executing this source code.
>>>>>>
>>>>>> You really do have rocks in your head. Think for at least 2 seconds before responding and
>>>>>> getting it all wrong. The mistakes you are making with the above statement are so basic that I
>>>>>> hardly know where to start. As I've been told many times it's harder to teach Kindergarten
>>>>>> than grad students. And in this instance, with you, we have a sixty year old crawling around
>>>>>> in diapers.
>>>>>>
>>>>>>> An interpreter that interprets source code can be reasonably construed as running this source
>>>>>>> code.
>>>>>>
>>>>>> Perhaps. The issue is it really doesn't know that it is it's own source code, does it? And, in
>>>>>> fact, neither it nor any observer is aware of any vicious self reference. Only a dunce would
>>>>>> worry about it. You do worry don't you?
>>>>>
>>>>> In other words you are saying that no one is bright enough to be able to detect what is
>>>>> essentially infinite recursion.
>>>> You soiled your diapers again. I said nothing of the sort. I will say it now though, nobody is
>>>> intelligent enough to systematically (by algorithm) spot infinite recursion. God can't do it
>>>> either. It's not theoretically possible. Only an ignorant nitwit would not know that and prattle
>>>> on for years about it.
>>>>
>>>
>>> I already have a group of many experts that concur that infinite recursion can be detected and
>>> the criterion measure by which it is correctly detected.
>>
>> I'm afraid that you lack the intellect to understand exactly what other people are saying on
>> technical issues.  How many times have you quoted me (and others here) as supporting something
>> you've claimed, whereas it turns out you had just misunderstood some remark that had been made?
>> [Answer: lots of times!]
>>
>> You also have a habit of going elsewhere, and "tricking" the people there into "agreeing" with
>> some claim you've made here by not properly explaining the full context of your claim.  Then you
>> come back here selectively quoting some "expert" to suggest he is supporting you. [Like when you
>> went to the x86 group and showed them your "trace" asking them if they could see what's going on,
>> and got one of them to say "it's looping...".  You failed to mention the trace was not the
>> "processor trace" they would naturally expect, and that there was simulation involved, and that
>> your trace was in fact some kind of "merged simulation trace", and that you were using this trace
>> to disprove the Halting Problem theorem.]
>>
>> It's been pointed out to you many times that algorithms exhist that can identify /some/ infinite
>> loops/recursions as such, but no algorithm detects ALL non-halting behaviour.
>>
>> And specifically, your test (looking for more than one call to a particular address etc.) is
>> /unsound/ when you try to use it on your "merged simulation" trace.  No expert would say otherwise
>> if they had been given the full context, so probably you've just tricked someone again...
>>
>>
>> Mike.
>
> None-the-less is is self-evident that the input presented to the copy of the Linz H embedded at Ĥ.qx
> does specify infinitely nested simulation to simulating halt decider embedded_H thus proving that a
> transition to Ĥ.qn by embedded_H would be correct.

You mean self-evident TO YOU. To people who have an understanding of TMs it is simply wrong or
meaningless (depending on how tolerant people are of your wishy-washy phrasing).

Mike.

On 3/16/2022 12:37 PM, Mike Terry wrote:
> On 16/03/2022 17:20, olcott wrote:
>> On 3/16/2022 12:04 PM, Mike Terry wrote:
>>> On 16/03/2022 14:15, olcott wrote:
>>>> On 3/16/2022 2:21 AM, Jeff Barnett wrote:
>>>>> On 3/15/2022 4:02 PM, olcott wrote:
>>>>>> On 3/15/2022 4:48 PM, Jeff Barnett wrote:
>>>>>>> On 3/15/2022 1:44 PM, olcott wrote:
>>>>>>>> On 3/15/2022 1:58 PM, Jeff Barnett wrote:
>>>>>>>>> On 3/15/2022 10:11 AM, olcott wrote:
>>>>>>>>>> On 3/15/2022 10:44 AM, Malcolm McLean wrote:
>>>>>>>>>
>>>>>>>>>     <MAJOR SNIP>
>>>>>>>>>
>>>>>>>>>>> So how would you describe a compiler which is "bootstrapped",
>>>>>>>>>>> i.e. fed its own
>>>>>>>>>>> source code?
>>>>>>>>>>
>>>>>>>>>> A compiler that is fed its own source-code is not the same
>>>>>>>>>> because the compiler does not execute this source-code.
>>>>>>>>> This is one of your best Peter. Along the way you've had 100s
>>>>>>>>> of messages that have said that simulation as a basis for a
>>>>>>>>> Halting Problem solution is hopeless. Of course you pay no
>>>>>>>>> attention because it's unlikely you understood what you were
>>>>>>>>> being told. So here you are looping back over years of the same
>>>>>>>>> bone headed approach.
>>>>>>>>>
>>>>>>>>> Let's start with a few basics:
>>>>>>>>>
>>>>>>>>> Nothing executes source code; even an interpreter ingests it
>>>>>>>>> first.
>>>>>>>>>
>>>>>>>>
>>>>>>>> A compiler the compiles its own source-code is nothing at all
>>>>>>>> like executing this source code.
>>>>>>>
>>>>>>> You really do have rocks in your head. Think for at least 2
>>>>>>> seconds before responding and getting it all wrong. The mistakes
>>>>>>> you are making with the above statement are so basic that I
>>>>>>> hardly know where to start. As I've been told many times it's
>>>>>>> harder to teach Kindergarten than grad students. And in this
>>>>>>> instance, with you, we have a sixty year old crawling around in
>>>>>>> diapers.
>>>>>>>
>>>>>>>> An interpreter that interprets source code can be reasonably
>>>>>>>> construed as running this source code.
>>>>>>>
>>>>>>> Perhaps. The issue is it really doesn't know that it is it's own
>>>>>>> source code, does it? And, in fact, neither it nor any observer
>>>>>>> is aware of any vicious self reference. Only a dunce would worry
>>>>>>> about it. You do worry don't you?
>>>>>>
>>>>>> In other words you are saying that no one is bright enough to be
>>>>>> able to detect what is essentially infinite recursion.
>>>>> You soiled your diapers again. I said nothing of the sort. I will
>>>>> say it now though, nobody is intelligent enough to systematically
>>>>> (by algorithm) spot infinite recursion. God can't do it either.
>>>>> It's not theoretically possible. Only an ignorant nitwit would not
>>>>> know that and prattle on for years about it.
>>>>>
>>>>
>>>> I already have a group of many experts that concur that infinite
>>>> recursion can be detected and the criterion measure by which it is
>>>> correctly detected.
>>>
>>> I'm afraid that you lack the intellect to understand exactly what
>>> other people are saying on technical issues.  How many times have you
>>> quoted me (and others here) as supporting something you've claimed,
>>> whereas it turns out you had just misunderstood some remark that had
>>> been made? [Answer: lots of times!]
>>>
>>> You also have a habit of going elsewhere, and "tricking" the people
>>> there into "agreeing" with some claim you've made here by not
>>> properly explaining the full context of your claim.  Then you come
>>> back here selectively quoting some "expert" to suggest he is
>>> supporting you. [Like when you went to the x86 group and showed them
>>> your "trace" asking them if they could see what's going on, and got
>>> one of them to say "it's looping...".  You failed to mention the
>>> trace was not the "processor trace" they would naturally expect, and
>>> that there was simulation involved, and that your trace was in fact
>>> some kind of "merged simulation trace", and that you were using this
>>> trace to disprove the Halting Problem theorem.]
>>>
>>> It's been pointed out to you many times that algorithms exhist that
>>> can identify /some/ infinite loops/recursions as such, but no
>>> algorithm detects ALL non-halting behaviour.
>>>
>>> And specifically, your test (looking for more than one call to a
>>> particular address etc.) is /unsound/ when you try to use it on your
>>> "merged simulation" trace.  No expert would say otherwise if they had
>>> been given the full context, so probably you've just tricked someone
>>> again...
>>>
>>>
>>> Mike.
>>
>> None-the-less is is self-evident that the input presented to the copy
>> of the Linz H embedded at Ĥ.qx does specify infinitely nested
>> simulation to simulating halt decider embedded_H thus proving that a
>> transition to Ĥ.qn by embedded_H would be correct.
>
> You mean self-evident TO YOU.  To people who have an understanding of
> TMs it is simply wrong or meaningless (depending on how tolerant people
> are of your wishy-washy phrasing).
>
>
> Mike.
>

They simply dogmatically state that the believe that I am wrong about
this yet cannot point to the specific error because there is none:

When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

Then these steps would keep repeating:
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

The above repeating pattern shows that the correctly simulated input to
embedded_H would never reach its final state of ⟨Ĥ⟩.qn conclusively
proving that this simulated input never halts. This enables embedded_H
to abort its simulation and correctly transition to Ĥ.qn.

--
Copyright 2021 Pete Olcott

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

On 2022-03-15 15:44, olcott wrote:
> On 3/15/2022 3:24 PM, André G. Isaak wrote:
>> On 2022-03-15 08:51, olcott wrote:
>>> On 3/15/2022 6:35 AM, Malcolm McLean wrote:
>>>> On Tuesday, 15 March 2022 at 04:04:06 UTC, André G. Isaak wrote:
>>>>> On 2022-03-14 21:07, olcott wrote:
>>>>>> On 3/14/2022 9:05 PM, André G. Isaak wrote:
>>>>>>> On 2022-03-14 20:02, olcott wrote:
>>>>>>>
>>>>>>> <snip nonresponsive post>
>>>>>>>
>>>>>>> Again, I'll repeat the question which you dishonestly snipped rather
>>>>>>> than answering. I won't bother putting it in all caps or
>>>>>>> repeating it
>>>>>>> five times.
>>>>>>>
>>>>>>> How does one encode Ĥ applied to ⟨Ĥ⟩ as a string which can be passed
>>>>>>> to Ĥ if that computation is in fact different from ⟨Ĥ⟩ ⟨Ĥ⟩?
>>>>>>>
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>
>>>>>> The ⟨Ĥ⟩ ⟨Ĥ⟩ above is inherently exactly one level of indirect
>>>>>> reference
>>>>>> away from Ĥ ⟨Ĥ⟩ above, thus making it utterly impossible to pass this
>>>>>> exact same Ĥ ⟨Ĥ⟩ as an input to embedded_H.
>>>>> There are no 'levels of indirection' when discussing Turing Machines.
>>>>>
>>>>> If there is no way to encode Ĥ ⟨Ĥ⟩ such that it can be given as an
>>>>> input
>>>>> to your decider, then your decider is broken since it must be able to
>>>>> provide an answer for *every* computation, including Ĥ ⟨Ĥ⟩.
>>>>>
>>>> Though that would actually be a genuine contribution to computer
>>>> science.
>>>> If you could devise a language such that a large subset of halting and
>>>> non-halting machines could be described, but not machines for which the
>>>> halting status is difficult or impossible for a predefined halt
>>>> decider to determine.
>>>
>>> André does not seem to be able to comprehend that a Turing machine
>>> decider cannot possibly have its own self or an encoding of its own
>>> self as its input. The closest thing possible that it can have is an
>>> encoding of another different instance of itself.
>>
>> Computations don't have different instances. What would it even mean
>> to 'instantiate' a computation?
>>
>> André
>>
>
> A Turing machine UTM that is simulating its own Turing machine
> description is two distinct instances: (executed and simulated) even if
> computer science does not bother to pay attention to this level of
> detail, or have the terminology to express it.

You're confusing computations and Turing Machines.

If you pass a UTM a description of itself, it will determine what UTM
applied to an empty tape will do.

UTM ⟨UTM⟩

and

UTM ∅

are entirely distinct computations. They are not different 'instances'
of some computation. Every "instance" of

M ⟨I⟩

is the exact same computation. So there is no point in talking about
"instances".

Do you actually understand what instantiation means?

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 3/16/2022 3:11 PM, André G. Isaak wrote:
> On 2022-03-15 15:44, olcott wrote:
>> On 3/15/2022 3:24 PM, André G. Isaak wrote:
>>> On 2022-03-15 08:51, olcott wrote:
>>>> On 3/15/2022 6:35 AM, Malcolm McLean wrote:
>>>>> On Tuesday, 15 March 2022 at 04:04:06 UTC, André G. Isaak wrote:
>>>>>> On 2022-03-14 21:07, olcott wrote:
>>>>>>> On 3/14/2022 9:05 PM, André G. Isaak wrote:
>>>>>>>> On 2022-03-14 20:02, olcott wrote:
>>>>>>>>
>>>>>>>> <snip nonresponsive post>
>>>>>>>>
>>>>>>>> Again, I'll repeat the question which you dishonestly snipped
>>>>>>>> rather
>>>>>>>> than answering. I won't bother putting it in all caps or
>>>>>>>> repeating it
>>>>>>>> five times.
>>>>>>>>
>>>>>>>> How does one encode Ĥ applied to ⟨Ĥ⟩ as a string which can be
>>>>>>>> passed
>>>>>>>> to Ĥ if that computation is in fact different from ⟨Ĥ⟩ ⟨Ĥ⟩?
>>>>>>>>
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>
>>>>>>> The ⟨Ĥ⟩ ⟨Ĥ⟩ above is inherently exactly one level of indirect
>>>>>>> reference
>>>>>>> away from Ĥ ⟨Ĥ⟩ above, thus making it utterly impossible to pass
>>>>>>> this
>>>>>>> exact same Ĥ ⟨Ĥ⟩ as an input to embedded_H.
>>>>>> There are no 'levels of indirection' when discussing Turing Machines.
>>>>>>
>>>>>> If there is no way to encode Ĥ ⟨Ĥ⟩ such that it can be given as an
>>>>>> input
>>>>>> to your decider, then your decider is broken since it must be able to
>>>>>> provide an answer for *every* computation, including Ĥ ⟨Ĥ⟩.
>>>>>>
>>>>> Though that would actually be a genuine contribution to computer
>>>>> science.
>>>>> If you could devise a language such that a large subset of halting and
>>>>> non-halting machines could be described, but not machines for which
>>>>> the
>>>>> halting status is difficult or impossible for a predefined halt
>>>>> decider to determine.
>>>>
>>>> André does not seem to be able to comprehend that a Turing machine
>>>> decider cannot possibly have its own self or an encoding of its own
>>>> self as its input. The closest thing possible that it can have is an
>>>> encoding of another different instance of itself.
>>>
>>> Computations don't have different instances. What would it even mean
>>> to 'instantiate' a computation?
>>>
>>> André
>>>
>>
>> A Turing machine UTM that is simulating its own Turing machine
>> description is two distinct instances: (executed and simulated) even
>> if computer science does not bother to pay attention to this level of
>> detail, or have the terminology to express it.
>
> You're confusing computations and Turing Machines.
>
> If you pass a UTM a description of itself, it will determine what UTM
> applied to an empty tape will do.
>
> UTM ⟨UTM⟩
>
> and
>
> UTM ∅
>
> are entirely distinct computations.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

In the above: Ĥ applied to ⟨Ĥ⟩ and the ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H
vary by exactly one level of indirect reference.

embedded_H does not, cannot, and its not supposed to report on the exact
same computation that contains itself.

embedded_H computes the mapping of its input ⟨Ĥ⟩ ⟨Ĥ⟩ a final state of
embedded_H.

> They are not different 'instances'
> of some computation. Every "instance" of
>
> M ⟨I⟩
>
> is the exact same computation. So there is no point in talking about
> "instances".
>
> Do you actually understand what instantiation means?
>
> André
>

What Does Instantiate Mean?
Instantiate (a verb) and instantiation (the noun) in computer science
refer to the creation of an object (or an “instance” of a given class)
in an object-oriented programming (OOP) language. Referencing a class
declaration, an instantiated object is named and created, in memory or
on disk.

https://www.techopedia.com/definition/26857/instantiate#:~:text=Instantiate%20(a%20verb)%20and%20instantiation,in%20memory%20or%20on%20disk.

--
Copyright 2021 Pete Olcott

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

In comp.theory olcott <NoOne@nowhere.com> wrote:
> On 3/16/2022 12:37 PM, Mike Terry wrote:
>> On 16/03/2022 17:20, olcott wrote:
>>> On 3/16/2022 12:04 PM, Mike Terry wrote:

[ .... ]

>>>> I'm afraid that you lack the intellect to understand exactly what
>>>> other people are saying on technical issues.  How many times have
>>>> you quoted me (and others here) as supporting something you've
>>>> claimed, whereas it turns out you had just misunderstood some remark
>>>> that had been made? [Answer: lots of times!]

>>>> You also have a habit of going elsewhere, and "tricking" the people
>>>> there into "agreeing" with some claim you've made here by not
>>>> properly explaining the full context of your claim.  Then you come
>>>> back here selectively quoting some "expert" to suggest he is
>>>> supporting you. [Like when you went to the x86 group and showed them
>>>> your "trace" asking them if they could see what's going on, and got
>>>> one of them to say "it's looping...".  You failed to mention the
>>>> trace was not the "processor trace" they would naturally expect, and
>>>> that there was simulation involved, and that your trace was in fact
>>>> some kind of "merged simulation trace", and that you were using this
>>>> trace to disprove the Halting Problem theorem.]

>>>> It's been pointed out to you many times that algorithms exhist that
>>>> can identify /some/ infinite loops/recursions as such, but no
>>>> algorithm detects ALL non-halting behaviour.

>>>> And specifically, your test (looking for more than one call to a
>>>> particular address etc.) is /unsound/ when you try to use it on your
>>>> "merged simulation" trace.  No expert would say otherwise if they
>>>> had been given the full context, so probably you've just tricked
>>>> someone again...

>>>> Mike.

>>> None-the-less is is self-evident that the input presented to the copy
>>> of the Linz H embedded at Ĥ.qx does specify infinitely nested
>>> simulation to simulating halt decider embedded_H thus proving that a
>>> transition to Ĥ.qn by embedded_H would be correct.

>> You mean self-evident TO YOU.  To people who have an understanding of
>> TMs it is simply wrong or meaningless (depending on how tolerant people
>> are of your wishy-washy phrasing).

>> Mike.

> They simply dogmatically state that the believe that I am wrong about
> this yet cannot point to the specific error because there is none:

You pathetic deluded patronising liar. There's no "believe" about it.
Everybody KNOWS you're wrong. There's a whole group of people who've
been pointing out specific errors in your ravings for years. You just
ignore them.

> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

> Then these steps would keep repeating:
> Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
> Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
> Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

What has the above got to do with anything? What the heck is
"embedded_H"? You keep trying to pretend that you are dealing with the
construction from Linz's book, but in that there is no "embedded_H".

> The above repeating pattern shows that the correctly simulated input to
> embedded_H would never reach its final state of ⟨Ĥ⟩..qn conclusively
> proving that this simulated input never halts. This enables embedded_H
> to abort its simulation and correctly transition to Ĥ.qn.

You haven't a clue what "prove" means in the mathematical sense, so stop
abusing the word. You have proven nothing.

> --
> Copyright 2021 Pete Olcott

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

--
Alan Mackenzie (Nuremberg, Germany).

On 2022-03-16 14:22, olcott wrote:
> On 3/16/2022 3:11 PM, André G. Isaak wrote:
>> On 2022-03-15 15:44, olcott wrote:

<snip>

>>> A Turing machine UTM that is simulating its own Turing machine
>>> description is two distinct instances: (executed and simulated) even
>>> if computer science does not bother to pay attention to this level of
>>> detail, or have the terminology to express it.
>>
>> You're confusing computations and Turing Machines.
>>
>> If you pass a UTM a description of itself, it will determine what UTM
>> applied to an empty tape will do.
>>
>> UTM ⟨UTM⟩
>>
>> and
>>
>> UTM ∅
>>
>> are entirely distinct computations.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> In the above: Ĥ applied to ⟨Ĥ⟩ and the ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H
> vary by exactly one level of indirect reference.

Which has absolutely nothing to do with my point since only *one* of the
above is a computation; Ĥ applied to ⟨Ĥ⟩. The other, ⟨Ĥ⟩ ⟨Ĥ⟩ is a string
which describes a computation, and the computation it describes is Ĥ
applied to ⟨Ĥ⟩ which is the computation which your 'embedded_H' must
answer about.

> embedded_H does not, cannot, and its not supposed to report on the exact
> same computation that contains itself.

Except that the description it has been given as an input *precisely*
describes the "computation that contains itself". So yes, it *is*
supposed to answer about this.

Every "instance" of Ĥ applied to ⟨Ĥ⟩ is identical.

> embedded_H computes the mapping of its input ⟨Ĥ⟩ ⟨Ĥ⟩ a final state of
> embedded_H.
>
>> They are not different 'instances' of some computation. Every
>> "instance" of
>>
>> M ⟨I⟩
>>
>> is the exact same computation. So there is no point in talking about
>> "instances".
>>
>> Do you actually understand what instantiation means?
>>
>> André
>>
>
> What Does Instantiate Mean?
> Instantiate (a verb) and instantiation (the noun) in computer science
> refer to the creation of an object (or an “instance” of a given class)
> in an object-oriented programming (OOP) language. Referencing a class
> declaration, an instantiated object is named and created, in memory or
> on disk.
>
> https://www.techopedia.com/definition/26857/instantiate#:~:text=Instantiate%20(a%20verb)%20and%20instantiation,in%20memory%20or%20on%20disk.

That doesn't answer my question. I asked whether you understood what it
means, not whether you could quote some random website. To demonstrate
the former you'd need to actually coherently explain the concept in your
own words.

What would it mean to create an "instance" of a computation?

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 3/16/2022 3:56 PM, Alan Mackenzie wrote:
> In comp.theory olcott <NoOne@nowhere.com> wrote:
>> On 3/16/2022 12:37 PM, Mike Terry wrote:
>>> On 16/03/2022 17:20, olcott wrote:
>>>> On 3/16/2022 12:04 PM, Mike Terry wrote:
>
> [ .... ]
>
>>>>> I'm afraid that you lack the intellect to understand exactly what
>>>>> other people are saying on technical issues.  How many times have
>>>>> you quoted me (and others here) as supporting something you've
>>>>> claimed, whereas it turns out you had just misunderstood some remark
>>>>> that had been made? [Answer: lots of times!]
>
>>>>> You also have a habit of going elsewhere, and "tricking" the people
>>>>> there into "agreeing" with some claim you've made here by not
>>>>> properly explaining the full context of your claim.  Then you come
>>>>> back here selectively quoting some "expert" to suggest he is
>>>>> supporting you. [Like when you went to the x86 group and showed them
>>>>> your "trace" asking them if they could see what's going on, and got
>>>>> one of them to say "it's looping...".  You failed to mention the
>>>>> trace was not the "processor trace" they would naturally expect, and
>>>>> that there was simulation involved, and that your trace was in fact
>>>>> some kind of "merged simulation trace", and that you were using this
>>>>> trace to disprove the Halting Problem theorem.]
>
>>>>> It's been pointed out to you many times that algorithms exhist that
>>>>> can identify /some/ infinite loops/recursions as such, but no
>>>>> algorithm detects ALL non-halting behaviour.
>
>>>>> And specifically, your test (looking for more than one call to a
>>>>> particular address etc.) is /unsound/ when you try to use it on your
>>>>> "merged simulation" trace.  No expert would say otherwise if they
>>>>> had been given the full context, so probably you've just tricked
>>>>> someone again...
>
>
>>>>> Mike.
>
>>>> None-the-less is is self-evident that the input presented to the copy
>>>> of the Linz H embedded at Ĥ.qx does specify infinitely nested
>>>> simulation to simulating halt decider embedded_H thus proving that a
>>>> transition to Ĥ.qn by embedded_H would be correct.
>
>>> You mean self-evident TO YOU.  To people who have an understanding of
>>> TMs it is simply wrong or meaningless (depending on how tolerant people
>>> are of your wishy-washy phrasing).
>
>
>>> Mike.
>
>
>> They simply dogmatically state that the believe that I am wrong about
>> this yet cannot point to the specific error because there is none:
>
> You pathetic deluded patronising liar. There's no "believe" about it.
> Everybody KNOWS you're wrong. There's a whole group of people who've
> been pointing out specific errors in your ravings for years. You just
> ignore them.
>
>> When Ĥ is applied to ⟨Ĥ⟩
>> Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>
>> Then these steps would keep repeating:
>> Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>> Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>> Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
>
> What has the above got to do with anything? What the heck is
> "embedded_H"? You keep trying to pretend that you are dealing with the
> construction from Linz's book, but in that there is no "embedded_H".
>

embedded_H is the copy of Linz H embedded at Ĥ.qx as a simulating halt
decider that computes the mapping from its input to its own final state
on the basis of the behavior of this simulated input.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final
state.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
final state.

>> The above repeating pattern shows that the correctly simulated input to
>> embedded_H would never reach its final state of ⟨Ĥ⟩.qn conclusively
>> proving that this simulated input never halts. This enables embedded_H
>> to abort its simulation and correctly transition to Ĥ.qn.
>
> You haven't a clue what "prove" means in the mathematical sense, so stop
> abusing the word. You have proven nothing.
>
>> --
>> Copyright 2021 Pete Olcott
>
>> Talent hits a target no one else can hit;
>> Genius hits a target no one else can see.
>> Arthur Schopenhauer
>

--
Copyright 2021 Pete Olcott

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

On 3/16/2022 3:58 PM, André G. Isaak wrote:
> On 2022-03-16 14:22, olcott wrote:
>> On 3/16/2022 3:11 PM, André G. Isaak wrote:
>>> On 2022-03-15 15:44, olcott wrote:
>
> <snip>
>
>>>> A Turing machine UTM that is simulating its own Turing machine
>>>> description is two distinct instances: (executed and simulated) even
>>>> if computer science does not bother to pay attention to this level
>>>> of detail, or have the terminology to express it.
>>>
>>> You're confusing computations and Turing Machines.
>>>
>>> If you pass a UTM a description of itself, it will determine what UTM
>>> applied to an empty tape will do.
>>>
>>> UTM ⟨UTM⟩
>>>
>>> and
>>>
>>> UTM ∅
>>>
>>> are entirely distinct computations.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> In the above: Ĥ applied to ⟨Ĥ⟩ and the ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H
>> vary by exactly one level of indirect reference.
>
> Which has absolutely nothing to do with my point since only *one* of the
> above is a computation; Ĥ applied to ⟨Ĥ⟩. The other, ⟨Ĥ⟩ ⟨Ĥ⟩ is a string
> which describes a computation, and the computation it describes is Ĥ
> applied to ⟨Ĥ⟩ which is the computation which your 'embedded_H' must
> answer about.
>

You can dodge this fact a million times, none-the-less the copy of Linz
H embedded at Ĥ.qx computes the mapping from its input to its own final
state on the basis of the behavior of its correct simulation of this input.

It is an easily verifiable fact that this simulated input would never
reach its own final state in any finite number of steps of simulation.

I will not address any other points until this point is fully addressed.

--
Copyright 2021 Pete Olcott

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