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 2022-05-27 16:52, olcott wrote:
> On 5/27/2022 5:31 PM, André G. Isaak wrote:

>> There is no bijection (and bijections hold between things, not to
>> things). Every element of the function's domain can potentially be
>> encoded in an infinite number of different ways. And this has no
>> relevance to the particular confusion of yours that I was pointing out.
>>
>> André
>>
>>
>
> The simpler way around all this is to deduce that set of possible inputs
> to a TM halt decider is the set of Turing machine descriptions.

No, it is the set of Turing Machine descriptions concatenated with an
input string.

> This is fairly widely known as an aspect of the definition of a halt
> decider.

And <H^> <H^> is part of that set, and therefore is a legitimate input
to a halt decider.

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

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.

--
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 2022-05-27 17:26, olcott wrote:
> On 5/27/2022 6:18 PM, Richard Damon wrote:

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

Casual dialogue isn't a good model of how theoretical discussions work.
Things are often left implicit in casual discussions which one should
make explicit in theoretical or formal contexts.

The reason I am insisting that somethings which you think are obvious
should be made explicit is because you frequently conflate several
different thing. Being explicit is how to avoid doing this.

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

Instead of always coming up with ludicrous (and inept) analogies, I
recommend the following: If someone says something you think is
completely out to lunch, before giving a snide response first consider
whether they may be making a much more subtle or nuanced point than your
initial interpretation.

André

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

On 5/27/2022 6:30 PM, André G. Isaak wrote:
> On 2022-05-27 16:52, olcott wrote:
>> On 5/27/2022 5:31 PM, André G. Isaak wrote:
>
>>> There is no bijection (and bijections hold between things, not to
>>> things). Every element of the function's domain can potentially be
>>> encoded in an infinite number of different ways. And this has no
>>> relevance to the particular confusion of yours that I was pointing out.
>>>
>>> André
>>>
>>>
>>
>> The simpler way around all this is to deduce that set of possible
>> inputs to a TM halt decider is the set of Turing machine descriptions.
>
> No, it is the set of Turing Machine descriptions concatenated with an
> input string.
>
>> This is fairly widely known as an aspect of the definition of a halt
>> decider.
>
> And <H^> <H^> is part of that set, and therefore is a legitimate input
> to a halt decider.
>
>

I created the x86 operating system so that key details about the actual
execution trace of correct emulated input to H(P,P) can be established
as verified facts and not merely imagined to have behavior that they do
not actually have.

Once it is understand that H(P,P)==0 is true for the C function H
applied to the machine code of the C function P, then it becomes much
easier to see that this also applies to the Linz proof of H applied to
<H^> <H^>.

