On 5/30/2022 10:41 AM, André G. Isaak wrote:
> On 2022-05-29 19:56, olcott wrote:
>> On 5/29/2022 7:51 PM, André G. Isaak wrote:
>>> On 2022-05-29 18:14, olcott wrote:
>>>> On 5/29/2022 4:56 PM, 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.
>>>>
>>>> I don't believe that you don't understand what that means.
>>>> What aspect of it do you not understand?
>>>
>>> Apart from your tortured syntax, it makes no sense to talk about the
>>> input determining the execution trace given that H1 and H are given
>>> the same input yet derive apparently produce different traces.
>>
>> So you simply "don't believe in" verified facts?
>
> Which "verified facts"?
>
> No one disputes that your H1 and H produce different traces. What is
> disputed is your preposterous claim that these are both involve
> *correct* simulations.

Yet when I challenge you to reverse-engineer the correct execution trace
of the input to H(P,P) under the assumption that H does correctly
emulate its input you dodge because you know this proves that I am correct.

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

--
Copyright 2022 Pete Olcott

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

On 5/30/22 11:05 AM, 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.
>

On 5/30/22 11:57 AM, olcott wrote:
> On 5/30/2022 10:41 AM, André G. Isaak wrote:
>> On 2022-05-29 19:56, olcott wrote:
>>> On 5/29/2022 7:51 PM, André G. Isaak wrote:
>>>> On 2022-05-29 18:14, olcott wrote:
>>>>> On 5/29/2022 4:56 PM, 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.
>>>>>
>>>>> I don't believe that you don't understand what that means.
>>>>> What aspect of it do you not understand?
>>>>
>>>> Apart from your tortured syntax, it makes no sense to talk about the
>>>> input determining the execution trace given that H1 and H are given
>>>> the same input yet derive apparently produce different traces.
>>>
>>> So you simply "don't believe in" verified facts?
>>
>> Which "verified facts"?
>>
>> No one disputes that your H1 and H produce different traces. What is
>> disputed is your preposterous claim that these are both involve
>> *correct* simulations.
>
> Yet when I challenge you to reverse-engineer the correct execution trace
> of the input to H(P,P) under the assumption that H does correctly
> emulate its input you dodge because you know this proves that I am correct.
>
> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax      // push P
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx      // push P
> [0000135d](05)  e840feffff      call 000011a2 // call H
> [00001362](03)  83c408          add esp,+08
> [00001365](02)  85c0            test eax,eax
> [00001367](02)  7402            jz 0000136b
> [00001369](02)  ebfe            jmp 00001369
> [0000136b](01)  5d              pop ebp
> [0000136c](01)  c3              ret
> Size in bytes:(0027) [0000136c]
>
>

Given that H MUST correct emulate its input, by definition, it can not
abort.

It will therefore simulate the first 7 instructions,

then simulate the simulation of the first 7 instructions,

then simulate the simulation of the simulation of the first 7 instructions,

and so on forever.

It can NOT "abort" the simulation and still meet the requirement of
being a correct emulation by the actual definition of that term.

Thus, H(P,P) never returns and H is proven to not be a decider.

Note, if ever H DOES abort and return 0 then the CORRECT emulation of
this input would be:

The simulation of the first 7 instructions.
The simulation of the simulation of the first 7 instuctions.
Repeat nesting of simulations until that first call to H decides to abort
The simulation of H returning 0
The simulation of the last instruction of P to its ret instruction.

THAT is the "CORRECT" emulation, but not the emulation of H, since it
broke its requirement to be an actual correct simulation.

Maybe it did a PO-Correct Simulation and showed that the input is
PO-Non-Halting, but that isn't interesting for the actual Halting Problem.

This is your problem, you don't know what the words actually mean.

On 5/30/22 9:46 AM, 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.

On 2022-05-30 09:57, olcott wrote:
> On 5/30/2022 10:41 AM, André G. Isaak wrote:
>> On 2022-05-29 19:56, olcott wrote:
>>> On 5/29/2022 7:51 PM, André G. Isaak wrote:
>>>> On 2022-05-29 18:14, olcott wrote:
>>>>> On 5/29/2022 4:56 PM, 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.
>>>>>
>>>>> I don't believe that you don't understand what that means.
>>>>> What aspect of it do you not understand?
>>>>
>>>> Apart from your tortured syntax, it makes no sense to talk about the
>>>> input determining the execution trace given that H1 and H are given
>>>> the same input yet derive apparently produce different traces.
>>>
>>> So you simply "don't believe in" verified facts?
>>
>> Which "verified facts"?
>>
>> No one disputes that your H1 and H produce different traces. What is
>> disputed is your preposterous claim that these are both involve
>> *correct* simulations.
>
> Yet when I challenge you to reverse-engineer the correct execution trace
> of the input to H(P,P) under the assumption that H does correctly
> emulate its input you dodge because you know this proves that I am correct.

Your "challenge" is entirely incoherent. You reverse-engineer things to
find out what they do, not whether they are correct. For the latter you
need some specification to compare it to [as I already stated in the
portion of my post which you dishonestly (as usual) snipped].

And what does it even mean to reverse engineer something "under that
[it] correctly" does something?

If I ask you to reverse-engineer photoshop under the assumption that it
correctly compresses audio, what exactly are you supposed to do?

André

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

