On 2022-05-27 16:13, olcott wrote:
> On 5/27/2022 4:41 PM, André G. Isaak wrote:
>> On 2022-05-27 15:31, olcott wrote:
>>> On 5/27/2022 4:21 PM, André G. Isaak wrote:
>>>> On 2022-05-27 14:38, olcott wrote:
>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>>>> The input to H is NOT a "sequence of configuratios", but the
>>>>>>>>>> representation of an algorithm and its input.
>>>>>>>>>
>>>>>>>>> The finite string inputs to a halt decider specify (rather then
>>>>>>>>> merely represent) a sequence of configurations that may or may
>>>>>>>>> not reach their own final state.
>>>>>>>>
>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>> 'represent', 'specify', or 'sequence of configurations' mean.
>>>>>>>> Richard is perfectly correct. You, as usual, are not.
>>>>>>>>
>>>>>>>
>>>>>>> The distinction that I make between represent and specify is that
>>>>>>> the x86 source-code for P represents P(P) whereas the actual
>>>>>>> correct x86 emulation of the input to H(P,P) specifies the actual
>>>>>>> behavior of this input. This is not the same behavior as the
>>>>>>> behavior specified by P(P).
>>>>>>>
>>>>>>> A sequence of configurations means a list of x86 program steps
>>>>>>> executed or emulated in the order that their source-code specifies.
>>>>>>>
>>>>>>> Likewise with a TM or the UTM simulation of a TM description
>>>>>>> specifies a sequence of state transitions.
>>>>>>
>>>>>> And this decidedly is *not* what a halt decider is given as its
>>>>>> input. It is not given a sequence of state transitions. It is
>>>>>> given a representation of a computation.
>>>>>>
>>>>>
>>>>> No it is not and you know that it is not. A halt decider is given a
>>>>> finite string TM description that specifies a sequence of
>>>>> configurations.
>>>>
>>>> A TM description and a sequence of configurations are entirely
>>>> different things (and the former certainly does not 'specify' the
>>>> latter). It's given either one or the other. Make up your mind.
>>>>
>>>> André
>>>>
>>>
>>> _Infinite_Loop()
>>> [000012c2](01)  55              push ebp
>>> [000012c3](02)  8bec            mov ebp,esp
>>> [000012c5](02)  ebfe            jmp 000012c5
>>> [000012c7](01)  5d              pop ebp
>>> [000012c8](01)  c3              ret
>>> Size in bytes:(0007) [000012c8]
>>>
>>> So then the above x86 code may specify a game of tic-tac-toe and
>>> there is no possible way to determine that it does not because the
>>> x86 source code of a function has nothing to do with the sequence of
>>> steps of its correct simulation.
>>
>>
>> That is not a sequence of configurations. It is a piece of assembly
>> code which represents a subroutine which is an infinite loop. The
>> sequence of configurations would look something like this:
>>
>
> Yes that code specifies this sequence.

No, it does not. What you have above only generates the following *only*
if you (a) interpret it as representing x86 instructions and (b)
actually execute it on an x86 or some appropriate emulator.

You keep claiming that the input to the decider is a sequence of
configurations, but that's just plain wrong. It is something which H
might possibly *use* to derive such a sequence but only when interpreted
in an appropriate way and only given an appropriate algorithm for doing so.

Just because you can get from A to B doesn't mean it is accurate to
refer to A as B.

André

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

On 5/27/2022 5:26 PM, André G. Isaak wrote:
> On 2022-05-27 16:13, olcott wrote:
>> On 5/27/2022 4:41 PM, André G. Isaak wrote:
>>> On 2022-05-27 15:31, olcott wrote:
>>>> On 5/27/2022 4:21 PM, André G. Isaak wrote:
>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>>>> The input to H is NOT a "sequence of configuratios", but the
>>>>>>>>>>> representation of an algorithm and its input.
>>>>>>>>>>
>>>>>>>>>> The finite string inputs to a halt decider specify (rather
>>>>>>>>>> then merely represent) a sequence of configurations that may
>>>>>>>>>> or may not reach their own final state.
>>>>>>>>>
>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' mean.
>>>>>>>>> Richard is perfectly correct. You, as usual, are not.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The distinction that I make between represent and specify is
>>>>>>>> that the x86 source-code for P represents P(P) whereas the
>>>>>>>> actual correct x86 emulation of the input to H(P,P) specifies
>>>>>>>> the actual behavior of this input. This is not the same behavior
>>>>>>>> as the behavior specified by P(P).
>>>>>>>>
>>>>>>>> A sequence of configurations means a list of x86 program steps
>>>>>>>> executed or emulated in the order that their source-code specifies.
>>>>>>>>
>>>>>>>> Likewise with a TM or the UTM simulation of a TM description
>>>>>>>> specifies a sequence of state transitions.
>>>>>>>
>>>>>>> And this decidedly is *not* what a halt decider is given as its
>>>>>>> input. It is not given a sequence of state transitions. It is
>>>>>>> given a representation of a computation.
>>>>>>>
>>>>>>
>>>>>> No it is not and you know that it is not. A halt decider is given
>>>>>> a finite string TM description that specifies a sequence of
>>>>>> configurations.
>>>>>
>>>>> A TM description and a sequence of configurations are entirely
>>>>> different things (and the former certainly does not 'specify' the
>>>>> latter). It's given either one or the other. Make up your mind.
>>>>>
>>>>> André
>>>>>
>>>>
>>>> _Infinite_Loop()
>>>> [000012c2](01)  55              push ebp
>>>> [000012c3](02)  8bec            mov ebp,esp
>>>> [000012c5](02)  ebfe            jmp 000012c5
>>>> [000012c7](01)  5d              pop ebp
>>>> [000012c8](01)  c3              ret
>>>> Size in bytes:(0007) [000012c8]
>>>>
>>>> So then the above x86 code may specify a game of tic-tac-toe and
>>>> there is no possible way to determine that it does not because the
>>>> x86 source code of a function has nothing to do with the sequence of
>>>> steps of its correct simulation.
>>>
>>>
>>> That is not a sequence of configurations. It is a piece of assembly
>>> code which represents a subroutine which is an infinite loop. The
>>> sequence of configurations would look something like this:
>>>
>>
>> Yes that code specifies this sequence.
>
> No, it does not. What you have above only generates the following *only*
> if you (a) interpret it as representing x86 instructions and (b)
> actually execute it on an x86 or some appropriate emulator.
>

Because no one in their right mind would think of doing it otherwise
those ridiculously self-evident facts need not be stated.

If it was not for communication context then every single rule of
grammar would have to be repeated with every sentence and every
definition of every work would have to be repeated over and over.

> You keep claiming that the input to the decider is a sequence of
> configurations, but that's just plain wrong.

The input to a decider

SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
A sequence of configirations

Did you notice that I said SPECFIES this time ???

> It is something which H
> might possibly *use* to derive such a sequence but only when interpreted
> in an appropriate way and only given an appropriate algorithm for doing so.
>

<sarcasm>
Yes and because it has not been explicitly specified maybe I am talking
about space aliens that are going to invade the Earth in a space alien
language that closely resembles a discussion on halt deciders in English?

Since I did not explicitly specify that I am talking in English and not
space alien you have no sufficient basis to have any idea what my words
actually mean.
</sarcasm>

> Just because you can get from A to B doesn't mean it is accurate to
> refer to A as B.
>
> André
>

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 5/27/22 6:42 PM, olcott wrote:
> On 5/27/2022 5:26 PM, André G. Isaak wrote:
>> On 2022-05-27 16:13, olcott wrote:
>>> On 5/27/2022 4:41 PM, André G. Isaak wrote:
>>>> On 2022-05-27 15:31, olcott wrote:
>>>>> On 5/27/2022 4:21 PM, André G. Isaak wrote:
>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios", but the
>>>>>>>>>>>> representation of an algorithm and its input.
>>>>>>>>>>>
>>>>>>>>>>> The finite string inputs to a halt decider specify (rather
>>>>>>>>>>> then merely represent) a sequence of configurations that may
>>>>>>>>>>> or may not reach their own final state.
>>>>>>>>>>
>>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' mean.
>>>>>>>>>> Richard is perfectly correct. You, as usual, are not.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The distinction that I make between represent and specify is
>>>>>>>>> that the x86 source-code for P represents P(P) whereas the
>>>>>>>>> actual correct x86 emulation of the input to H(P,P) specifies
>>>>>>>>> the actual behavior of this input. This is not the same
>>>>>>>>> behavior as the behavior specified by P(P).
>>>>>>>>>
>>>>>>>>> A sequence of configurations means a list of x86 program steps
>>>>>>>>> executed or emulated in the order that their source-code
>>>>>>>>> specifies.
>>>>>>>>>
>>>>>>>>> Likewise with a TM or the UTM simulation of a TM description
>>>>>>>>> specifies a sequence of state transitions.
>>>>>>>>
>>>>>>>> And this decidedly is *not* what a halt decider is given as its
>>>>>>>> input. It is not given a sequence of state transitions. It is
>>>>>>>> given a representation of a computation.
>>>>>>>>
>>>>>>>
>>>>>>> No it is not and you know that it is not. A halt decider is given
>>>>>>> a finite string TM description that specifies a sequence of
>>>>>>> configurations.
>>>>>>
>>>>>> A TM description and a sequence of configurations are entirely
>>>>>> different things (and the former certainly does not 'specify' the
>>>>>> latter). It's given either one or the other. Make up your mind.
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> _Infinite_Loop()
>>>>> [000012c2](01)  55              push ebp
>>>>> [000012c3](02)  8bec            mov ebp,esp
>>>>> [000012c5](02)  ebfe            jmp 000012c5
>>>>> [000012c7](01)  5d              pop ebp
>>>>> [000012c8](01)  c3              ret
>>>>> Size in bytes:(0007) [000012c8]
>>>>>
>>>>> So then the above x86 code may specify a game of tic-tac-toe and
>>>>> there is no possible way to determine that it does not because the
>>>>> x86 source code of a function has nothing to do with the sequence
>>>>> of steps of its correct simulation.
>>>>
>>>>
>>>> That is not a sequence of configurations. It is a piece of assembly
>>>> code which represents a subroutine which is an infinite loop. The
>>>> sequence of configurations would look something like this:
>>>>
>>>
>>> Yes that code specifies this sequence.
>>
>> No, it does not. What you have above only generates the following
>> *only* if you (a) interpret it as representing x86 instructions and
>> (b) actually execute it on an x86 or some appropriate emulator.
>>
>
> Because no one in their right mind would think of doing it otherwise
> those ridiculously self-evident facts need not be stated.
>
> If it was not for communication context then every single rule of
> grammar would have to be repeated with every sentence and every
> definition of every work would have to be repeated over and over.
>
>> You keep claiming that the input to the decider is a sequence of
>> configurations, but that's just plain wrong.
>
> The input to a decider
>
> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
> A sequence of configirations
>
> Did you notice that I said SPECFIES this time ???
>
>
>> It is something which H might possibly *use* to derive such a sequence
>> but only when interpreted in an appropriate way and only given an
>> appropriate algorithm for doing so.
>>
>
> <sarcasm>
> Yes and because it has not been explicitly specified maybe I am talking
> about space aliens that are going to invade the Earth in a space alien
> language that closely resembles a discussion on halt deciders in English?
>
> Since I did not explicitly specify that I am talking in English and not
> space alien you have no sufficient basis to have any idea what my words
> actually mean.
> </sarcasm>
>
>> Just because you can get from A to B doesn't mean it is accurate to
>> refer to A as B.
>>
>> André
>>
>
>

I think what Andre is pointing out is that the string itself doesn't
generate the sequence of states, but only when interpreted as
representing the computation that it is supposed to.

The byte sequence of a program doesn't definitively specify the program
it is a reprentation of, as it could be given to a different program
using a different sort of representation, and maybe it is just a string
of characters or numbers.

The key is the string itself doesn't do anything, it has no "behavior",
only by looking at what it represents do you get any such behavior.

Like the string "11" might represent any of a number of numbers, It
might be the decimal number 2, if using unary encoding (the number N is
represented by N 1s), it might be the decimal number 3 if using binary
encoding, or it might be decimal 11 if using decimal encoding, it might
even be decimal 17, if using hexadecimal encoding.

Thus, the string itself has no definitive meaning, only under a
definition of interpretation.

On 5/27/2022 6:18 PM, Richard Damon wrote:
> On 5/27/22 6:42 PM, olcott wrote:
>> On 5/27/2022 5:26 PM, André G. Isaak wrote:
>>> On 2022-05-27 16:13, olcott wrote:
>>>> On 5/27/2022 4:41 PM, André G. Isaak wrote:
>>>>> On 2022-05-27 15:31, olcott wrote:
>>>>>> On 5/27/2022 4:21 PM, André G. Isaak wrote:
>>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios", but
>>>>>>>>>>>>> the representation of an algorithm and its input.
>>>>>>>>>>>>
>>>>>>>>>>>> The finite string inputs to a halt decider specify (rather
>>>>>>>>>>>> then merely represent) a sequence of configurations that may
>>>>>>>>>>>> or may not reach their own final state.
>>>>>>>>>>>
>>>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' mean.
>>>>>>>>>>> Richard is perfectly correct. You, as usual, are not.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The distinction that I make between represent and specify is
>>>>>>>>>> that the x86 source-code for P represents P(P) whereas the
>>>>>>>>>> actual correct x86 emulation of the input to H(P,P) specifies
>>>>>>>>>> the actual behavior of this input. This is not the same
>>>>>>>>>> behavior as the behavior specified by P(P).
>>>>>>>>>>
>>>>>>>>>> A sequence of configurations means a list of x86 program steps
>>>>>>>>>> executed or emulated in the order that their source-code
>>>>>>>>>> specifies.
>>>>>>>>>>
>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM description
>>>>>>>>>> specifies a sequence of state transitions.
>>>>>>>>>
>>>>>>>>> And this decidedly is *not* what a halt decider is given as its
>>>>>>>>> input. It is not given a sequence of state transitions. It is
>>>>>>>>> given a representation of a computation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No it is not and you know that it is not. A halt decider is
>>>>>>>> given a finite string TM description that specifies a sequence
>>>>>>>> of configurations.
>>>>>>>
>>>>>>> A TM description and a sequence of configurations are entirely
>>>>>>> different things (and the former certainly does not 'specify' the
>>>>>>> latter). It's given either one or the other. Make up your mind.
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>
>>>>>> _Infinite_Loop()
>>>>>> [000012c2](01)  55              push ebp
>>>>>> [000012c3](02)  8bec            mov ebp,esp
>>>>>> [000012c5](02)  ebfe            jmp 000012c5
>>>>>> [000012c7](01)  5d              pop ebp
>>>>>> [000012c8](01)  c3              ret
>>>>>> Size in bytes:(0007) [000012c8]
>>>>>>
>>>>>> So then the above x86 code may specify a game of tic-tac-toe and
>>>>>> there is no possible way to determine that it does not because the
>>>>>> x86 source code of a function has nothing to do with the sequence
>>>>>> of steps of its correct simulation.
>>>>>
>>>>>
>>>>> That is not a sequence of configurations. It is a piece of assembly
>>>>> code which represents a subroutine which is an infinite loop. The
>>>>> sequence of configurations would look something like this:
>>>>>
>>>>
>>>> Yes that code specifies this sequence.
>>>
>>> No, it does not. What you have above only generates the following
>>> *only* if you (a) interpret it as representing x86 instructions and
>>> (b) actually execute it on an x86 or some appropriate emulator.
>>>
>>
>> Because no one in their right mind would think of doing it otherwise
>> those ridiculously self-evident facts need not be stated.
>>
>> If it was not for communication context then every single rule of
>> grammar would have to be repeated with every sentence and every
>> definition of every work would have to be repeated over and over.
>>
>>> You keep claiming that the input to the decider is a sequence of
>>> configurations, but that's just plain wrong.
>>
>> The input to a decider
>>
>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>> A sequence of configirations
>>
>> Did you notice that I said SPECFIES this time ???
>>
>>
>>> It is something which H might possibly *use* to derive such a
>>> sequence but only when interpreted in an appropriate way and only
>>> given an appropriate algorithm for doing so.
>>>
>>
>> <sarcasm>
>> Yes and because it has not been explicitly specified maybe I am
>> talking about space aliens that are going to invade the Earth in a
>> space alien language that closely resembles a discussion on halt
>> deciders in English?
>>
>> Since I did not explicitly specify that I am talking in English and
>> not space alien you have no sufficient basis to have any idea what my
>> words actually mean.
>> </sarcasm>
>>
>>> Just because you can get from A to B doesn't mean it is accurate to
>>> refer to A as B.
>>>
>>> André
>>>
>>
>>
>
> I think what Andre is pointing out is that the string itself doesn't
> generate the sequence of states, but only when interpreted as
> representing the computation that it is supposed to.
>
Yes and according the his reasoning I must endlessly repeat that every
sentence is written in English and not some space alien language that
looks just like English.

It would never ever occur to anyone that x86 source code must be
interpreted by an x86 emulator because nearly everyone would naturally
assume that x86 source-code is one of the ingredients to a milkshake.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 5/27/22 7:26 PM, olcott wrote:
> On 5/27/2022 6:18 PM, Richard Damon wrote:
>> On 5/27/22 6:42 PM, olcott wrote:
>>> On 5/27/2022 5:26 PM, André G. Isaak wrote:
>>>> On 2022-05-27 16:13, olcott wrote:
>>>>> On 5/27/2022 4:41 PM, André G. Isaak wrote:
>>>>>> On 2022-05-27 15:31, olcott wrote:
>>>>>>> On 5/27/2022 4:21 PM, André G. Isaak wrote:
>>>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios", but
>>>>>>>>>>>>>> the representation of an algorithm and its input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The finite string inputs to a halt decider specify (rather
>>>>>>>>>>>>> then merely represent) a sequence of configurations that
>>>>>>>>>>>>> may or may not reach their own final state.
>>>>>>>>>>>>
>>>>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations'
>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are not.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The distinction that I make between represent and specify is
>>>>>>>>>>> that the x86 source-code for P represents P(P) whereas the
>>>>>>>>>>> actual correct x86 emulation of the input to H(P,P) specifies
>>>>>>>>>>> the actual behavior of this input. This is not the same
>>>>>>>>>>> behavior as the behavior specified by P(P).
>>>>>>>>>>>
>>>>>>>>>>> A sequence of configurations means a list of x86 program
>>>>>>>>>>> steps executed or emulated in the order that their
>>>>>>>>>>> source-code specifies.
>>>>>>>>>>>
>>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM description
>>>>>>>>>>> specifies a sequence of state transitions.
>>>>>>>>>>
>>>>>>>>>> And this decidedly is *not* what a halt decider is given as
>>>>>>>>>> its input. It is not given a sequence of state transitions. It
>>>>>>>>>> is given a representation of a computation.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No it is not and you know that it is not. A halt decider is
>>>>>>>>> given a finite string TM description that specifies a sequence
>>>>>>>>> of configurations.
>>>>>>>>
>>>>>>>> A TM description and a sequence of configurations are entirely
>>>>>>>> different things (and the former certainly does not 'specify'
>>>>>>>> the latter). It's given either one or the other. Make up your mind.
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>
>>>>>>> _Infinite_Loop()
>>>>>>> [000012c2](01)  55              push ebp
>>>>>>> [000012c3](02)  8bec            mov ebp,esp
>>>>>>> [000012c5](02)  ebfe            jmp 000012c5
>>>>>>> [000012c7](01)  5d              pop ebp
>>>>>>> [000012c8](01)  c3              ret
>>>>>>> Size in bytes:(0007) [000012c8]
>>>>>>>
>>>>>>> So then the above x86 code may specify a game of tic-tac-toe and
>>>>>>> there is no possible way to determine that it does not because
>>>>>>> the x86 source code of a function has nothing to do with the
>>>>>>> sequence of steps of its correct simulation.
>>>>>>
>>>>>>
>>>>>> That is not a sequence of configurations. It is a piece of
>>>>>> assembly code which represents a subroutine which is an infinite
>>>>>> loop. The sequence of configurations would look something like this:
>>>>>>
>>>>>
>>>>> Yes that code specifies this sequence.
>>>>
>>>> No, it does not. What you have above only generates the following
>>>> *only* if you (a) interpret it as representing x86 instructions and
>>>> (b) actually execute it on an x86 or some appropriate emulator.
>>>>
>>>
>>> Because no one in their right mind would think of doing it otherwise
>>> those ridiculously self-evident facts need not be stated.
>>>
>>> If it was not for communication context then every single rule of
>>> grammar would have to be repeated with every sentence and every
>>> definition of every work would have to be repeated over and over.
>>>
>>>> You keep claiming that the input to the decider is a sequence of
>>>> configurations, but that's just plain wrong.
>>>
>>> The input to a decider
>>>
>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>> A sequence of configirations
>>>
>>> Did you notice that I said SPECFIES this time ???
>>>
>>>
>>>> It is something which H might possibly *use* to derive such a
>>>> sequence but only when interpreted in an appropriate way and only
>>>> given an appropriate algorithm for doing so.
>>>>
>>>
>>> <sarcasm>
>>> Yes and because it has not been explicitly specified maybe I am
>>> talking about space aliens that are going to invade the Earth in a
>>> space alien language that closely resembles a discussion on halt
>>> deciders in English?
>>>
>>> Since I did not explicitly specify that I am talking in English and
>>> not space alien you have no sufficient basis to have any idea what my
>>> words actually mean.
>>> </sarcasm>
>>>
>>>> Just because you can get from A to B doesn't mean it is accurate to
>>>> refer to A as B.
>>>>
>>>> André
>>>>
>>>
>>>
>>
>> I think what Andre is pointing out is that the string itself doesn't
>> generate the sequence of states, but only when interpreted as
>> representing the computation that it is supposed to.
>>
> Yes and according the his reasoning I must endlessly repeat that every
> sentence is written in English and not some space alien language that
> looks just like English.
>
> It would never ever occur to anyone that x86 source code must be
> interpreted by an x86 emulator because nearly everyone would naturally
> assume that x86 source-code is one of the ingredients to a milkshake.
>

