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.

>>>>>> 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.

>>>>>> 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)

(C) H MUST stop its simulation of P or P never halts

(D) H stops its simulation of P for some other reason.

>> 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.

> 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.

--
Copyright 2021 Pete Olcott

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