On 5/30/2022 11:45 AM, André G. Isaak wrote:
> On 2022-05-30 09:57, olcott wrote:
>> On 5/30/2022 10:41 AM, André G. Isaak wrote:
>>> On 2022-05-29 19:56, olcott wrote:
>>>> On 5/29/2022 7:51 PM, André G. Isaak wrote:
>>>>> On 2022-05-29 18:14, olcott wrote:
>>>>>> On 5/29/2022 4:56 PM, 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.
>>>>>>
>>>>>> I don't believe that you don't understand what that means.
>>>>>> What aspect of it do you not understand?
>>>>>
>>>>> Apart from your tortured syntax, it makes no sense to talk about
>>>>> the input determining the execution trace given that H1 and H are
>>>>> given the same input yet derive apparently produce different traces.
>>>>
>>>> So you simply "don't believe in" verified facts?
>>>
>>> Which "verified facts"?
>>>
>>> No one disputes that your H1 and H produce different traces. What is
>>> disputed is your preposterous claim that these are both involve
>>> *correct* simulations.
>>
>> Yet when I challenge you to reverse-engineer the correct execution
>> trace of the input to H(P,P) under the assumption that H does
>> correctly emulate its input you dodge because you know this proves
>> that I am correct.
>
> Your "challenge" is entirely incoherent. You reverse-engineer things to
> find out what they do, not whether they are correct. For the latter you
> need some specification to compare it to [as I already stated in the
> portion of my post which you dishonestly (as usual) snipped].
>
> And what does it even mean to reverse engineer something "under that
> [it] correctly" does something?
>
> If I ask you to reverse-engineer photoshop under the assumption that it
> correctly compresses audio, what exactly are you supposed to do?
>
> André
>

In other words you have no idea that a correct emulation of the input to
H(P,P) would emulate the first seven instruction of P?

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

--
Copyright 2022 Pete Olcott

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

On 2022-05-30 10:50, olcott wrote:
> On 5/30/2022 11:45 AM, André G. Isaak wrote:
>> On 2022-05-30 09:57, olcott wrote:
>>> On 5/30/2022 10:41 AM, André G. Isaak wrote:
>>>> On 2022-05-29 19:56, olcott wrote:
>>>>> On 5/29/2022 7:51 PM, André G. Isaak wrote:
>>>>>> On 2022-05-29 18:14, olcott wrote:
>>>>>>> On 5/29/2022 4:56 PM, 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.
>>>>>>>
>>>>>>> I don't believe that you don't understand what that means.
>>>>>>> What aspect of it do you not understand?
>>>>>>
>>>>>> Apart from your tortured syntax, it makes no sense to talk about
>>>>>> the input determining the execution trace given that H1 and H are
>>>>>> given the same input yet derive apparently produce different traces.
>>>>>
>>>>> So you simply "don't believe in" verified facts?
>>>>
>>>> Which "verified facts"?
>>>>
>>>> No one disputes that your H1 and H produce different traces. What is
>>>> disputed is your preposterous claim that these are both involve
>>>> *correct* simulations.
>>>
>>> Yet when I challenge you to reverse-engineer the correct execution
>>> trace of the input to H(P,P) under the assumption that H does
>>> correctly emulate its input you dodge because you know this proves
>>> that I am correct.
>>
>> Your "challenge" is entirely incoherent. You reverse-engineer things
>> to find out what they do, not whether they are correct. For the latter
>> you need some specification to compare it to [as I already stated in
>> the portion of my post which you dishonestly (as usual) snipped].
>>
>> And what does it even mean to reverse engineer something "under that
>> [it] correctly" does something?
>>
>> If I ask you to reverse-engineer photoshop under the assumption that
>> it correctly compresses audio, what exactly are you supposed to do?
>>
>> André
>>
>
> In other words you have no idea that a correct emulation of the input to
> H(P,P) would emulate the first seven instruction of P?

A *correct* emulation of P(P) would emulate the exact same sequence of
instructions that occurs when you run P(P) directly, not just the first
seven instructions. Getting the first seven right doesn't make something
a "correct" emulation.

And your comment fails to address my point regarding the fact that you
need some specification to compare to before you can meaningfully talk
about something being "correct".

André

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

On 5/30/22 12:50 PM, olcott wrote:
> On 5/30/2022 11:45 AM, André G. Isaak wrote:
>> On 2022-05-30 09:57, olcott wrote:
>>> On 5/30/2022 10:41 AM, André G. Isaak wrote:
>>>> On 2022-05-29 19:56, olcott wrote:
>>>>> On 5/29/2022 7:51 PM, André G. Isaak wrote:
>>>>>> On 2022-05-29 18:14, olcott wrote:
>>>>>>> On 5/29/2022 4:56 PM, 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.
>>>>>>>
>>>>>>> I don't believe that you don't understand what that means.
>>>>>>> What aspect of it do you not understand?
>>>>>>
>>>>>> Apart from your tortured syntax, it makes no sense to talk about
>>>>>> the input determining the execution trace given that H1 and H are
>>>>>> given the same input yet derive apparently produce different traces.
>>>>>
>>>>> So you simply "don't believe in" verified facts?
>>>>
>>>> Which "verified facts"?
>>>>
>>>> No one disputes that your H1 and H produce different traces. What is
>>>> disputed is your preposterous claim that these are both involve
>>>> *correct* simulations.
>>>
>>> Yet when I challenge you to reverse-engineer the correct execution
>>> trace of the input to H(P,P) under the assumption that H does
>>> correctly emulate its input you dodge because you know this proves
>>> that I am correct.
>>
>> Your "challenge" is entirely incoherent. You reverse-engineer things
>> to find out what they do, not whether they are correct. For the latter
>> you need some specification to compare it to [as I already stated in
>> the portion of my post which you dishonestly (as usual) snipped].
>>
>> And what does it even mean to reverse engineer something "under that
>> [it] correctly" does something?
>>
>> If I ask you to reverse-engineer photoshop under the assumption that
>> it correctly compresses audio, what exactly are you supposed to do?
>>
>> André
>>
>
> In other words you have no idea that a correct emulation of the input to
> H(P,P) would emulate the first seven instruction of P?

No, it doesn't, it emulates ALL the instructions of P and everything it
calls until it reaches the ret instruciton.

THAT is the definition of a correct emulation.

The first 7 instrucitions would be only a PARTIAL emulation of P.

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

On 5/30/2022 11:56 AM, André G. Isaak wrote:
> On 2022-05-30 10:50, olcott wrote:
>> On 5/30/2022 11:45 AM, André G. Isaak wrote:
>>> On 2022-05-30 09:57, olcott wrote:
>>>> On 5/30/2022 10:41 AM, André G. Isaak wrote:
>>>>> On 2022-05-29 19:56, olcott wrote:
>>>>>> On 5/29/2022 7:51 PM, André G. Isaak wrote:
>>>>>>> On 2022-05-29 18:14, olcott wrote:
>>>>>>>> On 5/29/2022 4:56 PM, 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.
>>>>>>>>
>>>>>>>> I don't believe that you don't understand what that means.
>>>>>>>> What aspect of it do you not understand?
>>>>>>>
>>>>>>> Apart from your tortured syntax, it makes no sense to talk about
>>>>>>> the input determining the execution trace given that H1 and H are
>>>>>>> given the same input yet derive apparently produce different traces.
>>>>>>
>>>>>> So you simply "don't believe in" verified facts?
>>>>>
>>>>> Which "verified facts"?
>>>>>
>>>>> No one disputes that your H1 and H produce different traces. What
>>>>> is disputed is your preposterous claim that these are both involve
>>>>> *correct* simulations.
>>>>
>>>> Yet when I challenge you to reverse-engineer the correct execution
>>>> trace of the input to H(P,P) under the assumption that H does
>>>> correctly emulate its input you dodge because you know this proves
>>>> that I am correct.
>>>
>>> Your "challenge" is entirely incoherent. You reverse-engineer things
>>> to find out what they do, not whether they are correct. For the
>>> latter you need some specification to compare it to [as I already
>>> stated in the portion of my post which you dishonestly (as usual)
>>> snipped].
>>>
>>> And what does it even mean to reverse engineer something "under that
>>> [it] correctly" does something?
>>>
>>> If I ask you to reverse-engineer photoshop under the assumption that
>>> it correctly compresses audio, what exactly are you supposed to do?
>>>
>>> André
>>>
>>
>> In other words you have no idea that a correct emulation of the input
>> to H(P,P) would emulate the first seven instruction of P?
>
> A *correct* emulation of P(P) would emulate the exact same sequence of
> instructions that occurs when you run P(P) directly,

This is factually incorrect.
The first seven instructions are the same.
The next instructions are not the same.
You dodged my challenge because you already know this.

_P()
[00001341](01) 55 push ebp
[00001342](02) 8bec mov ebp,esp
[00001344](03) 8b4508 mov eax,[ebp+08]
[00001347](01) 50 push eax
[00001348](03) 8b4d08 mov ecx,[ebp+08]
[0000134b](01) 51 push ecx
[0000134c](05) e840feffff call 00001191
[00001351](03) 83c408 add esp,+08
[00001354](02) 85c0 test eax,eax
[00001356](02) 7402 jz 0000135a
[00001358](02) ebfe jmp 00001358
[0000135a](01) 5d pop ebp
[0000135b](01) c3 ret
Size in bytes:(0027) [0000135b]

On 5/30/2022 12:59 PM, olcott wrote:
> On 5/30/2022 11:56 AM, André G. Isaak wrote:
>> On 2022-05-30 10:50, olcott wrote:
>>> On 5/30/2022 11:45 AM, André G. Isaak wrote:
>>>> On 2022-05-30 09:57, olcott wrote:
>>>>> On 5/30/2022 10:41 AM, André G. Isaak wrote:
>>>>>> On 2022-05-29 19:56, olcott wrote:
>>>>>>> On 5/29/2022 7:51 PM, André G. Isaak wrote:
>>>>>>>> On 2022-05-29 18:14, olcott wrote:
>>>>>>>>> On 5/29/2022 4:56 PM, 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.
>>>>>>>>>
>>>>>>>>> I don't believe that you don't understand what that means.
>>>>>>>>> What aspect of it do you not understand?
>>>>>>>>
>>>>>>>> Apart from your tortured syntax, it makes no sense to talk about
>>>>>>>> the input determining the execution trace given that H1 and H
>>>>>>>> are given the same input yet derive apparently produce different
>>>>>>>> traces.
>>>>>>>
>>>>>>> So you simply "don't believe in" verified facts?
>>>>>>
>>>>>> Which "verified facts"?
>>>>>>
>>>>>> No one disputes that your H1 and H produce different traces. What
>>>>>> is disputed is your preposterous claim that these are both involve
>>>>>> *correct* simulations.
>>>>>
>>>>> Yet when I challenge you to reverse-engineer the correct execution
>>>>> trace of the input to H(P,P) under the assumption that H does
>>>>> correctly emulate its input you dodge because you know this proves
>>>>> that I am correct.
>>>>
>>>> Your "challenge" is entirely incoherent. You reverse-engineer things
>>>> to find out what they do, not whether they are correct. For the
>>>> latter you need some specification to compare it to [as I already
>>>> stated in the portion of my post which you dishonestly (as usual)
>>>> snipped].
>>>>
>>>> And what does it even mean to reverse engineer something "under that
>>>> [it] correctly" does something?
>>>>
>>>> If I ask you to reverse-engineer photoshop under the assumption that
>>>> it correctly compresses audio, what exactly are you supposed to do?
>>>>
>>>> André
>>>>
>>>
>>> In other words you have no idea that a correct emulation of the input
>>> to H(P,P) would emulate the first seven instruction of P?
>>
>> A *correct* emulation of P(P) would emulate the exact same sequence of
>> instructions that occurs when you run P(P) directly,
>
> This is factually incorrect.
> The first seven instructions are the same.
> The next instructions are not the same.
> You dodged my challenge because you already know this.
>

