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.

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.

> This is a big part of
> your confusion: You conflate strings with the things they represent,
> whereas others here draw a clear distinction between the two.
>
> Consider the following finite string:
>
> "TΗЕ QUΙСΚ ВRΟWΝ FОΧ ЈUΜРS ΟVЕR ТHΕ LАΖY DОG."
>
> That string has no semantic content at all. Only if you construe it as a
> representation of a sentence of English can you talk about semantic
> content, but that semantic content belongs to the sentence of English,
> not the string.
>
> You complain that when people ask a halt decider about P(P) they are
> asking about a 'non-input' since a computation is not a finite string.
>

In the same way that cars run on gasoline instead of spaghetti sauce a
decider only runs on finite strings, thus non-finite strings out
out-of-scope.

> At the same time you talk about the input specifying a sequence of
> configurations, but as soon as you talk about a sequence of
> configurations (or about the input 'specifying anything, for that
> matter) you too are no longer talking about finite strings; you are
> taking about

The execution trace of the behavior of the finite string when the finite
string would be correctly emulated by an x86 emulator.

> something which the string might potentially represent (I
> add "potentially" since you refuse to clarify your use of 'specify' --
> under my usage, and I suspect most other people's usage, the string
> doesn't represent such a thing).
>
> So you are just as guilty of having a machine answer about 'non-inputs'
> as everyone else is.
>
> André
>

--
Copyright 2022 Pete Olcott

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

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

When we use strings we almost invariably use them to represent other
things. In many contexts we don't clearly distinguish between a string
and the thing it represents, but when discussing formal systems or
computational theory it is important to do so. You don't seem to grasp
this distinction.

André

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

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.

> When we use strings we almost invariably use them to represent other
> things. In many contexts we don't clearly distinguish between a string
> and the thing it represents, but when discussing formal systems or
> computational theory it is important to do so. You don't seem to grasp
> this distinction.
>
> André
>

--
Copyright 2022 Pete Olcott

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

On 5/29/22 4:35 PM, 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.

* PROGRAM *

>
> A semantic property is one about the program's behavior (for instance,
> does the program terminate for all inputs),

* PROGRAM *

>
> https://en.wikipedia.org/wiki/Rice%27s_theorem
>
> In formal semantics this would be the semantic property of a finite string.

Where did it say "finite string"

We use a finite string to REPRESENT a program to a Turing Machine, but
the finite string is NOT "THe Program", and isn't what actually has the
property, that belongs to the program.

The string only "has" the property under the interpretation of what the
string represents.

>
>> This is a big part of your confusion: You conflate strings with the
>> things they represent, whereas others here draw a clear distinction
>> between the two.
>>
>> Consider the following finite string:
>>
>> "TΗЕ QUΙСΚ ВRΟWΝ FОΧ ЈUΜРS ΟVЕR ТHΕ LАΖY DОG."
>>
>> That string has no semantic content at all. Only if you construe it as
>> a representation of a sentence of English can you talk about semantic
>> content, but that semantic content belongs to the sentence of English,
>> not the string.
>>
>> You complain that when people ask a halt decider about P(P) they are
>> asking about a 'non-input' since a computation is not a finite string.
>>
>
> In the same way that cars run on gasoline instead of spaghetti sauce a
> decider only runs on finite strings, thus non-finite strings out
> out-of-scope.

Irrelevent.

>
>> At the same time you talk about the input specifying a sequence of
>> configurations, but as soon as you talk about a sequence of
>> configurations (or about the input 'specifying anything, for that
>> matter) you too are no longer talking about finite strings; you are
>> taking about
>
> The execution trace of the behavior of the finite string when the finite
> string would be correctly emulated by an x86 emulator.

The "finite String" only generates an execution trace when that string
is INTERPRETED as representing a PROGRAM.

The string itself, doesn't have meaning, just as a string of numbers
doesn't mean anything, but if considered to be the encoding of an
ASCII/UNICODE string of a sentence in English, it might have a meaning.

Again. "Strings" don't have properties in and of themselves. Only by
their interpretation of what they represent.

In the context of a given machine, that likey provides the needed
context for interpretation, but it still needs to be interpreted.

This is why P(P) is NOT a "Non-Input" for H, becuase it is EXACTLY what
the input H(P,P) REPRESENTS as the problem to solve.

FAIL.

>
>> something which the string might potentially represent (I add
>> "potentially" since you refuse to clarify your use of 'specify' --
>> under my usage, and I suspect most other people's usage, the string
>> doesn't represent such a thing).
>>
>> So you are just as guilty of having a machine answer about
>> 'non-inputs' as everyone else is.
>>
>> André
>>
>
>

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.

I'm trying to get you to understand a distinction which you clearly
don't understand. Instead of doubling down and insisting your wording
was somehow correct (it wasn't), why not try to actually grasp the
distinction which is being brought to your attention?

André

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

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.

These execution traces are not the same.

> I'm trying to get you to understand a distinction which you clearly
> don't understand. Instead of doubling down and insisting your wording
> was somehow correct (it wasn't), why not try to actually grasp the
> distinction which is being brought to your attention?
>
> André
>

--
Copyright 2022 Pete Olcott

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

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

André

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

On 5/29/22 5:41 PM, 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.
>
> These execution traces are not the same.

Except the HALTING PROBLEM ask about the trace of the ACTUAL PROGRAM,
i.e. the equivalent of the simulation by a UNIVERSALLY CORRECT simulator
(i.e. the UTM).

IF H's emulation differs from that, and the difference affects the
answer, then H is just WRONG as a Halting Decider.

>
>> I'm trying to get you to understand a distinction which you clearly
>> don't understand. Instead of doubling down and insisting your wording
>> was somehow correct (it wasn't), why not try to actually grasp the
>> distinction which is being brought to your attention?
>>
>> André
>>
>
>

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.

André G. Isaak <agisaak@gm.invalid> writes:

> On 2022-05-29 15:16, olcott wrote:
>> On 5/29/2022 4:00 PM, André G. Isaak wrote:
>>> On 2022-05-29 14:35, olcott wrote:
>>>> On 5/29/2022 2:58 PM, André G. Isaak wrote:
>>>>> On 2022-05-29 13:26, olcott wrote:
>>>>>
>>>>>>> Agree.  I think PO probably can't understand the proper definition of halting.  That definition doesn't involve any UTMs or emulation
>>>>>>> - it's just a mathematical definition, first of the computation steps, then of halting in terms of there being an n such that
>>>>>>> computation step n is a final state of the TM.  That's TOO ABSTRACT for PO, so all he can do is replace it with something he
>>>>>>> thinks he /can/ understand: something more concrete - a simulation run in some "actual machine" processing a TM description and tape
>>>>>>> description!
>>>>>>
>>>>>> HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE WITH ME
>>>>>> Every decider computes the mapping from its input finite string(s) to an accept or reject state based on a semantic or syntactic
>>>>>> property of this finite string.
>>>>>
>>>>> Finite strings don't have semantic properties.
>>>>
>>>>
>>>> In computability theory, Rice's theorem states that all non-trivial semantic properties of programs are undecidable.
>>>
>>> And how 'bout them Mets?
>>>
>>>> A semantic property is one about the program's behavior (for instance, does the program terminate for all inputs),
>>>>
>>>> https://en.wikipedia.org/wiki/Rice%27s_theorem
>>>>
>>>> In formal semantics this would be the semantic property of a finite string.
>>>
>>> No, it would be a semantic property of the program. That program might be *represented* as a string, but the string itself has no semantic
>>> properties.
>>>
>> The semantic property of the string when it is interpreted as the
>> description of a program.
>
> WHOOOSH!
>
> As soon you you add 'when it is interpreted as...' you are no longer
> talking about the string but the thing which the string represents.

One of the most frustrating things about talking to PO is that he drags
the discussion down to his level. Precisely stated, Rice's theorem is
not about strings or semantics. These terms just cover the discussion
in a sort of intellectual molasses. Rice's theorem is about subsets of
ℕ and partial recursive functions that enumerate them. It is sharp and
precise and involves no questions of interpretation and semantics does
not come into it. All of the wriggle and waffle room PO gives himself
comes from operating at the level of "The Ladybird Book of
Computability".

I know you know this, but I can't help noticing how effectively PO's
lack of knowledge and understanding ends up handicapping everyone else
rather then him.

--
Ben.

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?

A specific x86 emulator emulates P with input P.
This derives an execution trace of P with input P.
What part of this do you not understand?

--
Copyright 2022 Pete Olcott

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

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

Well, the problem is that false statements based on incorrect defintions
from never-learned-due-to-ignorance label any clarification of meaning
as learned-by-rote rigidness it makes it hard to discuss things. The
Dumb think that anyone who says something that they can't understand
must be dumber than them.

One interesting thing that I have figured out is that his core princple
that Analytic Statements are True by the Meaning of Their Words, coupled
with his claim that Mathematics Statements are Analytic Statements
appears to be provably false.

A simple counter example is the statement: The Square of the Length of
the Hypotonuse of a Right Triangle is Equal to the Sum of the Squares of
the Lengths of the Other Two Sides.

And the key twist is that IF you can come up with a way to prove it,
just from the words themselves, you have shown the method invalid,
because the statement ISN'T actually universally True, but is only true
if you accept Euclid's Fifth Postulate (or one of the equivalent
alternatives) into your system, and thus are working in the Standard
Plane Geometry. None of the words actually change meaning when we move
from Euclidean Plane Geometry to a Non-Euclidean Geometry, so the
"Meaning of the Words" can't be the deciding factor.

This seems to be one of the struggles of Philosophers once the Formal
Logic of Mathematics was able to prove that it doesn't follow some of
the principles they like logic to have. Either they need to admit that
Analytical Statements don't always have these properties, or let
Mathematics move outside the Analyitcal Fold by accepting that some of
its operations don't fit in their rules, and let Mathematics create a
form of Empirical Truth based on it showing that some things just are
using the "Sense of Thought".

PO, by avoiding the dangers of Learned-By-Rote, doesn't seem to be able
to actually understand these arguments and is still making the Century
old errors since he won't learn from history to avoid repeating it. (or
maybe he is just unable to understand the principles since they go
against his ingrained principles).

On 5/29/22 8:14 PM, 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?
>
> A specific x86 emulator emulates P with input P.
> This derives an execution trace of P with input P.
> What part of this do you not understand?
>

And how can that emulation be "Correct" if that execution trace differs
from the trace that you get from tracing the actual program P with input P.

That is the problem. You claim that H is correct in its degtermination
that its ABORTED trace shows that the correct trace of its input will
never reach the ret instruction, when the actual trace of that input
when continued past the point that H abandoned it, does reach that ret
instruction.

You have a conflict in your definitions, which means SOMETHING must be
wrong. How does H specify/determine that a correct trace stops when H
stopped it by anything other than that is just when it stopped.

If that is the definition, then a H0 that just stops right away would be
correct in saying that all computations are non-halting, becuase it
never got to the return instruction.

You need to actually DEFINE what you mean, and what it means to be correct.

Also, if your correct differs from the definiton that makes UTM
simulation THE correct one, then you can't switch your Halting Problem
Critera from looking at the actual machine to looking at a simulation.

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

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

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

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

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

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

--
Copyright 2022 Pete Olcott

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

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.

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

int main()
{ Output("Input_Halts = ", H1((u32)P, (u32)P));
}

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

_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6852130000 push 00001352 // push P
[0000137a](05) 6852130000 push 00001352 // push P
[0000137f](05) e81efcffff call 00000fa2 // call H1
[00001384](03) 83c408 add esp,+08
[00001387](01) 50 push eax
[00001388](05) 6823040000 push 00000423
[0000138d](05) e8e0f0ffff call 00000472
[00001392](03) 83c408 add esp,+08
[00001395](02) 33c0 xor eax,eax
[00001397](01) 5d pop ebp
[00001398](01) c3 ret
Size in bytes:(0039) [00001398]

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. And in the context of its abort criteria, Ha is unable to simulate to a final state.

So what you're actually saying is that because Ha(Pa,Pa) cannot simulate to a final state then Ha(Pa,Pa)==0 is correct. By this same logic, because Ha3(N,5) cannot simulate to a final state then Ha3(N,5)==0 is correct. This is obviously wrong, which means the fact that Ha(Pa,Pa) cannot simulate to a final state does not prove non-halting.

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. Therefore, it
appears to be the DECIDER as well as the input which determines the trace.

Then there is the whole issue of what 'correctly emulated' might mean to
you given that it clearly has no relationship to the behaviour of the
actual computation P(P).

André

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

On 5/29/22 8:33 PM, 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.
>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H1((u32)P, (u32)P));
> }
>
> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx
> [0000135d](05)  e840feffff      call 000011a2 // call H
> [00001362](03)  83c408          add esp,+08
> [00001365](02)  85c0            test eax,eax
> [00001367](02)  7402            jz 0000136b
> [00001369](02)  ebfe            jmp 00001369
> [0000136b](01)  5d              pop ebp
> [0000136c](01)  c3              ret
> Size in bytes:(0027) [0000136c]
>
> _main()
> [00001372](01)  55              push ebp
> [00001373](02)  8bec            mov ebp,esp
> [00001375](05)  6852130000      push 00001352 // push P
> [0000137a](05)  6852130000      push 00001352 // push P
> [0000137f](05)  e81efcffff      call 00000fa2 // call H1
> [00001384](03)  83c408          add esp,+08
> [00001387](01)  50              push eax
> [00001388](05)  6823040000      push 00000423
> [0000138d](05)  e8e0f0ffff      call 00000472
> [00001392](03)  83c408          add esp,+08
> [00001395](02)  33c0            xor eax,eax
> [00001397](01)  5d              pop ebp
> [00001398](01)  c3              ret
> Size in bytes:(0039) [00001398]
>
>
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> ...[00001372][0010229e][00000000] 55              push ebp
> ...[00001373][0010229e][00000000] 8bec            mov ebp,esp
> ...[00001375][0010229a][00001352] 6852130000      push 00001352 // push P
> ...[0000137a][00102296][00001352] 6852130000      push 00001352 // push P
> ...[0000137f][00102292][00001384] e81efcffff      call 00000fa2 // call H1
>
> Begin Local Halt Decider Simulation   Execution Trace Stored at:212352
> H1_Root:1
> ...[00001352][0021233e][00212342] 55              push ebp
> ...[00001353][0021233e][00212342] 8bec            mov ebp,esp
> ...[00001355][0021233e][00212342] 8b4508          mov eax,[ebp+08]
> ...[00001358][0021233a][00001352] 50              push eax      // push P
> ...[00001359][0021233a][00001352] 8b4d08          mov ecx,[ebp+08]
> ...[0000135c][00212336][00001352] 51              push ecx      // push P
> ...[0000135d][00212332][00001362] e840feffff      call 000011a2 // call H
>
> Begin Local Halt Decider Simulation   Execution Trace Stored at:25cd7a
> ...[00001352][0025cd66][0025cd6a] 55              push ebp
> ...[00001353][0025cd66][0025cd6a] 8bec            mov ebp,esp
> ...[00001355][0025cd66][0025cd6a] 8b4508          mov eax,[ebp+08]
> ...[00001358][0025cd62][00001352] 50              push eax      // push P
> ...[00001359][0025cd62][00001352] 8b4d08          mov ecx,[ebp+08]
> ...[0000135c][0025cd5e][00001352] 51              push ecx      // push P
> ...[0000135d][0025cd5a][00001362] e840feffff      call 000011a2 // call H
> ...[00001352][002a778e][002a7792] 55              push ebp
> ...[00001353][002a778e][002a7792] 8bec            mov ebp,esp
> ...[00001355][002a778e][002a7792] 8b4508          mov eax,[ebp+08]
> ...[00001358][002a778a][00001352] 50              push eax      // push P
> ...[00001359][002a778a][00001352] 8b4d08          mov ecx,[ebp+08]
> ...[0000135c][002a7786][00001352] 51              push ecx      // push P
> ...[0000135d][002a7782][00001362] e840feffff      call 000011a2 // call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
> ...[00001362][0021233e][00212342] 83c408          add esp,+08
> ...[00001365][0021233e][00212342] 85c0            test eax,eax
> ...[00001367][0021233e][00212342] 7402            jz 0000136b
> ...[0000136b][00212342][0000107a] 5d              pop ebp
> ...[0000136c][00212346][00001352] c3              ret
> ...[00001384][0010229e][00000000] 83c408          add esp,+08
> ...[00001387][0010229a][00000001] 50              push eax
> ...[00001388][00102296][00000423] 6823040000      push 00000423
> ---[0000138d][00102296][00000423] e8e0f0ffff      call 00000472
> Input_Halts = 1
> ...[00001392][0010229e][00000000] 83c408          add esp,+08
> ...[00001395][0010229e][00000000] 33c0            xor eax,eax
> ...[00001397][001022a2][00100000] 5d              pop ebp
> ...[00001398][001022a6][00000004] c3              ret
> Number of Instructions Executed(398230) = 5,944 pages
>
>

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

Nope.

>
> It is true that H(P,P)==0

Yes, H(P,P) returns 0.

You have NOT proved this is correct, and in fact, agree to facts that
make it incorrect.

Remember, the DEFINITION of a Halt Decider is H applied the input Wm w,
Where Wm is the description of the Turing Machine M, needs to accept if
M applied to w Halts and reject if M applied to w never Halts.

THAT is the definition.

With Simulatation defined per a UTM (where UTM apploied to Wm w has the
exact same behavior as M applied to w), you can convert this to using
simulation, but NOT for any other defintion without actually PROVING it
is equivalent.

You have AGREED that P(P) Halts.

Thus H(P,P) MUST accept the input, but it rejects it.

Thus H fails to meet the requirments.

PERIOD.

> It is true that P forms the required HP proof relationship to H.

Nope.

>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> Therefore it is true that I have refuted the HP proofs by making the
> undecidable input decidable.

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

Garbage.

You start from wrong defintions, so NOTHING you paper says has meaning
to the proof of the Theorem.

FAIL.

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?

We can see that the trace of the input to H1 halts and we can see that
the trace of the input to H(P,P) would never reach its "ret" instruction.

Which of those verified facts do you disagree with?

Do you not understand the x86 language?

The last time that I asked you this you said there is no such thing as
the x86 language.

x86 assembly language is the name for the family of assembly languages
which provide some level of backward compatibility with CPUs back to the
Intel 8008 microprocessor.
https://en.wikipedia.org/wiki/X86_assembly_language

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

int main()
{ Output("Input_Halts = ", H1((u32)P, (u32)P));
}

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

_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6852130000 push 00001352 // push P
[0000137a](05) 6852130000 push 00001352 // push P
[0000137f](05) e81efcffff call 00000fa2 // call H1
[00001384](03) 83c408 add esp,+08
[00001387](01) 50 push eax
[00001388](05) 6823040000 push 00000423
[0000138d](05) e8e0f0ffff call 00000472
[00001392](03) 83c408 add esp,+08
[00001395](02) 33c0 xor eax,eax
[00001397](01) 5d pop ebp
[00001398](01) c3 ret
Size in bytes:(0039) [00001398]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
....[00001372][0010229e][00000000] 55 push ebp
....[00001373][0010229e][00000000] 8bec mov ebp,esp
....[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
....[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
....[0000137f][00102292][00001384] e81efcffff call 00000fa2 // call H1

Begin Local Halt Decider Simulation Execution Trace Stored at:212352
H1_Root:1
....[00001352][0021233e][00212342] 55 push ebp
....[00001353][0021233e][00212342] 8bec mov ebp,esp
....[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
....[00001358][0021233a][00001352] 50 push eax // push P
....[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][00212336][00001352] 51 push ecx // push P
....[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

Begin Local Halt Decider Simulation Execution Trace Stored at:25cd7a
....[00001352][0025cd66][0025cd6a] 55 push ebp
....[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
....[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
....[00001358][0025cd62][00001352] 50 push eax // push P
....[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][0025cd5e][00001352] 51 push ecx // push P
....[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
....[00001352][002a778e][002a7792] 55 push ebp
....[00001353][002a778e][002a7792] 8bec mov ebp,esp
....[00001355][002a778e][002a7792] 8b4508 mov eax,[ebp+08]
....[00001358][002a778a][00001352] 50 push eax // push P
....[00001359][002a778a][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][002a7786][00001352] 51 push ecx // push P
....[0000135d][002a7782][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
....[00001362][0021233e][00212342] 83c408 add esp,+08
....[00001365][0021233e][00212342] 85c0 test eax,eax
....[00001367][0021233e][00212342] 7402 jz 0000136b
....[0000136b][00212342][0000107a] 5d pop ebp
....[0000136c][00212346][00001352] c3 ret
....[00001384][0010229e][00000000] 83c408 add esp,+08
....[00001387][0010229a][00000001] 50 push eax
....[00001388][00102296][00000423] 6823040000 push 00000423
---[0000138d][00102296][00000423] e8e0f0ffff call 00000472
Input_Halts = 1
....[00001392][0010229e][00000000] 83c408 add esp,+08
....[00001395][0010229e][00000000] 33c0 xor eax,eax
....[00001397][001022a2][00100000] 5d pop ebp
....[00001398][001022a6][00000004] c3 ret
Number of Instructions Executed(398230) = 5,944 pages

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.

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.

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.

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

On Sun, 29 May 2022 22:42:19 -0500
olcott <NoOne@NoWhere.com> wrote:

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