On 2021-06-22 11:05, olcott wrote:
> On 6/22/2021 11:47 AM, André G. Isaak wrote:
>> On 2021-06-21 21:09, olcott wrote:
>>> On 6/21/2021 9:29 PM, André G. Isaak wrote:
>>>> On 2021-06-21 19:39, olcott wrote:
>>>>> On 6/21/2021 7:57 PM, André G. Isaak wrote:
>>>>>> On 2021-06-21 15:11, olcott wrote:
>>>>>>> On 6/21/2021 1:24 PM, André G. Isaak wrote:
>>>>>>>> On 2021-06-20 23:04, Chris M. Thomasson wrote:
>>>>>>>>> On 6/20/2021 9:15 PM, olcott wrote:
>>>>>>>>>> If you see an animal and test its DNA and confirm that it is
>>>>>>>>>> definitely a cat, what happens when the cat barks?
>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>> Have you been hearing cats bark lately? Wow.
>>>>>>>>
>>>>>>>> As long as he's just hearing them bark, we're probably fine.
>>>>>>>>
>>>>>>>> It's when the barking cats start telling him to do things (like
>>>>>>>> kill neighbours, steal catnip, or conquer Liechtenstein) that we
>>>>>>>> really need to worry.
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>
>>>>>>> The point is that the mere intuition about the halting behavior
>>>>>>> of Ĥ applied to ⟨Ĥ⟩ is superseded by meticulous sound deductive
>>>>>>> inference.
>>>>>>>
>>>>>>> SELF-EVIDENT-TRUTH
>>>>>>> Every computation that never halts unless its simulation is
>>>>>>> aborted is a computation that never halts.
>>>>>>
>>>>>> How can that possibly be "self-evident" when it doesn't even
>>>>>> explain what "its simulation" means. Its simulation of/by what?
>>>>>>
>>>>>
>>>>> We could simplify this and say that any computation that never
>>>>> halts unless this computation is aborted is a computation that
>>>>> never halts.
>>>>
>>>> That's no better. A computation which is aborted doesn't halt.
>>>> 'Halt' means to reach one of the final states. If you abort
>>>> something it doesn't reach a final state. But the simulator itself can.
>>>>
>>>
>>> When we are trying to determine whether or not an infinite loop is an
>>> infinite loop we can debug step through this code and see that it
>>> endlessly repeats and there is no escape from this endless repetition
>>> in this code. It is not really that hard.
>>
>> Which has nothing to do with what I wrote.
>>
>
> It explains the details of how a computation that must be aborted by the
> halt decider to prevent the infinite execution of this computation <is>
> a computation that never halts.

Which, once again, has nothing to do with what I wrote.

>>>>>>> SELF-EVIDENT-TRUTH
>>>>>>> The ⟨Ĥ⟩ ⟨Ĥ⟩ input to the embedded halt decider at Ĥ.qx is a
>>>>>>> computation that never halts unless its simulation is aborted.
>>>>>>
>>>>>> If that were self-evident, you wouldn't have so many people
>>>>>> pointing out to you that it is simply wrong. Things can't be both
>>>>>> wrong and self-evident.
>>>>>>
>>>>>
>>>>> That people simply don't want to bother to pay enough attention to
>>>>> see that I am right is not actually any rebuttal at all.
>>>>>
>>>>>>> ∴ IMPOSSIBLY FALSE CONCLUSION
>>>>>>
>>>>>> "Impossibly false" is a meaningless expression. No journal is
>>>>>> going to take you seriously if this phrase appears anywhere in
>>>>>> your work.
>>>>>>
>>>>>
>>>>> I improved this. I now call it the conclusion of sound deduction,
>>>>> which means exactly the same thing as impossibly false.
>>>>
>>>> So where is the sound deduction from which you reach the above
>>>> conclusion? You start with two premises, one of which is too vague
>>>> to be interpreted and the other of which is simply false. That's not
>>>> how deductively sound arguments work.
>>>
>>> We really have to look at this in terms of H and P because there is
>>> no other possible way to make sure that we examine all the details
>>> when we try to imagine what a Turing machine might do.
>>
>> Which doesn't answer my question. Where is your 'sound deductive
>> argument'?
>>
>
> (a) Every computation P that never halts unless the halt decider H
> aborts this computation is a computation that never halts.
>
> (b) X is a computation that never halts unless it is aborted by its halt
> decider.
>
> ∴ (c) X is a computation that is correctly decided to be a computation
> that never halts.

