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, to which you have rarely, if ever, actually made any
attempt to refure.

You have shown an UTTER lack of the prerequisite knowledge of the field
you are making claims about.

You claim things to be 'obvious by the meaning of their words', yet you
show you have no real understanding of the actual meaning of the words,
particulally as the relate to the field you claim to be making a major
discovery in.

You seem to have no idea what a Computation really is, and thus no idea
what a Computational Equivalent is, which is the foundation for your
arguement.

You seem to have no real understand of what a Turing Machine is, you may
be able to spout a few words that sort of make sense about them, but
have shown NO ability to actually create one or understand how they
work. You make 'obvious' claims about them that are definitionally false.

YOU are the one who doesn't seem to be willing to engage in an honest
dialog, ignoring or bashing people if they won't follow the script that
you want followed. A discussion is NOT scripted in that manner. When a
statement you make has broken groundwork behind it, that groundwork IS
open for discussion.

You come claiming to look for input to help improve your 'proof', if
that REALLY is your goal, take the input, your whole argument is on
broken premises, and NOBODY will accept a paper based on that.

You need to learn what an actual proof needs to look like, EVERYTHING
that you have broght forward has been really low level philosophical
rhetoric which might be suitable for the broader discussion of
comparative logical theory, but do not meet the requirements of the
rigorous mathematically logic using in this area of theory.

I think part of the issue is that you seem to be thinking under a
different fundamental rule of how logic works than what this branch
uses, but I don't think you understand that, and you just seem to think
that the logic used in mathemematics is just 'wrong', not understanding
that it was proved a long time ago that the logic system you seem to
want to think in just is incompatible with the basics of mathematics and
is unable to deal with it.