On 2021-08-19 12:35, olcott wrote:
> On 8/19/2021 12:22 PM, André G. Isaak wrote:
>> On 2021-08-19 11:13, olcott wrote:
>>> On 8/19/2021 12:04 PM, André G. Isaak wrote:
>>>> On 2021-08-19 10:52, olcott wrote:
>>>>> On 8/19/2021 11:44 AM, André G. Isaak wrote:
>>>>>> On 2021-08-19 09:40, olcott wrote:
>>>>>>> On 8/19/2021 10:30 AM, André G. Isaak wrote:
>>>>>>
>>>>>>>> No one is 'ignoring key words'. What you state above is simply
>>>>>>>> wrong.
>>>>>>>>
>>>>>>>> First, your H *never* acts as a pure simulator. A pure simulator
>>>>>>>> would behave as follows:
>>>>>>>>
>>>>>>>
>>>>>>> The behavior of H while H is in pure simulation mode is
>>>>>>> computationally equivalent to the behavior of a pure simulator in
>>>>>>> that while H is in pure simulation mode it has no effect
>>>>>>> what-so-ever on the behavior of its input.
>>>>>>
>>>>>> So first you complain about people 'ignoring your words', and then
>>>>>> you completely ignore all of the points I make below and simply
>>>>>> repeat your assertion?
>>>>>>
>>>>>
>>>>> Do you understand what the term: "computationally equivalent" means?
>>>>>
>>>>> Do you understand that the behavior of H while H is in pure
>>>>> simulation mode is not the same as the behavior of H while H is NOT
>>>>> in pure simulation mode?
>>>>
>>>> Maybe you should reread my original post. The points below were all
>>>> in response to your claim that:
>>>>
>>>> "WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE SIMULATOR
>>>> OF ITS INPUT. "
>>>>
>>>> There's no mention in the above of H acting in 'pure simulation
>>>> mode'. H is clearly acting as a halt decider in the above case.
>>>
>>>
>>> WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE SIMULATOR
>>> OF ITS INPUT.
>>
>> Which is false, as I explain in the points below which you continue to
>> ignore.
>>
>
> WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE SIMULATOR OF
> ITS INPUT (before it switches to halt decider mode) its act of merely
> examining the behavior of its input cannot possibly have any effect
> what-so-ever on the behavior of this input.

And, once again, you simply reiterate your position without actually
addressing the points I make below.

Most importantly, you need to answer my question about what you mean by
'mode'. Previously, you seemed to be suggesting your H had two separate
modes in which it runs in either one or the other.

Now you seem to be suggesting it can switch modes mid-execution.

If by 'switches to halt decider mode' you simply mean 'decides to
abort', then ALL of the objections I make below still stand and you need
to address them.

If you mean something else, you really need to explain what it means to
'switch modes' and what causes H to switch from one mode to another.

> Has this exceeded your capacity to understand?
>
>>> WHILE H IS ACTING AS A PURE SIMULATOR H CANNOT POSSIBLY HAVE ANY
>>> EFFECT ON THE BEHAVIOR OF ITS INPUT.
>>
>> Since it isn't acting as a pure simulator, this is also false. See the
>> explanation in the points below which you continue to ignore.
>>
>>> WHILE H CANNOT POSSIBLY HAVE ANY EFFECT ON THE BEHAVIOR OF ITS INPUT
>>> H NEED NOT EXAMINE ITS OWN EXECUTION TRACE IN ITS HALT STATUS DECISION.
>>
>> Which, again, is false. See the explanation in the points below which
>> you continue to ignore.
>>
>>> Try and find a specific flaw in that, there are one.
>>>
>>> Changing the subject to a different subject is also an act of
>>> dishonesty that I call a dishonest dodge.
>>
>> Since the points made below all *specifically* address the points you
>> made above, how is that 'changing the subject'? *You* changed the
>> subject by talking about 'pure simulator mode'
>>
>>>
>>>>
>>>> And you need to clarify what you mean by 'mode'. You keep talking
>>>> about your H running in different 'modes' without clarifying how you
>>>> tell H what 'mode' to operate in. I am assuming your 'pure simulator
>>>> mode' is simply H with the halt decision code commented out. What
>>>> happens in this 'mode' has no bearing on what happens in 'halt
>>>> decider mode', which is the only thing we are actually concerned with.
>>
>> And you still need to address the above question.
>>
>> André
>>
>>>> It's fine to change the OUTERMOST H to 'pure simulator mode' to test
>>>> the results of H, but if you also change the H inside P to 'pure
>>>> simulator mode', then you are simulating an entirely different
>>>> computation from the one which H is being asked about which renders
>>>> the results of that test entirely meaningless.
>>>>
>>>>> You are very obviously merely glancing at my words before
>>>>> artficially contriving a rebuttal that does not carefully take into
>>>>> account every meaning of every word that I said.
>>>>>
>>>>> I count this carelessness as dishonesty and no mere honest mistake.
>>>>>
>>>>>
>>>>>>>
>>>>>>>> (1) fetch an opcode
>>>>>>>> (2) emulate that opcode on the operands which follow
>>>>>>>> (4) advance to the next opcode and go back to step (1)
>>>>>>>>
>>>>>>>> Your H behaves as follows:
>>>>>>>>
>>>>>>>> (1) fetch an opcode
>>>>>>>> (2) emulate that opcode on the operands which follow
>>>>>>>> (3) decide whether to continue the simulation or not
>>>>>>>>
>>>>>>>>     (4a) if we decide not to continue, abort the simulation.
>>>>>>>>     (4b) if we decide to continue, advance to the next opcode
>>>>>>>> and go back
>>>>>>>>          to step (1)
>>>>>>
>>>>>> Do you not see the crucial difference between the above two?
>>>>>>
>>>>>>>> A pure simulator doesn't contain step (3). And step (3) means
>>>>>>>> that after *every* instruction there is a potential for the
>>>>>>>> decider to have an effect on the simulation of its input.
>>>>>>>>
>>>>>>>> When the input to H contains another call to H (call it H2),
>>>>>>>> that begins a *new* simulation and every single step of that
>>>>>>>> simulation includes step (3) which has the potential to abort
>>>>>>>> the simulation.
>>>>>>>>
>>>>>>>> We can say that your H 'sort of' acts like a pure simulator at
>>>>>>>> each step where, in step (3), it decides to continue with the
>>>>>>>> simulation. But when your H *ignores* the instructions in H2, it
>>>>>>>> never sees those decisions about whether to continue with the
>>>>>>>> simulation or not.
>>>>>>>>
>>>>>>>> This is exactly why your H(P, P) generates the wrong answer.
>>>>>>>>
>>>>>>>> When we execute P(P) it halts. Why? Because at some point in the
>>>>>>>> simulation of P within P(P) step (3) of the simulation decides
>>>>>>>> to abort the simulation.
>>>>>>>>
>>>>>>>> H(P, P) claims that P(P) doesn't halt because it *ignores* that
>>>>>>>> crucial decision made by P to abort the simulation.
>>>>>>>>
>>>>>>>> Its perfectly legitimate for H to ignore its *own* code. After
>>>>>>>> all, its own code isn't part of the input which it is analyzing.
>>>>>>>> But it cannot ignore H2 since that *is* part of the input which
>>>>>>>> it is analyzing.
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

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