Premise (b) is false, so this is not a 'sound deductive argument'

>>>>>>> The embedded simulating halt decider at Ĥ.qx correctly decides
>>>>>>> its input: ⟨Ĥ⟩ ⟨Ĥ⟩ is a computation that never halts.
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ specifies an infinite chain of invocations that is
>>>>>>> terminated at its third invocation. The first invocation of Ĥ.qx
>>>>>>> ⟨Ĥ⟩, ⟨Ĥ⟩ is the first element of an infinite chain of invocations.
>>>>>>>
>>>>>>> It is common knowledge that when any invocation of an infinite
>>>>>>> chain of invocations is terminated that the whole chain
>>>>>>> terminates. That the first element of this infinite chain
>>>>>>> terminates after its third element has been terminated does not
>>>>>>> entail that this first element is an actual terminating computation.
>>>>>>
>>>>>> No. It isn't "common knowledge". It is simply false.
>>>>>>
>>>>>
>>>>> I will make a common knowledge concrete example:
>>>>> Infinite recursion is an infinite sequence of invocations right?
>>>>
>>>> Sure, but there is no infinite recursion (or recursion period) in
>>>> the Linz example.
>>>>
>>>>> If any element of the infinite sequence of invocations of infinite
>>>>> recursion is aborted then the whole sequence stops right?
>>>>
>>>> Not necessarily. That depends entirely on what is meant by 'abort'.
>>>>
>>>>> If the third invocation of the infinite sequence of invocations of
>>>>> infinite recursion is aborted then the whole sequence stops right?
>>>>
>>>> No. The third invocation is aborted. The simulator itself continues
>>>> to run and is able to halt.
>>>>
>>>>> Was it really that hard to see the above three steps on the basis
>>>>> of my claim of common knowledge?
>>>>
>>>> Things that you believe and 'common knowledge' are not the same thing.
>>>>
>>>>>> And if the simulation is terminated after the third call to Ĥ, the
>>>>>> you don't have an infinite chain of calls. You have a chain of
>>>>>> three calls.
>>>>>>
>>>>>
>>>>> When the halt decider is analyzing the behavior stipulated by a
>>>>> finite string it is incorrect for the halt decider to conflate its
>>>>> own behavior in this analysis.
>>>>
>>>> And I am not conflating them. When you abort the simulation that
>>>> doesn't entail aborting the simulator. You conflate them by
>>>> concluding that the topmost program doesn't halt based on what
>>>> happens to the program it is simulating.
>>>>
>>>>> The question that the halt decider is answering is whether or not a
>>>>> pure simulation/execution of the input must be aborted to prevent
>>>>> the infinite execution of this input.
>>>>>
>>>>>>> For the first element to be an actual terminating computation it
>>>>>>> must terminate without any of the elements of the infinite chain
>>>>>>> of invocations being terminated.
>>>>>>
>>>>>> This is just plain silly.
>>>>>
>>>>> See my infinite recursion example above.
>>>>
>>>> As I said, the above is just plain silly.
>>>>
>>>>>> If some program H simulates another program Y along with an input
>>>>>> string but has the ability to terminate a simulation, then there
>>>>>> are three possibilities:
>>>>>>
>>>>>> A) The simulation is allowed to continue until Y reaches one of
>>>>>> its final states. In such a case we can say that Y halts. Since Y
>>>>>> halts, H can also halt.
>>>>>>
>>>>>> B) The simulation is allowed to continue forever, but it never
>>>>>> reaches a final state. The simulation continues forever. In this
>>>>>> case, Y doesn't halt. H therefore also doesn't halt. Of course,
>>>>>> this option would be difficult to empirically verify since we
>>>>>> can't actually observe something running for an infinite amount of
>>>>>> time.
>>>>>>
>>>>>> C) H decides to discontinue the simulation. In this case the
>>>>>> simulation neither halts nor runs forever. It may be that that Y
>>>>>> is non-halting, or it may be that H simply discontinued the
>>>>>> simulation prematurely. But in either of these two cases, H can halt.
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> As I have said so very many hundreds of times now that you really
>>>>> should not have made such a terrible mistake with part C
>>>>
>>>> There is no mistake in C.
>>>
>>>
>>> C) H decides to discontinue the simulation.
>>> This is very terribly incorrect
>>>
>>> H MUST stop its simulation of P or P never halts
>>
>> Which is subsumed under option C. The above enumerates all logical
>> possibilities.
>>
>
> Then you needs a (D)

