On 9/4/2021 1:04 PM, Alan Mackenzie wrote:
> [ Malicious cross posting snipped. ]
>
> In comp.theory olcott <NoOne@nowhere.com> wrote:
>> In computability theory, the halting problem is the
>> problem of determining, from a description of an arbitrary
>> computer program and an input,
>
>> whether the simulation of this program must be aborted to
>> prevent it from running forever.
>
> No, it is not. There might well not be a simulation of the program.
>
>> The above criteria is ...
>
> Just as a matter of interest, "criteria" is plural. The singular is
> "criterion".
>
>> .... valid on the basis of the known equivalence between the direct
>> execution of a computation and its simulation by a UTM.
>
> Not really. There might well not be a simulation of the program.
>

I am stopping here. If it is impossible to simulate the TM description
of a TM then it is not a proper TM.

>> The same criteria universally works on all inputs allowing their
>> halting status to be correctly decided.
>
> No, they do not. It has been proven that there is no such set of
> criteria (aka a turing machine) that can decide this.
>
>> The Peter Linz H is defined to be a simulating halt decider that applies
>> the above criteria and the halt decider at Ĥ.qx is an exact copy of H.
>
> No. The Peter Linz H doesn't exist. It's existence is posited purely
> to demonstrate the contradiction that proves it cannot exist.
>
> [ .... ]
>
>> The mistake of the Linz proof is forming a conclusion based on Ĥ
>> applied to its own Turing machine description ⟨Ĥ⟩.
>
> No. A universal halt decider would necessarily work correctly on its
> own turing machine description.
>
>> This is only answering the question: Can changes be made to an
>> otherwise correct halt decider such that this halt decider is no
>> longer correct?
>
> Are you talking about a partial halt decider, here? What does
> "otherwise correct" actually mean, here? "Otherwise" than what?
>
>> The required question is: Does the original H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>> correctly decide the halt status of its input?
>
> The correct question was half-stated by you at the top of the post.
> It's is there a turing machine which can decide the halting status of
> any turing machine?
>
> [ .... ]
>
>> The full Linz Proof:
>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>
>> --
>> Copyright 2021 Pete Olcott
>
>> "Great spirits have always encountered violent opposition from mediocre
>> minds." Einstein
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 9/4/21 1:46 PM, olcott wrote:
> On 9/4/2021 12:34 PM, Richard Damon wrote:
>> On 9/4/21 1:21 PM, olcott wrote:
>>> On 9/4/2021 12:13 PM, Richard Damon wrote:
>>>>
>>>>
>>>> He says:
>>>>
>>>> If M enters an infinite loop, then no matter how long we wait, we can
>>>> never be sure that M is in fact in a loop. It may simply be a case of a
>>>> very long computation. What we need is an algorithm that can determine
>>>> the correct answer for any M and w by performing some analysis on the
>>>> machine's description and the input. But as we now show, no such
>>>> algorithm exists.
>>>>
>>>> Thus he recognized that the issue with a simulating decider would be it
>>>
>>> No he recognized the very obvious issue of using a simulator instead of
>>> a decider. No one besides me has ever considered a simulating halt
>>> decider that examines the simulated execution trace for non halting
>>> patterns of behavior.
>>
>> Nope, He understood the issues involved. Maybe if you had studied some
>> of the field you would know that the limitation of Halt Deciding by
>> Simulating are WELL known, and have been shown to be impossible in
>> general.
>>
>
> In the text that you referenced he was only referring to using a
> simulator as a decider. He was not referring to using a simulating
> decider that examines the execution trace of the simulation to look for
> non halting behavior patterns.

Nope, maybe he doesn't explicitly call it that, but his words definitely
reference the well known and studied limitation of simulation for halt
deciding. Maybe the fact that you refuse to study the field means you
don't recognize that, and are dooming yourself to repeating all the
mistakes that have been worked through over the century,

>
>> They can answer some SPECIFIC forms of infinite behavior, but can not in
>> general.
>>
>> I think part of your problem is that YOU don't understand some of the
>> forms that are proven impossible, as shown by your claim that 'ALL' of
>> the proofs of the Halting Problem are based on this one method, which is
>> a demonstratably false statement.
>>
>> It may be the only one you understand, but it isn't the only one.
>>
>
>

On 9/4/21 2:13 PM, olcott wrote:
> On 9/4/2021 1:04 PM, Alan Mackenzie wrote:
>> [ Malicious cross posting snipped. ]
>>
>> In comp.theory olcott <NoOne@nowhere.com> wrote:
>>
>>> .... valid on the basis of the known equivalence between the direct
>>> execution of a computation and its simulation by a UTM.
>>
>> Not really.  There might well not be a simulation of the program.
>>
>
> I am stopping here. If it is impossible to simulate the TM description
> of a TM then it is not a proper TM.

I think he is refering to the fact that you refer to a Theorem about
FULL simulation showing the behavior of the simulated program, but all
you do is a PARTIAL simulation,

There is no equivalent equivalence between the direct execution of a
comptation and its PARTIAL simulation by a partial simulator.

YOUR logic presumes that copies of your decider are actually UTMs, when
they are not. It doesn't matter that they start in a 'pure simulator
mode', it is known that they WILL exit it for this input, so their
analyses must take that into account, which it doesn't. This means that
the transform of the simulation of the simulator to the simulation of
the simulated machine is NOT valid, and can create incorrectly
determined infinite execution.

Since the copies of the decider DON'T act FULLY as a UTM, there is no
full 'simulation' to apply the theorom to.

On 9/4/2021 1:15 PM, Richard Damon wrote:
> On 9/4/21 1:46 PM, olcott wrote:
>> On 9/4/2021 12:34 PM, Richard Damon wrote:
>>> On 9/4/21 1:21 PM, olcott wrote:
>>>> On 9/4/2021 12:13 PM, Richard Damon wrote:
>>>>>
>>>>>
>>>>> He says:
>>>>>
>>>>> If M enters an infinite loop, then no matter how long we wait, we can
>>>>> never be sure that M is in fact in a loop. It may simply be a case of a
>>>>> very long computation. What we need is an algorithm that can determine
>>>>> the correct answer for any M and w by performing some analysis on the
>>>>> machine's description and the input. But as we now show, no such
>>>>> algorithm exists.
>>>>>
>>>>> Thus he recognized that the issue with a simulating decider would be it
>>>>
>>>> No he recognized the very obvious issue of using a simulator instead of
>>>> a decider. No one besides me has ever considered a simulating halt
>>>> decider that examines the simulated execution trace for non halting
>>>> patterns of behavior.
>>>
>>> Nope, He understood the issues involved. Maybe if you had studied some
>>> of the field you would know that the limitation of Halt Deciding by
>>> Simulating are WELL known, and have been shown to be impossible in
>>> general.
>>>
>>
>> In the text that you referenced he was only referring to using a
>> simulator as a decider. He was not referring to using a simulating
>> decider that examines the execution trace of the simulation to look for
>> non halting behavior patterns.
>
> Nope, maybe he doesn't explicitly call it that, but his words definitely
> reference the well known and studied limitation of simulation for halt
> deciding.

Of course. If you want to tell if an infinite loops halts you sure as
Hell can't simply wait and see what happens.

It is getting to the point where I am convinced that you are simply
lying. If you are aware of any source besides me that proposes a
simulating halt decider that specifically examines the execution trace
of its simulation to match non-halting behavior patterns of its input
then PUT UP OR SHUT UP !!!

> Maybe the fact that you refuse to study the field means you
> don't recognize that, and are dooming yourself to repeating all the
> mistakes that have been worked through over the century,

PUT UP OR SHUT UP !!!
PUT UP OR SHUT UP !!!
PUT UP OR SHUT UP !!!
PUT UP OR SHUT UP !!!

>
>>
>>> They can answer some SPECIFIC forms of infinite behavior, but can not in
>>> general.
>>>
>>> I think part of your problem is that YOU don't understand some of the
>>> forms that are proven impossible, as shown by your claim that 'ALL' of
>>> the proofs of the Halting Problem are based on this one method, which is
>>> a demonstratably false statement.
>>>
>>> It may be the only one you understand, but it isn't the only one.
>>>
>>
>>
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

Richard Damon <Richard@Damon-Family.org> writes:

> On 9/4/21 2:13 PM, olcott wrote:
>> On 9/4/2021 1:04 PM, Alan Mackenzie wrote:
>>> [ Malicious cross posting snipped. ]
>>>
>>> In comp.theory olcott <NoOne@nowhere.com> wrote:
>>>
>>>> .... valid on the basis of the known equivalence between the direct
>>>> execution of a computation and its simulation by a UTM.
>>>
>>> Not really.  There might well not be a simulation of the program.
>>
>> I am stopping here. If it is impossible to simulate the TM description
>> of a TM then it is not a proper TM.

I am pretty sure he is referring to the unwarranted assumption that any
simulation at all is involved. The context has been lost, including the
key part that Alan was objecting to:

|| In computability theory, the halting problem is the
|| problem of determining, from a description of an arbitrary
|| computer program and an input,
|| whether the simulation of this program must be aborted to
|| prevent it from running forever.

The phrase "the simulation" implies there is simulation involved. Had
PO written "whether /a/ simulation of this program runs forever" the
reference to simulation would be silly and superfluous, but not wrong.

--
Ben.

On 9/4/21 2:47 PM, olcott wrote:
> On 9/4/2021 1:15 PM, Richard Damon wrote:
>> On 9/4/21 1:46 PM, olcott wrote:
>>> On 9/4/2021 12:34 PM, Richard Damon wrote:
>>>> On 9/4/21 1:21 PM, olcott wrote:
>>>>> On 9/4/2021 12:13 PM, Richard Damon wrote:
>>>>>>
>>>>>>
>>>>>> He says:
>>>>>>
>>>>>> If M enters an infinite loop, then no matter how long we wait, we can
>>>>>> never be sure that M is in fact in a loop. It may simply be a case
>>>>>> of a
>>>>>> very long computation. What we need is an algorithm that can
>>>>>> determine
>>>>>> the correct answer for any M and w by performing some analysis on the
>>>>>> machine's description and the input. But as we now show, no such
>>>>>> algorithm exists.
>>>>>>
>>>>>> Thus he recognized that the issue with a simulating decider would
>>>>>> be it
>>>>>
>>>>> No he recognized the very obvious issue of using a simulator
>>>>> instead of
>>>>> a decider. No one besides me has ever considered a simulating halt
>>>>> decider that examines the simulated execution trace for non halting
>>>>> patterns of behavior.
>>>>
>>>> Nope, He understood the issues involved. Maybe if you had studied some
>>>> of the field you would know that the limitation of Halt Deciding by
>>>> Simulating are WELL known, and have been shown to be impossible in
>>>> general.
>>>>
>>>
>>> In the text that you referenced he was only referring to using a
>>> simulator as a decider. He was not referring to using a simulating
>>> decider that examines the execution trace of the simulation to look for
>>> non halting behavior patterns.
>>
>> Nope, maybe he doesn't explicitly call it that, but his words definitely
>> reference the well known and studied limitation of simulation for halt
>> deciding.
>
> Of course. If you want to tell if an infinite loops halts you sure as
> Hell can't simply wait and see what happens.
>
> It is getting to the point where I am convinced that you are simply
> lying. If you are aware of any source besides me that proposes a
> simulating halt decider that specifically examines the execution trace
> of its simulation to match non-halting behavior patterns of its input
> then PUT UP OR SHUT UP !!!
>

Most of the stuff I know was pre-internet, so not easy to find.

Here is one example of a reference to this from a decade ago:
https://math.stackexchange.com/questions/27606/detecting-cycles-in-off-line-turing-machines

This mentions one of the techniques used for detecting SOME forms of
infinite loops.

Here is another person needing to solve the halting problem for a
limited case, and was given a few examples of classical methods (like
detecting repeating state) to detect an infinite loop.

https://try2explore.com/questions/10671161

And then there is this article on detecting the non-termination of
Turing Machines, to look for solutions to things like the Busy-Beaver
problem:

https://dl.acm.org/doi/pdf/10.5555/1273694.1273703

While not specifically a 'simulating Halt Decider' it is trying to solve
the same basic problem.

>> Maybe the fact that you refuse to study the field means you
>> don't recognize that, and are dooming yourself to repeating all the
>> mistakes that have been worked through over the century,
>
> PUT UP OR SHUT UP !!!
> PUT UP OR SHUT UP !!!
> PUT UP OR SHUT UP !!!
> PUT UP OR SHUT UP !!!

Will you now SHUT UP that NO ONE has looked at this before?
>
>>
>>>
>>>> They can answer some SPECIFIC forms of infinite behavior, but can
>>>> not in
>>>> general.
>>>>
>>>> I think part of your problem is that YOU don't understand some of the
>>>> forms that are proven impossible, as shown by your claim that 'ALL' of
>>>> the proofs of the Halting Problem are based on this one method,
>>>> which is
>>>> a demonstratably false statement.
>>>>
>>>> It may be the only one you understand, but it isn't the only one.
>>>>
>>>
>>>
>>
>
>

