On 11/11/21 9:29 PM, olcott wrote:
> On 11/11/2021 8:25 PM, Richard Damon wrote:
>> On 11/11/21 9:03 PM, olcott wrote:
>>> On 11/11/2021 7:54 PM, Richard Damon wrote:
>>>> On 11/11/21 7:50 PM, olcott wrote:
>>>>> On 11/11/2021 6:20 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 11/11/21 7:02 PM, olcott wrote:
>>>>>>
>>>>>>> I say that P never reaches 1a72.
>>>>>>> You say that it does.
>>>>>>> I prove that it doesn't
>>>>>>> You say that my proof doesn't matter
>>>>>>>
>>>>>>> That behavior matches the pattern of a liar.
>>>>>>>
>>>>>>
>>>>>> Ok, so your claim now is that that Direct Execution of P(P) never
>>>>>> reaches 1A72?
>>>>>>
>>>>>
>>>>> If under every circumstance P never reaches 1a72 then P never halts.
>>>>>
>>>>
>>>> Then why did you say prebviously that P(P) does halt?
>>>>
>>>
>>> If in the computation H(P,P) P never reaches 1a72 for every H that
>>> can possibly exist and in the computation P reaches 1a72 then these
>>> two computations must be entirely different from each other and able
>>> to have inconsistent behavior relative to each other without
>>> contradiction.
>>
>>
>> The DEFINITION of the problem that H is set to solve is to predict the
>> behavior of the machine that its input is a representation of [Which
>> will be the actual computatipn P(P)] which would be the equvalent of
>> giving the same input as given to H to a real pure simulator like a
>> UTM which simulates until the computation reaches its end (or
>> simulates forever if it never will).
>>
>
> The computation of H(P,P) is entirely contained within the computation
> of P(P) as a part of this larger computation. This by itself
> conclusively proves that they are not the same.
>

No one said that H(P,P) and P(P) were the same computation, and they
can't be.

The requirement is that, to be correct, the answer that H(<P>,I) needs
to correspond to the behavior of the comptation P(I), giving a 'Halting'
answer (Halt at qy) if the computation P(I) will finish in finite time
and a 'Non-Halting' (Halt at qn) if the computaton P(I) will NEVER reach
a halting state in any bounded number of steps.

H(P,P) can be computed as an independent computation, since we STARTED
with a Turing Machine H that claims to be a proper Halt Decider. Given
that Turing Machine, we can create the Turing Machine H^, and from that
create its representation <H^> and apply that twice to the machine H.
(You for some reason want to call the Turing Machine H^ as P).

Thus we have two distinct computations whose results can be compared to
see if H did its job correctly.

Since H is a Computation, we do have the option of just running P(P) and
examining the operation of the sub-machine within to see what H(P,P)
would have done if run by itself, but strictly speaking, the defintion
requires running the two machines to compare the results.

Maybe you don't understand that by the basic properties of how Turing
Machines work, that the copy of H embedded inside P will by necessity
behave exactly like the copy of H that is run on its own.

Thus if the direct asking of H(P,P) it goes to qn in some specific
number N steps, then we know that when we are running the compuation P,
when it gets to that sub-machine, that it too will go to its equivalent
state H^.qn in exactly that same N steps. If H doesn't predict that same
behavior, it is wrong.

Now, it can be shown that it is impossible for this H to actually
perform the simulation to the point that it sees this return, as if we
define x to be the number of steps that P does before getting to H^.qx
(and x > 0) then we know that since the outer H only simulated N steps,
that it will have only simulated this simulated version of H for N-x
steps, and N-x < N since x>0, thus it will be impossible to design an H
that can simulate long enough for it to see the answer that its copy
will give (that would be finding a N such that N > N+x for x>0)

This doesn't mean the the machine given for the input is non-halting, as
we know it will halt in N+x steps, just that H can never PROVE that it
halts.