Why?

> (C) H MUST stop its simulation of P or P never halts
>
> (D) H stops its simulation of P for some other reason.

Your (C) and (D) are both covered by my (C).

>>> H MUST stop its simulation of P or P never halts
>>> H MUST stop its simulation of P or P never halts
>>> H MUST stop its simulation of P or P never halts
>>> H MUST stop its simulation of P or P never halts
>>>
>>> This is not at all the same thing as H arbitrarily stops simulating P
>>> for possibly no good reason at all.
>>
>> Option C never said anything about why it aborts the simulation.
>
> That is its horribly terrible error. To simply ignore the key most
> important halt deciding criteria is a terribly awful mistake.

Clearly you have reading comprehension problems. The halting status of
the *simulator* has nothing to do with the halting status of its input
computation if the simulator is capable of aborting the simulation of
that input. That applies equally to your (C) and your (D). In either
case, the simulator can halt.

>> Whether it aborts it because it MUST do so (or, in your case, because
>> you think it MUST stop its simulation) or for some other reason, or
>> for no reason at all, H can still halt.
>>
>
> When-so-ever H must abort its input to prevent the infinite execution of
> this input H always correctly decides that this input never halts 100%
> of all the time.
>
> We can know this in the same way that we know that a dead person is not
> alive.
>
>>> This is not at all the same thing as H arbitrarily stops simulating P
>>> for possibly no good reason at all.
>>>
>>> This is not at all the same thing as H arbitrarily stops simulating P
>>> for possibly no good reason at all.
>>>
>>> This is not at all the same thing as H arbitrarily stops simulating P
>>> for possibly no good reason at all.
>>>
>>>
>>>> Your 'self-evident' truths are wrong, as virtually everyone posting
>>>> here has pointed out.
>>>>
>>>>> When H must terminate the simulation of its input to prevent the
>>>>> infinite execution of P then H does necessarily infallibly
>>>>> correctly decide that its input never halts.
>>>>>
>>>>> Unlike Turing machines where we must simply imagine crucially
>>>>> important details and have no way to infallibly ascertain that our
>>>>> imagination
>>>>
>>>> Exactly which 'crucially important details' do you think we need to
>>>> imagine?
>>>
>>> 100% of every single detail of the execution trace of the input
>>> without the most minute details not totally and completely specified.
>>> We just flat out can't do that with TM's of the sophistication of H
>>> and P.
>>
>> Of course we can. People work with actual Turing Machines all the time
>> and they don't have to 'imagine' anything.
>
> Only for very trivial things.
> No one has even attempted to write a C to TM compiler.
>
>> You just don't want to work with actual Turing Machines because you
>> don't understand what they are or how they work.
>>
>> André
>>
>
> The lack of direct memory access cripples the expressiveness of the TM
> model.

You really should learn something about Turing Machines. You really
don't grasp what they are for.

André

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