--
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:21 PM, olcott wrote:
> On 5/27/2022 6:11 PM, Richard Damon wrote:
>> On 5/27/22 6:52 PM, olcott wrote:
>>> On 5/27/2022 5:31 PM, André G. Isaak wrote:
>>>> On 2022-05-27 16:20, olcott wrote:
>>>>> On 5/27/2022 5:15 PM, André G. Isaak wrote:
>>>>>> On 2022-05-27 16:01, olcott wrote:
>>>>>>> On 5/27/2022 4:34 PM, André G. Isaak wrote:
>>>>>>>> On 2022-05-27 15:27, olcott wrote:
>>>>>>>>> On 5/27/2022 4:19 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-05-27 15:04, olcott wrote:
>>>>>>>>>>> On 5/27/2022 3:19 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2022-05-27 13:58, olcott wrote:
>>>>>>>>>>>>> On 5/27/2022 2:46 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 5/27/22 2:59 PM, olcott wrote:
>>>>>>>>>>>>>>> On 5/27/2022 1:45 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>> On 2022-05-27 12:37, Andy Walker wrote:
>>>>>>>>>>>>>>>>> On 27/05/2022 18:57, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>> The (positive) square root function you talk about
>>>>>>>>>>>>>>>>>> maps real numbers
>>>>>>>>>>>>>>>>>> (not scrambled eggs and not finite strings) to real
>>>>>>>>>>>>>>>>>> numbers (again,
>>>>>>>>>>>>>>>>>> not finite string). Unlike the prime() function,
>>>>>>>>>>>>>>>>>> however, the
>>>>>>>>>>>>>>>>>> positive square root function is NOT computable.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>      Um.  This is technically true, but [IMO]
>>>>>>>>>>>>>>>>> misleading. The reason
>>>>>>>>>>>>>>>>> for the failure is that most [indeed, almost all] real
>>>>>>>>>>>>>>>>> numbers are not
>>>>>>>>>>>>>>>>> computable.  But non-computable reals are of [almost]
>>>>>>>>>>>>>>>>> no interest for
>>>>>>>>>>>>>>>>> practical applied maths and theoretical physics, and
>>>>>>>>>>>>>>>>> are the sorts of
>>>>>>>>>>>>>>>>> object that give maths a bad name in the outside world.
>>>>>>>>>>>>>>>>> If "x" is a
>>>>>>>>>>>>>>>>> computable positive real, then "sqrt(x)" is also a
>>>>>>>>>>>>>>>>> computable real [eg
>>>>>>>>>>>>>>>>> by using Newton-Raphson], which is all you really have
>>>>>>>>>>>>>>>>> any right to
>>>>>>>>>>>>>>>>> expect.  If you can't compute "x", then what does it
>>>>>>>>>>>>>>>>> even mean to talk
>>>>>>>>>>>>>>>>> about its "sqrt"?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> All I was really trying to get Olcott to see was a case
>>>>>>>>>>>>>>>> where it really *isn't* possible to encode all elements
>>>>>>>>>>>>>>>> of the domain or codomain as finite strings, which is
>>>>>>>>>>>>>>>> rather different from his strange claim that
>>>>>>>>>>>>>>>> computations like P(P) cannot be encoded as finite strings.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Computations like P(P) can be encoded as finite string
>>>>>>>>>>>>>>> inputs to H1, they cannot be encoded as finite string
>>>>>>>>>>>>>>> inputs to H simply because the behavior specified by the
>>>>>>>>>>>>>>> correctly emulated input to H(P,P) is entirely different
>>>>>>>>>>>>>>> behavior than the correctly emulated input to H1(P,P).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We don't even need to understand why this is the case we
>>>>>>>>>>>>>>> only need to understand that it is a verified fact.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If P(P) can't be encoded to give to H, then H fails to be
>>>>>>>>>>>>>> a (Universal) Halt Decider from the begining, and can't be
>>>>>>>>>>>>>> a counter example.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Not at all. Halt deciders have sequences of configurations
>>>>>>>>>>>>> encoded as finite strings as the domain of their computable
>>>>>>>>>>>>> function.
>>>>>>>>>>>>
>>>>>>>>>>>> This is an entirely mangled sentence. You really need to go
>>>>>>>>>>>> back to the basics:
>>>>>>>>>>>>
>>>>>>>>>>>> First, a Turing Machine is *NOT* a computable function.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> A Turing machine would compute only the inputs to a its
>>>>>>>>>>> corresponding computable function that can be encoded as
>>>>>>>>>>> finite strings.
>>>>>>>>>>
>>>>>>>>>> Computable functions don't have inputs, they have domains. And
>>>>>>>>>> *all* of the elements in the domain of a computable function
>>>>>>>>>> can be encoded as finite string. Otherwise it wouldn't be a
>>>>>>>>>> computable function.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>       Computable functions are the basic objects of study in
>>>>>>>>> computability theory.
>>>>>>>>>       Computable functions are the formalized analogue of the
>>>>>>>>> intuitive notion of
>>>>>>>>>       algorithms, in the sense that a function is computable if
>>>>>>>>> there exists an algorithm
>>>>>>>>>       that can do the job of the function, i.e. given an input
>>>>>>>>> of the function domain it
>>>>>>>>>       can return the corresponding output.
>>>>>>>>>       https://en.wikipedia.org/wiki/Computable_function
>>>>>>>>> *I am going by the above*
>>>>>>>>
>>>>>>>> No. You're going by your *flawed* reading of the above. In the
>>>>>>>> above paragraph it is the algorithm which has an input,
>>>>>>>
>>>>>>> *input of the function domain*
>>>>>>
>>>>>> What that means is "input [to the algorithm] of [i.e. taken from]
>>>>>> the function domain".
>>>>> Thus mandating a bijection to finite strings.
>>>>
>>>> There is no bijection (and bijections hold between things, not to
>>>> things). Every element of the function's domain can potentially be
>>>> encoded in an infinite number of different ways. And this has no
>>>> relevance to the particular confusion of yours that I was pointing out.
>>>>
>>>> André
>>>>
>>>>
>>>
>>> The simpler way around all this is to deduce that set of possible
>>> inputs to a TM halt decider is the set of Turing machine descriptions.
>>>
>>> This is fairly widely known as an aspect of the definition of a halt
>>> decider.
>>>
>>
>> Right, so H can be given the description of ANY Turing Machine (even
>> H^) and an input for that, and needs to decide what that the Turing
>> Machine that input describes, applied to that input would do (Halt or
>> Not) and give the right answer to be correct.
>>
>
> The ultimate measure of the behavior of an input its its correct
> emulation. If the input to H(P,P) calls H(P,P) then P must actually call
> H(P,P). If the fact that the input calls H(P,P) makes its correct x86
> emulation never reach its "ret" instruction then this is the behavior
> that H must report.
>