On 11/11/2021 8:54 PM, Richard Damon wrote:
> On 11/11/21 9:29 PM, olcott wrote:
>> On 11/11/2021 8:25 PM, Richard Damon wrote:
>>> On 11/11/21 9:03 PM, olcott wrote:
>>>> On 11/11/2021 7:54 PM, Richard Damon wrote:
>>>>> On 11/11/21 7:50 PM, olcott wrote:
>>>>>> On 11/11/2021 6:20 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 11/11/21 7:02 PM, olcott wrote:
>>>>>>>
>>>>>>>> I say that P never reaches 1a72.
>>>>>>>> You say that it does.
>>>>>>>> I prove that it doesn't
>>>>>>>> You say that my proof doesn't matter
>>>>>>>>
>>>>>>>> That behavior matches the pattern of a liar.
>>>>>>>>
>>>>>>>
>>>>>>> Ok, so your claim now is that that Direct Execution of P(P) never
>>>>>>> reaches 1A72?
>>>>>>>
>>>>>>
>>>>>> If under every circumstance P never reaches 1a72 then P never halts.
>>>>>>
>>>>>
>>>>> Then why did you say prebviously that P(P) does halt?
>>>>>
>>>>
>>>> If in the computation H(P,P) P never reaches 1a72 for every H that
>>>> can possibly exist and in the computation P reaches 1a72 then these
>>>> two computations must be entirely different from each other and able
>>>> to have inconsistent behavior relative to each other without
>>>> contradiction.
>>>
>>>
>>> The DEFINITION of the problem that H is set to solve is to predict
>>> the behavior of the machine that its input is a representation of
>>> [Which will be the actual computatipn P(P)] which would be the
>>> equvalent of giving the same input as given to H to a real pure
>>> simulator like a UTM which simulates until the computation reaches
>>> its end (or simulates forever if it never will).
>>>
>>
>> The computation of H(P,P) is entirely contained within the computation
>> of P(P) as a part of this larger computation. This by itself
>> conclusively proves that they are not the same.
>>
>
> No one said that H(P,P) and P(P) were the same computation, and they
> can't be.
>
At the TM level the halt decider must report the actual behavior of the
simulation of the TM descrition on its tape.

--
Copyright 2021 Pete Olcott

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

On 11/11/21 10:12 PM, olcott wrote:
> On 11/11/2021 8:54 PM, Richard Damon wrote:
>> On 11/11/21 9:29 PM, olcott wrote:
>>> On 11/11/2021 8:25 PM, Richard Damon wrote:
>>>> On 11/11/21 9:03 PM, olcott wrote:
>>>>> On 11/11/2021 7:54 PM, Richard Damon wrote:
>>>>>> On 11/11/21 7:50 PM, olcott wrote:
>>>>>>> On 11/11/2021 6:20 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 11/11/21 7:02 PM, olcott wrote:
>>>>>>>>
>>>>>>>>> I say that P never reaches 1a72.
>>>>>>>>> You say that it does.
>>>>>>>>> I prove that it doesn't
>>>>>>>>> You say that my proof doesn't matter
>>>>>>>>>
>>>>>>>>> That behavior matches the pattern of a liar.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Ok, so your claim now is that that Direct Execution of P(P)
>>>>>>>> never reaches 1A72?
>>>>>>>>
>>>>>>>
>>>>>>> If under every circumstance P never reaches 1a72 then P never halts.
>>>>>>>
>>>>>>
>>>>>> Then why did you say prebviously that P(P) does halt?
>>>>>>
>>>>>
>>>>> If in the computation H(P,P) P never reaches 1a72 for every H that
>>>>> can possibly exist and in the computation P reaches 1a72 then these
>>>>> two computations must be entirely different from each other and
>>>>> able to have inconsistent behavior relative to each other without
>>>>> contradiction.
>>>>
>>>>
>>>> The DEFINITION of the problem that H is set to solve is to predict
>>>> the behavior of the machine that its input is a representation of
>>>> [Which will be the actual computatipn P(P)] which would be the
>>>> equvalent of giving the same input as given to H to a real pure
>>>> simulator like a UTM which simulates until the computation reaches
>>>> its end (or simulates forever if it never will).
>>>>
>>>
>>> The computation of H(P,P) is entirely contained within the
>>> computation of P(P) as a part of this larger computation. This by
>>> itself conclusively proves that they are not the same.
>>>
>>
>> No one said that H(P,P) and P(P) were the same computation, and they
>> can't be.
>>
> At the TM level the halt decider must report the actual behavior of the
> simulation of the TM descrition on its tape.
>