No, the key point in to not assign to things properties that it doesn't
have.

"Inputs" do not have behaviors. The Machines they represent do.

The key point here is that it is clear that the input P,P is actually
refering to the behavior of the ACTUAL machine P with input P, and not
just what H happens to get out of partial simulation of it.

It makes it clear that when H aborts its simulation, that doesn't stop
"the behavior of the input", since that behavior is of the actual
machine that it represents, that H can't actually touch.

On 5/28/2022 10:23 AM, Dennis Bush wrote:
> On Saturday, May 28, 2022 at 11:06:06 AM UTC-4, olcott wrote:
>> On 5/28/2022 8:58 AM, Richard Damon wrote:
>>>
>>> On 5/28/22 6:26 AM, olcott wrote:
>>>> On 5/27/2022 7:33 PM, Richard Damon wrote:
>>>>> On 5/27/22 7:33 PM, olcott wrote:
>>>>>> On 5/27/2022 6:26 PM, André G. Isaak wrote:
>>>>>>> On 2022-05-27 16:42, olcott wrote:
>>>>>>>> On 5/27/2022 5:26 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-05-27 16:13, olcott wrote:
>>>>>>>>>> On 5/27/2022 4:41 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2022-05-27 15:31, olcott wrote:
>>>>>>>>>>>> On 5/27/2022 4:21 PM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios",
>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The finite string inputs to a halt decider specify
>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of
>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own final
>>>>>>>>>>>>>>>>>> state.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations'
>>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are not.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The distinction that I make between represent and specify
>>>>>>>>>>>>>>>> is that the x86 source-code for P represents P(P) whereas
>>>>>>>>>>>>>>>> the actual correct x86 emulation of the input to H(P,P)
>>>>>>>>>>>>>>>> specifies the actual behavior of this input. This is not
>>>>>>>>>>>>>>>> the same behavior as the behavior specified by P(P).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A sequence of configurations means a list of x86 program
>>>>>>>>>>>>>>>> steps executed or emulated in the order that their
>>>>>>>>>>>>>>>> source-code specifies.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM
>>>>>>>>>>>>>>>> description specifies a sequence of state transitions.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And this decidedly is *not* what a halt decider is given as
>>>>>>>>>>>>>>> its input. It is not given a sequence of state transitions.
>>>>>>>>>>>>>>> It is given a representation of a computation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No it is not and you know that it is not. A halt decider is
>>>>>>>>>>>>>> given a finite string TM description that specifies a
>>>>>>>>>>>>>> sequence of configurations.
>>>>>>>>>>>>>
>>>>>>>>>>>>> A TM description and a sequence of configurations are
>>>>>>>>>>>>> entirely different things (and the former certainly does not
>>>>>>>>>>>>> 'specify' the latter). It's given either one or the other.
>>>>>>>>>>>>> Make up your mind.
>>>>>>>>>>>>>
>>>>>>>>>>>>> André
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>> [000012c2](01) 55 push ebp
>>>>>>>>>>>> [000012c3](02) 8bec mov ebp,esp
>>>>>>>>>>>> [000012c5](02) ebfe jmp 000012c5
>>>>>>>>>>>> [000012c7](01) 5d pop ebp
>>>>>>>>>>>> [000012c8](01) c3 ret
>>>>>>>>>>>> Size in bytes:(0007) [000012c8]
>>>>>>>>>>>>
>>>>>>>>>>>> So then the above x86 code may specify a game of tic-tac-toe
>>>>>>>>>>>> and there is no possible way to determine that it does not
>>>>>>>>>>>> because the x86 source code of a function has nothing to do
>>>>>>>>>>>> with the sequence of steps of its correct simulation.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> That is not a sequence of configurations. It is a piece of
>>>>>>>>>>> assembly code which represents a subroutine which is an
>>>>>>>>>>> infinite loop. The sequence of configurations would look
>>>>>>>>>>> something like this:
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Yes that code specifies this sequence.
>>>>>>>>>
>>>>>>>>> No, it does not. What you have above only generates the following
>>>>>>>>> *only* if you (a) interpret it as representing x86 instructions
>>>>>>>>> and (b) actually execute it on an x86 or some appropriate emulator.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Because no one in their right mind would think of doing it
>>>>>>>> otherwise those ridiculously self-evident facts need not be stated.
>>>>>>>
>>>>>>> You are the one who constantly makes much ado about nothing about
>>>>>>> the fact that Turing Machines can ONLY accept finite strings as
>>>>>>> their inputs and object to anyone who suggests that something might
>>>>>>> compute some function which isn't over strings.
>>>>>>>
>>>>>>> You don't seem to understand exactly what a finite string is. A
>>>>>>> finite string is simply a sequence of symbols. Given two strings,
>>>>>>> you can ask questions like which is longer or whether one is a
>>>>>>> substring or permutation of the other, but not much else.
>>>>>>>
>>>>>>> That's because neither strings nor the symbols they are composed of
>>>>>>> have any meaning whatsoever. They are just sequences of
>>>>>>> uninterpreted tokens. As soon as you start talking about 'sequences
>>>>>>> of configurations' or 'numerical values' or anything along those
>>>>>>> lines you are no longer talking about finite strings, but about the
>>>>>>> entities which those strings represent to a particular TM/program.
>>>>>>>
>>>>>>> Part of designing a TM involves specifying exactly how a string is
>>>>>>> to be interpreted (however 'ridiculously self-evident' it might
>>>>>>> seem to you) So yes, they need to be stated.
>>>>>>>
>>>>>>>
>>>>>>>> If it was not for communication context then every single rule of
>>>>>>>> grammar would have to be repeated with every sentence and every
>>>>>>>> definition of every work would have to be repeated over and over.
>>>>>>>>
>>>>>>>>> You keep claiming that the input to the decider is a sequence of
>>>>>>>>> configurations, but that's just plain wrong.
>>>>>>>>
>>>>>>>> The input to a decider
>>>>>>>>
>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>> A sequence of configirations
>>>>>>>>
>>>>>>>> Did you notice that I said SPECFIES this time ???
>>>>>>>
>>>>>>> But you still haven't provided a coherent definition of what *you*
>>>>>>> mean by 'specify'. You gave a bit of wishy-washy verbiage a few
>>>>>>> posts ago, but nothing which made this clear. Repeating it over and
>>>>>>> over again doesn't add any clarity.
>>>>>>
>>>>>>> The question originally arose when you objected to the claim that
>>>>>>> the input to a halt decider represents a computation (or TM
>>>>>>> description/input string pair) and instead insisted that it
>>>>>>> specifies a sequence of configurations.
>>>>>>>
>>>>>>
>>>>>> Yes of course as everyone knows x86 source-code is one of the
>>>>>> ingredients to a milkshake and because there is a standard practice
>>>>>> for making milkshakes they already know when and how the x86
>>>>>> source-code must be applied to make a milkshake.
>>>>>>
>>>>>>> Now it seems like you are trying to claim that a representation of
>>>>>>> a computation specifies a sequence of configurations, but that
>>>>>>> doesn't explain why you so vehemently objected
>>>>>>
>>>>>> Your brain is welded in rebuttal mode?
>>>>>>
>>>>>>> to the claim that the input to a halt decider represents a
>>>>>>> computation. So clearly you mean something else altogether.
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>
>>>>>> Because your brain is welded in rebuttal mode you will always act
>>>>>> like you never know.
>>>>>>
>>>>>
>>>>> No, YOUR brain is welded in stupid mode. You are unable to make a
>>>>> clear sentence because you misuse the English language to hide your
>>>>> lies.
>>>>
>>>> It is easily provable that the C function H(P,P)==0 is correct on the
>>>> basis of the fact correct execution trace of the x86 source-code of
>>>> input to H(P,P) shows that P would never reach its "ret" instruction.
>>>
>>> Again, I say HOW, since the CORRECT emulation of the input to H(P,P), as
>>> shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H is
>>> defined to return 0 from H(P,P).
>> Richard is one of the two liars.
>> *The actual behavior of P when correctly emulated by H is shown below*
>>
>> #include <stdint.h>
>> #define u32 uint32_t
>>
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H((u32)P, (u32)P));
>> }
>>
>> _P()
>> [00001352](01) 55 push ebp
>> [00001353](02) 8bec mov ebp,esp
>> [00001355](03) 8b4508 mov eax,[ebp+08]
>> [00001358](01) 50 push eax // push P
>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>> [0000135c](01) 51 push ecx // push P
>> [0000135d](05) e840feffff call 000011a2 // call H
>> [00001362](03) 83c408 add esp,+08
>> [00001365](02) 85c0 test eax,eax
>> [00001367](02) 7402 jz 0000136b
>> [00001369](02) ebfe jmp 00001369
>> [0000136b](01) 5d pop ebp
>> [0000136c](01) c3 ret
>> Size in bytes:(0027) [0000136c]
>>
>> _main()
>> [00001372](01) 55 push ebp
>> [00001373](02) 8bec mov ebp,esp
>> [00001375](05) 6852130000 push 00001352 // push P
>> [0000137a](05) 6852130000 push 00001352 // push P
>> [0000137f](05) e81efeffff call 000011a2 // call H
>> [00001384](03) 83c408 add esp,+08
>> [00001387](01) 50 push eax
>> [00001388](05) 6823040000 push 00000423 // "Input_Halts = "
>> [0000138d](05) e8e0f0ffff call 00000472 // call Output
>> [00001392](03) 83c408 add esp,+08
>> [00001395](02) 33c0 xor eax,eax
>> [00001397](01) 5d pop ebp
>> [00001398](01) c3 ret
>> Size in bytes:(0039) [00001398]
>>
>> machine stack stack machine assembly
>> address address data code language
>> ======== ======== ======== ========= =============
>> ...[00001372][0010229e][00000000] 55 push ebp
>> ...[00001373][0010229e][00000000] 8bec mov ebp,esp
>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>>
>> Begin Local Halt Decider Simulation Execution Trace Stored at:212352
>>
>> // H emulates the first seven instructions of P
>> ...[00001352][0021233e][00212342] 55 push ebp // enter P
>> ...[00001353][0021233e][00212342] 8bec mov ebp,esp
>> ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
>> ...[00001358][0021233a][00001352] 50 push eax // push P
>> ...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
>> ...[0000135c][00212336][00001352] 51 push ecx // push P
>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>
> Starting here is where the trace is incomplete. The emulation of the instructions of the inner instance of H are not shown. Also the lines below are not emulated by the top level H. They are emulated by the inner H called by P. So in between each of these lines is multiple instructions of the inner H performing the emulation of them.
>
>>
>> // The emulated H emulates the first seven instructions of P
>> ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
>> ...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
>> ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
>> ...[00001358][0025cd62][00001352] 50 push eax // push P
>> ...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
>> ...[0000135c][0025cd5e][00001352] 51 push ecx // push P
>> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> Here is where H makes its error of aborting too soon. Explanation below:
>