On 9/4/2021 3:48 PM, Richard Damon wrote:
> On 9/4/21 2:47 PM, olcott wrote:
>> On 9/4/2021 1:15 PM, Richard Damon wrote:
>>> On 9/4/21 1:46 PM, olcott wrote:
>>>> On 9/4/2021 12:34 PM, Richard Damon wrote:
>>>>> On 9/4/21 1:21 PM, olcott wrote:
>>>>>> On 9/4/2021 12:13 PM, Richard Damon wrote:
>>>>>>>
>>>>>>>
>>>>>>> He says:
>>>>>>>
>>>>>>> If M enters an infinite loop, then no matter how long we wait, we can
>>>>>>> never be sure that M is in fact in a loop. It may simply be a case
>>>>>>> of a
>>>>>>> very long computation. What we need is an algorithm that can
>>>>>>> determine
>>>>>>> the correct answer for any M and w by performing some analysis on the
>>>>>>> machine's description and the input. But as we now show, no such
>>>>>>> algorithm exists.
>>>>>>>
>>>>>>> Thus he recognized that the issue with a simulating decider would
>>>>>>> be it
>>>>>>
>>>>>> No he recognized the very obvious issue of using a simulator
>>>>>> instead of
>>>>>> a decider. No one besides me has ever considered a simulating halt
>>>>>> decider that examines the simulated execution trace for non halting
>>>>>> patterns of behavior.
>>>>>
>>>>> Nope, He understood the issues involved. Maybe if you had studied some
>>>>> of the field you would know that the limitation of Halt Deciding by
>>>>> Simulating are WELL known, and have been shown to be impossible in
>>>>> general.
>>>>>
>>>>
>>>> In the text that you referenced he was only referring to using a
>>>> simulator as a decider. He was not referring to using a simulating
>>>> decider that examines the execution trace of the simulation to look for
>>>> non halting behavior patterns.
>>>
>>> Nope, maybe he doesn't explicitly call it that, but his words definitely
>>> reference the well known and studied limitation of simulation for halt
>>> deciding.
>>
>> Of course. If you want to tell if an infinite loops halts you sure as
>> Hell can't simply wait and see what happens.
>>
>> It is getting to the point where I am convinced that you are simply
>> lying. If you are aware of any source besides me that proposes a
>> simulating halt decider that specifically examines the execution trace
>> of its simulation to match non-halting behavior patterns of its input
>> then PUT UP OR SHUT UP !!!
>>
>
> Most of the stuff I know was pre-internet, so not easy to find.
>
> Here is one example of a reference to this from a decade ago:
> https://math.stackexchange.com/questions/27606/detecting-cycles-in-off-line-turing-machines
>
> This mentions one of the techniques used for detecting SOME forms of
> infinite loops.
>
> Here is another person needing to solve the halting problem for a
> limited case, and was given a few examples of classical methods (like
> detecting repeating state) to detect an infinite loop.
>
> https://try2explore.com/questions/10671161
>
> And then there is this article on detecting the non-termination of
> Turing Machines, to look for solutions to things like the Busy-Beaver
> problem:
>
> https://dl.acm.org/doi/pdf/10.5555/1273694.1273703
>
> While not specifically a 'simulating Halt Decider' it is trying to solve
> the same basic problem.
>
>>> Maybe the fact that you refuse to study the field means you
>>> don't recognize that, and are dooming yourself to repeating all the
>>> mistakes that have been worked through over the century,
>>
>> PUT UP OR SHUT UP !!!
>> PUT UP OR SHUT UP !!!
>> PUT UP OR SHUT UP !!!
>> PUT UP OR SHUT UP !!!
>
> Will you now SHUT UP that NO ONE has looked at this before?

My original words included to the same extent that I have.

None-the-less is seems clear that you now do understand that when Linz
referred to a UTM he was only referring to using a UTM as a halt
decider, not using a hybrid UTM halt decider that examines the execution
trace of its input.

>>
>>>
>>>>
>>>>> They can answer some SPECIFIC forms of infinite behavior, but can
>>>>> not in
>>>>> general.
>>>>>
>>>>> I think part of your problem is that YOU don't understand some of the
>>>>> forms that are proven impossible, as shown by your claim that 'ALL' of
>>>>> the proofs of the Halting Problem are based on this one method,
>>>>> which is
>>>>> a demonstratably false statement.
>>>>>
>>>>> It may be the only one you understand, but it isn't the only one.
>>>>>
>>>>
>>>>
>>>
>>
>>
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

olcott <NoOne@NoWhere.com> writes:

> On 9/4/2021 3:48 PM, Richard Damon wrote:
>> On 9/4/21 2:47 PM, olcott wrote:
>>> On 9/4/2021 1:15 PM, Richard Damon wrote:

>>>> Maybe the fact that you refuse to study the field means you
>>>> don't recognize that, and are dooming yourself to repeating all the
>>>> mistakes that have been worked through over the century,
>>>
>>> PUT UP OR SHUT UP !!!
>>> PUT UP OR SHUT UP !!!
>>> PUT UP OR SHUT UP !!!
>>> PUT UP OR SHUT UP !!!

<examples posted>

>> Will you now SHUT UP that NO ONE has looked at this before?
>
> My original words included to the same extent that I have.

Ah, well, you are on pretty safe ground there as it's hard to imagine
anyone publishing as shallow an analysis of loop detection as you have
posted here.

--
Ben.

olcott <NoOne@NoWhere.com> writes:

> The Peter Linz H is defined to be a simulating halt decider...

No. Unsurprisingly, you can find the definition in Linz, should you
wish to become better informed.

--
Ben.

On 9/4/21 4:59 PM, olcott wrote:
> On 9/4/2021 3:48 PM, Richard Damon wrote:
>> On 9/4/21 2:47 PM, olcott wrote:
>>> On 9/4/2021 1:15 PM, Richard Damon wrote:
>>>> On 9/4/21 1:46 PM, olcott wrote:
>>>>> On 9/4/2021 12:34 PM, Richard Damon wrote:
>>>>>> On 9/4/21 1:21 PM, olcott wrote:
>>>>>>> On 9/4/2021 12:13 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> He says:
>>>>>>>>
>>>>>>>> If M enters an infinite loop, then no matter how long we wait,
>>>>>>>> we can
>>>>>>>> never be sure that M is in fact in a loop. It may simply be a case
>>>>>>>> of a
>>>>>>>> very long computation. What we need is an algorithm that can
>>>>>>>> determine
>>>>>>>> the correct answer for any M and w by performing some analysis
>>>>>>>> on the
>>>>>>>> machine's description and the input. But as we now show, no such
>>>>>>>> algorithm exists.
>>>>>>>>
>>>>>>>> Thus he recognized that the issue with a simulating decider would
>>>>>>>> be it
>>>>>>>
>>>>>>> No he recognized the very obvious issue of using a simulator
>>>>>>> instead of
>>>>>>> a decider. No one besides me has ever considered a simulating halt
>>>>>>> decider that examines the simulated execution trace for non halting
>>>>>>> patterns of behavior.
>>>>>>
>>>>>> Nope, He understood the issues involved. Maybe if you had studied
>>>>>> some
>>>>>> of the field you would know that the limitation of Halt Deciding by
>>>>>> Simulating are WELL known, and have been shown to be impossible in
>>>>>> general.
>>>>>>
>>>>>
>>>>> In the text that you referenced he was only referring to using a
>>>>> simulator as a decider. He was not referring to using a simulating
>>>>> decider that examines the execution trace of the simulation to look
>>>>> for
>>>>> non halting behavior patterns.
>>>>
>>>> Nope, maybe he doesn't explicitly call it that, but his words
>>>> definitely
>>>> reference the well known and studied limitation of simulation for halt
>>>> deciding.
>>>
>>> Of course. If you want to tell if an infinite loops halts you sure as
>>> Hell can't simply wait and see what happens.
>>>
>>> It is getting to the point where I am convinced that you are simply
>>> lying. If you are aware of any source besides me that proposes a
>>> simulating halt decider that specifically examines the execution trace
>>> of its simulation to match non-halting behavior patterns of its input
>>> then PUT UP OR SHUT UP !!!
>>>
>>
>> Most of the stuff I know was pre-internet, so not easy to find.
>>
>> Here is one example of a reference to this from a decade ago:
>> https://math.stackexchange.com/questions/27606/detecting-cycles-in-off-line-turing-machines
>>
>>
>> This mentions one of the techniques used for detecting SOME forms of
>> infinite loops.
>>
>> Here is another person needing to solve the halting problem for a
>> limited case, and was given a few examples of classical methods (like
>> detecting repeating state) to detect an infinite loop.
>>
>> https://try2explore.com/questions/10671161
>>
>> And then there is this article on detecting the non-termination of
>> Turing Machines, to look for solutions to things like the Busy-Beaver
>> problem:
>>
>> https://dl.acm.org/doi/pdf/10.5555/1273694.1273703
>>
>> While not specifically a 'simulating Halt Decider' it is trying to solve
>> the same basic problem.
>>
>>>> Maybe the fact that you refuse to study the field means you
>>>> don't recognize that, and are dooming yourself to repeating all the
>>>> mistakes that have been worked through over the century,
>>>
>>> PUT UP OR SHUT UP !!!
>>> PUT UP OR SHUT UP !!!
>>> PUT UP OR SHUT UP !!!
>>> PUT UP OR SHUT UP !!!
>>
>> Will you now SHUT UP that NO ONE has looked at this before?
>
> My original words included to the same extent that I have.
>
> None-the-less is seems clear that you now do understand that when Linz
> referred to a UTM he was only referring to using a UTM as a halt
> decider, not using a hybrid UTM halt decider that examines the execution
> trace of its input.
>

Nope, because I remember when I was in school, it was already
established that Simulating Halt Deciding did not show much promise as
there were serious limits as to what you could detect. Linz knew that
and knew that mentiones in passing that it couldn't know enough to make
the decision.

Also, since he proved it for ALL Halt deciders, he proved it for
Simulating Halt Deciders, as those are within the class of Halt
Deciders, and can't do anything that a 'generic' Halt Decider can't do.

>>>
>>>>
>>>>>
>>>>>> They can answer some SPECIFIC forms of infinite behavior, but can
>>>>>> not in
>>>>>> general.
>>>>>>
>>>>>> I think part of your problem is that YOU don't understand some of the
>>>>>> forms that are proven impossible, as shown by your claim that
>>>>>> 'ALL' of
>>>>>> the proofs of the Halting Problem are based on this one method,
>>>>>> which is
>>>>>> a demonstratably false statement.
>>>>>>
>>>>>> It may be the only one you understand, but it isn't the only one.
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>

On 9/4/2021 5:01 PM, Richard Damon wrote:
> On 9/4/21 4:59 PM, olcott wrote:
>> On 9/4/2021 3:48 PM, Richard Damon wrote:
>>> On 9/4/21 2:47 PM, olcott wrote:
>>>> On 9/4/2021 1:15 PM, Richard Damon wrote:
>>>>> On 9/4/21 1:46 PM, olcott wrote:
>>>>>> On 9/4/2021 12:34 PM, Richard Damon wrote:
>>>>>>> On 9/4/21 1:21 PM, olcott wrote:
>>>>>>>> On 9/4/2021 12:13 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> He says:
>>>>>>>>>
>>>>>>>>> If M enters an infinite loop, then no matter how long we wait,
>>>>>>>>> we can
>>>>>>>>> never be sure that M is in fact in a loop. It may simply be a case
>>>>>>>>> of a
>>>>>>>>> very long computation. What we need is an algorithm that can
>>>>>>>>> determine
>>>>>>>>> the correct answer for any M and w by performing some analysis
>>>>>>>>> on the
>>>>>>>>> machine's description and the input. But as we now show, no such
>>>>>>>>> algorithm exists.
>>>>>>>>>
>>>>>>>>> Thus he recognized that the issue with a simulating decider would
>>>>>>>>> be it
>>>>>>>>
>>>>>>>> No he recognized the very obvious issue of using a simulator
>>>>>>>> instead of
>>>>>>>> a decider. No one besides me has ever considered a simulating halt
>>>>>>>> decider that examines the simulated execution trace for non halting
>>>>>>>> patterns of behavior.
>>>>>>>
>>>>>>> Nope, He understood the issues involved. Maybe if you had studied
>>>>>>> some
>>>>>>> of the field you would know that the limitation of Halt Deciding by
>>>>>>> Simulating are WELL known, and have been shown to be impossible in
>>>>>>> general.
>>>>>>>
>>>>>>
>>>>>> In the text that you referenced he was only referring to using a
>>>>>> simulator as a decider. He was not referring to using a simulating
>>>>>> decider that examines the execution trace of the simulation to look
>>>>>> for
>>>>>> non halting behavior patterns.
>>>>>
>>>>> Nope, maybe he doesn't explicitly call it that, but his words
>>>>> definitely
>>>>> reference the well known and studied limitation of simulation for halt
>>>>> deciding.
>>>>
>>>> Of course. If you want to tell if an infinite loops halts you sure as
>>>> Hell can't simply wait and see what happens.
>>>>
>>>> It is getting to the point where I am convinced that you are simply
>>>> lying. If you are aware of any source besides me that proposes a
>>>> simulating halt decider that specifically examines the execution trace
>>>> of its simulation to match non-halting behavior patterns of its input
>>>> then PUT UP OR SHUT UP !!!
>>>>
>>>
>>> Most of the stuff I know was pre-internet, so not easy to find.
>>>
>>> Here is one example of a reference to this from a decade ago:
>>> https://math.stackexchange.com/questions/27606/detecting-cycles-in-off-line-turing-machines
>>>
>>>
>>> This mentions one of the techniques used for detecting SOME forms of
>>> infinite loops.
>>>
>>> Here is another person needing to solve the halting problem for a
>>> limited case, and was given a few examples of classical methods (like
>>> detecting repeating state) to detect an infinite loop.
>>>
>>> https://try2explore.com/questions/10671161
>>>
>>> And then there is this article on detecting the non-termination of
>>> Turing Machines, to look for solutions to things like the Busy-Beaver
>>> problem:
>>>
>>> https://dl.acm.org/doi/pdf/10.5555/1273694.1273703
>>>
>>> While not specifically a 'simulating Halt Decider' it is trying to solve
>>> the same basic problem.
>>>
>>>>> Maybe the fact that you refuse to study the field means you
>>>>> don't recognize that, and are dooming yourself to repeating all the
>>>>> mistakes that have been worked through over the century,
>>>>
>>>> PUT UP OR SHUT UP !!!
>>>> PUT UP OR SHUT UP !!!
>>>> PUT UP OR SHUT UP !!!
>>>> PUT UP OR SHUT UP !!!
>>>
>>> Will you now SHUT UP that NO ONE has looked at this before?
>>
>> My original words included to the same extent that I have.
>>
>> None-the-less is seems clear that you now do understand that when Linz
>> referred to a UTM he was only referring to using a UTM as a halt
>> decider, not using a hybrid UTM halt decider that examines the execution
>> trace of its input.
>>
>
> Nope, because I remember when I was in school, it was already
> established that Simulating Halt Deciding did not show much promise as
> there were serious limits as to what you could detect. Linz knew that
> and knew that mentiones in passing that it couldn't know enough to make
> the decision.
>
> Also, since he proved it for ALL Halt deciders, he proved it for
> Simulating Halt Deciders, as those are within the class of Halt
> Deciders, and can't do anything that a 'generic' Halt Decider can't do.
>