No, it must report the actual behavior of the machine represented on the
Tape, or equivalently, what a UTM would do if given this exact same input.

Since H is NOT a UTM, its partial simulation doesn't matter.

Again, you don't understand the meaning of the words or the definition
of the problem you have decided to work on, and thus fail at getting to
the right answer for it.

On 11/11/2021 9:18 PM, Richard Damon wrote:
> On 11/11/21 10:12 PM, olcott wrote:
>> On 11/11/2021 8:54 PM, Richard Damon wrote:
>>> On 11/11/21 9:29 PM, olcott wrote:
>>>> On 11/11/2021 8:25 PM, Richard Damon wrote:
>>>>> On 11/11/21 9:03 PM, olcott wrote:
>>>>>> On 11/11/2021 7:54 PM, Richard Damon wrote:
>>>>>>> On 11/11/21 7:50 PM, olcott wrote:
>>>>>>>> On 11/11/2021 6:20 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 11/11/21 7:02 PM, olcott wrote:
>>>>>>>>>
>>>>>>>>>> I say that P never reaches 1a72.
>>>>>>>>>> You say that it does.
>>>>>>>>>> I prove that it doesn't
>>>>>>>>>> You say that my proof doesn't matter
>>>>>>>>>>
>>>>>>>>>> That behavior matches the pattern of a liar.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ok, so your claim now is that that Direct Execution of P(P)
>>>>>>>>> never reaches 1A72?
>>>>>>>>>
>>>>>>>>
>>>>>>>> If under every circumstance P never reaches 1a72 then P never
>>>>>>>> halts.
>>>>>>>>
>>>>>>>
>>>>>>> Then why did you say prebviously that P(P) does halt?
>>>>>>>
>>>>>>
>>>>>> If in the computation H(P,P) P never reaches 1a72 for every H that
>>>>>> can possibly exist and in the computation P reaches 1a72 then
>>>>>> these two computations must be entirely different from each other
>>>>>> and able to have inconsistent behavior relative to each other
>>>>>> without contradiction.
>>>>>
>>>>>
>>>>> The DEFINITION of the problem that H is set to solve is to predict
>>>>> the behavior of the machine that its input is a representation of
>>>>> [Which will be the actual computatipn P(P)] which would be the
>>>>> equvalent of giving the same input as given to H to a real pure
>>>>> simulator like a UTM which simulates until the computation reaches
>>>>> its end (or simulates forever if it never will).
>>>>>
>>>>
>>>> The computation of H(P,P) is entirely contained within the
>>>> computation of P(P) as a part of this larger computation. This by
>>>> itself conclusively proves that they are not the same.
>>>>
>>>
>>> No one said that H(P,P) and P(P) were the same computation, and they
>>> can't be.
>>>
>> At the TM level the halt decider must report the actual behavior of
>> the simulation of the TM descrition on its tape.
>>
>
> No, it must report the actual behavior of the machine represented on the
> Tape, or equivalently, what a UTM would do if given this exact same input.
>

All the "represented" means is that the halt decider is looking at the
source-code of the TM.

> Since H is NOT a UTM, its partial simulation doesn't matter.

Linz did not exclude UTM's, they merely never occurred to him.
Linz was also not concerned with attaining any deeper understanding of
the halting problem. He only wanted to very clearly state the
conventional wisdom.

>
> Again, you don't understand the meaning of the words or the definition
> of the problem you have decided to work on, and thus fail at getting to
> the right answer for it.

--
Copyright 2021 Pete Olcott

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

On 11/11/21 10:42 PM, olcott wrote:
> On 11/11/2021 9:18 PM, Richard Damon wrote:
>> On 11/11/21 10:12 PM, olcott wrote:
>>> On 11/11/2021 8:54 PM, Richard Damon wrote:
>>>> On 11/11/21 9:29 PM, olcott wrote:
>>>>> On 11/11/2021 8:25 PM, Richard Damon wrote:
>>>>>> On 11/11/21 9:03 PM, olcott wrote:
>>>>>>> On 11/11/2021 7:54 PM, Richard Damon wrote:
>>>>>>>> On 11/11/21 7:50 PM, olcott wrote:
>>>>>>>>> On 11/11/2021 6:20 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 11/11/21 7:02 PM, olcott wrote:
>>>>>>>>>>
>>>>>>>>>>> I say that P never reaches 1a72.
>>>>>>>>>>> You say that it does.
>>>>>>>>>>> I prove that it doesn't
>>>>>>>>>>> You say that my proof doesn't matter
>>>>>>>>>>>
>>>>>>>>>>> That behavior matches the pattern of a liar.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Ok, so your claim now is that that Direct Execution of P(P)
>>>>>>>>>> never reaches 1A72?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If under every circumstance P never reaches 1a72 then P never
>>>>>>>>> halts.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Then why did you say prebviously that P(P) does halt?
>>>>>>>>
>>>>>>>
>>>>>>> If in the computation H(P,P) P never reaches 1a72 for every H
>>>>>>> that can possibly exist and in the computation P reaches 1a72
>>>>>>> then these two computations must be entirely different from each
>>>>>>> other and able to have inconsistent behavior relative to each
>>>>>>> other without contradiction.
>>>>>>
>>>>>>
>>>>>> The DEFINITION of the problem that H is set to solve is to predict
>>>>>> the behavior of the machine that its input is a representation of
>>>>>> [Which will be the actual computatipn P(P)] which would be the
>>>>>> equvalent of giving the same input as given to H to a real pure
>>>>>> simulator like a UTM which simulates until the computation reaches
>>>>>> its end (or simulates forever if it never will).
>>>>>>
>>>>>
>>>>> The computation of H(P,P) is entirely contained within the
>>>>> computation of P(P) as a part of this larger computation. This by
>>>>> itself conclusively proves that they are not the same.
>>>>>
>>>>
>>>> No one said that H(P,P) and P(P) were the same computation, and they
>>>> can't be.
>>>>
>>> At the TM level the halt decider must report the actual behavior of
>>> the simulation of the TM descrition on its tape.
>>>
>>
>> No, it must report the actual behavior of the machine represented on
>> the Tape, or equivalently, what a UTM would do if given this exact
>> same input.
>>
>
> All the "represented" means is that the halt decider is looking at the
> source-code of the TM.

No, it doesn't. Perhaps 'Source Code' might be one way to represent the
Turing Machine, but it isn't a required way.

We need to give a representation because you can't give an actual Turing
Machine as an input, as it is the wrong sort of thing.

If you wanted your computer to figure out some performance data about
your car, you don't give your computer your car as 'Input' because that
doesn't make sense. Instead you 'convert' your car into a suitable
representation that has all the details about the car, and that
'representation' is given to the computer.

Turing Machines can ge defined by a set of Tupples, (Input state, Input
Symbol, Next State, Output Symbol, Tape motion) but this can't just be
put on the tape, as the 'alphabet' of the Tape likely can't directly
express this, so we need to 'represent' this definition in some way for
the decider.

>
>> Since H is NOT a UTM, its partial simulation doesn't matter.
>
> Linz did not exclude UTM's, they merely never occurred to him.
> Linz was also not concerned with attaining any deeper understanding of
> the halting problem. He only wanted to very clearly state the
> conventional wisdom.

No, you COULD make H a UTM, but if it is it is a very bad decider, since
we have shown that a UTM can never indicate that an input is
non-halting, as BY DEFINITION, a UTM will never abort a non-halting
computaiton.

Now, if you want to make H be a UTM, go ahead, in that case then YES,
the simulation that H does is an accurate equivalent of the machine
whose the input represents. Your only problem is that BY DEFINITION,
UTMs CAN'T abort a Non-Halting Computation given to them, and thus can't
ever give a correct Non-Halting Answer. (If they do abort the simulaton,
they are thus shown to not be a UTM)

The issue you keep on missing is that the answer that H is supposed to
give is based on the actual behavior of the machine that the input is a
representation of,

Running the Machine H with the input tape holding <P> I means we have
encoded in some way the definition of what the Turing Machine P is, and
put it on the tape. The Question we are asking is what would the actual
machine P do if given the input I.