On 5/27/22 7:57 PM, olcott wrote:
> On 5/27/2022 6:30 PM, André G. Isaak wrote:
>> On 2022-05-27 16:52, olcott wrote:
>>> On 5/27/2022 5:31 PM, André G. Isaak wrote:
>>
>>>> There is no bijection (and bijections hold between things, not to
>>>> things). Every element of the function's domain can potentially be
>>>> encoded in an infinite number of different ways. And this has no
>>>> relevance to the particular confusion of yours that I was pointing out.
>>>>
>>>> André
>>>>
>>>>
>>>
>>> The simpler way around all this is to deduce that set of possible
>>> inputs to a TM halt decider is the set of Turing machine descriptions.
>>
>> No, it is the set of Turing Machine descriptions concatenated with an
>> input string.
>>
>>> This is fairly widely known as an aspect of the definition of a halt
>>> decider.
>>
>> And <H^> <H^> is part of that set, and therefore is a legitimate input
>> to a halt decider.
>>
>>
>
> I created the x86 operating system so that key details about the actual
> execution trace of correct emulated input to H(P,P) can be established
> as verified facts and not merely imagined to have behavior that they do
> not actually have.

Except you haven't actually proved that it gives a CORRECT trace.

Since it has been pointed out that the trace does NOT match the actual
behavior of an x86 processor, you need to clarify what you terms
actually mean and show that it actually is correct.

Remember, the trace of a call instruction for a program running on an
x86 processor will be followed by the trace of the instruction at the
target of the call.

That doesn't happen in your code.

x86 does not have user/system code that is changed with just a call
instruction.

>
> Once it is understand that H(P,P)==0 is true for the C function H
> applied to the machine code of the C function P, then it becomes much
> easier to see that this also applies to the Linz proof of H applied to
> <H^> <H^>.
>

Once you can (if you can) actually show that, which you haven't.

That will be a key part of your proof, very much like proving the
statement of the Liar's Paradox is actually True.

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

On 2022-05-27 17:33, 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.

Again again you resort to a meaningless analogy... How exactly is this
supposed to clarify what *you* mean by specify? You clearly mean
something different from 'represent', but you refuse to say what.

On 5/27/22 9:40 PM, André G. Isaak wrote:

> And why is it that your silly analogies always involve things like
> boston cream pies, milkshakes, and other things which would no doubt
> appeal to someone with the mentality of a four year old?
>
> André
>
>

Because that accurately reflects his mental age?

On 2022-05-27 19:51, Richard Damon wrote:
>
> On 5/27/22 9:40 PM, André G. Isaak wrote:
>
>> And why is it that your silly analogies always involve things like
>> boston cream pies, milkshakes, and other things which would no doubt
>> appeal to someone with the mentality of a four year old?
>>
>> André
>>
>>
>
> Because that accurately reflects his mental age?

You're not supposed to say the quiet bit out loud!

André

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

On 5/27/22 10:02 PM, André G. Isaak wrote:
> On 2022-05-27 19:51, Richard Damon wrote:
>>
>> On 5/27/22 9:40 PM, André G. Isaak wrote:
>>
>>> And why is it that your silly analogies always involve things like
>>> boston cream pies, milkshakes, and other things which would no doubt
>>> appeal to someone with the mentality of a four year old?
>>>
>>> André
>>>
>>>
>>
>> Because that accurately reflects his mental age?
>
> You're not supposed to say the quiet bit out loud!
>
> André
>

But it also goes with throwing his tantrums and just yelling the same
thing over and over.

On Friday, 27 May 2022 at 23:15:25 UTC+1, André G. Isaak wrote:
> On 2022-05-27 16:01, olcott wrote:
> > On 5/27/2022 4:34 PM, André G. Isaak wrote:
> >> On 2022-05-27 15:27, olcott wrote:
> >>> On 5/27/2022 4:19 PM, André G. Isaak wrote:
> >>>> On 2022-05-27 15:04, olcott wrote:
> >>>>> On 5/27/2022 3:19 PM, André G. Isaak wrote:
> >>>>>> On 2022-05-27 13:58, olcott wrote:
> >>>>>>> On 5/27/2022 2:46 PM, Richard Damon wrote:
> >>>>>>>> On 5/27/22 2:59 PM, olcott wrote:
> >>>>>>>>> On 5/27/2022 1:45 PM, André G. Isaak wrote:
> >>>>>>>>>> On 2022-05-27 12:37, Andy Walker wrote:
> >>>>>>>>>>> On 27/05/2022 18:57, André G. Isaak wrote:
> >>>>>>>>>>>> The (positive) square root function you talk about maps real
> >>>>>>>>>>>> numbers
> >>>>>>>>>>>> (not scrambled eggs and not finite strings) to real numbers
> >>>>>>>>>>>> (again,
> >>>>>>>>>>>> not finite string). Unlike the prime() function, however, the
> >>>>>>>>>>>> positive square root function is NOT computable.
> >>>>>>>>>>>
> >>>>>>>>>>> Um. This is technically true, but [IMO] misleading.
> >>>>>>>>>>> The reason
> >>>>>>>>>>> for the failure is that most [indeed, almost all] real
> >>>>>>>>>>> numbers are not
> >>>>>>>>>>> computable. But non-computable reals are of [almost] no
> >>>>>>>>>>> interest for
> >>>>>>>>>>> practical applied maths and theoretical physics, and are the
> >>>>>>>>>>> sorts of
> >>>>>>>>>>> object that give maths a bad name in the outside world. If
> >>>>>>>>>>> "x" is a
> >>>>>>>>>>> computable positive real, then "sqrt(x)" is also a computable
> >>>>>>>>>>> real [eg
> >>>>>>>>>>> by using Newton-Raphson], which is all you really have any
> >>>>>>>>>>> right to
> >>>>>>>>>>> expect. If you can't compute "x", then what does it even
> >>>>>>>>>>> mean to talk
> >>>>>>>>>>> about its "sqrt"?
> >>>>>>>>>>
> >>>>>>>>>> All I was really trying to get Olcott to see was a case where
> >>>>>>>>>> it really *isn't* possible to encode all elements of the
> >>>>>>>>>> domain or codomain as finite strings, which is rather
> >>>>>>>>>> different from his strange claim that computations like P(P)
> >>>>>>>>>> cannot be encoded as finite strings.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Computations like P(P) can be encoded as finite string inputs
> >>>>>>>>> to H1, they cannot be encoded as finite string inputs to H
> >>>>>>>>> simply because the behavior specified by the correctly emulated
> >>>>>>>>> input to H(P,P) is entirely different behavior than the
> >>>>>>>>> correctly emulated input to H1(P,P).
> >>>>>>>>>
> >>>>>>>>> We don't even need to understand why this is the case we only
> >>>>>>>>> need to understand that it is a verified fact.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> If P(P) can't be encoded to give to H, then H fails to be a
> >>>>>>>> (Universal) Halt Decider from the begining, and can't be a
> >>>>>>>> counter example.
> >>>>>>>>
> >>>>>>>
> >>>>>>> Not at all. Halt deciders have sequences of configurations
> >>>>>>> encoded as finite strings as the domain of their computable
> >>>>>>> function.
> >>>>>>
> >>>>>> This is an entirely mangled sentence. You really need to go back
> >>>>>> to the basics:
> >>>>>>
> >>>>>> First, a Turing Machine is *NOT* a computable function.
> >>>>>>
> >>>>>
> >>>>> A Turing machine would compute only the inputs to a its
> >>>>> corresponding computable function that can be encoded as finite
> >>>>> strings.
> >>>>
> >>>> Computable functions don't have inputs, they have domains. And *all*
> >>>> of the elements in the domain of a computable function can be
> >>>> encoded as finite string. Otherwise it wouldn't be a computable
> >>>> function.
> >>>>
> >>>
> >>> Computable functions are the basic objects of study in
> >>> computability theory.
> >>> Computable functions are the formalized analogue of the
> >>> intuitive notion of
> >>> algorithms, in the sense that a function is computable if there
> >>> exists an algorithm
> >>> that can do the job of the function, i.e. given an input of the
> >>> function domain it
> >>> can return the corresponding output.
> >>> https://en.wikipedia.org/wiki/Computable_function
> >>> *I am going by the above*
> >>
> >> No. You're going by your *flawed* reading of the above. In the above
> >> paragraph it is the algorithm which has an input,
> >
> > *input of the function domain*
> What that means is "input [to the algorithm] of [i.e. taken from] the
> function domain".
> >> not the function. Any arbitrary element of the functions domain can be
> >> used as an input to the algorithm once suitably encoded.
> >>
> >
> > Sure and if it can't be suitably encoded it is excluded.
> But if there exist elements of the domain which cannot be suitably
> encoded then we aren't dealing with a computable function in the first
> place. By specifying that the function is computable it is implied that
> *every* element of the domain *can* be suitably encoded.
>
Let's say I specify that the domain of my function is a subset of C
programs. goto is banned. while loops are banned. for loops must
be of the form "for(i =0; i <N; i++)".