None-the-less int main() { H1(P,P); } does correctly report that its
input halts on the basis that H(P,P) does correctly report that its
input never halts.

If you knew the x86 language and software engineering well enough you
would know that the following execution trace of the simulation of P(P)
matches the infinite recursion behavior pattern and you would know that
the infinite recursion behavior pattern is correct.

THAT YOU SIMPLY DON'T KNOW THESE THINGS WELL ENOUGH IS PROVEN BY THE
FACT THAT YOU ALWAYS CHANGE THE SUBJECT INSTEAD OF DIRECT POINTING OUT
ANY ERROR

Begin Local Halt Decider Simulation at Machine Address:c36
[00000c36][002117ca][002117ce] 55 push ebp
[00000c37][002117ca][002117ce] 8bec mov ebp,esp
[00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
[00000c3c][002117c6][00000c36] 50 push eax // push P
[00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][002117c2][00000c36] 51 push ecx // push P
[00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)

[00000c36][0025c1f2][0025c1f6] 55 push ebp
[00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp
[00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08]
[00000c3c][0025c1ee][00000c36] 50 push eax // push P
[00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][0025c1ea][00000c36] 51 push ecx // push P
[00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

This infinite recursion detection criteria are met by the above
execution trace:
(a) P calls H twice in sequence from the same machine address.
(b) With the same parameters: (P,P) to H.
(c) With no conditional branch or indexed jump instructions in the
execution trace of P.
(d) We know that there are no return instructions in H because we know
that H is in pure simulation mode.

>>>>
>>>>>
>>>>>>
>>>>>>> They can answer some SPECIFIC forms of infinite behavior, but can
>>>>>>> not in
>>>>>>> general.
>>>>>>>
>>>>>>> I think part of your problem is that YOU don't understand some of the
>>>>>>> forms that are proven impossible, as shown by your claim that
>>>>>>> 'ALL' of
>>>>>>> the proofs of the Halting Problem are based on this one method,
>>>>>>> which is
>>>>>>> a demonstratably false statement.
>>>>>>>
>>>>>>> It may be the only one you understand, but it isn't the only one.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>

On 9/4/21 6:15 PM, olcott wrote:
> On 9/4/2021 5:01 PM, Richard Damon wrote:
>> On 9/4/21 4:59 PM, olcott wrote:
>>> On 9/4/2021 3:48 PM, Richard Damon wrote:
>>>> On 9/4/21 2:47 PM, olcott wrote:
>>>>> On 9/4/2021 1:15 PM, Richard Damon wrote:
>>>>>> On 9/4/21 1:46 PM, olcott wrote:
>>>>>>> On 9/4/2021 12:34 PM, Richard Damon wrote:
>>>>>>>> On 9/4/21 1:21 PM, olcott wrote:
>>>>>>>>> On 9/4/2021 12:13 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> He says:
>>>>>>>>>>
>>>>>>>>>> If M enters an infinite loop, then no matter how long we wait,
>>>>>>>>>> we can
>>>>>>>>>> never be sure that M is in fact in a loop. It may simply be a
>>>>>>>>>> case
>>>>>>>>>> of a
>>>>>>>>>> very long computation. What we need is an algorithm that can
>>>>>>>>>> determine
>>>>>>>>>> the correct answer for any M and w by performing some analysis
>>>>>>>>>> on the
>>>>>>>>>> machine's description and the input. But as we now show, no such
>>>>>>>>>> algorithm exists.
>>>>>>>>>>
>>>>>>>>>> Thus he recognized that the issue with a simulating decider would
>>>>>>>>>> be it
>>>>>>>>>
>>>>>>>>> No he recognized the very obvious issue of using a simulator
>>>>>>>>> instead of
>>>>>>>>> a decider. No one besides me has ever considered a simulating halt
>>>>>>>>> decider that examines the simulated execution trace for non
>>>>>>>>> halting
>>>>>>>>> patterns of behavior.
>>>>>>>>
>>>>>>>> Nope, He understood the issues involved. Maybe if you had studied
>>>>>>>> some
>>>>>>>> of the field you would know that the limitation of Halt Deciding by
>>>>>>>> Simulating are WELL known, and have been shown to be impossible in
>>>>>>>> general.
>>>>>>>>
>>>>>>>
>>>>>>> In the text that you referenced he was only referring to using a
>>>>>>> simulator as a decider. He was not referring to using a simulating
>>>>>>> decider that examines the execution trace of the simulation to look
>>>>>>> for
>>>>>>> non halting behavior patterns.
>>>>>>
>>>>>> Nope, maybe he doesn't explicitly call it that, but his words
>>>>>> definitely
>>>>>> reference the well known and studied limitation of simulation for
>>>>>> halt
>>>>>> deciding.
>>>>>
>>>>> Of course. If you want to tell if an infinite loops halts you sure as
>>>>> Hell can't simply wait and see what happens.
>>>>>
>>>>> It is getting to the point where I am convinced that you are simply
>>>>> lying. If you are aware of any source besides me that proposes a
>>>>> simulating halt decider that specifically examines the execution trace
>>>>> of its simulation to match non-halting behavior patterns of its input
>>>>> then PUT UP OR SHUT UP !!!
>>>>>
>>>>
>>>> Most of the stuff I know was pre-internet, so not easy to find.
>>>>
>>>> Here is one example of a reference to this from a decade ago:
>>>> https://math.stackexchange.com/questions/27606/detecting-cycles-in-off-line-turing-machines
>>>>
>>>>
>>>>
>>>> This mentions one of the techniques used for detecting SOME forms of
>>>> infinite loops.
>>>>
>>>> Here is another person needing to solve the halting problem for a
>>>> limited case, and was given a few examples of classical methods (like
>>>> detecting repeating state) to detect an infinite loop.
>>>>
>>>> https://try2explore.com/questions/10671161
>>>>
>>>> And then there is this article on detecting the non-termination of
>>>> Turing Machines, to look for solutions to things like the Busy-Beaver
>>>> problem:
>>>>
>>>> https://dl.acm.org/doi/pdf/10.5555/1273694.1273703
>>>>
>>>> While not specifically a 'simulating Halt Decider' it is trying to
>>>> solve
>>>> the same basic problem.
>>>>
>>>>>> Maybe the fact that you refuse to study the field means you
>>>>>> don't recognize that, and are dooming yourself to repeating all the
>>>>>> mistakes that have been worked through over the century,
>>>>>
>>>>> PUT UP OR SHUT UP !!!
>>>>> PUT UP OR SHUT UP !!!
>>>>> PUT UP OR SHUT UP !!!
>>>>> PUT UP OR SHUT UP !!!
>>>>
>>>> Will you now SHUT UP that NO ONE has looked at this before?
>>>
>>> My original words included to the same extent that I have.
>>>
>>> None-the-less is seems clear that you now do understand that when Linz
>>> referred to a UTM he was only referring to using a UTM as a halt
>>> decider, not using a hybrid UTM halt decider that examines the execution
>>> trace of its input.
>>>
>>
>> Nope, because I remember when I was in school, it was already
>> established that Simulating Halt Deciding did not show much promise as
>> there were serious limits as to what you could detect. Linz knew that
>> and knew that mentiones in passing that it couldn't know enough to make
>> the decision.
>>
>> Also, since he proved it for ALL Halt deciders, he proved it for
>> Simulating Halt Deciders, as those are within the class of Halt
>> Deciders, and can't do anything that a 'generic' Halt Decider can't do.
>>
>
> None-the-less int main() { H1(P,P); } does correctly report that its
> input halts on the basis that H(P,P) does correctly report that its
> input never halts.
>

But since H^ was built on H, it is H that needs to get the answer right,
not H1, and it doesn't

If you want to claim that they are the same machine, you need to explain
how they give different answers for the same input, which shows they are
Computations.

> If you knew the x86 language and software engineering well enough you
> would know that the following execution trace of the simulation of P(P)
> matches the infinite recursion behavior pattern and you would know that
> the infinite recursion behavior pattern is correct.
>

Nope, since it skips over the CONDITIONAL code of H.

That code needs to be traced and shown to be unconditional.

> THAT YOU SIMPLY DON'T KNOW THESE THINGS WELL ENOUGH IS PROVEN BY THE
> FACT THAT YOU ALWAYS CHANGE THE SUBJECT INSTEAD OF DIRECT POINTING OUT
> ANY ERROR
>

WRONG. I keep pointing out that you build your arguement on false
foundations.

> Begin Local Halt Decider Simulation at Machine Address:c36
> [00000c36][002117ca][002117ce] 55          push ebp
> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
> [00000c3c][002117c6][00000c36] 50          push eax       // push P
> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][002117c2][00000c36] 51          push ecx       // push P
> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>
> [00000c36][0025c1f2][0025c1f6] 55          push ebp
> [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
> [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
> [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
> [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
> [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call H(P,P)
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> This infinite recursion detection criteria are met by the above
> execution trace:
> (a) P calls H twice in sequence from the same machine address.
> (b) With the same parameters: (P,P) to H.
> (c) With no conditional branch or indexed jump instructions in the
> execution trace of P.

On 9/4/2021 5:39 PM, Richard Damon wrote:
> On 9/4/21 6:15 PM, olcott wrote:
>> On 9/4/2021 5:01 PM, Richard Damon wrote:
>>> On 9/4/21 4:59 PM, olcott wrote:
>>>> On 9/4/2021 3:48 PM, Richard Damon wrote:
>>>>> On 9/4/21 2:47 PM, olcott wrote:
>>>>>> On 9/4/2021 1:15 PM, Richard Damon wrote:
>>>>>>> On 9/4/21 1:46 PM, olcott wrote:
>>>>>>>> On 9/4/2021 12:34 PM, Richard Damon wrote:
>>>>>>>>> On 9/4/21 1:21 PM, olcott wrote:
>>>>>>>>>> On 9/4/2021 12:13 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> He says:
>>>>>>>>>>>
>>>>>>>>>>> If M enters an infinite loop, then no matter how long we wait,
>>>>>>>>>>> we can
>>>>>>>>>>> never be sure that M is in fact in a loop. It may simply be a
>>>>>>>>>>> case
>>>>>>>>>>> of a
>>>>>>>>>>> very long computation. What we need is an algorithm that can
>>>>>>>>>>> determine
>>>>>>>>>>> the correct answer for any M and w by performing some analysis
>>>>>>>>>>> on the
>>>>>>>>>>> machine's description and the input. But as we now show, no such
>>>>>>>>>>> algorithm exists.
>>>>>>>>>>>
>>>>>>>>>>> Thus he recognized that the issue with a simulating decider would
>>>>>>>>>>> be it
>>>>>>>>>>
>>>>>>>>>> No he recognized the very obvious issue of using a simulator
>>>>>>>>>> instead of
>>>>>>>>>> a decider. No one besides me has ever considered a simulating halt
>>>>>>>>>> decider that examines the simulated execution trace for non
>>>>>>>>>> halting
>>>>>>>>>> patterns of behavior.
>>>>>>>>>
>>>>>>>>> Nope, He understood the issues involved. Maybe if you had studied
>>>>>>>>> some
>>>>>>>>> of the field you would know that the limitation of Halt Deciding by
>>>>>>>>> Simulating are WELL known, and have been shown to be impossible in
>>>>>>>>> general.
>>>>>>>>>
>>>>>>>>
>>>>>>>> In the text that you referenced he was only referring to using a
>>>>>>>> simulator as a decider. He was not referring to using a simulating
>>>>>>>> decider that examines the execution trace of the simulation to look
>>>>>>>> for
>>>>>>>> non halting behavior patterns.
>>>>>>>
>>>>>>> Nope, maybe he doesn't explicitly call it that, but his words
>>>>>>> definitely
>>>>>>> reference the well known and studied limitation of simulation for
>>>>>>> halt
>>>>>>> deciding.
>>>>>>
>>>>>> Of course. If you want to tell if an infinite loops halts you sure as
>>>>>> Hell can't simply wait and see what happens.
>>>>>>
>>>>>> It is getting to the point where I am convinced that you are simply
>>>>>> lying. If you are aware of any source besides me that proposes a
>>>>>> simulating halt decider that specifically examines the execution trace
>>>>>> of its simulation to match non-halting behavior patterns of its input
>>>>>> then PUT UP OR SHUT UP !!!
>>>>>>
>>>>>
>>>>> Most of the stuff I know was pre-internet, so not easy to find.
>>>>>
>>>>> Here is one example of a reference to this from a decade ago:
>>>>> https://math.stackexchange.com/questions/27606/detecting-cycles-in-off-line-turing-machines
>>>>>
>>>>>
>>>>>
>>>>> This mentions one of the techniques used for detecting SOME forms of
>>>>> infinite loops.
>>>>>
>>>>> Here is another person needing to solve the halting problem for a
>>>>> limited case, and was given a few examples of classical methods (like
>>>>> detecting repeating state) to detect an infinite loop.
>>>>>
>>>>> https://try2explore.com/questions/10671161
>>>>>
>>>>> And then there is this article on detecting the non-termination of
>>>>> Turing Machines, to look for solutions to things like the Busy-Beaver
>>>>> problem:
>>>>>
>>>>> https://dl.acm.org/doi/pdf/10.5555/1273694.1273703
>>>>>
>>>>> While not specifically a 'simulating Halt Decider' it is trying to
>>>>> solve
>>>>> the same basic problem.
>>>>>
>>>>>>> Maybe the fact that you refuse to study the field means you
>>>>>>> don't recognize that, and are dooming yourself to repeating all the
>>>>>>> mistakes that have been worked through over the century,
>>>>>>
>>>>>> PUT UP OR SHUT UP !!!
>>>>>> PUT UP OR SHUT UP !!!
>>>>>> PUT UP OR SHUT UP !!!
>>>>>> PUT UP OR SHUT UP !!!
>>>>>
>>>>> Will you now SHUT UP that NO ONE has looked at this before?
>>>>
>>>> My original words included to the same extent that I have.
>>>>
>>>> None-the-less is seems clear that you now do understand that when Linz
>>>> referred to a UTM he was only referring to using a UTM as a halt
>>>> decider, not using a hybrid UTM halt decider that examines the execution
>>>> trace of its input.
>>>>
>>>
>>> Nope, because I remember when I was in school, it was already
>>> established that Simulating Halt Deciding did not show much promise as
>>> there were serious limits as to what you could detect. Linz knew that
>>> and knew that mentiones in passing that it couldn't know enough to make
>>> the decision.
>>>
>>> Also, since he proved it for ALL Halt deciders, he proved it for
>>> Simulating Halt Deciders, as those are within the class of Halt
>>> Deciders, and can't do anything that a 'generic' Halt Decider can't do.
>>>
>>
>> None-the-less int main() { H1(P,P); } does correctly report that its
>> input halts on the basis that H(P,P) does correctly report that its
>> input never halts.
>>
>
> But since H^ was built on H, it is H that needs to get the answer right,
> not H1, and it doesn't
>
> If you want to claim that they are the same machine, you need to explain
> how they give different answers for the same input, which shows they are
> Computations.
>
>> If you knew the x86 language and software engineering well enough you
>> would know that the following execution trace of the simulation of P(P)
>> matches the infinite recursion behavior pattern and you would know that
>> the infinite recursion behavior pattern is correct.
>>
>
> Nope, since it skips over the CONDITIONAL code of H.
>
> That code needs to be traced and shown to be unconditional.
>
>> THAT YOU SIMPLY DON'T KNOW THESE THINGS WELL ENOUGH IS PROVEN BY THE
>> FACT THAT YOU ALWAYS CHANGE THE SUBJECT INSTEAD OF DIRECT POINTING OUT
>> ANY ERROR
>>
>
> WRONG. I keep pointing out that you build your arguement on false
> foundations.
> >
>> Begin Local Halt Decider Simulation at Machine Address:c36
>> [00000c36][002117ca][002117ce] 55          push ebp
>> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
>> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
>> [00000c3c][002117c6][00000c36] 50          push eax       // push P
>> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
>> [00000c40][002117c2][00000c36] 51          push ecx       // push P
>> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>>
>> [00000c36][0025c1f2][0025c1f6] 55          push ebp
>> [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
>> [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
>> [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
>> [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
>> [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
>> [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call H(P,P)
>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>
>> This infinite recursion detection criteria are met by the above
>> execution trace:
>> (a) P calls H twice in sequence from the same machine address.
>> (b) With the same parameters: (P,P) to H.
>> (c) With no conditional branch or indexed jump instructions in the
>> execution trace of P.
>
> Only because the trace is incorrect.
>
>> (d) We know that there are no return instructions in H because we know
>> that H is in pure simulation mode.
>
>
> The H can NEVER answer even as a top level machine, so THAT is false too.
>
> Remember there is no such thing a 'Pure Simulator Mode', something is or
> it isn't a Pure Simulator. H isn't if it ever answer H(H^,H^)

On 9/4/21 6:52 PM, olcott wrote:
> On 9/4/2021 5:39 PM, Richard Damon wrote:
>> On 9/4/21 6:15 PM, olcott wrote:
>>> On 9/4/2021 5:01 PM, Richard Damon wrote:
>>>> On 9/4/21 4:59 PM, olcott wrote:
>>>>> On 9/4/2021 3:48 PM, Richard Damon wrote:
>>>>>> On 9/4/21 2:47 PM, olcott wrote:
>>>>>>> On 9/4/2021 1:15 PM, Richard Damon wrote:
>>>>>>>> On 9/4/21 1:46 PM, olcott wrote:
>>>>>>>>> On 9/4/2021 12:34 PM, Richard Damon wrote:
>>>>>>>>>> On 9/4/21 1:21 PM, olcott wrote:
>>>>>>>>>>> On 9/4/2021 12:13 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> He says:
>>>>>>>>>>>>
>>>>>>>>>>>> If M enters an infinite loop, then no matter how long we wait,
>>>>>>>>>>>> we can
>>>>>>>>>>>> never be sure that M is in fact in a loop. It may simply be a
>>>>>>>>>>>> case
>>>>>>>>>>>> of a
>>>>>>>>>>>> very long computation. What we need is an algorithm that can
>>>>>>>>>>>> determine
>>>>>>>>>>>> the correct answer for any M and w by performing some analysis
>>>>>>>>>>>> on the
>>>>>>>>>>>> machine's description and the input. But as we now show, no
>>>>>>>>>>>> such
>>>>>>>>>>>> algorithm exists.
>>>>>>>>>>>>
>>>>>>>>>>>> Thus he recognized that the issue with a simulating decider
>>>>>>>>>>>> would
>>>>>>>>>>>> be it
>>>>>>>>>>>
>>>>>>>>>>> No he recognized the very obvious issue of using a simulator
>>>>>>>>>>> instead of
>>>>>>>>>>> a decider. No one besides me has ever considered a simulating
>>>>>>>>>>> halt
>>>>>>>>>>> decider that examines the simulated execution trace for non
>>>>>>>>>>> halting
>>>>>>>>>>> patterns of behavior.
>>>>>>>>>>
>>>>>>>>>> Nope, He understood the issues involved. Maybe if you had studied
>>>>>>>>>> some
>>>>>>>>>> of the field you would know that the limitation of Halt
>>>>>>>>>> Deciding by
>>>>>>>>>> Simulating are WELL known, and have been shown to be
>>>>>>>>>> impossible in
>>>>>>>>>> general.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In the text that you referenced he was only referring to using a
>>>>>>>>> simulator as a decider. He was not referring to using a simulating
>>>>>>>>> decider that examines the execution trace of the simulation to
>>>>>>>>> look
>>>>>>>>> for
>>>>>>>>> non halting behavior patterns.
>>>>>>>>
>>>>>>>> Nope, maybe he doesn't explicitly call it that, but his words
>>>>>>>> definitely
>>>>>>>> reference the well known and studied limitation of simulation for
>>>>>>>> halt
>>>>>>>> deciding.
>>>>>>>
>>>>>>> Of course. If you want to tell if an infinite loops halts you
>>>>>>> sure as
>>>>>>> Hell can't simply wait and see what happens.
>>>>>>>
>>>>>>> It is getting to the point where I am convinced that you are simply
>>>>>>> lying. If you are aware of any source besides me that proposes a
>>>>>>> simulating halt decider that specifically examines the execution
>>>>>>> trace
>>>>>>> of its simulation to match non-halting behavior patterns of its
>>>>>>> input
>>>>>>> then PUT UP OR SHUT UP !!!
>>>>>>>
>>>>>>
>>>>>> Most of the stuff I know was pre-internet, so not easy to find.
>>>>>>
>>>>>> Here is one example of a reference to this from a decade ago:
>>>>>> https://math.stackexchange.com/questions/27606/detecting-cycles-in-off-line-turing-machines
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> This mentions one of the techniques used for detecting SOME forms of
>>>>>> infinite loops.
>>>>>>
>>>>>> Here is another person needing to solve the halting problem for a
>>>>>> limited case, and was given a few examples of classical methods (like
>>>>>> detecting repeating state) to detect an infinite loop.
>>>>>>
>>>>>> https://try2explore.com/questions/10671161
>>>>>>
>>>>>> And then there is this article on detecting the non-termination of
>>>>>> Turing Machines, to look for solutions to things like the Busy-Beaver
>>>>>> problem:
>>>>>>
>>>>>> https://dl.acm.org/doi/pdf/10.5555/1273694.1273703
>>>>>>
>>>>>> While not specifically a 'simulating Halt Decider' it is trying to
>>>>>> solve
>>>>>> the same basic problem.
>>>>>>
>>>>>>>> Maybe the fact that you refuse to study the field means you
>>>>>>>> don't recognize that, and are dooming yourself to repeating all the
>>>>>>>> mistakes that have been worked through over the century,
>>>>>>>
>>>>>>> PUT UP OR SHUT UP !!!
>>>>>>> PUT UP OR SHUT UP !!!
>>>>>>> PUT UP OR SHUT UP !!!
>>>>>>> PUT UP OR SHUT UP !!!
>>>>>>
>>>>>> Will you now SHUT UP that NO ONE has looked at this before?
>>>>>
>>>>> My original words included to the same extent that I have.
>>>>>
>>>>> None-the-less is seems clear that you now do understand that when Linz
>>>>> referred to a UTM he was only referring to using a UTM as a halt
>>>>> decider, not using a hybrid UTM halt decider that examines the
>>>>> execution
>>>>> trace of its input.
>>>>>
>>>>
>>>> Nope, because I remember when I was in school, it was already
>>>> established that Simulating Halt Deciding did not show much promise as
>>>> there were serious limits as to what you could detect. Linz knew that
>>>> and knew that mentiones in passing that it couldn't know enough to make
>>>> the decision.
>>>>
>>>> Also, since he proved it for ALL Halt deciders, he proved it for
>>>> Simulating Halt Deciders, as those are within the class of Halt
>>>> Deciders, and can't do anything that a 'generic' Halt Decider can't do.
>>>>
>>>
>>> None-the-less int main() { H1(P,P); } does correctly report that its
>>> input halts on the basis that H(P,P) does correctly report that its
>>> input never halts.
>>>
>>
>> But since H^ was built on H, it is H that needs to get the answer right,
>> not H1, and it doesn't
>>
>> If you want to claim that they are the same machine, you need to explain
>> how they give different answers for the same input, which shows they are
>> Computations.
>>
>>> If you knew the x86 language and software engineering well enough you
>>> would know that the following execution trace of the simulation of P(P)
>>> matches the infinite recursion behavior pattern and you would know that
>>> the infinite recursion behavior pattern is correct.
>>>
>>
>> Nope, since it skips over the CONDITIONAL code of H.
>>
>> That code needs to be traced and shown to be unconditional.
>>
>>> THAT YOU SIMPLY DON'T KNOW THESE THINGS WELL ENOUGH IS PROVEN BY THE
>>> FACT THAT YOU ALWAYS CHANGE THE SUBJECT INSTEAD OF DIRECT POINTING OUT
>>> ANY ERROR
>>>
>>
>> WRONG. I keep pointing out that you build your arguement on false
>> foundations.
>>  >
>>> Begin Local Halt Decider Simulation at Machine Address:c36
>>> [00000c36][002117ca][002117ce] 55          push ebp
>>> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
>>> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
>>> [00000c3c][002117c6][00000c36] 50          push eax       // push P
>>> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
>>> [00000c40][002117c2][00000c36] 51          push ecx       // push P
>>> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>>>
>>> [00000c36][0025c1f2][0025c1f6] 55          push ebp
>>> [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
>>> [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
>>> [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
>>> [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
>>> [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
>>> [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call H(P,P)
>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>
>>> This infinite recursion detection criteria are met by the above
>>> execution trace:
>>> (a) P calls H twice in sequence from the same machine address.
>>> (b) With the same parameters: (P,P) to H.
>>> (c) With no conditional branch or indexed jump instructions in the
>>> execution trace of P.
>>
>> Only because the trace is incorrect.
>>
>>> (d) We know that there are no return instructions in H because we know
>>> that H is in pure simulation mode.
>>
>>
>> The H can NEVER answer even as a top level machine, so THAT is false too.
>>
>> Remember there is no such thing a 'Pure Simulator Mode', something is or
>> it isn't a Pure Simulator. H isn't if it ever answer H(H^,H^)
>
> That the entire time that the halt decider is making its halt status
> decision the halt decider has no behavior what-so-ever that can have any
> effect on the behavior of its simulated input seems to be beyond your
> intellectual capacity to comprehend.

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Richard Damon <Richard@Damon-Family.org> writes:

>> On 9/4/21 2:13 PM, olcott wrote:
>>> On 9/4/2021 1:04 PM, Alan Mackenzie wrote:
>>>> [ Malicious cross posting snipped. ]

>>>> In comp.theory olcott <NoOne@nowhere.com> wrote:

>>>>> .... valid on the basis of the known equivalence between the direct
>>>>> execution of a computation and its simulation by a UTM.

>>>> Not really.  There might well not be a simulation of the program.

>>> I am stopping here. If it is impossible to simulate the TM description
>>> of a TM then it is not a proper TM.

> I am pretty sure he is referring to the unwarranted assumption that any
> simulation at all is involved.

Thanks, Ben, that's exactly what I was trying to say. Apologies to PO
for being unclear, here.

> The context has been lost, including the key part that Alan was
> objecting to:

> || In computability theory, the halting problem is the
> || problem of determining, from a description of an arbitrary
> || computer program and an input,
> || whether the simulation of this program must be aborted to
> || prevent it from running forever.

> The phrase "the simulation" implies there is simulation involved. Had
> PO written "whether /a/ simulation of this program runs forever" the
> reference to simulation would be silly and superfluous, but not wrong.

> --
> Ben.

--
Alan Mackenzie (Nuremberg, Germany).

On 9/5/2021 4:37 AM, Alan Mackenzie wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>
>>> On 9/4/21 2:13 PM, olcott wrote:
>>>> On 9/4/2021 1:04 PM, Alan Mackenzie wrote:
>>>>> [ Malicious cross posting snipped. ]
>
>>>>> In comp.theory olcott <NoOne@nowhere.com> wrote:
>
>>>>>> .... valid on the basis of the known equivalence between the direct
>>>>>> execution of a computation and its simulation by a UTM.
>
>>>>> Not really.  There might well not be a simulation of the program.
>
>>>> I am stopping here. If it is impossible to simulate the TM description
>>>> of a TM then it is not a proper TM.
>
>> I am pretty sure he is referring to the unwarranted assumption that any
>> simulation at all is involved.
>
> Thanks, Ben, that's exactly what I was trying to say. Apologies to PO
> for being unclear, here.

Yet the point that I am making is that when a simulating halt decider
applies this criteria to its input:

whether the simulation of this program must be aborted to
prevent it from running forever.

Then the Peter Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its
input halts and transitions to H.qy on the basis of Ĥ.qx applied to ⟨Ĥ⟩
⟨Ĥ⟩ correctly decides that its input does not halt and transitions to Ĥ.qn.

>
>> The context has been lost, including the key part that Alan was
>> objecting to:
>
>> || In computability theory, the halting problem is the
>> || problem of determining, from a description of an arbitrary
>> || computer program and an input,
>> || whether the simulation of this program must be aborted to
>> || prevent it from running forever.
>
>> The phrase "the simulation" implies there is simulation involved. Had
>> PO written "whether /a/ simulation of this program runs forever" the
>> reference to simulation would be silly and superfluous, but not wrong.
>
>> --
>> Ben.
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

olcott <NoOne@NoWhere.com> writes:

> Yet the point that I am making is that when a simulating halt decider
> applies this criteria to its input:
>
> whether the simulation of this program must be aborted to
> prevent it from running forever.

No need to go any further. An algorithm that can make such a
determination is, in effect, already a halt decider. If you think you
have one, just publish it so we can find the errors for you.

--
Ben.

On 9/5/21 10:46 AM, olcott wrote:
> On 9/5/2021 4:37 AM, Alan Mackenzie wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>>> On 9/4/21 2:13 PM, olcott wrote:
>>>>> On 9/4/2021 1:04 PM, Alan Mackenzie wrote:
>>>>>> [ Malicious cross posting snipped. ]
>>
>>>>>> In comp.theory olcott <NoOne@nowhere.com> wrote:
>>
>>>>>>> .... valid on the basis of the known equivalence between the direct
>>>>>>> execution of a computation and its simulation by a UTM.
>>
>>>>>> Not really.  There might well not be a simulation of the program.
>>
>>>>> I am stopping here. If it is impossible to simulate the TM description
>>>>> of a TM then it is not a proper TM.
>>
>>> I am pretty sure he is referring to the unwarranted assumption that any
>>> simulation at all is involved.
>>
>> Thanks, Ben, that's exactly what I was trying to say.  Apologies to PO
>> for being unclear, here.
>
> Yet the point that I am making is that when a simulating halt decider
> applies this criteria to its input:
>
>    whether the simulation of this program must be aborted to
>    prevent it from running forever.
>

Except that your interpretation of that doesn't match the ACTAUL Halting
Problem criteria, and thus you actually get the wrong answer.

> Then the Peter Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its
> input halts and transitions to H.qy on the basis of Ĥ.qx applied to ⟨Ĥ⟩
> ⟨Ĥ⟩ correctly decides that its input does not halt and transitions to Ĥ.qn.
>

No, Linz doesn't actually HAVE an H, he shows that such an H is
impossible to build.

He points out as a REQUIREMENT, that if H^(H^) halts, that H(H^,H^)
needs to end up in the state qy, and if H^(H^) doesn't halt that
H(H^,H^) needs to end up in the state qn.

He NEVER claims that he actually has such a machine, he begins by
assuming that such an H exists, and then shows that such an assumption
leads to necessary contradictions, so such an assumption MUST be wrong,
a classical 'Proof by Contradiction'.

You just seem to ignore the contradictions and assume that you must be
right. But then for your the wrong answer is right, so if you must be
right that also means you must be wrong.

>
>>
>>> The context has been lost, including the key part that Alan was
>>> objecting to:
>>
>>> ||    In computability theory, the halting problem is the
>>> ||    problem of determining, from a description of an arbitrary
>>> ||    computer program and an input,
>>> ||    whether the simulation of this program must be aborted to
>>> ||    prevent it from running forever.
>>
>>> The phrase "the simulation" implies there is simulation involved.  Had
>>> PO written "whether /a/ simulation of this program runs forever" the
>>> reference to simulation would be silly and superfluous, but not wrong.
>>
>>> -- 
>>> Ben.
>>
>
>

On Sat, 4 Sep 2021 17:52:27 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 9/4/2021 5:39 PM, Richard Damon wrote:
> > On 9/4/21 6:15 PM, olcott wrote:
> >> On 9/4/2021 5:01 PM, Richard Damon wrote:
> >>> On 9/4/21 4:59 PM, olcott wrote:
> >>>> On 9/4/2021 3:48 PM, Richard Damon wrote:
> >>>>> On 9/4/21 2:47 PM, olcott wrote:
> >>>>>> On 9/4/2021 1:15 PM, Richard Damon wrote:
> >>>>>>> On 9/4/21 1:46 PM, olcott wrote:
> >>>>>>>> On 9/4/2021 12:34 PM, Richard Damon wrote:
> >>>>>>>>> On 9/4/21 1:21 PM, olcott wrote:
> >>>>>>>>>> On 9/4/2021 12:13 PM, Richard Damon wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> He says:
> >>>>>>>>>>>
> >>>>>>>>>>> If M enters an infinite loop, then no matter how long we
> >>>>>>>>>>> wait, we can
> >>>>>>>>>>> never be sure that M is in fact in a loop. It may simply
> >>>>>>>>>>> be a case
> >>>>>>>>>>> of a
> >>>>>>>>>>> very long computation. What we need is an algorithm that
> >>>>>>>>>>> can determine
> >>>>>>>>>>> the correct answer for any M and w by performing some
> >>>>>>>>>>> analysis on the
> >>>>>>>>>>> machine's description and the input. But as we now show,
> >>>>>>>>>>> no such algorithm exists.
> >>>>>>>>>>>
> >>>>>>>>>>> Thus he recognized that the issue with a simulating
> >>>>>>>>>>> decider would be it
> >>>>>>>>>>
> >>>>>>>>>> No he recognized the very obvious issue of using a
> >>>>>>>>>> simulator instead of
> >>>>>>>>>> a decider. No one besides me has ever considered a
> >>>>>>>>>> simulating halt decider that examines the simulated
> >>>>>>>>>> execution trace for non halting
> >>>>>>>>>> patterns of behavior.
> >>>>>>>>>
> >>>>>>>>> Nope, He understood the issues involved. Maybe if you had
> >>>>>>>>> studied some
> >>>>>>>>> of the field you would know that the limitation of Halt
> >>>>>>>>> Deciding by Simulating are WELL known, and have been shown
> >>>>>>>>> to be impossible in general.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> In the text that you referenced he was only referring to
> >>>>>>>> using a simulator as a decider. He was not referring to
> >>>>>>>> using a simulating decider that examines the execution trace
> >>>>>>>> of the simulation to look for
> >>>>>>>> non halting behavior patterns.
> >>>>>>>
> >>>>>>> Nope, maybe he doesn't explicitly call it that, but his words
> >>>>>>> definitely
> >>>>>>> reference the well known and studied limitation of simulation
> >>>>>>> for halt
> >>>>>>> deciding.
> >>>>>>
> >>>>>> Of course. If you want to tell if an infinite loops halts you
> >>>>>> sure as Hell can't simply wait and see what happens.
> >>>>>>
> >>>>>> It is getting to the point where I am convinced that you are
> >>>>>> simply lying. If you are aware of any source besides me that
> >>>>>> proposes a simulating halt decider that specifically examines
> >>>>>> the execution trace of its simulation to match non-halting
> >>>>>> behavior patterns of its input then PUT UP OR SHUT UP !!!
> >>>>>>
> >>>>>
> >>>>> Most of the stuff I know was pre-internet, so not easy to find.
> >>>>>
> >>>>> Here is one example of a reference to this from a decade ago:
> >>>>> https://math.stackexchange.com/questions/27606/detecting-cycles-in-off-line-turing-machines
> >>>>>
> >>>>>
> >>>>>
> >>>>> This mentions one of the techniques used for detecting SOME
> >>>>> forms of infinite loops.
> >>>>>
> >>>>> Here is another person needing to solve the halting problem for
> >>>>> a limited case, and was given a few examples of classical
> >>>>> methods (like detecting repeating state) to detect an infinite
> >>>>> loop.
> >>>>>
> >>>>> https://try2explore.com/questions/10671161
> >>>>>
> >>>>> And then there is this article on detecting the non-termination
> >>>>> of Turing Machines, to look for solutions to things like the
> >>>>> Busy-Beaver problem:
> >>>>>
> >>>>> https://dl.acm.org/doi/pdf/10.5555/1273694.1273703
> >>>>>
> >>>>> While not specifically a 'simulating Halt Decider' it is trying
> >>>>> to solve
> >>>>> the same basic problem.
> >>>>>
> >>>>>>> Maybe the fact that you refuse to study the field means you
> >>>>>>> don't recognize that, and are dooming yourself to repeating
> >>>>>>> all the mistakes that have been worked through over the
> >>>>>>> century,
> >>>>>>
> >>>>>> PUT UP OR SHUT UP !!!
> >>>>>> PUT UP OR SHUT UP !!!
> >>>>>> PUT UP OR SHUT UP !!!
> >>>>>> PUT UP OR SHUT UP !!!
> >>>>>
> >>>>> Will you now SHUT UP that NO ONE has looked at this before?
> >>>>
> >>>> My original words included to the same extent that I have.
> >>>>
> >>>> None-the-less is seems clear that you now do understand that
> >>>> when Linz referred to a UTM he was only referring to using a UTM
> >>>> as a halt decider, not using a hybrid UTM halt decider that
> >>>> examines the execution trace of its input.
> >>>>
> >>>
> >>> Nope, because I remember when I was in school, it was already
> >>> established that Simulating Halt Deciding did not show much
> >>> promise as there were serious limits as to what you could detect.
> >>> Linz knew that and knew that mentiones in passing that it
> >>> couldn't know enough to make the decision.
> >>>
> >>> Also, since he proved it for ALL Halt deciders, he proved it for
> >>> Simulating Halt Deciders, as those are within the class of Halt
> >>> Deciders, and can't do anything that a 'generic' Halt Decider
> >>> can't do.
> >>
> >> None-the-less int main() { H1(P,P); } does correctly report that
> >> its input halts on the basis that H(P,P) does correctly report
> >> that its input never halts.
> >>
> >
> > But since H^ was built on H, it is H that needs to get the answer
> > right, not H1, and it doesn't
> >
> > If you want to claim that they are the same machine, you need to
> > explain how they give different answers for the same input, which
> > shows they are Computations.
> >
> >> If you knew the x86 language and software engineering well enough
> >> you would know that the following execution trace of the
> >> simulation of P(P) matches the infinite recursion behavior pattern
> >> and you would know that the infinite recursion behavior pattern is
> >> correct.
> >
> > Nope, since it skips over the CONDITIONAL code of H.
> >
> > That code needs to be traced and shown to be unconditional.
> >
> >> THAT YOU SIMPLY DON'T KNOW THESE THINGS WELL ENOUGH IS PROVEN BY
> >> THE FACT THAT YOU ALWAYS CHANGE THE SUBJECT INSTEAD OF DIRECT
> >> POINTING OUT ANY ERROR
> >>
> >
> > WRONG. I keep pointing out that you build your arguement on false
> > foundations.
> > >
> >> Begin Local Halt Decider Simulation at Machine Address:c36
> >> [00000c36][002117ca][002117ce] 55          push ebp
> >> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
> >> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
> >> [00000c3c][002117c6][00000c36] 50          push eax       // push P
> >> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
> >> [00000c40][002117c2][00000c36] 51          push ecx       // push P
> >> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call
> >> H(P,P)
> >>
> >> [00000c36][0025c1f2][0025c1f6] 55          push ebp
> >> [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
> >> [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
> >> [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
> >> [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
> >> [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
> >> [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call
> >> H(P,P) Local Halt Decider: Infinite Recursion Detected Simulation
> >> Stopped
> >>
> >> This infinite recursion detection criteria are met by the above
> >> execution trace:
> >> (a) P calls H twice in sequence from the same machine address.
> >> (b) With the same parameters: (P,P) to H.
> >> (c) With no conditional branch or indexed jump instructions in the
> >> execution trace of P.
> >
> > Only because the trace is incorrect.
> >
> >> (d) We know that there are no return instructions in H because we
> >> know that H is in pure simulation mode.
> >
> >
> > The H can NEVER answer even as a top level machine, so THAT is
> > false too.
> >
> > Remember there is no such thing a 'Pure Simulator Mode', something
> > is or it isn't a Pure Simulator. H isn't if it ever answer H(H^,H^)
> >
>
> That the entire time that the halt decider is making its halt status
> decision the halt decider has no behavior what-so-ever that can have
> any effect on the behavior of its simulated input seems to be beyond
> your intellectual capacity to comprehend.

On 9/17/2021 1:27 PM, Mr Flibble wrote:
> On Sat, 4 Sep 2021 17:52:27 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 9/4/2021 5:39 PM, Richard Damon wrote:
>>> On 9/4/21 6:15 PM, olcott wrote:
>>>> On 9/4/2021 5:01 PM, Richard Damon wrote:
>>>>> On 9/4/21 4:59 PM, olcott wrote:
>>>>>> On 9/4/2021 3:48 PM, Richard Damon wrote:
>>>>>>> On 9/4/21 2:47 PM, olcott wrote:
>>>>>>>> On 9/4/2021 1:15 PM, Richard Damon wrote:
>>>>>>>>> On 9/4/21 1:46 PM, olcott wrote:
>>>>>>>>>> On 9/4/2021 12:34 PM, Richard Damon wrote:
>>>>>>>>>>> On 9/4/21 1:21 PM, olcott wrote:
>>>>>>>>>>>> On 9/4/2021 12:13 PM, Richard Damon wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> He says:
>>>>>>>>>>>>>
>>>>>>>>>>>>> If M enters an infinite loop, then no matter how long we
>>>>>>>>>>>>> wait, we can
>>>>>>>>>>>>> never be sure that M is in fact in a loop. It may simply
>>>>>>>>>>>>> be a case
>>>>>>>>>>>>> of a
>>>>>>>>>>>>> very long computation. What we need is an algorithm that
>>>>>>>>>>>>> can determine
>>>>>>>>>>>>> the correct answer for any M and w by performing some
>>>>>>>>>>>>> analysis on the
>>>>>>>>>>>>> machine's description and the input. But as we now show,
>>>>>>>>>>>>> no such algorithm exists.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thus he recognized that the issue with a simulating
>>>>>>>>>>>>> decider would be it
>>>>>>>>>>>>
>>>>>>>>>>>> No he recognized the very obvious issue of using a
>>>>>>>>>>>> simulator instead of
>>>>>>>>>>>> a decider. No one besides me has ever considered a
>>>>>>>>>>>> simulating halt decider that examines the simulated
>>>>>>>>>>>> execution trace for non halting
>>>>>>>>>>>> patterns of behavior.
>>>>>>>>>>>
>>>>>>>>>>> Nope, He understood the issues involved. Maybe if you had
>>>>>>>>>>> studied some
>>>>>>>>>>> of the field you would know that the limitation of Halt
>>>>>>>>>>> Deciding by Simulating are WELL known, and have been shown
>>>>>>>>>>> to be impossible in general.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> In the text that you referenced he was only referring to
>>>>>>>>>> using a simulator as a decider. He was not referring to
>>>>>>>>>> using a simulating decider that examines the execution trace
>>>>>>>>>> of the simulation to look for
>>>>>>>>>> non halting behavior patterns.
>>>>>>>>>
>>>>>>>>> Nope, maybe he doesn't explicitly call it that, but his words
>>>>>>>>> definitely
>>>>>>>>> reference the well known and studied limitation of simulation
>>>>>>>>> for halt
>>>>>>>>> deciding.
>>>>>>>>
>>>>>>>> Of course. If you want to tell if an infinite loops halts you
>>>>>>>> sure as Hell can't simply wait and see what happens.
>>>>>>>>
>>>>>>>> It is getting to the point where I am convinced that you are
>>>>>>>> simply lying. If you are aware of any source besides me that
>>>>>>>> proposes a simulating halt decider that specifically examines
>>>>>>>> the execution trace of its simulation to match non-halting
>>>>>>>> behavior patterns of its input then PUT UP OR SHUT UP !!!
>>>>>>>>
>>>>>>>
>>>>>>> Most of the stuff I know was pre-internet, so not easy to find.
>>>>>>>
>>>>>>> Here is one example of a reference to this from a decade ago:
>>>>>>> https://math.stackexchange.com/questions/27606/detecting-cycles-in-off-line-turing-machines
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This mentions one of the techniques used for detecting SOME
>>>>>>> forms of infinite loops.
>>>>>>>
>>>>>>> Here is another person needing to solve the halting problem for
>>>>>>> a limited case, and was given a few examples of classical
>>>>>>> methods (like detecting repeating state) to detect an infinite
>>>>>>> loop.
>>>>>>>
>>>>>>> https://try2explore.com/questions/10671161
>>>>>>>
>>>>>>> And then there is this article on detecting the non-termination
>>>>>>> of Turing Machines, to look for solutions to things like the
>>>>>>> Busy-Beaver problem:
>>>>>>>
>>>>>>> https://dl.acm.org/doi/pdf/10.5555/1273694.1273703
>>>>>>>
>>>>>>> While not specifically a 'simulating Halt Decider' it is trying
>>>>>>> to solve
>>>>>>> the same basic problem.
>>>>>>>
>>>>>>>>> Maybe the fact that you refuse to study the field means you
>>>>>>>>> don't recognize that, and are dooming yourself to repeating
>>>>>>>>> all the mistakes that have been worked through over the
>>>>>>>>> century,
>>>>>>>>
>>>>>>>> PUT UP OR SHUT UP !!!
>>>>>>>> PUT UP OR SHUT UP !!!
>>>>>>>> PUT UP OR SHUT UP !!!
>>>>>>>> PUT UP OR SHUT UP !!!
>>>>>>>
>>>>>>> Will you now SHUT UP that NO ONE has looked at this before?
>>>>>>
>>>>>> My original words included to the same extent that I have.
>>>>>>
>>>>>> None-the-less is seems clear that you now do understand that
>>>>>> when Linz referred to a UTM he was only referring to using a UTM
>>>>>> as a halt decider, not using a hybrid UTM halt decider that
>>>>>> examines the execution trace of its input.
>>>>>>
>>>>>
>>>>> Nope, because I remember when I was in school, it was already
>>>>> established that Simulating Halt Deciding did not show much
>>>>> promise as there were serious limits as to what you could detect.
>>>>> Linz knew that and knew that mentiones in passing that it
>>>>> couldn't know enough to make the decision.
>>>>>
>>>>> Also, since he proved it for ALL Halt deciders, he proved it for
>>>>> Simulating Halt Deciders, as those are within the class of Halt
>>>>> Deciders, and can't do anything that a 'generic' Halt Decider
>>>>> can't do.
>>>>
>>>> None-the-less int main() { H1(P,P); } does correctly report that
>>>> its input halts on the basis that H(P,P) does correctly report
>>>> that its input never halts.
>>>>
>>>
>>> But since H^ was built on H, it is H that needs to get the answer
>>> right, not H1, and it doesn't
>>>
>>> If you want to claim that they are the same machine, you need to
>>> explain how they give different answers for the same input, which
>>> shows they are Computations.
>>>
>>>> If you knew the x86 language and software engineering well enough
>>>> you would know that the following execution trace of the
>>>> simulation of P(P) matches the infinite recursion behavior pattern
>>>> and you would know that the infinite recursion behavior pattern is
>>>> correct.
>>>
>>> Nope, since it skips over the CONDITIONAL code of H.
>>>
>>> That code needs to be traced and shown to be unconditional.
>>>
>>>> THAT YOU SIMPLY DON'T KNOW THESE THINGS WELL ENOUGH IS PROVEN BY
>>>> THE FACT THAT YOU ALWAYS CHANGE THE SUBJECT INSTEAD OF DIRECT
>>>> POINTING OUT ANY ERROR
>>>>
>>>
>>> WRONG. I keep pointing out that you build your arguement on false
>>> foundations.
>>> >
>>>> Begin Local Halt Decider Simulation at Machine Address:c36
>>>> [00000c36][002117ca][002117ce] 55          push ebp
>>>> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
>>>> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
>>>> [00000c3c][002117c6][00000c36] 50          push eax       // push P
>>>> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
>>>> [00000c40][002117c2][00000c36] 51          push ecx       // push P
>>>> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call
>>>> H(P,P)
>>>>
>>>> [00000c36][0025c1f2][0025c1f6] 55          push ebp
>>>> [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
>>>> [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
>>>> [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
>>>> [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
>>>> [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
>>>> [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call
>>>> H(P,P) Local Halt Decider: Infinite Recursion Detected Simulation
>>>> Stopped
>>>>
>>>> This infinite recursion detection criteria are met by the above
>>>> execution trace:
>>>> (a) P calls H twice in sequence from the same machine address.
>>>> (b) With the same parameters: (P,P) to H.
>>>> (c) With no conditional branch or indexed jump instructions in the
>>>> execution trace of P.
>>>
>>> Only because the trace is incorrect.
>>>
>>>> (d) We know that there are no return instructions in H because we
>>>> know that H is in pure simulation mode.
>>>
>>>
>>> The H can NEVER answer even as a top level machine, so THAT is
>>> false too.
>>>
>>> Remember there is no such thing a 'Pure Simulator Mode', something
>>> is or it isn't a Pure Simulator. H isn't if it ever answer H(H^,H^)
>>>
>>
>> That the entire time that the halt decider is making its halt status
>> decision the halt decider has no behavior what-so-ever that can have
>> any effect on the behavior of its simulated input seems to be beyond
>> your intellectual capacity to comprehend.
>
> The ad hominem attack is a logical fallacy: attack the argument and not
> the person and progress might be made.
>
> /Flibble
>

On 9/17/21 2:41 PM, olcott wrote:
> On 9/17/2021 1:27 PM, Mr Flibble wrote:
>> On Sat, 4 Sep 2021 17:52:27 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 9/4/2021 5:39 PM, Richard Damon wrote:
>>>> On 9/4/21 6:15 PM, olcott wrote:
>>>>> On 9/4/2021 5:01 PM, Richard Damon wrote:
>>>>>> On 9/4/21 4:59 PM, olcott wrote:
>>>>>>> On 9/4/2021 3:48 PM, Richard Damon wrote:
>>>>>>>> On 9/4/21 2:47 PM, olcott wrote:
>>>>>>>>> On 9/4/2021 1:15 PM, Richard Damon wrote:
>>>>>>>>>> On 9/4/21 1:46 PM, olcott wrote:
>>>>>>>>>>> On 9/4/2021 12:34 PM, Richard Damon wrote:
>>>>>>>>>>>> On 9/4/21 1:21 PM, olcott wrote:
>>>>>>>>>>>>> On 9/4/2021 12:13 PM, Richard Damon wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> He says:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If M enters an infinite loop, then no matter how long we
>>>>>>>>>>>>>> wait, we can
>>>>>>>>>>>>>> never be sure that M is in fact in a loop. It may simply
>>>>>>>>>>>>>> be a case
>>>>>>>>>>>>>> of a
>>>>>>>>>>>>>> very long computation. What we need is an algorithm that
>>>>>>>>>>>>>> can determine
>>>>>>>>>>>>>> the correct answer for any M and w by performing some
>>>>>>>>>>>>>> analysis on the
>>>>>>>>>>>>>> machine's description and the input. But as we now show,
>>>>>>>>>>>>>> no such algorithm exists.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thus he recognized that the issue with a simulating
>>>>>>>>>>>>>> decider would be it
>>>>>>>>>>>>>
>>>>>>>>>>>>> No he recognized the very obvious issue of using a
>>>>>>>>>>>>> simulator instead of
>>>>>>>>>>>>> a decider. No one besides me has ever considered a
>>>>>>>>>>>>> simulating halt decider that examines the simulated
>>>>>>>>>>>>> execution trace for non halting
>>>>>>>>>>>>> patterns of behavior.
>>>>>>>>>>>>
>>>>>>>>>>>> Nope, He understood the issues involved. Maybe if you had
>>>>>>>>>>>> studied some
>>>>>>>>>>>> of the field you would know that the limitation of Halt
>>>>>>>>>>>> Deciding by Simulating are WELL known, and have been shown
>>>>>>>>>>>> to be impossible in general.
>>>>>>>>>>>>  
>>>>>>>>>>>
>>>>>>>>>>> In the text that you referenced he was only referring to
>>>>>>>>>>> using a simulator as a decider. He was not referring to
>>>>>>>>>>> using a simulating decider that examines the execution trace
>>>>>>>>>>> of the simulation to look for
>>>>>>>>>>> non halting behavior patterns.
>>>>>>>>>>
>>>>>>>>>> Nope, maybe he doesn't explicitly call it that, but his words
>>>>>>>>>> definitely
>>>>>>>>>> reference the well known and studied limitation of simulation
>>>>>>>>>> for halt
>>>>>>>>>> deciding.
>>>>>>>>>
>>>>>>>>> Of course. If you want to tell if an infinite loops halts you
>>>>>>>>> sure as Hell can't simply wait and see what happens.
>>>>>>>>>
>>>>>>>>> It is getting to the point where I am convinced that you are
>>>>>>>>> simply lying. If you are aware of any source besides me that
>>>>>>>>> proposes a simulating halt decider that specifically examines
>>>>>>>>> the execution trace of its simulation to match non-halting
>>>>>>>>> behavior patterns of its input then PUT UP OR SHUT UP !!!
>>>>>>>>>  
>>>>>>>>
>>>>>>>> Most of the stuff I know was pre-internet, so not easy to find.
>>>>>>>>
>>>>>>>> Here is one example of a reference to this from a decade ago:
>>>>>>>> https://math.stackexchange.com/questions/27606/detecting-cycles-in-off-line-turing-machines
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> This mentions one of the techniques used for detecting SOME
>>>>>>>> forms of infinite loops.
>>>>>>>>
>>>>>>>> Here is another person needing to solve the halting problem for
>>>>>>>> a limited case, and was given a few examples of classical
>>>>>>>> methods (like detecting repeating state) to detect an infinite
>>>>>>>> loop.
>>>>>>>>
>>>>>>>> https://try2explore.com/questions/10671161
>>>>>>>>
>>>>>>>> And then there is this article on detecting the non-termination
>>>>>>>> of Turing Machines, to look for solutions to things like the
>>>>>>>> Busy-Beaver problem:
>>>>>>>>
>>>>>>>> https://dl.acm.org/doi/pdf/10.5555/1273694.1273703
>>>>>>>>
>>>>>>>> While not specifically a 'simulating Halt Decider' it is trying
>>>>>>>> to solve
>>>>>>>> the same basic problem.
>>>>>>>>  
>>>>>>>>>> Maybe the fact that you refuse to study the field means you
>>>>>>>>>> don't recognize that, and are dooming yourself to repeating
>>>>>>>>>> all the mistakes that have been worked through over the
>>>>>>>>>> century,
>>>>>>>>>
>>>>>>>>> PUT UP OR SHUT UP !!!
>>>>>>>>> PUT UP OR SHUT UP !!!
>>>>>>>>> PUT UP OR SHUT UP !!!
>>>>>>>>> PUT UP OR SHUT UP !!!
>>>>>>>>
>>>>>>>> Will you now SHUT UP that NO ONE has looked at this before?
>>>>>>>
>>>>>>> My original words included to the same extent that I have.
>>>>>>>
>>>>>>> None-the-less is seems clear that you now do understand that
>>>>>>> when Linz referred to a UTM he was only referring to using a UTM
>>>>>>> as a halt decider, not using a hybrid UTM halt decider that
>>>>>>> examines the execution trace of its input.
>>>>>>>  
>>>>>>
>>>>>> Nope, because I remember when I was in school, it was already
>>>>>> established that Simulating Halt Deciding did not show much
>>>>>> promise as there were serious limits as to what you could detect.
>>>>>> Linz knew that and knew that mentiones in passing that it
>>>>>> couldn't know enough to make the decision.
>>>>>>
>>>>>> Also, since he proved it for ALL Halt deciders, he proved it for
>>>>>> Simulating Halt Deciders, as those are within the class of Halt
>>>>>> Deciders, and can't do anything that a 'generic' Halt Decider
>>>>>> can't do.
>>>>>
>>>>> None-the-less int main() { H1(P,P); } does correctly report that
>>>>> its input halts on the basis that H(P,P) does correctly report
>>>>> that its input never halts.
>>>>>  
>>>>
>>>> But since H^ was built on H, it is H that needs to get the answer
>>>> right, not H1, and it doesn't
>>>>
>>>> If you want to claim that they are the same machine, you need to
>>>> explain how they give different answers for the same input, which
>>>> shows they are Computations.
>>>>   
>>>>> If you knew the x86 language and software engineering well enough
>>>>> you would know that the following execution trace of the
>>>>> simulation of P(P) matches the infinite recursion behavior pattern
>>>>> and you would know that the infinite recursion behavior pattern is
>>>>> correct.
>>>>
>>>> Nope, since it skips over the CONDITIONAL code of H.
>>>>
>>>> That code needs to be traced and shown to be unconditional.
>>>>   
>>>>> THAT YOU SIMPLY DON'T KNOW THESE THINGS WELL ENOUGH IS PROVEN BY
>>>>> THE FACT THAT YOU ALWAYS CHANGE THE SUBJECT INSTEAD OF DIRECT
>>>>> POINTING OUT ANY ERROR
>>>>>  
>>>>
>>>> WRONG. I keep pointing out that you build your arguement on false
>>>> foundations.
>>>>   >
>>>>> Begin Local Halt Decider Simulation at Machine Address:c36
>>>>> [00000c36][002117ca][002117ce] 55          push ebp
>>>>> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
>>>>> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
>>>>> [00000c3c][002117c6][00000c36] 50          push eax       // push P
>>>>> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
>>>>> [00000c40][002117c2][00000c36] 51          push ecx       // push P
>>>>> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call
>>>>> H(P,P)
>>>>>
>>>>> [00000c36][0025c1f2][0025c1f6] 55          push ebp
>>>>> [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
>>>>> [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
>>>>> [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
>>>>> [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
>>>>> [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
>>>>> [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call
>>>>> H(P,P) Local Halt Decider: Infinite Recursion Detected Simulation
>>>>> Stopped
>>>>>
>>>>> This infinite recursion detection criteria are met by the above
>>>>> execution trace:
>>>>> (a) P calls H twice in sequence from the same machine address.
>>>>> (b) With the same parameters: (P,P) to H.
>>>>> (c) With no conditional branch or indexed jump instructions in the
>>>>> execution trace of P.
>>>>
>>>> Only because the trace is incorrect.
>>>>   
>>>>> (d) We know that there are no return instructions in H because we
>>>>> know that H is in pure simulation mode.
>>>>
>>>>
>>>> The H can NEVER answer even as a top level machine, so THAT is
>>>> false too.
>>>>
>>>> Remember there is no such thing a 'Pure Simulator Mode', something
>>>> is or it isn't a Pure Simulator. H isn't if it ever answer H(H^,H^)
>>>>  
>>>
>>> That the entire time that the halt decider is making its halt status
>>> decision the halt decider has no behavior what-so-ever that can have
>>> any effect on the behavior of its simulated input seems to be beyond
>>> your intellectual capacity to comprehend.
>>
>> The ad hominem attack is a logical fallacy: attack the argument and not
>> the person and progress might be made.
>>
>> /Flibble
>>
>
> It seems to be an objective fact that most people here simply do not
> want an honest dialogue and/or lack the intellectual capacity /
> prerequisite knowledge to comprehend what is being said.
>
> This is assessed on the basis that no actual valid reasoning is applied
> as rebuttals to my ideas. Most of the fake rebuttals are the dishonest
> dodge tactic of changing the subject rather than directly addressing any
> key points that have been made, AKA the strawman error:
>
> A straw man (sometimes written as strawman) is a form of argument and an
> informal fallacy of having the impression of refuting an argument,
> whereas the real subject of the argument was not addressed or refuted,
> but instead replaced with a false one.
> https://en.wikipedia.org/wiki/Straw_man
>

On 9/17/2021 2:15 PM, Richard Damon wrote:
>
> On 9/17/21 2:41 PM, olcott wrote:
>> On 9/17/2021 1:27 PM, Mr Flibble wrote:
>>> On Sat, 4 Sep 2021 17:52:27 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 9/4/2021 5:39 PM, Richard Damon wrote:
>>>>> On 9/4/21 6:15 PM, olcott wrote:
>>>>>> On 9/4/2021 5:01 PM, Richard Damon wrote:
>>>>>>> On 9/4/21 4:59 PM, olcott wrote:
>>>>>>>> On 9/4/2021 3:48 PM, Richard Damon wrote:
>>>>>>>>> On 9/4/21 2:47 PM, olcott wrote:
>>>>>>>>>> On 9/4/2021 1:15 PM, Richard Damon wrote:
>>>>>>>>>>> On 9/4/21 1:46 PM, olcott wrote:
>>>>>>>>>>>> On 9/4/2021 12:34 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 9/4/21 1:21 PM, olcott wrote:
>>>>>>>>>>>>>> On 9/4/2021 12:13 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> He says:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If M enters an infinite loop, then no matter how long we
>>>>>>>>>>>>>>> wait, we can
>>>>>>>>>>>>>>> never be sure that M is in fact in a loop. It may simply
>>>>>>>>>>>>>>> be a case
>>>>>>>>>>>>>>> of a
>>>>>>>>>>>>>>> very long computation. What we need is an algorithm that
>>>>>>>>>>>>>>> can determine
>>>>>>>>>>>>>>> the correct answer for any M and w by performing some
>>>>>>>>>>>>>>> analysis on the
>>>>>>>>>>>>>>> machine's description and the input. But as we now show,
>>>>>>>>>>>>>>> no such algorithm exists.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thus he recognized that the issue with a simulating
>>>>>>>>>>>>>>> decider would be it
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No he recognized the very obvious issue of using a
>>>>>>>>>>>>>> simulator instead of
>>>>>>>>>>>>>> a decider. No one besides me has ever considered a
>>>>>>>>>>>>>> simulating halt decider that examines the simulated
>>>>>>>>>>>>>> execution trace for non halting
>>>>>>>>>>>>>> patterns of behavior.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nope, He understood the issues involved. Maybe if you had
>>>>>>>>>>>>> studied some
>>>>>>>>>>>>> of the field you would know that the limitation of Halt
>>>>>>>>>>>>> Deciding by Simulating are WELL known, and have been shown
>>>>>>>>>>>>> to be impossible in general.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> In the text that you referenced he was only referring to
>>>>>>>>>>>> using a simulator as a decider. He was not referring to
>>>>>>>>>>>> using a simulating decider that examines the execution trace
>>>>>>>>>>>> of the simulation to look for
>>>>>>>>>>>> non halting behavior patterns.
>>>>>>>>>>>
>>>>>>>>>>> Nope, maybe he doesn't explicitly call it that, but his words
>>>>>>>>>>> definitely
>>>>>>>>>>> reference the well known and studied limitation of simulation
>>>>>>>>>>> for halt
>>>>>>>>>>> deciding.
>>>>>>>>>>
>>>>>>>>>> Of course. If you want to tell if an infinite loops halts you
>>>>>>>>>> sure as Hell can't simply wait and see what happens.
>>>>>>>>>>
>>>>>>>>>> It is getting to the point where I am convinced that you are
>>>>>>>>>> simply lying. If you are aware of any source besides me that
>>>>>>>>>> proposes a simulating halt decider that specifically examines
>>>>>>>>>> the execution trace of its simulation to match non-halting
>>>>>>>>>> behavior patterns of its input then PUT UP OR SHUT UP !!!
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Most of the stuff I know was pre-internet, so not easy to find.
>>>>>>>>>
>>>>>>>>> Here is one example of a reference to this from a decade ago:
>>>>>>>>> https://math.stackexchange.com/questions/27606/detecting-cycles-in-off-line-turing-machines
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This mentions one of the techniques used for detecting SOME
>>>>>>>>> forms of infinite loops.
>>>>>>>>>
>>>>>>>>> Here is another person needing to solve the halting problem for
>>>>>>>>> a limited case, and was given a few examples of classical
>>>>>>>>> methods (like detecting repeating state) to detect an infinite
>>>>>>>>> loop.
>>>>>>>>>
>>>>>>>>> https://try2explore.com/questions/10671161
>>>>>>>>>
>>>>>>>>> And then there is this article on detecting the non-termination
>>>>>>>>> of Turing Machines, to look for solutions to things like the
>>>>>>>>> Busy-Beaver problem:
>>>>>>>>>
>>>>>>>>> https://dl.acm.org/doi/pdf/10.5555/1273694.1273703
>>>>>>>>>
>>>>>>>>> While not specifically a 'simulating Halt Decider' it is trying
>>>>>>>>> to solve
>>>>>>>>> the same basic problem.
>>>>>>>>>
>>>>>>>>>>> Maybe the fact that you refuse to study the field means you
>>>>>>>>>>> don't recognize that, and are dooming yourself to repeating
>>>>>>>>>>> all the mistakes that have been worked through over the
>>>>>>>>>>> century,
>>>>>>>>>>
>>>>>>>>>> PUT UP OR SHUT UP !!!
>>>>>>>>>> PUT UP OR SHUT UP !!!
>>>>>>>>>> PUT UP OR SHUT UP !!!
>>>>>>>>>> PUT UP OR SHUT UP !!!
>>>>>>>>>
>>>>>>>>> Will you now SHUT UP that NO ONE has looked at this before?
>>>>>>>>
>>>>>>>> My original words included to the same extent that I have.
>>>>>>>>
>>>>>>>> None-the-less is seems clear that you now do understand that
>>>>>>>> when Linz referred to a UTM he was only referring to using a UTM
>>>>>>>> as a halt decider, not using a hybrid UTM halt decider that
>>>>>>>> examines the execution trace of its input.
>>>>>>>>
>>>>>>>
>>>>>>> Nope, because I remember when I was in school, it was already
>>>>>>> established that Simulating Halt Deciding did not show much
>>>>>>> promise as there were serious limits as to what you could detect.
>>>>>>> Linz knew that and knew that mentiones in passing that it
>>>>>>> couldn't know enough to make the decision.
>>>>>>>
>>>>>>> Also, since he proved it for ALL Halt deciders, he proved it for
>>>>>>> Simulating Halt Deciders, as those are within the class of Halt
>>>>>>> Deciders, and can't do anything that a 'generic' Halt Decider
>>>>>>> can't do.
>>>>>>
>>>>>> None-the-less int main() { H1(P,P); } does correctly report that
>>>>>> its input halts on the basis that H(P,P) does correctly report
>>>>>> that its input never halts.
>>>>>>
>>>>>
>>>>> But since H^ was built on H, it is H that needs to get the answer
>>>>> right, not H1, and it doesn't
>>>>>
>>>>> If you want to claim that they are the same machine, you need to
>>>>> explain how they give different answers for the same input, which
>>>>> shows they are Computations.
>>>>>
>>>>>> If you knew the x86 language and software engineering well enough
>>>>>> you would know that the following execution trace of the
>>>>>> simulation of P(P) matches the infinite recursion behavior pattern
>>>>>> and you would know that the infinite recursion behavior pattern is
>>>>>> correct.
>>>>>
>>>>> Nope, since it skips over the CONDITIONAL code of H.
>>>>>
>>>>> That code needs to be traced and shown to be unconditional.
>>>>>
>>>>>> THAT YOU SIMPLY DON'T KNOW THESE THINGS WELL ENOUGH IS PROVEN BY
>>>>>> THE FACT THAT YOU ALWAYS CHANGE THE SUBJECT INSTEAD OF DIRECT
>>>>>> POINTING OUT ANY ERROR
>>>>>>
>>>>>
>>>>> WRONG. I keep pointing out that you build your arguement on false
>>>>> foundations.
>>>>>   >
>>>>>> Begin Local Halt Decider Simulation at Machine Address:c36
>>>>>> [00000c36][002117ca][002117ce] 55          push ebp
>>>>>> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
>>>>>> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
>>>>>> [00000c3c][002117c6][00000c36] 50          push eax       // push P
>>>>>> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
>>>>>> [00000c40][002117c2][00000c36] 51          push ecx       // push P
>>>>>> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call
>>>>>> H(P,P)
>>>>>>
>>>>>> [00000c36][0025c1f2][0025c1f6] 55          push ebp
>>>>>> [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
>>>>>> [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
>>>>>> [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
>>>>>> [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
>>>>>> [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
>>>>>> [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call
>>>>>> H(P,P) Local Halt Decider: Infinite Recursion Detected Simulation
>>>>>> Stopped
>>>>>>
>>>>>> This infinite recursion detection criteria are met by the above
>>>>>> execution trace:
>>>>>> (a) P calls H twice in sequence from the same machine address.
>>>>>> (b) With the same parameters: (P,P) to H.
>>>>>> (c) With no conditional branch or indexed jump instructions in the
>>>>>> execution trace of P.
>>>>>
>>>>> Only because the trace is incorrect.
>>>>>
>>>>>> (d) We know that there are no return instructions in H because we
>>>>>> know that H is in pure simulation mode.
>>>>>
>>>>>
>>>>> The H can NEVER answer even as a top level machine, so THAT is
>>>>> false too.
>>>>>
>>>>> Remember there is no such thing a 'Pure Simulator Mode', something
>>>>> is or it isn't a Pure Simulator. H isn't if it ever answer H(H^,H^)
>>>>>
>>>>
>>>> That the entire time that the halt decider is making its halt status
>>>> decision the halt decider has no behavior what-so-ever that can have
>>>> any effect on the behavior of its simulated input seems to be beyond
>>>> your intellectual capacity to comprehend.
>>>
>>> The ad hominem attack is a logical fallacy: attack the argument and not
>>> the person and progress might be made.
>>>
>>> /Flibble
>>>
>>
>> It seems to be an objective fact that most people here simply do not
>> want an honest dialogue and/or lack the intellectual capacity /
>> prerequisite knowledge to comprehend what is being said.
>>
>> This is assessed on the basis that no actual valid reasoning is applied
>> as rebuttals to my ideas. Most of the fake rebuttals are the dishonest
>> dodge tactic of changing the subject rather than directly addressing any
>> key points that have been made, AKA the strawman error:
>>
>> A straw man (sometimes written as strawman) is a form of argument and an
>> informal fallacy of having the impression of refuting an argument,
>> whereas the real subject of the argument was not addressed or refuted,
>> but instead replaced with a false one.
>> https://en.wikipedia.org/wiki/Straw_man
>>
>
> It is an objective fact that MANY actual valid rebuttals have been made
> to your arguements,
Gullible fools may believe this.

On 9/17/21 3:19 PM, olcott wrote:
> On 9/17/2021 2:15 PM, Richard Damon wrote:
>>
>> On 9/17/21 2:41 PM, olcott wrote:
>>> On 9/17/2021 1:27 PM, Mr Flibble wrote:
>>>> On Sat, 4 Sep 2021 17:52:27 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>
>>>>> On 9/4/2021 5:39 PM, Richard Damon wrote:
>>>>>> On 9/4/21 6:15 PM, olcott wrote:
>>>>>>> On 9/4/2021 5:01 PM, Richard Damon wrote:
>>>>>>>> On 9/4/21 4:59 PM, olcott wrote:
>>>>>>>>> On 9/4/2021 3:48 PM, Richard Damon wrote:
>>>>>>>>>> On 9/4/21 2:47 PM, olcott wrote:
>>>>>>>>>>> On 9/4/2021 1:15 PM, Richard Damon wrote:
>>>>>>>>>>>> On 9/4/21 1:46 PM, olcott wrote:
>>>>>>>>>>>>> On 9/4/2021 12:34 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 9/4/21 1:21 PM, olcott wrote:
>>>>>>>>>>>>>>> On 9/4/2021 12:13 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> He says:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If M enters an infinite loop, then no matter how long we
>>>>>>>>>>>>>>>> wait, we can
>>>>>>>>>>>>>>>> never be sure that M is in fact in a loop. It may simply
>>>>>>>>>>>>>>>> be a case
>>>>>>>>>>>>>>>> of a
>>>>>>>>>>>>>>>> very long computation. What we need is an algorithm that
>>>>>>>>>>>>>>>> can determine
>>>>>>>>>>>>>>>> the correct answer for any M and w by performing some
>>>>>>>>>>>>>>>> analysis on the
>>>>>>>>>>>>>>>> machine's description and the input. But as we now show,
>>>>>>>>>>>>>>>> no such algorithm exists.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thus he recognized that the issue with a simulating
>>>>>>>>>>>>>>>> decider would be it
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No he recognized the very obvious issue of using a
>>>>>>>>>>>>>>> simulator instead of
>>>>>>>>>>>>>>> a decider. No one besides me has ever considered a
>>>>>>>>>>>>>>> simulating halt decider that examines the simulated
>>>>>>>>>>>>>>> execution trace for non halting
>>>>>>>>>>>>>>> patterns of behavior.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope, He understood the issues involved. Maybe if you had
>>>>>>>>>>>>>> studied some
>>>>>>>>>>>>>> of the field you would know that the limitation of Halt
>>>>>>>>>>>>>> Deciding by Simulating are WELL known, and have been shown
>>>>>>>>>>>>>> to be impossible in general.
>>>>>>>>>>>>>>   
>>>>>>>>>>>>>
>>>>>>>>>>>>> In the text that you referenced he was only referring to
>>>>>>>>>>>>> using a simulator as a decider. He was not referring to
>>>>>>>>>>>>> using a simulating decider that examines the execution trace
>>>>>>>>>>>>> of the simulation to look for
>>>>>>>>>>>>> non halting behavior patterns.
>>>>>>>>>>>>
>>>>>>>>>>>> Nope, maybe he doesn't explicitly call it that, but his words
>>>>>>>>>>>> definitely
>>>>>>>>>>>> reference the well known and studied limitation of simulation
>>>>>>>>>>>> for halt
>>>>>>>>>>>> deciding.
>>>>>>>>>>>
>>>>>>>>>>> Of course. If you want to tell if an infinite loops halts you
>>>>>>>>>>> sure as Hell can't simply wait and see what happens.
>>>>>>>>>>>
>>>>>>>>>>> It is getting to the point where I am convinced that you are
>>>>>>>>>>> simply lying. If you are aware of any source besides me that
>>>>>>>>>>> proposes a simulating halt decider that specifically examines
>>>>>>>>>>> the execution trace of its simulation to match non-halting
>>>>>>>>>>> behavior patterns of its input then PUT UP OR SHUT UP !!!
>>>>>>>>>>>   
>>>>>>>>>>
>>>>>>>>>> Most of the stuff I know was pre-internet, so not easy to find.
>>>>>>>>>>
>>>>>>>>>> Here is one example of a reference to this from a decade ago:
>>>>>>>>>> https://math.stackexchange.com/questions/27606/detecting-cycles-in-off-line-turing-machines
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This mentions one of the techniques used for detecting SOME
>>>>>>>>>> forms of infinite loops.
>>>>>>>>>>
>>>>>>>>>> Here is another person needing to solve the halting problem for
>>>>>>>>>> a limited case, and was given a few examples of classical
>>>>>>>>>> methods (like detecting repeating state) to detect an infinite
>>>>>>>>>> loop.
>>>>>>>>>>
>>>>>>>>>> https://try2explore.com/questions/10671161
>>>>>>>>>>
>>>>>>>>>> And then there is this article on detecting the non-termination
>>>>>>>>>> of Turing Machines, to look for solutions to things like the
>>>>>>>>>> Busy-Beaver problem:
>>>>>>>>>>
>>>>>>>>>> https://dl.acm.org/doi/pdf/10.5555/1273694.1273703
>>>>>>>>>>
>>>>>>>>>> While not specifically a 'simulating Halt Decider' it is trying
>>>>>>>>>> to solve
>>>>>>>>>> the same basic problem.
>>>>>>>>>>  
>>>>>>>>>>>> Maybe the fact that you refuse to study the field means you
>>>>>>>>>>>> don't recognize that, and are dooming yourself to repeating
>>>>>>>>>>>> all the mistakes that have been worked through over the
>>>>>>>>>>>> century,
>>>>>>>>>>>
>>>>>>>>>>> PUT UP OR SHUT UP !!!
>>>>>>>>>>> PUT UP OR SHUT UP !!!
>>>>>>>>>>> PUT UP OR SHUT UP !!!
>>>>>>>>>>> PUT UP OR SHUT UP !!!
>>>>>>>>>>
>>>>>>>>>> Will you now SHUT UP that NO ONE has looked at this before?
>>>>>>>>>
>>>>>>>>> My original words included to the same extent that I have.
>>>>>>>>>
>>>>>>>>> None-the-less is seems clear that you now do understand that
>>>>>>>>> when Linz referred to a UTM he was only referring to using a UTM
>>>>>>>>> as a halt decider, not using a hybrid UTM halt decider that
>>>>>>>>> examines the execution trace of its input.
>>>>>>>>>   
>>>>>>>>
>>>>>>>> Nope, because I remember when I was in school, it was already
>>>>>>>> established that Simulating Halt Deciding did not show much
>>>>>>>> promise as there were serious limits as to what you could detect.
>>>>>>>> Linz knew that and knew that mentiones in passing that it
>>>>>>>> couldn't know enough to make the decision.
>>>>>>>>
>>>>>>>> Also, since he proved it for ALL Halt deciders, he proved it for
>>>>>>>> Simulating Halt Deciders, as those are within the class of Halt
>>>>>>>> Deciders, and can't do anything that a 'generic' Halt Decider
>>>>>>>> can't do.
>>>>>>>
>>>>>>> None-the-less int main() { H1(P,P); } does correctly report that
>>>>>>> its input halts on the basis that H(P,P) does correctly report
>>>>>>> that its input never halts.
>>>>>>>   
>>>>>>
>>>>>> But since H^ was built on H, it is H that needs to get the answer
>>>>>> right, not H1, and it doesn't
>>>>>>
>>>>>> If you want to claim that they are the same machine, you need to
>>>>>> explain how they give different answers for the same input, which
>>>>>> shows they are Computations.
>>>>>>   
>>>>>>> If you knew the x86 language and software engineering well enough
>>>>>>> you would know that the following execution trace of the
>>>>>>> simulation of P(P) matches the infinite recursion behavior pattern
>>>>>>> and you would know that the infinite recursion behavior pattern is
>>>>>>> correct.
>>>>>>
>>>>>> Nope, since it skips over the CONDITIONAL code of H.
>>>>>>
>>>>>> That code needs to be traced and shown to be unconditional.
>>>>>>   
>>>>>>> THAT YOU SIMPLY DON'T KNOW THESE THINGS WELL ENOUGH IS PROVEN BY
>>>>>>> THE FACT THAT YOU ALWAYS CHANGE THE SUBJECT INSTEAD OF DIRECT
>>>>>>> POINTING OUT ANY ERROR
>>>>>>>   
>>>>>>
>>>>>> WRONG. I keep pointing out that you build your arguement on false
>>>>>> foundations.
>>>>>>    >
>>>>>>> Begin Local Halt Decider Simulation at Machine Address:c36
>>>>>>> [00000c36][002117ca][002117ce] 55          push ebp
>>>>>>> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
>>>>>>> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
>>>>>>> [00000c3c][002117c6][00000c36] 50          push eax       // push P
>>>>>>> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
>>>>>>> [00000c40][002117c2][00000c36] 51          push ecx       // push P
>>>>>>> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call
>>>>>>> H(P,P)
>>>>>>>
>>>>>>> [00000c36][0025c1f2][0025c1f6] 55          push ebp
>>>>>>> [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
>>>>>>> [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
>>>>>>> [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
>>>>>>> [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
>>>>>>> [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
>>>>>>> [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call
>>>>>>> H(P,P) Local Halt Decider: Infinite Recursion Detected Simulation
>>>>>>> Stopped
>>>>>>>
>>>>>>> This infinite recursion detection criteria are met by the above
>>>>>>> execution trace:
>>>>>>> (a) P calls H twice in sequence from the same machine address.
>>>>>>> (b) With the same parameters: (P,P) to H.
>>>>>>> (c) With no conditional branch or indexed jump instructions in the
>>>>>>> execution trace of P.
>>>>>>
>>>>>> Only because the trace is incorrect.
>>>>>>   
>>>>>>> (d) We know that there are no return instructions in H because we
>>>>>>> know that H is in pure simulation mode.
>>>>>>
>>>>>>
>>>>>> The H can NEVER answer even as a top level machine, so THAT is
>>>>>> false too.
>>>>>>
>>>>>> Remember there is no such thing a 'Pure Simulator Mode', something
>>>>>> is or it isn't a Pure Simulator. H isn't if it ever answer H(H^,H^)
>>>>>>   
>>>>>
>>>>> That the entire time that the halt decider is making its halt status
>>>>> decision the halt decider has no behavior what-so-ever that can have
>>>>> any effect on the behavior of its simulated input seems to be beyond
>>>>> your intellectual capacity to comprehend.
>>>>
>>>> The ad hominem attack is a logical fallacy: attack the argument and not
>>>> the person and progress might be made.
>>>>
>>>> /Flibble
>>>>
>>>
>>> It seems to be an objective fact that most people here simply do not
>>> want an honest dialogue and/or lack the intellectual capacity /
>>> prerequisite knowledge to comprehend what is being said.
>>>
>>> This is assessed on the basis that no actual valid reasoning is applied
>>> as rebuttals to my ideas. Most of the fake rebuttals are the dishonest
>>> dodge tactic of changing the subject rather than directly addressing any
>>> key points that have been made, AKA the strawman error:
>>>
>>> A straw man (sometimes written as strawman) is a form of argument and an
>>> informal fallacy of having the impression of refuting an argument,
>>> whereas the real subject of the argument was not addressed or refuted,
>>> but instead replaced with a false one.
>>> https://en.wikipedia.org/wiki/Straw_man
>>>
>>
>> It is an objective fact that MANY actual valid rebuttals have been made
>> to your arguements,
> Gullible fools may believe this.
>
> Gullible fools are not bright enough to recognize a subtle case of the
> strawman error.
>

On Friday, 17 September 2021 at 19:41:45 UTC+1, olcott wrote:
>
> A straw man (sometimes written as strawman) is a form of argument and an
> informal fallacy of having the impression of refuting an argument,
> whereas the real subject of the argument was not addressed or refuted,
> but instead replaced with a false one.
>
I wrote a book called "12 Common Atheist Arguments (refuted)" where I
presented 12 common arguments made by atheists, and refuted them.
Inevitably I was accused of presenting "strawman" argments. However
when I asked "how has that argument been weakened and why is the
case I presented weak?" I didn't get many sensible replies. I did get one
for the "Evil Bible" argument. A chap on alt.atheism used to post scriptures
such as the ones demanding the extermination of the Amalekites.
He said that his posts were an argument against God as most Christians
conceived Him, but not a God of grandeur and vengeance as the Ancient
Israelites conceived Him. But he did concede that his goal was to show that
God didn't exist.

So he kind of had a point, but not a very strong one.

If you can't explain how your arguments have been weakened, and why the
weakened versions are weak, but the corrected versions are stronger,
then you can't really plead "strawman". It's rhetorically a dangerous plea,
since it involves conceding that there are weak arguments that can be
advanced for your case.

On 9/17/2021 5:11 PM, Malcolm McLean wrote:
> On Friday, 17 September 2021 at 19:41:45 UTC+1, olcott wrote:
>>
>> A straw man (sometimes written as strawman) is a form of argument and an
>> informal fallacy of having the impression of refuting an argument,
>> whereas the real subject of the argument was not addressed or refuted,
>> but instead replaced with a false one.
>>
> I wrote a book called "12 Common Atheist Arguments (refuted)" where I
> presented 12 common arguments made by atheists, and refuted them.
> Inevitably I was accused of presenting "strawman" argments. However
> when I asked "how has that argument been weakened and why is the
> case I presented weak?" I didn't get many sensible replies. I did get one
> for the "Evil Bible" argument. A chap on alt.atheism used to post scriptures
> such as the ones demanding the extermination of the Amalekites.
> He said that his posts were an argument against God as most Christians
> conceived Him, but not a God of grandeur and vengeance as the Ancient
> Israelites conceived Him. But he did concede that his goal was to show that
> God didn't exist.
>
> So he kind of had a point, but not a very strong one.
>
> If you can't explain how your arguments have been weakened, and why the
> weakened versions are weak, but the corrected versions are stronger,
> then you can't really plead "strawman". It's rhetorically a dangerous plea,
> since it involves conceding that there are weak arguments that can be
> advanced for your case.
>

I don't really care whether others understand that none of what has been
presented as a rebuttal can accurately be construed as such mostly
because hardly anyone here really cares about that. Their goal is to
look like that have provided a rebuttal to others here.

Of the people here you may be the only one that has any serious interest
in the actual truth.

If you pay very close attention you will notice that when I make a point
that X is proved by A,B,C, every rebuttal always changes the subject
away from the exactly precise proposition of X into another proposition
entirely that is very subtly different than X, hence an actual case of
strawman.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein