On 8/28/2021 7:15 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/27/2021 7:01 PM, Ben Bacarisse wrote:
>>> André G. Isaak <agisaak@gm.invalid> writes:
>>>
>>>> On 2021-08-27 10:18, olcott wrote:
>>>>> On 8/27/2021 10:57 AM, André G. Isaak wrote:
>>>
>>>>>> Ben never made any claims that it didn't perform some operation
>>>>>> which could be construed as the functional equivalent of copying a
>>>>>> string. He claimed that there was no *literal* copying involved
>>>>>> except in the first instance.
>>> Indeed. I see in my absence there's been a flurry of "Ben is wrong"
>>> posts from PO. Thanks, to you and RD, for stepping in.
>>>
>>>>> So in other words he said that my high level abstraction was wrong on
>>>>> the basis that it was a high level abstraction and did not delve into
>>>>> the tedious details of how this high level abstraction is
>>>>> implemented.
>>>>
>>>> No, he was claiming that your high level abstraction was *misleading*
>>>> and belied a lack of understanding of UTMs on your part.
>>> At the time I was actually calling out hard errors of fact, not just
>>> misleading abstractions. I was (dangerously) prepared to go along with
>>> the abstract view, as I (and others) have done for some time, because,
>>> whilst I agree it is potentially misleading, it's not actually wrong.
>>> But PO did not think he was talking about abstractions at the time I
>>> called him out on the mistake. He really did think that if you do the
>>> "hat" construction on a TM that is little more that a UTM, then it --
>>> the actual TM we'd call UTM^ -- has a cycle in its state graph allowing
>>> it to go from what he calls qx (the UTM's q0) back (via other states of
>>> course) to UTM^'s q0. And he thought that this loop is what wrote the
>>> endless literal copies. He used Linz's notation for TM configurations
>>> to show the strings right there on the tape next to each other, mid
>>> computation, with q0 being entered again and again.
>>
>> It does have literal endless copies and no one besides you has claimed
>> otherwise.
>
> (1) Of something, yes, but of what? Not of what you claimed.
>

When the TM copies a string the UTM must perform the functional
equivalent of copying a string. It could be as simple as a literal copy
of a string (with the additional overhead of simulation). From the
simulated TM's perspective it is a literal copy of a string.

> (2) Are you backing down from your claim about the loop in the state
> transition graph?
>

The loop in the state transition graph applies to the template as I
explicitly showed in the execution trace:

Ĵ copies its input ⟨Ĵ1⟩ to ⟨Ĵ2⟩ then simulates this input Ĵ1 with its
input ⟨Ĵ2⟩
which copies its input ⟨Ĵ2⟩ to ⟨Ĵ3⟩ then simulates this input Ĵ2 with
its input ⟨Ĵ3⟩
which copies its input ⟨Ĵ3⟩ to ⟨Ĵ4⟩ then simulates this input Ĵ3 with
its input ⟨Ĵ4⟩ ...

Ĵ copies Ĵ.qx simulates which essentially transitions to Ĵ1.q0.
This is not the conventional notion of a state transition within the
same machine. It is a more figurative use of the term so the gist of the
behavior can be understood. I changed my paper so that it no longer
refers to this cycle because the unconventional use of a term could be
more difficult to understand.

H.q0 ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* H.qy
H.q0 ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* H.qy

The bottom line of all of this is that H could recognize the infinitely
nested simulation of Ĵ applied to ⟨Ĵ⟩ and correctly decide that Ĵ
applied to ⟨Ĵ⟩ never halts.

> (3) You have it backwards. I only see posters agreeing with me on this
> topic.

They are careful to use double-talk that does not directly contradict
what you said. Since it is possible that the simulated Ĵ could perform a
literal string copy (having the additional overhead of simulation) your
statement that this is not what is occurring is flat out incorrect.

>>> Even if he now tries to suggest that he was using the notation in some
>>> sort of abstract way, the explicit cycle in the states gives a lie to
>>> that. He thought it was actual, literal, symbol by symbol copying every
>>> time, exactly as the extra states added by the hat construction do it.
>

--
Copyright 2021 Pete Olcott

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

On 8/28/2021 7:18 AM, Richard Damon wrote:
> On 8/28/21 12:46 AM, olcott wrote:
>> On 8/27/2021 6:51 PM, Richard Damon wrote:
>>> On 8/27/21 10:16 AM, olcott wrote:
>>>> On 8/26/2021 7:38 PM, Richard Damon wrote:
>>>>> On 8/26/21 8:53 AM, olcott wrote:
>>>>>> On 8/26/2021 5:41 AM, Richard Damon wrote:
>>>>>>> On 8/25/21 11:50 PM, olcott wrote:
>>>>>>>> On 8/25/2021 10:21 PM, Richard Damon wrote:
>>>>>>>>> On 8/25/21 11:10 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>>> Too disingenuous to continue.
>>>>>>>>>>
>>>>>>>>>> Excellent!  Mind you, you've said you won't talk go to me many
>>>>>>>>>> times
>>>>>>>>>> before and I always end up disappointed.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes, me too. It is clear that when people clearly point out his
>>>>>>>>> mistakes, his brain starts to go crazy and he finds it
>>>>>>>>> irresistible to
>>>>>>>>> lash out and try to muddy the air with some illogic to try and
>>>>>>>>> hide the
>>>>>>>>> clear rebuttal.
>>>>>>>>>
>>>>>>>>> I think he hopes that the thread will go off some other
>>>>>>>>> direction and
>>>>>>>>> the clear rebuttal will be forgotten.
>>>>>>>>>
>>>>>>>>> THAT is why he calls them 'dishonest dodges', he thinks if he says
>>>>>>>>> that
>>>>>>>>> enough some people might beleive it and not look at them.
>>>>>>>>>
>>>>>>>>
>>>>>>>> This is the crux of my whole proof try and refute it without
>>>>>>>> changing
>>>>>>>> the subject or talking in circles:
>>>>>>>>
>>>>>>>> Simulating Halt Decider Theorem (Olcott 2020):
>>>>>>>> A simulating halt decider correctly decides that any input that
>>>>>>>> never
>>>>>>>> halts unless the simulating halt decider aborts its simulation of
>>>>>>>> this
>>>>>>>> input is an input that never halts.
>>>>>>>>
>>>>>>>
>>>>>>> Easy, Fundamental Definitions (do you disagree with any of these):
>>>>>>>
>>>>>>> The Definition of a Computation: The act of performing a Step by Step
>>>>>>> Algorithm on an input data to get an answer. The Algorithm needs to
>>>>>>> precisely state exactly what operations to perform and the input
>>>>>>> needs
>>>>>>> to specify all the variable data for the caluclation.
>>>>>>>
>>>>>>> Since a Computation fully specifies what is done and what it is done
>>>>>>> on,
>>>>>>> every time you run a given computation on the same data you will get
>>>>>>> the
>>>>>>> same answer.
>>>>>>>
>>>>>>> The Definition of A Halting Computation is CDomputatiion that
>>>>>>> reaches a
>>>>>>> halting state in a finite numb4r of steps. A Non-Halting one is one
>>>>>>> that
>>>>>>> never reaches a Halting state for ANY finite number of Steps.
>>>>>>>
>>>>>>> The Definition of a Halt Decider: A Computation that, when given
>>>>>>> as an
>>>>>>> input the representation of a Computation, is able to correctly
>>>>>>> indicate
>>>>>>> if that Computation is Halting or Non-Halting.
>>>>>>>
>>>>>>> Thus the right answer isn't based on a partial simulation
>>>>>>> performed by
>>>>>>> the decider, but on what the actual machine does.
>>>>>>>
>>>>>>
>>>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>>>> // Strachey(1965) CPL translated to C
>>>>>> void P(u32 x)
>>>>>> {
>>>>>>     if (H(x, x))
>>>>>>       HERE: goto HERE;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>>     Output("Input_Halts = ", H1((u32)P, (u32)P));
>>>>>> }
>>>>>>
>>>>>> H1 determines that its input halts on its input on the basis that H
>>>>>> determines that its input never halts.
>>>>>
>>>>> Yes H THINKS its input never halts, but since the input to H is the
>>>>> exact same input as to H1, the machine it represents is the same, so
>>>>> its
>>>>> behavior MUST be the same.
>>>>>
>>>>> Think about what you are trying to claim.
>>>>>
>>>>
>>>> I don't have to think about it. H1 does correctly decide that P halts on
>>>> the basis that H correctly decides that its input never halts.
>>>
>>> No, you wouldn't think about it would you.
>>>>
>>>> H1 has identical machine code and inputs to H.
>>>> It is the execution order that makes the difference in the results.
>>>>
>>>> H1 can see all of the code that it simulates, H can see all of the code
>>>> that its simulates, H1 cannot see any of the code that H simulates.
>>>
>>> Since H1 and H are copies of each other and H(P,P) and H1(P,P) give
>>> different answer, you have just proved that your H is NOT a computation,
>>
>> H(P,P) and H1(P,P) give a different answer because of their different
>> placement in the execution sequence.
>
> Thus, they aren't computations, as 'placement in the execution sequence'
> isn't one of their inputs, and thus not ALLOWED to change their answer.
H1(P,P) simulates P(P) as a slave process which executes H(P,P) as a
part of this same slave process. H(P,P) simulates P(P) as its own slave
process that H1 cannot see because each halt decider is a pure function
of its own inputs. Because H1 and H are at different machine addresses
they are not the same function executed with the same data.

--
Copyright 2021 Pete Olcott

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

On 8/28/2021 9:47 AM, olcott wrote:
> On 8/28/2021 7:18 AM, Richard Damon wrote:
>> On 8/28/21 12:46 AM, olcott wrote:
>>> On 8/27/2021 6:51 PM, Richard Damon wrote:
>>>> On 8/27/21 10:16 AM, olcott wrote:
>>>>> On 8/26/2021 7:38 PM, Richard Damon wrote:
>>>>>> On 8/26/21 8:53 AM, olcott wrote:
>>>>>>> On 8/26/2021 5:41 AM, Richard Damon wrote:
>>>>>>>> On 8/25/21 11:50 PM, olcott wrote:
>>>>>>>>> On 8/25/2021 10:21 PM, Richard Damon wrote:
>>>>>>>>>> On 8/25/21 11:10 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>>> Too disingenuous to continue.
>>>>>>>>>>>
>>>>>>>>>>> Excellent!  Mind you, you've said you won't talk go to me many
>>>>>>>>>>> times
>>>>>>>>>>> before and I always end up disappointed.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Yes, me too. It is clear that when people clearly point out his
>>>>>>>>>> mistakes, his brain starts to go crazy and he finds it
>>>>>>>>>> irresistible to
>>>>>>>>>> lash out and try to muddy the air with some illogic to try and
>>>>>>>>>> hide the
>>>>>>>>>> clear rebuttal.
>>>>>>>>>>
>>>>>>>>>> I think he hopes that the thread will go off some other
>>>>>>>>>> direction and
>>>>>>>>>> the clear rebuttal will be forgotten.
>>>>>>>>>>
>>>>>>>>>> THAT is why he calls them 'dishonest dodges', he thinks if he
>>>>>>>>>> says
>>>>>>>>>> that
>>>>>>>>>> enough some people might beleive it and not look at them.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This is the crux of my whole proof try and refute it without
>>>>>>>>> changing
>>>>>>>>> the subject or talking in circles:
>>>>>>>>>
>>>>>>>>> Simulating Halt Decider Theorem (Olcott 2020):
>>>>>>>>> A simulating halt decider correctly decides that any input that
>>>>>>>>> never
>>>>>>>>> halts unless the simulating halt decider aborts its simulation of
>>>>>>>>> this
>>>>>>>>> input is an input that never halts.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Easy, Fundamental Definitions (do you disagree with any of these):
>>>>>>>>
>>>>>>>> The Definition of a Computation: The act of performing a Step by
>>>>>>>> Step
>>>>>>>> Algorithm on an input data to get an answer. The Algorithm needs to
>>>>>>>> precisely state exactly what operations to perform and the input
>>>>>>>> needs
>>>>>>>> to specify all the variable data for the caluclation.
>>>>>>>>
>>>>>>>> Since a Computation fully specifies what is done and what it is
>>>>>>>> done
>>>>>>>> on,
>>>>>>>> every time you run a given computation on the same data you will
>>>>>>>> get
>>>>>>>> the
>>>>>>>> same answer.
>>>>>>>>
>>>>>>>> The Definition of A Halting Computation is CDomputatiion that
>>>>>>>> reaches a
>>>>>>>> halting state in a finite numb4r of steps. A Non-Halting one is one
>>>>>>>> that
>>>>>>>> never reaches a Halting state for ANY finite number of Steps.
>>>>>>>>
>>>>>>>> The Definition of a Halt Decider: A Computation that, when given
>>>>>>>> as an
>>>>>>>> input the representation of a Computation, is able to correctly
>>>>>>>> indicate
>>>>>>>> if that Computation is Halting or Non-Halting.
>>>>>>>>
>>>>>>>> Thus the right answer isn't based on a partial simulation
>>>>>>>> performed by
>>>>>>>> the decider, but on what the actual machine does.
>>>>>>>>
>>>>>>>
>>>>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>>>>> // Strachey(1965) CPL translated to C
>>>>>>> void P(u32 x)
>>>>>>> {
>>>>>>>      if (H(x, x))
>>>>>>>        HERE: goto HERE;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>>      Output("Input_Halts = ", H1((u32)P, (u32)P));
>>>>>>> }
>>>>>>>
>>>>>>> H1 determines that its input halts on its input on the basis that H
>>>>>>> determines that its input never halts.
>>>>>>
>>>>>> Yes H THINKS its input never halts, but since the input to H is the
>>>>>> exact same input as to H1, the machine it represents is the same, so
>>>>>> its
>>>>>> behavior MUST be the same.
>>>>>>
>>>>>> Think about what you are trying to claim.
>>>>>>
>>>>>
>>>>> I don't have to think about it. H1 does correctly decide that P
>>>>> halts on
>>>>> the basis that H correctly decides that its input never halts.
>>>>
>>>> No, you wouldn't think about it would you.
>>>>>
>>>>> H1 has identical machine code and inputs to H.
>>>>> It is the execution order that makes the difference in the results.
>>>>>
>>>>> H1 can see all of the code that it simulates, H can see all of the
>>>>> code
>>>>> that its simulates, H1 cannot see any of the code that H simulates.
>>>>
>>>> Since H1 and H are copies of each other and H(P,P) and H1(P,P) give
>>>> different answer, you have just proved that your H is NOT a
>>>> computation,
>>>
>>> H(P,P) and H1(P,P) give a different answer because of their different
>>> placement in the execution sequence.
>>
>> Thus, they aren't computations, as 'placement in the execution sequence'
>> isn't one of their inputs, and thus not ALLOWED to change their answer.
> H1(P,P) simulates P(P) as a slave process which executes H(P,P) as a
> part of this same slave process. H(P,P) simulates P(P) as its own slave
> process that H1 cannot see because each halt decider is a pure function
> of its own inputs. Because H1 and H are at different machine addresses
> they are not the same function executed with the same data.

// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
}

int main()
{ Output("Input_Halts = ", H((u32)P, (u32)P));
P((u32)P);
}

The H executed in main() on line 1 is the same function with the same
inputs as the H that is called from P(P) of line 2 of main. These two
instances have identical behavior.

The simulated H called from the P simulated by the executed H on line 1
of main() is the same function called with the same inputs as the
executed H. In this case we have a brand new exception to the rule that
the same function called with the same inputs must have identical behavior.

When one of these function instances is directly executed and the other
is simulated by a simulating halt decider their behavior need not be
identical. The executed function can not be aborted and the simulated
function can be aborted. This forms an exception to the rule that the
same function called with the same input must have identical behavior.

--
Copyright 2021 Pete Olcott

On 8/28/21 10:47 AM, olcott wrote:
> On 8/28/2021 7:18 AM, Richard Damon wrote:
>> On 8/28/21 12:46 AM, olcott wrote:
>>> On 8/27/2021 6:51 PM, Richard Damon wrote:
>>>> On 8/27/21 10:16 AM, olcott wrote:
>>>>> On 8/26/2021 7:38 PM, Richard Damon wrote:
>>>>>> On 8/26/21 8:53 AM, olcott wrote:
>>>>>>> On 8/26/2021 5:41 AM, Richard Damon wrote:
>>>>>>>> On 8/25/21 11:50 PM, olcott wrote:
>>>>>>>>> On 8/25/2021 10:21 PM, Richard Damon wrote:
>>>>>>>>>> On 8/25/21 11:10 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>>> Too disingenuous to continue.
>>>>>>>>>>>
>>>>>>>>>>> Excellent!  Mind you, you've said you won't talk go to me many
>>>>>>>>>>> times
>>>>>>>>>>> before and I always end up disappointed.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Yes, me too. It is clear that when people clearly point out his
>>>>>>>>>> mistakes, his brain starts to go crazy and he finds it
>>>>>>>>>> irresistible to
>>>>>>>>>> lash out and try to muddy the air with some illogic to try and
>>>>>>>>>> hide the
>>>>>>>>>> clear rebuttal.
>>>>>>>>>>
>>>>>>>>>> I think he hopes that the thread will go off some other
>>>>>>>>>> direction and
>>>>>>>>>> the clear rebuttal will be forgotten.
>>>>>>>>>>
>>>>>>>>>> THAT is why he calls them 'dishonest dodges', he thinks if he
>>>>>>>>>> says
>>>>>>>>>> that
>>>>>>>>>> enough some people might beleive it and not look at them.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This is the crux of my whole proof try and refute it without
>>>>>>>>> changing
>>>>>>>>> the subject or talking in circles:
>>>>>>>>>
>>>>>>>>> Simulating Halt Decider Theorem (Olcott 2020):
>>>>>>>>> A simulating halt decider correctly decides that any input that
>>>>>>>>> never
>>>>>>>>> halts unless the simulating halt decider aborts its simulation of
>>>>>>>>> this
>>>>>>>>> input is an input that never halts.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Easy, Fundamental Definitions (do you disagree with any of these):
>>>>>>>>
>>>>>>>> The Definition of a Computation: The act of performing a Step by
>>>>>>>> Step
>>>>>>>> Algorithm on an input data to get an answer. The Algorithm needs to
>>>>>>>> precisely state exactly what operations to perform and the input
>>>>>>>> needs
>>>>>>>> to specify all the variable data for the caluclation.
>>>>>>>>
>>>>>>>> Since a Computation fully specifies what is done and what it is
>>>>>>>> done
>>>>>>>> on,
>>>>>>>> every time you run a given computation on the same data you will
>>>>>>>> get
>>>>>>>> the
>>>>>>>> same answer.
>>>>>>>>
>>>>>>>> The Definition of A Halting Computation is CDomputatiion that
>>>>>>>> reaches a
>>>>>>>> halting state in a finite numb4r of steps. A Non-Halting one is one
>>>>>>>> that
>>>>>>>> never reaches a Halting state for ANY finite number of Steps.
>>>>>>>>
>>>>>>>> The Definition of a Halt Decider: A Computation that, when given
>>>>>>>> as an
>>>>>>>> input the representation of a Computation, is able to correctly
>>>>>>>> indicate
>>>>>>>> if that Computation is Halting or Non-Halting.
>>>>>>>>
>>>>>>>> Thus the right answer isn't based on a partial simulation
>>>>>>>> performed by
>>>>>>>> the decider, but on what the actual machine does.
>>>>>>>>
>>>>>>>
>>>>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>>>>> // Strachey(1965) CPL translated to C
>>>>>>> void P(u32 x)
>>>>>>> {
>>>>>>>      if (H(x, x))
>>>>>>>        HERE: goto HERE;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>>      Output("Input_Halts = ", H1((u32)P, (u32)P));
>>>>>>> }
>>>>>>>
>>>>>>> H1 determines that its input halts on its input on the basis that H
>>>>>>> determines that its input never halts.
>>>>>>
>>>>>> Yes H THINKS its input never halts, but since the input to H is the
>>>>>> exact same input as to H1, the machine it represents is the same, so
>>>>>> its
>>>>>> behavior MUST be the same.
>>>>>>
>>>>>> Think about what you are trying to claim.
>>>>>>
>>>>>
>>>>> I don't have to think about it. H1 does correctly decide that P
>>>>> halts on
>>>>> the basis that H correctly decides that its input never halts.
>>>>
>>>> No, you wouldn't think about it would you.
>>>>>
>>>>> H1 has identical machine code and inputs to H.
>>>>> It is the execution order that makes the difference in the results.
>>>>>
>>>>> H1 can see all of the code that it simulates, H can see all of the
>>>>> code
>>>>> that its simulates, H1 cannot see any of the code that H simulates.
>>>>
>>>> Since H1 and H are copies of each other and H(P,P) and H1(P,P) give
>>>> different answer, you have just proved that your H is NOT a
>>>> computation,
>>>
>>> H(P,P) and H1(P,P) give a different answer because of their different
>>> placement in the execution sequence.
>>
>> Thus, they aren't computations, as 'placement in the execution sequence'
>> isn't one of their inputs, and thus not ALLOWED to change their answer.
> H1(P,P) simulates P(P) as a slave process which executes H(P,P) as a
> part of this same slave process. H(P,P) simulates P(P) as its own slave
> process that H1 cannot see because each halt decider is a pure function
> of its own inputs. Because H1 and H are at different machine addresses
> they are not the same function executed with the same data.
>
>

Ok, so if you aren't claiming that H1 and H represent the same
computation, but are both different but correct halt deciders, you have
just proved that your halting definition is inconsistent as two
different halt deciders just gave the opposite answer but you claim both
are correct.

Since the Halting Status of a Machine is NOT a function of the machine
making the decision.

Now, if you are saying that just because they are at different addresses
but with the same 'algorithm' they are different computations, then this
says that they can't be the Computational Equivalent of the H is Linz,
as two functions that return different answers can't both be the
computational equivalence of the same Turing Machines, and Turing
Machines don't have 'machine addresses' to distinguish which is which.

Thus it appears that you are just proving that nither your H or this new
H1 is the Computational Equivalent of the Turing Machine H referred to
in the Linz proof.

On 8/28/21 11:02 AM, olcott wrote:
> On 8/28/2021 9:47 AM, olcott wrote:
>> On 8/28/2021 7:18 AM, Richard Damon wrote:
>>> On 8/28/21 12:46 AM, olcott wrote:
>>>> On 8/27/2021 6:51 PM, Richard Damon wrote:
>>>>> On 8/27/21 10:16 AM, olcott wrote:
>>>>>> On 8/26/2021 7:38 PM, Richard Damon wrote:
>>>>>>> On 8/26/21 8:53 AM, olcott wrote:
>>>>>>>> On 8/26/2021 5:41 AM, Richard Damon wrote:
>>>>>>>>> On 8/25/21 11:50 PM, olcott wrote:
>>>>>>>>>> On 8/25/2021 10:21 PM, Richard Damon wrote:
>>>>>>>>>>> On 8/25/21 11:10 PM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>>> Too disingenuous to continue.
>>>>>>>>>>>>
>>>>>>>>>>>> Excellent!  Mind you, you've said you won't talk go to me many
>>>>>>>>>>>> times
>>>>>>>>>>>> before and I always end up disappointed.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Yes, me too. It is clear that when people clearly point out his
>>>>>>>>>>> mistakes, his brain starts to go crazy and he finds it
>>>>>>>>>>> irresistible to
>>>>>>>>>>> lash out and try to muddy the air with some illogic to try and
>>>>>>>>>>> hide the
>>>>>>>>>>> clear rebuttal.
>>>>>>>>>>>
>>>>>>>>>>> I think he hopes that the thread will go off some other
>>>>>>>>>>> direction and
>>>>>>>>>>> the clear rebuttal will be forgotten.
>>>>>>>>>>>
>>>>>>>>>>> THAT is why he calls them 'dishonest dodges', he thinks if he
>>>>>>>>>>> says
>>>>>>>>>>> that
>>>>>>>>>>> enough some people might beleive it and not look at them.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This is the crux of my whole proof try and refute it without
>>>>>>>>>> changing
>>>>>>>>>> the subject or talking in circles:
>>>>>>>>>>
>>>>>>>>>> Simulating Halt Decider Theorem (Olcott 2020):
>>>>>>>>>> A simulating halt decider correctly decides that any input that
>>>>>>>>>> never
>>>>>>>>>> halts unless the simulating halt decider aborts its simulation of
>>>>>>>>>> this
>>>>>>>>>> input is an input that never halts.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Easy, Fundamental Definitions (do you disagree with any of these):
>>>>>>>>>
>>>>>>>>> The Definition of a Computation: The act of performing a Step
>>>>>>>>> by Step
>>>>>>>>> Algorithm on an input data to get an answer. The Algorithm
>>>>>>>>> needs to
>>>>>>>>> precisely state exactly what operations to perform and the input
>>>>>>>>> needs
>>>>>>>>> to specify all the variable data for the caluclation.
>>>>>>>>>
>>>>>>>>> Since a Computation fully specifies what is done and what it is
>>>>>>>>> done
>>>>>>>>> on,
>>>>>>>>> every time you run a given computation on the same data you
>>>>>>>>> will get
>>>>>>>>> the
>>>>>>>>> same answer.
>>>>>>>>>
>>>>>>>>> The Definition of A Halting Computation is CDomputatiion that
>>>>>>>>> reaches a
>>>>>>>>> halting state in a finite numb4r of steps. A Non-Halting one is
>>>>>>>>> one
>>>>>>>>> that
>>>>>>>>> never reaches a Halting state for ANY finite number of Steps.
>>>>>>>>>
>>>>>>>>> The Definition of a Halt Decider: A Computation that, when given
>>>>>>>>> as an
>>>>>>>>> input the representation of a Computation, is able to correctly
>>>>>>>>> indicate
>>>>>>>>> if that Computation is Halting or Non-Halting.
>>>>>>>>>
>>>>>>>>> Thus the right answer isn't based on a partial simulation
>>>>>>>>> performed by
>>>>>>>>> the decider, but on what the actual machine does.
>>>>>>>>>
>>>>>>>>
>>>>>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>>>>>> // Strachey(1965) CPL translated to C
>>>>>>>> void P(u32 x)
>>>>>>>> {
>>>>>>>>      if (H(x, x))
>>>>>>>>        HERE: goto HERE;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>>      Output("Input_Halts = ", H1((u32)P, (u32)P));
>>>>>>>> }
>>>>>>>>
>>>>>>>> H1 determines that its input halts on its input on the basis that H
>>>>>>>> determines that its input never halts.
>>>>>>>
>>>>>>> Yes H THINKS its input never halts, but since the input to H is the
>>>>>>> exact same input as to H1, the machine it represents is the same, so
>>>>>>> its
>>>>>>> behavior MUST be the same.
>>>>>>>
>>>>>>> Think about what you are trying to claim.
>>>>>>>
>>>>>>
>>>>>> I don't have to think about it. H1 does correctly decide that P
>>>>>> halts on
>>>>>> the basis that H correctly decides that its input never halts.
>>>>>
>>>>> No, you wouldn't think about it would you.
>>>>>>
>>>>>> H1 has identical machine code and inputs to H.
>>>>>> It is the execution order that makes the difference in the results.
>>>>>>
>>>>>> H1 can see all of the code that it simulates, H can see all of the
>>>>>> code
>>>>>> that its simulates, H1 cannot see any of the code that H simulates.
>>>>>
>>>>> Since H1 and H are copies of each other and H(P,P) and H1(P,P) give
>>>>> different answer, you have just proved that your H is NOT a
>>>>> computation,
>>>>
>>>> H(P,P) and H1(P,P) give a different answer because of their different
>>>> placement in the execution sequence.
>>>
>>> Thus, they aren't computations, as 'placement in the execution sequence'
>>> isn't one of their inputs, and thus not ALLOWED to change their answer.
>> H1(P,P) simulates P(P) as a slave process which executes H(P,P) as a
>> part of this same slave process. H(P,P) simulates P(P) as its own
>> slave process that H1 cannot see because each halt decider is a pure
>> function of its own inputs. Because H1 and H are at different machine
>> addresses they are not the same function executed with the same data.
>
> // Simplified Linz Ĥ (Linz:1990:319)
> // Strachey(1965) CPL translated to C
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
>   P((u32)P);
> }
>
> The H executed in main() on line 1 is the same function with the same
> inputs as the H that is called from P(P) of line 2 of main. These two
> instances have identical behavior.
>
> The simulated H called from the P simulated by the executed H on line 1
> of main() is the same function called with the same inputs as the
> executed H. In this case we have a brand new exception to the rule that
> the same function called with the same inputs must have identical behavior.
>
> When one of these function instances is directly executed and the other
> is simulated by a simulating halt decider their behavior need not be
> identical. The executed function can not be aborted and the simulated
> function can be aborted. This forms an exception to the rule that the
> same function called with the same input must have identical behavior.
>

On 27/08/2021 19:46, André G. Isaak wrote:
> When Le Verrier in the 19th century successfully predicted the
> existence and location of Neptune based on observed anomalies in the
> orbit of Uranus, do you think he used a computer? Do you think he
> simply left all the details of the math to the imagination and just
> made a lucky guess?

Most* people in the UK think he found a copy of the earlier
similarly successful prediction of Adams. Non-UK readers had better
add a mental ":-)" to the previous sentence.

____
* For some [small] value of "most".

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Hause

André G. Isaak <agisaak@gm.invalid> writes:

> On 2021-08-27 11:48, olcott wrote:

>> Math is merely computer science with the details of the underlying
>> algorithm left to the imagination rather than explicitly specified.
>
> This is probably the most singularly absurd statement you've ever
> written. And you've written some incredibly absurd things.

Yes, it's a high bar indeed.

....
> Second, the foundations of almost all major branches of mathematics
> were established long before computer science even existed as a
> discipline. And people successfully performed enormously complex
> computations without computers and certainly without anything 'left to
> the imagination'.

Euclid's algorithm comes to mind.

--
Ben.

On 27/08/2021 18:12, André G. Isaak wrote:
> A machine description doesn't even remotely resemble "source code".

I think people make too much of what a machine description is.
There is no interesting reason why a "machine description" should not
be "source code". Eg, C code can be thought of as the description of
an abstract machine, which can either be transformed by a compiler
into machine [or assembler] code to be run by a real computer [which
is then, for all practical purposes, a UTM running TMs described by
machine code for that computer], or be run by either a C interpreter
or a load-and-go C compiler [when the interpreter/compiler is for
all practical purposes a UTM for TMs described via C]. It is not
[IMO] necessary for a TM to be described exactly by states and
transitions, merely for it to consist of a FSM with an unbounded
tape. Similarly, a microcodable computer is effectively a UTM
for running computers [programs] described by the microcode.

There are many roads leading to Rome.

Whether such changes in ones PoV are helpful is perhaps
another matter. When Turing was describing his abstraction, the
idea of a UTM must have seemed like magic*; today. we're so used
to compilers, interpreters, microcode, and multi-layered versions
of these that they don't strike us in that way. The main modern
use of "traditional" TMs is to build very simple abstractions
that nevertheless do [or simulate!] complicated things. I think
the big surprise to students is that almost everything that a
practical computer can do can be thrown away, without losing the
[potential] universality -- at the expense, of course, of speed.
But there is no reason why TMs need to be "inefficient", in terms
of the number of cycles needed to execute "programs"; a real
computer is simply a FSM, and thus becomes a TM if it has memory
that can, if necessary [usually it won't be], be augmented, eg
by adding new discs or USB sticks or similar.

[PO:]
>> It is not totally impossible to adapt the concept of a TM to write
>> 32-bit integers instead of bits.
> Since TMs don't write bits, the above is unclear. If you mean we
> could define a TM which uses an alphabet consisting of 4,294,967,296
> symbols, then sure, we could, though I'm not sure why you would want
> to.

If you are using a real computer as a TM [or even a UTM], it
makes sense for the "tape" to be divided into 8/16/32/64 bit chunks
for efficiency. You wouldn't, of course, want to write out the full
list of states and transitions for such a FSM; rather, you would
refer to a manual for how the hardware works.

FTAOD, I'm not supporting PO [except in trivial ways] in
this. I just think people are barking up the wrong tree by going
on about the [manifest] fact that he doesn't understand [U]TMs,
about whether something is a "computation", and so on. Indeed,
IMO there is no point barking up PO's trees at all; we have all
seen every argument countless times, and PO is not going to admit
that he has wasted the last couple of decades. Let him get on
with writing his "paper". He thinks it would be revolutionary
and publishable; "we" [FSVO] think it wouldn't. There's only
one way to find out for sure. He can then carry on his debate
with the editor and referees.

____
* Comparable with the more recent "magic" of the discovery of
a universal NP-complete problem?

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Hause

On 8/28/2021 2:42 PM, Andy Walker wrote:
> On 27/08/2021 18:12, André G. Isaak wrote:
>> A machine description doesn't even remotely resemble "source code".
>
>     I think people make too much of what a machine description is.
> There is no interesting reason why a "machine description" should not
> be "source code".  Eg, C code can be thought of as the description of
> an abstract machine, which can either be transformed by a compiler
> into machine [or assembler] code to be run by a real computer [which
> is then, for all practical purposes, a UTM running TMs described by
> machine code for that computer], or be run by either a C interpreter
> or a load-and-go C compiler [when the interpreter/compiler is for
> all practical purposes a UTM for TMs described via C].  It is not
> [IMO] necessary for a TM to be described exactly by states and
> transitions, merely for it to consist of a FSM with an unbounded
> tape.  Similarly, a microcodable computer is effectively a UTM
> for running computers [programs] described by the microcode.
>
>     There are many roads leading to Rome.
>
>     Whether such changes in ones PoV are helpful is perhaps
> another matter.  When Turing was describing his abstraction, the
> idea of a UTM must have seemed like magic*;  today. we're so used
> to compilers, interpreters, microcode, and multi-layered versions
> of these that they don't strike us in that way.  The main modern
> use of "traditional" TMs is to build very simple abstractions
> that nevertheless do [or simulate!] complicated things.  I think
> the big surprise to students is that almost everything that a
> practical computer can do can be thrown away, without losing the
> [potential] universality -- at the expense, of course, of speed.
> But there is no reason why TMs need to be "inefficient", in terms
> of the number of cycles needed to execute "programs";  a real
> computer is simply a FSM, and thus becomes a TM if it has memory
> that can, if necessary [usually it won't be], be augmented, eg
> by adding new discs or USB sticks or similar.
>
> [PO:]
>>> It is not totally impossible to adapt the concept of a TM to write
>>> 32-bit integers instead of bits.
>> Since TMs don't write bits, the above is unclear. If you mean we
>> could define a TM which uses an alphabet consisting of 4,294,967,296
>> symbols, then sure, we could, though I'm not sure why you would want
>> to.
>
>     If you are using a real computer as a TM [or even a UTM], it
> makes sense for the "tape" to be divided into 8/16/32/64 bit chunks
> for efficiency.  You wouldn't, of course, want to write out the full
> list of states and transitions for such a FSM;  rather, you would
> refer to a manual for how the hardware works.
>
>     FTAOD, I'm not supporting PO [except in trivial ways] in
> this.  I just think people are barking up the wrong tree by going
> on about the [manifest] fact that he doesn't understand [U]TMs,
> about whether something is a "computation", and so on.  Indeed,
> IMO there is no point barking up PO's trees at all;  we have all
> seen every argument countless times, and PO is not going to admit
> that he has wasted the last couple of decades.  Let him get on
> with writing his "paper".  He thinks it would be revolutionary
> and publishable;  "we" [FSVO] think it wouldn't.  There's only
> one way to find out for sure.  He can then carry on his debate
> with the editor and referees.
>
> ____
>   * Comparable with the more recent "magic" of the discovery of
>     a universal NP-complete problem?
>

The bottom line is that none of the "mistakes" that anyone has pointed
out pertain to the essence of my proof. It is like they are saying that
my cure for cancer is no good at all because in describing how the cure
is implemented my punctuation use of commas was not precisely correct.

--
Copyright 2021 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> On 8/28/2021 7:15 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/27/2021 7:01 PM, Ben Bacarisse wrote:

>>>> At the time I was actually calling out hard errors of fact, not just
>>>> misleading abstractions. I was (dangerously) prepared to go along with
>>>> the abstract view, as I (and others) have done for some time, because,
>>>> whilst I agree it is potentially misleading, it's not actually wrong.
>>>> But PO did not think he was talking about abstractions at the time I
>>>> called him out on the mistake. He really did think that if you do the
>>>> "hat" construction on a TM that is little more that a UTM, then it --
>>>> the actual TM we'd call UTM^ -- has a cycle in its state graph allowing
>>>> it to go from what he calls qx (the UTM's q0) back (via other states of
>>>> course) to UTM^'s q0. And he thought that this loop is what wrote the
>>>> endless literal copies. He used Linz's notation for TM configurations
>>>> to show the strings right there on the tape next to each other, mid
>>>> computation, with q0 being entered again and again.
>>>
>>> It does have literal endless copies and no one besides you has claimed
>>> otherwise.
>>
>> (1) Of something, yes, but of what? Not of what you claimed.
>
> When the TM copies a string the UTM must perform the functional
> equivalent of copying a string. It could be as simple as a literal
> copy of a string (with the additional overhead of simulation). From
> the simulated TM's perspective it is a literal copy of a string.

You don't know what you wrote. That's because you used a precise
notation in a metaphorical way. When /you/ write symbols they mean
precisely what you want them to mean, not more and no less.

>> (2) Are you backing down from your claim about the loop in the state
>> transition graph?
>
> The loop in the state transition graph applies to the template as I
> explicitly showed in the execution trace:

"Applies to". You either believe there is one (as you once claimed) or
you don't.

> Ĵ copies its input ⟨Ĵ1⟩ to ⟨Ĵ2⟩ then simulates this input Ĵ1 with its input ⟨Ĵ2⟩
> which copies its input ⟨Ĵ2⟩ to ⟨Ĵ3⟩ then simulates this input Ĵ2 with its input ⟨Ĵ3⟩
> which copies its input ⟨Ĵ3⟩ to ⟨Ĵ4⟩ then simulates this input Ĵ3 with its input ⟨Ĵ4⟩ ...
>
> Ĵ copies Ĵ.qx simulates which essentially transitions to Ĵ1.q0.

Ah, there's the get-out clause: "essentially transitions to Ĵ1.q0". You
said that it did, not that it "essentially" did.

> This is not the conventional notion of a state transition within the
> same machine.

Indeed. It's the "I made a mistake but can't ever admit to it" notion
of a state transition.

> It is a more figurative use of the term so the gist of the behavior
> can be understood. I changed my paper so that it no longer refers to
> this cycle because the unconventional use of a term could be more
> difficult to understand.

Figurative language and poetic license. You are in the wrong game.

> H.q0 ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* H.qy
> H.q0 ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* H.qy

>> (3) You have it backwards. I only see posters agreeing with me on this
>> topic.
>
> They are careful to use double-talk that does not directly contradict
> what you said.

Such tricky double-talk as "No, he isn't wrong" in reply to your "Ben is
simply wrong". Don't apply this figurative interpretation to matters to
consent: no means no!

>>>> Even if he now tries to suggest that he was using the notation in some
>>>> sort of abstract way, the explicit cycle in the states gives a lie to
>>>> that. He thought it was actual, literal, symbol by symbol copying every
>>>> time, exactly as the extra states added by the hat construction do it.

--
Ben.

On 8/28/21 3:51 PM, olcott wrote:
> On 8/28/2021 2:42 PM, Andy Walker wrote:
>> On 27/08/2021 18:12, André G. Isaak wrote:
>>> A machine description doesn't even remotely resemble "source code".
>>
>>      I think people make too much of what a machine description is.
>> There is no interesting reason why a "machine description" should not
>> be "source code".  Eg, C code can be thought of as the description of
>> an abstract machine, which can either be transformed by a compiler
>> into machine [or assembler] code to be run by a real computer [which
>> is then, for all practical purposes, a UTM running TMs described by
>> machine code for that computer], or be run by either a C interpreter
>> or a load-and-go C compiler [when the interpreter/compiler is for
>> all practical purposes a UTM for TMs described via C].  It is not
>> [IMO] necessary for a TM to be described exactly by states and
>> transitions, merely for it to consist of a FSM with an unbounded
>> tape.  Similarly, a microcodable computer is effectively a UTM
>> for running computers [programs] described by the microcode.
>>
>>      There are many roads leading to Rome.
>>
>>      Whether such changes in ones PoV are helpful is perhaps
>> another matter.  When Turing was describing his abstraction, the
>> idea of a UTM must have seemed like magic*;  today. we're so used
>> to compilers, interpreters, microcode, and multi-layered versions
>> of these that they don't strike us in that way.  The main modern
>> use of "traditional" TMs is to build very simple abstractions
>> that nevertheless do [or simulate!] complicated things.  I think
>> the big surprise to students is that almost everything that a
>> practical computer can do can be thrown away, without losing the
>> [potential] universality -- at the expense, of course, of speed.
>> But there is no reason why TMs need to be "inefficient", in terms
>> of the number of cycles needed to execute "programs";  a real
>> computer is simply a FSM, and thus becomes a TM if it has memory
>> that can, if necessary [usually it won't be], be augmented, eg
>> by adding new discs or USB sticks or similar.
>>
>> [PO:]
>>>> It is not totally impossible to adapt the concept of a TM to write
>>>> 32-bit integers instead of bits.
>>> Since TMs don't write bits, the above is unclear. If you mean we
>>> could define a TM which uses an alphabet consisting of 4,294,967,296
>>> symbols, then sure, we could, though I'm not sure why you would want
>>> to.
>>
>>      If you are using a real computer as a TM [or even a UTM], it
>> makes sense for the "tape" to be divided into 8/16/32/64 bit chunks
>> for efficiency.  You wouldn't, of course, want to write out the full
>> list of states and transitions for such a FSM;  rather, you would
>> refer to a manual for how the hardware works.
>>
>>      FTAOD, I'm not supporting PO [except in trivial ways] in
>> this.  I just think people are barking up the wrong tree by going
>> on about the [manifest] fact that he doesn't understand [U]TMs,
>> about whether something is a "computation", and so on.  Indeed,
>> IMO there is no point barking up PO's trees at all;  we have all
>> seen every argument countless times, and PO is not going to admit
>> that he has wasted the last couple of decades.  Let him get on
>> with writing his "paper".  He thinks it would be revolutionary
>> and publishable;  "we" [FSVO] think it wouldn't.  There's only
>> one way to find out for sure.  He can then carry on his debate
>> with the editor and referees.
>>
>> ____
>>    * Comparable with the more recent "magic" of the discovery of
>>      a universal NP-complete problem?
>>
>
> The bottom line is that none of the "mistakes" that anyone has pointed
> out pertain to the essence of my proof. It is like they are saying that
> my cure for cancer is no good at all because in describing how the cure
> is implemented my punctuation use of commas was not precisely correct.
>

No, you CLAIM to have a cure for cancer, but you have yet to show that
any of your patients have survived or had cancer.

A 'Halt Decider' is a well defined type of machine with detailed
input/output specfications.

The Halting State of a Machine is well defined also.

All you claims show a machine that says its input represents a
non-halting machine when that machine when run does halt.

Thus you machine is shown to be wrong.

On 8/28/2021 2:02 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/28/2021 7:15 AM, Ben Bacarisse wrote:

<SNIP>
> You don't know what you wrote. That's because you used a precise
> notation in a metaphorical way. When /you/ write symbols they mean
> precisely what you want them to mean, not more and no less.

That was precisely Humpty Dumpty's comment about words usage. So PO has
now achieved the status of a Lewis Carroll character in Wonderland. Sure
sounds appropriate to me; PO in Wonderland featured as the Mad Hatter!
--
Jeff Barnett

On 8/28/2021 3:02 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/28/2021 7:15 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/27/2021 7:01 PM, Ben Bacarisse wrote:
>
>>>>> At the time I was actually calling out hard errors of fact, not just
>>>>> misleading abstractions. I was (dangerously) prepared to go along with
>>>>> the abstract view, as I (and others) have done for some time, because,
>>>>> whilst I agree it is potentially misleading, it's not actually wrong.
>>>>> But PO did not think he was talking about abstractions at the time I
>>>>> called him out on the mistake. He really did think that if you do the
>>>>> "hat" construction on a TM that is little more that a UTM, then it --
>>>>> the actual TM we'd call UTM^ -- has a cycle in its state graph allowing
>>>>> it to go from what he calls qx (the UTM's q0) back (via other states of
>>>>> course) to UTM^'s q0. And he thought that this loop is what wrote the
>>>>> endless literal copies. He used Linz's notation for TM configurations
>>>>> to show the strings right there on the tape next to each other, mid
>>>>> computation, with q0 being entered again and again.
>>>>
>>>> It does have literal endless copies and no one besides you has claimed
>>>> otherwise.
>>>
>>> (1) Of something, yes, but of what? Not of what you claimed.
>>
>> When the TM copies a string the UTM must perform the functional
>> equivalent of copying a string. It could be as simple as a literal
>> copy of a string (with the additional overhead of simulation). From
>> the simulated TM's perspective it is a literal copy of a string.
>
> You don't know what you wrote. That's because you used a precise
> notation in a metaphorical way. When /you/ write symbols they mean
> precisely what you want them to mean, not more and no less.
>

When the TM literally copies a string a UTM simulating the TM
description of this TM must implement the functional equivalent of
copying the string. It might even do this by performing the exact same
process as the TM.

>>> (2) Are you backing down from your claim about the loop in the state
>>> transition graph?
>>
>> The loop in the state transition graph applies to the template as I
>> explicitly showed in the execution trace:
>
> "Applies to". You either believe there is one (as you once claimed) or
> you don't.
>
>> Ĵ copies its input ⟨Ĵ1⟩ to ⟨Ĵ2⟩ then simulates this input Ĵ1 with its input ⟨Ĵ2⟩
>> which copies its input ⟨Ĵ2⟩ to ⟨Ĵ3⟩ then simulates this input Ĵ2 with its input ⟨Ĵ3⟩
>> which copies its input ⟨Ĵ3⟩ to ⟨Ĵ4⟩ then simulates this input Ĵ3 with its input ⟨Ĵ4⟩ ...
>>
>> Ĵ copies Ĵ.qx simulates which essentially transitions to Ĵ1.q0.
>
> Ah, there's the get-out clause: "essentially transitions to Ĵ1.q0". You
> said that it did, not that it "essentially" did.
>
>> This is not the conventional notion of a state transition within the
>> same machine.
>
> Indeed. It's the "I made a mistake but can't ever admit to it" notion
> of a state transition.
>

In this case I was speaking a little metaphorically because the term
state transition has a very precise meaning and this precise meaning was
not satisfied. My intentional was to convey the gist of what was happening.

>> It is a more figurative use of the term so the gist of the behavior
>> can be understood. I changed my paper so that it no longer refers to
>> this cycle because the unconventional use of a term could be more
>> difficult to understand.
>
> Figurative language and poetic license. You are in the wrong game.
>
>> H.q0 ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* H.qy
>> H.q0 ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* H.qy
>
>>> (3) You have it backwards. I only see posters agreeing with me on this
>>> topic.
>>
>> They are careful to use double-talk that does not directly contradict
>> what you said.
>
> Such tricky double-talk as "No, he isn't wrong" in reply to your "Ben is
> simply wrong". Don't apply this figurative interpretation to matters to
> consent: no means no!
>

When they try and show how he isn't wrong then switch to double-talk.
What the Hell did you mean that the string is not literally copied?

The string exists in one place and the elements of the string are copied
to some other place. This means that the string was <literally> copied.

>>>>> Even if he now tries to suggest that he was using the notation in some
>>>>> sort of abstract way, the explicit cycle in the states gives a lie to
>>>>> that. He thought it was actual, literal, symbol by symbol copying every
>>>>> time, exactly as the extra states added by the hat construction do it.
>

--
Copyright 2021 Pete Olcott

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

On 8/28/21 6:48 PM, olcott wrote:
> On 8/28/2021 3:02 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/28/2021 7:15 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/27/2021 7:01 PM, Ben Bacarisse wrote:
>>
>>>>>> At the time I was actually calling out hard errors of fact, not just
>>>>>> misleading abstractions.  I was (dangerously) prepared to go along
>>>>>> with
>>>>>> the abstract view, as I (and others) have done for some time,
>>>>>> because,
>>>>>> whilst I agree it is potentially misleading, it's not actually wrong.
>>>>>> But PO did not think he was talking about abstractions at the time I
>>>>>> called him out on the mistake.  He really did think that if you do
>>>>>> the
>>>>>> "hat" construction on a TM that is little more that a UTM, then it --
>>>>>> the actual TM we'd call UTM^ -- has a cycle in its state graph
>>>>>> allowing
>>>>>> it to go from what he calls qx (the UTM's q0) back (via other
>>>>>> states of
>>>>>> course) to UTM^'s q0.  And he thought that this loop is what wrote
>>>>>> the
>>>>>> endless literal copies.  He used Linz's notation for TM
>>>>>> configurations
>>>>>> to show the strings right there on the tape next to each other, mid
>>>>>> computation, with q0 being entered again and again.
>>>>>
>>>>> It does have literal endless copies and no one besides you has claimed
>>>>> otherwise.
>>>>
>>>> (1) Of something, yes, but of what?  Not of what you claimed.
>>>
>>> When the TM copies a string the UTM must perform the functional
>>> equivalent of copying a string. It could be as simple as a literal
>>> copy of a string (with the additional overhead of simulation). From
>>> the simulated TM's perspective it is a literal copy of a string.
>>
>> You don't know what you wrote.  That's because you used a precise
>> notation in a metaphorical way.  When /you/ write symbols they mean
>> precisely what you want them to mean, not more and no less.
>>
>
> When the TM literally copies a string a UTM simulating the TM
> description of this TM must implement the functional equivalent of
> copying the string. It might even do this by performing the exact same
> process as the TM.

Yes, the UTM needs to create the copy in the VIRTUAL tape of the
simulated Turing Machine. Except for VERY special conditions, the actual
tape of the UTM is likely encoded differently.

>
>>>> (2) Are you backing down from your claim about the loop in the state
>>>>       transition graph?
>>>
>>> The loop in the state transition graph applies to the template as I
>>> explicitly showed in the execution trace:
>>
>> "Applies to".  You either believe there is one (as you once claimed) or
>> you don't.
>>
>>> Ĵ copies its input ⟨Ĵ1⟩ to ⟨Ĵ2⟩ then simulates this input Ĵ1 with its
>>> input ⟨Ĵ2⟩
>>> which copies its input ⟨Ĵ2⟩ to ⟨Ĵ3⟩ then simulates this input Ĵ2 with
>>> its input ⟨Ĵ3⟩
>>> which copies its input ⟨Ĵ3⟩ to ⟨Ĵ4⟩ then simulates this input Ĵ3 with
>>> its input ⟨Ĵ4⟩ ...
>>>
>>> Ĵ copies Ĵ.qx simulates which essentially transitions to Ĵ1.q0.
>>
>> Ah, there's the get-out clause: "essentially transitions to Ĵ1.q0".  You
>> said that it did, not that it "essentially" did.
>>
>>> This is not the conventional notion of a state transition within the
>>> same machine.
>>
>> Indeed.  It's the "I made a mistake but can't ever admit to it" notion
>> of a state transition.
>>
>
> In this case I was speaking a little metaphorically because the term
> state transition has a very precise meaning and this precise meaning was
> not satisfied. My intentional was to convey the gist of what was happening.
>
>>> It is a more figurative use of the term so the gist of the behavior
>>> can be understood. I changed my paper so that it no longer refers to
>>> this cycle because the unconventional use of a term could be more
>>> difficult to understand.
>>
>> Figurative language and poetic license.  You are in the wrong game.
>>
>>> H.q0 ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* H.qy
>>> H.q0 ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* H.qy
>>
>>>> (3) You have it backwards.  I only see posters agreeing with me on this
>>>>       topic.
>>>
>>> They are careful to use double-talk that does not directly contradict
>>> what you said.
>>
>> Such tricky double-talk as "No, he isn't wrong" in reply to your "Ben is
>> simply wrong".  Don't apply this figurative interpretation to matters to
>> consent: no means no!
>>
>
> When they try and show how he isn't wrong then switch to double-talk.
> What the Hell did you mean that the string is not literally copied?
>
> The string exists in one place and the elements of the string are copied
> to some other place. This means that the string was <literally> copied.
>
>>>>>> Even if he now tries to suggest that he was using the notation in
>>>>>> some
>>>>>> sort of abstract way, the explicit cycle in the states gives a lie to
>>>>>> that.  He thought it was actual, literal, symbol by symbol copying
>>>>>> every
>>>>>> time, exactly as the extra states added by the hat construction do
>>>>>> it.
>>
>
>

On 2021-08-28 16:48, olcott wrote:

> When they try and show how he isn't wrong then switch to double-talk.
> What the Hell did you mean that the string is not literally copied?
>
> The string exists in one place and the elements of the string are copied
> to some other place. This means that the string was <literally> copied.

You might want to learn what the word 'literal' means.

André

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

On 8/28/2021 7:45 PM, André G. Isaak wrote:
> On 2021-08-28 16:48, olcott wrote:
>
>> When they try and show how he isn't wrong then switch to double-talk.
>> What the Hell did you mean that the string is not literally copied?
>>
>> The string exists in one place and the elements of the string are
>> copied to some other place. This means that the string was <literally>
>> copied.
>
> You might want to learn what the word 'literal' means.
>
> André
>
>

A literal string copy is not using the computer science meaning,
https://en.wikipedia.org/wiki/Literal_(computer_programming)

thus we are left with things that are not figure-of-speech:

literal adjective
in accordance with, involving, or being the primary or strict meaning of
the word or words; not figurative or metaphorical:

https://www.dictionary.com/browse/literal

The string exists in one place and the elements of the string are copied
to some other place. This means that the string was <literally> copied.

--
Copyright 2021 Pete Olcott

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

On Saturday, 28 August 2021 at 23:36:58 UTC+1, Jeff Barnett wrote:
> On 8/28/2021 2:02 PM, Ben Bacarisse wrote:
> > olcott <No...@NoWhere.com> writes:
> >
> >> On 8/28/2021 7:15 AM, Ben Bacarisse wrote:
> <SNIP>
> > You don't know what you wrote. That's because you used a precise
> > notation in a metaphorical way. When /you/ write symbols they mean
> > precisely what you want them to mean, not more and no less.
> That was precisely Humpty Dumpty's comment about words usage. So PO has
> now achieved the status of a Lewis Carroll character in Wonderland. Sure
> sounds appropriate to me; PO in Wonderland featured as the Mad Hatter!
>
Of course Lewis Carroll was a mathematician. And Alice in Wonderland wraps
philosophical ideas in burlesque.

On 8/29/2021 3:19 AM, Malcolm McLean wrote:
> On Saturday, 28 August 2021 at 23:36:58 UTC+1, Jeff Barnett wrote:
>> On 8/28/2021 2:02 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 8/28/2021 7:15 AM, Ben Bacarisse wrote:
>> <SNIP>
>>> You don't know what you wrote. That's because you used a precise
>>> notation in a metaphorical way. When /you/ write symbols they mean
>>> precisely what you want them to mean, not more and no less.
>> That was precisely Humpty Dumpty's comment about words usage. So PO has
>> now achieved the status of a Lewis Carroll character in Wonderland. Sure
>> sounds appropriate to me; PO in Wonderland featured as the Mad Hatter!
>>
> Of course Lewis Carroll was a mathematician. And Alice in Wonderland wraps
> philosophical ideas in burlesque.

And delightfully too! I don't get the same smile from PO; too pathetic.
--
Jeff Barnett

On 8/29/2021 11:58 AM, Jeff Barnett wrote:
> On 8/29/2021 3:19 AM, Malcolm McLean wrote:
>> On Saturday, 28 August 2021 at 23:36:58 UTC+1, Jeff Barnett wrote:
>>> On 8/28/2021 2:02 PM, Ben Bacarisse wrote:
>>>> olcott <No...@NoWhere.com> writes:
>>>>
>>>>> On 8/28/2021 7:15 AM, Ben Bacarisse wrote:
>>> <SNIP>
>>>> You don't know what you wrote. That's because you used a precise
>>>> notation in a metaphorical way. When /you/ write symbols they mean
>>>> precisely what you want them to mean, not more and no less.
>>> That was precisely Humpty Dumpty's comment about words usage. So PO has
>>> now achieved the status of a Lewis Carroll character in Wonderland. Sure
>>> sounds appropriate to me; PO in Wonderland featured as the Mad Hatter!
>>>
>> Of course Lewis Carroll was a mathematician. And Alice in Wonderland
>> wraps
>> philosophical ideas in burlesque.
>
> And delightfully too! I don't get the same smile from PO; too pathetic.

The reason that you only have denigration rather than any technically
accurate rebuttal is that a technically accurate rebuttal is beyond your
technical competence.

That you baselessly denigrate things beyond your technical competence is
quite foolish and flatly dishonest.

--
Copyright 2021 Pete Olcott

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

On 8/29/21 1:03 PM, olcott wrote:
> On 8/29/2021 11:58 AM, Jeff Barnett wrote:
>> On 8/29/2021 3:19 AM, Malcolm McLean wrote:
>>> On Saturday, 28 August 2021 at 23:36:58 UTC+1, Jeff Barnett wrote:
>>>> On 8/28/2021 2:02 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 8/28/2021 7:15 AM, Ben Bacarisse wrote:
>>>> <SNIP>
>>>>> You don't know what you wrote. That's because you used a precise
>>>>> notation in a metaphorical way. When /you/ write symbols they mean
>>>>> precisely what you want them to mean, not more and no less.
>>>> That was precisely Humpty Dumpty's comment about words usage. So PO has
>>>> now achieved the status of a Lewis Carroll character in Wonderland.
>>>> Sure
>>>> sounds appropriate to me; PO in Wonderland featured as the Mad Hatter!
>>>>
>>> Of course Lewis Carroll was a mathematician. And Alice in Wonderland
>>> wraps
>>> philosophical ideas in burlesque.
>>
>> And delightfully too! I don't get the same smile from PO; too pathetic.
>
> The reason that you only have denigration rather than any technically
> accurate rebuttal is that a technically accurate rebuttal is beyond your
> technical competence.
>
> That you baselessly denigrate things beyond your technical competence is
> quite foolish and flatly dishonest.
>

Technically Accurate Rebuttals seem to be outside your understanding,
because you have rewritten the dictionary, so nothing means the same thing.

This basically means actual communication is impossible as you don't
speak the same language, namely Logic and Mathematics.

On 8/29/2021 11:03 AM, olcott wrote:
> On 8/29/2021 11:58 AM, Jeff Barnett wrote:
>> On 8/29/2021 3:19 AM, Malcolm McLean wrote:
>>> On Saturday, 28 August 2021 at 23:36:58 UTC+1, Jeff Barnett wrote:
>>>> On 8/28/2021 2:02 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 8/28/2021 7:15 AM, Ben Bacarisse wrote:
>>>> <SNIP>
>>>>> You don't know what you wrote. That's because you used a precise
>>>>> notation in a metaphorical way. When /you/ write symbols they mean
>>>>> precisely what you want them to mean, not more and no less.
>>>> That was precisely Humpty Dumpty's comment about words usage. So PO has
>>>> now achieved the status of a Lewis Carroll character in Wonderland.
>>>> Sure
>>>> sounds appropriate to me; PO in Wonderland featured as the Mad Hatter!
>>>>
>>> Of course Lewis Carroll was a mathematician. And Alice in Wonderland
>>> wraps
>>> philosophical ideas in burlesque.
>>
>> And delightfully too! I don't get the same smile from PO; too pathetic.
>
> The reason that you only have denigration rather than any technically
> accurate rebuttal is that a technically accurate rebuttal is beyond your
> technical competence.
>
> That you baselessly denigrate things beyond your technical competence is
> quite foolish and flatly dishonest.

What's dishonest????? Have you looked in a mirror? How does your visage
differ from that of the Mad Hatter? The Mad Hatter is a parody as you
are. Humpty Dumpty (Ben in this case) is the voice of logic and the core
of linguistics. Compare -- PO : Nonsense :: BB : Rationality. As for me,
I'm just a commentator on the Tea Party.

I really think you should read Alice in Wonderland and Through the
Looking Glass. They are difficult but not so difficult as Linz. Since
there is a lot of logic wrapped in humor, it will mostly sail right over
your head. There are two ways to get through it: 1) buy a copy of The
Annotated Alice and pay attention to the footnotes or 2) ask questions
here and we will all try to help you and correct your misunderstandings.
Option 2 is less expensive but you would need to humble yourself just a
little bit.

There is a third option: 3) find a smart kid in your neighborhood and
trade some candy for explanations of the hard parts. The advantages here
are that you can save face and have some relief from the total isolation
and friendless existence that has plagued you for years. Yes! I think
option 3 is just right for you. Don't screw it up; just remember you are
in this relationship since the kid is smarter and knows more than you
do. And if the candy is good, nobody else will ever know.
--
Jeff Barnett