On 5/28/2022 10:29 AM, Richard Damon wrote:
>
> On 5/28/22 11:05 AM, olcott wrote:
>> On 5/28/2022 8:58 AM, Richard Damon wrote:
>>>
>>> On 5/28/22 6:26 AM, olcott wrote:
>>>> On 5/27/2022 7:33 PM, Richard Damon wrote:
>>>>> On 5/27/22 7:33 PM, olcott wrote:
>>>>>> On 5/27/2022 6:26 PM, André G. Isaak wrote:
>>>>>>> On 2022-05-27 16:42, olcott wrote:
>>>>>>>> On 5/27/2022 5:26 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-05-27 16:13, olcott wrote:
>>>>>>>>>> On 5/27/2022 4:41 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2022-05-27 15:31, olcott wrote:
>>>>>>>>>>>> On 5/27/2022 4:21 PM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios",
>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The finite string inputs to a halt decider specify
>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of
>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own
>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations'
>>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are
>>>>>>>>>>>>>>>>> not.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The distinction that I make between represent and
>>>>>>>>>>>>>>>> specify is that the x86 source-code for P represents
>>>>>>>>>>>>>>>> P(P) whereas the actual correct x86 emulation of the
>>>>>>>>>>>>>>>> input to H(P,P) specifies the actual behavior of this
>>>>>>>>>>>>>>>> input. This is not the same behavior as the behavior
>>>>>>>>>>>>>>>> specified by P(P).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A sequence of configurations means a list of x86 program
>>>>>>>>>>>>>>>> steps executed or emulated in the order that their
>>>>>>>>>>>>>>>> source-code specifies.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM
>>>>>>>>>>>>>>>> description specifies a sequence of state transitions.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And this decidedly is *not* what a halt decider is given
>>>>>>>>>>>>>>> as its input. It is not given a sequence of state
>>>>>>>>>>>>>>> transitions. It is given a representation of a computation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No it is not and you know that it is not. A halt decider
>>>>>>>>>>>>>> is given a finite string TM description that specifies a
>>>>>>>>>>>>>> sequence of configurations.
>>>>>>>>>>>>>
>>>>>>>>>>>>> A TM description and a sequence of configurations are
>>>>>>>>>>>>> entirely different things (and the former certainly does
>>>>>>>>>>>>> not 'specify' the latter). It's given either one or the
>>>>>>>>>>>>> other. Make up your mind.
>>>>>>>>>>>>>
>>>>>>>>>>>>> André
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>> [000012c2](01)  55              push ebp
>>>>>>>>>>>> [000012c3](02)  8bec            mov ebp,esp
>>>>>>>>>>>> [000012c5](02)  ebfe            jmp 000012c5
>>>>>>>>>>>> [000012c7](01)  5d              pop ebp
>>>>>>>>>>>> [000012c8](01)  c3              ret
>>>>>>>>>>>> Size in bytes:(0007) [000012c8]
>>>>>>>>>>>>
>>>>>>>>>>>> So then the above x86 code may specify a game of tic-tac-toe
>>>>>>>>>>>> and there is no possible way to determine that it does not
>>>>>>>>>>>> because the x86 source code of a function has nothing to do
>>>>>>>>>>>> with the sequence of steps of its correct simulation.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> That is not a sequence of configurations. It is a piece of
>>>>>>>>>>> assembly code which represents a subroutine which is an
>>>>>>>>>>> infinite loop. The sequence of configurations would look
>>>>>>>>>>> something like this:
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Yes that code specifies this sequence.
>>>>>>>>>
>>>>>>>>> No, it does not. What you have above only generates the
>>>>>>>>> following *only* if you (a) interpret it as representing x86
>>>>>>>>> instructions and (b) actually execute it on an x86 or some
>>>>>>>>> appropriate emulator.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Because no one in their right mind would think of doing it
>>>>>>>> otherwise those ridiculously self-evident facts need not be stated.
>>>>>>>
>>>>>>> You are the one who constantly makes much ado about nothing about
>>>>>>> the fact that Turing Machines can ONLY accept finite strings as
>>>>>>> their inputs and object to anyone who suggests that something
>>>>>>> might compute some function which isn't over strings.
>>>>>>>
>>>>>>> You don't seem to understand exactly what a finite string is. A
>>>>>>> finite string is simply a sequence of symbols. Given two strings,
>>>>>>> you can ask questions like which is longer or whether one is a
>>>>>>> substring or permutation of the other, but not much else.
>>>>>>>
>>>>>>> That's because neither strings nor the symbols they are composed
>>>>>>> of have any meaning whatsoever. They are just sequences of
>>>>>>> uninterpreted tokens. As soon as you start talking about
>>>>>>> 'sequences of configurations' or 'numerical values' or anything
>>>>>>> along those lines you are no longer talking about finite strings,
>>>>>>> but about the entities which those strings represent to a
>>>>>>> particular TM/program.
>>>>>>>
>>>>>>> Part of designing a TM involves specifying exactly how a string
>>>>>>> is to be interpreted (however 'ridiculously self-evident' it
>>>>>>> might seem to you) So yes, they need to be stated.
>>>>>>>
>>>>>>>
>>>>>>>> If it was not for communication context then every single rule
>>>>>>>> of grammar would have to be repeated with every sentence and
>>>>>>>> every definition of every work would have to be repeated over
>>>>>>>> and over.
>>>>>>>>
>>>>>>>>> You keep claiming that the input to the decider is a sequence
>>>>>>>>> of configurations, but that's just plain wrong.
>>>>>>>>
>>>>>>>> The input to a decider
>>>>>>>>
>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>> A sequence of configirations
>>>>>>>>
>>>>>>>> Did you notice that I said SPECFIES this time ???
>>>>>>>
>>>>>>> But you still haven't provided a coherent definition of what
>>>>>>> *you* mean by 'specify'. You gave a bit of wishy-washy verbiage a
>>>>>>> few posts ago, but nothing which made this clear. Repeating it
>>>>>>> over and over again doesn't add any clarity.
>>>>>>
>>>>>>> The question originally arose when you objected to the claim that
>>>>>>> the input to a halt decider represents a computation (or TM
>>>>>>> description/input string pair) and instead insisted that it
>>>>>>> specifies a sequence of configurations.
>>>>>>>
>>>>>>
>>>>>> Yes of course as everyone knows x86 source-code is one of the
>>>>>> ingredients to a milkshake and because there is a standard
>>>>>> practice for making milkshakes they already know when and how the
>>>>>> x86 source-code must be applied to make a milkshake.
>>>>>>
>>>>>>> Now it seems like you are trying to claim that a representation
>>>>>>> of a computation specifies a sequence of configurations, but that
>>>>>>> doesn't explain why you so vehemently objected
>>>>>>
>>>>>> Your brain is welded in rebuttal mode?
>>>>>>
>>>>>>> to the claim that the input to a halt decider represents a
>>>>>>> computation. So clearly you mean something else altogether.
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>
>>>>>> Because your brain is welded in rebuttal mode you will always act
>>>>>> like you never know.
>>>>>>
>>>>>
>>>>> No, YOUR brain is welded in stupid mode. You are unable to make a
>>>>> clear sentence because you misuse the English language to hide your
>>>>> lies.
>>>>
>>>> It is easily provable that the C function H(P,P)==0 is correct on
>>>> the basis of the fact correct execution trace of the x86 source-code
>>>> of input to H(P,P) shows that P would never reach its "ret"
>>>> instruction.
>>>
>>> Again, I say HOW, since the CORRECT emulation of the input to H(P,P),
>>> as shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H
>>> is defined to return 0 from H(P,P).
>>
>> Richard is one of the two liars.
>> *The actual behavior of P when correctly emulated by H is shown below*
>
>
> No, it isn't, because it LIES.
>>
>> #include <stdint.h>
>> #define u32 uint32_t
>>
>> void P(u32 x)
>> {
>>    if (H(x, x))
>>      HERE: goto HERE;
>>    return;
>> }
>>
>> int main()
>> {
>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>> }
>>
>> _P()
>> [00001352](01)  55              push ebp
>> [00001353](02)  8bec            mov ebp,esp
>> [00001355](03)  8b4508          mov eax,[ebp+08]
>> [00001358](01)  50              push eax      // push P
>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>> [0000135c](01)  51              push ecx      // push P
>> [0000135d](05)  e840feffff      call 000011a2 // call H
>> [00001362](03)  83c408          add esp,+08
>> [00001365](02)  85c0            test eax,eax
>> [00001367](02)  7402            jz 0000136b
>> [00001369](02)  ebfe            jmp 00001369
>> [0000136b](01)  5d              pop ebp
>> [0000136c](01)  c3              ret
>> Size in bytes:(0027) [0000136c]
>>
>> _main()
>> [00001372](01)  55              push ebp
>> [00001373](02)  8bec            mov ebp,esp
>> [00001375](05)  6852130000      push 00001352 // push P
>> [0000137a](05)  6852130000      push 00001352 // push P
>> [0000137f](05)  e81efeffff      call 000011a2 // call H
>> [00001384](03)  83c408          add esp,+08
>> [00001387](01)  50              push eax
>> [00001388](05)  6823040000      push 00000423 // "Input_Halts = "
>> [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
>> [00001392](03)  83c408          add esp,+08
>> [00001395](02)  33c0            xor eax,eax
>> [00001397](01)  5d              pop ebp
>> [00001398](01)  c3              ret
>> Size in bytes:(0039) [00001398]
>>
>>      machine   stack     stack     machine    assembly
>>      address   address   data      code       language
>>      ========  ========  ========  =========  =============
>> ...[00001372][0010229e][00000000] 55         push ebp
>> ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>>
>> Begin Local Halt Decider Simulation   Execution Trace Stored at:212352
>>
>> // H emulates the first seven instructions of P
>> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
>> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
>> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
>> ...[00001358][0021233a][00001352] 50         push eax      // push P
>> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
>> ...[0000135c][00212336][00001352] 51         push ecx      // push P
>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>>
>> // The emulated H emulates the first seven instructions of P
> So, the following is NOT an emulation of the P that the top level H is
> emulating, and

On 5/28/22 11:48 AM, olcott wrote:
> On 5/28/2022 10:23 AM, Dennis Bush wrote:
>> On Saturday, May 28, 2022 at 11:06:06 AM UTC-4, olcott wrote:
>>> On 5/28/2022 8:58 AM, Richard Damon wrote:
>>>>
>>>> On 5/28/22 6:26 AM, olcott wrote:
>>>>> On 5/27/2022 7:33 PM, Richard Damon wrote:
>>>>>> On 5/27/22 7:33 PM, olcott wrote:
>>>>>>> On 5/27/2022 6:26 PM, André G. Isaak wrote:
>>>>>>>> On 2022-05-27 16:42, olcott wrote:
>>>>>>>>> On 5/27/2022 5:26 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-05-27 16:13, olcott wrote:
>>>>>>>>>>> On 5/27/2022 4:41 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2022-05-27 15:31, olcott wrote:
>>>>>>>>>>>>> On 5/27/2022 4:21 PM, André G. Isaak wrote:
>>>>>>>>>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>>>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios",
>>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The finite string inputs to a halt decider specify
>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of
>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own final
>>>>>>>>>>>>>>>>>>> state.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations'
>>>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are
>>>>>>>>>>>>>>>>>> not.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The distinction that I make between represent and specify
>>>>>>>>>>>>>>>>> is that the x86 source-code for P represents P(P) whereas
>>>>>>>>>>>>>>>>> the actual correct x86 emulation of the input to H(P,P)
>>>>>>>>>>>>>>>>> specifies the actual behavior of this input. This is not
>>>>>>>>>>>>>>>>> the same behavior as the behavior specified by P(P).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A sequence of configurations means a list of x86 program
>>>>>>>>>>>>>>>>> steps executed or emulated in the order that their
>>>>>>>>>>>>>>>>> source-code specifies.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM
>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And this decidedly is *not* what a halt decider is given as
>>>>>>>>>>>>>>>> its input. It is not given a sequence of state transitions.
>>>>>>>>>>>>>>>> It is given a representation of a computation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No it is not and you know that it is not. A halt decider is
>>>>>>>>>>>>>>> given a finite string TM description that specifies a
>>>>>>>>>>>>>>> sequence of configurations.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A TM description and a sequence of configurations are
>>>>>>>>>>>>>> entirely different things (and the former certainly does not
>>>>>>>>>>>>>> 'specify' the latter). It's given either one or the other.
>>>>>>>>>>>>>> Make up your mind.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>> [000012c2](01)  55              push ebp
>>>>>>>>>>>>> [000012c3](02)  8bec            mov ebp,esp
>>>>>>>>>>>>> [000012c5](02)  ebfe            jmp 000012c5
>>>>>>>>>>>>> [000012c7](01)  5d              pop ebp
>>>>>>>>>>>>> [000012c8](01)  c3              ret
>>>>>>>>>>>>> Size in bytes:(0007) [000012c8]
>>>>>>>>>>>>>
>>>>>>>>>>>>> So then the above x86 code may specify a game of tic-tac-toe
>>>>>>>>>>>>> and there is no possible way to determine that it does not
>>>>>>>>>>>>> because the x86 source code of a function has nothing to do
>>>>>>>>>>>>> with the sequence of steps of its correct simulation.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> That is not a sequence of configurations. It is a piece of
>>>>>>>>>>>> assembly code which represents a subroutine which is an
>>>>>>>>>>>> infinite loop. The sequence of configurations would look
>>>>>>>>>>>> something like this:
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Yes that code specifies this sequence.
>>>>>>>>>>
>>>>>>>>>> No, it does not. What you have above only generates the following
>>>>>>>>>> *only* if you (a) interpret it as representing x86 instructions
>>>>>>>>>> and (b) actually execute it on an x86 or some appropriate
>>>>>>>>>> emulator.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Because no one in their right mind would think of doing it
>>>>>>>>> otherwise those ridiculously self-evident facts need not be
>>>>>>>>> stated.
>>>>>>>>
>>>>>>>> You are the one who constantly makes much ado about nothing about
>>>>>>>> the fact that Turing Machines can ONLY accept finite strings as
>>>>>>>> their inputs and object to anyone who suggests that something might
>>>>>>>> compute some function which isn't over strings.
>>>>>>>>
>>>>>>>> You don't seem to understand exactly what a finite string is. A
>>>>>>>> finite string is simply a sequence of symbols. Given two strings,
>>>>>>>> you can ask questions like which is longer or whether one is a
>>>>>>>> substring or permutation of the other, but not much else.
>>>>>>>>
>>>>>>>> That's because neither strings nor the symbols they are composed of
>>>>>>>> have any meaning whatsoever. They are just sequences of
>>>>>>>> uninterpreted tokens. As soon as you start talking about 'sequences
>>>>>>>> of configurations' or 'numerical values' or anything along those
>>>>>>>> lines you are no longer talking about finite strings, but about the
>>>>>>>> entities which those strings represent to a particular TM/program.
>>>>>>>>
>>>>>>>> Part of designing a TM involves specifying exactly how a string is
>>>>>>>> to be interpreted (however 'ridiculously self-evident' it might
>>>>>>>> seem to you) So yes, they need to be stated.
>>>>>>>>
>>>>>>>>
>>>>>>>>> If it was not for communication context then every single rule of
>>>>>>>>> grammar would have to be repeated with every sentence and every
>>>>>>>>> definition of every work would have to be repeated over and over.
>>>>>>>>>
>>>>>>>>>> You keep claiming that the input to the decider is a sequence of
>>>>>>>>>> configurations, but that's just plain wrong.
>>>>>>>>>
>>>>>>>>> The input to a decider
>>>>>>>>>
>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>> A sequence of configirations
>>>>>>>>>
>>>>>>>>> Did you notice that I said SPECFIES this time ???
>>>>>>>>
>>>>>>>> But you still haven't provided a coherent definition of what *you*
>>>>>>>> mean by 'specify'. You gave a bit of wishy-washy verbiage a few
>>>>>>>> posts ago, but nothing which made this clear. Repeating it over and
>>>>>>>> over again doesn't add any clarity.
>>>>>>>
>>>>>>>> The question originally arose when you objected to the claim that
>>>>>>>> the input to a halt decider represents a computation (or TM
>>>>>>>> description/input string pair) and instead insisted that it
>>>>>>>> specifies a sequence of configurations.
>>>>>>>>
>>>>>>>
>>>>>>> Yes of course as everyone knows x86 source-code is one of the
>>>>>>> ingredients to a milkshake and because there is a standard practice
>>>>>>> for making milkshakes they already know when and how the x86
>>>>>>> source-code must be applied to make a milkshake.
>>>>>>>
>>>>>>>> Now it seems like you are trying to claim that a representation of
>>>>>>>> a computation specifies a sequence of configurations, but that
>>>>>>>> doesn't explain why you so vehemently objected
>>>>>>>
>>>>>>> Your brain is welded in rebuttal mode?
>>>>>>>
>>>>>>>> to the claim that the input to a halt decider represents a
>>>>>>>> computation. So clearly you mean something else altogether.
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>
>>>>>>> Because your brain is welded in rebuttal mode you will always act
>>>>>>> like you never know.
>>>>>>>
>>>>>>
>>>>>> No, YOUR brain is welded in stupid mode. You are unable to make a
>>>>>> clear sentence because you misuse the English language to hide your
>>>>>> lies.
>>>>>
>>>>> It is easily provable that the C function H(P,P)==0 is correct on the
>>>>> basis of the fact correct execution trace of the x86 source-code of
>>>>> input to H(P,P) shows that P would never reach its "ret" instruction.
>>>>
>>>> Again, I say HOW, since the CORRECT emulation of the input to
>>>> H(P,P), as
>>>> shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H is
>>>> defined to return 0 from H(P,P).
>>> Richard is one of the two liars.
>>> *The actual behavior of P when correctly emulated by H is shown below*
>>>
>>> #include <stdint.h>
>>> #define u32 uint32_t
>>>
>>> void P(u32 x)
>>> {
>>> if (H(x, x))
>>> HERE: goto HERE;
>>> return;
>>> }
>>>
>>> int main()
>>> {
>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>> }
>>>
>>> _P()
>>> [00001352](01) 55 push ebp
>>> [00001353](02) 8bec mov ebp,esp
>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>> [00001358](01) 50 push eax // push P
>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>> [0000135c](01) 51 push ecx // push P
>>> [0000135d](05) e840feffff call 000011a2 // call H
>>> [00001362](03) 83c408 add esp,+08
>>> [00001365](02) 85c0 test eax,eax
>>> [00001367](02) 7402 jz 0000136b
>>> [00001369](02) ebfe jmp 00001369
>>> [0000136b](01) 5d pop ebp
>>> [0000136c](01) c3 ret
>>> Size in bytes:(0027) [0000136c]
>>>
>>> _main()
>>> [00001372](01) 55 push ebp
>>> [00001373](02) 8bec mov ebp,esp
>>> [00001375](05) 6852130000 push 00001352 // push P
>>> [0000137a](05) 6852130000 push 00001352 // push P
>>> [0000137f](05) e81efeffff call 000011a2 // call H
>>> [00001384](03) 83c408 add esp,+08
>>> [00001387](01) 50 push eax
>>> [00001388](05) 6823040000 push 00000423 // "Input_Halts = "
>>> [0000138d](05) e8e0f0ffff call 00000472 // call Output
>>> [00001392](03) 83c408 add esp,+08
>>> [00001395](02) 33c0 xor eax,eax
>>> [00001397](01) 5d pop ebp
>>> [00001398](01) c3 ret
>>> Size in bytes:(0039) [00001398]
>>>
>>> machine stack stack machine assembly
>>> address address data code language
>>> ======== ======== ======== ========= =============
>>> ...[00001372][0010229e][00000000] 55 push ebp
>>> ...[00001373][0010229e][00000000] 8bec mov ebp,esp
>>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>>>
>>> Begin Local Halt Decider Simulation Execution Trace Stored at:212352
>>>
>>> // H emulates the first seven instructions of P
>>> ...[00001352][0021233e][00212342] 55 push ebp // enter P
>>> ...[00001353][0021233e][00212342] 8bec mov ebp,esp
>>> ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
>>> ...[00001358][0021233a][00001352] 50 push eax // push P
>>> ...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
>>> ...[0000135c][00212336][00001352] 51 push ecx // push P
>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>>
>> Starting here is where the trace is incomplete.  The emulation of the
>> instructions of the inner instance of H are not shown.  Also the lines
>> below are not emulated by the top level H.  They are emulated by the
>> inner H called by P.  So in between each of these lines is multiple
>> instructions of the inner H performing the emulation of them.
>>
>>>
>>> // The emulated H emulates the first seven instructions of P
>>> ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
>>> ...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
>>> ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
>>> ...[00001358][0025cd62][00001352] 50 push eax // push P
>>> ...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
>>> ...[0000135c][0025cd5e][00001352] 51 push ecx // push P
>>> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>
>> Here is where H makes its error of aborting too soon.  Explanation below:
>>
>
> Several different confusions (see below).
>
>>>
>>> If the execution trace of function H() called by function P() shows:
>>> (1) Function H() is called twice in sequence from the same machine
>>> address of P().
>>> (2) With the same parameters to H().
>>> (3) With no conditional branch or indexed jump instructions in P().
>>
>> This condition is not met.
>
> (1) is proven
> (2) is proven // Third column shows TOS value of P's machine address
> (3) is proven //

On 5/28/2022 11:06 AM, Dennis Bush wrote:
> On Saturday, May 28, 2022 at 11:48:43 AM UTC-4, olcott wrote:
>> On 5/28/2022 10:23 AM, Dennis Bush wrote:
>>> On Saturday, May 28, 2022 at 11:06:06 AM UTC-4, olcott wrote:
>>>> On 5/28/2022 8:58 AM, Richard Damon wrote:
>>>>>
>>>>> On 5/28/22 6:26 AM, olcott wrote:
>>>>>> On 5/27/2022 7:33 PM, Richard Damon wrote:
>>>>>>> On 5/27/22 7:33 PM, olcott wrote:
>>>>>>>> On 5/27/2022 6:26 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-05-27 16:42, olcott wrote:
>>>>>>>>>> On 5/27/2022 5:26 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2022-05-27 16:13, olcott wrote:
>>>>>>>>>>>> On 5/27/2022 4:41 PM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2022-05-27 15:31, olcott wrote:
>>>>>>>>>>>>>> On 5/27/2022 4:21 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>>>>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios",
>>>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The finite string inputs to a halt decider specify
>>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of
>>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own final
>>>>>>>>>>>>>>>>>>>> state.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations'
>>>>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are not.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The distinction that I make between represent and specify
>>>>>>>>>>>>>>>>>> is that the x86 source-code for P represents P(P) whereas
>>>>>>>>>>>>>>>>>> the actual correct x86 emulation of the input to H(P,P)
>>>>>>>>>>>>>>>>>> specifies the actual behavior of this input. This is not
>>>>>>>>>>>>>>>>>> the same behavior as the behavior specified by P(P).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> A sequence of configurations means a list of x86 program
>>>>>>>>>>>>>>>>>> steps executed or emulated in the order that their
>>>>>>>>>>>>>>>>>> source-code specifies.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM
>>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> And this decidedly is *not* what a halt decider is given as
>>>>>>>>>>>>>>>>> its input. It is not given a sequence of state transitions.
>>>>>>>>>>>>>>>>> It is given a representation of a computation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No it is not and you know that it is not. A halt decider is
>>>>>>>>>>>>>>>> given a finite string TM description that specifies a
>>>>>>>>>>>>>>>> sequence of configurations.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A TM description and a sequence of configurations are
>>>>>>>>>>>>>>> entirely different things (and the former certainly does not
>>>>>>>>>>>>>>> 'specify' the latter). It's given either one or the other.
>>>>>>>>>>>>>>> Make up your mind.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>> [000012c2](01) 55 push ebp
>>>>>>>>>>>>>> [000012c3](02) 8bec mov ebp,esp
>>>>>>>>>>>>>> [000012c5](02) ebfe jmp 000012c5
>>>>>>>>>>>>>> [000012c7](01) 5d pop ebp
>>>>>>>>>>>>>> [000012c8](01) c3 ret
>>>>>>>>>>>>>> Size in bytes:(0007) [000012c8]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So then the above x86 code may specify a game of tic-tac-toe
>>>>>>>>>>>>>> and there is no possible way to determine that it does not
>>>>>>>>>>>>>> because the x86 source code of a function has nothing to do
>>>>>>>>>>>>>> with the sequence of steps of its correct simulation.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> That is not a sequence of configurations. It is a piece of
>>>>>>>>>>>>> assembly code which represents a subroutine which is an
>>>>>>>>>>>>> infinite loop. The sequence of configurations would look
>>>>>>>>>>>>> something like this:
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Yes that code specifies this sequence.
>>>>>>>>>>>
>>>>>>>>>>> No, it does not. What you have above only generates the following
>>>>>>>>>>> *only* if you (a) interpret it as representing x86 instructions
>>>>>>>>>>> and (b) actually execute it on an x86 or some appropriate emulator.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Because no one in their right mind would think of doing it
>>>>>>>>>> otherwise those ridiculously self-evident facts need not be stated.
>>>>>>>>>
>>>>>>>>> You are the one who constantly makes much ado about nothing about
>>>>>>>>> the fact that Turing Machines can ONLY accept finite strings as
>>>>>>>>> their inputs and object to anyone who suggests that something might
>>>>>>>>> compute some function which isn't over strings.
>>>>>>>>>
>>>>>>>>> You don't seem to understand exactly what a finite string is. A
>>>>>>>>> finite string is simply a sequence of symbols. Given two strings,
>>>>>>>>> you can ask questions like which is longer or whether one is a
>>>>>>>>> substring or permutation of the other, but not much else.
>>>>>>>>>
>>>>>>>>> That's because neither strings nor the symbols they are composed of
>>>>>>>>> have any meaning whatsoever. They are just sequences of
>>>>>>>>> uninterpreted tokens. As soon as you start talking about 'sequences
>>>>>>>>> of configurations' or 'numerical values' or anything along those
>>>>>>>>> lines you are no longer talking about finite strings, but about the
>>>>>>>>> entities which those strings represent to a particular TM/program.
>>>>>>>>>
>>>>>>>>> Part of designing a TM involves specifying exactly how a string is
>>>>>>>>> to be interpreted (however 'ridiculously self-evident' it might
>>>>>>>>> seem to you) So yes, they need to be stated.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> If it was not for communication context then every single rule of
>>>>>>>>>> grammar would have to be repeated with every sentence and every
>>>>>>>>>> definition of every work would have to be repeated over and over.
>>>>>>>>>>
>>>>>>>>>>> You keep claiming that the input to the decider is a sequence of
>>>>>>>>>>> configurations, but that's just plain wrong.
>>>>>>>>>>
>>>>>>>>>> The input to a decider
>>>>>>>>>>
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> A sequence of configirations
>>>>>>>>>>
>>>>>>>>>> Did you notice that I said SPECFIES this time ???
>>>>>>>>>
>>>>>>>>> But you still haven't provided a coherent definition of what *you*
>>>>>>>>> mean by 'specify'. You gave a bit of wishy-washy verbiage a few
>>>>>>>>> posts ago, but nothing which made this clear. Repeating it over and
>>>>>>>>> over again doesn't add any clarity.
>>>>>>>>
>>>>>>>>> The question originally arose when you objected to the claim that
>>>>>>>>> the input to a halt decider represents a computation (or TM
>>>>>>>>> description/input string pair) and instead insisted that it
>>>>>>>>> specifies a sequence of configurations.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes of course as everyone knows x86 source-code is one of the
>>>>>>>> ingredients to a milkshake and because there is a standard practice
>>>>>>>> for making milkshakes they already know when and how the x86
>>>>>>>> source-code must be applied to make a milkshake.
>>>>>>>>
>>>>>>>>> Now it seems like you are trying to claim that a representation of
>>>>>>>>> a computation specifies a sequence of configurations, but that
>>>>>>>>> doesn't explain why you so vehemently objected
>>>>>>>>
>>>>>>>> Your brain is welded in rebuttal mode?
>>>>>>>>
>>>>>>>>> to the claim that the input to a halt decider represents a
>>>>>>>>> computation. So clearly you mean something else altogether.
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>>
>>>>>>>>
>>>>>>>> Because your brain is welded in rebuttal mode you will always act
>>>>>>>> like you never know.
>>>>>>>>
>>>>>>>
>>>>>>> No, YOUR brain is welded in stupid mode. You are unable to make a
>>>>>>> clear sentence because you misuse the English language to hide your
>>>>>>> lies.
>>>>>>
>>>>>> It is easily provable that the C function H(P,P)==0 is correct on the
>>>>>> basis of the fact correct execution trace of the x86 source-code of
>>>>>> input to H(P,P) shows that P would never reach its "ret" instruction.
>>>>>
>>>>> Again, I say HOW, since the CORRECT emulation of the input to H(P,P), as
>>>>> shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H is
>>>>> defined to return 0 from H(P,P).
>>>> Richard is one of the two liars.
>>>> *The actual behavior of P when correctly emulated by H is shown below*
>>>>
>>>> #include <stdint.h>
>>>> #define u32 uint32_t
>>>>
>>>> void P(u32 x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>> }
>>>>
>>>> _P()
>>>> [00001352](01) 55 push ebp
>>>> [00001353](02) 8bec mov ebp,esp
>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>> [00001358](01) 50 push eax // push P
>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>> [0000135c](01) 51 push ecx // push P
>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>> [00001362](03) 83c408 add esp,+08
>>>> [00001365](02) 85c0 test eax,eax
>>>> [00001367](02) 7402 jz 0000136b
>>>> [00001369](02) ebfe jmp 00001369
>>>> [0000136b](01) 5d pop ebp
>>>> [0000136c](01) c3 ret
>>>> Size in bytes:(0027) [0000136c]
>>>>
>>>> _main()
>>>> [00001372](01) 55 push ebp
>>>> [00001373](02) 8bec mov ebp,esp
>>>> [00001375](05) 6852130000 push 00001352 // push P
>>>> [0000137a](05) 6852130000 push 00001352 // push P
>>>> [0000137f](05) e81efeffff call 000011a2 // call H
>>>> [00001384](03) 83c408 add esp,+08
>>>> [00001387](01) 50 push eax
>>>> [00001388](05) 6823040000 push 00000423 // "Input_Halts = "
>>>> [0000138d](05) e8e0f0ffff call 00000472 // call Output
>>>> [00001392](03) 83c408 add esp,+08
>>>> [00001395](02) 33c0 xor eax,eax
>>>> [00001397](01) 5d pop ebp
>>>> [00001398](01) c3 ret
>>>> Size in bytes:(0039) [00001398]
>>>>
>>>> machine stack stack machine assembly
>>>> address address data code language
>>>> ======== ======== ======== ========= =============
>>>> ...[00001372][0010229e][00000000] 55 push ebp
>>>> ...[00001373][0010229e][00000000] 8bec mov ebp,esp
>>>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
>>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
>>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>>>>
>>>> Begin Local Halt Decider Simulation Execution Trace Stored at:212352
>>>>
>>>> // H emulates the first seven instructions of P
>>>> ...[00001352][0021233e][00212342] 55 push ebp // enter P
>>>> ...[00001353][0021233e][00212342] 8bec mov ebp,esp
>>>> ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
>>>> ...[00001358][0021233a][00001352] 50 push eax // push P
>>>> ...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
>>>> ...[0000135c][00212336][00001352] 51 push ecx // push P
>>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>>>
>>> Starting here is where the trace is incomplete. The emulation of the instructions of the inner instance of H are not shown. Also the lines below are not emulated by the top level H. They are emulated by the inner H called by P. So in between each of these lines is multiple instructions of the inner H performing the emulation of them.
>>>
>>>>
>>>> // The emulated H emulates the first seven instructions of P
>>>> ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
>>>> ...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
>>>> ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
>>>> ...[00001358][0025cd62][00001352] 50 push eax // push P
>>>> ...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
>>>> ...[0000135c][0025cd5e][00001352] 51 push ecx // push P
>>>> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>
>>> Here is where H makes its error of aborting too soon. Explanation below:
>>>
>> Several different confusions (see below).
>>>>
>>>> If the execution trace of function H() called by function P() shows:
>>>> (1) Function H() is called twice in sequence from the same machine
>>>> address of P().
>>>> (2) With the same parameters to H().
>>>> (3) With no conditional branch or indexed jump instructions in P().
>>>
>>> This condition is not met.
>> (1) is proven
>> (2) is proven // Third column shows TOS value of P's machine address
>> (3) is proven //
>>> There are branches / jumps in the *program* P contained in the function H that can abort.
>> We are not looking for jumps, we are looking for code that can change
>> the behavior of P from one invocation to the next.
>
> And the conditional code of H that checks if its abort criteria is met does *exactly* that.

On 5/28/2022 11:11 AM, Dennis Bush wrote:
> On Saturday, May 28, 2022 at 12:02:30 PM UTC-4, olcott wrote:
>> On 5/28/2022 10:29 AM, Richard Damon wrote:
>>>
>>> On 5/28/22 11:05 AM, olcott wrote:
>>>> On 5/28/2022 8:58 AM, Richard Damon wrote:
>>>>>
>>>>> On 5/28/22 6:26 AM, olcott wrote:
>>>>>> On 5/27/2022 7:33 PM, Richard Damon wrote:
>>>>>>> On 5/27/22 7:33 PM, olcott wrote:
>>>>>>>> On 5/27/2022 6:26 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-05-27 16:42, olcott wrote:
>>>>>>>>>> On 5/27/2022 5:26 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2022-05-27 16:13, olcott wrote:
>>>>>>>>>>>> On 5/27/2022 4:41 PM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2022-05-27 15:31, olcott wrote:
>>>>>>>>>>>>>> On 5/27/2022 4:21 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>>>>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios",
>>>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The finite string inputs to a halt decider specify
>>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of
>>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own
>>>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations'
>>>>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are
>>>>>>>>>>>>>>>>>>> not.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The distinction that I make between represent and
>>>>>>>>>>>>>>>>>> specify is that the x86 source-code for P represents
>>>>>>>>>>>>>>>>>> P(P) whereas the actual correct x86 emulation of the
>>>>>>>>>>>>>>>>>> input to H(P,P) specifies the actual behavior of this
>>>>>>>>>>>>>>>>>> input. This is not the same behavior as the behavior
>>>>>>>>>>>>>>>>>> specified by P(P).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> A sequence of configurations means a list of x86 program
>>>>>>>>>>>>>>>>>> steps executed or emulated in the order that their
>>>>>>>>>>>>>>>>>> source-code specifies.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM
>>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> And this decidedly is *not* what a halt decider is given
>>>>>>>>>>>>>>>>> as its input. It is not given a sequence of state
>>>>>>>>>>>>>>>>> transitions. It is given a representation of a computation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No it is not and you know that it is not. A halt decider
>>>>>>>>>>>>>>>> is given a finite string TM description that specifies a
>>>>>>>>>>>>>>>> sequence of configurations.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A TM description and a sequence of configurations are
>>>>>>>>>>>>>>> entirely different things (and the former certainly does
>>>>>>>>>>>>>>> not 'specify' the latter). It's given either one or the
>>>>>>>>>>>>>>> other. Make up your mind.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>> [000012c2](01) 55 push ebp
>>>>>>>>>>>>>> [000012c3](02) 8bec mov ebp,esp
>>>>>>>>>>>>>> [000012c5](02) ebfe jmp 000012c5
>>>>>>>>>>>>>> [000012c7](01) 5d pop ebp
>>>>>>>>>>>>>> [000012c8](01) c3 ret
>>>>>>>>>>>>>> Size in bytes:(0007) [000012c8]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So then the above x86 code may specify a game of tic-tac-toe
>>>>>>>>>>>>>> and there is no possible way to determine that it does not
>>>>>>>>>>>>>> because the x86 source code of a function has nothing to do
>>>>>>>>>>>>>> with the sequence of steps of its correct simulation.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> That is not a sequence of configurations. It is a piece of
>>>>>>>>>>>>> assembly code which represents a subroutine which is an
>>>>>>>>>>>>> infinite loop. The sequence of configurations would look
>>>>>>>>>>>>> something like this:
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Yes that code specifies this sequence.
>>>>>>>>>>>
>>>>>>>>>>> No, it does not. What you have above only generates the
>>>>>>>>>>> following *only* if you (a) interpret it as representing x86
>>>>>>>>>>> instructions and (b) actually execute it on an x86 or some
>>>>>>>>>>> appropriate emulator.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Because no one in their right mind would think of doing it
>>>>>>>>>> otherwise those ridiculously self-evident facts need not be stated.
>>>>>>>>>
>>>>>>>>> You are the one who constantly makes much ado about nothing about
>>>>>>>>> the fact that Turing Machines can ONLY accept finite strings as
>>>>>>>>> their inputs and object to anyone who suggests that something
>>>>>>>>> might compute some function which isn't over strings.
>>>>>>>>>
>>>>>>>>> You don't seem to understand exactly what a finite string is. A
>>>>>>>>> finite string is simply a sequence of symbols. Given two strings,
>>>>>>>>> you can ask questions like which is longer or whether one is a
>>>>>>>>> substring or permutation of the other, but not much else.
>>>>>>>>>
>>>>>>>>> That's because neither strings nor the symbols they are composed
>>>>>>>>> of have any meaning whatsoever. They are just sequences of
>>>>>>>>> uninterpreted tokens. As soon as you start talking about
>>>>>>>>> 'sequences of configurations' or 'numerical values' or anything
>>>>>>>>> along those lines you are no longer talking about finite strings,
>>>>>>>>> but about the entities which those strings represent to a
>>>>>>>>> particular TM/program.
>>>>>>>>>
>>>>>>>>> Part of designing a TM involves specifying exactly how a string
>>>>>>>>> is to be interpreted (however 'ridiculously self-evident' it
>>>>>>>>> might seem to you) So yes, they need to be stated.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> If it was not for communication context then every single rule
>>>>>>>>>> of grammar would have to be repeated with every sentence and
>>>>>>>>>> every definition of every work would have to be repeated over
>>>>>>>>>> and over.
>>>>>>>>>>
>>>>>>>>>>> You keep claiming that the input to the decider is a sequence
>>>>>>>>>>> of configurations, but that's just plain wrong.
>>>>>>>>>>
>>>>>>>>>> The input to a decider
>>>>>>>>>>
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> A sequence of configirations
>>>>>>>>>>
>>>>>>>>>> Did you notice that I said SPECFIES this time ???
>>>>>>>>>
>>>>>>>>> But you still haven't provided a coherent definition of what
>>>>>>>>> *you* mean by 'specify'. You gave a bit of wishy-washy verbiage a
>>>>>>>>> few posts ago, but nothing which made this clear. Repeating it
>>>>>>>>> over and over again doesn't add any clarity.
>>>>>>>>
>>>>>>>>> The question originally arose when you objected to the claim that
>>>>>>>>> the input to a halt decider represents a computation (or TM
>>>>>>>>> description/input string pair) and instead insisted that it
>>>>>>>>> specifies a sequence of configurations.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes of course as everyone knows x86 source-code is one of the
>>>>>>>> ingredients to a milkshake and because there is a standard
>>>>>>>> practice for making milkshakes they already know when and how the
>>>>>>>> x86 source-code must be applied to make a milkshake.
>>>>>>>>
>>>>>>>>> Now it seems like you are trying to claim that a representation
>>>>>>>>> of a computation specifies a sequence of configurations, but that
>>>>>>>>> doesn't explain why you so vehemently objected
>>>>>>>>
>>>>>>>> Your brain is welded in rebuttal mode?
>>>>>>>>
>>>>>>>>> to the claim that the input to a halt decider represents a
>>>>>>>>> computation. So clearly you mean something else altogether.
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>>
>>>>>>>>
>>>>>>>> Because your brain is welded in rebuttal mode you will always act
>>>>>>>> like you never know.
>>>>>>>>
>>>>>>>
>>>>>>> No, YOUR brain is welded in stupid mode. You are unable to make a
>>>>>>> clear sentence because you misuse the English language to hide your
>>>>>>> lies.
>>>>>>
>>>>>> It is easily provable that the C function H(P,P)==0 is correct on
>>>>>> the basis of the fact correct execution trace of the x86 source-code
>>>>>> of input to H(P,P) shows that P would never reach its "ret"
>>>>>> instruction.
>>>>>
>>>>> Again, I say HOW, since the CORRECT emulation of the input to H(P,P),
>>>>> as shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H
>>>>> is defined to return 0 from H(P,P).
>>>>
>>>> Richard is one of the two liars.
>>>> *The actual behavior of P when correctly emulated by H is shown below*
>>>
>>>
>>> No, it isn't, because it LIES.
>>>>
>>>> #include <stdint.h>
>>>> #define u32 uint32_t
>>>>
>>>> void P(u32 x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>> }
>>>>
>>>> _P()
>>>> [00001352](01) 55 push ebp
>>>> [00001353](02) 8bec mov ebp,esp
>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>> [00001358](01) 50 push eax // push P
>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>> [0000135c](01) 51 push ecx // push P
>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>> [00001362](03) 83c408 add esp,+08
>>>> [00001365](02) 85c0 test eax,eax
>>>> [00001367](02) 7402 jz 0000136b
>>>> [00001369](02) ebfe jmp 00001369
>>>> [0000136b](01) 5d pop ebp
>>>> [0000136c](01) c3 ret
>>>> Size in bytes:(0027) [0000136c]
>>>>
>>>> _main()
>>>> [00001372](01) 55 push ebp
>>>> [00001373](02) 8bec mov ebp,esp
>>>> [00001375](05) 6852130000 push 00001352 // push P
>>>> [0000137a](05) 6852130000 push 00001352 // push P
>>>> [0000137f](05) e81efeffff call 000011a2 // call H
>>>> [00001384](03) 83c408 add esp,+08
>>>> [00001387](01) 50 push eax
>>>> [00001388](05) 6823040000 push 00000423 // "Input_Halts = "
>>>> [0000138d](05) e8e0f0ffff call 00000472 // call Output
>>>> [00001392](03) 83c408 add esp,+08
>>>> [00001395](02) 33c0 xor eax,eax
>>>> [00001397](01) 5d pop ebp
>>>> [00001398](01) c3 ret
>>>> Size in bytes:(0039) [00001398]
>>>>
>>>> machine stack stack machine assembly
>>>> address address data code language
>>>> ======== ======== ======== ========= =============
>>>> ...[00001372][0010229e][00000000] 55 push ebp
>>>> ...[00001373][0010229e][00000000] 8bec mov ebp,esp
>>>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
>>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
>>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>>>>
>>>> Begin Local Halt Decider Simulation Execution Trace Stored at:212352
>>>>
>>>> // H emulates the first seven instructions of P
>>>> ...[00001352][0021233e][00212342] 55 push ebp // enter P
>>>> ...[00001353][0021233e][00212342] 8bec mov ebp,esp
>>>> ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
>>>> ...[00001358][0021233a][00001352] 50 push eax // push P
>>>> ...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
>>>> ...[0000135c][00212336][00001352] 51 push ecx // push P
>>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>>>>
>>>> // The emulated H emulates the first seven instructions of P
>>> So, the following is NOT an emulation of the P that the top level H is
>>> emulating, and
>> Right.
>>> thus NOT part of a CORRECT x86 emulation of the program.
>> Wrong.
>>
>> Just like the first invocation of infinite recursion is the root cause
>> of the infinite recursion the first invocation of infinitely nested x86
>> emulation is its root cause.
>>
>>
>> You are basically saying that when a C function H emulates another C
>> function P and this second C function in
>>
>> I spent a year of development of the x86utm operating system so that
>> when H(P,P) is invoked and its emulated P calls H(P,P) the outer H could
>> correctly emulate P and P calling H(P,P) and this inner P calling H(P,P)
>> to an arbitrary recursive depth.
>>
>> I don't show the 236 pages of the emulation of H because we can simply
>> hypothesize that it merely emulates its input
>
> Deceptive use of "H" to refer to multiple unrelated computations.
>
> The fixed algorithm of H, hereafter referred to as Ha, and the P that calls it referred to as Pa, does abort and does not "merely emulate". Hn is what does that. And since Pa doesn't call Hn that means we are no longer deciding on Pa but on Pn.
>
> So your argument boils down to: Ha(Pa,Pa)==0 is correct because Pn(Pn) does not halt.
>

On 5/28/22 12:02 PM, olcott wrote:
> On 5/28/2022 10:29 AM, Richard Damon wrote:
>>
>> On 5/28/22 11:05 AM, olcott wrote:
>>> On 5/28/2022 8:58 AM, Richard Damon wrote:
>>>>
>>>> On 5/28/22 6:26 AM, olcott wrote:
>>>>> On 5/27/2022 7:33 PM, Richard Damon wrote:
>>>>>> On 5/27/22 7:33 PM, olcott wrote:
>>>>>>> On 5/27/2022 6:26 PM, André G. Isaak wrote:
>>>>>>>> On 2022-05-27 16:42, olcott wrote:
>>>>>>>>> On 5/27/2022 5:26 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-05-27 16:13, olcott wrote:
>>>>>>>>>>> On 5/27/2022 4:41 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2022-05-27 15:31, olcott wrote:
>>>>>>>>>>>>> On 5/27/2022 4:21 PM, André G. Isaak wrote:
>>>>>>>>>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>>>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios",
>>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The finite string inputs to a halt decider specify
>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of
>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own
>>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of
>>>>>>>>>>>>>>>>>> configurations' mean. Richard is perfectly correct.
>>>>>>>>>>>>>>>>>> You, as usual, are not.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The distinction that I make between represent and
>>>>>>>>>>>>>>>>> specify is that the x86 source-code for P represents
>>>>>>>>>>>>>>>>> P(P) whereas the actual correct x86 emulation of the
>>>>>>>>>>>>>>>>> input to H(P,P) specifies the actual behavior of this
>>>>>>>>>>>>>>>>> input. This is not the same behavior as the behavior
>>>>>>>>>>>>>>>>> specified by P(P).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A sequence of configurations means a list of x86
>>>>>>>>>>>>>>>>> program steps executed or emulated in the order that
>>>>>>>>>>>>>>>>> their source-code specifies.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM
>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And this decidedly is *not* what a halt decider is given
>>>>>>>>>>>>>>>> as its input. It is not given a sequence of state
>>>>>>>>>>>>>>>> transitions. It is given a representation of a computation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No it is not and you know that it is not. A halt decider
>>>>>>>>>>>>>>> is given a finite string TM description that specifies a
>>>>>>>>>>>>>>> sequence of configurations.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A TM description and a sequence of configurations are
>>>>>>>>>>>>>> entirely different things (and the former certainly does
>>>>>>>>>>>>>> not 'specify' the latter). It's given either one or the
>>>>>>>>>>>>>> other. Make up your mind.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>> [000012c2](01)  55              push ebp
>>>>>>>>>>>>> [000012c3](02)  8bec            mov ebp,esp
>>>>>>>>>>>>> [000012c5](02)  ebfe            jmp 000012c5
>>>>>>>>>>>>> [000012c7](01)  5d              pop ebp
>>>>>>>>>>>>> [000012c8](01)  c3              ret
>>>>>>>>>>>>> Size in bytes:(0007) [000012c8]
>>>>>>>>>>>>>
>>>>>>>>>>>>> So then the above x86 code may specify a game of
>>>>>>>>>>>>> tic-tac-toe and there is no possible way to determine that
>>>>>>>>>>>>> it does not because the x86 source code of a function has
>>>>>>>>>>>>> nothing to do with the sequence of steps of its correct
>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> That is not a sequence of configurations. It is a piece of
>>>>>>>>>>>> assembly code which represents a subroutine which is an
>>>>>>>>>>>> infinite loop. The sequence of configurations would look
>>>>>>>>>>>> something like this:
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Yes that code specifies this sequence.
>>>>>>>>>>
>>>>>>>>>> No, it does not. What you have above only generates the
>>>>>>>>>> following *only* if you (a) interpret it as representing x86
>>>>>>>>>> instructions and (b) actually execute it on an x86 or some
>>>>>>>>>> appropriate emulator.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Because no one in their right mind would think of doing it
>>>>>>>>> otherwise those ridiculously self-evident facts need not be
>>>>>>>>> stated.
>>>>>>>>
>>>>>>>> You are the one who constantly makes much ado about nothing
>>>>>>>> about the fact that Turing Machines can ONLY accept finite
>>>>>>>> strings as their inputs and object to anyone who suggests that
>>>>>>>> something might compute some function which isn't over strings.
>>>>>>>>
>>>>>>>> You don't seem to understand exactly what a finite string is. A
>>>>>>>> finite string is simply a sequence of symbols. Given two
>>>>>>>> strings, you can ask questions like which is longer or whether
>>>>>>>> one is a substring or permutation of the other, but not much else.
>>>>>>>>
>>>>>>>> That's because neither strings nor the symbols they are composed
>>>>>>>> of have any meaning whatsoever. They are just sequences of
>>>>>>>> uninterpreted tokens. As soon as you start talking about
>>>>>>>> 'sequences of configurations' or 'numerical values' or anything
>>>>>>>> along those lines you are no longer talking about finite
>>>>>>>> strings, but about the entities which those strings represent to
>>>>>>>> a particular TM/program.
>>>>>>>>
>>>>>>>> Part of designing a TM involves specifying exactly how a string
>>>>>>>> is to be interpreted (however 'ridiculously self-evident' it
>>>>>>>> might seem to you) So yes, they need to be stated.
>>>>>>>>
>>>>>>>>
>>>>>>>>> If it was not for communication context then every single rule
>>>>>>>>> of grammar would have to be repeated with every sentence and
>>>>>>>>> every definition of every work would have to be repeated over
>>>>>>>>> and over.
>>>>>>>>>
>>>>>>>>>> You keep claiming that the input to the decider is a sequence
>>>>>>>>>> of configurations, but that's just plain wrong.
>>>>>>>>>
>>>>>>>>> The input to a decider
>>>>>>>>>
>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>> A sequence of configirations
>>>>>>>>>
>>>>>>>>> Did you notice that I said SPECFIES this time ???
>>>>>>>>
>>>>>>>> But you still haven't provided a coherent definition of what
>>>>>>>> *you* mean by 'specify'. You gave a bit of wishy-washy verbiage
>>>>>>>> a few posts ago, but nothing which made this clear. Repeating it
>>>>>>>> over and over again doesn't add any clarity.
>>>>>>>
>>>>>>>> The question originally arose when you objected to the claim
>>>>>>>> that the input to a halt decider represents a computation (or TM
>>>>>>>> description/input string pair) and instead insisted that it
>>>>>>>> specifies a sequence of configurations.
>>>>>>>>
>>>>>>>
>>>>>>> Yes of course as everyone knows x86 source-code is one of the
>>>>>>> ingredients to a milkshake and because there is a standard
>>>>>>> practice for making milkshakes they already know when and how the
>>>>>>> x86 source-code must be applied to make a milkshake.
>>>>>>>
>>>>>>>> Now it seems like you are trying to claim that a representation
>>>>>>>> of a computation specifies a sequence of configurations, but
>>>>>>>> that doesn't explain why you so vehemently objected
>>>>>>>
>>>>>>> Your brain is welded in rebuttal mode?
>>>>>>>
>>>>>>>> to the claim that the input to a halt decider represents a
>>>>>>>> computation. So clearly you mean something else altogether.
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>
>>>>>>> Because your brain is welded in rebuttal mode you will always act
>>>>>>> like you never know.
>>>>>>>
>>>>>>
>>>>>> No, YOUR brain is welded in stupid mode. You are unable to make a
>>>>>> clear sentence because you misuse the English language to hide
>>>>>> your lies.
>>>>>
>>>>> It is easily provable that the C function H(P,P)==0 is correct on
>>>>> the basis of the fact correct execution trace of the x86
>>>>> source-code of input to H(P,P) shows that P would never reach its
>>>>> "ret" instruction.
>>>>
>>>> Again, I say HOW, since the CORRECT emulation of the input to
>>>> H(P,P), as shown by UTM(P,P), H1(P,P), or even P(P) shows that it
>>>> Halts, if H is defined to return 0 from H(P,P).
>>>
>>> Richard is one of the two liars.
>>> *The actual behavior of P when correctly emulated by H is shown below*
>>
>>
>> No, it isn't, because it LIES.
>>>
>>> #include <stdint.h>
>>> #define u32 uint32_t
>>>
>>> void P(u32 x)
>>> {
>>>    if (H(x, x))
>>>      HERE: goto HERE;
>>>    return;
>>> }
>>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>>> }
>>>
>>> _P()
>>> [00001352](01)  55              push ebp
>>> [00001353](02)  8bec            mov ebp,esp
>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>> [00001358](01)  50              push eax      // push P
>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>> [0000135c](01)  51              push ecx      // push P
>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>> [00001362](03)  83c408          add esp,+08
>>> [00001365](02)  85c0            test eax,eax
>>> [00001367](02)  7402            jz 0000136b
>>> [00001369](02)  ebfe            jmp 00001369
>>> [0000136b](01)  5d              pop ebp
>>> [0000136c](01)  c3              ret
>>> Size in bytes:(0027) [0000136c]
>>>
>>> _main()
>>> [00001372](01)  55              push ebp
>>> [00001373](02)  8bec            mov ebp,esp
>>> [00001375](05)  6852130000      push 00001352 // push P
>>> [0000137a](05)  6852130000      push 00001352 // push P
>>> [0000137f](05)  e81efeffff      call 000011a2 // call H
>>> [00001384](03)  83c408          add esp,+08
>>> [00001387](01)  50              push eax
>>> [00001388](05)  6823040000      push 00000423 // "Input_Halts = "
>>> [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
>>> [00001392](03)  83c408          add esp,+08
>>> [00001395](02)  33c0            xor eax,eax
>>> [00001397](01)  5d              pop ebp
>>> [00001398](01)  c3              ret
>>> Size in bytes:(0039) [00001398]
>>>
>>>      machine   stack     stack     machine    assembly
>>>      address   address   data      code       language
>>>      ========  ========  ========  =========  =============
>>> ...[00001372][0010229e][00000000] 55         push ebp
>>> ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
>>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>>>
>>> Begin Local Halt Decider Simulation   Execution Trace Stored at:212352
>>>
>>> // H emulates the first seven instructions of P
>>> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
>>> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
>>> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
>>> ...[00001358][0021233a][00001352] 50         push eax      // push P
>>> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
>>> ...[0000135c][00212336][00001352] 51         push ecx      // push P
>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>>>
>>> // The emulated H emulates the first seven instructions of P
>> So, the following is NOT an emulation of the P that the top level H is
>> emulating, and
>
> Right.
>
>> thus NOT part of a CORRECT x86 emulation of the program.
>
> Wrong.
>
> Just like the first invocation of infinite recursion is the root cause
> of the infinite recursion the first invocation of infinitely nested x86
> emulation is its root cause.
>

On 5/28/22 12:28 PM, olcott wrote:
> On 5/28/2022 11:11 AM, Dennis Bush wrote:
>> On Saturday, May 28, 2022 at 12:02:30 PM UTC-4, olcott wrote:
>>> On 5/28/2022 10:29 AM, Richard Damon wrote:
>>>>
>>>> On 5/28/22 11:05 AM, olcott wrote:
>>>>> On 5/28/2022 8:58 AM, Richard Damon wrote:
>>>>>>
>>>>>> On 5/28/22 6:26 AM, olcott wrote:
>>>>>>> On 5/27/2022 7:33 PM, Richard Damon wrote:
>>>>>>>> On 5/27/22 7:33 PM, olcott wrote:
>>>>>>>>> On 5/27/2022 6:26 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-05-27 16:42, olcott wrote:
>>>>>>>>>>> On 5/27/2022 5:26 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2022-05-27 16:13, olcott wrote:
>>>>>>>>>>>>> On 5/27/2022 4:41 PM, André G. Isaak wrote:
>>>>>>>>>>>>>> On 2022-05-27 15:31, olcott wrote:
>>>>>>>>>>>>>>> On 5/27/2022 4:21 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>>>>>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios",
>>>>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The finite string inputs to a halt decider specify
>>>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of
>>>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own
>>>>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations'
>>>>>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are
>>>>>>>>>>>>>>>>>>>> not.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The distinction that I make between represent and
>>>>>>>>>>>>>>>>>>> specify is that the x86 source-code for P represents
>>>>>>>>>>>>>>>>>>> P(P) whereas the actual correct x86 emulation of the
>>>>>>>>>>>>>>>>>>> input to H(P,P) specifies the actual behavior of this
>>>>>>>>>>>>>>>>>>> input. This is not the same behavior as the behavior
>>>>>>>>>>>>>>>>>>> specified by P(P).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> A sequence of configurations means a list of x86 program
>>>>>>>>>>>>>>>>>>> steps executed or emulated in the order that their
>>>>>>>>>>>>>>>>>>> source-code specifies.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM
>>>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> And this decidedly is *not* what a halt decider is given
>>>>>>>>>>>>>>>>>> as its input. It is not given a sequence of state
>>>>>>>>>>>>>>>>>> transitions. It is given a representation of a
>>>>>>>>>>>>>>>>>> computation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No it is not and you know that it is not. A halt decider
>>>>>>>>>>>>>>>>> is given a finite string TM description that specifies a
>>>>>>>>>>>>>>>>> sequence of configurations.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A TM description and a sequence of configurations are
>>>>>>>>>>>>>>>> entirely different things (and the former certainly does
>>>>>>>>>>>>>>>> not 'specify' the latter). It's given either one or the
>>>>>>>>>>>>>>>> other. Make up your mind.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>> [000012c2](01)  55              push ebp
>>>>>>>>>>>>>>> [000012c3](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>> [000012c5](02)  ebfe            jmp 000012c5
>>>>>>>>>>>>>>> [000012c7](01)  5d              pop ebp
>>>>>>>>>>>>>>> [000012c8](01)  c3              ret
>>>>>>>>>>>>>>> Size in bytes:(0007) [000012c8]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So then the above x86 code may specify a game of tic-tac-toe
>>>>>>>>>>>>>>> and there is no possible way to determine that it does not
>>>>>>>>>>>>>>> because the x86 source code of a function has nothing to do
>>>>>>>>>>>>>>> with the sequence of steps of its correct simulation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That is not a sequence of configurations. It is a piece of
>>>>>>>>>>>>>> assembly code which represents a subroutine which is an
>>>>>>>>>>>>>> infinite loop. The sequence of configurations would look
>>>>>>>>>>>>>> something like this:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes that code specifies this sequence.
>>>>>>>>>>>>
>>>>>>>>>>>> No, it does not. What you have above only generates the
>>>>>>>>>>>> following *only* if you (a) interpret it as representing x86
>>>>>>>>>>>> instructions and (b) actually execute it on an x86 or some
>>>>>>>>>>>> appropriate emulator.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Because no one in their right mind would think of doing it
>>>>>>>>>>> otherwise those ridiculously self-evident facts need not be
>>>>>>>>>>> stated.
>>>>>>>>>>
>>>>>>>>>> You are the one who constantly makes much ado about nothing about
>>>>>>>>>> the fact that Turing Machines can ONLY accept finite strings as
>>>>>>>>>> their inputs and object to anyone who suggests that something
>>>>>>>>>> might compute some function which isn't over strings.
>>>>>>>>>>
>>>>>>>>>> You don't seem to understand exactly what a finite string is. A
>>>>>>>>>> finite string is simply a sequence of symbols. Given two strings,
>>>>>>>>>> you can ask questions like which is longer or whether one is a
>>>>>>>>>> substring or permutation of the other, but not much else.
>>>>>>>>>>
>>>>>>>>>> That's because neither strings nor the symbols they are composed
>>>>>>>>>> of have any meaning whatsoever. They are just sequences of
>>>>>>>>>> uninterpreted tokens. As soon as you start talking about
>>>>>>>>>> 'sequences of configurations' or 'numerical values' or anything
>>>>>>>>>> along those lines you are no longer talking about finite strings,
>>>>>>>>>> but about the entities which those strings represent to a
>>>>>>>>>> particular TM/program.
>>>>>>>>>>
>>>>>>>>>> Part of designing a TM involves specifying exactly how a string
>>>>>>>>>> is to be interpreted (however 'ridiculously self-evident' it
>>>>>>>>>> might seem to you) So yes, they need to be stated.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> If it was not for communication context then every single rule
>>>>>>>>>>> of grammar would have to be repeated with every sentence and
>>>>>>>>>>> every definition of every work would have to be repeated over
>>>>>>>>>>> and over.
>>>>>>>>>>>
>>>>>>>>>>>> You keep claiming that the input to the decider is a sequence
>>>>>>>>>>>> of configurations, but that's just plain wrong.
>>>>>>>>>>>
>>>>>>>>>>> The input to a decider
>>>>>>>>>>>
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> A sequence of configirations
>>>>>>>>>>>
>>>>>>>>>>> Did you notice that I said SPECFIES this time ???
>>>>>>>>>>
>>>>>>>>>> But you still haven't provided a coherent definition of what
>>>>>>>>>> *you* mean by 'specify'. You gave a bit of wishy-washy verbiage a
>>>>>>>>>> few posts ago, but nothing which made this clear. Repeating it
>>>>>>>>>> over and over again doesn't add any clarity.
>>>>>>>>>
>>>>>>>>>> The question originally arose when you objected to the claim that
>>>>>>>>>> the input to a halt decider represents a computation (or TM
>>>>>>>>>> description/input string pair) and instead insisted that it
>>>>>>>>>> specifies a sequence of configurations.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes of course as everyone knows x86 source-code is one of the
>>>>>>>>> ingredients to a milkshake and because there is a standard
>>>>>>>>> practice for making milkshakes they already know when and how the
>>>>>>>>> x86 source-code must be applied to make a milkshake.
>>>>>>>>>
>>>>>>>>>> Now it seems like you are trying to claim that a representation
>>>>>>>>>> of a computation specifies a sequence of configurations, but that
>>>>>>>>>> doesn't explain why you so vehemently objected
>>>>>>>>>
>>>>>>>>> Your brain is welded in rebuttal mode?
>>>>>>>>>
>>>>>>>>>> to the claim that the input to a halt decider represents a
>>>>>>>>>> computation. So clearly you mean something else altogether.
>>>>>>>>>>
>>>>>>>>>> André
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Because your brain is welded in rebuttal mode you will always act
>>>>>>>>> like you never know.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No, YOUR brain is welded in stupid mode. You are unable to make a
>>>>>>>> clear sentence because you misuse the English language to hide your
>>>>>>>> lies.
>>>>>>>
>>>>>>> It is easily provable that the C function H(P,P)==0 is correct on
>>>>>>> the basis of the fact correct execution trace of the x86 source-code
>>>>>>> of input to H(P,P) shows that P would never reach its "ret"
>>>>>>> instruction.
>>>>>>
>>>>>> Again, I say HOW, since the CORRECT emulation of the input to H(P,P),
>>>>>> as shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H
>>>>>> is defined to return 0 from H(P,P).
>>>>>
>>>>> Richard is one of the two liars.
>>>>> *The actual behavior of P when correctly emulated by H is shown below*
>>>>
>>>>
>>>> No, it isn't, because it LIES.
>>>>>
>>>>> #include <stdint.h>
>>>>> #define u32 uint32_t
>>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>>     if (H(x, x))
>>>>>       HERE: goto HERE;
>>>>>     return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>     Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>> }
>>>>>
>>>>> _P()
>>>>> [00001352](01)  55              push ebp
>>>>> [00001353](02)  8bec            mov ebp,esp
>>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>>>> [00001358](01)  50              push eax      // push P
>>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>>>> [0000135c](01)  51              push ecx      // push P
>>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>>>> [00001362](03)  83c408          add esp,+08
>>>>> [00001365](02)  85c0            test eax,eax
>>>>> [00001367](02)  7402            jz 0000136b
>>>>> [00001369](02)  ebfe            jmp 00001369
>>>>> [0000136b](01)  5d              pop ebp
>>>>> [0000136c](01)  c3              ret
>>>>> Size in bytes:(0027) [0000136c]
>>>>>
>>>>> _main()
>>>>> [00001372](01)  55              push ebp
>>>>> [00001373](02)  8bec            mov ebp,esp
>>>>> [00001375](05)  6852130000      push 00001352 // push P
>>>>> [0000137a](05)  6852130000      push 00001352 // push P
>>>>> [0000137f](05)  e81efeffff      call 000011a2 // call H
>>>>> [00001384](03)  83c408          add esp,+08
>>>>> [00001387](01)  50              push eax
>>>>> [00001388](05)  6823040000      push 00000423 // "Input_Halts = "
>>>>> [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
>>>>> [00001392](03)  83c408          add esp,+08
>>>>> [00001395](02)  33c0            xor eax,eax
>>>>> [00001397](01)  5d              pop ebp
>>>>> [00001398](01)  c3              ret
>>>>> Size in bytes:(0039) [00001398]
>>>>>
>>>>>       machine   stack     stack     machine    assembly
>>>>>       address   address   data      code       language
>>>>>       ========  ========  ========  =========  =============
>>>>> ...[00001372][0010229e][00000000] 55         push ebp
>>>>> ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
>>>>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
>>>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
>>>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>>>>>
>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored at:212352
>>>>>
>>>>> // H emulates the first seven instructions of P
>>>>> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
>>>>> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
>>>>> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
>>>>> ...[00001358][0021233a][00001352] 50         push eax      // push P
>>>>> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
>>>>> ...[0000135c][00212336][00001352] 51         push ecx      // push P
>>>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>>>>>
>>>>> // The emulated H emulates the first seven instructions of P
>>>> So, the following is NOT an emulation of the P that the top level H is
>>>> emulating, and
>>> Right.
>>>> thus NOT part of a CORRECT x86 emulation of the program.
>>> Wrong.
>>>
>>> Just like the first invocation of infinite recursion is the root cause
>>> of the infinite recursion the first invocation of infinitely nested x86
>>> emulation is its root cause.
>>>
>>>
>>> You are basically saying that when a C function H emulates another C
>>> function P and this second C function in
>>>
>>> I spent a year of development of the x86utm operating system so that
>>> when H(P,P) is invoked and its emulated P calls H(P,P) the outer H could
>>> correctly emulate P and P calling H(P,P) and this inner P calling H(P,P)
>>> to an arbitrary recursive depth.
>>>
>>> I don't show the 236 pages of the emulation of H because we can simply
>>> hypothesize that it merely emulates its input
>>
>> Deceptive use of "H" to refer to multiple unrelated computations.
>>
>> The fixed algorithm of H, hereafter referred to as Ha, and the P that
>> calls it referred to as Pa, does abort and does not "merely emulate".
>> Hn is what does that.  And since Pa doesn't call Hn that means we are
>> no longer deciding on Pa but on Pn.
>>
>> So your argument boils down to:  Ha(Pa,Pa)==0 is correct because
>> Pn(Pn) does  not halt.
>>
>
> A halt decider must only compute the mapping from its input to an accept
> or reject state based on the actual behavior specified by this input.
>
> It is the case that the correct x86 emulation of the input to H(P,P) by
> H would NEVER reach the "ret" instruction of P therefore H(P,P)==0 is
> proved to be correct.
>

On 5/28/2022 11:35 AM, Richard Damon wrote:
> On 5/28/22 12:02 PM, olcott wrote:
>> On 5/28/2022 10:29 AM, Richard Damon wrote:
>>>
>>> On 5/28/22 11:05 AM, olcott wrote:
>>>> On 5/28/2022 8:58 AM, Richard Damon wrote:
>>>>>
>>>>> On 5/28/22 6:26 AM, olcott wrote:
>>>>>> On 5/27/2022 7:33 PM, Richard Damon wrote:
>>>>>>> On 5/27/22 7:33 PM, olcott wrote:
>>>>>>>> On 5/27/2022 6:26 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-05-27 16:42, olcott wrote:
>>>>>>>>>> On 5/27/2022 5:26 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2022-05-27 16:13, olcott wrote:
>>>>>>>>>>>> On 5/27/2022 4:41 PM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2022-05-27 15:31, olcott wrote:
>>>>>>>>>>>>>> On 5/27/2022 4:21 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>>>>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The input to H is NOT a "sequence of
>>>>>>>>>>>>>>>>>>>>> configuratios", but the representation of an
>>>>>>>>>>>>>>>>>>>>> algorithm and its input.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The finite string inputs to a halt decider specify
>>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of
>>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own
>>>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I really don't think you have any idea what terms
>>>>>>>>>>>>>>>>>>> like 'represent', 'specify', or 'sequence of
>>>>>>>>>>>>>>>>>>> configurations' mean. Richard is perfectly correct.
>>>>>>>>>>>>>>>>>>> You, as usual, are not.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The distinction that I make between represent and
>>>>>>>>>>>>>>>>>> specify is that the x86 source-code for P represents
>>>>>>>>>>>>>>>>>> P(P) whereas the actual correct x86 emulation of the
>>>>>>>>>>>>>>>>>> input to H(P,P) specifies the actual behavior of this
>>>>>>>>>>>>>>>>>> input. This is not the same behavior as the behavior
>>>>>>>>>>>>>>>>>> specified by P(P).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> A sequence of configurations means a list of x86
>>>>>>>>>>>>>>>>>> program steps executed or emulated in the order that
>>>>>>>>>>>>>>>>>> their source-code specifies.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM
>>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> And this decidedly is *not* what a halt decider is
>>>>>>>>>>>>>>>>> given as its input. It is not given a sequence of state
>>>>>>>>>>>>>>>>> transitions. It is given a representation of a
>>>>>>>>>>>>>>>>> computation.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No it is not and you know that it is not. A halt decider
>>>>>>>>>>>>>>>> is given a finite string TM description that specifies a
>>>>>>>>>>>>>>>> sequence of configurations.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A TM description and a sequence of configurations are
>>>>>>>>>>>>>>> entirely different things (and the former certainly does
>>>>>>>>>>>>>>> not 'specify' the latter). It's given either one or the
>>>>>>>>>>>>>>> other. Make up your mind.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>> [000012c2](01)  55              push ebp
>>>>>>>>>>>>>> [000012c3](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>> [000012c5](02)  ebfe            jmp 000012c5
>>>>>>>>>>>>>> [000012c7](01)  5d              pop ebp
>>>>>>>>>>>>>> [000012c8](01)  c3              ret
>>>>>>>>>>>>>> Size in bytes:(0007) [000012c8]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So then the above x86 code may specify a game of
>>>>>>>>>>>>>> tic-tac-toe and there is no possible way to determine that
>>>>>>>>>>>>>> it does not because the x86 source code of a function has
>>>>>>>>>>>>>> nothing to do with the sequence of steps of its correct
>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> That is not a sequence of configurations. It is a piece of
>>>>>>>>>>>>> assembly code which represents a subroutine which is an
>>>>>>>>>>>>> infinite loop. The sequence of configurations would look
>>>>>>>>>>>>> something like this:
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Yes that code specifies this sequence.
>>>>>>>>>>>
>>>>>>>>>>> No, it does not. What you have above only generates the
>>>>>>>>>>> following *only* if you (a) interpret it as representing x86
>>>>>>>>>>> instructions and (b) actually execute it on an x86 or some
>>>>>>>>>>> appropriate emulator.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Because no one in their right mind would think of doing it
>>>>>>>>>> otherwise those ridiculously self-evident facts need not be
>>>>>>>>>> stated.
>>>>>>>>>
>>>>>>>>> You are the one who constantly makes much ado about nothing
>>>>>>>>> about the fact that Turing Machines can ONLY accept finite
>>>>>>>>> strings as their inputs and object to anyone who suggests that
>>>>>>>>> something might compute some function which isn't over strings.
>>>>>>>>>
>>>>>>>>> You don't seem to understand exactly what a finite string is. A
>>>>>>>>> finite string is simply a sequence of symbols. Given two
>>>>>>>>> strings, you can ask questions like which is longer or whether
>>>>>>>>> one is a substring or permutation of the other, but not much else.
>>>>>>>>>
>>>>>>>>> That's because neither strings nor the symbols they are
>>>>>>>>> composed of have any meaning whatsoever. They are just
>>>>>>>>> sequences of uninterpreted tokens. As soon as you start talking
>>>>>>>>> about 'sequences of configurations' or 'numerical values' or
>>>>>>>>> anything along those lines you are no longer talking about
>>>>>>>>> finite strings, but about the entities which those strings
>>>>>>>>> represent to a particular TM/program.
>>>>>>>>>
>>>>>>>>> Part of designing a TM involves specifying exactly how a string
>>>>>>>>> is to be interpreted (however 'ridiculously self-evident' it
>>>>>>>>> might seem to you) So yes, they need to be stated.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> If it was not for communication context then every single rule
>>>>>>>>>> of grammar would have to be repeated with every sentence and
>>>>>>>>>> every definition of every work would have to be repeated over
>>>>>>>>>> and over.
>>>>>>>>>>
>>>>>>>>>>> You keep claiming that the input to the decider is a sequence
>>>>>>>>>>> of configurations, but that's just plain wrong.
>>>>>>>>>>
>>>>>>>>>> The input to a decider
>>>>>>>>>>
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>> A sequence of configirations
>>>>>>>>>>
>>>>>>>>>> Did you notice that I said SPECFIES this time ???
>>>>>>>>>
>>>>>>>>> But you still haven't provided a coherent definition of what
>>>>>>>>> *you* mean by 'specify'. You gave a bit of wishy-washy verbiage
>>>>>>>>> a few posts ago, but nothing which made this clear. Repeating
>>>>>>>>> it over and over again doesn't add any clarity.
>>>>>>>>
>>>>>>>>> The question originally arose when you objected to the claim
>>>>>>>>> that the input to a halt decider represents a computation (or
>>>>>>>>> TM description/input string pair) and instead insisted that it
>>>>>>>>> specifies a sequence of configurations.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes of course as everyone knows x86 source-code is one of the
>>>>>>>> ingredients to a milkshake and because there is a standard
>>>>>>>> practice for making milkshakes they already know when and how
>>>>>>>> the x86 source-code must be applied to make a milkshake.
>>>>>>>>
>>>>>>>>> Now it seems like you are trying to claim that a representation
>>>>>>>>> of a computation specifies a sequence of configurations, but
>>>>>>>>> that doesn't explain why you so vehemently objected
>>>>>>>>
>>>>>>>> Your brain is welded in rebuttal mode?
>>>>>>>>
>>>>>>>>> to the claim that the input to a halt decider represents a
>>>>>>>>> computation. So clearly you mean something else altogether.
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>>
>>>>>>>>
>>>>>>>> Because your brain is welded in rebuttal mode you will always
>>>>>>>> act like you never know.
>>>>>>>>
>>>>>>>
>>>>>>> No, YOUR brain is welded in stupid mode. You are unable to make a
>>>>>>> clear sentence because you misuse the English language to hide
>>>>>>> your lies.
>>>>>>
>>>>>> It is easily provable that the C function H(P,P)==0 is correct on
>>>>>> the basis of the fact correct execution trace of the x86
>>>>>> source-code of input to H(P,P) shows that P would never reach its
>>>>>> "ret" instruction.
>>>>>
>>>>> Again, I say HOW, since the CORRECT emulation of the input to
>>>>> H(P,P), as shown by UTM(P,P), H1(P,P), or even P(P) shows that it
>>>>> Halts, if H is defined to return 0 from H(P,P).
>>>>
>>>> Richard is one of the two liars.
>>>> *The actual behavior of P when correctly emulated by H is shown below*
>>>
>>>
>>> No, it isn't, because it LIES.
>>>>
>>>> #include <stdint.h>
>>>> #define u32 uint32_t
>>>>
>>>> void P(u32 x)
>>>> {
>>>>    if (H(x, x))
>>>>      HERE: goto HERE;
>>>>    return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>>>> }
>>>>
>>>> _P()
>>>> [00001352](01)  55              push ebp
>>>> [00001353](02)  8bec            mov ebp,esp
>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>>> [00001358](01)  50              push eax      // push P
>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>>> [0000135c](01)  51              push ecx      // push P
>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>>> [00001362](03)  83c408          add esp,+08
>>>> [00001365](02)  85c0            test eax,eax
>>>> [00001367](02)  7402            jz 0000136b
>>>> [00001369](02)  ebfe            jmp 00001369
>>>> [0000136b](01)  5d              pop ebp
>>>> [0000136c](01)  c3              ret
>>>> Size in bytes:(0027) [0000136c]
>>>>
>>>> _main()
>>>> [00001372](01)  55              push ebp
>>>> [00001373](02)  8bec            mov ebp,esp
>>>> [00001375](05)  6852130000      push 00001352 // push P
>>>> [0000137a](05)  6852130000      push 00001352 // push P
>>>> [0000137f](05)  e81efeffff      call 000011a2 // call H
>>>> [00001384](03)  83c408          add esp,+08
>>>> [00001387](01)  50              push eax
>>>> [00001388](05)  6823040000      push 00000423 // "Input_Halts = "
>>>> [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
>>>> [00001392](03)  83c408          add esp,+08
>>>> [00001395](02)  33c0            xor eax,eax
>>>> [00001397](01)  5d              pop ebp
>>>> [00001398](01)  c3              ret
>>>> Size in bytes:(0039) [00001398]
>>>>
>>>>      machine   stack     stack     machine    assembly
>>>>      address   address   data      code       language
>>>>      ========  ========  ========  =========  =============
>>>> ...[00001372][0010229e][00000000] 55         push ebp
>>>> ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
>>>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
>>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
>>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>>>>
>>>> Begin Local Halt Decider Simulation   Execution Trace Stored at:212352
>>>>
>>>> // H emulates the first seven instructions of P
>>>> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
>>>> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
>>>> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
>>>> ...[00001358][0021233a][00001352] 50         push eax      // push P
>>>> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
>>>> ...[0000135c][00212336][00001352] 51         push ecx      // push P
>>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>>>>
>>>> // The emulated H emulates the first seven instructions of P
>>> So, the following is NOT an emulation of the P that the top level H
>>> is emulating, and
>>
>> Right.
>>
>>> thus NOT part of a CORRECT x86 emulation of the program.
>>
>> Wrong.
>>
>> Just like the first invocation of infinite recursion is the root cause
>> of the infinite recursion the first invocation of infinitely nested
>> x86 emulation is its root cause.
>>
>
> Except you don't understand the definitions.
>
> The second emulation is NOT an emulation by the emulator we are looking
> at (At least not if H is how you have defined it), so can't be just
> called part of it.
>

On 5/28/22 12:24 PM, olcott wrote:
> On 5/28/2022 11:06 AM, Dennis Bush wrote:
>> On Saturday, May 28, 2022 at 11:48:43 AM UTC-4, olcott wrote:
>>> On 5/28/2022 10:23 AM, Dennis Bush wrote:
>>>> On Saturday, May 28, 2022 at 11:06:06 AM UTC-4, olcott wrote:
>>>>> On 5/28/2022 8:58 AM, Richard Damon wrote:
>>>>>>
>>>>>> On 5/28/22 6:26 AM, olcott wrote:
>>>>>>> On 5/27/2022 7:33 PM, Richard Damon wrote:
>>>>>>>> On 5/27/22 7:33 PM, olcott wrote:
>>>>>>>>> On 5/27/2022 6:26 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-05-27 16:42, olcott wrote:
>>>>>>>>>>> On 5/27/2022 5:26 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2022-05-27 16:13, olcott wrote:
>>>>>>>>>>>>> On 5/27/2022 4:41 PM, André G. Isaak wrote:
>>>>>>>>>>>>>> On 2022-05-27 15:31, olcott wrote:
>>>>>>>>>>>>>>> On 5/27/2022 4:21 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>>>>>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios",
>>>>>>>>>>>>>>>>>>>>>> but the representation of an algorithm and its input.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The finite string inputs to a halt decider specify
>>>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of
>>>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own
>>>>>>>>>>>>>>>>>>>>> final
>>>>>>>>>>>>>>>>>>>>> state.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations'
>>>>>>>>>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual,
>>>>>>>>>>>>>>>>>>>> are not.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The distinction that I make between represent and
>>>>>>>>>>>>>>>>>>> specify
>>>>>>>>>>>>>>>>>>> is that the x86 source-code for P represents P(P)
>>>>>>>>>>>>>>>>>>> whereas
>>>>>>>>>>>>>>>>>>> the actual correct x86 emulation of the input to H(P,P)
>>>>>>>>>>>>>>>>>>> specifies the actual behavior of this input. This is not
>>>>>>>>>>>>>>>>>>> the same behavior as the behavior specified by P(P).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> A sequence of configurations means a list of x86 program
>>>>>>>>>>>>>>>>>>> steps executed or emulated in the order that their
>>>>>>>>>>>>>>>>>>> source-code specifies.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM
>>>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> And this decidedly is *not* what a halt decider is
>>>>>>>>>>>>>>>>>> given as
>>>>>>>>>>>>>>>>>> its input. It is not given a sequence of state
>>>>>>>>>>>>>>>>>> transitions.
>>>>>>>>>>>>>>>>>> It is given a representation of a computation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No it is not and you know that it is not. A halt
>>>>>>>>>>>>>>>>> decider is
>>>>>>>>>>>>>>>>> given a finite string TM description that specifies a
>>>>>>>>>>>>>>>>> sequence of configurations.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A TM description and a sequence of configurations are
>>>>>>>>>>>>>>>> entirely different things (and the former certainly does
>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>> 'specify' the latter). It's given either one or the other.
>>>>>>>>>>>>>>>> Make up your mind.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>> [000012c2](01) 55 push ebp
>>>>>>>>>>>>>>> [000012c3](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>> [000012c5](02) ebfe jmp 000012c5
>>>>>>>>>>>>>>> [000012c7](01) 5d pop ebp
>>>>>>>>>>>>>>> [000012c8](01) c3 ret
>>>>>>>>>>>>>>> Size in bytes:(0007) [000012c8]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So then the above x86 code may specify a game of tic-tac-toe
>>>>>>>>>>>>>>> and there is no possible way to determine that it does not
>>>>>>>>>>>>>>> because the x86 source code of a function has nothing to do
>>>>>>>>>>>>>>> with the sequence of steps of its correct simulation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That is not a sequence of configurations. It is a piece of
>>>>>>>>>>>>>> assembly code which represents a subroutine which is an
>>>>>>>>>>>>>> infinite loop. The sequence of configurations would look
>>>>>>>>>>>>>> something like this:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes that code specifies this sequence.
>>>>>>>>>>>>
>>>>>>>>>>>> No, it does not. What you have above only generates the
>>>>>>>>>>>> following
>>>>>>>>>>>> *only* if you (a) interpret it as representing x86 instructions
>>>>>>>>>>>> and (b) actually execute it on an x86 or some appropriate
>>>>>>>>>>>> emulator.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Because no one in their right mind would think of doing it
>>>>>>>>>>> otherwise those ridiculously self-evident facts need not be
>>>>>>>>>>> stated.
>>>>>>>>>>
>>>>>>>>>> You are the one who constantly makes much ado about nothing about
>>>>>>>>>> the fact that Turing Machines can ONLY accept finite strings as
>>>>>>>>>> their inputs and object to anyone who suggests that something
>>>>>>>>>> might
>>>>>>>>>> compute some function which isn't over strings.
>>>>>>>>>>
>>>>>>>>>> You don't seem to understand exactly what a finite string is. A
>>>>>>>>>> finite string is simply a sequence of symbols. Given two strings,
>>>>>>>>>> you can ask questions like which is longer or whether one is a
>>>>>>>>>> substring or permutation of the other, but not much else.
>>>>>>>>>>
>>>>>>>>>> That's because neither strings nor the symbols they are
>>>>>>>>>> composed of
>>>>>>>>>> have any meaning whatsoever. They are just sequences of
>>>>>>>>>> uninterpreted tokens. As soon as you start talking about
>>>>>>>>>> 'sequences
>>>>>>>>>> of configurations' or 'numerical values' or anything along those
>>>>>>>>>> lines you are no longer talking about finite strings, but
>>>>>>>>>> about the
>>>>>>>>>> entities which those strings represent to a particular
>>>>>>>>>> TM/program.
>>>>>>>>>>
>>>>>>>>>> Part of designing a TM involves specifying exactly how a
>>>>>>>>>> string is
>>>>>>>>>> to be interpreted (however 'ridiculously self-evident' it might
>>>>>>>>>> seem to you) So yes, they need to be stated.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> If it was not for communication context then every single
>>>>>>>>>>> rule of
>>>>>>>>>>> grammar would have to be repeated with every sentence and every
>>>>>>>>>>> definition of every work would have to be repeated over and
>>>>>>>>>>> over.
>>>>>>>>>>>
>>>>>>>>>>>> You keep claiming that the input to the decider is a
>>>>>>>>>>>> sequence of
>>>>>>>>>>>> configurations, but that's just plain wrong.
>>>>>>>>>>>
>>>>>>>>>>> The input to a decider
>>>>>>>>>>>
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> A sequence of configirations
>>>>>>>>>>>
>>>>>>>>>>> Did you notice that I said SPECFIES this time ???
>>>>>>>>>>
>>>>>>>>>> But you still haven't provided a coherent definition of what
>>>>>>>>>> *you*
>>>>>>>>>> mean by 'specify'. You gave a bit of wishy-washy verbiage a few
>>>>>>>>>> posts ago, but nothing which made this clear. Repeating it
>>>>>>>>>> over and
>>>>>>>>>> over again doesn't add any clarity.
>>>>>>>>>
>>>>>>>>>> The question originally arose when you objected to the claim that
>>>>>>>>>> the input to a halt decider represents a computation (or TM
>>>>>>>>>> description/input string pair) and instead insisted that it
>>>>>>>>>> specifies a sequence of configurations.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes of course as everyone knows x86 source-code is one of the
>>>>>>>>> ingredients to a milkshake and because there is a standard
>>>>>>>>> practice
>>>>>>>>> for making milkshakes they already know when and how the x86
>>>>>>>>> source-code must be applied to make a milkshake.
>>>>>>>>>
>>>>>>>>>> Now it seems like you are trying to claim that a
>>>>>>>>>> representation of
>>>>>>>>>> a computation specifies a sequence of configurations, but that
>>>>>>>>>> doesn't explain why you so vehemently objected
>>>>>>>>>
>>>>>>>>> Your brain is welded in rebuttal mode?
>>>>>>>>>
>>>>>>>>>> to the claim that the input to a halt decider represents a
>>>>>>>>>> computation. So clearly you mean something else altogether.
>>>>>>>>>>
>>>>>>>>>> André
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Because your brain is welded in rebuttal mode you will always act
>>>>>>>>> like you never know.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No, YOUR brain is welded in stupid mode. You are unable to make a
>>>>>>>> clear sentence because you misuse the English language to hide your
>>>>>>>> lies.
>>>>>>>
>>>>>>> It is easily provable that the C function H(P,P)==0 is correct on
>>>>>>> the
>>>>>>> basis of the fact correct execution trace of the x86 source-code of
>>>>>>> input to H(P,P) shows that P would never reach its "ret"
>>>>>>> instruction.
>>>>>>
>>>>>> Again, I say HOW, since the CORRECT emulation of the input to
>>>>>> H(P,P), as
>>>>>> shown by UTM(P,P), H1(P,P), or even P(P) shows that it Halts, if H is
>>>>>> defined to return 0 from H(P,P).
>>>>> Richard is one of the two liars.
>>>>> *The actual behavior of P when correctly emulated by H is shown below*
>>>>>
>>>>> #include <stdint.h>
>>>>> #define u32 uint32_t
>>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>> if (H(x, x))
>>>>> HERE: goto HERE;
>>>>> return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>> }
>>>>>
>>>>> _P()
>>>>> [00001352](01) 55 push ebp
>>>>> [00001353](02) 8bec mov ebp,esp
>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>> [00001358](01) 50 push eax // push P
>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>> [0000135c](01) 51 push ecx // push P
>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>> [00001362](03) 83c408 add esp,+08
>>>>> [00001365](02) 85c0 test eax,eax
>>>>> [00001367](02) 7402 jz 0000136b
>>>>> [00001369](02) ebfe jmp 00001369
>>>>> [0000136b](01) 5d pop ebp
>>>>> [0000136c](01) c3 ret
>>>>> Size in bytes:(0027) [0000136c]
>>>>>
>>>>> _main()
>>>>> [00001372](01) 55 push ebp
>>>>> [00001373](02) 8bec mov ebp,esp
>>>>> [00001375](05) 6852130000 push 00001352 // push P
>>>>> [0000137a](05) 6852130000 push 00001352 // push P
>>>>> [0000137f](05) e81efeffff call 000011a2 // call H
>>>>> [00001384](03) 83c408 add esp,+08
>>>>> [00001387](01) 50 push eax
>>>>> [00001388](05) 6823040000 push 00000423 // "Input_Halts = "
>>>>> [0000138d](05) e8e0f0ffff call 00000472 // call Output
>>>>> [00001392](03) 83c408 add esp,+08
>>>>> [00001395](02) 33c0 xor eax,eax
>>>>> [00001397](01) 5d pop ebp
>>>>> [00001398](01) c3 ret
>>>>> Size in bytes:(0039) [00001398]
>>>>>
>>>>> machine stack stack machine assembly
>>>>> address address data code language
>>>>> ======== ======== ======== ========= =============
>>>>> ...[00001372][0010229e][00000000] 55 push ebp
>>>>> ...[00001373][0010229e][00000000] 8bec mov ebp,esp
>>>>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
>>>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
>>>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>>>>>
>>>>> Begin Local Halt Decider Simulation Execution Trace Stored at:212352
>>>>>
>>>>> // H emulates the first seven instructions of P
>>>>> ...[00001352][0021233e][00212342] 55 push ebp // enter P
>>>>> ...[00001353][0021233e][00212342] 8bec mov ebp,esp
>>>>> ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
>>>>> ...[00001358][0021233a][00001352] 50 push eax // push P
>>>>> ...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
>>>>> ...[0000135c][00212336][00001352] 51 push ecx // push P
>>>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>>>>
>>>> Starting here is where the trace is incomplete. The emulation of the
>>>> instructions of the inner instance of H are not shown. Also the
>>>> lines below are not emulated by the top level H. They are emulated
>>>> by the inner H called by P. So in between each of these lines is
>>>> multiple instructions of the inner H performing the emulation of them.
>>>>
>>>>>
>>>>> // The emulated H emulates the first seven instructions of P
>>>>> ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
>>>>> ...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
>>>>> ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
>>>>> ...[00001358][0025cd62][00001352] 50 push eax // push P
>>>>> ...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
>>>>> ...[0000135c][0025cd5e][00001352] 51 push ecx // push P
>>>>> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>
>>>> Here is where H makes its error of aborting too soon. Explanation
>>>> below:
>>>>
>>> Several different confusions (see below).
>>>>>
>>>>> If the execution trace of function H() called by function P() shows:
>>>>> (1) Function H() is called twice in sequence from the same machine
>>>>> address of P().
>>>>> (2) With the same parameters to H().
>>>>> (3) With no conditional branch or indexed jump instructions in P().
>>>>
>>>> This condition is not met.
>>> (1) is proven
>>> (2) is proven // Third column shows TOS value of P's machine address
>>> (3) is proven //
>>>> There are branches / jumps in the *program* P contained in the
>>>> function H that can abort.
>>> We are not looking for jumps, we are looking for code that can change
>>> the behavior of P from one invocation to the next.
>>
>> And the conditional code of H that checks if its abort criteria is met
>> does *exactly* that.
>
> It is possible that H can change the behavior of P, yet H does not do
> that until after its input has already correctly matched an infinite
> behavior pattern.
>
> It is easy to verify that H does not change the behavior of P for the
> first 14 instructions of P.
>
>> The top level H is unable to see that the H called by P will trigger
>> that abort condition if allowed to continue, such as when simulated by
>> a UTM.
>>
>>> (a) conditional branch or
>>> (b) indexed jump instructions (where the index can vary)
>>>> The outer H is unable to detect that the inner H will do exactly
>>>> what the outer H does,
>>> None of this could possibly show that the simulated P ever reaches its
>>> "ret" instruction, thus is irrelevant.
>>>
>>> We are not asking:
>>> [A] Does P stop running?
>>
>> We are by the definition of the problem:  does an algorithm exist that
>> can detect if *any* arbitrary algorithm will halt when given a
>> particular input.
>
> No not at all this is false.
> A halt decider must only compute the mapping of its input to an accept
> or reject state based on the actual behavior specified by this input.

On 5/28/22 12:49 PM, olcott wrote:
> On 5/28/2022 11:35 AM, Richard Damon wrote:
>> On 5/28/22 12:02 PM, olcott wrote:
>>> On 5/28/2022 10:29 AM, Richard Damon wrote:
>>>>
>>>> On 5/28/22 11:05 AM, olcott wrote:
>>>>> On 5/28/2022 8:58 AM, Richard Damon wrote:
>>>>>>
>>>>>> On 5/28/22 6:26 AM, olcott wrote:
>>>>>>> On 5/27/2022 7:33 PM, Richard Damon wrote:
>>>>>>>> On 5/27/22 7:33 PM, olcott wrote:
>>>>>>>>> On 5/27/2022 6:26 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-05-27 16:42, olcott wrote:
>>>>>>>>>>> On 5/27/2022 5:26 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2022-05-27 16:13, olcott wrote:
>>>>>>>>>>>>> On 5/27/2022 4:41 PM, André G. Isaak wrote:
>>>>>>>>>>>>>> On 2022-05-27 15:31, olcott wrote:
>>>>>>>>>>>>>>> On 5/27/2022 4:21 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>>>>>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The input to H is NOT a "sequence of
>>>>>>>>>>>>>>>>>>>>>> configuratios", but the representation of an
>>>>>>>>>>>>>>>>>>>>>> algorithm and its input.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The finite string inputs to a halt decider specify
>>>>>>>>>>>>>>>>>>>>> (rather then merely represent) a sequence of
>>>>>>>>>>>>>>>>>>>>> configurations that may or may not reach their own
>>>>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I really don't think you have any idea what terms
>>>>>>>>>>>>>>>>>>>> like 'represent', 'specify', or 'sequence of
>>>>>>>>>>>>>>>>>>>> configurations' mean. Richard is perfectly correct.
>>>>>>>>>>>>>>>>>>>> You, as usual, are not.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The distinction that I make between represent and
>>>>>>>>>>>>>>>>>>> specify is that the x86 source-code for P represents
>>>>>>>>>>>>>>>>>>> P(P) whereas the actual correct x86 emulation of the
>>>>>>>>>>>>>>>>>>> input to H(P,P) specifies the actual behavior of this
>>>>>>>>>>>>>>>>>>> input. This is not the same behavior as the behavior
>>>>>>>>>>>>>>>>>>> specified by P(P).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> A sequence of configurations means a list of x86
>>>>>>>>>>>>>>>>>>> program steps executed or emulated in the order that
>>>>>>>>>>>>>>>>>>> their source-code specifies.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM
>>>>>>>>>>>>>>>>>>> description specifies a sequence of state transitions.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> And this decidedly is *not* what a halt decider is
>>>>>>>>>>>>>>>>>> given as its input. It is not given a sequence of
>>>>>>>>>>>>>>>>>> state transitions. It is given a representation of a
>>>>>>>>>>>>>>>>>> computation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No it is not and you know that it is not. A halt
>>>>>>>>>>>>>>>>> decider is given a finite string TM description that
>>>>>>>>>>>>>>>>> specifies a sequence of configurations.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A TM description and a sequence of configurations are
>>>>>>>>>>>>>>>> entirely different things (and the former certainly does
>>>>>>>>>>>>>>>> not 'specify' the latter). It's given either one or the
>>>>>>>>>>>>>>>> other. Make up your mind.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>> [000012c2](01)  55              push ebp
>>>>>>>>>>>>>>> [000012c3](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>> [000012c5](02)  ebfe            jmp 000012c5
>>>>>>>>>>>>>>> [000012c7](01)  5d              pop ebp
>>>>>>>>>>>>>>> [000012c8](01)  c3              ret
>>>>>>>>>>>>>>> Size in bytes:(0007) [000012c8]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So then the above x86 code may specify a game of
>>>>>>>>>>>>>>> tic-tac-toe and there is no possible way to determine
>>>>>>>>>>>>>>> that it does not because the x86 source code of a
>>>>>>>>>>>>>>> function has nothing to do with the sequence of steps of
>>>>>>>>>>>>>>> its correct simulation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That is not a sequence of configurations. It is a piece of
>>>>>>>>>>>>>> assembly code which represents a subroutine which is an
>>>>>>>>>>>>>> infinite loop. The sequence of configurations would look
>>>>>>>>>>>>>> something like this:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes that code specifies this sequence.
>>>>>>>>>>>>
>>>>>>>>>>>> No, it does not. What you have above only generates the
>>>>>>>>>>>> following *only* if you (a) interpret it as representing x86
>>>>>>>>>>>> instructions and (b) actually execute it on an x86 or some
>>>>>>>>>>>> appropriate emulator.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Because no one in their right mind would think of doing it
>>>>>>>>>>> otherwise those ridiculously self-evident facts need not be
>>>>>>>>>>> stated.
>>>>>>>>>>
>>>>>>>>>> You are the one who constantly makes much ado about nothing
>>>>>>>>>> about the fact that Turing Machines can ONLY accept finite
>>>>>>>>>> strings as their inputs and object to anyone who suggests that
>>>>>>>>>> something might compute some function which isn't over strings.
>>>>>>>>>>
>>>>>>>>>> You don't seem to understand exactly what a finite string is.
>>>>>>>>>> A finite string is simply a sequence of symbols. Given two
>>>>>>>>>> strings, you can ask questions like which is longer or whether
>>>>>>>>>> one is a substring or permutation of the other, but not much
>>>>>>>>>> else.
>>>>>>>>>>
>>>>>>>>>> That's because neither strings nor the symbols they are
>>>>>>>>>> composed of have any meaning whatsoever. They are just
>>>>>>>>>> sequences of uninterpreted tokens. As soon as you start
>>>>>>>>>> talking about 'sequences of configurations' or 'numerical
>>>>>>>>>> values' or anything along those lines you are no longer
>>>>>>>>>> talking about finite strings, but about the entities which
>>>>>>>>>> those strings represent to a particular TM/program.
>>>>>>>>>>
>>>>>>>>>> Part of designing a TM involves specifying exactly how a
>>>>>>>>>> string is to be interpreted (however 'ridiculously
>>>>>>>>>> self-evident' it might seem to you) So yes, they need to be
>>>>>>>>>> stated.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> If it was not for communication context then every single
>>>>>>>>>>> rule of grammar would have to be repeated with every sentence
>>>>>>>>>>> and every definition of every work would have to be repeated
>>>>>>>>>>> over and over.
>>>>>>>>>>>
>>>>>>>>>>>> You keep claiming that the input to the decider is a
>>>>>>>>>>>> sequence of configurations, but that's just plain wrong.
>>>>>>>>>>>
>>>>>>>>>>> The input to a decider
>>>>>>>>>>>
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> SPECIFIES SPECIFIES SPECIFIES SPECIFIES SPECIFIES
>>>>>>>>>>> A sequence of configirations
>>>>>>>>>>>
>>>>>>>>>>> Did you notice that I said SPECFIES this time ???
>>>>>>>>>>
>>>>>>>>>> But you still haven't provided a coherent definition of what
>>>>>>>>>> *you* mean by 'specify'. You gave a bit of wishy-washy
>>>>>>>>>> verbiage a few posts ago, but nothing which made this clear.
>>>>>>>>>> Repeating it over and over again doesn't add any clarity.
>>>>>>>>>
>>>>>>>>>> The question originally arose when you objected to the claim
>>>>>>>>>> that the input to a halt decider represents a computation (or
>>>>>>>>>> TM description/input string pair) and instead insisted that it
>>>>>>>>>> specifies a sequence of configurations.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes of course as everyone knows x86 source-code is one of the
>>>>>>>>> ingredients to a milkshake and because there is a standard
>>>>>>>>> practice for making milkshakes they already know when and how
>>>>>>>>> the x86 source-code must be applied to make a milkshake.
>>>>>>>>>
>>>>>>>>>> Now it seems like you are trying to claim that a
>>>>>>>>>> representation of a computation specifies a sequence of
>>>>>>>>>> configurations, but that doesn't explain why you so vehemently
>>>>>>>>>> objected
>>>>>>>>>
>>>>>>>>> Your brain is welded in rebuttal mode?
>>>>>>>>>
>>>>>>>>>> to the claim that the input to a halt decider represents a
>>>>>>>>>> computation. So clearly you mean something else altogether.
>>>>>>>>>>
>>>>>>>>>> André
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Because your brain is welded in rebuttal mode you will always
>>>>>>>>> act like you never know.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No, YOUR brain is welded in stupid mode. You are unable to make
>>>>>>>> a clear sentence because you misuse the English language to hide
>>>>>>>> your lies.
>>>>>>>
>>>>>>> It is easily provable that the C function H(P,P)==0 is correct on
>>>>>>> the basis of the fact correct execution trace of the x86
>>>>>>> source-code of input to H(P,P) shows that P would never reach its
>>>>>>> "ret" instruction.
>>>>>>
>>>>>> Again, I say HOW, since the CORRECT emulation of the input to
>>>>>> H(P,P), as shown by UTM(P,P), H1(P,P), or even P(P) shows that it
>>>>>> Halts, if H is defined to return 0 from H(P,P).
>>>>>
>>>>> Richard is one of the two liars.
>>>>> *The actual behavior of P when correctly emulated by H is shown below*
>>>>
>>>>
>>>> No, it isn't, because it LIES.
>>>>>
>>>>> #include <stdint.h>
>>>>> #define u32 uint32_t
>>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>>    if (H(x, x))
>>>>>      HERE: goto HERE;
>>>>>    return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>> }
>>>>>
>>>>> _P()
>>>>> [00001352](01)  55              push ebp
>>>>> [00001353](02)  8bec            mov ebp,esp
>>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>>>> [00001358](01)  50              push eax      // push P
>>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>>>> [0000135c](01)  51              push ecx      // push P
>>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>>>> [00001362](03)  83c408          add esp,+08
>>>>> [00001365](02)  85c0            test eax,eax
>>>>> [00001367](02)  7402            jz 0000136b
>>>>> [00001369](02)  ebfe            jmp 00001369
>>>>> [0000136b](01)  5d              pop ebp
>>>>> [0000136c](01)  c3              ret
>>>>> Size in bytes:(0027) [0000136c]
>>>>>
>>>>> _main()
>>>>> [00001372](01)  55              push ebp
>>>>> [00001373](02)  8bec            mov ebp,esp
>>>>> [00001375](05)  6852130000      push 00001352 // push P
>>>>> [0000137a](05)  6852130000      push 00001352 // push P
>>>>> [0000137f](05)  e81efeffff      call 000011a2 // call H
>>>>> [00001384](03)  83c408          add esp,+08
>>>>> [00001387](01)  50              push eax
>>>>> [00001388](05)  6823040000      push 00000423 // "Input_Halts = "
>>>>> [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
>>>>> [00001392](03)  83c408          add esp,+08
>>>>> [00001395](02)  33c0            xor eax,eax
>>>>> [00001397](01)  5d              pop ebp
>>>>> [00001398](01)  c3              ret
>>>>> Size in bytes:(0039) [00001398]
>>>>>
>>>>>      machine   stack     stack     machine    assembly
>>>>>      address   address   data      code       language
>>>>>      ========  ========  ========  =========  =============
>>>>> ...[00001372][0010229e][00000000] 55         push ebp
>>>>> ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
>>>>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
>>>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
>>>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>>>>>
>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored at:212352
>>>>>
>>>>> // H emulates the first seven instructions of P
>>>>> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
>>>>> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
>>>>> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
>>>>> ...[00001358][0021233a][00001352] 50         push eax      // push P
>>>>> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
>>>>> ...[0000135c][00212336][00001352] 51         push ecx      // push P
>>>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>>>>>
>>>>> // The emulated H emulates the first seven instructions of P
>>>> So, the following is NOT an emulation of the P that the top level H
>>>> is emulating, and
>>>
>>> Right.
>>>
>>>> thus NOT part of a CORRECT x86 emulation of the program.
>>>
>>> Wrong.
>>>
>>> Just like the first invocation of infinite recursion is the root
>>> cause of the infinite recursion the first invocation of infinitely
>>> nested x86 emulation is its root cause.
>>>
>>
>> Except you don't understand the definitions.
>>
>> The second emulation is NOT an emulation by the emulator we are
>> looking at (At least not if H is how you have defined it), so can't be
>> just called part of it.
>>
>
> The question is: Would the correct x86 emulation of the input to H(P,P)
> ever reach the "ret" instruction of P?
>
> An answer of "no" conclusively proves that H(P,P)==0 is correct.
>

On 5/28/2022 1:10 PM, André G. Isaak wrote:
> On 2022-05-28 10:24, olcott wrote:
>> On 5/28/2022 11:06 AM, Dennis Bush wrote:
>
>>> And since the computation that H(P,P) is deciding on *by definition*
>>> is P(P), and the computation P(P) completes, H is incorrect to abort
>>> and return 0.
>>
>> A halt decider must only compute the mapping of its input to an accept
>> or reject state based on the actual behavior specified by this input.
>
> And what exactly is the above supposed to mean? You still haven't
> provided a coherent definition of what you mean by 'specified'. What
> does it mean for an input string to specify a behaviour?
>
> André
>

In other words when I prove what I mean by "specified" 100 times the
fact that you always make sure to ignore what I said is equivalent to me
having never said anything about it.

The behavior specified by an input is the execution trace derived by the
correct x86 emulation of this input by its simulating halt decider.

This proves that H(P,P)==0 and H1(P,P)==1.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 5/28/2022 2:21 PM, André G. Isaak wrote:
> On 2022-05-28 12:52, olcott wrote:
>> On 5/28/2022 1:38 PM, André G. Isaak wrote:
>>> On 2022-05-28 12:26, olcott wrote:
>>>> On 5/28/2022 1:10 PM, André G. Isaak wrote:
>>>>> On 2022-05-28 10:24, olcott wrote:
>>>>>> On 5/28/2022 11:06 AM, Dennis Bush wrote:
>>>>>
>>>>>>> And since the computation that H(P,P) is deciding on *by
>>>>>>> definition* is P(P), and the computation P(P) completes, H is
>>>>>>> incorrect to abort and return 0.
>>>>>>
>>>>>> A halt decider must only compute the mapping of its input to an
>>>>>> accept or reject state based on the actual behavior specified by
>>>>>> this input.
>>>>>
>>>>> And what exactly is the above supposed to mean? You still haven't
>>>>> provided a coherent definition of what you mean by 'specified'.
>>>>> What does it mean for an input string to specify a behaviour?
>>>>>
>>>>> André
>>>>>
>>>>
>>>> In other words when I prove what I mean by "specified" 100 times the
>>>> fact that you always make sure to ignore what I said is equivalent
>>>> to me having never said anything about it.
>>>
>>> You can't "prove" what you mean by something. You define what
>>> something is intended to mean. And so far you haven't provided a
>>> definition for 'specify'. When asked you've either hurled insults or
>>> given strange analogies involving milkshakes.
>>>
>>>> The behavior specified by an input is the execution trace derived by
>>>> the correct x86 emulation of this input by its simulating halt decider.
>>>
>>> And how exactly do you define 'correct x86 emulation'?
>>
>> I have told you this many times. Why do you persistently ignore what I
>> say and then claim that I said nothing?
>
> No, you have not. When asked in the past you've given vaguely worded
> 'explanations' or unclear examples, but you've never provided anything
> resembling a definition. A definition would take the form:
>
> A program S correctly emulates an input M, I if and only if ...
*THIS IS THE CORRECT WAY TO ANALYZE IT*
The sequence of instructions that program S emulates is the same
sequence that the x86 machine language input M specifies when it is
being emulated by S.

*THIS IS THE LYING CHEATING WAY TO ANALYZE IT*
The sequence of instructions that program S emulates is the same
sequence that the x86 machine language input M specifies when it is
being emulated by R.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 5/28/22 3:27 PM, olcott wrote:
> On 5/28/2022 2:21 PM, André G. Isaak wrote:
>> On 2022-05-28 12:52, olcott wrote:
>>> On 5/28/2022 1:38 PM, André G. Isaak wrote:
>>>> On 2022-05-28 12:26, olcott wrote:
>>>>> On 5/28/2022 1:10 PM, André G. Isaak wrote:
>>>>>> On 2022-05-28 10:24, olcott wrote:
>>>>>>> On 5/28/2022 11:06 AM, Dennis Bush wrote:
>>>>>>
>>>>>>>> And since the computation that H(P,P) is deciding on *by
>>>>>>>> definition* is P(P), and the computation P(P) completes, H is
>>>>>>>> incorrect to abort and return 0.
>>>>>>>
>>>>>>> A halt decider must only compute the mapping of its input to an
>>>>>>> accept or reject state based on the actual behavior specified by
>>>>>>> this input.
>>>>>>
>>>>>> And what exactly is the above supposed to mean? You still haven't
>>>>>> provided a coherent definition of what you mean by 'specified'.
>>>>>> What does it mean for an input string to specify a behaviour?
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> In other words when I prove what I mean by "specified" 100 times
>>>>> the fact that you always make sure to ignore what I said is
>>>>> equivalent to me having never said anything about it.
>>>>
>>>> You can't "prove" what you mean by something. You define what
>>>> something is intended to mean. And so far you haven't provided a
>>>> definition for 'specify'. When asked you've either hurled insults or
>>>> given strange analogies involving milkshakes.
>>>>
>>>>> The behavior specified by an input is the execution trace derived
>>>>> by the correct x86 emulation of this input by its simulating halt
>>>>> decider.
>>>>
>>>> And how exactly do you define 'correct x86 emulation'?
>>>
>>> I have told you this many times. Why do you persistently ignore what
>>> I say and then claim that I said nothing?
>>
>> No, you have not. When asked in the past you've given vaguely worded
>> 'explanations' or unclear examples, but you've never provided anything
>> resembling a definition. A definition would take the form:
>>
>> A program S correctly emulates an input M, I if and only if ...
> *THIS IS THE CORRECT WAY TO ANALYZE IT*
> The sequence of instructions that program S emulates is the same
> sequence that the x86 machine language input M specifies when it is
> being emulated by S.
>
> *THIS IS THE LYING CHEATING WAY TO ANALYZE IT*
> The sequence of instructions that program S emulates is the same
> sequence that the x86 machine language input M specifies when it is
> being emulated by R.
>
>

So CORRECTNESS is relative to the one doing it?

The ACTUAL correct answer the sequence of instructions that would occur
from a simulator that doesn't stop until the program ends. Yes, this
means that the correct simulation of a non-halting computation is
non-halting and generates an infinite sequence.

So, If S decided to stop after one step, its simulation would still be
correct?

That seems to be what you mean.

That means almost ALL programs can be correctly decided as "Non-Halting"
by a dumb enough.

That definition makes your definition of the halting problem incorrect,
as the Halting behavior of a Compuation is NOT a funciton of the decider
that is deciding it.

Thus you are not working on the halting problem but just your POOP.

On 5/28/2022 7:22 PM, Mike Terry wrote:
> On 27/05/2022 22:32, Richard Damon wrote:
>> On 5/27/22 5:21 PM, André G. Isaak wrote:
>>> On 2022-05-27 14:38, olcott wrote:
>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>
>>>>>>>>> The input to H is NOT a "sequence of configuratios", but the
>>>>>>>>> representation of an algorithm and its input.
>>>>>>>>
>>>>>>>> The finite string inputs to a halt decider specify (rather then
>>>>>>>> merely represent) a sequence of configurations that may or may
>>>>>>>> not reach their own final state.
>>>>>>>
>>>>>>> I really don't think you have any idea what terms like
>>>>>>> 'represent', 'specify', or 'sequence of configurations' mean.
>>>>>>> Richard is perfectly correct. You, as usual, are not.
>>>>>>>
>>>>>>
>>>>>> The distinction that I make between represent and specify is that
>>>>>> the x86 source-code for P represents P(P) whereas the actual
>>>>>> correct x86 emulation of the input to H(P,P) specifies the actual
>>>>>> behavior of this input. This is not the same behavior as the
>>>>>> behavior specified by P(P).
>>>>>>
>>>>>> A sequence of configurations means a list of x86 program steps
>>>>>> executed or emulated in the order that their source-code specifies.
>>>>>>
>>>>>> Likewise with a TM or the UTM simulation of a TM description
>>>>>> specifies a sequence of state transitions.
>>>>>
>>>>> And this decidedly is *not* what a halt decider is given as its
>>>>> input. It is not given a sequence of state transitions. It is given
>>>>> a representation of a computation.
>>>>>
>>>>
>>>> No it is not and you know that it is not. A halt decider is given a
>>>> finite string TM description that specifies a sequence of
>>>> configurations.
>>>
>>> A TM description and a sequence of configurations are entirely
>>> different things (and the former certainly does not 'specify' the
>>> latter). It's given either one or the other. Make up your mind.
>>>
>>> André
>>>
>>
>> Well, a TM description, and a description of an input to that TM, does
>> specify a "sequence of configurations" based on what running that TM
>> on that input would do.
>
> "Specify" is not the word I'd use.  (If I write a shopping list I
> specify what I'm going to get when I go shopping: one loaf of bread and
> 4oz jar of strawberry jam.  I don't write various clues which can
> together be used to generate what I want by applying some algorithm.)
>
> For your scenario, "determine" seems accurate.  But PO also says that
> P(P) "specifies non-halting behaviour", and that computation halts.  I
> think that this use just means "matches PO's abort test".
>

I never said that: "P(P) specifies non-halting behaviour".
Your term "determine" is better than my term "specify".

The input to H(P,P) determines the sequence of x86 instructions of the
correct x86 emulation of P by H. This sequence never reaches the "ret"
instruction of P.

The input to H1(P,P) determines the sequence of x86 instructions of the
correct x86 emulation of P by H1. This sequence reaches the "ret"
instruction of P and halts.

This latter sequence of x86 instructions of P is identical to the
sequence specified by P(P).

>>
>> The sequence of configurations may be finite (if the TM would halt on
>> that input) or it might be infinite (if the TM would not halt on that
>> input), but ANY TM description + an input generates such an output.
>
> Just to add more room for misunderstanding, I believe Linz actually
> defines "computation" as meaning your sequence of configurations, while
> some define it as the combination (P,I) (which together determine Linz's
> calculation...).  Now, anyone for "...on the basis of.."?
>
> Mike.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 5/28/22 10:43 PM, olcott wrote:
> On 5/28/2022 7:22 PM, Mike Terry wrote:
>> On 27/05/2022 22:32, Richard Damon wrote:
>>> On 5/27/22 5:21 PM, André G. Isaak wrote:
>>>> On 2022-05-27 14:38, olcott wrote:
>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>>>> The input to H is NOT a "sequence of configuratios", but the
>>>>>>>>>> representation of an algorithm and its input.
>>>>>>>>>
>>>>>>>>> The finite string inputs to a halt decider specify (rather then
>>>>>>>>> merely represent) a sequence of configurations that may or may
>>>>>>>>> not reach their own final state.
>>>>>>>>
>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>> 'represent', 'specify', or 'sequence of configurations' mean.
>>>>>>>> Richard is perfectly correct. You, as usual, are not.
>>>>>>>>
>>>>>>>
>>>>>>> The distinction that I make between represent and specify is that
>>>>>>> the x86 source-code for P represents P(P) whereas the actual
>>>>>>> correct x86 emulation of the input to H(P,P) specifies the actual
>>>>>>> behavior of this input. This is not the same behavior as the
>>>>>>> behavior specified by P(P).
>>>>>>>
>>>>>>> A sequence of configurations means a list of x86 program steps
>>>>>>> executed or emulated in the order that their source-code specifies.
>>>>>>>
>>>>>>> Likewise with a TM or the UTM simulation of a TM description
>>>>>>> specifies a sequence of state transitions.
>>>>>>
>>>>>> And this decidedly is *not* what a halt decider is given as its
>>>>>> input. It is not given a sequence of state transitions. It is
>>>>>> given a representation of a computation.
>>>>>>
>>>>>
>>>>> No it is not and you know that it is not. A halt decider is given a
>>>>> finite string TM description that specifies a sequence of
>>>>> configurations.
>>>>
>>>> A TM description and a sequence of configurations are entirely
>>>> different things (and the former certainly does not 'specify' the
>>>> latter). It's given either one or the other. Make up your mind.
>>>>
>>>> André
>>>>
>>>
>>> Well, a TM description, and a description of an input to that TM,
>>> does specify a "sequence of configurations" based on what running
>>> that TM on that input would do.
>>
>> "Specify" is not the word I'd use.  (If I write a shopping list I
>> specify what I'm going to get when I go shopping: one loaf of bread
>> and 4oz jar of strawberry jam.  I don't write various clues which can
>> together be used to generate what I want by applying some algorithm.)
>>
>> For your scenario, "determine" seems accurate.  But PO also says that
>> P(P) "specifies non-halting behaviour", and that computation halts.  I
>> think that this use just means "matches PO's abort test".
>>
>
> I never said that: "P(P) specifies non-halting behaviour".
> Your term "determine" is better than my term "specify".

But that is what a Halt Decider saying its input represents a
Non-Halting Computaiton IS saying. If that is not what H is saying, it
isn't a Halt DEcider.

>
> The input to H(P,P) determines the sequence of x86 instructions of the
> correct x86 emulation of P by H. This sequence never reaches the "ret"
> instruction of P.

How is it a "Correct Emulation" if it doesn't match the behavior of the
thing it is emulating?

Note, the ONLY reason H doesn't reach the ret instruction is because H
stopped to soon.

Remember, if you change THIS copy of H into a different program that
simulates longer, it will see the simulation reach the end. This is
because H^/P doesn't use "self-refenceing" to refer to the decider
deciding it, it uses a copy of the Halt Decider that it is designed to foil.

In fact, they way you are showing your programs being built actually
shows that H and P are not correctly defined as independent
computations. Your design error is what makes an actual self-referential
system. My guess is you are doing it this way because the right way is
too complicated for you to understand with the input being in a virtual
address range independent of the decider (it also breaks you method of
detecting the 'recursion').

>
> The input to H1(P,P) determines the sequence of x86 instructions of the
> correct x86 emulation of P by H1. This sequence reaches the "ret"
> instruction of P and halts.

Rignt, because it doesn't stop to soon.

The input is the same, so the "Correct Simulation" of that input is the
same.

>
> This latter sequence of x86 instructions of P is identical to the
> sequence specified by P(P).

As is required by the term "Correct Simulation"

>
>>>
>>> The sequence of configurations may be finite (if the TM would halt on
>>> that input) or it might be infinite (if the TM would not halt on that
>>> input), but ANY TM description + an input generates such an output.
>>
>> Just to add more room for misunderstanding, I believe Linz actually
>> defines "computation" as meaning your sequence of configurations,
>> while some define it as the combination (P,I) (which together
>> determine Linz's calculation...).  Now, anyone for "...on the basis
>> of.."?
>>
>> Mike.
>
>

On 5/29/2022 12:04 PM, Mike Terry wrote:
> On 29/05/2022 03:43, olcott wrote:
>> On 5/28/2022 7:22 PM, Mike Terry wrote:
>>> On 27/05/2022 22:32, Richard Damon wrote:
>>>> On 5/27/22 5:21 PM, André G. Isaak wrote:
>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>>>> The input to H is NOT a "sequence of configuratios", but the
>>>>>>>>>>> representation of an algorithm and its input.
>>>>>>>>>>
>>>>>>>>>> The finite string inputs to a halt decider specify (rather
>>>>>>>>>> then merely represent) a sequence of configurations that may
>>>>>>>>>> or may not reach their own final state.
>>>>>>>>>
>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' mean.
>>>>>>>>> Richard is perfectly correct. You, as usual, are not.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The distinction that I make between represent and specify is
>>>>>>>> that the x86 source-code for P represents P(P) whereas the
>>>>>>>> actual correct x86 emulation of the input to H(P,P) specifies
>>>>>>>> the actual behavior of this input. This is not the same behavior
>>>>>>>> as the behavior specified by P(P).
>>>>>>>>
>>>>>>>> A sequence of configurations means a list of x86 program steps
>>>>>>>> executed or emulated in the order that their source-code specifies.
>>>>>>>>
>>>>>>>> Likewise with a TM or the UTM simulation of a TM description
>>>>>>>> specifies a sequence of state transitions.
>>>>>>>
>>>>>>> And this decidedly is *not* what a halt decider is given as its
>>>>>>> input. It is not given a sequence of state transitions. It is
>>>>>>> given a representation of a computation.
>>>>>>>
>>>>>>
>>>>>> No it is not and you know that it is not. A halt decider is given
>>>>>> a finite string TM description that specifies a sequence of
>>>>>> configurations.
>>>>>
>>>>> A TM description and a sequence of configurations are entirely
>>>>> different things (and the former certainly does not 'specify' the
>>>>> latter). It's given either one or the other. Make up your mind.
>>>>>
>>>>> André
>>>>>
>>>>
>>>> Well, a TM description, and a description of an input to that TM,
>>>> does specify a "sequence of configurations" based on what running
>>>> that TM on that input would do.
>>>
>>> "Specify" is not the word I'd use.  (If I write a shopping list I
>>> specify what I'm going to get when I go shopping: one loaf of bread
>>> and 4oz jar of strawberry jam.  I don't write various clues which can
>>> together be used to generate what I want by applying some algorithm.)
>>>
>>> For your scenario, "determine" seems accurate.  But PO also says that
>>> P(P) "specifies non-halting behaviour", and that computation halts.
>>> I think that this use just means "matches PO's abort test".
>>>
>>
>> I never said that: "P(P) specifies non-halting behaviour".
>> Your term "determine" is better than my term "specify".
>>
>> The input to H(P,P) determines the sequence of x86 instructions of the
>> correct x86 emulation of P by H. This sequence never reaches the "ret"
>> instruction of P.
>
> Obviously H never gets to emulate the final ret of P - because it aborts
> the emulation before it gets there.  Duh!  Not seeing the final ret
> /because you gave up and stopped emulating/ does not mean the
> computation P(P) never halts, or that "never halts" is "the correct
> answer" for H to return for input (P,P).  That's some gibberish idea
> you've come up with in your confusion.
>
> If UTM emulates the P(P) computation, it will see all the EXACT SAME
> config steps that H emulated, except that where H gave up due to
> spotting some pattern, UTM carries on and sees the P(P) steps after H
> gave up, INCLUDING THE FINAL RET OF P.
The correct x86 emulation of the input to H(P,P) by H never reaches the
"ret" instruction of P in 1 to ∞ emulated steps.

Honest reviewers can very easily verify the truth of this by simply
reverse-engineering the execution trace of the sequence of instructions
of P when the input to H(P,P) is correctly emulated by H.

Honest reviewers that are not stupid will also know that when H(P,P)
aborts the simulation of its input that this does not magically cause P
to leap to its "ret" instruction.

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 5/29/22 1:19 PM, olcott wrote:
> On 5/29/2022 12:04 PM, Mike Terry wrote:
>> On 29/05/2022 03:43, olcott wrote:
>>> On 5/28/2022 7:22 PM, Mike Terry wrote:
>>>> On 27/05/2022 22:32, Richard Damon wrote:
>>>>> On 5/27/22 5:21 PM, André G. Isaak wrote:
>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios", but the
>>>>>>>>>>>> representation of an algorithm and its input.
>>>>>>>>>>>
>>>>>>>>>>> The finite string inputs to a halt decider specify (rather
>>>>>>>>>>> then merely represent) a sequence of configurations that may
>>>>>>>>>>> or may not reach their own final state.
>>>>>>>>>>
>>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' mean.
>>>>>>>>>> Richard is perfectly correct. You, as usual, are not.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The distinction that I make between represent and specify is
>>>>>>>>> that the x86 source-code for P represents P(P) whereas the
>>>>>>>>> actual correct x86 emulation of the input to H(P,P) specifies
>>>>>>>>> the actual behavior of this input. This is not the same
>>>>>>>>> behavior as the behavior specified by P(P).
>>>>>>>>>
>>>>>>>>> A sequence of configurations means a list of x86 program steps
>>>>>>>>> executed or emulated in the order that their source-code
>>>>>>>>> specifies.
>>>>>>>>>
>>>>>>>>> Likewise with a TM or the UTM simulation of a TM description
>>>>>>>>> specifies a sequence of state transitions.
>>>>>>>>
>>>>>>>> And this decidedly is *not* what a halt decider is given as its
>>>>>>>> input. It is not given a sequence of state transitions. It is
>>>>>>>> given a representation of a computation.
>>>>>>>>
>>>>>>>
>>>>>>> No it is not and you know that it is not. A halt decider is given
>>>>>>> a finite string TM description that specifies a sequence of
>>>>>>> configurations.
>>>>>>
>>>>>> A TM description and a sequence of configurations are entirely
>>>>>> different things (and the former certainly does not 'specify' the
>>>>>> latter). It's given either one or the other. Make up your mind.
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> Well, a TM description, and a description of an input to that TM,
>>>>> does specify a "sequence of configurations" based on what running
>>>>> that TM on that input would do.
>>>>
>>>> "Specify" is not the word I'd use.  (If I write a shopping list I
>>>> specify what I'm going to get when I go shopping: one loaf of bread
>>>> and 4oz jar of strawberry jam.  I don't write various clues which
>>>> can together be used to generate what I want by applying some
>>>> algorithm.)
>>>>
>>>> For your scenario, "determine" seems accurate.  But PO also says
>>>> that P(P) "specifies non-halting behaviour", and that computation
>>>> halts. I think that this use just means "matches PO's abort test".
>>>>
>>>
>>> I never said that: "P(P) specifies non-halting behaviour".
>>> Your term "determine" is better than my term "specify".
>>>
>>> The input to H(P,P) determines the sequence of x86 instructions of
>>> the correct x86 emulation of P by H. This sequence never reaches the
>>> "ret" instruction of P.
>>
>> Obviously H never gets to emulate the final ret of P - because it
>> aborts the emulation before it gets there.  Duh!  Not seeing the final
>> ret /because you gave up and stopped emulating/ does not mean the
>> computation P(P) never halts, or that "never halts" is "the correct
>> answer" for H to return for input (P,P).  That's some gibberish idea
>> you've come up with in your confusion.
>>
>> If UTM emulates the P(P) computation, it will see all the EXACT SAME
>> config steps that H emulated, except that where H gave up due to
>> spotting some pattern, UTM carries on and sees the P(P) steps after H
>> gave up, INCLUDING THE FINAL RET OF P.
> The correct x86 emulation of the input to H(P,P) by H never reaches the
> "ret" instruction of P in 1 to ∞ emulated steps.

No, H will abort it at whatever number of steps would abort that input.

Remember, H is a FIXED algorithm (or needs to be to be a decider) and
thus has DEFINITE behavior for a given input.

Your arguement isn't about a given H, but confounds the behavior of
different members of a whole class of them, each generating a DIFFERENT
input, and thus not making an actual arguement about any of the input.

This is the fallacy of your notation. Your H keeps on being shown to not
be a definite algorithm, so it can't be a Halt Decider.

>
> Honest reviewers can very easily verify the truth of this by simply
> reverse-engineering the execution trace of the sequence of instructions
> of P when the input to H(P,P) is correctly emulated by H.
>

What, that P(P) calls H(P,P) which is defined to return a 0 after some
period of time and thus halts.

The problem is you have introduced incorrect assumptions into your logic
system making it inconsistent, thus we can actually prove opposites
sides of a number of questions.

> Honest reviewers that are not stupid will also know that when H(P,P)
> aborts the simulation of its input that this does not magically cause P
> to leap to its "ret" instruction.
>

In one sense, you are right, THAT instance of P doesn't just jump to the
ret instruction.

But, H returning 0, mean that an P that called that H WILL go to its ret
instruction.

This PROVES that if H is actually a Computation, and thus the property
that ALL copies of it given the same input will produce the same
behavior, proves that the P that H aborted, would have reached that ret
instruction if continued to be simulated by what the field defines as a
correct simulation (that of a UTM), even if that is not what you want to
define as a correct simulation in your proof.

You INCORRECT definition of what a "Correct Simulation", and then
assuming it has all the properties of what the theory calls a correct
simulation, is what broke you logic system.

You are just shown to not be actually working on the halting problem,
and are working in a logic system broken by your incorrect assumptions.

> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax      // push P
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx      // push P
> [0000135d](05)  e840feffff      call 000011a2 // call H
> [00001362](03)  83c408          add esp,+08
> [00001365](02)  85c0            test eax,eax
> [00001367](02)  7402            jz 0000136b
> [00001369](02)  ebfe            jmp 00001369
> [0000136b](01)  5d              pop ebp
> [0000136c](01)  c3              ret
> Size in bytes:(0027) [0000136c]
>
>

On 5/29/2022 12:39 PM, Richard Damon wrote:
> On 5/29/22 1:19 PM, olcott wrote:
>> On 5/29/2022 12:04 PM, Mike Terry wrote:
>>> On 29/05/2022 03:43, olcott wrote:
>>>> On 5/28/2022 7:22 PM, Mike Terry wrote:
>>>>> On 27/05/2022 22:32, Richard Damon wrote:
>>>>>> On 5/27/22 5:21 PM, André G. Isaak wrote:
>>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios", but
>>>>>>>>>>>>> the representation of an algorithm and its input.
>>>>>>>>>>>>
>>>>>>>>>>>> The finite string inputs to a halt decider specify (rather
>>>>>>>>>>>> then merely represent) a sequence of configurations that may
>>>>>>>>>>>> or may not reach their own final state.
>>>>>>>>>>>
>>>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' mean.
>>>>>>>>>>> Richard is perfectly correct. You, as usual, are not.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The distinction that I make between represent and specify is
>>>>>>>>>> that the x86 source-code for P represents P(P) whereas the
>>>>>>>>>> actual correct x86 emulation of the input to H(P,P) specifies
>>>>>>>>>> the actual behavior of this input. This is not the same
>>>>>>>>>> behavior as the behavior specified by P(P).
>>>>>>>>>>
>>>>>>>>>> A sequence of configurations means a list of x86 program steps
>>>>>>>>>> executed or emulated in the order that their source-code
>>>>>>>>>> specifies.
>>>>>>>>>>
>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM description
>>>>>>>>>> specifies a sequence of state transitions.
>>>>>>>>>
>>>>>>>>> And this decidedly is *not* what a halt decider is given as its
>>>>>>>>> input. It is not given a sequence of state transitions. It is
>>>>>>>>> given a representation of a computation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No it is not and you know that it is not. A halt decider is
>>>>>>>> given a finite string TM description that specifies a sequence
>>>>>>>> of configurations.
>>>>>>>
>>>>>>> A TM description and a sequence of configurations are entirely
>>>>>>> different things (and the former certainly does not 'specify' the
>>>>>>> latter). It's given either one or the other. Make up your mind.
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>
>>>>>> Well, a TM description, and a description of an input to that TM,
>>>>>> does specify a "sequence of configurations" based on what running
>>>>>> that TM on that input would do.
>>>>>
>>>>> "Specify" is not the word I'd use.  (If I write a shopping list I
>>>>> specify what I'm going to get when I go shopping: one loaf of bread
>>>>> and 4oz jar of strawberry jam.  I don't write various clues which
>>>>> can together be used to generate what I want by applying some
>>>>> algorithm.)
>>>>>
>>>>> For your scenario, "determine" seems accurate.  But PO also says
>>>>> that P(P) "specifies non-halting behaviour", and that computation
>>>>> halts. I think that this use just means "matches PO's abort test".
>>>>>
>>>>
>>>> I never said that: "P(P) specifies non-halting behaviour".
>>>> Your term "determine" is better than my term "specify".
>>>>
>>>> The input to H(P,P) determines the sequence of x86 instructions of
>>>> the correct x86 emulation of P by H. This sequence never reaches the
>>>> "ret" instruction of P.
>>>
>>> Obviously H never gets to emulate the final ret of P - because it
>>> aborts the emulation before it gets there.  Duh!  Not seeing the
>>> final ret /because you gave up and stopped emulating/ does not mean
>>> the computation P(P) never halts, or that "never halts" is "the
>>> correct answer" for H to return for input (P,P).  That's some
>>> gibberish idea you've come up with in your confusion.
>>>
>>> If UTM emulates the P(P) computation, it will see all the EXACT SAME
>>> config steps that H emulated, except that where H gave up due to
>>> spotting some pattern, UTM carries on and sees the P(P) steps after H
>>> gave up, INCLUDING THE FINAL RET OF P.
>> The correct x86 emulation of the input to H(P,P) by H never reaches
>> the "ret" instruction of P in 1 to ∞ emulated steps.
>
> No, H will abort it at whatever number of steps would abort that input.
>
> Remember, H is a FIXED algorithm (or needs to be to be a decider) and
> thus has DEFINITE behavior for a given input.
>
> Your arguement isn't about a given H, but confounds the behavior of
> different members of a whole class of them,

Yes, that is how categorically exhaustive reasoning** works.
** Reasoning that cannot possibly have any gaps.

The alternative method that you suggest is to test each element of an
infinite set one-at-a-time.

> each generating a DIFFERENT
> input, and thus not making an actual arguement about any of the input.
>

The literal string of machine code bytes is the only actual input.

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

H is defined to be at machine address 000011a2.

> This is the fallacy of your notation. Your H keeps on being shown to not
> be a definite algorithm, so it can't be a Halt Decider.
>

There are only two possible ways that H can be defined:
(a) H that aborts its simulation after some fixed number of emulated steps.

(b) H that does not abort its simulation after some fixed number of
emulated steps.

In neither of these categorically exhaustive cases does the correctly
emulated input to H(P,P) ever reach its "ret" instruction.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 5/29/22 3:16 PM, olcott wrote:
> On 5/29/2022 12:39 PM, Richard Damon wrote:
>> On 5/29/22 1:19 PM, olcott wrote:
>>> On 5/29/2022 12:04 PM, Mike Terry wrote:
>>>> On 29/05/2022 03:43, olcott wrote:
>>>>> On 5/28/2022 7:22 PM, Mike Terry wrote:
>>>>>> On 27/05/2022 22:32, Richard Damon wrote:
>>>>>>> On 5/27/22 5:21 PM, André G. Isaak wrote:
>>>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios", but
>>>>>>>>>>>>>> the representation of an algorithm and its input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The finite string inputs to a halt decider specify (rather
>>>>>>>>>>>>> then merely represent) a sequence of configurations that
>>>>>>>>>>>>> may or may not reach their own final state.
>>>>>>>>>>>>
>>>>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations'
>>>>>>>>>>>> mean. Richard is perfectly correct. You, as usual, are not.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The distinction that I make between represent and specify is
>>>>>>>>>>> that the x86 source-code for P represents P(P) whereas the
>>>>>>>>>>> actual correct x86 emulation of the input to H(P,P) specifies
>>>>>>>>>>> the actual behavior of this input. This is not the same
>>>>>>>>>>> behavior as the behavior specified by P(P).
>>>>>>>>>>>
>>>>>>>>>>> A sequence of configurations means a list of x86 program
>>>>>>>>>>> steps executed or emulated in the order that their
>>>>>>>>>>> source-code specifies.
>>>>>>>>>>>
>>>>>>>>>>> Likewise with a TM or the UTM simulation of a TM description
>>>>>>>>>>> specifies a sequence of state transitions.
>>>>>>>>>>
>>>>>>>>>> And this decidedly is *not* what a halt decider is given as
>>>>>>>>>> its input. It is not given a sequence of state transitions. It
>>>>>>>>>> is given a representation of a computation.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No it is not and you know that it is not. A halt decider is
>>>>>>>>> given a finite string TM description that specifies a sequence
>>>>>>>>> of configurations.
>>>>>>>>
>>>>>>>> A TM description and a sequence of configurations are entirely
>>>>>>>> different things (and the former certainly does not 'specify'
>>>>>>>> the latter). It's given either one or the other. Make up your mind.
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>
>>>>>>> Well, a TM description, and a description of an input to that TM,
>>>>>>> does specify a "sequence of configurations" based on what running
>>>>>>> that TM on that input would do.
>>>>>>
>>>>>> "Specify" is not the word I'd use.  (If I write a shopping list I
>>>>>> specify what I'm going to get when I go shopping: one loaf of
>>>>>> bread and 4oz jar of strawberry jam.  I don't write various clues
>>>>>> which can together be used to generate what I want by applying
>>>>>> some algorithm.)
>>>>>>
>>>>>> For your scenario, "determine" seems accurate.  But PO also says
>>>>>> that P(P) "specifies non-halting behaviour", and that computation
>>>>>> halts. I think that this use just means "matches PO's abort test".
>>>>>>
>>>>>
>>>>> I never said that: "P(P) specifies non-halting behaviour".
>>>>> Your term "determine" is better than my term "specify".
>>>>>
>>>>> The input to H(P,P) determines the sequence of x86 instructions of
>>>>> the correct x86 emulation of P by H. This sequence never reaches
>>>>> the "ret" instruction of P.
>>>>
>>>> Obviously H never gets to emulate the final ret of P - because it
>>>> aborts the emulation before it gets there.  Duh!  Not seeing the
>>>> final ret /because you gave up and stopped emulating/ does not mean
>>>> the computation P(P) never halts, or that "never halts" is "the
>>>> correct answer" for H to return for input (P,P).  That's some
>>>> gibberish idea you've come up with in your confusion.
>>>>
>>>> If UTM emulates the P(P) computation, it will see all the EXACT SAME
>>>> config steps that H emulated, except that where H gave up due to
>>>> spotting some pattern, UTM carries on and sees the P(P) steps after
>>>> H gave up, INCLUDING THE FINAL RET OF P.
>>> The correct x86 emulation of the input to H(P,P) by H never reaches
>>> the "ret" instruction of P in 1 to ∞ emulated steps.
>>
>> No, H will abort it at whatever number of steps would abort that input.
>>
>> Remember, H is a FIXED algorithm (or needs to be to be a decider) and
>> thus has DEFINITE behavior for a given input.
>>
>> Your arguement isn't about a given H, but confounds the behavior of
>> different members of a whole class of them,
>
> Yes, that is how categorically exhaustive reasoning** works.
> ** Reasoning that cannot possibly have any gaps.

But it does have gaps.

>
> The alternative method that you suggest is to test each element of an
> infinite set one-at-a-time.

What infinite set.

H is supposed to be *A* Halt Decider.

You need to show that *IT* is correct.

>
>> each generating a DIFFERENT input, and thus not making an actual
>> arguement about any of the input.
>>
>
> The literal string of machine code bytes is the only actual input.

WRONG. That string of code does NOT define the behavior of the PROGRAM
P, because it doesn't define the contents of the memory at 000011A2

THAT is the "GAP" in your logic.

>
> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax      // push P
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx      // push P
> [0000135d](05)  e840feffff      call 000011a2 // call H
> [00001362](03)  83c408          add esp,+08
> [00001365](02)  85c0            test eax,eax
> [00001367](02)  7402            jz 0000136b
> [00001369](02)  ebfe            jmp 00001369
> [0000136b](01)  5d              pop ebp
> [0000136c](01)  c3              ret
> Size in bytes:(0027) [0000136c]
>
> H is defined to be at machine address 000011a2.

WHICH H? You said H is an infinite set of deciders. You have just
defined that No H can actually look at a P that does't use it.

Let us lable each of the members of that set H as Hi where i is the
number of steps that it will simulate its corresponding Pi before
aborting it.

First thing to note, as defined, your H's fail to be valid halt deciders
as it is impossible to give Hi the input Pj,Pj for j != i, so there are
inputs it BY YOUR DEFINITION can't answer. Let us fix that by making an
actual copy of the code of H (as Linz says to do) and include that in P,
and make that call go to that one, thus for the code above 000011a2 has
diffent contents for the different Pi's based on the value of i and will
always be the corresponding Hi.

On 5/29/2022 6:52 PM, Ben wrote:
> André G. Isaak <agisaak@gm.invalid> writes:
>
>> On 2022-05-29 15:16, olcott wrote:
>>> On 5/29/2022 4:00 PM, André G. Isaak wrote:
>>>> On 2022-05-29 14:35, olcott wrote:
>>>>> On 5/29/2022 2:58 PM, André G. Isaak wrote:
>>>>>> On 2022-05-29 13:26, olcott wrote:
>>>>>>
>>>>>>>> Agree.  I think PO probably can't understand the proper definition of halting.  That definition doesn't involve any UTMs or emulation
>>>>>>>> - it's just a mathematical definition, first of the computation steps, then of halting in terms of there being an n such that
>>>>>>>> computation step n is a final state of the TM.  That's TOO ABSTRACT for PO, so all he can do is replace it with something he
>>>>>>>> thinks he /can/ understand: something more concrete - a simulation run in some "actual machine" processing a TM description and tape
>>>>>>>> description!
>>>>>>>
>>>>>>> HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE WITH ME
>>>>>>> Every decider computes the mapping from its input finite string(s) to an accept or reject state based on a semantic or syntactic
>>>>>>> property of this finite string.
>>>>>>
>>>>>> Finite strings don't have semantic properties.
>>>>>
>>>>>
>>>>> In computability theory, Rice's theorem states that all non-trivial semantic properties of programs are undecidable.
>>>>
>>>> And how 'bout them Mets?
>>>>
>>>>> A semantic property is one about the program's behavior (for instance, does the program terminate for all inputs),
>>>>>
>>>>> https://en.wikipedia.org/wiki/Rice%27s_theorem
>>>>>
>>>>> In formal semantics this would be the semantic property of a finite string.
>>>>
>>>> No, it would be a semantic property of the program. That program might be *represented* as a string, but the string itself has no semantic
>>>> properties.
>>>>
>>> The semantic property of the string when it is interpreted as the
>>> description of a program.
>>
>> WHOOOSH!
>>
>> As soon you you add 'when it is interpreted as...' you are no longer
>> talking about the string but the thing which the string represents.
>
> One of the most frustrating things about talking to PO is that he drags
> the discussion down to his level. Precisely stated, Rice's theorem is
> not about strings or semantics. These terms just cover the discussion
> in a sort of intellectual molasses. Rice's theorem is about subsets of
> ℕ and partial recursive functions that enumerate them. It is sharp and
> precise and involves no questions of interpretation and semantics does
> not come into it. All of the wriggle and waffle room PO gives himself
> comes from operating at the level of "The Ladybird Book of
> Computability".
>
> I know you know this, but I can't help noticing how effectively PO's
> lack of knowledge and understanding ends up handicapping everyone else
> rather then him.
>

I prove that I am correct thus there is either some disconnect in the
relationship to the other proof or my reasoning can be adapted to the
other proof.

It is true that H(P,P)==0
It is true that P forms the required HP proof relationship to H.

void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
return;
}

Therefore it is true that I have refuted the HP proofs by making the
undecidable input decidable.

Halting problem undecidability and infinitely nested simulation (V5)
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer