On Monday, May 30, 2022 at 8:56:49 AM UTC-4, olcott wrote:
> On 5/29/2022 11:04 PM, Dennis Bush wrote:
> > On Sunday, May 29, 2022 at 11:42:27 PM UTC-4, olcott wrote:
> >> On 5/29/2022 7:44 PM, Dennis Bush wrote:
> >>> On Sunday, May 29, 2022 at 8:33:53 PM UTC-4, olcott wrote:
> >>>> On 5/29/2022 6:24 PM, Mike Terry wrote:
> >>>>> On 29/05/2022 22:56, André G. Isaak wrote:
> >>>>>> On 2022-05-29 15:41, olcott wrote:
> >>>>>>> On 5/29/2022 4:30 PM, André G. Isaak wrote:
> >>>>>>>> On 2022-05-29 15:16, olcott wrote:
> >>>>>>>>> On 5/29/2022 4:00 PM, André G. Isaak wrote:
> >>>>>>>>>> On 2022-05-29 14:35, olcott wrote:
> >>>>>>>>>>> On 5/29/2022 2:58 PM, André G. Isaak wrote:
> >>>>>>>>>>>> On 2022-05-29 13:26, olcott wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>>> Agree. I think PO probably can't understand the proper
> >>>>>>>>>>>>>> definition of halting. That definition doesn't involve any
> >>>>>>>>>>>>>> UTMs or emulation - it's just a mathematical definition, first
> >>>>>>>>>>>>>> of the computation steps, then of halting in terms of there
> >>>>>>>>>>>>>> being an n such that computation step n is a final state of
> >>>>>>>>>>>>>> the TM. That's TOO ABSTRACT for PO, so all he can do is
> >>>>>>>>>>>>>> replace it with something he thinks he /can/ understand:
> >>>>>>>>>>>>>> something more concrete - a simulation run in some "actual
> >>>>>>>>>>>>>> machine" processing a TM description and tape description!
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE WITH ME
> >>>>>>>>>>>>> Every decider computes the mapping from its input finite
> >>>>>>>>>>>>> string(s) to an accept or reject state based on a semantic or
> >>>>>>>>>>>>> syntactic property of this finite string.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Finite strings don't have semantic properties.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> In computability theory, Rice's theorem states that all
> >>>>>>>>>>> non-trivial semantic properties of programs are undecidable.
> >>>>>>>>>>
> >>>>>>>>>> And how 'bout them Mets?
> >>>>>>>>>>
> >>>>>>>>>>> A semantic property is one about the program's behavior (for
> >>>>>>>>>>> instance, does the program terminate for all inputs),
> >>>>>>>>>>>
> >>>>>>>>>>> https://en.wikipedia.org/wiki/Rice%27s_theorem
> >>>>>>>>>>>
> >>>>>>>>>>> In formal semantics this would be the semantic property of a
> >>>>>>>>>>> finite string.
> >>>>>>>>>>
> >>>>>>>>>> No, it would be a semantic property of the program. That program
> >>>>>>>>>> might be *represented* as a string, but the string itself has no
> >>>>>>>>>> semantic properties.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> The semantic property of the string when it is interpreted as the
> >>>>>>>>> description of a program.
> >>>>>>>>
> >>>>>>>> WHOOOSH!
> >>>>>>>>
> >>>>>>>> As soon you you add 'when it is interpreted as...' you are no longer
> >>>>>>>> talking about the string but the thing which the string represents.
> >>>>>>>>
> >>>>>>>
> >>>>>>> Yes. The string has no semantics on its own.
> >>>>>>>
> >>>>>>> The input to H(P,P) determines (Mike's word) an execution trace of
> >>>>>>> x86 instructions when correctly emulated by H.
> >>>>>>>
> >>>>>>> The input to H1(P,P) determines (Mike's word) an execution trace of
> >>>>>>> x86 instructions when correctly emulated by H1.
> >>>>>>
> >>>>>> And neither of those sentences make any sense. Replacing 'specifies'
> >>>>>> with 'determines' doesn't make things any clearer. You need to
> >>>>>> actually DEFINE your terms.
> >>>>>>
> >>>>>>> These execution traces are not the same.
> >>>>>> Which means at least one of the above programs is *not* interpreting
> >>>>>> its input in the correct way, i.e. in the way which the specification
> >>>>>> of a halt decider demands.
> >>>>>
> >>>>> Hows about...
> >>>>>
> >>>>> Computation P(P) goes through a sequence of steps, which for
> >>>>> illustration I'll just refer to as <a> <b> ... <z> with <z> being the
> >>>>> final (RET) step where the computation halts. Now, H and H1 calculate
> >>>>> these steps ["emulate their input"] something like this:
> >>>>>
> >>>>> H1 H
> >>>>> ---- ----
> >>>>> <a> <a> // P(P) very first state!
> >>>>> <b> <b>
> >>>>> <c> <c>
> >>>>> <d> <d>
> >>>>> <e> <e>
> >>>>> <f> <f>
> >>>>> <g> <g>
> >>>>> <h> <h>
> >>>>> <i> <i>
> >>>>> <j> <j>
> >>>>> <k> <k>
> >>>>> <l> <l> // no divergence so far!
> >>>>> <m> <m>
> >>>>> <n> <n>
> >>>>> <o> <o>
> >>>>> <p> <p>
> >>>>> <q> <q>
> >>>>> <r> <r> // H spots some pattern and stops simulating
> >>>>> <s>
> >>>>> <t>
> >>>>> <u>
> >>>>> <v>
> >>>>> <w>
> >>>>> <x>
> >>>>> <y>
> >>>>> <z> // P(P) final state - it halts!
> >>>>>
> >>>>> So in PO language "the input to H(P,P)" is (P,P), and this determines
> >>>>> the steps of the computation P(P) which are being calculated by the
> >>>>> emulator in H, which calculates <a>...<r> then stops calculating because
> >>>>> it spotted some pattern. [in PO terms, <a>...<r> are the x86
> >>>>> instructions or their trace entries].
> >>>>>
> >>>>> "the input to H1(P,P)" is also (P,P), and this determines the steps of
> >>>>> the computation P(P) which are being calculated by the emulator in H1,
> >>>>> which calculates <a>...<r>...<z> then stops because final state [ret
> >>>>> instruction] is reached.
> >>>>>
> >>>>> PO might try to deny that H1 calculates the same steps as H from <a> to
> >>>>> <r>, or might agree. I don't think PO really understands what's
> >>>>> happening in his own program. :)
> >>>>>
> >>>>> In PO language, perhaps, BOTH the above are "correct emulations" because
> >>>>> the sequence of "x86 instruction transitions" <a> --> <b> etc. is
> >>>>> correct on a step-by-step basis. (That would be consistent with his
> >>>>> claim repeated 1000 times, that we can check the emulation is correct by
> >>>>> comparing the machine code listings and verifying that emulation is
> >>>>> [doing each instruction correctly].)
> >>>>>
> >>>>> H's decision to stop emulating is not (IMO) part of the emulation
> >>>>> itself. (How could it be? but probably that's just a matter of agreeing
> >>>>> the terms we're using.)
> >>>>>
> >>>>> Anyhow, he who would argue with PO would do well to pin PO down on his
> >>>>> strange choice of phrases to avoid weeks or months of
> >>>>> miscommunications. And you have to start by discovering /something/ you
> >>>>> agree on... Just demanding he "defines all his terms" won't get far as
> >>>>> he can't "define" anything properly. :)
> >>>>>
> >>>>>
> >>>>> Mike.
> >>>>>
> >>>> The input to H1(P,P) halts.
> >>>> In this same computation the input to H(P,P)
> >>>> would never reach its "ret" instruction in 1 to ∞ emulated steps.
> >>>
> >>> But the fixed algorithm of H, hereafter referred to as Ha and the P that call it referred to as Pa, does not simulate for an infinite number of steps. It simulates for a particular number of cycles.
> >> _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]
> >>
> >> H correctly simulates its input until it determines that a correct
> >> simulation of ∞ steps of this input would never reach the "ret"
> >> instruction of this input.
> >
> > By definition, a correct simulation is performed by a UTM. UTM(_Infinite_Loop,"") does not halt. UTM(Pa,Pa) does halt, so Ha(Pa,Pa)==0 is wrong.
> UTM(P,P) determines an execution trace of P that reaches its "ret"
> instruction. Yet this is a deliberately deceptive example and you know
> it. Here is an actual comparable example:

On 5/30/2022 8:11 AM, Mr Flibble wrote:
> On Sun, 29 May 2022 22:42:19 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 5/29/2022 7:44 PM, Dennis Bush wrote:
>>> On Sunday, May 29, 2022 at 8:33:53 PM UTC-4, olcott wrote:
>>>> On 5/29/2022 6:24 PM, Mike Terry wrote:
>>>>> On 29/05/2022 22:56, André G. Isaak wrote:
>>>>>> On 2022-05-29 15:41, olcott wrote:
>>>>>>> On 5/29/2022 4:30 PM, André G. Isaak wrote:
>>>>>>>> On 2022-05-29 15:16, olcott wrote:
>>>>>>>>> On 5/29/2022 4:00 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-05-29 14:35, olcott wrote:
>>>>>>>>>>> On 5/29/2022 2:58 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2022-05-29 13:26, olcott wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>> Agree. I think PO probably can't understand the proper
>>>>>>>>>>>>>> definition of halting. That definition doesn't involve
>>>>>>>>>>>>>> any UTMs or emulation - it's just a mathematical
>>>>>>>>>>>>>> definition, first of the computation steps, then of
>>>>>>>>>>>>>> halting in terms of there being an n such that
>>>>>>>>>>>>>> computation step n is a final state of the TM. That's
>>>>>>>>>>>>>> TOO ABSTRACT for PO, so all he can do is replace it with
>>>>>>>>>>>>>> something he thinks he /can/ understand: something more
>>>>>>>>>>>>>> concrete - a simulation run in some "actual machine"
>>>>>>>>>>>>>> processing a TM description and tape description!
>>>>>>>>>>>>>
>>>>>>>>>>>>> HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE WITH ME
>>>>>>>>>>>>> Every decider computes the mapping from its input finite
>>>>>>>>>>>>> string(s) to an accept or reject state based on a
>>>>>>>>>>>>> semantic or syntactic property of this finite string.
>>>>>>>>>>>>
>>>>>>>>>>>> Finite strings don't have semantic properties.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> In computability theory, Rice's theorem states that all
>>>>>>>>>>> non-trivial semantic properties of programs are
>>>>>>>>>>> undecidable.
>>>>>>>>>>
>>>>>>>>>> And how 'bout them Mets?
>>>>>>>>>>
>>>>>>>>>>> A semantic property is one about the program's behavior (for
>>>>>>>>>>> instance, does the program terminate for all inputs),
>>>>>>>>>>>
>>>>>>>>>>> https://en.wikipedia.org/wiki/Rice%27s_theorem
>>>>>>>>>>>
>>>>>>>>>>> In formal semantics this would be the semantic property of a
>>>>>>>>>>> finite string.
>>>>>>>>>>
>>>>>>>>>> No, it would be a semantic property of the program. That
>>>>>>>>>> program might be *represented* as a string, but the string
>>>>>>>>>> itself has no semantic properties.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The semantic property of the string when it is interpreted as
>>>>>>>>> the description of a program.
>>>>>>>>
>>>>>>>> WHOOOSH!
>>>>>>>>
>>>>>>>> As soon you you add 'when it is interpreted as...' you are no
>>>>>>>> longer talking about the string but the thing which the string
>>>>>>>> represents.
>>>>>>>
>>>>>>> Yes. The string has no semantics on its own.
>>>>>>>
>>>>>>> The input to H(P,P) determines (Mike's word) an execution trace
>>>>>>> of x86 instructions when correctly emulated by H.
>>>>>>>
>>>>>>> The input to H1(P,P) determines (Mike's word) an execution
>>>>>>> trace of x86 instructions when correctly emulated by H1.
>>>>>>
>>>>>> And neither of those sentences make any sense. Replacing
>>>>>> 'specifies' with 'determines' doesn't make things any clearer.
>>>>>> You need to actually DEFINE your terms.
>>>>>>
>>>>>>> These execution traces are not the same.
>>>>>> Which means at least one of the above programs is *not*
>>>>>> interpreting its input in the correct way, i.e. in the way which
>>>>>> the specification of a halt decider demands.
>>>>>
>>>>> Hows about...
>>>>>
>>>>> Computation P(P) goes through a sequence of steps, which for
>>>>> illustration I'll just refer to as <a> <b> ... <z> with <z> being
>>>>> the final (RET) step where the computation halts. Now, H and H1
>>>>> calculate these steps ["emulate their input"] something like this:
>>>>>
>>>>> H1 H
>>>>> ---- ----
>>>>> <a> <a> // P(P) very first state!
>>>>> <b> <b>
>>>>> <c> <c>
>>>>> <d> <d>
>>>>> <e> <e>
>>>>> <f> <f>
>>>>> <g> <g>
>>>>> <h> <h>
>>>>> <i> <i>
>>>>> <j> <j>
>>>>> <k> <k>
>>>>> <l> <l> // no divergence so far!
>>>>> <m> <m>
>>>>> <n> <n>
>>>>> <o> <o>
>>>>> <p> <p>
>>>>> <q> <q>
>>>>> <r> <r> // H spots some pattern and stops
>>>>> simulating <s>
>>>>> <t>
>>>>> <u>
>>>>> <v>
>>>>> <w>
>>>>> <x>
>>>>> <y>
>>>>> <z> // P(P) final state - it halts!
>>>>>
>>>>> So in PO language "the input to H(P,P)" is (P,P), and this
>>>>> determines the steps of the computation P(P) which are being
>>>>> calculated by the emulator in H, which calculates <a>...<r> then
>>>>> stops calculating because it spotted some pattern. [in PO terms,
>>>>> <a>...<r> are the x86 instructions or their trace entries].
>>>>>
>>>>> "the input to H1(P,P)" is also (P,P), and this determines the
>>>>> steps of the computation P(P) which are being calculated by the
>>>>> emulator in H1, which calculates <a>...<r>...<z> then stops
>>>>> because final state [ret instruction] is reached.
>>>>>
>>>>> PO might try to deny that H1 calculates the same steps as H from
>>>>> <a> to <r>, or might agree. I don't think PO really understands
>>>>> what's happening in his own program. :)
>>>>>
>>>>> In PO language, perhaps, BOTH the above are "correct emulations"
>>>>> because the sequence of "x86 instruction transitions" <a> --> <b>
>>>>> etc. is correct on a step-by-step basis. (That would be
>>>>> consistent with his claim repeated 1000 times, that we can check
>>>>> the emulation is correct by comparing the machine code listings
>>>>> and verifying that emulation is [doing each instruction
>>>>> correctly].)
>>>>>
>>>>> H's decision to stop emulating is not (IMO) part of the emulation
>>>>> itself. (How could it be? but probably that's just a matter of
>>>>> agreeing the terms we're using.)
>>>>>
>>>>> Anyhow, he who would argue with PO would do well to pin PO down
>>>>> on his strange choice of phrases to avoid weeks or months of
>>>>> miscommunications. And you have to start by discovering
>>>>> /something/ you agree on... Just demanding he "defines all his
>>>>> terms" won't get far as he can't "define" anything properly. :)
>>>>>
>>>>>
>>>>> Mike.
>>>>>
>>>> The input to H1(P,P) halts.
>>>> In this same computation the input to H(P,P)
>>>> would never reach its "ret" instruction in 1 to ∞ emulated steps.
>>>
>>> But the fixed algorithm of H, hereafter referred to as Ha and the P
>>> that call it referred to as Pa, does not simulate for an infinite
>>> number of steps. It simulates for a particular number of cycles.
>>>
>>
>> _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]
>>
>> H correctly simulates its input until it determines that a correct
>> simulation of ∞ steps of this input would never reach the "ret"
>> instruction of this input.
>>
>> Surely you are bright enough to tell that the above _Infinite_Loop()
>> would never reach its "ret" instruction?
>
> I thought the reason why it would never reach its "ret" instruction was
> due to an infinite recursion that you invented? Make your mind up.
>
> /Flibble
>

On Mon, 30 May 2022 08:17:03 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 5/30/2022 8:11 AM, Mr Flibble wrote:
> > On Sun, 29 May 2022 22:42:19 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 5/29/2022 7:44 PM, Dennis Bush wrote:
> >>> On Sunday, May 29, 2022 at 8:33:53 PM UTC-4, olcott wrote:
> >>>> On 5/29/2022 6:24 PM, Mike Terry wrote:
> >>>>> On 29/05/2022 22:56, André G. Isaak wrote:
> >>>>>> On 2022-05-29 15:41, olcott wrote:
> >>>>>>> On 5/29/2022 4:30 PM, André G. Isaak wrote:
> >>>>>>>> On 2022-05-29 15:16, olcott wrote:
> >>>>>>>>> On 5/29/2022 4:00 PM, André G. Isaak wrote:
> >>>>>>>>>> On 2022-05-29 14:35, olcott wrote:
> >>>>>>>>>>> On 5/29/2022 2:58 PM, André G. Isaak wrote:
> >>>>>>>>>>>> On 2022-05-29 13:26, olcott wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>>> Agree. I think PO probably can't understand the proper
> >>>>>>>>>>>>>> definition of halting. That definition doesn't involve
> >>>>>>>>>>>>>> any UTMs or emulation - it's just a mathematical
> >>>>>>>>>>>>>> definition, first of the computation steps, then of
> >>>>>>>>>>>>>> halting in terms of there being an n such that
> >>>>>>>>>>>>>> computation step n is a final state of the TM. That's
> >>>>>>>>>>>>>> TOO ABSTRACT for PO, so all he can do is replace it
> >>>>>>>>>>>>>> with something he thinks he /can/ understand:
> >>>>>>>>>>>>>> something more concrete - a simulation run in some
> >>>>>>>>>>>>>> "actual machine" processing a TM description and tape
> >>>>>>>>>>>>>> description!
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE WITH
> >>>>>>>>>>>>> ME Every decider computes the mapping from its input
> >>>>>>>>>>>>> finite string(s) to an accept or reject state based on a
> >>>>>>>>>>>>> semantic or syntactic property of this finite string.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Finite strings don't have semantic properties.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> In computability theory, Rice's theorem states that all
> >>>>>>>>>>> non-trivial semantic properties of programs are
> >>>>>>>>>>> undecidable.
> >>>>>>>>>>
> >>>>>>>>>> And how 'bout them Mets?
> >>>>>>>>>>
> >>>>>>>>>>> A semantic property is one about the program's behavior
> >>>>>>>>>>> (for instance, does the program terminate for all inputs),
> >>>>>>>>>>>
> >>>>>>>>>>> https://en.wikipedia.org/wiki/Rice%27s_theorem
> >>>>>>>>>>>
> >>>>>>>>>>> In formal semantics this would be the semantic property
> >>>>>>>>>>> of a finite string.
> >>>>>>>>>>
> >>>>>>>>>> No, it would be a semantic property of the program. That
> >>>>>>>>>> program might be *represented* as a string, but the string
> >>>>>>>>>> itself has no semantic properties.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> The semantic property of the string when it is interpreted
> >>>>>>>>> as the description of a program.
> >>>>>>>>
> >>>>>>>> WHOOOSH!
> >>>>>>>>
> >>>>>>>> As soon you you add 'when it is interpreted as...' you are no
> >>>>>>>> longer talking about the string but the thing which the
> >>>>>>>> string represents.
> >>>>>>>
> >>>>>>> Yes. The string has no semantics on its own.
> >>>>>>>
> >>>>>>> The input to H(P,P) determines (Mike's word) an execution
> >>>>>>> trace of x86 instructions when correctly emulated by H.
> >>>>>>>
> >>>>>>> The input to H1(P,P) determines (Mike's word) an execution
> >>>>>>> trace of x86 instructions when correctly emulated by H1.
> >>>>>>
> >>>>>> And neither of those sentences make any sense. Replacing
> >>>>>> 'specifies' with 'determines' doesn't make things any clearer.
> >>>>>> You need to actually DEFINE your terms.
> >>>>>>
> >>>>>>> These execution traces are not the same.
> >>>>>> Which means at least one of the above programs is *not*
> >>>>>> interpreting its input in the correct way, i.e. in the way
> >>>>>> which the specification of a halt decider demands.
> >>>>>
> >>>>> Hows about...
> >>>>>
> >>>>> Computation P(P) goes through a sequence of steps, which for
> >>>>> illustration I'll just refer to as <a> <b> ... <z> with <z>
> >>>>> being the final (RET) step where the computation halts. Now, H
> >>>>> and H1 calculate these steps ["emulate their input"] something
> >>>>> like this:
> >>>>>
> >>>>> H1 H
> >>>>> ---- ----
> >>>>> <a> <a> // P(P) very first state!
> >>>>> <b> <b>
> >>>>> <c> <c>
> >>>>> <d> <d>
> >>>>> <e> <e>
> >>>>> <f> <f>
> >>>>> <g> <g>
> >>>>> <h> <h>
> >>>>> <i> <i>
> >>>>> <j> <j>
> >>>>> <k> <k>
> >>>>> <l> <l> // no divergence so far!
> >>>>> <m> <m>
> >>>>> <n> <n>
> >>>>> <o> <o>
> >>>>> <p> <p>
> >>>>> <q> <q>
> >>>>> <r> <r> // H spots some pattern and stops
> >>>>> simulating <s>
> >>>>> <t>
> >>>>> <u>
> >>>>> <v>
> >>>>> <w>
> >>>>> <x>
> >>>>> <y>
> >>>>> <z> // P(P) final state - it halts!
> >>>>>
> >>>>> So in PO language "the input to H(P,P)" is (P,P), and this
> >>>>> determines the steps of the computation P(P) which are being
> >>>>> calculated by the emulator in H, which calculates <a>...<r> then
> >>>>> stops calculating because it spotted some pattern. [in PO
> >>>>> terms, <a>...<r> are the x86 instructions or their trace
> >>>>> entries].
> >>>>>
> >>>>> "the input to H1(P,P)" is also (P,P), and this determines the
> >>>>> steps of the computation P(P) which are being calculated by the
> >>>>> emulator in H1, which calculates <a>...<r>...<z> then stops
> >>>>> because final state [ret instruction] is reached.
> >>>>>
> >>>>> PO might try to deny that H1 calculates the same steps as H from
> >>>>> <a> to <r>, or might agree. I don't think PO really understands
> >>>>> what's happening in his own program. :)
> >>>>>
> >>>>> In PO language, perhaps, BOTH the above are "correct emulations"
> >>>>> because the sequence of "x86 instruction transitions" <a> -->
> >>>>> <b> etc. is correct on a step-by-step basis. (That would be
> >>>>> consistent with his claim repeated 1000 times, that we can check
> >>>>> the emulation is correct by comparing the machine code listings
> >>>>> and verifying that emulation is [doing each instruction
> >>>>> correctly].)
> >>>>>
> >>>>> H's decision to stop emulating is not (IMO) part of the
> >>>>> emulation itself. (How could it be? but probably that's just a
> >>>>> matter of agreeing the terms we're using.)
> >>>>>
> >>>>> Anyhow, he who would argue with PO would do well to pin PO down
> >>>>> on his strange choice of phrases to avoid weeks or months of
> >>>>> miscommunications. And you have to start by discovering
> >>>>> /something/ you agree on... Just demanding he "defines all his
> >>>>> terms" won't get far as he can't "define" anything properly. :)
> >>>>>
> >>>>>
> >>>>> Mike.
> >>>>>
> >>>> The input to H1(P,P) halts.
> >>>> In this same computation the input to H(P,P)
> >>>> would never reach its "ret" instruction in 1 to ∞ emulated
> >>>> steps.
> >>>
> >>> But the fixed algorithm of H, hereafter referred to as Ha and the
> >>> P that call it referred to as Pa, does not simulate for an
> >>> infinite number of steps. It simulates for a particular number
> >>> of cycles.
> >>
> >> _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]
> >>
> >> H correctly simulates its input until it determines that a correct
> >> simulation of ∞ steps of this input would never reach the "ret"
> >> instruction of this input.
> >>
> >> Surely you are bright enough to tell that the above
> >> _Infinite_Loop() would never reach its "ret" instruction?
> >
> > I thought the reason why it would never reach its "ret" instruction
> > was due to an infinite recursion that you invented? Make your mind
> > up.
> >
> > /Flibble
> >
>
> You have to actually look at what I say before responding. H is a
> general purpose halt determiner that can determine the correct halt
> status of many different inputs.
>
> This is an infinite loop:
> [000012c5](02) ebfe jmp 000012c5

On 5/30/22 8:56 AM, olcott wrote:
> On 5/29/2022 11:04 PM, Dennis Bush wrote:
>> On Sunday, May 29, 2022 at 11:42:27 PM UTC-4, olcott wrote:
>>> On 5/29/2022 7:44 PM, Dennis Bush wrote:
>>>> On Sunday, May 29, 2022 at 8:33:53 PM UTC-4, olcott wrote:
>>>>> On 5/29/2022 6:24 PM, Mike Terry wrote:
>>>>>> On 29/05/2022 22:56, André G. Isaak wrote:
>>>>>>> On 2022-05-29 15:41, olcott wrote:
>>>>>>>> On 5/29/2022 4:30 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-05-29 15:16, olcott wrote:
>>>>>>>>>> On 5/29/2022 4:00 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2022-05-29 14:35, olcott wrote:
>>>>>>>>>>>> On 5/29/2022 2:58 PM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2022-05-29 13:26, olcott wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Agree. I think PO probably can't understand the proper
>>>>>>>>>>>>>>> definition of halting. That definition doesn't involve any
>>>>>>>>>>>>>>> UTMs or emulation - it's just a mathematical definition,
>>>>>>>>>>>>>>> first
>>>>>>>>>>>>>>> of the computation steps, then of halting in terms of there
>>>>>>>>>>>>>>> being an n such that computation step n is a final state of
>>>>>>>>>>>>>>> the TM. That's TOO ABSTRACT for PO, so all he can do is
>>>>>>>>>>>>>>> replace it with something he thinks he /can/ understand:
>>>>>>>>>>>>>>> something more concrete - a simulation run in some "actual
>>>>>>>>>>>>>>> machine" processing a TM description and tape description!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE WITH ME
>>>>>>>>>>>>>> Every decider computes the mapping from its input finite
>>>>>>>>>>>>>> string(s) to an accept or reject state based on a semantic or
>>>>>>>>>>>>>> syntactic property of this finite string.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Finite strings don't have semantic properties.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> In computability theory, Rice's theorem states that all
>>>>>>>>>>>> non-trivial semantic properties of programs are undecidable.
>>>>>>>>>>>
>>>>>>>>>>> And how 'bout them Mets?
>>>>>>>>>>>
>>>>>>>>>>>> A semantic property is one about the program's behavior (for
>>>>>>>>>>>> instance, does the program terminate for all inputs),
>>>>>>>>>>>>
>>>>>>>>>>>> https://en.wikipedia.org/wiki/Rice%27s_theorem
>>>>>>>>>>>>
>>>>>>>>>>>> In formal semantics this would be the semantic property of a
>>>>>>>>>>>> finite string.
>>>>>>>>>>>
>>>>>>>>>>> No, it would be a semantic property of the program. That program
>>>>>>>>>>> might be *represented* as a string, but the string itself has no
>>>>>>>>>>> semantic properties.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The semantic property of the string when it is interpreted as the
>>>>>>>>>> description of a program.
>>>>>>>>>
>>>>>>>>> WHOOOSH!
>>>>>>>>>
>>>>>>>>> As soon you you add 'when it is interpreted as...' you are no
>>>>>>>>> longer
>>>>>>>>> talking about the string but the thing which the string
>>>>>>>>> represents.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes. The string has no semantics on its own.
>>>>>>>>
>>>>>>>> The input to H(P,P) determines (Mike's word) an execution trace of
>>>>>>>> x86 instructions when correctly emulated by H.
>>>>>>>>
>>>>>>>> The input to H1(P,P) determines (Mike's word) an execution trace of
>>>>>>>> x86 instructions when correctly emulated by H1.
>>>>>>>
>>>>>>> And neither of those sentences make any sense. Replacing 'specifies'
>>>>>>> with 'determines' doesn't make things any clearer. You need to
>>>>>>> actually DEFINE your terms.
>>>>>>>
>>>>>>>> These execution traces are not the same.
>>>>>>> Which means at least one of the above programs is *not* interpreting
>>>>>>> its input in the correct way, i.e. in the way which the
>>>>>>> specification
>>>>>>> of a halt decider demands.
>>>>>>
>>>>>> Hows about...
>>>>>>
>>>>>> Computation P(P) goes through a sequence of steps, which for
>>>>>> illustration I'll just refer to as <a> <b> ... <z> with <z> being the
>>>>>> final (RET) step where the computation halts. Now, H and H1 calculate
>>>>>> these steps ["emulate their input"] something like this:
>>>>>>
>>>>>> H1 H
>>>>>> ---- ----
>>>>>> <a> <a> // P(P) very first state!
>>>>>> <b> <b>
>>>>>> <c> <c>
>>>>>> <d> <d>
>>>>>> <e> <e>
>>>>>> <f> <f>
>>>>>> <g> <g>
>>>>>> <h> <h>
>>>>>> <i> <i>
>>>>>> <j> <j>
>>>>>> <k> <k>
>>>>>> <l> <l> // no divergence so far!
>>>>>> <m> <m>
>>>>>> <n> <n>
>>>>>> <o> <o>
>>>>>> <p> <p>
>>>>>> <q> <q>
>>>>>> <r> <r> // H spots some pattern and stops simulating
>>>>>> <s>
>>>>>> <t>
>>>>>> <u>
>>>>>> <v>
>>>>>> <w>
>>>>>> <x>
>>>>>> <y>
>>>>>> <z> // P(P) final state - it halts!
>>>>>>
>>>>>> So in PO language "the input to H(P,P)" is (P,P), and this determines
>>>>>> the steps of the computation P(P) which are being calculated by the
>>>>>> emulator in H, which calculates <a>...<r> then stops calculating
>>>>>> because
>>>>>> it spotted some pattern. [in PO terms, <a>...<r> are the x86
>>>>>> instructions or their trace entries].
>>>>>>
>>>>>> "the input to H1(P,P)" is also (P,P), and this determines the
>>>>>> steps of
>>>>>> the computation P(P) which are being calculated by the emulator in
>>>>>> H1,
>>>>>> which calculates <a>...<r>...<z> then stops because final state [ret
>>>>>> instruction] is reached.
>>>>>>
>>>>>> PO might try to deny that H1 calculates the same steps as H from
>>>>>> <a> to
>>>>>> <r>, or might agree. I don't think PO really understands what's
>>>>>> happening in his own program. :)
>>>>>>
>>>>>> In PO language, perhaps, BOTH the above are "correct emulations"
>>>>>> because
>>>>>> the sequence of "x86 instruction transitions" <a> --> <b> etc. is
>>>>>> correct on a step-by-step basis. (That would be consistent with his
>>>>>> claim repeated 1000 times, that we can check the emulation is
>>>>>> correct by
>>>>>> comparing the machine code listings and verifying that emulation is
>>>>>> [doing each instruction correctly].)
>>>>>>
>>>>>> H's decision to stop emulating is not (IMO) part of the emulation
>>>>>> itself. (How could it be? but probably that's just a matter of
>>>>>> agreeing
>>>>>> the terms we're using.)
>>>>>>
>>>>>> Anyhow, he who would argue with PO would do well to pin PO down on
>>>>>> his
>>>>>> strange choice of phrases to avoid weeks or months of
>>>>>> miscommunications. And you have to start by discovering
>>>>>> /something/ you
>>>>>> agree on... Just demanding he "defines all his terms" won't get
>>>>>> far as
>>>>>> he can't "define" anything properly. :)
>>>>>>
>>>>>>
>>>>>> Mike.
>>>>>>
>>>>> The input to H1(P,P) halts.
>>>>> In this same computation the input to H(P,P)
>>>>> would never reach its "ret" instruction in 1 to ∞ emulated steps.
>>>>
>>>> But the fixed algorithm of H, hereafter referred to as Ha and the P
>>>> that call it referred to as Pa, does not simulate for an infinite
>>>> number of steps. It simulates for a particular number of cycles.
>>> _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]
>>>
>>> H correctly simulates its input until it determines that a correct
>>> simulation of ∞ steps of this input would never reach the "ret"
>>> instruction of this input.
>>
>> By definition, a correct simulation is performed by a UTM.
>> UTM(_Infinite_Loop,"") does not halt.  UTM(Pa,Pa) does halt, so
>> Ha(Pa,Pa)==0 is wrong.
>
> UTM(P,P) determines an execution trace of P that reaches its "ret"
> instruction. Yet this is a deliberately deceptive example and you know
> it. Here is an actual comparable example:
>
> Emulate(P,P);
>
> void P(u32 x)
> {
>   if (Emulate(x, x))
>     HERE: goto HERE;
>   return;
> }
>

On 5/30/22 9:07 AM, olcott wrote:
> On 5/30/2022 7:56 AM, olcott wrote:
>> On 5/29/2022 11:04 PM, Dennis Bush wrote:
>>> On Sunday, May 29, 2022 at 11:42:27 PM UTC-4, olcott wrote:
>>>> On 5/29/2022 7:44 PM, Dennis Bush wrote:
>>>>> On Sunday, May 29, 2022 at 8:33:53 PM UTC-4, olcott wrote:
>>>>>> On 5/29/2022 6:24 PM, Mike Terry wrote:
>>>>>>> On 29/05/2022 22:56, André G. Isaak wrote:
>>>>>>>> On 2022-05-29 15:41, olcott wrote:
>>>>>>>>> On 5/29/2022 4:30 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-05-29 15:16, olcott wrote:
>>>>>>>>>>> On 5/29/2022 4:00 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2022-05-29 14:35, olcott wrote:
>>>>>>>>>>>>> On 5/29/2022 2:58 PM, André G. Isaak wrote:
>>>>>>>>>>>>>> On 2022-05-29 13:26, olcott wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Agree. I think PO probably can't understand the proper
>>>>>>>>>>>>>>>> definition of halting. That definition doesn't involve any
>>>>>>>>>>>>>>>> UTMs or emulation - it's just a mathematical definition,
>>>>>>>>>>>>>>>> first
>>>>>>>>>>>>>>>> of the computation steps, then of halting in terms of there
>>>>>>>>>>>>>>>> being an n such that computation step n is a final state of
>>>>>>>>>>>>>>>> the TM. That's TOO ABSTRACT for PO, so all he can do is
>>>>>>>>>>>>>>>> replace it with something he thinks he /can/ understand:
>>>>>>>>>>>>>>>> something more concrete - a simulation run in some "actual
>>>>>>>>>>>>>>>> machine" processing a TM description and tape description!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE WITH ME
>>>>>>>>>>>>>>> Every decider computes the mapping from its input finite
>>>>>>>>>>>>>>> string(s) to an accept or reject state based on a
>>>>>>>>>>>>>>> semantic or
>>>>>>>>>>>>>>> syntactic property of this finite string.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Finite strings don't have semantic properties.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> In computability theory, Rice's theorem states that all
>>>>>>>>>>>>> non-trivial semantic properties of programs are undecidable.
>>>>>>>>>>>>
>>>>>>>>>>>> And how 'bout them Mets?
>>>>>>>>>>>>
>>>>>>>>>>>>> A semantic property is one about the program's behavior (for
>>>>>>>>>>>>> instance, does the program terminate for all inputs),
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Rice%27s_theorem
>>>>>>>>>>>>>
>>>>>>>>>>>>> In formal semantics this would be the semantic property of a
>>>>>>>>>>>>> finite string.
>>>>>>>>>>>>
>>>>>>>>>>>> No, it would be a semantic property of the program. That
>>>>>>>>>>>> program
>>>>>>>>>>>> might be *represented* as a string, but the string itself
>>>>>>>>>>>> has no
>>>>>>>>>>>> semantic properties.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The semantic property of the string when it is interpreted as
>>>>>>>>>>> the
>>>>>>>>>>> description of a program.
>>>>>>>>>>
>>>>>>>>>> WHOOOSH!
>>>>>>>>>>
>>>>>>>>>> As soon you you add 'when it is interpreted as...' you are no
>>>>>>>>>> longer
>>>>>>>>>> talking about the string but the thing which the string
>>>>>>>>>> represents.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes. The string has no semantics on its own.
>>>>>>>>>
>>>>>>>>> The input to H(P,P) determines (Mike's word) an execution trace of
>>>>>>>>> x86 instructions when correctly emulated by H.
>>>>>>>>>
>>>>>>>>> The input to H1(P,P) determines (Mike's word) an execution
>>>>>>>>> trace of
>>>>>>>>> x86 instructions when correctly emulated by H1.
>>>>>>>>
>>>>>>>> And neither of those sentences make any sense. Replacing
>>>>>>>> 'specifies'
>>>>>>>> with 'determines' doesn't make things any clearer. You need to
>>>>>>>> actually DEFINE your terms.
>>>>>>>>
>>>>>>>>> These execution traces are not the same.
>>>>>>>> Which means at least one of the above programs is *not*
>>>>>>>> interpreting
>>>>>>>> its input in the correct way, i.e. in the way which the
>>>>>>>> specification
>>>>>>>> of a halt decider demands.
>>>>>>>
>>>>>>> Hows about...
>>>>>>>
>>>>>>> Computation P(P) goes through a sequence of steps, which for
>>>>>>> illustration I'll just refer to as <a> <b> ... <z> with <z> being
>>>>>>> the
>>>>>>> final (RET) step where the computation halts. Now, H and H1
>>>>>>> calculate
>>>>>>> these steps ["emulate their input"] something like this:
>>>>>>>
>>>>>>> H1 H
>>>>>>> ---- ----
>>>>>>> <a> <a> // P(P) very first state!
>>>>>>> <b> <b>
>>>>>>> <c> <c>
>>>>>>> <d> <d>
>>>>>>> <e> <e>
>>>>>>> <f> <f>
>>>>>>> <g> <g>
>>>>>>> <h> <h>
>>>>>>> <i> <i>
>>>>>>> <j> <j>
>>>>>>> <k> <k>
>>>>>>> <l> <l> // no divergence so far!
>>>>>>> <m> <m>
>>>>>>> <n> <n>
>>>>>>> <o> <o>
>>>>>>> <p> <p>
>>>>>>> <q> <q>
>>>>>>> <r> <r> // H spots some pattern and stops simulating
>>>>>>> <s>
>>>>>>> <t>
>>>>>>> <u>
>>>>>>> <v>
>>>>>>> <w>
>>>>>>> <x>
>>>>>>> <y>
>>>>>>> <z> // P(P) final state - it halts!
>>>>>>>
>>>>>>> So in PO language "the input to H(P,P)" is (P,P), and this
>>>>>>> determines
>>>>>>> the steps of the computation P(P) which are being calculated by the
>>>>>>> emulator in H, which calculates <a>...<r> then stops calculating
>>>>>>> because
>>>>>>> it spotted some pattern. [in PO terms, <a>...<r> are the x86
>>>>>>> instructions or their trace entries].
>>>>>>>
>>>>>>> "the input to H1(P,P)" is also (P,P), and this determines the
>>>>>>> steps of
>>>>>>> the computation P(P) which are being calculated by the emulator
>>>>>>> in H1,
>>>>>>> which calculates <a>...<r>...<z> then stops because final state [ret
>>>>>>> instruction] is reached.
>>>>>>>
>>>>>>> PO might try to deny that H1 calculates the same steps as H from
>>>>>>> <a> to
>>>>>>> <r>, or might agree. I don't think PO really understands what's
>>>>>>> happening in his own program. :)
>>>>>>>
>>>>>>> In PO language, perhaps, BOTH the above are "correct emulations"
>>>>>>> because
>>>>>>> the sequence of "x86 instruction transitions" <a> --> <b> etc. is
>>>>>>> correct on a step-by-step basis. (That would be consistent with his
>>>>>>> claim repeated 1000 times, that we can check the emulation is
>>>>>>> correct by
>>>>>>> comparing the machine code listings and verifying that emulation is
>>>>>>> [doing each instruction correctly].)
>>>>>>>
>>>>>>> H's decision to stop emulating is not (IMO) part of the emulation
>>>>>>> itself. (How could it be? but probably that's just a matter of
>>>>>>> agreeing
>>>>>>> the terms we're using.)
>>>>>>>
>>>>>>> Anyhow, he who would argue with PO would do well to pin PO down
>>>>>>> on his
>>>>>>> strange choice of phrases to avoid weeks or months of
>>>>>>> miscommunications. And you have to start by discovering
>>>>>>> /something/ you
>>>>>>> agree on... Just demanding he "defines all his terms" won't get
>>>>>>> far as
>>>>>>> he can't "define" anything properly. :)
>>>>>>>
>>>>>>>
>>>>>>> Mike.
>>>>>>>
>>>>>> The input to H1(P,P) halts.
>>>>>> In this same computation the input to H(P,P)
>>>>>> would never reach its "ret" instruction in 1 to ∞ emulated steps.
>>>>>
>>>>> But the fixed algorithm of H, hereafter referred to as Ha and the P
>>>>> that call it referred to as Pa, does not simulate for an infinite
>>>>> number of steps. It simulates for a particular number of cycles.
>>>> _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]
>>>>
>>>> H correctly simulates its input until it determines that a correct
>>>> simulation of ∞ steps of this input would never reach the "ret"
>>>> instruction of this input.
>>>
>>> By definition, a correct simulation is performed by a UTM.
>>> UTM(_Infinite_Loop,"") does not halt.  UTM(Pa,Pa) does halt, so
>>> Ha(Pa,Pa)==0 is wrong.
>>
>> UTM(P,P) determines an execution trace of P that reaches its "ret"
>> instruction. Yet this is a deliberately deceptive example and you know
>> it. Here is an actual comparable example:
>>
>> Emulate(P,P);
>>
>> void P(u32 x)
>> {
>>    if (Emulate(x, x))
>>      HERE: goto HERE;
>>    return;
>> }
>>
>>>
>>> Ha3 can also simulate _Infinite_Loop to correctly determine that it
>>> never halts, so the fact that Ha can do it means nothing.
>>
>>
>
> This would also apply to atheists:
> Revelation 21:8 King James Version
> ...all liars, shall have their part in the lake which burneth with fire
> and brimstone: which is the second death.
>

On 5/30/22 9:17 AM, olcott wrote:
> On 5/30/2022 8:11 AM, Mr Flibble wrote:
>> On Sun, 29 May 2022 22:42:19 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 5/29/2022 7:44 PM, Dennis Bush wrote:
>>>> On Sunday, May 29, 2022 at 8:33:53 PM UTC-4, olcott wrote:
>>>>> On 5/29/2022 6:24 PM, Mike Terry wrote:
>>>>>> On 29/05/2022 22:56, André G. Isaak wrote:
>>>>>>> On 2022-05-29 15:41, olcott wrote:
>>>>>>>> On 5/29/2022 4:30 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-05-29 15:16, olcott wrote:
>>>>>>>>>> On 5/29/2022 4:00 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2022-05-29 14:35, olcott wrote:
>>>>>>>>>>>> On 5/29/2022 2:58 PM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2022-05-29 13:26, olcott wrote:
>>>>>>>>>>>>>>> Agree.  I think PO probably can't understand the proper
>>>>>>>>>>>>>>> definition of halting.  That definition doesn't involve
>>>>>>>>>>>>>>> any UTMs or emulation - it's just a mathematical
>>>>>>>>>>>>>>> definition, first of the computation steps, then of
>>>>>>>>>>>>>>> halting in terms of there being an n such that
>>>>>>>>>>>>>>> computation step n is a final state of the TM.  That's
>>>>>>>>>>>>>>> TOO ABSTRACT for PO, so all he can do is replace it with
>>>>>>>>>>>>>>> something he thinks he /can/ understand: something more
>>>>>>>>>>>>>>> concrete - a simulation run in some "actual machine"
>>>>>>>>>>>>>>> processing a TM description and tape description!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE WITH ME
>>>>>>>>>>>>>> Every decider computes the mapping from its input finite
>>>>>>>>>>>>>> string(s) to an accept or reject state based on a
>>>>>>>>>>>>>> semantic or syntactic property of this finite string.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Finite strings don't have semantic properties.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> In computability theory, Rice's theorem states that all
>>>>>>>>>>>> non-trivial semantic properties of programs are
>>>>>>>>>>>> undecidable.
>>>>>>>>>>>
>>>>>>>>>>> And how 'bout them Mets?
>>>>>>>>>>>> A semantic property is one about the program's behavior (for
>>>>>>>>>>>> instance, does the program terminate for all inputs),
>>>>>>>>>>>>
>>>>>>>>>>>> https://en.wikipedia.org/wiki/Rice%27s_theorem
>>>>>>>>>>>>
>>>>>>>>>>>> In formal semantics this would be the semantic property of a
>>>>>>>>>>>> finite string.
>>>>>>>>>>>
>>>>>>>>>>> No, it would be a semantic property of the program. That
>>>>>>>>>>> program might be *represented* as a string, but the string
>>>>>>>>>>> itself has no semantic properties.
>>>>>>>>>>
>>>>>>>>>> The semantic property of the string when it is interpreted as
>>>>>>>>>> the description of a program.
>>>>>>>>>
>>>>>>>>> WHOOOSH!
>>>>>>>>>
>>>>>>>>> As soon you you add 'when it is interpreted as...' you are no
>>>>>>>>> longer talking about the string but the thing which the string
>>>>>>>>> represents.
>>>>>>>>
>>>>>>>> Yes. The string has no semantics on its own.
>>>>>>>>
>>>>>>>> The input to H(P,P) determines (Mike's word) an execution trace
>>>>>>>> of x86 instructions when correctly emulated by H.
>>>>>>>>
>>>>>>>> The input to H1(P,P) determines (Mike's word) an execution
>>>>>>>> trace of x86 instructions when correctly emulated by H1.
>>>>>>>
>>>>>>> And neither of those sentences make any sense. Replacing
>>>>>>> 'specifies' with 'determines' doesn't make things any clearer.
>>>>>>> You need to actually DEFINE your terms.
>>>>>>>> These execution traces are not the same.
>>>>>>> Which means at least one of the above programs is *not*
>>>>>>> interpreting its input in the correct way, i.e. in the way which
>>>>>>> the specification of a halt decider demands.
>>>>>>
>>>>>> Hows about...
>>>>>>
>>>>>>     Computation P(P) goes through a sequence of steps, which for
>>>>>> illustration I'll just refer to as <a> <b> ... <z> with <z> being
>>>>>> the final (RET) step where the computation halts.  Now, H and H1
>>>>>> calculate these steps ["emulate their input"] something like this:
>>>>>>
>>>>>>     H1          H
>>>>>>    ----        ----
>>>>>>     <a>         <a>      // P(P) very first state!
>>>>>>     <b>         <b>
>>>>>>     <c>         <c>
>>>>>>     <d>         <d>
>>>>>>     <e>         <e>
>>>>>>     <f>         <f>
>>>>>>     <g>         <g>
>>>>>>     <h>         <h>
>>>>>>     <i>         <i>
>>>>>>     <j>         <j>
>>>>>>     <k>         <k>
>>>>>>     <l>         <l>      // no divergence so far!
>>>>>>     <m>         <m>
>>>>>>     <n>         <n>
>>>>>>     <o>         <o>
>>>>>>     <p>         <p>
>>>>>>     <q>         <q>
>>>>>>     <r>         <r>      // H spots some pattern and stops
>>>>>> simulating <s>
>>>>>>     <t>
>>>>>>     <u>
>>>>>>     <v>
>>>>>>     <w>
>>>>>>     <x>
>>>>>>     <y>
>>>>>>     <z>                  // P(P) final state - it halts!
>>>>>>
>>>>>> So in PO language "the input to H(P,P)" is (P,P), and this
>>>>>> determines the steps of the computation P(P) which are being
>>>>>> calculated by the emulator in H, which calculates <a>...<r> then
>>>>>> stops calculating because it spotted some pattern.  [in PO terms,
>>>>>> <a>...<r> are the x86 instructions or their trace entries].
>>>>>>
>>>>>> "the input to H1(P,P)" is also (P,P), and this determines the
>>>>>> steps of the computation P(P) which are being calculated by the
>>>>>> emulator in H1, which calculates <a>...<r>...<z> then stops
>>>>>> because final state [ret instruction] is reached.
>>>>>>
>>>>>> PO might try to deny that H1 calculates the same steps as H from
>>>>>> <a> to <r>, or might agree.  I don't think PO really understands
>>>>>> what's happening in his own program.  :)
>>>>>>
>>>>>> In PO language, perhaps, BOTH the above are "correct emulations"
>>>>>> because the sequence of "x86 instruction transitions" <a> --> <b>
>>>>>> etc. is correct on a step-by-step basis.  (That would be
>>>>>> consistent with his claim repeated 1000 times, that we can check
>>>>>> the emulation is correct by comparing the machine code listings
>>>>>> and verifying that emulation is [doing each instruction
>>>>>> correctly].)
>>>>>>
>>>>>> H's decision to stop emulating is not (IMO) part of the emulation
>>>>>> itself.  (How could it be? but probably that's just a matter of
>>>>>> agreeing the terms we're using.)
>>>>>>
>>>>>> Anyhow, he who would argue with PO would do well to pin PO down
>>>>>> on his strange choice of phrases to avoid weeks or months of
>>>>>> miscommunications.  And you have to start by discovering
>>>>>> /something/ you agree on...  Just demanding he "defines all his
>>>>>> terms" won't get far as he can't "define" anything properly.  :)
>>>>>>
>>>>>>
>>>>>> Mike.
>>>>> The input to H1(P,P) halts.
>>>>> In this same computation the input to H(P,P)
>>>>> would never reach its "ret" instruction in 1 to ∞ emulated steps.
>>>>
>>>> But the fixed algorithm of H, hereafter referred to as Ha and the P
>>>> that call it referred to as Pa, does not simulate for an infinite
>>>> number of steps.  It simulates for a particular number of cycles.
>>>
>>> _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]
>>>
>>> H correctly simulates its input until it determines that a correct
>>> simulation of ∞ steps of this input would never reach the "ret"
>>> instruction of this input.
>>>
>>> Surely you are bright enough to tell that the above _Infinite_Loop()
>>> would never reach its "ret" instruction?
>>
>> I thought the reason why it would never reach its "ret" instruction was
>> due to an infinite recursion that you invented? Make your mind up.
>>
>> /Flibble
>>
>
> You have to actually look at what I say before responding. H is a
> general purpose halt determiner that can determine the correct halt
> status of many different inputs.
>
> This is an infinite loop:
> [000012c5](02)  ebfe            jmp 000012c5
>
>

On 5/30/2022 8:14 AM, Dennis Bush wrote:
> On Monday, May 30, 2022 at 8:56:49 AM UTC-4, olcott wrote:
>> On 5/29/2022 11:04 PM, Dennis Bush wrote:
>>> On Sunday, May 29, 2022 at 11:42:27 PM UTC-4, olcott wrote:
>>>> On 5/29/2022 7:44 PM, Dennis Bush wrote:
>>>>> On Sunday, May 29, 2022 at 8:33:53 PM UTC-4, olcott wrote:
>>>>>> On 5/29/2022 6:24 PM, Mike Terry wrote:
>>>>>>> On 29/05/2022 22:56, André G. Isaak wrote:
>>>>>>>> On 2022-05-29 15:41, olcott wrote:
>>>>>>>>> On 5/29/2022 4:30 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-05-29 15:16, olcott wrote:
>>>>>>>>>>> On 5/29/2022 4:00 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2022-05-29 14:35, olcott wrote:
>>>>>>>>>>>>> On 5/29/2022 2:58 PM, André G. Isaak wrote:
>>>>>>>>>>>>>> On 2022-05-29 13:26, olcott wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Agree. I think PO probably can't understand the proper
>>>>>>>>>>>>>>>> definition of halting. That definition doesn't involve any
>>>>>>>>>>>>>>>> UTMs or emulation - it's just a mathematical definition, first
>>>>>>>>>>>>>>>> of the computation steps, then of halting in terms of there
>>>>>>>>>>>>>>>> being an n such that computation step n is a final state of
>>>>>>>>>>>>>>>> the TM. That's TOO ABSTRACT for PO, so all he can do is
>>>>>>>>>>>>>>>> replace it with something he thinks he /can/ understand:
>>>>>>>>>>>>>>>> something more concrete - a simulation run in some "actual
>>>>>>>>>>>>>>>> machine" processing a TM description and tape description!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE WITH ME
>>>>>>>>>>>>>>> Every decider computes the mapping from its input finite
>>>>>>>>>>>>>>> string(s) to an accept or reject state based on a semantic or
>>>>>>>>>>>>>>> syntactic property of this finite string.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Finite strings don't have semantic properties.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> In computability theory, Rice's theorem states that all
>>>>>>>>>>>>> non-trivial semantic properties of programs are undecidable.
>>>>>>>>>>>>
>>>>>>>>>>>> And how 'bout them Mets?
>>>>>>>>>>>>
>>>>>>>>>>>>> A semantic property is one about the program's behavior (for
>>>>>>>>>>>>> instance, does the program terminate for all inputs),
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Rice%27s_theorem
>>>>>>>>>>>>>
>>>>>>>>>>>>> In formal semantics this would be the semantic property of a
>>>>>>>>>>>>> finite string.
>>>>>>>>>>>>
>>>>>>>>>>>> No, it would be a semantic property of the program. That program
>>>>>>>>>>>> might be *represented* as a string, but the string itself has no
>>>>>>>>>>>> semantic properties.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The semantic property of the string when it is interpreted as the
>>>>>>>>>>> description of a program.
>>>>>>>>>>
>>>>>>>>>> WHOOOSH!
>>>>>>>>>>
>>>>>>>>>> As soon you you add 'when it is interpreted as...' you are no longer
>>>>>>>>>> talking about the string but the thing which the string represents.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes. The string has no semantics on its own.
>>>>>>>>>
>>>>>>>>> The input to H(P,P) determines (Mike's word) an execution trace of
>>>>>>>>> x86 instructions when correctly emulated by H.
>>>>>>>>>
>>>>>>>>> The input to H1(P,P) determines (Mike's word) an execution trace of
>>>>>>>>> x86 instructions when correctly emulated by H1.
>>>>>>>>
>>>>>>>> And neither of those sentences make any sense. Replacing 'specifies'
>>>>>>>> with 'determines' doesn't make things any clearer. You need to
>>>>>>>> actually DEFINE your terms.
>>>>>>>>
>>>>>>>>> These execution traces are not the same.
>>>>>>>> Which means at least one of the above programs is *not* interpreting
>>>>>>>> its input in the correct way, i.e. in the way which the specification
>>>>>>>> of a halt decider demands.
>>>>>>>
>>>>>>> Hows about...
>>>>>>>
>>>>>>> Computation P(P) goes through a sequence of steps, which for
>>>>>>> illustration I'll just refer to as <a> <b> ... <z> with <z> being the
>>>>>>> final (RET) step where the computation halts. Now, H and H1 calculate
>>>>>>> these steps ["emulate their input"] something like this:
>>>>>>>
>>>>>>> H1 H
>>>>>>> ---- ----
>>>>>>> <a> <a> // P(P) very first state!
>>>>>>> <b> <b>
>>>>>>> <c> <c>
>>>>>>> <d> <d>
>>>>>>> <e> <e>
>>>>>>> <f> <f>
>>>>>>> <g> <g>
>>>>>>> <h> <h>
>>>>>>> <i> <i>
>>>>>>> <j> <j>
>>>>>>> <k> <k>
>>>>>>> <l> <l> // no divergence so far!
>>>>>>> <m> <m>
>>>>>>> <n> <n>
>>>>>>> <o> <o>
>>>>>>> <p> <p>
>>>>>>> <q> <q>
>>>>>>> <r> <r> // H spots some pattern and stops simulating
>>>>>>> <s>
>>>>>>> <t>
>>>>>>> <u>
>>>>>>> <v>
>>>>>>> <w>
>>>>>>> <x>
>>>>>>> <y>
>>>>>>> <z> // P(P) final state - it halts!
>>>>>>>
>>>>>>> So in PO language "the input to H(P,P)" is (P,P), and this determines
>>>>>>> the steps of the computation P(P) which are being calculated by the
>>>>>>> emulator in H, which calculates <a>...<r> then stops calculating because
>>>>>>> it spotted some pattern. [in PO terms, <a>...<r> are the x86
>>>>>>> instructions or their trace entries].
>>>>>>>
>>>>>>> "the input to H1(P,P)" is also (P,P), and this determines the steps of
>>>>>>> the computation P(P) which are being calculated by the emulator in H1,
>>>>>>> which calculates <a>...<r>...<z> then stops because final state [ret
>>>>>>> instruction] is reached.
>>>>>>>
>>>>>>> PO might try to deny that H1 calculates the same steps as H from <a> to
>>>>>>> <r>, or might agree. I don't think PO really understands what's
>>>>>>> happening in his own program. :)
>>>>>>>
>>>>>>> In PO language, perhaps, BOTH the above are "correct emulations" because
>>>>>>> the sequence of "x86 instruction transitions" <a> --> <b> etc. is
>>>>>>> correct on a step-by-step basis. (That would be consistent with his
>>>>>>> claim repeated 1000 times, that we can check the emulation is correct by
>>>>>>> comparing the machine code listings and verifying that emulation is
>>>>>>> [doing each instruction correctly].)
>>>>>>>
>>>>>>> H's decision to stop emulating is not (IMO) part of the emulation
>>>>>>> itself. (How could it be? but probably that's just a matter of agreeing
>>>>>>> the terms we're using.)
>>>>>>>
>>>>>>> Anyhow, he who would argue with PO would do well to pin PO down on his
>>>>>>> strange choice of phrases to avoid weeks or months of
>>>>>>> miscommunications. And you have to start by discovering /something/ you
>>>>>>> agree on... Just demanding he "defines all his terms" won't get far as
>>>>>>> he can't "define" anything properly. :)
>>>>>>>
>>>>>>>
>>>>>>> Mike.
>>>>>>>
>>>>>> The input to H1(P,P) halts.
>>>>>> In this same computation the input to H(P,P)
>>>>>> would never reach its "ret" instruction in 1 to ∞ emulated steps.
>>>>>
>>>>> But the fixed algorithm of H, hereafter referred to as Ha and the P that call it referred to as Pa, does not simulate for an infinite number of steps. It simulates for a particular number of cycles.
>>>> _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]
>>>>
>>>> H correctly simulates its input until it determines that a correct
>>>> simulation of ∞ steps of this input would never reach the "ret"
>>>> instruction of this input.
>>>
>>> By definition, a correct simulation is performed by a UTM. UTM(_Infinite_Loop,"") does not halt. UTM(Pa,Pa) does halt, so Ha(Pa,Pa)==0 is wrong.
>> UTM(P,P) determines an execution trace of P that reaches its "ret"
>> instruction. Yet this is a deliberately deceptive example and you know
>> it. Here is an actual comparable example:
>
> It is not deceptive. It is the *definition* of a correct simulation.
>
>>
>> Emulate(P,P);
>>
>> void P(u32 x)
>> {
>> if (Emulate(x, x))
>> HERE: goto HERE;
>> return;
>> }
>
>
> What you call Emulate is Hn,

On Mon, 30 May 2022 08:46:48 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 5/30/2022 8:14 AM, Dennis Bush wrote:
> > On Monday, May 30, 2022 at 8:56:49 AM UTC-4, olcott wrote:
> >> On 5/29/2022 11:04 PM, Dennis Bush wrote:
> >>> On Sunday, May 29, 2022 at 11:42:27 PM UTC-4, olcott wrote:
> >>>> On 5/29/2022 7:44 PM, Dennis Bush wrote:
> >>>>> On Sunday, May 29, 2022 at 8:33:53 PM UTC-4, olcott wrote:
> >>>>>> On 5/29/2022 6:24 PM, Mike Terry wrote:
> >>>>>>> On 29/05/2022 22:56, André G. Isaak wrote:
> >>>>>>>> On 2022-05-29 15:41, olcott wrote:
> >>>>>>>>> On 5/29/2022 4:30 PM, André G. Isaak wrote:
> >>>>>>>>>> On 2022-05-29 15:16, olcott wrote:
> >>>>>>>>>>> On 5/29/2022 4:00 PM, André G. Isaak wrote:
> >>>>>>>>>>>> On 2022-05-29 14:35, olcott wrote:
> >>>>>>>>>>>>> On 5/29/2022 2:58 PM, André G. Isaak wrote:
> >>>>>>>>>>>>>> On 2022-05-29 13:26, olcott wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Agree. I think PO probably can't understand the
> >>>>>>>>>>>>>>>> proper definition of halting. That definition
> >>>>>>>>>>>>>>>> doesn't involve any UTMs or emulation - it's just a
> >>>>>>>>>>>>>>>> mathematical definition, first of the computation
> >>>>>>>>>>>>>>>> steps, then of halting in terms of there being an n
> >>>>>>>>>>>>>>>> such that computation step n is a final state of the
> >>>>>>>>>>>>>>>> TM. That's TOO ABSTRACT for PO, so all he can do is
> >>>>>>>>>>>>>>>> replace it with something he thinks he /can/
> >>>>>>>>>>>>>>>> understand: something more concrete - a simulation
> >>>>>>>>>>>>>>>> run in some "actual machine" processing a TM
> >>>>>>>>>>>>>>>> description and tape description!
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE
> >>>>>>>>>>>>>>> WITH ME Every decider computes the mapping from its
> >>>>>>>>>>>>>>> input finite string(s) to an accept or reject state
> >>>>>>>>>>>>>>> based on a semantic or syntactic property of this
> >>>>>>>>>>>>>>> finite string.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Finite strings don't have semantic properties.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> In computability theory, Rice's theorem states that all
> >>>>>>>>>>>>> non-trivial semantic properties of programs are
> >>>>>>>>>>>>> undecidable.
> >>>>>>>>>>>>
> >>>>>>>>>>>> And how 'bout them Mets?
> >>>>>>>>>>>>
> >>>>>>>>>>>>> A semantic property is one about the program's behavior
> >>>>>>>>>>>>> (for instance, does the program terminate for all
> >>>>>>>>>>>>> inputs),
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> https://en.wikipedia.org/wiki/Rice%27s_theorem
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> In formal semantics this would be the semantic property
> >>>>>>>>>>>>> of a finite string.
> >>>>>>>>>>>>
> >>>>>>>>>>>> No, it would be a semantic property of the program. That
> >>>>>>>>>>>> program might be *represented* as a string, but the
> >>>>>>>>>>>> string itself has no semantic properties.
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> The semantic property of the string when it is
> >>>>>>>>>>> interpreted as the description of a program.
> >>>>>>>>>>
> >>>>>>>>>> WHOOOSH!
> >>>>>>>>>>
> >>>>>>>>>> As soon you you add 'when it is interpreted as...' you are
> >>>>>>>>>> no longer talking about the string but the thing which the
> >>>>>>>>>> string represents.
> >>>>>>>>>
> >>>>>>>>> Yes. The string has no semantics on its own.
> >>>>>>>>>
> >>>>>>>>> The input to H(P,P) determines (Mike's word) an execution
> >>>>>>>>> trace of x86 instructions when correctly emulated by H.
> >>>>>>>>>
> >>>>>>>>> The input to H1(P,P) determines (Mike's word) an execution
> >>>>>>>>> trace of x86 instructions when correctly emulated by H1.
> >>>>>>>>
> >>>>>>>> And neither of those sentences make any sense. Replacing
> >>>>>>>> 'specifies' with 'determines' doesn't make things any
> >>>>>>>> clearer. You need to actually DEFINE your terms.
> >>>>>>>>
> >>>>>>>>> These execution traces are not the same.
> >>>>>>>> Which means at least one of the above programs is *not*
> >>>>>>>> interpreting its input in the correct way, i.e. in the way
> >>>>>>>> which the specification of a halt decider demands.
> >>>>>>>
> >>>>>>> Hows about...
> >>>>>>>
> >>>>>>> Computation P(P) goes through a sequence of steps, which for
> >>>>>>> illustration I'll just refer to as <a> <b> ... <z> with <z>
> >>>>>>> being the final (RET) step where the computation halts. Now,
> >>>>>>> H and H1 calculate these steps ["emulate their input"]
> >>>>>>> something like this:
> >>>>>>>
> >>>>>>> H1 H
> >>>>>>> ---- ----
> >>>>>>> <a> <a> // P(P) very first state!
> >>>>>>> <b> <b>
> >>>>>>> <c> <c>
> >>>>>>> <d> <d>
> >>>>>>> <e> <e>
> >>>>>>> <f> <f>
> >>>>>>> <g> <g>
> >>>>>>> <h> <h>
> >>>>>>> <i> <i>
> >>>>>>> <j> <j>
> >>>>>>> <k> <k>
> >>>>>>> <l> <l> // no divergence so far!
> >>>>>>> <m> <m>
> >>>>>>> <n> <n>
> >>>>>>> <o> <o>
> >>>>>>> <p> <p>
> >>>>>>> <q> <q>
> >>>>>>> <r> <r> // H spots some pattern and stops simulating
> >>>>>>> <s>
> >>>>>>> <t>
> >>>>>>> <u>
> >>>>>>> <v>
> >>>>>>> <w>
> >>>>>>> <x>
> >>>>>>> <y>
> >>>>>>> <z> // P(P) final state - it halts!
> >>>>>>>
> >>>>>>> So in PO language "the input to H(P,P)" is (P,P), and this
> >>>>>>> determines the steps of the computation P(P) which are being
> >>>>>>> calculated by the emulator in H, which calculates <a>...<r>
> >>>>>>> then stops calculating because it spotted some pattern. [in
> >>>>>>> PO terms, <a>...<r> are the x86 instructions or their trace
> >>>>>>> entries].
> >>>>>>>
> >>>>>>> "the input to H1(P,P)" is also (P,P), and this determines the
> >>>>>>> steps of the computation P(P) which are being calculated by
> >>>>>>> the emulator in H1, which calculates <a>...<r>...<z> then
> >>>>>>> stops because final state [ret instruction] is reached.
> >>>>>>>
> >>>>>>> PO might try to deny that H1 calculates the same steps as H
> >>>>>>> from <a> to <r>, or might agree. I don't think PO really
> >>>>>>> understands what's happening in his own program. :)
> >>>>>>>
> >>>>>>> In PO language, perhaps, BOTH the above are "correct
> >>>>>>> emulations" because the sequence of "x86 instruction
> >>>>>>> transitions" <a> --> <b> etc. is correct on a step-by-step
> >>>>>>> basis. (That would be consistent with his claim repeated 1000
> >>>>>>> times, that we can check the emulation is correct by
> >>>>>>> comparing the machine code listings and verifying that
> >>>>>>> emulation is [doing each instruction correctly].)
> >>>>>>>
> >>>>>>> H's decision to stop emulating is not (IMO) part of the
> >>>>>>> emulation itself. (How could it be? but probably that's just
> >>>>>>> a matter of agreeing the terms we're using.)
> >>>>>>>
> >>>>>>> Anyhow, he who would argue with PO would do well to pin PO
> >>>>>>> down on his strange choice of phrases to avoid weeks or
> >>>>>>> months of miscommunications. And you have to start by
> >>>>>>> discovering /something/ you agree on... Just demanding he
> >>>>>>> "defines all his terms" won't get far as he can't "define"
> >>>>>>> anything properly. :)
> >>>>>>>
> >>>>>>>
> >>>>>>> Mike.
> >>>>>>>
> >>>>>> The input to H1(P,P) halts.
> >>>>>> In this same computation the input to H(P,P)
> >>>>>> would never reach its "ret" instruction in 1 to ∞ emulated
> >>>>>> steps.
> >>>>>
> >>>>> But the fixed algorithm of H, hereafter referred to as Ha and
> >>>>> the P that call it referred to as Pa, does not simulate for an
> >>>>> infinite number of steps. It simulates for a particular number
> >>>>> of cycles.
> >>>> _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]
> >>>>
> >>>> H correctly simulates its input until it determines that a
> >>>> correct simulation of ∞ steps of this input would never reach
> >>>> the "ret" instruction of this input.
> >>>
> >>> By definition, a correct simulation is performed by a UTM.
> >>> UTM(_Infinite_Loop,"") does not halt. UTM(Pa,Pa) does halt, so
> >>> Ha(Pa,Pa)==0 is wrong.
> >> UTM(P,P) determines an execution trace of P that reaches its "ret"
> >> instruction. Yet this is a deliberately deceptive example and you
> >> know it. Here is an actual comparable example:
> >
> > It is not deceptive. It is the *definition* of a correct
> > simulation.
> >>
> >> Emulate(P,P);
> >>
> >> void P(u32 x)
> >> {
> >> if (Emulate(x, x))
> >> HERE: goto HERE;
> >> return;
> >> }
> >
> >
> > What you call Emulate is Hn,
>
> No I would not because the H means halt decider.
>
> > and because of that, P is Pn. And Pn(Pn) does not halt, nor does
> > Hn(Pn,Pn).
> >
> > So you're claiming that Ha(Pa,Pa)==0 is correct because Pn(Pn) does
> > not halt.
>
> When-so-ever any input to a simulating halt decider must have its
> simulation aborted to prevent the infinite simulation of this input
> this input is correctly determined to be a non-halting input.

On 5/30/2022 8:20 AM, Mr Flibble wrote:
> On Mon, 30 May 2022 08:17:03 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 5/30/2022 8:11 AM, Mr Flibble wrote:
>>> On Sun, 29 May 2022 22:42:19 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 5/29/2022 7:44 PM, Dennis Bush wrote:
>>>>> On Sunday, May 29, 2022 at 8:33:53 PM UTC-4, olcott wrote:
>>>>>> On 5/29/2022 6:24 PM, Mike Terry wrote:
>>>>>>> On 29/05/2022 22:56, André G. Isaak wrote:
>>>>>>>> On 2022-05-29 15:41, olcott wrote:
>>>>>>>>> On 5/29/2022 4:30 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-05-29 15:16, olcott wrote:
>>>>>>>>>>> On 5/29/2022 4:00 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2022-05-29 14:35, olcott wrote:
>>>>>>>>>>>>> On 5/29/2022 2:58 PM, André G. Isaak wrote:
>>>>>>>>>>>>>> On 2022-05-29 13:26, olcott wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Agree. I think PO probably can't understand the proper
>>>>>>>>>>>>>>>> definition of halting. That definition doesn't involve
>>>>>>>>>>>>>>>> any UTMs or emulation - it's just a mathematical
>>>>>>>>>>>>>>>> definition, first of the computation steps, then of
>>>>>>>>>>>>>>>> halting in terms of there being an n such that
>>>>>>>>>>>>>>>> computation step n is a final state of the TM. That's
>>>>>>>>>>>>>>>> TOO ABSTRACT for PO, so all he can do is replace it
>>>>>>>>>>>>>>>> with something he thinks he /can/ understand:
>>>>>>>>>>>>>>>> something more concrete - a simulation run in some
>>>>>>>>>>>>>>>> "actual machine" processing a TM description and tape
>>>>>>>>>>>>>>>> description!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE WITH
>>>>>>>>>>>>>>> ME Every decider computes the mapping from its input
>>>>>>>>>>>>>>> finite string(s) to an accept or reject state based on a
>>>>>>>>>>>>>>> semantic or syntactic property of this finite string.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Finite strings don't have semantic properties.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> In computability theory, Rice's theorem states that all
>>>>>>>>>>>>> non-trivial semantic properties of programs are
>>>>>>>>>>>>> undecidable.
>>>>>>>>>>>>
>>>>>>>>>>>> And how 'bout them Mets?
>>>>>>>>>>>>
>>>>>>>>>>>>> A semantic property is one about the program's behavior
>>>>>>>>>>>>> (for instance, does the program terminate for all inputs),
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Rice%27s_theorem
>>>>>>>>>>>>>
>>>>>>>>>>>>> In formal semantics this would be the semantic property
>>>>>>>>>>>>> of a finite string.
>>>>>>>>>>>>
>>>>>>>>>>>> No, it would be a semantic property of the program. That
>>>>>>>>>>>> program might be *represented* as a string, but the string
>>>>>>>>>>>> itself has no semantic properties.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The semantic property of the string when it is interpreted
>>>>>>>>>>> as the description of a program.
>>>>>>>>>>
>>>>>>>>>> WHOOOSH!
>>>>>>>>>>
>>>>>>>>>> As soon you you add 'when it is interpreted as...' you are no
>>>>>>>>>> longer talking about the string but the thing which the
>>>>>>>>>> string represents.
>>>>>>>>>
>>>>>>>>> Yes. The string has no semantics on its own.
>>>>>>>>>
>>>>>>>>> The input to H(P,P) determines (Mike's word) an execution
>>>>>>>>> trace of x86 instructions when correctly emulated by H.
>>>>>>>>>
>>>>>>>>> The input to H1(P,P) determines (Mike's word) an execution
>>>>>>>>> trace of x86 instructions when correctly emulated by H1.
>>>>>>>>
>>>>>>>> And neither of those sentences make any sense. Replacing
>>>>>>>> 'specifies' with 'determines' doesn't make things any clearer.
>>>>>>>> You need to actually DEFINE your terms.
>>>>>>>>
>>>>>>>>> These execution traces are not the same.
>>>>>>>> Which means at least one of the above programs is *not*
>>>>>>>> interpreting its input in the correct way, i.e. in the way
>>>>>>>> which the specification of a halt decider demands.
>>>>>>>
>>>>>>> Hows about...
>>>>>>>
>>>>>>> Computation P(P) goes through a sequence of steps, which for
>>>>>>> illustration I'll just refer to as <a> <b> ... <z> with <z>
>>>>>>> being the final (RET) step where the computation halts. Now, H
>>>>>>> and H1 calculate these steps ["emulate their input"] something
>>>>>>> like this:
>>>>>>>
>>>>>>> H1 H
>>>>>>> ---- ----
>>>>>>> <a> <a> // P(P) very first state!
>>>>>>> <b> <b>
>>>>>>> <c> <c>
>>>>>>> <d> <d>
>>>>>>> <e> <e>
>>>>>>> <f> <f>
>>>>>>> <g> <g>
>>>>>>> <h> <h>
>>>>>>> <i> <i>
>>>>>>> <j> <j>
>>>>>>> <k> <k>
>>>>>>> <l> <l> // no divergence so far!
>>>>>>> <m> <m>
>>>>>>> <n> <n>
>>>>>>> <o> <o>
>>>>>>> <p> <p>
>>>>>>> <q> <q>
>>>>>>> <r> <r> // H spots some pattern and stops
>>>>>>> simulating <s>
>>>>>>> <t>
>>>>>>> <u>
>>>>>>> <v>
>>>>>>> <w>
>>>>>>> <x>
>>>>>>> <y>
>>>>>>> <z> // P(P) final state - it halts!
>>>>>>>
>>>>>>> So in PO language "the input to H(P,P)" is (P,P), and this
>>>>>>> determines the steps of the computation P(P) which are being
>>>>>>> calculated by the emulator in H, which calculates <a>...<r> then
>>>>>>> stops calculating because it spotted some pattern. [in PO
>>>>>>> terms, <a>...<r> are the x86 instructions or their trace
>>>>>>> entries].
>>>>>>>
>>>>>>> "the input to H1(P,P)" is also (P,P), and this determines the
>>>>>>> steps of the computation P(P) which are being calculated by the
>>>>>>> emulator in H1, which calculates <a>...<r>...<z> then stops
>>>>>>> because final state [ret instruction] is reached.
>>>>>>>
>>>>>>> PO might try to deny that H1 calculates the same steps as H from
>>>>>>> <a> to <r>, or might agree. I don't think PO really understands
>>>>>>> what's happening in his own program. :)
>>>>>>>
>>>>>>> In PO language, perhaps, BOTH the above are "correct emulations"
>>>>>>> because the sequence of "x86 instruction transitions" <a> -->
>>>>>>> <b> etc. is correct on a step-by-step basis. (That would be
>>>>>>> consistent with his claim repeated 1000 times, that we can check
>>>>>>> the emulation is correct by comparing the machine code listings
>>>>>>> and verifying that emulation is [doing each instruction
>>>>>>> correctly].)
>>>>>>>
>>>>>>> H's decision to stop emulating is not (IMO) part of the
>>>>>>> emulation itself. (How could it be? but probably that's just a
>>>>>>> matter of agreeing the terms we're using.)
>>>>>>>
>>>>>>> Anyhow, he who would argue with PO would do well to pin PO down
>>>>>>> on his strange choice of phrases to avoid weeks or months of
>>>>>>> miscommunications. And you have to start by discovering
>>>>>>> /something/ you agree on... Just demanding he "defines all his
>>>>>>> terms" won't get far as he can't "define" anything properly. :)
>>>>>>>
>>>>>>>
>>>>>>> Mike.
>>>>>>>
>>>>>> The input to H1(P,P) halts.
>>>>>> In this same computation the input to H(P,P)
>>>>>> would never reach its "ret" instruction in 1 to ∞ emulated
>>>>>> steps.
>>>>>
>>>>> But the fixed algorithm of H, hereafter referred to as Ha and the
>>>>> P that call it referred to as Pa, does not simulate for an
>>>>> infinite number of steps. It simulates for a particular number
>>>>> of cycles.
>>>>
>>>> _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]
>>>>
>>>> H correctly simulates its input until it determines that a correct
>>>> simulation of ∞ steps of this input would never reach the "ret"
>>>> instruction of this input.
>>>>
>>>> Surely you are bright enough to tell that the above
>>>> _Infinite_Loop() would never reach its "ret" instruction?
>>>
>>> I thought the reason why it would never reach its "ret" instruction
>>> was due to an infinite recursion that you invented? Make your mind
>>> up.
>>>
>>> /Flibble
>>>
>>
>> You have to actually look at what I say before responding. H is a
>> general purpose halt determiner that can determine the correct halt
>> status of many different inputs.
>>
>> This is an infinite loop:
>> [000012c5](02) ebfe jmp 000012c5
>
> I know what an infinite loop looks like, dear. What about interrupts?
> x86 CPU supports interrupts so don't you need:
>
> FA EB FE?
>
> /Flibble
>

On Mon, 30 May 2022 08:51:38 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 5/30/2022 8:20 AM, Mr Flibble wrote:
> > On Mon, 30 May 2022 08:17:03 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 5/30/2022 8:11 AM, Mr Flibble wrote:
> >>> On Sun, 29 May 2022 22:42:19 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 5/29/2022 7:44 PM, Dennis Bush wrote:
> >>>>> On Sunday, May 29, 2022 at 8:33:53 PM UTC-4, olcott wrote:
> >>>>>> On 5/29/2022 6:24 PM, Mike Terry wrote:
> >>>>>>> On 29/05/2022 22:56, André G. Isaak wrote:
> >>>>>>>> On 2022-05-29 15:41, olcott wrote:
> >>>>>>>>> On 5/29/2022 4:30 PM, André G. Isaak wrote:
> >>>>>>>>>> On 2022-05-29 15:16, olcott wrote:
> >>>>>>>>>>> On 5/29/2022 4:00 PM, André G. Isaak wrote:
> >>>>>>>>>>>> On 2022-05-29 14:35, olcott wrote:
> >>>>>>>>>>>>> On 5/29/2022 2:58 PM, André G. Isaak wrote:
> >>>>>>>>>>>>>> On 2022-05-29 13:26, olcott wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Agree. I think PO probably can't understand the
> >>>>>>>>>>>>>>>> proper definition of halting. That definition
> >>>>>>>>>>>>>>>> doesn't involve any UTMs or emulation - it's just a
> >>>>>>>>>>>>>>>> mathematical definition, first of the computation
> >>>>>>>>>>>>>>>> steps, then of halting in terms of there being an n
> >>>>>>>>>>>>>>>> such that computation step n is a final state of the
> >>>>>>>>>>>>>>>> TM. That's TOO ABSTRACT for PO, so all he can do is
> >>>>>>>>>>>>>>>> replace it with something he thinks he /can/
> >>>>>>>>>>>>>>>> understand: something more concrete - a simulation
> >>>>>>>>>>>>>>>> run in some "actual machine" processing a TM
> >>>>>>>>>>>>>>>> description and tape description!
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE WITH
> >>>>>>>>>>>>>>> ME Every decider computes the mapping from its input
> >>>>>>>>>>>>>>> finite string(s) to an accept or reject state based
> >>>>>>>>>>>>>>> on a semantic or syntactic property of this finite
> >>>>>>>>>>>>>>> string.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Finite strings don't have semantic properties.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> In computability theory, Rice's theorem states that all
> >>>>>>>>>>>>> non-trivial semantic properties of programs are
> >>>>>>>>>>>>> undecidable.
> >>>>>>>>>>>>
> >>>>>>>>>>>> And how 'bout them Mets?
> >>>>>>>>>>>>
> >>>>>>>>>>>>> A semantic property is one about the program's behavior
> >>>>>>>>>>>>> (for instance, does the program terminate for all
> >>>>>>>>>>>>> inputs),
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> https://en.wikipedia.org/wiki/Rice%27s_theorem
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> In formal semantics this would be the semantic property
> >>>>>>>>>>>>> of a finite string.
> >>>>>>>>>>>>
> >>>>>>>>>>>> No, it would be a semantic property of the program. That
> >>>>>>>>>>>> program might be *represented* as a string, but the
> >>>>>>>>>>>> string itself has no semantic properties.
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> The semantic property of the string when it is interpreted
> >>>>>>>>>>> as the description of a program.
> >>>>>>>>>>
> >>>>>>>>>> WHOOOSH!
> >>>>>>>>>>
> >>>>>>>>>> As soon you you add 'when it is interpreted as...' you are
> >>>>>>>>>> no longer talking about the string but the thing which the
> >>>>>>>>>> string represents.
> >>>>>>>>>
> >>>>>>>>> Yes. The string has no semantics on its own.
> >>>>>>>>>
> >>>>>>>>> The input to H(P,P) determines (Mike's word) an execution
> >>>>>>>>> trace of x86 instructions when correctly emulated by H.
> >>>>>>>>>
> >>>>>>>>> The input to H1(P,P) determines (Mike's word) an execution
> >>>>>>>>> trace of x86 instructions when correctly emulated by H1.
> >>>>>>>>
> >>>>>>>> And neither of those sentences make any sense. Replacing
> >>>>>>>> 'specifies' with 'determines' doesn't make things any
> >>>>>>>> clearer. You need to actually DEFINE your terms.
> >>>>>>>>
> >>>>>>>>> These execution traces are not the same.
> >>>>>>>> Which means at least one of the above programs is *not*
> >>>>>>>> interpreting its input in the correct way, i.e. in the way
> >>>>>>>> which the specification of a halt decider demands.
> >>>>>>>
> >>>>>>> Hows about...
> >>>>>>>
> >>>>>>> Computation P(P) goes through a sequence of steps, which
> >>>>>>> for illustration I'll just refer to as <a> <b> ... <z> with
> >>>>>>> <z> being the final (RET) step where the computation halts.
> >>>>>>> Now, H and H1 calculate these steps ["emulate their input"]
> >>>>>>> something like this:
> >>>>>>>
> >>>>>>> H1 H
> >>>>>>> ---- ----
> >>>>>>> <a> <a> // P(P) very first state!
> >>>>>>> <b> <b>
> >>>>>>> <c> <c>
> >>>>>>> <d> <d>
> >>>>>>> <e> <e>
> >>>>>>> <f> <f>
> >>>>>>> <g> <g>
> >>>>>>> <h> <h>
> >>>>>>> <i> <i>
> >>>>>>> <j> <j>
> >>>>>>> <k> <k>
> >>>>>>> <l> <l> // no divergence so far!
> >>>>>>> <m> <m>
> >>>>>>> <n> <n>
> >>>>>>> <o> <o>
> >>>>>>> <p> <p>
> >>>>>>> <q> <q>
> >>>>>>> <r> <r> // H spots some pattern and stops
> >>>>>>> simulating <s>
> >>>>>>> <t>
> >>>>>>> <u>
> >>>>>>> <v>
> >>>>>>> <w>
> >>>>>>> <x>
> >>>>>>> <y>
> >>>>>>> <z> // P(P) final state - it halts!
> >>>>>>>
> >>>>>>> So in PO language "the input to H(P,P)" is (P,P), and this
> >>>>>>> determines the steps of the computation P(P) which are being
> >>>>>>> calculated by the emulator in H, which calculates <a>...<r>
> >>>>>>> then stops calculating because it spotted some pattern. [in
> >>>>>>> PO terms, <a>...<r> are the x86 instructions or their trace
> >>>>>>> entries].
> >>>>>>>
> >>>>>>> "the input to H1(P,P)" is also (P,P), and this determines the
> >>>>>>> steps of the computation P(P) which are being calculated by
> >>>>>>> the emulator in H1, which calculates <a>...<r>...<z> then
> >>>>>>> stops because final state [ret instruction] is reached.
> >>>>>>>
> >>>>>>> PO might try to deny that H1 calculates the same steps as H
> >>>>>>> from <a> to <r>, or might agree. I don't think PO really
> >>>>>>> understands what's happening in his own program. :)
> >>>>>>>
> >>>>>>> In PO language, perhaps, BOTH the above are "correct
> >>>>>>> emulations" because the sequence of "x86 instruction
> >>>>>>> transitions" <a> --> <b> etc. is correct on a step-by-step
> >>>>>>> basis. (That would be consistent with his claim repeated
> >>>>>>> 1000 times, that we can check the emulation is correct by
> >>>>>>> comparing the machine code listings and verifying that
> >>>>>>> emulation is [doing each instruction correctly].)
> >>>>>>>
> >>>>>>> H's decision to stop emulating is not (IMO) part of the
> >>>>>>> emulation itself. (How could it be? but probably that's just
> >>>>>>> a matter of agreeing the terms we're using.)
> >>>>>>>
> >>>>>>> Anyhow, he who would argue with PO would do well to pin PO
> >>>>>>> down on his strange choice of phrases to avoid weeks or
> >>>>>>> months of miscommunications. And you have to start by
> >>>>>>> discovering /something/ you agree on... Just demanding he
> >>>>>>> "defines all his terms" won't get far as he can't "define"
> >>>>>>> anything properly. :)
> >>>>>>>
> >>>>>>>
> >>>>>>> Mike.
> >>>>>>>
> >>>>>> The input to H1(P,P) halts.
> >>>>>> In this same computation the input to H(P,P)
> >>>>>> would never reach its "ret" instruction in 1 to ∞ emulated
> >>>>>> steps.
> >>>>>
> >>>>> But the fixed algorithm of H, hereafter referred to as Ha and
> >>>>> the P that call it referred to as Pa, does not simulate for an
> >>>>> infinite number of steps. It simulates for a particular number
> >>>>> of cycles.
> >>>>
> >>>> _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]
> >>>>
> >>>> H correctly simulates its input until it determines that a
> >>>> correct simulation of ∞ steps of this input would never reach
> >>>> the "ret" instruction of this input.
> >>>>
> >>>> Surely you are bright enough to tell that the above
> >>>> _Infinite_Loop() would never reach its "ret" instruction?
> >>>
> >>> I thought the reason why it would never reach its "ret"
> >>> instruction was due to an infinite recursion that you invented?
> >>> Make your mind up.
> >>>
> >>> /Flibble
> >>>
> >>
> >> You have to actually look at what I say before responding. H is a
> >> general purpose halt determiner that can determine the correct halt
> >> status of many different inputs.
> >>
> >> This is an infinite loop:
> >> [000012c5](02) ebfe jmp 000012c5
> >
> > I know what an infinite loop looks like, dear. What about
> > interrupts? x86 CPU supports interrupts so don't you need:
> >
> > FA EB FE?
> >
> > /Flibble
> >
>
> As long as H(P,P) determines that that its correctly simulated input
> never reaches its "return" instruction all of the HP proofs have been
> refuted. This is the entire scope of the investigation.

On Monday, May 30, 2022 at 9:46:56 AM UTC-4, olcott wrote:
> On 5/30/2022 8:14 AM, Dennis Bush wrote:
> > On Monday, May 30, 2022 at 8:56:49 AM UTC-4, olcott wrote:
> >> On 5/29/2022 11:04 PM, Dennis Bush wrote:
> >>> On Sunday, May 29, 2022 at 11:42:27 PM UTC-4, olcott wrote:
> >>>> On 5/29/2022 7:44 PM, Dennis Bush wrote:
> >>>>> On Sunday, May 29, 2022 at 8:33:53 PM UTC-4, olcott wrote:
> >>>>>> On 5/29/2022 6:24 PM, Mike Terry wrote:
> >>>>>>> On 29/05/2022 22:56, André G. Isaak wrote:
> >>>>>>>> On 2022-05-29 15:41, olcott wrote:
> >>>>>>>>> On 5/29/2022 4:30 PM, André G. Isaak wrote:
> >>>>>>>>>> On 2022-05-29 15:16, olcott wrote:
> >>>>>>>>>>> On 5/29/2022 4:00 PM, André G. Isaak wrote:
> >>>>>>>>>>>> On 2022-05-29 14:35, olcott wrote:
> >>>>>>>>>>>>> On 5/29/2022 2:58 PM, André G. Isaak wrote:
> >>>>>>>>>>>>>> On 2022-05-29 13:26, olcott wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Agree. I think PO probably can't understand the proper
> >>>>>>>>>>>>>>>> definition of halting. That definition doesn't involve any
> >>>>>>>>>>>>>>>> UTMs or emulation - it's just a mathematical definition, first
> >>>>>>>>>>>>>>>> of the computation steps, then of halting in terms of there
> >>>>>>>>>>>>>>>> being an n such that computation step n is a final state of
> >>>>>>>>>>>>>>>> the TM. That's TOO ABSTRACT for PO, so all he can do is
> >>>>>>>>>>>>>>>> replace it with something he thinks he /can/ understand:
> >>>>>>>>>>>>>>>> something more concrete - a simulation run in some "actual
> >>>>>>>>>>>>>>>> machine" processing a TM description and tape description!
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE WITH ME
> >>>>>>>>>>>>>>> Every decider computes the mapping from its input finite
> >>>>>>>>>>>>>>> string(s) to an accept or reject state based on a semantic or
> >>>>>>>>>>>>>>> syntactic property of this finite string.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Finite strings don't have semantic properties.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> In computability theory, Rice's theorem states that all
> >>>>>>>>>>>>> non-trivial semantic properties of programs are undecidable..
> >>>>>>>>>>>>
> >>>>>>>>>>>> And how 'bout them Mets?
> >>>>>>>>>>>>
> >>>>>>>>>>>>> A semantic property is one about the program's behavior (for
> >>>>>>>>>>>>> instance, does the program terminate for all inputs),
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> https://en.wikipedia.org/wiki/Rice%27s_theorem
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> In formal semantics this would be the semantic property of a
> >>>>>>>>>>>>> finite string.
> >>>>>>>>>>>>
> >>>>>>>>>>>> No, it would be a semantic property of the program. That program
> >>>>>>>>>>>> might be *represented* as a string, but the string itself has no
> >>>>>>>>>>>> semantic properties.
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> The semantic property of the string when it is interpreted as the
> >>>>>>>>>>> description of a program.
> >>>>>>>>>>
> >>>>>>>>>> WHOOOSH!
> >>>>>>>>>>
> >>>>>>>>>> As soon you you add 'when it is interpreted as...' you are no longer
> >>>>>>>>>> talking about the string but the thing which the string represents.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Yes. The string has no semantics on its own.
> >>>>>>>>>
> >>>>>>>>> The input to H(P,P) determines (Mike's word) an execution trace of
> >>>>>>>>> x86 instructions when correctly emulated by H.
> >>>>>>>>>
> >>>>>>>>> The input to H1(P,P) determines (Mike's word) an execution trace of
> >>>>>>>>> x86 instructions when correctly emulated by H1.
> >>>>>>>>
> >>>>>>>> And neither of those sentences make any sense. Replacing 'specifies'
> >>>>>>>> with 'determines' doesn't make things any clearer. You need to
> >>>>>>>> actually DEFINE your terms.
> >>>>>>>>
> >>>>>>>>> These execution traces are not the same.
> >>>>>>>> Which means at least one of the above programs is *not* interpreting
> >>>>>>>> its input in the correct way, i.e. in the way which the specification
> >>>>>>>> of a halt decider demands.
> >>>>>>>
> >>>>>>> Hows about...
> >>>>>>>
> >>>>>>> Computation P(P) goes through a sequence of steps, which for
> >>>>>>> illustration I'll just refer to as <a> <b> ... <z> with <z> being the
> >>>>>>> final (RET) step where the computation halts. Now, H and H1 calculate
> >>>>>>> these steps ["emulate their input"] something like this:
> >>>>>>>
> >>>>>>> H1 H
> >>>>>>> ---- ----
> >>>>>>> <a> <a> // P(P) very first state!
> >>>>>>> <b> <b>
> >>>>>>> <c> <c>
> >>>>>>> <d> <d>
> >>>>>>> <e> <e>
> >>>>>>> <f> <f>
> >>>>>>> <g> <g>
> >>>>>>> <h> <h>
> >>>>>>> <i> <i>
> >>>>>>> <j> <j>
> >>>>>>> <k> <k>
> >>>>>>> <l> <l> // no divergence so far!
> >>>>>>> <m> <m>
> >>>>>>> <n> <n>
> >>>>>>> <o> <o>
> >>>>>>> <p> <p>
> >>>>>>> <q> <q>
> >>>>>>> <r> <r> // H spots some pattern and stops simulating
> >>>>>>> <s>
> >>>>>>> <t>
> >>>>>>> <u>
> >>>>>>> <v>
> >>>>>>> <w>
> >>>>>>> <x>
> >>>>>>> <y>
> >>>>>>> <z> // P(P) final state - it halts!
> >>>>>>>
> >>>>>>> So in PO language "the input to H(P,P)" is (P,P), and this determines
> >>>>>>> the steps of the computation P(P) which are being calculated by the
> >>>>>>> emulator in H, which calculates <a>...<r> then stops calculating because
> >>>>>>> it spotted some pattern. [in PO terms, <a>...<r> are the x86
> >>>>>>> instructions or their trace entries].
> >>>>>>>
> >>>>>>> "the input to H1(P,P)" is also (P,P), and this determines the steps of
> >>>>>>> the computation P(P) which are being calculated by the emulator in H1,
> >>>>>>> which calculates <a>...<r>...<z> then stops because final state [ret
> >>>>>>> instruction] is reached.
> >>>>>>>
> >>>>>>> PO might try to deny that H1 calculates the same steps as H from <a> to
> >>>>>>> <r>, or might agree. I don't think PO really understands what's
> >>>>>>> happening in his own program. :)
> >>>>>>>
> >>>>>>> In PO language, perhaps, BOTH the above are "correct emulations" because
> >>>>>>> the sequence of "x86 instruction transitions" <a> --> <b> etc. is
> >>>>>>> correct on a step-by-step basis. (That would be consistent with his
> >>>>>>> claim repeated 1000 times, that we can check the emulation is correct by
> >>>>>>> comparing the machine code listings and verifying that emulation is
> >>>>>>> [doing each instruction correctly].)
> >>>>>>>
> >>>>>>> H's decision to stop emulating is not (IMO) part of the emulation
> >>>>>>> itself. (How could it be? but probably that's just a matter of agreeing
> >>>>>>> the terms we're using.)
> >>>>>>>
> >>>>>>> Anyhow, he who would argue with PO would do well to pin PO down on his
> >>>>>>> strange choice of phrases to avoid weeks or months of
> >>>>>>> miscommunications. And you have to start by discovering /something/ you
> >>>>>>> agree on... Just demanding he "defines all his terms" won't get far as
> >>>>>>> he can't "define" anything properly. :)
> >>>>>>>
> >>>>>>>
> >>>>>>> Mike.
> >>>>>>>
> >>>>>> The input to H1(P,P) halts.
> >>>>>> In this same computation the input to H(P,P)
> >>>>>> would never reach its "ret" instruction in 1 to ∞ emulated steps.
> >>>>>
> >>>>> But the fixed algorithm of H, hereafter referred to as Ha and the P that call it referred to as Pa, does not simulate for an infinite number of steps. It simulates for a particular number of cycles.
> >>>> _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]
> >>>>
> >>>> H correctly simulates its input until it determines that a correct
> >>>> simulation of ∞ steps of this input would never reach the "ret"
> >>>> instruction of this input.
> >>>
> >>> By definition, a correct simulation is performed by a UTM. UTM(_Infinite_Loop,"") does not halt. UTM(Pa,Pa) does halt, so Ha(Pa,Pa)==0 is wrong.
> >> UTM(P,P) determines an execution trace of P that reaches its "ret"
> >> instruction. Yet this is a deliberately deceptive example and you know
> >> it. Here is an actual comparable example:
> >
> > It is not deceptive. It is the *definition* of a correct simulation.
> >
> >>
> >> Emulate(P,P);
> >>
> >> void P(u32 x)
> >> {
> >> if (Emulate(x, x))
> >> HERE: goto HERE;
> >> return;
> >> }
> >
> >
> > What you call Emulate is Hn,
> No I would not because the H means halt decider.
> > and because of that, P is Pn. And Pn(Pn) does not halt, nor does Hn(Pn,Pn).
> >
> > So you're claiming that Ha(Pa,Pa)==0 is correct because Pn(Pn) does not halt.
> When-so-ever any input to a simulating halt decider must have its
> simulation aborted to prevent the infinite simulation of this input this
> input is correctly determined to be a non-halting input.

On 5/30/2022 8:49 AM, Mr Flibble wrote:
> On Mon, 30 May 2022 08:46:48 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 5/30/2022 8:14 AM, Dennis Bush wrote:
>>> On Monday, May 30, 2022 at 8:56:49 AM UTC-4, olcott wrote:
>>>> On 5/29/2022 11:04 PM, Dennis Bush wrote:
>>>>> On Sunday, May 29, 2022 at 11:42:27 PM UTC-4, olcott wrote:
>>>>>> On 5/29/2022 7:44 PM, Dennis Bush wrote:
>>>>>>> On Sunday, May 29, 2022 at 8:33:53 PM UTC-4, olcott wrote:
>>>>>>>> On 5/29/2022 6:24 PM, Mike Terry wrote:
>>>>>>>>> On 29/05/2022 22:56, André G. Isaak wrote:
>>>>>>>>>> On 2022-05-29 15:41, olcott wrote:
>>>>>>>>>>> On 5/29/2022 4:30 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2022-05-29 15:16, olcott wrote:
>>>>>>>>>>>>> On 5/29/2022 4:00 PM, André G. Isaak wrote:
>>>>>>>>>>>>>> On 2022-05-29 14:35, olcott wrote:
>>>>>>>>>>>>>>> On 5/29/2022 2:58 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>> On 2022-05-29 13:26, olcott wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Agree. I think PO probably can't understand the
>>>>>>>>>>>>>>>>>> proper definition of halting. That definition
>>>>>>>>>>>>>>>>>> doesn't involve any UTMs or emulation - it's just a
>>>>>>>>>>>>>>>>>> mathematical definition, first of the computation
>>>>>>>>>>>>>>>>>> steps, then of halting in terms of there being an n
>>>>>>>>>>>>>>>>>> such that computation step n is a final state of the
>>>>>>>>>>>>>>>>>> TM. That's TOO ABSTRACT for PO, so all he can do is
>>>>>>>>>>>>>>>>>> replace it with something he thinks he /can/
>>>>>>>>>>>>>>>>>> understand: something more concrete - a simulation
>>>>>>>>>>>>>>>>>> run in some "actual machine" processing a TM
>>>>>>>>>>>>>>>>>> description and tape description!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE
>>>>>>>>>>>>>>>>> WITH ME Every decider computes the mapping from its
>>>>>>>>>>>>>>>>> input finite string(s) to an accept or reject state
>>>>>>>>>>>>>>>>> based on a semantic or syntactic property of this
>>>>>>>>>>>>>>>>> finite string.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Finite strings don't have semantic properties.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In computability theory, Rice's theorem states that all
>>>>>>>>>>>>>>> non-trivial semantic properties of programs are
>>>>>>>>>>>>>>> undecidable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And how 'bout them Mets?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A semantic property is one about the program's behavior
>>>>>>>>>>>>>>> (for instance, does the program terminate for all
>>>>>>>>>>>>>>> inputs),
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Rice%27s_theorem
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In formal semantics this would be the semantic property
>>>>>>>>>>>>>>> of a finite string.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No, it would be a semantic property of the program. That
>>>>>>>>>>>>>> program might be *represented* as a string, but the
>>>>>>>>>>>>>> string itself has no semantic properties.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The semantic property of the string when it is
>>>>>>>>>>>>> interpreted as the description of a program.
>>>>>>>>>>>>
>>>>>>>>>>>> WHOOOSH!
>>>>>>>>>>>>
>>>>>>>>>>>> As soon you you add 'when it is interpreted as...' you are
>>>>>>>>>>>> no longer talking about the string but the thing which the
>>>>>>>>>>>> string represents.
>>>>>>>>>>>
>>>>>>>>>>> Yes. The string has no semantics on its own.
>>>>>>>>>>>
>>>>>>>>>>> The input to H(P,P) determines (Mike's word) an execution
>>>>>>>>>>> trace of x86 instructions when correctly emulated by H.
>>>>>>>>>>>
>>>>>>>>>>> The input to H1(P,P) determines (Mike's word) an execution
>>>>>>>>>>> trace of x86 instructions when correctly emulated by H1.
>>>>>>>>>>
>>>>>>>>>> And neither of those sentences make any sense. Replacing
>>>>>>>>>> 'specifies' with 'determines' doesn't make things any
>>>>>>>>>> clearer. You need to actually DEFINE your terms.
>>>>>>>>>>
>>>>>>>>>>> These execution traces are not the same.
>>>>>>>>>> Which means at least one of the above programs is *not*
>>>>>>>>>> interpreting its input in the correct way, i.e. in the way
>>>>>>>>>> which the specification of a halt decider demands.
>>>>>>>>>
>>>>>>>>> Hows about...
>>>>>>>>>
>>>>>>>>> Computation P(P) goes through a sequence of steps, which for
>>>>>>>>> illustration I'll just refer to as <a> <b> ... <z> with <z>
>>>>>>>>> being the final (RET) step where the computation halts. Now,
>>>>>>>>> H and H1 calculate these steps ["emulate their input"]
>>>>>>>>> something like this:
>>>>>>>>>
>>>>>>>>> H1 H
>>>>>>>>> ---- ----
>>>>>>>>> <a> <a> // P(P) very first state!
>>>>>>>>> <b> <b>
>>>>>>>>> <c> <c>
>>>>>>>>> <d> <d>
>>>>>>>>> <e> <e>
>>>>>>>>> <f> <f>
>>>>>>>>> <g> <g>
>>>>>>>>> <h> <h>
>>>>>>>>> <i> <i>
>>>>>>>>> <j> <j>
>>>>>>>>> <k> <k>
>>>>>>>>> <l> <l> // no divergence so far!
>>>>>>>>> <m> <m>
>>>>>>>>> <n> <n>
>>>>>>>>> <o> <o>
>>>>>>>>> <p> <p>
>>>>>>>>> <q> <q>
>>>>>>>>> <r> <r> // H spots some pattern and stops simulating
>>>>>>>>> <s>
>>>>>>>>> <t>
>>>>>>>>> <u>
>>>>>>>>> <v>
>>>>>>>>> <w>
>>>>>>>>> <x>
>>>>>>>>> <y>
>>>>>>>>> <z> // P(P) final state - it halts!
>>>>>>>>>
>>>>>>>>> So in PO language "the input to H(P,P)" is (P,P), and this
>>>>>>>>> determines the steps of the computation P(P) which are being
>>>>>>>>> calculated by the emulator in H, which calculates <a>...<r>
>>>>>>>>> then stops calculating because it spotted some pattern. [in
>>>>>>>>> PO terms, <a>...<r> are the x86 instructions or their trace
>>>>>>>>> entries].
>>>>>>>>>
>>>>>>>>> "the input to H1(P,P)" is also (P,P), and this determines the
>>>>>>>>> steps of the computation P(P) which are being calculated by
>>>>>>>>> the emulator in H1, which calculates <a>...<r>...<z> then
>>>>>>>>> stops because final state [ret instruction] is reached.
>>>>>>>>>
>>>>>>>>> PO might try to deny that H1 calculates the same steps as H
>>>>>>>>> from <a> to <r>, or might agree. I don't think PO really
>>>>>>>>> understands what's happening in his own program. :)
>>>>>>>>>
>>>>>>>>> In PO language, perhaps, BOTH the above are "correct
>>>>>>>>> emulations" because the sequence of "x86 instruction
>>>>>>>>> transitions" <a> --> <b> etc. is correct on a step-by-step
>>>>>>>>> basis. (That would be consistent with his claim repeated 1000
>>>>>>>>> times, that we can check the emulation is correct by
>>>>>>>>> comparing the machine code listings and verifying that
>>>>>>>>> emulation is [doing each instruction correctly].)
>>>>>>>>>
>>>>>>>>> H's decision to stop emulating is not (IMO) part of the
>>>>>>>>> emulation itself. (How could it be? but probably that's just
>>>>>>>>> a matter of agreeing the terms we're using.)
>>>>>>>>>
>>>>>>>>> Anyhow, he who would argue with PO would do well to pin PO
>>>>>>>>> down on his strange choice of phrases to avoid weeks or
>>>>>>>>> months of miscommunications. And you have to start by
>>>>>>>>> discovering /something/ you agree on... Just demanding he
>>>>>>>>> "defines all his terms" won't get far as he can't "define"
>>>>>>>>> anything properly. :)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Mike.
>>>>>>>>>
>>>>>>>> The input to H1(P,P) halts.
>>>>>>>> In this same computation the input to H(P,P)
>>>>>>>> would never reach its "ret" instruction in 1 to ∞ emulated
>>>>>>>> steps.
>>>>>>>
>>>>>>> But the fixed algorithm of H, hereafter referred to as Ha and
>>>>>>> the P that call it referred to as Pa, does not simulate for an
>>>>>>> infinite number of steps. It simulates for a particular number
>>>>>>> of cycles.
>>>>>> _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]
>>>>>>
>>>>>> H correctly simulates its input until it determines that a
>>>>>> correct simulation of ∞ steps of this input would never reach
>>>>>> the "ret" instruction of this input.
>>>>>
>>>>> By definition, a correct simulation is performed by a UTM.
>>>>> UTM(_Infinite_Loop,"") does not halt. UTM(Pa,Pa) does halt, so
>>>>> Ha(Pa,Pa)==0 is wrong.
>>>> UTM(P,P) determines an execution trace of P that reaches its "ret"
>>>> instruction. Yet this is a deliberately deceptive example and you
>>>> know it. Here is an actual comparable example:
>>>
>>> It is not deceptive. It is the *definition* of a correct
>>> simulation.
>>>>
>>>> Emulate(P,P);
>>>>
>>>> void P(u32 x)
>>>> {
>>>> if (Emulate(x, x))
>>>> HERE: goto HERE;
>>>> return;
>>>> }
>>>
>>>
>>> What you call Emulate is Hn,
>>
>> No I would not because the H means halt decider.
>>
>>> and because of that, P is Pn. And Pn(Pn) does not halt, nor does
>>> Hn(Pn,Pn).
>>>
>>> So you're claiming that Ha(Pa,Pa)==0 is correct because Pn(Pn) does
>>> not halt.
>>
>> When-so-ever any input to a simulating halt decider must have its
>> simulation aborted to prevent the infinite simulation of this input
>> this input is correctly determined to be a non-halting input.
>
> There is no "infinite simulation" in the proofs you are attempting to
> refute; it is a fiction of your own making.
>
> /Flibble
>

On 5/30/2022 8:55 AM, Mr Flibble wrote:
> On Mon, 30 May 2022 08:51:38 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 5/30/2022 8:20 AM, Mr Flibble wrote:
>>> On Mon, 30 May 2022 08:17:03 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 5/30/2022 8:11 AM, Mr Flibble wrote:
>>>>> On Sun, 29 May 2022 22:42:19 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 5/29/2022 7:44 PM, Dennis Bush wrote:
>>>>>>> On Sunday, May 29, 2022 at 8:33:53 PM UTC-4, olcott wrote:
>>>>>>>> On 5/29/2022 6:24 PM, Mike Terry wrote:
>>>>>>>>> On 29/05/2022 22:56, André G. Isaak wrote:
>>>>>>>>>> On 2022-05-29 15:41, olcott wrote:
>>>>>>>>>>> On 5/29/2022 4:30 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2022-05-29 15:16, olcott wrote:
>>>>>>>>>>>>> On 5/29/2022 4:00 PM, André G. Isaak wrote:
>>>>>>>>>>>>>> On 2022-05-29 14:35, olcott wrote:
>>>>>>>>>>>>>>> On 5/29/2022 2:58 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>> On 2022-05-29 13:26, olcott wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Agree. I think PO probably can't understand the
>>>>>>>>>>>>>>>>>> proper definition of halting. That definition
>>>>>>>>>>>>>>>>>> doesn't involve any UTMs or emulation - it's just a
>>>>>>>>>>>>>>>>>> mathematical definition, first of the computation
>>>>>>>>>>>>>>>>>> steps, then of halting in terms of there being an n
>>>>>>>>>>>>>>>>>> such that computation step n is a final state of the
>>>>>>>>>>>>>>>>>> TM. That's TOO ABSTRACT for PO, so all he can do is
>>>>>>>>>>>>>>>>>> replace it with something he thinks he /can/
>>>>>>>>>>>>>>>>>> understand: something more concrete - a simulation
>>>>>>>>>>>>>>>>>> run in some "actual machine" processing a TM
>>>>>>>>>>>>>>>>>> description and tape description!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE WITH
>>>>>>>>>>>>>>>>> ME Every decider computes the mapping from its input
>>>>>>>>>>>>>>>>> finite string(s) to an accept or reject state based
>>>>>>>>>>>>>>>>> on a semantic or syntactic property of this finite
>>>>>>>>>>>>>>>>> string.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Finite strings don't have semantic properties.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In computability theory, Rice's theorem states that all
>>>>>>>>>>>>>>> non-trivial semantic properties of programs are
>>>>>>>>>>>>>>> undecidable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And how 'bout them Mets?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A semantic property is one about the program's behavior
>>>>>>>>>>>>>>> (for instance, does the program terminate for all
>>>>>>>>>>>>>>> inputs),
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Rice%27s_theorem
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In formal semantics this would be the semantic property
>>>>>>>>>>>>>>> of a finite string.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No, it would be a semantic property of the program. That
>>>>>>>>>>>>>> program might be *represented* as a string, but the
>>>>>>>>>>>>>> string itself has no semantic properties.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The semantic property of the string when it is interpreted
>>>>>>>>>>>>> as the description of a program.
>>>>>>>>>>>>
>>>>>>>>>>>> WHOOOSH!
>>>>>>>>>>>>
>>>>>>>>>>>> As soon you you add 'when it is interpreted as...' you are
>>>>>>>>>>>> no longer talking about the string but the thing which the
>>>>>>>>>>>> string represents.
>>>>>>>>>>>
>>>>>>>>>>> Yes. The string has no semantics on its own.
>>>>>>>>>>>
>>>>>>>>>>> The input to H(P,P) determines (Mike's word) an execution
>>>>>>>>>>> trace of x86 instructions when correctly emulated by H.
>>>>>>>>>>>
>>>>>>>>>>> The input to H1(P,P) determines (Mike's word) an execution
>>>>>>>>>>> trace of x86 instructions when correctly emulated by H1.
>>>>>>>>>>
>>>>>>>>>> And neither of those sentences make any sense. Replacing
>>>>>>>>>> 'specifies' with 'determines' doesn't make things any
>>>>>>>>>> clearer. You need to actually DEFINE your terms.
>>>>>>>>>>
>>>>>>>>>>> These execution traces are not the same.
>>>>>>>>>> Which means at least one of the above programs is *not*
>>>>>>>>>> interpreting its input in the correct way, i.e. in the way
>>>>>>>>>> which the specification of a halt decider demands.
>>>>>>>>>
>>>>>>>>> Hows about...
>>>>>>>>>
>>>>>>>>> Computation P(P) goes through a sequence of steps, which
>>>>>>>>> for illustration I'll just refer to as <a> <b> ... <z> with
>>>>>>>>> <z> being the final (RET) step where the computation halts.
>>>>>>>>> Now, H and H1 calculate these steps ["emulate their input"]
>>>>>>>>> something like this:
>>>>>>>>>
>>>>>>>>> H1 H
>>>>>>>>> ---- ----
>>>>>>>>> <a> <a> // P(P) very first state!
>>>>>>>>> <b> <b>
>>>>>>>>> <c> <c>
>>>>>>>>> <d> <d>
>>>>>>>>> <e> <e>
>>>>>>>>> <f> <f>
>>>>>>>>> <g> <g>
>>>>>>>>> <h> <h>
>>>>>>>>> <i> <i>
>>>>>>>>> <j> <j>
>>>>>>>>> <k> <k>
>>>>>>>>> <l> <l> // no divergence so far!
>>>>>>>>> <m> <m>
>>>>>>>>> <n> <n>
>>>>>>>>> <o> <o>
>>>>>>>>> <p> <p>
>>>>>>>>> <q> <q>
>>>>>>>>> <r> <r> // H spots some pattern and stops
>>>>>>>>> simulating <s>
>>>>>>>>> <t>
>>>>>>>>> <u>
>>>>>>>>> <v>
>>>>>>>>> <w>
>>>>>>>>> <x>
>>>>>>>>> <y>
>>>>>>>>> <z> // P(P) final state - it halts!
>>>>>>>>>
>>>>>>>>> So in PO language "the input to H(P,P)" is (P,P), and this
>>>>>>>>> determines the steps of the computation P(P) which are being
>>>>>>>>> calculated by the emulator in H, which calculates <a>...<r>
>>>>>>>>> then stops calculating because it spotted some pattern. [in
>>>>>>>>> PO terms, <a>...<r> are the x86 instructions or their trace
>>>>>>>>> entries].
>>>>>>>>>
>>>>>>>>> "the input to H1(P,P)" is also (P,P), and this determines the
>>>>>>>>> steps of the computation P(P) which are being calculated by
>>>>>>>>> the emulator in H1, which calculates <a>...<r>...<z> then
>>>>>>>>> stops because final state [ret instruction] is reached.
>>>>>>>>>
>>>>>>>>> PO might try to deny that H1 calculates the same steps as H
>>>>>>>>> from <a> to <r>, or might agree. I don't think PO really
>>>>>>>>> understands what's happening in his own program. :)
>>>>>>>>>
>>>>>>>>> In PO language, perhaps, BOTH the above are "correct
>>>>>>>>> emulations" because the sequence of "x86 instruction
>>>>>>>>> transitions" <a> --> <b> etc. is correct on a step-by-step
>>>>>>>>> basis. (That would be consistent with his claim repeated
>>>>>>>>> 1000 times, that we can check the emulation is correct by
>>>>>>>>> comparing the machine code listings and verifying that
>>>>>>>>> emulation is [doing each instruction correctly].)
>>>>>>>>>
>>>>>>>>> H's decision to stop emulating is not (IMO) part of the
>>>>>>>>> emulation itself. (How could it be? but probably that's just
>>>>>>>>> a matter of agreeing the terms we're using.)
>>>>>>>>>
>>>>>>>>> Anyhow, he who would argue with PO would do well to pin PO
>>>>>>>>> down on his strange choice of phrases to avoid weeks or
>>>>>>>>> months of miscommunications. And you have to start by
>>>>>>>>> discovering /something/ you agree on... Just demanding he
>>>>>>>>> "defines all his terms" won't get far as he can't "define"
>>>>>>>>> anything properly. :)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Mike.
>>>>>>>>>
>>>>>>>> The input to H1(P,P) halts.
>>>>>>>> In this same computation the input to H(P,P)
>>>>>>>> would never reach its "ret" instruction in 1 to ∞ emulated
>>>>>>>> steps.
>>>>>>>
>>>>>>> But the fixed algorithm of H, hereafter referred to as Ha and
>>>>>>> the P that call it referred to as Pa, does not simulate for an
>>>>>>> infinite number of steps. It simulates for a particular number
>>>>>>> of cycles.
>>>>>>
>>>>>> _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]
>>>>>>
>>>>>> H correctly simulates its input until it determines that a
>>>>>> correct simulation of ∞ steps of this input would never reach
>>>>>> the "ret" instruction of this input.
>>>>>>
>>>>>> Surely you are bright enough to tell that the above
>>>>>> _Infinite_Loop() would never reach its "ret" instruction?
>>>>>
>>>>> I thought the reason why it would never reach its "ret"
>>>>> instruction was due to an infinite recursion that you invented?
>>>>> Make your mind up.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> You have to actually look at what I say before responding. H is a
>>>> general purpose halt determiner that can determine the correct halt
>>>> status of many different inputs.
>>>>
>>>> This is an infinite loop:
>>>> [000012c5](02) ebfe jmp 000012c5
>>>
>>> I know what an infinite loop looks like, dear. What about
>>> interrupts? x86 CPU supports interrupts so don't you need:
>>>
>>> FA EB FE?
>>>
>>> /Flibble
>>>
>>
>> As long as H(P,P) determines that that its correctly simulated input
>> never reaches its "return" instruction all of the HP proofs have been
>> refuted. This is the entire scope of the investigation.
>
> But your refutation is predicated on the existence of an infinite
> recursion which isn't present in the proofs you are attempting to
> refute as it is a fiction of your own making.
>
> /Flibble
>
>

On 5/30/2022 9:29 AM, Dennis Bush wrote:
> On Monday, May 30, 2022 at 9:46:56 AM UTC-4, olcott wrote:
>> On 5/30/2022 8:14 AM, Dennis Bush wrote:
>>> On Monday, May 30, 2022 at 8:56:49 AM UTC-4, olcott wrote:
>>>> On 5/29/2022 11:04 PM, Dennis Bush wrote:
>>>>> On Sunday, May 29, 2022 at 11:42:27 PM UTC-4, olcott wrote:
>>>>>> On 5/29/2022 7:44 PM, Dennis Bush wrote:
>>>>>>> On Sunday, May 29, 2022 at 8:33:53 PM UTC-4, olcott wrote:
>>>>>>>> On 5/29/2022 6:24 PM, Mike Terry wrote:
>>>>>>>>> On 29/05/2022 22:56, André G. Isaak wrote:
>>>>>>>>>> On 2022-05-29 15:41, olcott wrote:
>>>>>>>>>>> On 5/29/2022 4:30 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2022-05-29 15:16, olcott wrote:
>>>>>>>>>>>>> On 5/29/2022 4:00 PM, André G. Isaak wrote:
>>>>>>>>>>>>>> On 2022-05-29 14:35, olcott wrote:
>>>>>>>>>>>>>>> On 5/29/2022 2:58 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>> On 2022-05-29 13:26, olcott wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Agree. I think PO probably can't understand the proper
>>>>>>>>>>>>>>>>>> definition of halting. That definition doesn't involve any
>>>>>>>>>>>>>>>>>> UTMs or emulation - it's just a mathematical definition, first
>>>>>>>>>>>>>>>>>> of the computation steps, then of halting in terms of there
>>>>>>>>>>>>>>>>>> being an n such that computation step n is a final state of
>>>>>>>>>>>>>>>>>> the TM. That's TOO ABSTRACT for PO, so all he can do is
>>>>>>>>>>>>>>>>>> replace it with something he thinks he /can/ understand:
>>>>>>>>>>>>>>>>>> something more concrete - a simulation run in some "actual
>>>>>>>>>>>>>>>>>> machine" processing a TM description and tape description!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE WITH ME
>>>>>>>>>>>>>>>>> Every decider computes the mapping from its input finite
>>>>>>>>>>>>>>>>> string(s) to an accept or reject state based on a semantic or
>>>>>>>>>>>>>>>>> syntactic property of this finite string.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Finite strings don't have semantic properties.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In computability theory, Rice's theorem states that all
>>>>>>>>>>>>>>> non-trivial semantic properties of programs are undecidable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And how 'bout them Mets?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A semantic property is one about the program's behavior (for
>>>>>>>>>>>>>>> instance, does the program terminate for all inputs),
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Rice%27s_theorem
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In formal semantics this would be the semantic property of a
>>>>>>>>>>>>>>> finite string.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No, it would be a semantic property of the program. That program
>>>>>>>>>>>>>> might be *represented* as a string, but the string itself has no
>>>>>>>>>>>>>> semantic properties.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The semantic property of the string when it is interpreted as the
>>>>>>>>>>>>> description of a program.
>>>>>>>>>>>>
>>>>>>>>>>>> WHOOOSH!
>>>>>>>>>>>>
>>>>>>>>>>>> As soon you you add 'when it is interpreted as...' you are no longer
>>>>>>>>>>>> talking about the string but the thing which the string represents.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Yes. The string has no semantics on its own.
>>>>>>>>>>>
>>>>>>>>>>> The input to H(P,P) determines (Mike's word) an execution trace of
>>>>>>>>>>> x86 instructions when correctly emulated by H.
>>>>>>>>>>>
>>>>>>>>>>> The input to H1(P,P) determines (Mike's word) an execution trace of
>>>>>>>>>>> x86 instructions when correctly emulated by H1.
>>>>>>>>>>
>>>>>>>>>> And neither of those sentences make any sense. Replacing 'specifies'
>>>>>>>>>> with 'determines' doesn't make things any clearer. You need to
>>>>>>>>>> actually DEFINE your terms.
>>>>>>>>>>
>>>>>>>>>>> These execution traces are not the same.
>>>>>>>>>> Which means at least one of the above programs is *not* interpreting
>>>>>>>>>> its input in the correct way, i.e. in the way which the specification
>>>>>>>>>> of a halt decider demands.
>>>>>>>>>
>>>>>>>>> Hows about...
>>>>>>>>>
>>>>>>>>> Computation P(P) goes through a sequence of steps, which for
>>>>>>>>> illustration I'll just refer to as <a> <b> ... <z> with <z> being the
>>>>>>>>> final (RET) step where the computation halts. Now, H and H1 calculate
>>>>>>>>> these steps ["emulate their input"] something like this:
>>>>>>>>>
>>>>>>>>> H1 H
>>>>>>>>> ---- ----
>>>>>>>>> <a> <a> // P(P) very first state!
>>>>>>>>> <b> <b>
>>>>>>>>> <c> <c>
>>>>>>>>> <d> <d>
>>>>>>>>> <e> <e>
>>>>>>>>> <f> <f>
>>>>>>>>> <g> <g>
>>>>>>>>> <h> <h>
>>>>>>>>> <i> <i>
>>>>>>>>> <j> <j>
>>>>>>>>> <k> <k>
>>>>>>>>> <l> <l> // no divergence so far!
>>>>>>>>> <m> <m>
>>>>>>>>> <n> <n>
>>>>>>>>> <o> <o>
>>>>>>>>> <p> <p>
>>>>>>>>> <q> <q>
>>>>>>>>> <r> <r> // H spots some pattern and stops simulating
>>>>>>>>> <s>
>>>>>>>>> <t>
>>>>>>>>> <u>
>>>>>>>>> <v>
>>>>>>>>> <w>
>>>>>>>>> <x>
>>>>>>>>> <y>
>>>>>>>>> <z> // P(P) final state - it halts!
>>>>>>>>>
>>>>>>>>> So in PO language "the input to H(P,P)" is (P,P), and this determines
>>>>>>>>> the steps of the computation P(P) which are being calculated by the
>>>>>>>>> emulator in H, which calculates <a>...<r> then stops calculating because
>>>>>>>>> it spotted some pattern. [in PO terms, <a>...<r> are the x86
>>>>>>>>> instructions or their trace entries].
>>>>>>>>>
>>>>>>>>> "the input to H1(P,P)" is also (P,P), and this determines the steps of
>>>>>>>>> the computation P(P) which are being calculated by the emulator in H1,
>>>>>>>>> which calculates <a>...<r>...<z> then stops because final state [ret
>>>>>>>>> instruction] is reached.
>>>>>>>>>
>>>>>>>>> PO might try to deny that H1 calculates the same steps as H from <a> to
>>>>>>>>> <r>, or might agree. I don't think PO really understands what's
>>>>>>>>> happening in his own program. :)
>>>>>>>>>
>>>>>>>>> In PO language, perhaps, BOTH the above are "correct emulations" because
>>>>>>>>> the sequence of "x86 instruction transitions" <a> --> <b> etc. is
>>>>>>>>> correct on a step-by-step basis. (That would be consistent with his
>>>>>>>>> claim repeated 1000 times, that we can check the emulation is correct by
>>>>>>>>> comparing the machine code listings and verifying that emulation is
>>>>>>>>> [doing each instruction correctly].)
>>>>>>>>>
>>>>>>>>> H's decision to stop emulating is not (IMO) part of the emulation
>>>>>>>>> itself. (How could it be? but probably that's just a matter of agreeing
>>>>>>>>> the terms we're using.)
>>>>>>>>>
>>>>>>>>> Anyhow, he who would argue with PO would do well to pin PO down on his
>>>>>>>>> strange choice of phrases to avoid weeks or months of
>>>>>>>>> miscommunications. And you have to start by discovering /something/ you
>>>>>>>>> agree on... Just demanding he "defines all his terms" won't get far as
>>>>>>>>> he can't "define" anything properly. :)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Mike.
>>>>>>>>>
>>>>>>>> The input to H1(P,P) halts.
>>>>>>>> In this same computation the input to H(P,P)
>>>>>>>> would never reach its "ret" instruction in 1 to ∞ emulated steps.
>>>>>>>
>>>>>>> But the fixed algorithm of H, hereafter referred to as Ha and the P that call it referred to as Pa, does not simulate for an infinite number of steps. It simulates for a particular number of cycles.
>>>>>> _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]
>>>>>>
>>>>>> H correctly simulates its input until it determines that a correct
>>>>>> simulation of ∞ steps of this input would never reach the "ret"
>>>>>> instruction of this input.
>>>>>
>>>>> By definition, a correct simulation is performed by a UTM. UTM(_Infinite_Loop,"") does not halt. UTM(Pa,Pa) does halt, so Ha(Pa,Pa)==0 is wrong.
>>>> UTM(P,P) determines an execution trace of P that reaches its "ret"
>>>> instruction. Yet this is a deliberately deceptive example and you know
>>>> it. Here is an actual comparable example:
>>>
>>> It is not deceptive. It is the *definition* of a correct simulation.
>>>
>>>>
>>>> Emulate(P,P);
>>>>
>>>> void P(u32 x)
>>>> {
>>>> if (Emulate(x, x))
>>>> HERE: goto HERE;
>>>> return;
>>>> }
>>>
>>>
>>> What you call Emulate is Hn,
>> No I would not because the H means halt decider.
>>> and because of that, P is Pn. And Pn(Pn) does not halt, nor does Hn(Pn,Pn).
>>>
>>> So you're claiming that Ha(Pa,Pa)==0 is correct because Pn(Pn) does not halt.
>> When-so-ever any input to a simulating halt decider must have its
>> simulation aborted to prevent the infinite simulation of this input this
>> input is correctly determined to be a non-halting input.
>
> So when the input to Ha(Pa,Pa) is passed to UTM(Pa,Pa) we can see that the input halts without being aborted, therefore Ha(Pa,Pa)==0 is wrong.
>
>>
>> H(P,P) determines the infinite behavior of Hn(P,P) in a few steps thus
>> conclusively proving that its input never reaches its "ret" instruction
>> whether it aborts the simulation of this input or not.
>
> But Ha is seeing infinite behavior where none exists, as demonstrated by UTM(Pa,Pa) halting.

On 5/30/2022 9:50 AM, olcott wrote:
> On 5/30/2022 9:29 AM, Dennis Bush wrote:
>> On Monday, May 30, 2022 at 9:46:56 AM UTC-4, olcott wrote:
>>> On 5/30/2022 8:14 AM, Dennis Bush wrote:
>>>> On Monday, May 30, 2022 at 8:56:49 AM UTC-4, olcott wrote:
>>>>> On 5/29/2022 11:04 PM, Dennis Bush wrote:
>>>>>> On Sunday, May 29, 2022 at 11:42:27 PM UTC-4, olcott wrote:
>>>>>>> On 5/29/2022 7:44 PM, Dennis Bush wrote:
>>>>>>>> On Sunday, May 29, 2022 at 8:33:53 PM UTC-4, olcott wrote:
>>>>>>>>> On 5/29/2022 6:24 PM, Mike Terry wrote:
>>>>>>>>>> On 29/05/2022 22:56, André G. Isaak wrote:
>>>>>>>>>>> On 2022-05-29 15:41, olcott wrote:
>>>>>>>>>>>> On 5/29/2022 4:30 PM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2022-05-29 15:16, olcott wrote:
>>>>>>>>>>>>>> On 5/29/2022 4:00 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>> On 2022-05-29 14:35, olcott wrote:
>>>>>>>>>>>>>>>> On 5/29/2022 2:58 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>> On 2022-05-29 13:26, olcott wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Agree. I think PO probably can't understand the proper
>>>>>>>>>>>>>>>>>>> definition of halting. That definition doesn't
>>>>>>>>>>>>>>>>>>> involve any
>>>>>>>>>>>>>>>>>>> UTMs or emulation - it's just a mathematical
>>>>>>>>>>>>>>>>>>> definition, first
>>>>>>>>>>>>>>>>>>> of the computation steps, then of halting in terms of
>>>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>>>> being an n such that computation step n is a final
>>>>>>>>>>>>>>>>>>> state of
>>>>>>>>>>>>>>>>>>> the TM. That's TOO ABSTRACT for PO, so all he can do is
>>>>>>>>>>>>>>>>>>> replace it with something he thinks he /can/ understand:
>>>>>>>>>>>>>>>>>>> something more concrete - a simulation run in some
>>>>>>>>>>>>>>>>>>> "actual
>>>>>>>>>>>>>>>>>>> machine" processing a TM description and tape
>>>>>>>>>>>>>>>>>>> description!
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE WITH ME
>>>>>>>>>>>>>>>>>> Every decider computes the mapping from its input finite
>>>>>>>>>>>>>>>>>> string(s) to an accept or reject state based on a
>>>>>>>>>>>>>>>>>> semantic or
>>>>>>>>>>>>>>>>>> syntactic property of this finite string.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Finite strings don't have semantic properties.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In computability theory, Rice's theorem states that all
>>>>>>>>>>>>>>>> non-trivial semantic properties of programs are
>>>>>>>>>>>>>>>> undecidable.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And how 'bout them Mets?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A semantic property is one about the program's behavior
>>>>>>>>>>>>>>>> (for
>>>>>>>>>>>>>>>> instance, does the program terminate for all inputs),
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Rice%27s_theorem
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In formal semantics this would be the semantic property
>>>>>>>>>>>>>>>> of a
>>>>>>>>>>>>>>>> finite string.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No, it would be a semantic property of the program. That
>>>>>>>>>>>>>>> program
>>>>>>>>>>>>>>> might be *represented* as a string, but the string itself
>>>>>>>>>>>>>>> has no
>>>>>>>>>>>>>>> semantic properties.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The semantic property of the string when it is interpreted
>>>>>>>>>>>>>> as the
>>>>>>>>>>>>>> description of a program.
>>>>>>>>>>>>>
>>>>>>>>>>>>> WHOOOSH!
>>>>>>>>>>>>>
>>>>>>>>>>>>> As soon you you add 'when it is interpreted as...' you are
>>>>>>>>>>>>> no longer
>>>>>>>>>>>>> talking about the string but the thing which the string
>>>>>>>>>>>>> represents.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Yes. The string has no semantics on its own.
>>>>>>>>>>>>
>>>>>>>>>>>> The input to H(P,P) determines (Mike's word) an execution
>>>>>>>>>>>> trace of
>>>>>>>>>>>> x86 instructions when correctly emulated by H.
>>>>>>>>>>>>
>>>>>>>>>>>> The input to H1(P,P) determines (Mike's word) an execution
>>>>>>>>>>>> trace of
>>>>>>>>>>>> x86 instructions when correctly emulated by H1.
>>>>>>>>>>>
>>>>>>>>>>> And neither of those sentences make any sense. Replacing
>>>>>>>>>>> 'specifies'
>>>>>>>>>>> with 'determines' doesn't make things any clearer. You need to
>>>>>>>>>>> actually DEFINE your terms.
>>>>>>>>>>>
>>>>>>>>>>>> These execution traces are not the same.
>>>>>>>>>>> Which means at least one of the above programs is *not*
>>>>>>>>>>> interpreting
>>>>>>>>>>> its input in the correct way, i.e. in the way which the
>>>>>>>>>>> specification
>>>>>>>>>>> of a halt decider demands.
>>>>>>>>>>
>>>>>>>>>> Hows about...
>>>>>>>>>>
>>>>>>>>>> Computation P(P) goes through a sequence of steps, which for
>>>>>>>>>> illustration I'll just refer to as <a> <b> ... <z> with <z>
>>>>>>>>>> being the
>>>>>>>>>> final (RET) step where the computation halts. Now, H and H1
>>>>>>>>>> calculate
>>>>>>>>>> these steps ["emulate their input"] something like this:
>>>>>>>>>>
>>>>>>>>>> H1 H
>>>>>>>>>> ---- ----
>>>>>>>>>> <a> <a> // P(P) very first state!
>>>>>>>>>> <b> <b>
>>>>>>>>>> <c> <c>
>>>>>>>>>> <d> <d>
>>>>>>>>>> <e> <e>
>>>>>>>>>> <f> <f>
>>>>>>>>>> <g> <g>
>>>>>>>>>> <h> <h>
>>>>>>>>>> <i> <i>
>>>>>>>>>> <j> <j>
>>>>>>>>>> <k> <k>
>>>>>>>>>> <l> <l> // no divergence so far!
>>>>>>>>>> <m> <m>
>>>>>>>>>> <n> <n>
>>>>>>>>>> <o> <o>
>>>>>>>>>> <p> <p>
>>>>>>>>>> <q> <q>
>>>>>>>>>> <r> <r> // H spots some pattern and stops simulating
>>>>>>>>>> <s>
>>>>>>>>>> <t>
>>>>>>>>>> <u>
>>>>>>>>>> <v>
>>>>>>>>>> <w>
>>>>>>>>>> <x>
>>>>>>>>>> <y>
>>>>>>>>>> <z> // P(P) final state - it halts!
>>>>>>>>>>
>>>>>>>>>> So in PO language "the input to H(P,P)" is (P,P), and this
>>>>>>>>>> determines
>>>>>>>>>> the steps of the computation P(P) which are being calculated
>>>>>>>>>> by the
>>>>>>>>>> emulator in H, which calculates <a>...<r> then stops
>>>>>>>>>> calculating because
>>>>>>>>>> it spotted some pattern. [in PO terms, <a>...<r> are the x86
>>>>>>>>>> instructions or their trace entries].
>>>>>>>>>>
>>>>>>>>>> "the input to H1(P,P)" is also (P,P), and this determines the
>>>>>>>>>> steps of
>>>>>>>>>> the computation P(P) which are being calculated by the
>>>>>>>>>> emulator in H1,
>>>>>>>>>> which calculates <a>...<r>...<z> then stops because final
>>>>>>>>>> state [ret
>>>>>>>>>> instruction] is reached.
>>>>>>>>>>
>>>>>>>>>> PO might try to deny that H1 calculates the same steps as H
>>>>>>>>>> from <a> to
>>>>>>>>>> <r>, or might agree. I don't think PO really understands what's
>>>>>>>>>> happening in his own program. :)
>>>>>>>>>>
>>>>>>>>>> In PO language, perhaps, BOTH the above are "correct
>>>>>>>>>> emulations" because
>>>>>>>>>> the sequence of "x86 instruction transitions" <a> --> <b> etc. is
>>>>>>>>>> correct on a step-by-step basis. (That would be consistent
>>>>>>>>>> with his
>>>>>>>>>> claim repeated 1000 times, that we can check the emulation is
>>>>>>>>>> correct by
>>>>>>>>>> comparing the machine code listings and verifying that
>>>>>>>>>> emulation is
>>>>>>>>>> [doing each instruction correctly].)
>>>>>>>>>>
>>>>>>>>>> H's decision to stop emulating is not (IMO) part of the emulation
>>>>>>>>>> itself. (How could it be? but probably that's just a matter of
>>>>>>>>>> agreeing
>>>>>>>>>> the terms we're using.)
>>>>>>>>>>
>>>>>>>>>> Anyhow, he who would argue with PO would do well to pin PO
>>>>>>>>>> down on his
>>>>>>>>>> strange choice of phrases to avoid weeks or months of
>>>>>>>>>> miscommunications. And you have to start by discovering
>>>>>>>>>> /something/ you
>>>>>>>>>> agree on... Just demanding he "defines all his terms" won't
>>>>>>>>>> get far as
>>>>>>>>>> he can't "define" anything properly. :)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Mike.
>>>>>>>>>>
>>>>>>>>> The input to H1(P,P) halts.
>>>>>>>>> In this same computation the input to H(P,P)
>>>>>>>>> would never reach its "ret" instruction in 1 to ∞ emulated steps.
>>>>>>>>
>>>>>>>> But the fixed algorithm of H, hereafter referred to as Ha and
>>>>>>>> the P that call it referred to as Pa, does not simulate for an
>>>>>>>> infinite number of steps. It simulates for a particular number
>>>>>>>> of cycles.
>>>>>>> _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]
>>>>>>>
>>>>>>> H correctly simulates its input until it determines that a correct
>>>>>>> simulation of ∞ steps of this input would never reach the "ret"
>>>>>>> instruction of this input.
>>>>>>
>>>>>> By definition, a correct simulation is performed by a UTM.
>>>>>> UTM(_Infinite_Loop,"") does not halt. UTM(Pa,Pa) does halt, so
>>>>>> Ha(Pa,Pa)==0 is wrong.
>>>>> UTM(P,P) determines an execution trace of P that reaches its "ret"
>>>>> instruction. Yet this is a deliberately deceptive example and you know
>>>>> it. Here is an actual comparable example:
>>>>
>>>> It is not deceptive. It is the *definition* of a correct simulation.
>>>>
>>>>>
>>>>> Emulate(P,P);
>>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>> if (Emulate(x, x))
>>>>> HERE: goto HERE;
>>>>> return;
>>>>> }
>>>>
>>>>
>>>> What you call Emulate is Hn,
>>> No I would not because the H means halt decider.
>>>> and because of that, P is Pn. And Pn(Pn) does not halt, nor does
>>>> Hn(Pn,Pn).
>>>>
>>>> So you're claiming that Ha(Pa,Pa)==0 is correct because Pn(Pn) does
>>>> not halt.
>>> When-so-ever any input to a simulating halt decider must have its
>>> simulation aborted to prevent the infinite simulation of this input this
>>> input is correctly determined to be a non-halting input.
>>
>> So when the input to Ha(Pa,Pa) is passed to UTM(Pa,Pa) we can see that
>> the input halts without being aborted, therefore Ha(Pa,Pa)==0 is wrong.
>>
>>>
>>> H(P,P) determines the infinite behavior of Hn(P,P) in a few steps thus
>>> conclusively proving that its input never reaches its "ret" instruction
>>> whether it aborts the simulation of this input or not.
>>
>> But Ha is seeing infinite behavior where none exists, as demonstrated
>> by UTM(Pa,Pa) halting.
>
> H(P,P) is seeing that its correctly simulated input would never reach
> the "ret" instruction of this input for the infinite set of different
> definitions of H that either abort their simulation at some point or
> never abort the simulation of their input.
>

On Monday, May 30, 2022 at 10:50:50 AM UTC-4, olcott wrote:
> On 5/30/2022 9:29 AM, Dennis Bush wrote:
> > On Monday, May 30, 2022 at 9:46:56 AM UTC-4, olcott wrote:
> >> On 5/30/2022 8:14 AM, Dennis Bush wrote:
> >>> On Monday, May 30, 2022 at 8:56:49 AM UTC-4, olcott wrote:
> >>>> On 5/29/2022 11:04 PM, Dennis Bush wrote:
> >>>>> On Sunday, May 29, 2022 at 11:42:27 PM UTC-4, olcott wrote:
> >>>>>> On 5/29/2022 7:44 PM, Dennis Bush wrote:
> >>>>>>> On Sunday, May 29, 2022 at 8:33:53 PM UTC-4, olcott wrote:
> >>>>>>>> On 5/29/2022 6:24 PM, Mike Terry wrote:
> >>>>>>>>> On 29/05/2022 22:56, André G. Isaak wrote:
> >>>>>>>>>> On 2022-05-29 15:41, olcott wrote:
> >>>>>>>>>>> On 5/29/2022 4:30 PM, André G. Isaak wrote:
> >>>>>>>>>>>> On 2022-05-29 15:16, olcott wrote:
> >>>>>>>>>>>>> On 5/29/2022 4:00 PM, André G. Isaak wrote:
> >>>>>>>>>>>>>> On 2022-05-29 14:35, olcott wrote:
> >>>>>>>>>>>>>>> On 5/29/2022 2:58 PM, André G. Isaak wrote:
> >>>>>>>>>>>>>>>> On 2022-05-29 13:26, olcott wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Agree. I think PO probably can't understand the proper
> >>>>>>>>>>>>>>>>>> definition of halting. That definition doesn't involve any
> >>>>>>>>>>>>>>>>>> UTMs or emulation - it's just a mathematical definition, first
> >>>>>>>>>>>>>>>>>> of the computation steps, then of halting in terms of there
> >>>>>>>>>>>>>>>>>> being an n such that computation step n is a final state of
> >>>>>>>>>>>>>>>>>> the TM. That's TOO ABSTRACT for PO, so all he can do is
> >>>>>>>>>>>>>>>>>> replace it with something he thinks he /can/ understand:
> >>>>>>>>>>>>>>>>>> something more concrete - a simulation run in some "actual
> >>>>>>>>>>>>>>>>>> machine" processing a TM description and tape description!
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE WITH ME
> >>>>>>>>>>>>>>>>> Every decider computes the mapping from its input finite
> >>>>>>>>>>>>>>>>> string(s) to an accept or reject state based on a semantic or
> >>>>>>>>>>>>>>>>> syntactic property of this finite string.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Finite strings don't have semantic properties.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> In computability theory, Rice's theorem states that all
> >>>>>>>>>>>>>>> non-trivial semantic properties of programs are undecidable.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> And how 'bout them Mets?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> A semantic property is one about the program's behavior (for
> >>>>>>>>>>>>>>> instance, does the program terminate for all inputs),
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Rice%27s_theorem
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> In formal semantics this would be the semantic property of a
> >>>>>>>>>>>>>>> finite string.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> No, it would be a semantic property of the program. That program
> >>>>>>>>>>>>>> might be *represented* as a string, but the string itself has no
> >>>>>>>>>>>>>> semantic properties.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> The semantic property of the string when it is interpreted as the
> >>>>>>>>>>>>> description of a program.
> >>>>>>>>>>>>
> >>>>>>>>>>>> WHOOOSH!
> >>>>>>>>>>>>
> >>>>>>>>>>>> As soon you you add 'when it is interpreted as...' you are no longer
> >>>>>>>>>>>> talking about the string but the thing which the string represents.
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Yes. The string has no semantics on its own.
> >>>>>>>>>>>
> >>>>>>>>>>> The input to H(P,P) determines (Mike's word) an execution trace of
> >>>>>>>>>>> x86 instructions when correctly emulated by H.
> >>>>>>>>>>>
> >>>>>>>>>>> The input to H1(P,P) determines (Mike's word) an execution trace of
> >>>>>>>>>>> x86 instructions when correctly emulated by H1.
> >>>>>>>>>>
> >>>>>>>>>> And neither of those sentences make any sense. Replacing 'specifies'
> >>>>>>>>>> with 'determines' doesn't make things any clearer. You need to
> >>>>>>>>>> actually DEFINE your terms.
> >>>>>>>>>>
> >>>>>>>>>>> These execution traces are not the same.
> >>>>>>>>>> Which means at least one of the above programs is *not* interpreting
> >>>>>>>>>> its input in the correct way, i.e. in the way which the specification
> >>>>>>>>>> of a halt decider demands.
> >>>>>>>>>
> >>>>>>>>> Hows about...
> >>>>>>>>>
> >>>>>>>>> Computation P(P) goes through a sequence of steps, which for
> >>>>>>>>> illustration I'll just refer to as <a> <b> ... <z> with <z> being the
> >>>>>>>>> final (RET) step where the computation halts. Now, H and H1 calculate
> >>>>>>>>> these steps ["emulate their input"] something like this:
> >>>>>>>>>
> >>>>>>>>> H1 H
> >>>>>>>>> ---- ----
> >>>>>>>>> <a> <a> // P(P) very first state!
> >>>>>>>>> <b> <b>
> >>>>>>>>> <c> <c>
> >>>>>>>>> <d> <d>
> >>>>>>>>> <e> <e>
> >>>>>>>>> <f> <f>
> >>>>>>>>> <g> <g>
> >>>>>>>>> <h> <h>
> >>>>>>>>> <i> <i>
> >>>>>>>>> <j> <j>
> >>>>>>>>> <k> <k>
> >>>>>>>>> <l> <l> // no divergence so far!
> >>>>>>>>> <m> <m>
> >>>>>>>>> <n> <n>
> >>>>>>>>> <o> <o>
> >>>>>>>>> <p> <p>
> >>>>>>>>> <q> <q>
> >>>>>>>>> <r> <r> // H spots some pattern and stops simulating
> >>>>>>>>> <s>
> >>>>>>>>> <t>
> >>>>>>>>> <u>
> >>>>>>>>> <v>
> >>>>>>>>> <w>
> >>>>>>>>> <x>
> >>>>>>>>> <y>
> >>>>>>>>> <z> // P(P) final state - it halts!
> >>>>>>>>>
> >>>>>>>>> So in PO language "the input to H(P,P)" is (P,P), and this determines
> >>>>>>>>> the steps of the computation P(P) which are being calculated by the
> >>>>>>>>> emulator in H, which calculates <a>...<r> then stops calculating because
> >>>>>>>>> it spotted some pattern. [in PO terms, <a>...<r> are the x86
> >>>>>>>>> instructions or their trace entries].
> >>>>>>>>>
> >>>>>>>>> "the input to H1(P,P)" is also (P,P), and this determines the steps of
> >>>>>>>>> the computation P(P) which are being calculated by the emulator in H1,
> >>>>>>>>> which calculates <a>...<r>...<z> then stops because final state [ret
> >>>>>>>>> instruction] is reached.
> >>>>>>>>>
> >>>>>>>>> PO might try to deny that H1 calculates the same steps as H from <a> to
> >>>>>>>>> <r>, or might agree. I don't think PO really understands what's
> >>>>>>>>> happening in his own program. :)
> >>>>>>>>>
> >>>>>>>>> In PO language, perhaps, BOTH the above are "correct emulations" because
> >>>>>>>>> the sequence of "x86 instruction transitions" <a> --> <b> etc. is
> >>>>>>>>> correct on a step-by-step basis. (That would be consistent with his
> >>>>>>>>> claim repeated 1000 times, that we can check the emulation is correct by
> >>>>>>>>> comparing the machine code listings and verifying that emulation is
> >>>>>>>>> [doing each instruction correctly].)
> >>>>>>>>>
> >>>>>>>>> H's decision to stop emulating is not (IMO) part of the emulation
> >>>>>>>>> itself. (How could it be? but probably that's just a matter of agreeing
> >>>>>>>>> the terms we're using.)
> >>>>>>>>>
> >>>>>>>>> Anyhow, he who would argue with PO would do well to pin PO down on his
> >>>>>>>>> strange choice of phrases to avoid weeks or months of
> >>>>>>>>> miscommunications. And you have to start by discovering /something/ you
> >>>>>>>>> agree on... Just demanding he "defines all his terms" won't get far as
> >>>>>>>>> he can't "define" anything properly. :)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Mike.
> >>>>>>>>>
> >>>>>>>> The input to H1(P,P) halts.
> >>>>>>>> In this same computation the input to H(P,P)
> >>>>>>>> would never reach its "ret" instruction in 1 to ∞ emulated steps.
> >>>>>>>
> >>>>>>> But the fixed algorithm of H, hereafter referred to as Ha and the P that call it referred to as Pa, does not simulate for an infinite number of steps. It simulates for a particular number of cycles.
> >>>>>> _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]
> >>>>>>
> >>>>>> H correctly simulates its input until it determines that a correct
> >>>>>> simulation of ∞ steps of this input would never reach the "ret"
> >>>>>> instruction of this input.
> >>>>>
> >>>>> By definition, a correct simulation is performed by a UTM. UTM(_Infinite_Loop,"") does not halt. UTM(Pa,Pa) does halt, so Ha(Pa,Pa)==0 is wrong.
> >>>> UTM(P,P) determines an execution trace of P that reaches its "ret"
> >>>> instruction. Yet this is a deliberately deceptive example and you know
> >>>> it. Here is an actual comparable example:
> >>>
> >>> It is not deceptive. It is the *definition* of a correct simulation.
> >>>
> >>>>
> >>>> Emulate(P,P);
> >>>>
> >>>> void P(u32 x)
> >>>> {
> >>>> if (Emulate(x, x))
> >>>> HERE: goto HERE;
> >>>> return;
> >>>> }
> >>>
> >>>
> >>> What you call Emulate is Hn,
> >> No I would not because the H means halt decider.
> >>> and because of that, P is Pn. And Pn(Pn) does not halt, nor does Hn(Pn,Pn).
> >>>
> >>> So you're claiming that Ha(Pa,Pa)==0 is correct because Pn(Pn) does not halt.
> >> When-so-ever any input to a simulating halt decider must have its
> >> simulation aborted to prevent the infinite simulation of this input this
> >> input is correctly determined to be a non-halting input.
> >
> > So when the input to Ha(Pa,Pa) is passed to UTM(Pa,Pa) we can see that the input halts without being aborted, therefore Ha(Pa,Pa)==0 is wrong.
> >
> >>
> >> H(P,P) determines the infinite behavior of Hn(P,P) in a few steps thus
> >> conclusively proving that its input never reaches its "ret" instruction
> >> whether it aborts the simulation of this input or not.
> >
> > But Ha is seeing infinite behavior where none exists, as demonstrated by UTM(Pa,Pa) halting.
> H(P,P) is seeing that its correctly simulated input

On 5/30/2022 9:54 AM, Dennis Bush wrote:
> On Monday, May 30, 2022 at 10:50:50 AM UTC-4, olcott wrote:
>> On 5/30/2022 9:29 AM, Dennis Bush wrote:
>>> On Monday, May 30, 2022 at 9:46:56 AM UTC-4, olcott wrote:
>>>> On 5/30/2022 8:14 AM, Dennis Bush wrote:
>>>>> On Monday, May 30, 2022 at 8:56:49 AM UTC-4, olcott wrote:
>>>>>> On 5/29/2022 11:04 PM, Dennis Bush wrote:
>>>>>>> On Sunday, May 29, 2022 at 11:42:27 PM UTC-4, olcott wrote:
>>>>>>>> On 5/29/2022 7:44 PM, Dennis Bush wrote:
>>>>>>>>> On Sunday, May 29, 2022 at 8:33:53 PM UTC-4, olcott wrote:
>>>>>>>>>> On 5/29/2022 6:24 PM, Mike Terry wrote:
>>>>>>>>>>> On 29/05/2022 22:56, André G. Isaak wrote:
>>>>>>>>>>>> On 2022-05-29 15:41, olcott wrote:
>>>>>>>>>>>>> On 5/29/2022 4:30 PM, André G. Isaak wrote:
>>>>>>>>>>>>>> On 2022-05-29 15:16, olcott wrote:
>>>>>>>>>>>>>>> On 5/29/2022 4:00 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>> On 2022-05-29 14:35, olcott wrote:
>>>>>>>>>>>>>>>>> On 5/29/2022 2:58 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>> On 2022-05-29 13:26, olcott wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Agree. I think PO probably can't understand the proper
>>>>>>>>>>>>>>>>>>>> definition of halting. That definition doesn't involve any
>>>>>>>>>>>>>>>>>>>> UTMs or emulation - it's just a mathematical definition, first
>>>>>>>>>>>>>>>>>>>> of the computation steps, then of halting in terms of there
>>>>>>>>>>>>>>>>>>>> being an n such that computation step n is a final state of
>>>>>>>>>>>>>>>>>>>> the TM. That's TOO ABSTRACT for PO, so all he can do is
>>>>>>>>>>>>>>>>>>>> replace it with something he thinks he /can/ understand:
>>>>>>>>>>>>>>>>>>>> something more concrete - a simulation run in some "actual
>>>>>>>>>>>>>>>>>>>> machine" processing a TM description and tape description!
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE WITH ME
>>>>>>>>>>>>>>>>>>> Every decider computes the mapping from its input finite
>>>>>>>>>>>>>>>>>>> string(s) to an accept or reject state based on a semantic or
>>>>>>>>>>>>>>>>>>> syntactic property of this finite string.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Finite strings don't have semantic properties.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> In computability theory, Rice's theorem states that all
>>>>>>>>>>>>>>>>> non-trivial semantic properties of programs are undecidable.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And how 'bout them Mets?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A semantic property is one about the program's behavior (for
>>>>>>>>>>>>>>>>> instance, does the program terminate for all inputs),
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Rice%27s_theorem
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> In formal semantics this would be the semantic property of a
>>>>>>>>>>>>>>>>> finite string.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No, it would be a semantic property of the program. That program
>>>>>>>>>>>>>>>> might be *represented* as a string, but the string itself has no
>>>>>>>>>>>>>>>> semantic properties.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The semantic property of the string when it is interpreted as the
>>>>>>>>>>>>>>> description of a program.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> WHOOOSH!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As soon you you add 'when it is interpreted as...' you are no longer
>>>>>>>>>>>>>> talking about the string but the thing which the string represents.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes. The string has no semantics on its own.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The input to H(P,P) determines (Mike's word) an execution trace of
>>>>>>>>>>>>> x86 instructions when correctly emulated by H.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The input to H1(P,P) determines (Mike's word) an execution trace of
>>>>>>>>>>>>> x86 instructions when correctly emulated by H1.
>>>>>>>>>>>>
>>>>>>>>>>>> And neither of those sentences make any sense. Replacing 'specifies'
>>>>>>>>>>>> with 'determines' doesn't make things any clearer. You need to
>>>>>>>>>>>> actually DEFINE your terms.
>>>>>>>>>>>>
>>>>>>>>>>>>> These execution traces are not the same.
>>>>>>>>>>>> Which means at least one of the above programs is *not* interpreting
>>>>>>>>>>>> its input in the correct way, i.e. in the way which the specification
>>>>>>>>>>>> of a halt decider demands.
>>>>>>>>>>>
>>>>>>>>>>> Hows about...
>>>>>>>>>>>
>>>>>>>>>>> Computation P(P) goes through a sequence of steps, which for
>>>>>>>>>>> illustration I'll just refer to as <a> <b> ... <z> with <z> being the
>>>>>>>>>>> final (RET) step where the computation halts. Now, H and H1 calculate
>>>>>>>>>>> these steps ["emulate their input"] something like this:
>>>>>>>>>>>
>>>>>>>>>>> H1 H
>>>>>>>>>>> ---- ----
>>>>>>>>>>> <a> <a> // P(P) very first state!
>>>>>>>>>>> <b> <b>
>>>>>>>>>>> <c> <c>
>>>>>>>>>>> <d> <d>
>>>>>>>>>>> <e> <e>
>>>>>>>>>>> <f> <f>
>>>>>>>>>>> <g> <g>
>>>>>>>>>>> <h> <h>
>>>>>>>>>>> <i> <i>
>>>>>>>>>>> <j> <j>
>>>>>>>>>>> <k> <k>
>>>>>>>>>>> <l> <l> // no divergence so far!
>>>>>>>>>>> <m> <m>
>>>>>>>>>>> <n> <n>
>>>>>>>>>>> <o> <o>
>>>>>>>>>>> <p> <p>
>>>>>>>>>>> <q> <q>
>>>>>>>>>>> <r> <r> // H spots some pattern and stops simulating
>>>>>>>>>>> <s>
>>>>>>>>>>> <t>
>>>>>>>>>>> <u>
>>>>>>>>>>> <v>
>>>>>>>>>>> <w>
>>>>>>>>>>> <x>
>>>>>>>>>>> <y>
>>>>>>>>>>> <z> // P(P) final state - it halts!
>>>>>>>>>>>
>>>>>>>>>>> So in PO language "the input to H(P,P)" is (P,P), and this determines
>>>>>>>>>>> the steps of the computation P(P) which are being calculated by the
>>>>>>>>>>> emulator in H, which calculates <a>...<r> then stops calculating because
>>>>>>>>>>> it spotted some pattern. [in PO terms, <a>...<r> are the x86
>>>>>>>>>>> instructions or their trace entries].
>>>>>>>>>>>
>>>>>>>>>>> "the input to H1(P,P)" is also (P,P), and this determines the steps of
>>>>>>>>>>> the computation P(P) which are being calculated by the emulator in H1,
>>>>>>>>>>> which calculates <a>...<r>...<z> then stops because final state [ret
>>>>>>>>>>> instruction] is reached.
>>>>>>>>>>>
>>>>>>>>>>> PO might try to deny that H1 calculates the same steps as H from <a> to
>>>>>>>>>>> <r>, or might agree. I don't think PO really understands what's
>>>>>>>>>>> happening in his own program. :)
>>>>>>>>>>>
>>>>>>>>>>> In PO language, perhaps, BOTH the above are "correct emulations" because
>>>>>>>>>>> the sequence of "x86 instruction transitions" <a> --> <b> etc. is
>>>>>>>>>>> correct on a step-by-step basis. (That would be consistent with his
>>>>>>>>>>> claim repeated 1000 times, that we can check the emulation is correct by
>>>>>>>>>>> comparing the machine code listings and verifying that emulation is
>>>>>>>>>>> [doing each instruction correctly].)
>>>>>>>>>>>
>>>>>>>>>>> H's decision to stop emulating is not (IMO) part of the emulation
>>>>>>>>>>> itself. (How could it be? but probably that's just a matter of agreeing
>>>>>>>>>>> the terms we're using.)
>>>>>>>>>>>
>>>>>>>>>>> Anyhow, he who would argue with PO would do well to pin PO down on his
>>>>>>>>>>> strange choice of phrases to avoid weeks or months of
>>>>>>>>>>> miscommunications. And you have to start by discovering /something/ you
>>>>>>>>>>> agree on... Just demanding he "defines all his terms" won't get far as
>>>>>>>>>>> he can't "define" anything properly. :)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Mike.
>>>>>>>>>>>
>>>>>>>>>> The input to H1(P,P) halts.
>>>>>>>>>> In this same computation the input to H(P,P)
>>>>>>>>>> would never reach its "ret" instruction in 1 to ∞ emulated steps.
>>>>>>>>>
>>>>>>>>> But the fixed algorithm of H, hereafter referred to as Ha and the P that call it referred to as Pa, does not simulate for an infinite number of steps. It simulates for a particular number of cycles.
>>>>>>>> _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]
>>>>>>>>
>>>>>>>> H correctly simulates its input until it determines that a correct
>>>>>>>> simulation of ∞ steps of this input would never reach the "ret"
>>>>>>>> instruction of this input.
>>>>>>>
>>>>>>> By definition, a correct simulation is performed by a UTM. UTM(_Infinite_Loop,"") does not halt. UTM(Pa,Pa) does halt, so Ha(Pa,Pa)==0 is wrong.
>>>>>> UTM(P,P) determines an execution trace of P that reaches its "ret"
>>>>>> instruction. Yet this is a deliberately deceptive example and you know
>>>>>> it. Here is an actual comparable example:
>>>>>
>>>>> It is not deceptive. It is the *definition* of a correct simulation.
>>>>>
>>>>>>
>>>>>> Emulate(P,P);
>>>>>>
>>>>>> void P(u32 x)
>>>>>> {
>>>>>> if (Emulate(x, x))
>>>>>> HERE: goto HERE;
>>>>>> return;
>>>>>> }
>>>>>
>>>>>
>>>>> What you call Emulate is Hn,
>>>> No I would not because the H means halt decider.
>>>>> and because of that, P is Pn. And Pn(Pn) does not halt, nor does Hn(Pn,Pn).
>>>>>
>>>>> So you're claiming that Ha(Pa,Pa)==0 is correct because Pn(Pn) does not halt.
>>>> When-so-ever any input to a simulating halt decider must have its
>>>> simulation aborted to prevent the infinite simulation of this input this
>>>> input is correctly determined to be a non-halting input.
>>>
>>> So when the input to Ha(Pa,Pa) is passed to UTM(Pa,Pa) we can see that the input halts without being aborted, therefore Ha(Pa,Pa)==0 is wrong.
>>>
>>>>
>>>> H(P,P) determines the infinite behavior of Hn(P,P) in a few steps thus
>>>> conclusively proving that its input never reaches its "ret" instruction
>>>> whether it aborts the simulation of this input or not.
>>>
>>> But Ha is seeing infinite behavior where none exists, as demonstrated by UTM(Pa,Pa) halting.
>> H(P,P) is seeing that its correctly simulated input
>
> I.E. the input when simulated by a UTM
>
>> would never reach
>> the "ret" instruction of this input for the infinite set of different
>> definitions of H that either abort their simulation at some point or
>> never abort the simulation of their input.
>
> So you're saying:
>
> Because Hn(Pn,Pn) does not halt,
> and H1(P1,P1)==0,
> and H2(P2,P2)==0,
> and H3(P3,P3)==0,
> and H4(P4,P4)==0,
> and H5(P5,P5)==0
> ....
> Then for all i, Hi(Pi,Pi)==0 is correct.
>
> This is invalid, since Pn and each Pi are different computations that are unrelated to each other.

On Monday, May 30, 2022 at 11:05:27 AM UTC-4, olcott wrote:
> On 5/30/2022 9:54 AM, Dennis Bush wrote:
> > On Monday, May 30, 2022 at 10:50:50 AM UTC-4, olcott wrote:
> >> On 5/30/2022 9:29 AM, Dennis Bush wrote:
> >>> On Monday, May 30, 2022 at 9:46:56 AM UTC-4, olcott wrote:
> >>>> On 5/30/2022 8:14 AM, Dennis Bush wrote:
> >>>>> On Monday, May 30, 2022 at 8:56:49 AM UTC-4, olcott wrote:
> >>>>>> On 5/29/2022 11:04 PM, Dennis Bush wrote:
> >>>>>>> On Sunday, May 29, 2022 at 11:42:27 PM UTC-4, olcott wrote:
> >>>>>>>> On 5/29/2022 7:44 PM, Dennis Bush wrote:
> >>>>>>>>> On Sunday, May 29, 2022 at 8:33:53 PM UTC-4, olcott wrote:
> >>>>>>>>>> On 5/29/2022 6:24 PM, Mike Terry wrote:
> >>>>>>>>>>> On 29/05/2022 22:56, André G. Isaak wrote:
> >>>>>>>>>>>> On 2022-05-29 15:41, olcott wrote:
> >>>>>>>>>>>>> On 5/29/2022 4:30 PM, André G. Isaak wrote:
> >>>>>>>>>>>>>> On 2022-05-29 15:16, olcott wrote:
> >>>>>>>>>>>>>>> On 5/29/2022 4:00 PM, André G. Isaak wrote:
> >>>>>>>>>>>>>>>> On 2022-05-29 14:35, olcott wrote:
> >>>>>>>>>>>>>>>>> On 5/29/2022 2:58 PM, André G. Isaak wrote:
> >>>>>>>>>>>>>>>>>> On 2022-05-29 13:26, olcott wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Agree. I think PO probably can't understand the proper
> >>>>>>>>>>>>>>>>>>>> definition of halting. That definition doesn't involve any
> >>>>>>>>>>>>>>>>>>>> UTMs or emulation - it's just a mathematical definition, first
> >>>>>>>>>>>>>>>>>>>> of the computation steps, then of halting in terms of there
> >>>>>>>>>>>>>>>>>>>> being an n such that computation step n is a final state of
> >>>>>>>>>>>>>>>>>>>> the TM. That's TOO ABSTRACT for PO, so all he can do is
> >>>>>>>>>>>>>>>>>>>> replace it with something he thinks he /can/ understand:
> >>>>>>>>>>>>>>>>>>>> something more concrete - a simulation run in some "actual
> >>>>>>>>>>>>>>>>>>>> machine" processing a TM description and tape description!
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE WITH ME
> >>>>>>>>>>>>>>>>>>> Every decider computes the mapping from its input finite
> >>>>>>>>>>>>>>>>>>> string(s) to an accept or reject state based on a semantic or
> >>>>>>>>>>>>>>>>>>> syntactic property of this finite string.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Finite strings don't have semantic properties.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> In computability theory, Rice's theorem states that all
> >>>>>>>>>>>>>>>>> non-trivial semantic properties of programs are undecidable.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> And how 'bout them Mets?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> A semantic property is one about the program's behavior (for
> >>>>>>>>>>>>>>>>> instance, does the program terminate for all inputs),
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Rice%27s_theorem
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> In formal semantics this would be the semantic property of a
> >>>>>>>>>>>>>>>>> finite string.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> No, it would be a semantic property of the program. That program
> >>>>>>>>>>>>>>>> might be *represented* as a string, but the string itself has no
> >>>>>>>>>>>>>>>> semantic properties.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The semantic property of the string when it is interpreted as the
> >>>>>>>>>>>>>>> description of a program.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> WHOOOSH!
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> As soon you you add 'when it is interpreted as...' you are no longer
> >>>>>>>>>>>>>> talking about the string but the thing which the string represents.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Yes. The string has no semantics on its own.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> The input to H(P,P) determines (Mike's word) an execution trace of
> >>>>>>>>>>>>> x86 instructions when correctly emulated by H.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> The input to H1(P,P) determines (Mike's word) an execution trace of
> >>>>>>>>>>>>> x86 instructions when correctly emulated by H1.
> >>>>>>>>>>>>
> >>>>>>>>>>>> And neither of those sentences make any sense. Replacing 'specifies'
> >>>>>>>>>>>> with 'determines' doesn't make things any clearer. You need to
> >>>>>>>>>>>> actually DEFINE your terms.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> These execution traces are not the same.
> >>>>>>>>>>>> Which means at least one of the above programs is *not* interpreting
> >>>>>>>>>>>> its input in the correct way, i.e. in the way which the specification
> >>>>>>>>>>>> of a halt decider demands.
> >>>>>>>>>>>
> >>>>>>>>>>> Hows about...
> >>>>>>>>>>>
> >>>>>>>>>>> Computation P(P) goes through a sequence of steps, which for
> >>>>>>>>>>> illustration I'll just refer to as <a> <b> ... <z> with <z> being the
> >>>>>>>>>>> final (RET) step where the computation halts. Now, H and H1 calculate
> >>>>>>>>>>> these steps ["emulate their input"] something like this:
> >>>>>>>>>>>
> >>>>>>>>>>> H1 H
> >>>>>>>>>>> ---- ----
> >>>>>>>>>>> <a> <a> // P(P) very first state!
> >>>>>>>>>>> <b> <b>
> >>>>>>>>>>> <c> <c>
> >>>>>>>>>>> <d> <d>
> >>>>>>>>>>> <e> <e>
> >>>>>>>>>>> <f> <f>
> >>>>>>>>>>> <g> <g>
> >>>>>>>>>>> <h> <h>
> >>>>>>>>>>> <i> <i>
> >>>>>>>>>>> <j> <j>
> >>>>>>>>>>> <k> <k>
> >>>>>>>>>>> <l> <l> // no divergence so far!
> >>>>>>>>>>> <m> <m>
> >>>>>>>>>>> <n> <n>
> >>>>>>>>>>> <o> <o>
> >>>>>>>>>>> <p> <p>
> >>>>>>>>>>> <q> <q>
> >>>>>>>>>>> <r> <r> // H spots some pattern and stops simulating
> >>>>>>>>>>> <s>
> >>>>>>>>>>> <t>
> >>>>>>>>>>> <u>
> >>>>>>>>>>> <v>
> >>>>>>>>>>> <w>
> >>>>>>>>>>> <x>
> >>>>>>>>>>> <y>
> >>>>>>>>>>> <z> // P(P) final state - it halts!
> >>>>>>>>>>>
> >>>>>>>>>>> So in PO language "the input to H(P,P)" is (P,P), and this determines
> >>>>>>>>>>> the steps of the computation P(P) which are being calculated by the
> >>>>>>>>>>> emulator in H, which calculates <a>...<r> then stops calculating because
> >>>>>>>>>>> it spotted some pattern. [in PO terms, <a>...<r> are the x86
> >>>>>>>>>>> instructions or their trace entries].
> >>>>>>>>>>>
> >>>>>>>>>>> "the input to H1(P,P)" is also (P,P), and this determines the steps of
> >>>>>>>>>>> the computation P(P) which are being calculated by the emulator in H1,
> >>>>>>>>>>> which calculates <a>...<r>...<z> then stops because final state [ret
> >>>>>>>>>>> instruction] is reached.
> >>>>>>>>>>>
> >>>>>>>>>>> PO might try to deny that H1 calculates the same steps as H from <a> to
> >>>>>>>>>>> <r>, or might agree. I don't think PO really understands what's
> >>>>>>>>>>> happening in his own program. :)
> >>>>>>>>>>>
> >>>>>>>>>>> In PO language, perhaps, BOTH the above are "correct emulations" because
> >>>>>>>>>>> the sequence of "x86 instruction transitions" <a> --> <b> etc.. is
> >>>>>>>>>>> correct on a step-by-step basis. (That would be consistent with his
> >>>>>>>>>>> claim repeated 1000 times, that we can check the emulation is correct by
> >>>>>>>>>>> comparing the machine code listings and verifying that emulation is
> >>>>>>>>>>> [doing each instruction correctly].)
> >>>>>>>>>>>
> >>>>>>>>>>> H's decision to stop emulating is not (IMO) part of the emulation
> >>>>>>>>>>> itself. (How could it be? but probably that's just a matter of agreeing
> >>>>>>>>>>> the terms we're using.)
> >>>>>>>>>>>
> >>>>>>>>>>> Anyhow, he who would argue with PO would do well to pin PO down on his
> >>>>>>>>>>> strange choice of phrases to avoid weeks or months of
> >>>>>>>>>>> miscommunications. And you have to start by discovering /something/ you
> >>>>>>>>>>> agree on... Just demanding he "defines all his terms" won't get far as
> >>>>>>>>>>> he can't "define" anything properly. :)
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Mike.
> >>>>>>>>>>>
> >>>>>>>>>> The input to H1(P,P) halts.
> >>>>>>>>>> In this same computation the input to H(P,P)
> >>>>>>>>>> would never reach its "ret" instruction in 1 to ∞ emulated steps.
> >>>>>>>>>
> >>>>>>>>> But the fixed algorithm of H, hereafter referred to as Ha and the P that call it referred to as Pa, does not simulate for an infinite number of steps. It simulates for a particular number of cycles.
> >>>>>>>> _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]
> >>>>>>>>
> >>>>>>>> H correctly simulates its input until it determines that a correct
> >>>>>>>> simulation of ∞ steps of this input would never reach the "ret"
> >>>>>>>> instruction of this input.
> >>>>>>>
> >>>>>>> By definition, a correct simulation is performed by a UTM. UTM(_Infinite_Loop,"") does not halt. UTM(Pa,Pa) does halt, so Ha(Pa,Pa)==0 is wrong.
> >>>>>> UTM(P,P) determines an execution trace of P that reaches its "ret"
> >>>>>> instruction. Yet this is a deliberately deceptive example and you know
> >>>>>> it. Here is an actual comparable example:
> >>>>>
> >>>>> It is not deceptive. It is the *definition* of a correct simulation..
> >>>>>
> >>>>>>
> >>>>>> Emulate(P,P);
> >>>>>>
> >>>>>> void P(u32 x)
> >>>>>> {
> >>>>>> if (Emulate(x, x))
> >>>>>> HERE: goto HERE;
> >>>>>> return;
> >>>>>> }
> >>>>>
> >>>>>
> >>>>> What you call Emulate is Hn,
> >>>> No I would not because the H means halt decider.
> >>>>> and because of that, P is Pn. And Pn(Pn) does not halt, nor does Hn(Pn,Pn).
> >>>>>
> >>>>> So you're claiming that Ha(Pa,Pa)==0 is correct because Pn(Pn) does not halt.
> >>>> When-so-ever any input to a simulating halt decider must have its
> >>>> simulation aborted to prevent the infinite simulation of this input this
> >>>> input is correctly determined to be a non-halting input.
> >>>
> >>> So when the input to Ha(Pa,Pa) is passed to UTM(Pa,Pa) we can see that the input halts without being aborted, therefore Ha(Pa,Pa)==0 is wrong.
> >>>
> >>>>
> >>>> H(P,P) determines the infinite behavior of Hn(P,P) in a few steps thus
> >>>> conclusively proving that its input never reaches its "ret" instruction
> >>>> whether it aborts the simulation of this input or not.
> >>>
> >>> But Ha is seeing infinite behavior where none exists, as demonstrated by UTM(Pa,Pa) halting.
> >> H(P,P) is seeing that its correctly simulated input
> >
> > I.E. the input when simulated by a UTM
> >
> >> would never reach
> >> the "ret" instruction of this input for the infinite set of different
> >> definitions of H that either abort their simulation at some point or
> >> never abort the simulation of their input.
> >
> > So you're saying:
> >
> > Because Hn(Pn,Pn) does not halt,
> > and H1(P1,P1)==0,
> > and H2(P2,P2)==0,
> > and H3(P3,P3)==0,
> > and H4(P4,P4)==0,
> > and H5(P5,P5)==0
> > ....
> > Then for all i, Hi(Pi,Pi)==0 is correct.
> >
> > This is invalid, since Pn and each Pi are different computations that are unrelated to each other.
> In every case where the emulated input to Hn(Pn,Pn) defines Pn that
> calls Hn(Pn,Pn) the emulated Pn never reaches its "ret" instruction.