Thus, running H with input <H^> <H^> means asking it what the actual
machine H^ would do if given the input <H^>

Since you have admited that this would be Halt, that is the answer we
are expecting out of H, that would be the CORRECT answer, and the
Non-Halting answer would be INCORRECT.

The comment about UTM is because we know, from the definition of what a
UTM is, that a complete equivalent test would be to take the input to H,
the <H^> <H^> and make that the input to a UTM.

>
>>
>> Again, you don't understand the meaning of the words or the definition
>> of the problem you have decided to work on, and thus fail at getting
>> to the right answer for it.
>
>

On 11/11/2021 10:08 PM, Richard Damon wrote:
> On 11/11/21 10:42 PM, olcott wrote:
>> On 11/11/2021 9:18 PM, Richard Damon wrote:
>>> On 11/11/21 10:12 PM, olcott wrote:
>>>> On 11/11/2021 8:54 PM, Richard Damon wrote:
>>>>> On 11/11/21 9:29 PM, olcott wrote:
>>>>>> On 11/11/2021 8:25 PM, Richard Damon wrote:
>>>>>>> On 11/11/21 9:03 PM, olcott wrote:
>>>>>>>> On 11/11/2021 7:54 PM, Richard Damon wrote:
>>>>>>>>> On 11/11/21 7:50 PM, olcott wrote:
>>>>>>>>>> On 11/11/2021 6:20 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 11/11/21 7:02 PM, olcott wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I say that P never reaches 1a72.
>>>>>>>>>>>> You say that it does.
>>>>>>>>>>>> I prove that it doesn't
>>>>>>>>>>>> You say that my proof doesn't matter
>>>>>>>>>>>>
>>>>>>>>>>>> That behavior matches the pattern of a liar.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Ok, so your claim now is that that Direct Execution of P(P)
>>>>>>>>>>> never reaches 1A72?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If under every circumstance P never reaches 1a72 then P never
>>>>>>>>>> halts.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Then why did you say prebviously that P(P) does halt?
>>>>>>>>>
>>>>>>>>
>>>>>>>> If in the computation H(P,P) P never reaches 1a72 for every H
>>>>>>>> that can possibly exist and in the computation P reaches 1a72
>>>>>>>> then these two computations must be entirely different from each
>>>>>>>> other and able to have inconsistent behavior relative to each
>>>>>>>> other without contradiction.
>>>>>>>
>>>>>>>
>>>>>>> The DEFINITION of the problem that H is set to solve is to
>>>>>>> predict the behavior of the machine that its input is a
>>>>>>> representation of [Which will be the actual computatipn P(P)]
>>>>>>> which would be the equvalent of giving the same input as given to
>>>>>>> H to a real pure simulator like a UTM which simulates until the
>>>>>>> computation reaches its end (or simulates forever if it never will).
>>>>>>>
>>>>>>
>>>>>> The computation of H(P,P) is entirely contained within the
>>>>>> computation of P(P) as a part of this larger computation. This by
>>>>>> itself conclusively proves that they are not the same.
>>>>>>
>>>>>
>>>>> No one said that H(P,P) and P(P) were the same computation, and
>>>>> they can't be.
>>>>>
>>>> At the TM level the halt decider must report the actual behavior of
>>>> the simulation of the TM descrition on its tape.
>>>>
>>>
>>> No, it must report the actual behavior of the machine represented on
>>> the Tape, or equivalently, what a UTM would do if given this exact
>>> same input.
>>>
>>
>> All the "represented" means is that the halt decider is looking at the
>> source-code of the TM.
>
> No, it doesn't. Perhaps 'Source Code' might be one way to represent the
> Turing Machine, but it isn't a required way.
>

All that "represented" means is that the halt decider bases its decision
on the TM description that is on the tape not the execution of the
actual TM. The TM description "represents" the TM to be analyzed meaning
that it is not the actual TM itself.

> We need to give a representation because you can't give an actual Turing
> Machine as an input, as it is the wrong sort of thing.
>

Yes.

> If you wanted your computer to figure out some performance data about
> your car, you don't give your computer your car as 'Input' because that
> doesn't make sense. Instead you 'convert' your car into a suitable
> representation that has all the details about the car, and that
> 'representation' is given to the computer.
>
> Turing Machines can ge defined by a set of Tupples, (Input state, Input
> Symbol, Next State, Output Symbol, Tape motion) but this can't just be
> put on the tape, as the 'alphabet' of the Tape likely can't directly
> express this, so we need to 'represent' this definition in some way for
> the decider.

A turing machine is a model of a computer. It has a finite number of
states, and it is capable of reading and modifying a tape. A turing
machine program consists of a list of 'quintuples', each one of which is
a five-symbol turing machine instruction.
http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt

If we don't assume some kind of nutty half-bit sized tape element it is
enormously easy to put a 'quintuple' on the tape.

>>
>>> Since H is NOT a UTM, its partial simulation doesn't matter.
>>
>> Linz did not exclude UTM's, they merely never occurred to him.
>> Linz was also not concerned with attaining any deeper understanding of
>> the halting problem. He only wanted to very clearly state the
>> conventional wisdom.
>
> No, you COULD make H a UTM, but if it is it is a very bad decider, since
> we have shown that a UTM can never indicate that an input is
> non-halting, as BY DEFINITION, a UTM will never abort a non-halting
> computaiton.
>
> Now, if you want to make H be a UTM, go ahead, in that case then YES,
> the simulation that H does is an accurate  equivalent of the machine
> whose the input represents. Your only problem is that BY DEFINITION,
> UTMs CAN'T abort a Non-Halting Computation given to them, and thus can't
> ever give a correct Non-Halting Answer. (If they do abort the simulaton,
> they are thus shown to not be a UTM)
>
> The issue you keep on missing is that the answer that H is supposed to
> give is based on the actual behavior of the machine that the input is a
> representation of,
>
> Running the Machine H with the input tape holding <P> I means we have
> encoded in some way the definition of what the Turing Machine P is, and
> put it on the tape. The Question we are asking is what would the actual
> machine P do if given the input I.
>
> Thus, running H with input <H^> <H^> means asking it what the actual
> machine H^ would do if given the input <H^>
>
> Since you have admited that this would be Halt, that is the answer we
> are expecting out of H, that would be the CORRECT answer, and the
> Non-Halting answer would be INCORRECT.
>
> The comment about UTM is because we know, from the definition of what a
> UTM is, that a complete equivalent test would be to take the input to H,
> the <H^> <H^> and make that the input to a UTM.
>
>
>>
>>>
>>> Again, you don't understand the meaning of the words or the
>>> definition of the problem you have decided to work on, and thus fail
>>> at getting to the right answer for it.
>>
>>
>

--
Copyright 2021 Pete Olcott

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

On 2021-11-11 21:08, Richard Damon wrote:

> If you wanted your computer to figure out some performance data about
> your car, you don't give your computer your car as 'Input' because that
> doesn't make sense. Instead you 'convert' your car into a suitable
> representation that has all the details about the car, and that
> 'representation' is given to the computer.

And, crucially in this example, you're presumably interested in the
performance of the *actual* car. If the simulation of the representation
passed as an input doesn't match the behaviour of the actual car no one
is going to accept the argument that the simulator is still correct
because it answers 'correctly' about 'its input'.

André

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

On 11/11/2021 11:24 PM, André G. Isaak wrote:
> On 2021-11-11 21:08, Richard Damon wrote:
>
>> If you wanted your computer to figure out some performance data about
>> your car, you don't give your computer your car as 'Input' because
>> that doesn't make sense. Instead you 'convert' your car into a
>> suitable representation that has all the details about the car, and
>> that 'representation' is given to the computer.
>
> And, crucially in this example, you're presumably interested in the
> performance of the *actual* car. If the simulation of the representation
> passed as an input doesn't match the behaviour of the actual car no one
> is going to accept the argument that the simulator is still correct
> because it answers 'correctly' about 'its input'.
>
> André
>

It is the behavior of the TM description that is on the tape that can be
most accurately demonstrated by simply simulating it. If the simulated
input never reaches its final state then this input never halts.

The equivalent for the C/x86 mode of computation is the parameters that
have been pushed on the stack.

Ben did a good job cleaning up the syntax of my code.

--
Copyright 2021 Pete Olcott

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

On 11/11/21 11:45 PM, olcott wrote:
> On 11/11/2021 10:08 PM, Richard Damon wrote:
>> On 11/11/21 10:42 PM, olcott wrote:
>>> On 11/11/2021 9:18 PM, Richard Damon wrote:
>>>> On 11/11/21 10:12 PM, olcott wrote:
>>>>> On 11/11/2021 8:54 PM, Richard Damon wrote:
>>>>>> On 11/11/21 9:29 PM, olcott wrote:
>>>>>>> On 11/11/2021 8:25 PM, Richard Damon wrote:
>>>>>>>> On 11/11/21 9:03 PM, olcott wrote:
>>>>>>>>> On 11/11/2021 7:54 PM, Richard Damon wrote:
>>>>>>>>>> On 11/11/21 7:50 PM, olcott wrote:
>>>>>>>>>>> On 11/11/2021 6:20 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 11/11/21 7:02 PM, olcott wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I say that P never reaches 1a72.
>>>>>>>>>>>>> You say that it does.
>>>>>>>>>>>>> I prove that it doesn't
>>>>>>>>>>>>> You say that my proof doesn't matter
>>>>>>>>>>>>>
>>>>>>>>>>>>> That behavior matches the pattern of a liar.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Ok, so your claim now is that that Direct Execution of P(P)
>>>>>>>>>>>> never reaches 1A72?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> If under every circumstance P never reaches 1a72 then P never
>>>>>>>>>>> halts.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Then why did you say prebviously that P(P) does halt?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If in the computation H(P,P) P never reaches 1a72 for every H
>>>>>>>>> that can possibly exist and in the computation P reaches 1a72
>>>>>>>>> then these two computations must be entirely different from
>>>>>>>>> each other and able to have inconsistent behavior relative to
>>>>>>>>> each other without contradiction.
>>>>>>>>
>>>>>>>>
>>>>>>>> The DEFINITION of the problem that H is set to solve is to
>>>>>>>> predict the behavior of the machine that its input is a
>>>>>>>> representation of [Which will be the actual computatipn P(P)]
>>>>>>>> which would be the equvalent of giving the same input as given
>>>>>>>> to H to a real pure simulator like a UTM which simulates until
>>>>>>>> the computation reaches its end (or simulates forever if it
>>>>>>>> never will).
>>>>>>>>
>>>>>>>
>>>>>>> The computation of H(P,P) is entirely contained within the
>>>>>>> computation of P(P) as a part of this larger computation. This by
>>>>>>> itself conclusively proves that they are not the same.
>>>>>>>
>>>>>>
>>>>>> No one said that H(P,P) and P(P) were the same computation, and
>>>>>> they can't be.
>>>>>>
>>>>> At the TM level the halt decider must report the actual behavior of
>>>>> the simulation of the TM descrition on its tape.
>>>>>
>>>>
>>>> No, it must report the actual behavior of the machine represented on
>>>> the Tape, or equivalently, what a UTM would do if given this exact
>>>> same input.
>>>>
>>>
>>> All the "represented" means is that the halt decider is looking at
>>> the source-code of the TM.
>>
>> No, it doesn't. Perhaps 'Source Code' might be one way to represent
>> the Turing Machine, but it isn't a required way.
>>
>
> All that "represented" means is that the halt decider bases its decision
> on the TM description that is on the tape not the execution of the
> actual TM. The TM description "represents" the TM to be analyzed meaning
> that it is not the actual TM itself.

Right, the Decider works with the representation, but its answer needs
to match the behavior of the ACTUAL machine. That is one of the 'tough'
parts of the challenge.

That is why, when I am being precise, I put the brackets <> arround an
input to mark that it is actually a representation, not the machine
itself. That is Why Linz give H the input wM, the representation of M,
instead of M itself, BUT the condition on the answer that H needs to
give is based on M applied to w, not something using wM.

>
>> We need to give a representation because you can't give an actual
>> Turing Machine as an input, as it is the wrong sort of thing.
>>
>
> Yes.
>
>> If you wanted your computer to figure out some performance data about
>> your car, you don't give your computer your car as 'Input' because
>> that doesn't make sense. Instead you 'convert' your car into a
>> suitable representation that has all the details about the car, and
>> that 'representation' is given to the computer.
>>
>> Turing Machines can ge defined by a set of Tupples, (Input state,
>> Input Symbol, Next State, Output Symbol, Tape motion) but this can't
>> just be put on the tape, as the 'alphabet' of the Tape likely can't
>> directly express this, so we need to 'represent' this definition in
>> some way for the decider.
>
>
> A turing machine is a model of a computer.

No, it isn't, it is a model of Computation. It can't be a model of a
'Computer', as Computers, as you think of them didn't exits when Turing
Machines were created.

> It has a finite number of
> states, and it is capable of reading and modifying a tape.  A turing
> machine program consists of a list of 'quintuples', each one of which is
> a five-symbol turing machine instruction.
> http://www.lns.mit.edu/~dsw/turing/doc/tm_manual.txt
> > If we don't assume some kind of nutty half-bit sized tape element it is
> enormously easy to put a 'quintuple' on the tape.
>

You just don't understand the concept of abstract computation
structures. You can put a REPRESENTATION of a quintuple on the tape, you
can't put the actual quintuple on the tape, unless the 'Alphabet' of you
tape includes that quintuple as a 'Character' of the alphabet.

On 11/12/21 12:32 AM, olcott wrote:
> On 11/11/2021 11:24 PM, André G. Isaak wrote:
>> On 2021-11-11 21:08, Richard Damon wrote:
>>
>>> If you wanted your computer to figure out some performance data about
>>> your car, you don't give your computer your car as 'Input' because
>>> that doesn't make sense. Instead you 'convert' your car into a
>>> suitable representation that has all the details about the car, and
>>> that 'representation' is given to the computer.
>>
>> And, crucially in this example, you're presumably interested in the
>> performance of the *actual* car. If the simulation of the
>> representation passed as an input doesn't match the behaviour of the
>> actual car no one is going to accept the argument that the simulator
>> is still correct because it answers 'correctly' about 'its input'.
>>
>> André
>>
>
> It is the behavior of the TM description that is on the tape that can be
> most accurately demonstrated by simply simulating it. If the simulated
> input never reaches its final state then this input never halts.

Except that the input that is on the tape WILL halt if it was given to a
real pure simulator instead of one that aborts it.

The issue is that an aborted simulation doesn't prove anything.

You in fact, do provide a simulation that SHOWS that a proper simulation
of you P will halt, you do this with H1, since H1 never aborted its
simulation, its simulation is pure, and the fact that H1 sees P(P) as
halting shows that it is, and that H got the wrong answer.

>
> The equivalent for the C/x86 mode of computation is the parameters that
> have been pushed on the stack.

Nope. Pushing on the stack and creating a representation are TOTALLY
different types of operations.

>
> Ben did a good job cleaning up the syntax of my code.
>

On 2021-11-11 22:32, olcott wrote:
> On 11/11/2021 11:24 PM, André G. Isaak wrote:
>> On 2021-11-11 21:08, Richard Damon wrote:
>>
>>> If you wanted your computer to figure out some performance data about
>>> your car, you don't give your computer your car as 'Input' because
>>> that doesn't make sense. Instead you 'convert' your car into a
>>> suitable representation that has all the details about the car, and
>>> that 'representation' is given to the computer.
>>
>> And, crucially in this example, you're presumably interested in the
>> performance of the *actual* car. If the simulation of the
>> representation passed as an input doesn't match the behaviour of the
>> actual car no one is going to accept the argument that the simulator
>> is still correct because it answers 'correctly' about 'its input'.
>>
>> André
>>
>
> It is the behavior of the TM description that is on the tape that can be > most accurately demonstrated by simply simulating it. If the simulated
> input never reaches its final state then this input never halts.

The TM description doesn't have a behaviour. Only the machine
represented by that description has a behaviour, and its about that
machine that your decider must answer. If I give it a description of P,
wP, and an input string w, I want to know whether P(w) halts. I don't
want to know anything about wP, w.

André

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