On 2022-05-30 11:59, olcott wrote:
> On 5/30/2022 11:56 AM, André G. Isaak wrote:

>> A *correct* emulation of P(P) would emulate the exact same sequence of
>> instructions that occurs when you run P(P) directly,
>
> This is factually incorrect.

How exactly? How would *you* define "correct emulation" if not as above?
You can propose whatever definition you want, but unless the rest of the
world accepts your definition you're not going to get anywhere.

> The first seven instructions are the same.
> The next instructions are not the same.

Yes. They diverge. That's what it MEANS to be an INcorrect emulation.

Your "argument" seems to be descending into depths of absurdity which I
did not think were possible even for you.

> You dodged my challenge because you already know this.

I already explained that your "challenge" is entirely incoherent. You,
of course, snipped that portion without addressing it at all.

André

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

On 5/30/22 1:59 PM, olcott wrote:
> On 5/30/2022 11:56 AM, André G. Isaak wrote:
>> On 2022-05-30 10:50, olcott wrote:
>>> On 5/30/2022 11:45 AM, André G. Isaak wrote:
>>>> On 2022-05-30 09:57, olcott wrote:
>>>>> On 5/30/2022 10:41 AM, André G. Isaak wrote:
>>>>>> On 2022-05-29 19:56, olcott wrote:
>>>>>>> On 5/29/2022 7:51 PM, André G. Isaak wrote:
>>>>>>>> On 2022-05-29 18:14, olcott wrote:
>>>>>>>>> On 5/29/2022 4:56 PM, 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.
>>>>>>>>>
>>>>>>>>> I don't believe that you don't understand what that means.
>>>>>>>>> What aspect of it do you not understand?
>>>>>>>>
>>>>>>>> Apart from your tortured syntax, it makes no sense to talk about
>>>>>>>> the input determining the execution trace given that H1 and H
>>>>>>>> are given the same input yet derive apparently produce different
>>>>>>>> traces.
>>>>>>>
>>>>>>> So you simply "don't believe in" verified facts?
>>>>>>
>>>>>> Which "verified facts"?
>>>>>>
>>>>>> No one disputes that your H1 and H produce different traces. What
>>>>>> is disputed is your preposterous claim that these are both involve
>>>>>> *correct* simulations.
>>>>>
>>>>> Yet when I challenge you to reverse-engineer the correct execution
>>>>> trace of the input to H(P,P) under the assumption that H does
>>>>> correctly emulate its input you dodge because you know this proves
>>>>> that I am correct.
>>>>
>>>> Your "challenge" is entirely incoherent. You reverse-engineer things
>>>> to find out what they do, not whether they are correct. For the
>>>> latter you need some specification to compare it to [as I already
>>>> stated in the portion of my post which you dishonestly (as usual)
>>>> snipped].
>>>>
>>>> And what does it even mean to reverse engineer something "under that
>>>> [it] correctly" does something?
>>>>
>>>> If I ask you to reverse-engineer photoshop under the assumption that
>>>> it correctly compresses audio, what exactly are you supposed to do?
>>>>
>>>> André
>>>>
>>>
>>> In other words you have no idea that a correct emulation of the input
>>> to H(P,P) would emulate the first seven instruction of P?
>>
>> A *correct* emulation of P(P) would emulate the exact same sequence of
>> instructions that occurs when you run P(P) directly,
>
> This is factually incorrect.

On 5/30/2022 2:17 PM, André G. Isaak wrote:
> On 2022-05-30 11:59, olcott wrote:
>> On 5/30/2022 11:56 AM, André G. Isaak wrote:
>
>>> A *correct* emulation of P(P) would emulate the exact same sequence
>>> of instructions that occurs when you run P(P) directly,
>>
>> This is factually incorrect.
>
> How exactly? How would *you* define "correct emulation" if not as above?
> You can propose whatever definition you want, but unless the rest of the
> world accepts your definition you're not going to get anywhere.
>
>> The first seven instructions are the same.
>> The next instructions are not the same.
>
> Yes. They diverge. That's what it MEANS to be an INcorrect emulation.
>

The x86 source-code of P proves that they must diverge.
When the executed P(P) calls H(P,P) it must return to P.

When the simulated input to H(P,P) calls H(P,P) it cannot return to P
because it keeps simulating the same first seven instructions of P until
aborted.

This would be clear to everyone with sufficient technical competence.
This would be clear to everyone with sufficient technical competence.
This would be clear to everyone with sufficient technical competence.
This would be clear to everyone with sufficient technical competence.
This would be clear to everyone with sufficient technical competence.

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

int main()
{ P(P);
}

_P()
[00001341](01) 55 push ebp
[00001342](02) 8bec mov ebp,esp
[00001344](03) 8b4508 mov eax,[ebp+08]
[00001347](01) 50 push eax
[00001348](03) 8b4d08 mov ecx,[ebp+08]
[0000134b](01) 51 push ecx
[0000134c](05) e840feffff call 00001191
[00001351](03) 83c408 add esp,+08
[00001354](02) 85c0 test eax,eax
[00001356](02) 7402 jz 0000135a
[00001358](02) ebfe jmp 00001358
[0000135a](01) 5d pop ebp
[0000135b](01) c3 ret
Size in bytes:(0027) [0000135b]

_main()
[00001361](01) 55 push ebp
[00001362](02) 8bec mov ebp,esp
[00001364](05) 6841130000 push 00001341
[00001369](05) e8d3ffffff call 00001341
[0000136e](03) 83c404 add esp,+04
[00001371](02) 33c0 xor eax,eax
[00001373](01) 5d pop ebp
[00001374](01) c3 ret
Size in bytes:(0020) [00001374]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
....[00001361][0010224a][00000000] 55 push ebp
....[00001362][0010224a][00000000] 8bec mov ebp,esp
....[00001364][00102246][00001341] 6841130000 push 00001341
....[00001369][00102242][0000136e] e8d3ffffff call 00001341
....[00001341][0010223e][0010224a] 55 push ebp
....[00001342][0010223e][0010224a] 8bec mov ebp,esp
....[00001344][0010223e][0010224a] 8b4508 mov eax,[ebp+08]
....[00001347][0010223a][00001341] 50 push eax
....[00001348][0010223a][00001341] 8b4d08 mov ecx,[ebp+08]
....[0000134b][00102236][00001341] 51 push ecx
....[0000134c][00102232][00001351] e840feffff call 00001191

Begin Local Halt Decider Simulation Execution Trace Stored at:2122fe
....[00001341][002122ea][002122ee] 55 push ebp
....[00001342][002122ea][002122ee] 8bec mov ebp,esp
....[00001344][002122ea][002122ee] 8b4508 mov eax,[ebp+08]
....[00001347][002122e6][00001341] 50 push eax
....[00001348][002122e6][00001341] 8b4d08 mov ecx,[ebp+08]
....[0000134b][002122e2][00001341] 51 push ecx
....[0000134c][002122de][00001351] e840feffff call 00001191

....[00001341][0025cd12][0025cd16] 55 push ebp
....[00001342][0025cd12][0025cd16] 8bec mov ebp,esp
....[00001344][0025cd12][0025cd16] 8b4508 mov eax,[ebp+08]
....[00001347][0025cd0e][00001341] 50 push eax
....[00001348][0025cd0e][00001341] 8b4d08 mov ecx,[ebp+08]
....[0000134b][0025cd0a][00001341] 51 push ecx
....[0000134c][0025cd06][00001351] e840feffff call 00001191
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
....[00001351][0010223e][0010224a] 83c408 add esp,+08
....[00001354][0010223e][0010224a] 85c0 test eax,eax
....[00001356][0010223e][0010224a] 7402 jz 0000135a
....[0000135a][00102242][0000136e] 5d pop ebp
....[0000135b][00102246][00001341] c3 ret
....[0000136e][0010224a][00000000] 83c404 add esp,+04
....[00001371][0010224a][00000000] 33c0 xor eax,eax
....[00001373][0010224e][00100000] 5d pop ebp
....[00001374][00102252][00000000] c3 ret
Number of Instructions Executed(15900)

--
Copyright 2022 Pete Olcott

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

On 5/30/22 6:57 PM, olcott wrote:
> On 5/30/2022 2:17 PM, André G. Isaak wrote:
>> On 2022-05-30 11:59, olcott wrote:
>>> On 5/30/2022 11:56 AM, André G. Isaak wrote:
>>
>>>> A *correct* emulation of P(P) would emulate the exact same sequence
>>>> of instructions that occurs when you run P(P) directly,
>>>
>>> This is factually incorrect.
>>
>> How exactly? How would *you* define "correct emulation" if not as
>> above? You can propose whatever definition you want, but unless the
>> rest of the world accepts your definition you're not going to get
>> anywhere.
>>
>>> The first seven instructions are the same.
>>> The next instructions are not the same.
>>
>> Yes. They diverge. That's what it MEANS to be an INcorrect emulation.
>>
>
> The x86 source-code of P proves that they must diverge.
> When the executed P(P) calls H(P,P) it must return to P.

Right.

>
> When the simulated input to H(P,P) calls H(P,P) it cannot return to P
> because it keeps simulating the same first seven instructions of P until
> aborted.

No, that presumes that the simulated H won't ever abort.

A CORRECT simulation of that input would see that H that P calls perform
its simulation, then the simulated H deciding to abort its simulaton,
and returning to P, just like the directly executed version did.

You error is presuming that H CAN correctly simulate this input and give
an answer.

If you assume an impossibility, you can get wrong answers, you need to
double check that you assumptions actually are possible.

The fact you fail to do this shows that you are a gross amateur at doing
logic. You Arguemnt begins with a false premis, that H can do a correct
simulation of its input and answer.ca

>
> This would be clear to everyone with sufficient technical competence.
> This would be clear to everyone with sufficient technical competence.
> This would be clear to everyone with sufficient technical competence.
> This would be clear to everyone with sufficient technical competence.
> This would be clear to everyone with sufficient technical competence.

No, it shows you are not technicall competent.

All it shows is that H can not correct simulate this input and deliver
ans answer at the same time.

>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   P(P);
> }
>
> _P()
> [00001341](01)  55              push ebp
> [00001342](02)  8bec            mov ebp,esp
> [00001344](03)  8b4508          mov eax,[ebp+08]
> [00001347](01)  50              push eax
> [00001348](03)  8b4d08          mov ecx,[ebp+08]
> [0000134b](01)  51              push ecx
> [0000134c](05)  e840feffff      call 00001191
> [00001351](03)  83c408          add esp,+08
> [00001354](02)  85c0            test eax,eax
> [00001356](02)  7402            jz 0000135a
> [00001358](02)  ebfe            jmp 00001358
> [0000135a](01)  5d              pop ebp
> [0000135b](01)  c3              ret
> Size in bytes:(0027) [0000135b]
>
> _main()
> [00001361](01)  55              push ebp
> [00001362](02)  8bec            mov ebp,esp
> [00001364](05)  6841130000      push 00001341
> [00001369](05)  e8d3ffffff      call 00001341
> [0000136e](03)  83c404          add esp,+04
> [00001371](02)  33c0            xor eax,eax
> [00001373](01)  5d              pop ebp
> [00001374](01)  c3              ret
> Size in bytes:(0020) [00001374]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> ...[00001361][0010224a][00000000] 55              push ebp
> ...[00001362][0010224a][00000000] 8bec            mov ebp,esp
> ...[00001364][00102246][00001341] 6841130000      push 00001341
> ...[00001369][00102242][0000136e] e8d3ffffff      call 00001341
> ...[00001341][0010223e][0010224a] 55              push ebp
> ...[00001342][0010223e][0010224a] 8bec            mov ebp,esp
> ...[00001344][0010223e][0010224a] 8b4508          mov eax,[ebp+08]
> ...[00001347][0010223a][00001341] 50              push eax
> ...[00001348][0010223a][00001341] 8b4d08          mov ecx,[ebp+08]
> ...[0000134b][00102236][00001341] 51              push ecx
> ...[0000134c][00102232][00001351] e840feffff      call 00001191
>
> Begin Local Halt Decider Simulation   Execution Trace Stored at:2122fe
> ...[00001341][002122ea][002122ee] 55              push ebp
> ...[00001342][002122ea][002122ee] 8bec            mov ebp,esp
> ...[00001344][002122ea][002122ee] 8b4508          mov eax,[ebp+08]
> ...[00001347][002122e6][00001341] 50              push eax
> ...[00001348][002122e6][00001341] 8b4d08          mov ecx,[ebp+08]
> ...[0000134b][002122e2][00001341] 51              push ecx
> ...[0000134c][002122de][00001351] e840feffff      call 00001191

And here is where the simulation goes wrong. After the call to 00001191,
the next instruction simulated needs to be the instruction at 00001191

>
> ...[00001341][0025cd12][0025cd16] 55              push ebp
> ...[00001342][0025cd12][0025cd16] 8bec            mov ebp,esp
> ...[00001344][0025cd12][0025cd16] 8b4508          mov eax,[ebp+08]
> ...[00001347][0025cd0e][00001341] 50              push eax
> ...[00001348][0025cd0e][00001341] 8b4d08          mov ecx,[ebp+08]
> ...[0000134b][0025cd0a][00001341] 51              push ecx
> ...[0000134c][0025cd06][00001351] e840feffff      call 00001191
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

And H just made an invalid conclusion because it did not use valid
inference rules, thus it got the wrong answer.

> ...[00001351][0010223e][0010224a] 83c408          add esp,+08
> ...[00001354][0010223e][0010224a] 85c0            test eax,eax
> ...[00001356][0010223e][0010224a] 7402            jz 0000135a
> ...[0000135a][00102242][0000136e] 5d              pop ebp
> ...[0000135b][00102246][00001341] c3              ret

And here we see that the correct simulation shows that P(P) halts, and
thus the CORRECT simulation of the input to H(P,P) will halt, since the
DEFINTION of the correct simulation IS what P(P) does.

> ...[0000136e][0010224a][00000000] 83c404          add esp,+04
> ...[00001371][0010224a][00000000] 33c0            xor eax,eax
> ...[00001373][0010224e][00100000] 5d              pop ebp
> ...[00001374][00102252][00000000] c3              ret
> Number of Instructions Executed(15900)
>

Thus, this above trae PROVES that P(P) Halts, and thus the correct
simulation of the input to H(P,P) Halts, and that H doesn't do a
"Correct Simulation" (at least by the rules of the Halting Problem) so
it got the wrohg answer.

On Monday, 30 May 2022 at 15:35:38 UTC+1, olcott wrote:
>
> When we assume a simulating halt decider then none of the simulated
> inputs to the conventional proofs ever reach their final state when
> correctly simulated by this simulating halt decider.
>
> That you don't understand this does not make it false.
>
We can't "assume a simulating halt decider" because the proof shows,
or at least claims to show, that a simulating halt decider can't exist.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> Wrote in message:r
> On Monday, 30 May 2022 at 15:35:38 UTC+1, olcott wrote:> > When we assume a simulating halt decider then none of the simulated > inputs to the conventional proofs ever reach their final state when > correctly simulated by this simulating halt decider. > > That you don't understand this does not make it false.

>We can't "assume a simulating halt decider" because the proof shows,or at least claims to show, that a simulating halt decider can't exist.

No proof shows that a simulating halt decider does not exist. A
simulating halt decider is a brand new idea that has never before
been thoroughly analyzed relative to the halting problem proofs.

--

----Android NewsGroup Reader----
https://piaohong.s3-us-west-2.amazonaws.com/usenet/index.html

On Tuesday, 31 May 2022 at 13:35:24 UTC+1, Malcolm McLean wrote:
> On Monday, 30 May 2022 at 15:35:38 UTC+1, olcott wrote:
> >
> > When we assume a simulating halt decider then none of the simulated
> > inputs to the conventional proofs ever reach their final state when
> > correctly simulated by this simulating halt decider.
> >
> > That you don't understand this does not make it false.
> >
> We can't "assume a simulating halt decider" because the proof shows,
> or at least claims to show, that a simulating halt decider can't exist.

On 5/31/2022 4:05 PM, Malcolm McLean wrote:
> On Tuesday, 31 May 2022 at 13:35:24 UTC+1, Malcolm McLean wrote:
>> On Monday, 30 May 2022 at 15:35:38 UTC+1, olcott wrote:
>>>
>>> When we assume a simulating halt decider then none of the simulated
>>> inputs to the conventional proofs ever reach their final state when
>>> correctly simulated by this simulating halt decider.
>>>
>>> That you don't understand this does not make it false.
>>>
>> We can't "assume a simulating halt decider" because the proof shows,
>> or at least claims to show, that a simulating halt decider can't exist.

None of the proofs bother to specifically examine simulating halt
deciders this is their big mistake. All of the proofs simply assume that
the execution trace of the input to H(P,P) reaches the
self-contradictory part. This is a provably false assumption.

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 5/31/22 6:23 PM, olcott wrote:
> On 5/31/2022 4:05 PM, Malcolm McLean wrote:
>> On Tuesday, 31 May 2022 at 13:35:24 UTC+1, Malcolm McLean wrote:
>>> On Monday, 30 May 2022 at 15:35:38 UTC+1, olcott wrote:
>>>>
>>>> When we assume a simulating halt decider then none of the simulated
>>>> inputs to the conventional proofs ever reach their final state when
>>>> correctly simulated by this simulating halt decider.
>>>>
>>>> That you don't understand this does not make it false.
>>>>
>>> We can't "assume a simulating halt decider" because the proof shows,
>>> or at least claims to show, that a simulating halt decider can't exist.
>
> None of the proofs bother to specifically examine simulating halt
> deciders this is their big mistake. All of the proofs simply assume that
> the execution trace of the input to H(P,P) reaches the
> self-contradictory part. This is a provably false assumption.
>

Because a simulating halt decider can't do something that NO halt
decider can do.

Your "Simulating Halt Decider" only gives what you call a correct answer
because it isn't actually a Halt Decider, bcuase it isn't computing the
Mapping of the Halting Problem.

Your H isn't a Halt Decider, but a POOP decider.

BY DEFINITION, A Halt Decider Accepts representations for ALL
Machine/Input Combinations that Halt, and Rejects representations for
ALL Machine/Inputs Combinations that never halt.

Since H^ applied to H^ (ala P(P)) Halts when H is given there
representation and answers that its input represents a Non-Halting
Computation, H is just WRONG as a Halt Decider.

If you can't represent that input to H, then it still fails, as you need
to be able to represent ALL Machine/Input combinations.

This is DEFINITIONALLY true.

Note, the definition NEVER mentions an "Executiom Trace", that is only a
transform allowed when the definition of simulation matches that of a
UTM where the simulation DOES match the direct execution.

Since you claim this isn't true of your simulation, you can't use that
transform, and so you are shown to NOT be working on the Halting Problem.

On Tuesday, 31 May 2022 at 23:23:15 UTC+1, olcott wrote:
> On 5/31/2022 4:05 PM, Malcolm McLean wrote:
> > On Tuesday, 31 May 2022 at 13:35:24 UTC+1, Malcolm McLean wrote:
> >> On Monday, 30 May 2022 at 15:35:38 UTC+1, olcott wrote:
> >>>
> >>> When we assume a simulating halt decider then none of the simulated
> >>> inputs to the conventional proofs ever reach their final state when
> >>> correctly simulated by this simulating halt decider.
> >>>
> >>> That you don't understand this does not make it false.
> >>>
> >> We can't "assume a simulating halt decider" because the proof shows,
> >> or at least claims to show, that a simulating halt decider can't exist.
> None of the proofs bother to specifically examine simulating halt
> deciders this is their big mistake. All of the proofs simply assume that
> the execution trace of the input to H(P,P) reaches the
> self-contradictory part. This is a provably false assumption.
>
And actually, what you have done is construct a simulating attempted halt
decider, which fails on H_Hat, for reasons unrelated to the invert loop.
So you have actually achieved something of interest, if you could only
recognise that.

On 5/31/2022 6:48 PM, Malcolm McLean wrote:
> On Tuesday, 31 May 2022 at 23:23:15 UTC+1, olcott wrote:
>> On 5/31/2022 4:05 PM, Malcolm McLean wrote:
>>> On Tuesday, 31 May 2022 at 13:35:24 UTC+1, Malcolm McLean wrote:
>>>> On Monday, 30 May 2022 at 15:35:38 UTC+1, olcott wrote:
>>>>>
>>>>> When we assume a simulating halt decider then none of the simulated
>>>>> inputs to the conventional proofs ever reach their final state when
>>>>> correctly simulated by this simulating halt decider.
>>>>>
>>>>> That you don't understand this does not make it false.
>>>>>
>>>> We can't "assume a simulating halt decider" because the proof shows,
>>>> or at least claims to show, that a simulating halt decider can't exist.
>> None of the proofs bother to specifically examine simulating halt
>> deciders this is their big mistake. All of the proofs simply assume that
>> the execution trace of the input to H(P,P) reaches the
>> self-contradictory part. This is a provably false assumption.
>>
> And actually, what you have done is construct a simulating attempted halt
> decider, which fails on H_Hat,

H(P,P) does correctly determine that its correctly simulated input never
reaches the "ret" input of the input. H_Hat is off topic because all of
my much clearer reasoning refers to H(P,P).

> for reasons unrelated to the invert loop.
> So you have actually achieved something of interest, if you could only
> recognise that.

I really have refuted all of the conventional halting problem proofs.

--
Copyright 2022 Pete Olcott

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

On Tue, 31 May 2022 19:26:25 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 5/31/2022 6:48 PM, Malcolm McLean wrote:
> > On Tuesday, 31 May 2022 at 23:23:15 UTC+1, olcott wrote:
> >> On 5/31/2022 4:05 PM, Malcolm McLean wrote:
> >>> On Tuesday, 31 May 2022 at 13:35:24 UTC+1, Malcolm McLean wrote:
> >>>> On Monday, 30 May 2022 at 15:35:38 UTC+1, olcott wrote:
> >>>>>
> >>>>> When we assume a simulating halt decider then none of the
> >>>>> simulated inputs to the conventional proofs ever reach their
> >>>>> final state when correctly simulated by this simulating halt
> >>>>> decider.
> >>>>>
> >>>>> That you don't understand this does not make it false.
> >>>>>
> >>>> We can't "assume a simulating halt decider" because the proof
> >>>> shows, or at least claims to show, that a simulating halt
> >>>> decider can't exist.
> >> None of the proofs bother to specifically examine simulating halt
> >> deciders this is their big mistake. All of the proofs simply
> >> assume that the execution trace of the input to H(P,P) reaches the
> >> self-contradictory part. This is a provably false assumption.
> >>
> > And actually, what you have done is construct a simulating
> > attempted halt decider, which fails on H_Hat,
>
> H(P,P) does correctly determine that its correctly simulated input
> never reaches the "ret" input of the input. H_Hat is off topic
> because all of my much clearer reasoning refers to H(P,P).
>
> > for reasons unrelated to the invert loop.
> > So you have actually achieved something of interest, if you could
> > only recognise that.
>
> I really have refuted all of the conventional halting problem proofs.

Not by detecting an infinite recursion you haven't as no such recursion
exists in those proofs.

/Flibble

On 5/31/22 8:26 PM, olcott wrote:
> On 5/31/2022 6:48 PM, Malcolm McLean wrote:
>> On Tuesday, 31 May 2022 at 23:23:15 UTC+1, olcott wrote:
>>> On 5/31/2022 4:05 PM, Malcolm McLean wrote:
>>>> On Tuesday, 31 May 2022 at 13:35:24 UTC+1, Malcolm McLean wrote:
>>>>> On Monday, 30 May 2022 at 15:35:38 UTC+1, olcott wrote:
>>>>>>
>>>>>> When we assume a simulating halt decider then none of the simulated
>>>>>> inputs to the conventional proofs ever reach their final state when
>>>>>> correctly simulated by this simulating halt decider.
>>>>>>
>>>>>> That you don't understand this does not make it false.
>>>>>>
>>>>> We can't "assume a simulating halt decider" because the proof shows,
>>>>> or at least claims to show, that a simulating halt decider can't
>>>>> exist.
>>> None of the proofs bother to specifically examine simulating halt
>>> deciders this is their big mistake. All of the proofs simply assume that
>>> the execution trace of the input to H(P,P) reaches the
>>> self-contradictory part. This is a provably false assumption.
>>>
>> And actually, what you have done is construct a simulating attempted halt
>> decider, which fails on H_Hat,
>
> H(P,P) does correctly determine that its correctly simulated input never
> reaches the "ret" input of the input. H_Hat is off topic because all of
> my much clearer reasoning refers to H(P,P).

Only with an incorrect definition of correctly simulated.

With YOUR definiton of "correctly simulated", you can't use "correctly
simulated" as a criteria of determining Halting, only the actual
behavior of the machines, which you admit your machine doesn't match.

>
>> for reasons unrelated to the invert loop.
>> So you have actually achieved something of interest, if you could only
>> recognise that.
>
> I really have refuted all of the conventional halting problem proofs.
>
>

Nope, just proved you don't understand how any of this works

On 5/31/2022 7:41 PM, Mr Flibble wrote:
> On Tue, 31 May 2022 19:26:25 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 5/31/2022 6:48 PM, Malcolm McLean wrote:
>>> On Tuesday, 31 May 2022 at 23:23:15 UTC+1, olcott wrote:
>>>> On 5/31/2022 4:05 PM, Malcolm McLean wrote:
>>>>> On Tuesday, 31 May 2022 at 13:35:24 UTC+1, Malcolm McLean wrote:
>>>>>> On Monday, 30 May 2022 at 15:35:38 UTC+1, olcott wrote:
>>>>>>>
>>>>>>> When we assume a simulating halt decider then none of the
>>>>>>> simulated inputs to the conventional proofs ever reach their
>>>>>>> final state when correctly simulated by this simulating halt
>>>>>>> decider.
>>>>>>>
>>>>>>> That you don't understand this does not make it false.
>>>>>>>
>>>>>> We can't "assume a simulating halt decider" because the proof
>>>>>> shows, or at least claims to show, that a simulating halt
>>>>>> decider can't exist.
>>>> None of the proofs bother to specifically examine simulating halt
>>>> deciders this is their big mistake. All of the proofs simply
>>>> assume that the execution trace of the input to H(P,P) reaches the
>>>> self-contradictory part. This is a provably false assumption.
>>>>
>>> And actually, what you have done is construct a simulating
>>> attempted halt decider, which fails on H_Hat,
>>
>> H(P,P) does correctly determine that its correctly simulated input
>> never reaches the "ret" input of the input. H_Hat is off topic
>> because all of my much clearer reasoning refers to H(P,P).
>>
>>> for reasons unrelated to the invert loop.
>>> So you have actually achieved something of interest, if you could
>>> only recognise that.
>>
>> I really have refuted all of the conventional halting problem proofs.
>
> Not by detecting an infinite recursion you haven't as no such recursion
> exists in those proofs.
>
> /Flibble
>

There is a behavior pattern that prevents the correctly emulated input
to H(P,P) from every reaching its "ret" instruction this is a sufficient
basis to correctly determine that the input to H(P,P) is non halting.

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

olcott <NoOne@NoWhere.com> Wrote in message:r
> On 5/24/2022 10:35 AM, Mikko wrote:> On 2022-05-24 14:40:02 +0000, olcott said:> >> Any smart software engineer with a sufficient technical background can >> easily confirm that H(P,P)==0 is correct:> > No "would" or "can" helps if they don't.> > Mikko> That I know this is an established fact simply proves that my reviewers here have outlived their usefulness.-- Copyright 2022 Pete Olcott"Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer

Test of android
--
test

----Android NewsGroup Reader----
https://piaohong.s3-us-west-2.amazonaws.com/usenet/index.html