Now, unless I've nodded, I ought to be able to produce a very simple Turing
machine which solves the halting problem for this domain.

Note that H_Hat is banned bacause it contains a while loop in the "invert"
step.

Can we be a bit less stringent with the restrictions, to allow more functions
whilst still ruling out H_Hat and allied patterns?

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.

On 2022-05-28 08:41:42 +0000, Malcolm McLean said:

> Let's say I specify that the domain of my function is a subset of C
> programs. goto is banned. while loops are banned. for loops must
> be of the form "for(i =0; i <N; i++)".
>
> Now, unless I've nodded, I ought to be able to produce a very simple Turing
> machine which solves the halting problem for this domain.

You must also exclude directly and indirectly recursive functions.
In addition, the loop variable of a for loop must not be modified
in the loop and its address must not be given to a function that
does not promise to regard it as an address to a constant.

Mikko

On 28/05/2022 11:46, Mikko wrote:
> On 2022-05-28 08:41:42 +0000, Malcolm McLean said:
[... various restrictions ...]
>> Now, unless I've nodded, I ought to be able to produce a very simple Turing
>> machine which solves the halting problem for this domain.
> You must also exclude directly and indirectly recursive functions.
> In addition, the loop variable of a for loop must not be modified
> in the loop and its address must not be given to a function that
> does not promise to regard it as an address to a constant.

What the pair of you are saying is, in effect, that there is a
significant subset of programs which are guaranteed to halt, and for
which the HP is therefore trivial. Such programs even include many of
practical [eg engineering] interest. This is true, and uncontroversial.
There are also significant subsets of programs which are guaranteed not
to halt [at least in normal circumstances and short of hardware failure
or intervention]. But, no matter how you slice and dice, there is also
a substantial subset of programs whose behaviour cannot be determined
by an algorithmic examination of the code [inc input]; and the attack
on the HP via emulation and Busy Beavers shows clearly that a lot of
/very/ simple programs, and indeed problems, fall into this category.
[Not least because a UTM is a very simple program, and any complexity
relates to its input, which /could/ be a representation of a UTM and
/its/ input, which could be ....]

As ever, although the HP is expressed in terms of halting, it
equally applies to problems such as "Does my program ever reach line
23?", or "Does it ever produce any output?" or "Does it produce the
same output as your program?", which may be of more practical interest.
Yes, in line with what Malcolm is proposing, it's possible to produce
analysers, perhaps even of commercial interest, which often say useful
things about some code; but there are always areas of doubt, and
every time you explore one of these another can of worms opens up.

A partial answer for practical programming lies in disciplined
code, with carefully designed pre- and post-conditions, etc., etc. But
that doesn't help with programs written without that discipline, and it
doesn't help to solve the Goldbach Conjecture.

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

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.

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

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

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*

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

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