On Tuesday, 23 August 2022 at 14:19:16 UTC+2, Paul N wrote:
> On Tuesday, August 23, 2022 at 12:21:07 AM UTC+1, richar...@gmail.com wrote:
> > On 8/22/22 10:31 AM, olcott wrote:
> > > It is common knowledge that the correct and complete simulation of a
> > > machine description always provides the actual behavior specified by
> > > this machine description.
> > >
> > Right, so why do you say it doesn't?
> The quote from Olcott above is highly misleading, as he is playing fast and loose with the definitions of such apparently simple terms as "actual behaviour" and "correct simulation".
>
> He accepts that the simulated P does not halt, and that the directly executed P does halt. However, for reasons he has failed to explain, he takes the "actual behavior" (his spelling) to be the former, even when the sentence has extra "actual"s in to apparently emphasise the point that he is talking about the actual behaviour.
>
> He also insists that his simulation is correct, despite (a) you pointing out problems with it (he describes this as "no-one has found an error") and (b) the fact that it is clearly giving the wrong results. He thinks the difference in the results is not due to an error in his simulator, but simply that everyone except him has wrongly assumed that a correct simulator will give the same results as the thing being simulated. He clearly doesn't use the term "correct simulation" the way most people do.
Said another way...

Olcott is coming from the perspective of Univalent Mathematics.

Take these two Python programs:

"while False: pass" <--- This one halts.
"while True: pass" <--- This one doesn't halt.

Now consider a (slight) modification to the source code of the Python interpreter such that the behavior of these two programs is reversed.
So lets call the default Python interpreter P, and the modified/reversed one R.

These two programs are identical - they don't halt: P("while True: pass") <=> R("while False: pass")
These two programs are identical - they both halt: P("while False: pass") <=> R("while True: pass")

In a nutshell True and False don't really mean anything. They are just arbitrary symbols which directly determine the halting behavior of P and R.

On 8/23/2022 7:19 AM, Paul N wrote:
> On Tuesday, August 23, 2022 at 12:21:07 AM UTC+1, richar...@gmail.com wrote:
>> On 8/22/22 10:31 AM, olcott wrote:
>>> It is common knowledge that the correct and complete simulation of a
>>> machine description always provides the actual behavior specified by
>>> this machine description.
>>>
>> Right, so why do you say it doesn't?
>
> The quote from Olcott above is highly misleading, as he is playing fast and loose with the definitions of such apparently simple terms as "actual behaviour" and "correct simulation".
>
> He accepts that the simulated P does not halt, and that the directly executed P does halt. However, for reasons he has failed to explain, he takes the "actual behavior" (his spelling) to be the former, even when the sentence has extra "actual"s in to apparently emphasise the point that he is talking about the actual behaviour.
>
> He also insists that his simulation is correct,

H(P,P) continues to perform a pure simulation of its input until it
correctly matches a behavior pattern that proves this would be the
behavior of the correctly and complete simulation of the input to H(P,P)

(a) H(P,P) simulates P(P) that calls a simulated H(P,P)
(b) that simulates P(P) that calls a simulated H(P,P)
(c) that simulates P(P) that calls a simulated H(P,P)
(d) that simulates P(P) that calls a simulated H(P,P)...

If you really want to see what the direct execution of P would be you
must put this direct execution of P(P) at the same point in the
execution trace as H(P,P)

void P(ptr x)
{ int Halt_Status = P(x);
if (Halt_Status)
HERE: goto HERE;
return;
}

(a) P(P) calls P(P)
(b) that calls P(P)
(c) that calls P(P)
(d) that calls P(P)...

> despite (a) you pointing out problems with it (he describes this as "no-one has found an error") and (b) the fact that it is clearly giving the wrong results. He thinks the difference in the results is not due to an error in his simulator,

I have proven that the execution trace of the simulation of the input to
H(P,P) exactly matches line-by-line the x86 source-code of P.

Apparently you have succumb to group-think so that when I conclusively
prove my point yet the opinion of other disagrees you go with incorrect
opinion instead of the proof.

> but simply that everyone except him has wrongly assumed that a correct simulator will give the same results as the thing being simulated. He clearly doesn't use the term "correct simulation" the way most people do.

I have proven that the execution trace of the simulation of the input by
H(P,P) exactly matches line-by-line the x86 source-code of P.

--
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 8/23/2022 3:15 AM, Mikko wrote:
> On 2022-08-22 15:24:08 +0000, olcott said:
>
>> Does the finite string input SPECIFY a sequence of INSTRUCTIONS that
>> reach their own final state?
>
> What the input string specifies depends on the interpretation. The
> question is not about the input string, the question is: "Does this
> Turing machine halt with this input?" and the input string must be
> constructed so that this question gets answered. How that is done
> is part of the required solution.
>
> Mikko
>

I have proven that the execution trace of the simulation of the input by
H(P,P) exactly matches line-by-line the x86 source-code of P and this
shows that the correct and complete simulation of this input never
reaches its final state and stops running:

(a) H(P,P) simulates P(P) that calls a simulated H(P,P)
(b) that simulates P(P) that calls a simulated H(P,P)
(c) that simulates P(P) that calls a simulated H(P,P)
(d) that simulates P(P) that calls a simulated H(P,P)...

--
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 8/23/2022 7:24 AM, Skep Dick wrote:
> On Tuesday, 23 August 2022 at 14:19:16 UTC+2, Paul N wrote:
>> On Tuesday, August 23, 2022 at 12:21:07 AM UTC+1, richar...@gmail.com wrote:
>>> On 8/22/22 10:31 AM, olcott wrote:
>>>> It is common knowledge that the correct and complete simulation of a
>>>> machine description always provides the actual behavior specified by
>>>> this machine description.
>>>>
>>> Right, so why do you say it doesn't?
>> The quote from Olcott above is highly misleading, as he is playing fast and loose with the definitions of such apparently simple terms as "actual behaviour" and "correct simulation".
>>
>> He accepts that the simulated P does not halt, and that the directly executed P does halt. However, for reasons he has failed to explain, he takes the "actual behavior" (his spelling) to be the former, even when the sentence has extra "actual"s in to apparently emphasise the point that he is talking about the actual behaviour.
>>
>> He also insists that his simulation is correct, despite (a) you pointing out problems with it (he describes this as "no-one has found an error") and (b) the fact that it is clearly giving the wrong results. He thinks the difference in the results is not due to an error in his simulator, but simply that everyone except him has wrongly assumed that a correct simulator will give the same results as the thing being simulated. He clearly doesn't use the term "correct simulation" the way most people do.
>
> None of that is actually true.
>
> What Olcott is doing is interpreting his terminology from the perspective of his own runtime (model of computation).
>
> The "actuaal behavior" of P is not specified; or rather - the actual behavior of P is unspecified and open to interpretation UNTIL one also specifies the semantics of the programming language; the runtime in which P is to be interpreted.
>
> does the program "while True: pass" halt? The question is meaningless without semantics.

// P does the opposite of whatever H decides
void P(ptr x)
{ int Halt_Status = H(x, x);
if (Halt_Status) // if H(P,P) reports that its input halts
HERE: goto HERE; // P loops and never halts
return; // else P halts
}

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

*BEHAVIOR OF THE CORRECT AND COMPLETE SIMULATION OF P(P) BY H*
(a) H(P,P) simulates P(P) that calls a simulated H(P,P)
(b) that simulates P(P) that calls a simulated H(P,P)
(c) that simulates P(P) that calls a simulated H(P,P)
(d) that simulates P(P) that calls a simulated H(P,P)...

Within the semantics of the C programming language

--
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 Tuesday, 23 August 2022 at 16:57:22 UTC+2, olcott wrote:
> On 8/23/2022 7:24 AM, Skep Dick wrote:
> > On Tuesday, 23 August 2022 at 14:19:16 UTC+2, Paul N wrote:
> >> On Tuesday, August 23, 2022 at 12:21:07 AM UTC+1, richar...@gmail.com wrote:
> >>> On 8/22/22 10:31 AM, olcott wrote:
> >>>> It is common knowledge that the correct and complete simulation of a
> >>>> machine description always provides the actual behavior specified by
> >>>> this machine description.
> >>>>
> >>> Right, so why do you say it doesn't?
> >> The quote from Olcott above is highly misleading, as he is playing fast and loose with the definitions of such apparently simple terms as "actual behaviour" and "correct simulation".
> >>
> >> He accepts that the simulated P does not halt, and that the directly executed P does halt. However, for reasons he has failed to explain, he takes the "actual behavior" (his spelling) to be the former, even when the sentence has extra "actual"s in to apparently emphasise the point that he is talking about the actual behaviour.
> >>
> >> He also insists that his simulation is correct, despite (a) you pointing out problems with it (he describes this as "no-one has found an error") and (b) the fact that it is clearly giving the wrong results. He thinks the difference in the results is not due to an error in his simulator, but simply that everyone except him has wrongly assumed that a correct simulator will give the same results as the thing being simulated. He clearly doesn't use the term "correct simulation" the way most people do.
> >
> > None of that is actually true.
> >
> > What Olcott is doing is interpreting his terminology from the perspective of his own runtime (model of computation).
> >
> > The "actuaal behavior" of P is not specified; or rather - the actual behavior of P is unspecified and open to interpretation UNTIL one also specifies the semantics of the programming language; the runtime in which P is to be interpreted.
> >
> > does the program "while True: pass" halt? The question is meaningless without semantics.
> // P does the opposite of whatever H decides
> void P(ptr x)
> {
> int Halt_Status = H(x, x);
> if (Halt_Status) // if H(P,P) reports that its input halts
> HERE: goto HERE; // P loops and never halts
> return; // else P halts
> }
>
> int main()
> {
> Output("Input_Halts = ", H(P, P));
> }
> *BEHAVIOR OF THE CORRECT AND COMPLETE SIMULATION OF P(P) BY H*
> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
> (b) that simulates P(P) that calls a simulated H(P,P)
> (c) that simulates P(P) that calls a simulated H(P,P)
> (d) that simulates P(P) that calls a simulated H(P,P)...
> Within the semantics of the C programming language

You are super confused (as always). You haven't presented any semantics for C. At least, you haven't presented the kind of semantics Mathematicians talk, and care about - denotational semantics.
Probably because nothing you've ever said relates to Categorical logic.

https://en.wikipedia.org/wiki/Categorical_logic

On 8/23/2022 10:15 AM, Skep Dick wrote:
> On Tuesday, 23 August 2022 at 16:57:22 UTC+2, olcott wrote:
>> On 8/23/2022 7:24 AM, Skep Dick wrote:
>>> On Tuesday, 23 August 2022 at 14:19:16 UTC+2, Paul N wrote:
>>>> On Tuesday, August 23, 2022 at 12:21:07 AM UTC+1, richar...@gmail.com wrote:
>>>>> On 8/22/22 10:31 AM, olcott wrote:
>>>>>> It is common knowledge that the correct and complete simulation of a
>>>>>> machine description always provides the actual behavior specified by
>>>>>> this machine description.
>>>>>>
>>>>> Right, so why do you say it doesn't?
>>>> The quote from Olcott above is highly misleading, as he is playing fast and loose with the definitions of such apparently simple terms as "actual behaviour" and "correct simulation".
>>>>
>>>> He accepts that the simulated P does not halt, and that the directly executed P does halt. However, for reasons he has failed to explain, he takes the "actual behavior" (his spelling) to be the former, even when the sentence has extra "actual"s in to apparently emphasise the point that he is talking about the actual behaviour.
>>>>
>>>> He also insists that his simulation is correct, despite (a) you pointing out problems with it (he describes this as "no-one has found an error") and (b) the fact that it is clearly giving the wrong results. He thinks the difference in the results is not due to an error in his simulator, but simply that everyone except him has wrongly assumed that a correct simulator will give the same results as the thing being simulated. He clearly doesn't use the term "correct simulation" the way most people do.
>>>
>>> None of that is actually true.
>>>
>>> What Olcott is doing is interpreting his terminology from the perspective of his own runtime (model of computation).
>>>
>>> The "actuaal behavior" of P is not specified; or rather - the actual behavior of P is unspecified and open to interpretation UNTIL one also specifies the semantics of the programming language; the runtime in which P is to be interpreted.
>>>
>>> does the program "while True: pass" halt? The question is meaningless without semantics.
>> // P does the opposite of whatever H decides
>> void P(ptr x)
>> {
>> int Halt_Status = H(x, x);
>> if (Halt_Status) // if H(P,P) reports that its input halts
>> HERE: goto HERE; // P loops and never halts
>> return; // else P halts
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H(P, P));
>> }
>> *BEHAVIOR OF THE CORRECT AND COMPLETE SIMULATION OF P(P) BY H*
>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>> (b) that simulates P(P) that calls a simulated H(P,P)
>> (c) that simulates P(P) that calls a simulated H(P,P)
>> (d) that simulates P(P) that calls a simulated H(P,P)...
>> Within the semantics of the C programming language
>
> You are super confused (as always). You haven't presented any semantics for C.

Likewise I have not provided any semantics for English either.

> At least, you haven't presented the kind of semantics Mathematicians talk, and care about - denotational semantics.

This semantics of the x86 model of computation provides the semantics
for this:

_P()
[00000fc2](01) 55 push ebp
[00000fc3](02) 8bec mov ebp,esp
[00000fc5](01) 51 push ecx
[00000fc6](03) 8b4508 mov eax,[ebp+08]
[00000fc9](01) 50 push eax // push P
[00000fca](03) 8b4d08 mov ecx,[ebp+08]
[00000fcd](01) 51 push ecx // push P
[00000fce](05) e8bffeffff call 00000e92 // call H
[00000fd3](03) 83c408 add esp,+08
[00000fd6](03) 8945fc mov [ebp-04],eax
[00000fd9](04) 837dfc00 cmp dword [ebp-04],+00
[00000fdd](02) 7402 jz 00000fe1
[00000fdf](02) ebfe jmp 00000fdf
[00000fe1](01) f4 hlt
[00000fe2](02) 8be5 mov esp,ebp
[00000fe4](01) 5d pop ebp
[00000fe5](01) c3 ret
Size in bytes:(0036) [00000fe5]

> Probably because nothing you've ever said relates to Categorical logic.
>

This is the way that logic was before symbolic logic and mathematical
logic screwed it up:
https://en.wikipedia.org/wiki/Syllogism#Basic_structure

> https://en.wikipedia.org/wiki/Categorical_logic
>

The basis for the syllogism

--
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 Tuesday, 23 August 2022 at 17:49:59 UTC+2, olcott wrote:
> This is the way that logic was before symbolic logic and mathematical
> logic screwed it up:
> https://en.wikipedia.org/wiki/Syllogism#Basic_structure
Idiot. There is no difference between Logic, Mathematics and Topology.

They are just different forms of computation.

https://ncatlab.org/nlab/show/computational+trilogy

On 8/23/2022 11:10 AM, Skep Dick wrote:
> On Tuesday, 23 August 2022 at 17:49:59 UTC+2, olcott wrote:
>> This is the way that logic was before symbolic logic and mathematical
>> logic screwed it up:
>> https://en.wikipedia.org/wiki/Syllogism#Basic_structure
> Idiot. There is no difference between Logic, Mathematics and Topology.
>
> They are just different forms of computation.
>
> https://ncatlab.org/nlab/show/computational+trilogy
>

The categorical logic of the syllogism retains the semantics of the
categories, both mathematical logic and symbolic logic make sure to
discard semantics and evaluate everything syntactically.

Correct reasoning requires that all proofs only apply truth preserving
operations to the premises thus they pass any truth value that these
premises might have along to the conclusion.

When the premises are false then the application of truth preserving
operations to these premises does not and cannot not propagate a truth
value of true to the conclusion.

This means that when "proof" is defined as applying truth preserving
operations to the premises then the Principle of explosion:

In classical logic, intuitionistic logic and similar logical systems,
the principle of explosion (Latin: ex falso [sequitur] quodlibet, 'from
falsehood, anything [follows]'; or ex contradictione [sequitur]
quodlibet, 'from contradiction, anything [follows]'),
https://en.wikipedia.org/wiki/Principle_of_explosion

Is incorrect.

--
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 Tuesday, August 23, 2022 at 3:50:37 PM UTC+1, olcott wrote:
> I have proven that the execution trace of the simulation of the input by
> H(P,P) exactly matches line-by-line the x86 source-code of P and this
> shows that the correct and complete simulation of this input never
> reaches its final state and stops running:
> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
> (b) that simulates P(P) that calls a simulated H(P,P)
> (c) that simulates P(P) that calls a simulated H(P,P)
> (d) that simulates P(P) that calls a simulated H(P,P)...

This is what would happen if H always simulated its input.

But H does not always simulate its input. So your "proof" above is invalid, because it is based on wrong assumptions of what H does.

On 8/23/2022 11:35 AM, Paul N wrote:
> On Tuesday, August 23, 2022 at 3:50:37 PM UTC+1, olcott wrote:
>> I have proven that the execution trace of the simulation of the input by
>> H(P,P) exactly matches line-by-line the x86 source-code of P and this
>> shows that the correct and complete simulation of this input never
>> reaches its final state and stops running:
>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>> (b) that simulates P(P) that calls a simulated H(P,P)
>> (c) that simulates P(P) that calls a simulated H(P,P)
>> (d) that simulates P(P) that calls a simulated H(P,P)...
>
> This is what would happen if H always simulated its input.
>
> But H does not always simulate its input.

void Infinite_Loop()
{ HERE: goto HERE;
}

int main()
{ Output("Input_Halts = ", H0((u32)Infinite_Loop));
}

_Infinite_Loop()
[00001102](01) 55 push ebp
[00001103](02) 8bec mov ebp,esp
[00001105](02) ebfe jmp 00001105
[00001107](01) 5d pop ebp
[00001108](01) c3 ret
Size in bytes:(0007) [00001108]

*This is what would happen if H always simulated its input*
*This is what would happen if H always simulated its input*
*This is what would happen if H always simulated its input*
*This is what would happen if H always simulated its input*

(a) H0(Infinite_Loop) simulates Infinite_Loop()
(b) goto HERE
(c) goto HERE
(d) goto HERE...

Yet a simulating halt decider must always abort the simulation of every
non-terminating input.

It does this as soon as it correctly matches a correct non-terminating
behavior.

This non-terminating behavior pattern is verified as correct when it
proves that a correct and complete simulation of this input would never
stop running.

--
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 Tuesday, 23 August 2022 at 18:33:52 UTC+2, olcott wrote:
> The categorical logic of the syllogism retains the semantics of the
> categories, both mathematical logic and symbolic logic make sure to
> discard semantics and evaluate everything syntactically.
That's literally nonsense if you even bothered to read a paragraph.

"In broad terms, categorical logic represents both syntax and semantics by a category, and an interpretation by a functor."

> Correct reasoning requires that all proofs only apply truth preserving
> operations to the premises thus they pass any truth value that these
> premises might have along to the conclusion.
"Correct" reasoning requires ONLY property-preservation, not truth-preservation.

Take these two functions.

In [1]: def P(x):
...: while x: pass
...:

In [2]: def R(x):
...: while not(x): pass
...:

P(True) <-> R(False) because it preserves the non-halting property.
P(False) <-> R(True) because it preserves the halting property.

> When the premises are false then the application of truth preserving
> operations to these premises does not and cannot not propagate a truth
> value of true to the conclusion.
"True" and "false" don't have any connotation! They are just two arbitrary values.

1/0, red/green, up/down, on/off.

You are confusing Boolean-True with the Philosophical notion of truth.

> This means that when "proof" is defined as applying truth preserving
> operations to the premises then the Principle of explosion:
Then don't define it like that. Define it as property-preserving operations.

Universal properties.
> In classical logic, intuitionistic logic and similar logical systems,
> the principle of explosion (Latin: ex falso [sequitur] quodlibet, 'from
> falsehood, anything [follows]'; or ex contradictione [sequitur]
> quodlibet, 'from contradiction, anything [follows]'),
> https://en.wikipedia.org/wiki/Principle_of_explosion
>
> Is incorrect.

It's a principle. it's neither correct nor incorrect.

You either use it; or you don't use it.

On 8/23/2022 12:08 PM, Skep Dick wrote:
> On Tuesday, 23 August 2022 at 18:33:52 UTC+2, olcott wrote:
>> The categorical logic of the syllogism retains the semantics of the
>> categories, both mathematical logic and symbolic logic make sure to
>> discard semantics and evaluate everything syntactically.
> That's literally nonsense if you even bothered to read a paragraph.
>
> "In broad terms, categorical logic represents both syntax and semantics by a category, and an interpretation by a functor."
>
>> Correct reasoning requires that all proofs only apply truth preserving
>> operations to the premises thus they pass any truth value that these
>> premises might have along to the conclusion.
> "Correct" reasoning requires ONLY property-preservation, not truth-preservation.
>
> Take these two functions.
>
> In [1]: def P(x):
> ...: while x: pass
> ...:
>
> In [2]: def R(x):
> ...: while not(x): pass
> ...:
>
> P(True) <-> R(False) because it preserves the non-halting property.
> P(False) <-> R(True) because it preserves the halting property.
>
>
>> When the premises are false then the application of truth preserving
>> operations to these premises does not and cannot not propagate a truth
>> value of true to the conclusion.
> "True" and "false" don't have any connotation! They are just two arbitrary values.
>
> 1/0, red/green, up/down, on/off.
>
> You are confusing Boolean-True with the Philosophical notion of truth.
>
>> This means that when "proof" is defined as applying truth preserving
>> operations to the premises then the Principle of explosion:
> Then don't define it like that. Define it as property-preserving operations.
>
> Universal properties.
>
>> In classical logic, intuitionistic logic and similar logical systems,
>> the principle of explosion (Latin: ex falso [sequitur] quodlibet, 'from
>> falsehood, anything [follows]'; or ex contradictione [sequitur]
>> quodlibet, 'from contradiction, anything [follows]'),
>> https://en.wikipedia.org/wiki/Principle_of_explosion
>>
>> Is incorrect.
>
> It's a principle. it's neither correct nor incorrect.

It stipulates that the truth value of the conclusion is a necessary
consequence of premises that are unrelated to this conclusion, this is
the non-sequitur error.

If categorical semantics were retained then this error would be more
obvious.

*Correct reasoning*
Major premise: All humans are mortal.
Minor premise: All Greeks are humans.
Conclusion: All Greeks are mortal.

*Here is the principle of explosion version*
Major premise: All humans are mortal.
Minor premise: All humans are immortal (not mortal).
Conclusion: The Moon is made from Green Cheese.

--
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-08-23 14:50:30 +0000, olcott said:

> On 8/23/2022 3:15 AM, Mikko wrote:
>> On 2022-08-22 15:24:08 +0000, olcott said:
>>
>>> Does the finite string input SPECIFY a sequence of INSTRUCTIONS that
>>> reach their own final state?
>>
>> What the input string specifies depends on the interpretation. The
>> question is not about the input string, the question is: "Does this
>> Turing machine halt with this input?" and the input string must be
>> constructed so that this question gets answered. How that is done
>> is part of the required solution.
>>
>> Mikko
>>
>
> I have proven that the execution trace of the simulation of the input
> by H(P,P) exactly matches line-by-line the x86 source-code of P and
> this shows that the correct and complete simulation of this input never
> reaches its final state and stops running:
>
> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
> (b) that simulates P(P) that calls a simulated H(P,P)
> (c) that simulates P(P) that calls a simulated H(P,P)
> (d) that simulates P(P) that calls a simulated H(P,P)...

Which does not contradict what I said.

Mikko

On 8/23/2022 3:15 AM, Mikko wrote:
> On 2022-08-22 15:24:08 +0000, olcott said:
>
>> Does the finite string input SPECIFY a sequence of INSTRUCTIONS that
>> reach their own final state?
>
> What the input string specifies depends on the interpretation. The
> question is not about the input string, the question is: "Does this
> Turing machine halt with this input?"

It is common knowledge that the correct and complete simulation of a
machine description always provides the actual behavior specified by
this machine description.

Thus the behavior of the input to H(P,P) is correctly measured by
the behavior of the correct and complete simulation by H(P,P) of its
input as shown below:

(a) H(P,P) simulates P(P) that calls a simulated H(P,P)
(b) that simulates P(P) that calls a simulated H(P,P)
(c) that simulates P(P) that calls a simulated H(P,P)
(d) that simulates P(P) that calls a simulated H(P,P)...

> and the input string must be
> constructed so that this question gets answered. How that is done
> is part of the required solution.
>
> Mikko
>

--
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 Tuesday, 23 August 2022 at 20:22:16 UTC+2, olcott wrote:
> It is common knowledge that the correct and complete simulation of a
> machine description always provides the actual behavior specified by
> this machine description.
That is 100% not true!

Does the syntactic description of the machine "f 1" in language P describe halting or non-halting behavior?

On 8/23/2022 1:31 PM, Skep Dick wrote:
> On Tuesday, 23 August 2022 at 20:22:16 UTC+2, olcott wrote:
>> It is common knowledge that the correct and complete simulation of a
>> machine description always provides the actual behavior specified by
>> this machine description.
> That is 100% not true!
>
> Does the syntactic description of the machine "f 1" in language P describe halting or non-halting behavior?
>
>

The semantics of the x86 language proves that the correct and complete
simulation of the input to H(P,P) by H proves that P remains stuck in
infinitely recursive simulation:

_P()
[00000fc2](01) 55 push ebp
[00000fc3](02) 8bec mov ebp,esp
[00000fc5](01) 51 push ecx
[00000fc6](03) 8b4508 mov eax,[ebp+08]
[00000fc9](01) 50 push eax // push P
[00000fca](03) 8b4d08 mov ecx,[ebp+08]
[00000fcd](01) 51 push ecx // push P
[00000fce](05) e8bffeffff call 00000e92 // call H
[00000fd3](03) 83c408 add esp,+08
[00000fd6](03) 8945fc mov [ebp-04],eax
[00000fd9](04) 837dfc00 cmp dword [ebp-04],+00
[00000fdd](02) 7402 jz 00000fe1
[00000fdf](02) ebfe jmp 00000fdf
[00000fe1](01) f4 hlt
[00000fe2](02) 8be5 mov esp,ebp
[00000fe4](01) 5d pop ebp
[00000fe5](01) c3 ret
Size in bytes:(0036) [00000fe5]

*In x86 this would be*
(a) H(P,P) simulates machine instructions [00000fc2] to [00000fce] that
calls H(P,P)

(b) that simulates machine instructions [00000fc2] to [00000fce] that
calls H(P,P)

(c) that simulates machine instructions [00000fc2] to [00000fce] that
calls H(P,P)

(d) that simulates machine instructions [00000fc2] to [00000fce] that
calls H(P,P)...

*In C this would be*
(a) H(P,P) simulates P(P) that calls a simulated H(P,P)
(b) that simulates P(P) that calls a simulated H(P,P)
(c) that simulates P(P) that calls a simulated H(P,P)
(d) that simulates P(P) that calls a simulated H(P,P)...

--
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 Tuesday, 23 August 2022 at 20:47:49 UTC+2, olcott wrote:
> The semantics of the x86 language proves that the correct and complete
x86 doesn't have denotational semantics.

On 8/23/2022 2:32 PM, Skep Dick wrote:
> On Tuesday, 23 August 2022 at 20:47:49 UTC+2, olcott wrote:
>> The semantics of the x86 language proves that the correct and complete
> x86 doesn't have denotational semantics.
>

The way that formal semantics works in computer programming is that the
behavior associated with finite strings of machine instruction is
specified.

Semantics describes the processes a computer follows when executing a
program in that specific language.

Operational semantics may define an abstract machine (such as the SECD
machine), and give meaning to phrases by describing the transitions they
induce on states of the machine.

https://en.wikipedia.org/wiki/Semantics_(computer_science)

H: Begin Simulation Execution Trace Stored at:11240b
[000013c6][001123f7][001123fb] 55 push ebp
[000013c7][001123f7][001123fb] 8bec mov ebp,esp
[000013c9][001123f3][001023c7] 51 push ecx // Save the
value of ecx on the stack
[000013ca][001123f3][001023c7] 8b4508 mov eax,[ebp+08] // Load eax
with argument to P
[000013cd][001123ef][000013c6] 50 push eax // push 2nd
argument to H onto the stack
[000013ce][001123ef][000013c6] 8b4d08 mov ecx,[ebp+08] // Load ecx
with with argument to P
[000013d1][001123eb][000013c6] 51 push ecx // push 1st
argument to H onto the stack
[000013d2][001123e7][000013d7] e82ffdffff call 00001106 // push
return address; call simulated H

--
Copyright 2022 Pete Olcott

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

On Tuesday, August 23, 2022 at 6:08:25 PM UTC+1, olcott wrote:
> On 8/23/2022 11:35 AM, Paul N wrote:
> > On Tuesday, August 23, 2022 at 3:50:37 PM UTC+1, olcott wrote:
> >> I have proven that the execution trace of the simulation of the input by
> >> H(P,P) exactly matches line-by-line the x86 source-code of P and this
> >> shows that the correct and complete simulation of this input never
> >> reaches its final state and stops running:
> >> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
> >> (b) that simulates P(P) that calls a simulated H(P,P)
> >> (c) that simulates P(P) that calls a simulated H(P,P)
> >> (d) that simulates P(P) that calls a simulated H(P,P)...
> >
> > This is what would happen if H always simulated its input.
> >
> > But H does not always simulate its input.
> void Infinite_Loop()
> {
> HERE: goto HERE;
> }
> int main()
> {
> Output("Input_Halts = ", H0((u32)Infinite_Loop));
> }
>
> _Infinite_Loop()
> [00001102](01) 55 push ebp
> [00001103](02) 8bec mov ebp,esp
> [00001105](02) ebfe jmp 00001105
> [00001107](01) 5d pop ebp
> [00001108](01) c3 ret
> Size in bytes:(0007) [00001108]
>
> *This is what would happen if H always simulated its input*
> *This is what would happen if H always simulated its input*
> *This is what would happen if H always simulated its input*
> *This is what would happen if H always simulated its input*

So it's not what happens with your actual H.

> (a) H0(Infinite_Loop) simulates Infinite_Loop()
> (b) goto HERE
> (c) goto HERE
> (d) goto HERE...
>
> Yet a simulating halt decider must always abort the simulation of every
> non-terminating input.
>
> It does this as soon as it correctly matches a correct non-terminating
> behavior.

But H(P, P) does not correctly match a non-terminating behaviour. The behaviour of P(P) is that it terminates, or so you claim.

> This non-terminating behavior pattern is verified as correct when it
> proves that a correct and complete simulation of this input would never
> stop running.

When you swap a running-forever H with an aborting H, you are no longer doing a correct simulation, because you are not simulating H correctly. Others have explained this in much greater detail.

On 8/23/2022 5:47 PM, Paul N wrote:
> On Tuesday, August 23, 2022 at 6:08:25 PM UTC+1, olcott wrote:
>> On 8/23/2022 11:35 AM, Paul N wrote:
>>> On Tuesday, August 23, 2022 at 3:50:37 PM UTC+1, olcott wrote:
>>>> I have proven that the execution trace of the simulation of the input by
>>>> H(P,P) exactly matches line-by-line the x86 source-code of P and this
>>>> shows that the correct and complete simulation of this input never
>>>> reaches its final state and stops running:
>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>
>>> This is what would happen if H always simulated its input.
>>>
>>> But H does not always simulate its input.
>> void Infinite_Loop()
>> {
>> HERE: goto HERE;
>> }
>> int main()
>> {
>> Output("Input_Halts = ", H0((u32)Infinite_Loop));
>> }
>>
>> _Infinite_Loop()
>> [00001102](01) 55 push ebp
>> [00001103](02) 8bec mov ebp,esp
>> [00001105](02) ebfe jmp 00001105
>> [00001107](01) 5d pop ebp
>> [00001108](01) c3 ret
>> Size in bytes:(0007) [00001108]
>>
>> *This is what would happen if H always simulated its input*
>> *This is what would happen if H always simulated its input*
>> *This is what would happen if H always simulated its input*
>> *This is what would happen if H always simulated its input*
>
> So it's not what happens with your actual H.
>
>> (a) H0(Infinite_Loop) simulates Infinite_Loop()
>> (b) goto HERE
>> (c) goto HERE
>> (d) goto HERE...
>>
>> Yet a simulating halt decider must always abort the simulation of every
>> non-terminating input.
>>
>> It does this as soon as it correctly matches a correct non-terminating
>> behavior.
>
> But H(P, P) does not correctly match a non-terminating behaviour. The behaviour of P(P) is that it terminates, or so you claim.

The correct and complete simulation by

int main()
{ Simulate(P,P);
}

Is an entirely different sequence of instructions than the correct and
complete simulation by H(P,P) of its input.

If you don't give a rat's ass about facts and truth I am done talking
with you.

>
>> This non-terminating behavior pattern is verified as correct when it
>> proves that a correct and complete simulation of this input would never
>> stop running.
>
> When you swap a running-forever H with an aborting H, you are no longer doing a correct simulation, because you are not simulating H correctly. Others have explained this in much greater detail.

--
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 8/23/22 8:24 AM, Skep Dick wrote:
> On Tuesday, 23 August 2022 at 14:19:16 UTC+2, Paul N wrote:
>> On Tuesday, August 23, 2022 at 12:21:07 AM UTC+1, richar...@gmail.com wrote:
>>> On 8/22/22 10:31 AM, olcott wrote:
>>>> It is common knowledge that the correct and complete simulation of a
>>>> machine description always provides the actual behavior specified by
>>>> this machine description.
>>>>
>>> Right, so why do you say it doesn't?
>> The quote from Olcott above is highly misleading, as he is playing fast and loose with the definitions of such apparently simple terms as "actual behaviour" and "correct simulation".
>>
>> He accepts that the simulated P does not halt, and that the directly executed P does halt. However, for reasons he has failed to explain, he takes the "actual behavior" (his spelling) to be the former, even when the sentence has extra "actual"s in to apparently emphasise the point that he is talking about the actual behaviour.
>>
>> He also insists that his simulation is correct, despite (a) you pointing out problems with it (he describes this as "no-one has found an error") and (b) the fact that it is clearly giving the wrong results. He thinks the difference in the results is not due to an error in his simulator, but simply that everyone except him has wrongly assumed that a correct simulator will give the same results as the thing being simulated. He clearly doesn't use the term "correct simulation" the way most people do.
>
> None of that is actually true.
>
> What Olcott is doing is interpreting his terminology from the perspective of his own runtime (model of computation).

No, because he SPEICIFICALLY points to the classic Halting Theorem and
Proof, and says that is framework he is working in.

>
> The "actuaal behavior" of P is not specified; or rather - the actual behavior of P is unspecified and open to interpretation UNTIL one also specifies the semantics of the programming language; the runtime in which P is to be interpreted.

Which he does (at times)

>
> does the program "while True: pass" halt? The question is meaningless without semantics.
>
>
>
>
>
>
>

On 8/23/22 8:02 AM, Skep Dick wrote:
> On Tuesday, 23 August 2022 at 13:46:15 UTC+2, richar...@gmail.com wrote:
>> On 8/23/22 7:38 AM, Skep Dick wrote:
>>> On Tuesday, 23 August 2022 at 13:17:13 UTC+2, richar...@gmail.com wrote:
>>>> Nope, that is INCORRECT because it disagrees with th ACTUAL meaning of Halting.
>>> Que?!? When you speak of "ACTUAL" meanings you must be refering to some kind of formal semantics.
>>>
>>> Are you assuming denotational, operational, axiomatic, reduction, natural, your own?
>>>
>>> There are so many possibilities. Why are you pretending that meaning is canonical? You must be assuming some model you aren't telling us about.
>>>
>>> Looks like you are stuck IN some theory. Need help getting out?
>>>
>> I am "Stuck" in the field of Classical Computation Theory and the
>> Halting Theorem, for THIS discussion.
>> That is the context of the whole discussion.
> Does this group say classical.comp.theory? No, it doesn't!

I didn't say this GROUP was just about classical computation theory (and
the name would be comp.theory.classical, you don't seem to even know the
naming conventions of the medium you are posting in),

I was saying that this PARTICULAR discussion, by the original posters
own declaration, is in the domain of classical computation theory.

>
> Why the fuck are you pretending that the the context of "computation" is fixed?

Because if you are talking about a SPECIFIC theory, you need to talking
within the field that the theory is framed in.

>
>> IF you can't figure that out, your even dumber than you seem.
> I have figured out THAT you are doing it. I can't figure out WHY you are doing it.

Maybe the problem is you don't actually understand what YOU are talking
about.

>
>> As you have admitted, your thinking is knowledge free, so of course you
>> don't understand what people talk about.
> Q.E.D You continue to misrepresent what I say.
>
> I have admitted THAT I posess knowledge of the fact THAT Mathematics contains no knowledge.
> Which is not the same thing as my thinking being "knowledge free".
>
> For somebody who pretends to "understand" you sure misunderstand a lot.
>
>

If you claim that what you are talking about has no knowledge, what else
does it mean?

You are knowledge free, because you reject to concept of First
Principles, and thus EVERYTHING you talk about has nothing to be based on.

Eitehr that or you are LYING about rejecting all first orincples, and
thus everything you say is built on a LIE.

Either way, your statements have know actual knowledge behind them.

On 8/23/22 6:59 PM, olcott wrote:
> On 8/23/2022 5:47 PM, Paul N wrote:
>> On Tuesday, August 23, 2022 at 6:08:25 PM UTC+1, olcott wrote:
>>> On 8/23/2022 11:35 AM, Paul N wrote:
>>>> On Tuesday, August 23, 2022 at 3:50:37 PM UTC+1, olcott wrote:
>>>>> I have proven that the execution trace of the simulation of the
>>>>> input by
>>>>> H(P,P) exactly matches line-by-line the x86 source-code of P and this
>>>>> shows that the correct and complete simulation of this input never
>>>>> reaches its final state and stops running:
>>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>>
>>>> This is what would happen if H always simulated its input.
>>>>
>>>> But H does not always simulate its input.
>>> void Infinite_Loop()
>>> {
>>> HERE: goto HERE;
>>> }
>>> int main()
>>> {
>>> Output("Input_Halts = ", H0((u32)Infinite_Loop));
>>> }
>>>
>>> _Infinite_Loop()
>>> [00001102](01) 55 push ebp
>>> [00001103](02) 8bec mov ebp,esp
>>> [00001105](02) ebfe jmp 00001105
>>> [00001107](01) 5d pop ebp
>>> [00001108](01) c3 ret
>>> Size in bytes:(0007) [00001108]
>>>
>>> *This is what would happen if H always simulated its input*
>>> *This is what would happen if H always simulated its input*
>>> *This is what would happen if H always simulated its input*
>>> *This is what would happen if H always simulated its input*
>>
>> So it's not what happens with your actual H.
>>
>>> (a) H0(Infinite_Loop) simulates Infinite_Loop()
>>> (b) goto HERE
>>> (c) goto HERE
>>> (d) goto HERE...
>>>
>>> Yet a simulating halt decider must always abort the simulation of every
>>> non-terminating input.
>>>
>>> It does this as soon as it correctly matches a correct non-terminating
>>> behavior.
>>
>> But H(P, P) does not correctly match a non-terminating behaviour. The
>> behaviour of P(P) is that it terminates, or so you claim.
>
> The correct and complete simulation by
>
> int main()
> {
>   Simulate(P,P);
> }
>
> Is an entirely different sequence of instructions than the correct and
> complete simulation by H(P,P) of its input.

What is the different sequence of instruction that are simulated?

Point out the first one that is actually different?

One that H actually simulates, and not just "guess" what it will do base
on erroneous premises?

>
> If you don't give a rat's ass about facts and truth I am done talking
> with you.
>

You are the one who is sort on facts.

When asked why something is, point out a great way for you to show an
actual fact to back up you claim, you just deflect on go somewhere else.

This seems to indicate that you don't actually have the facts to back up
your made up claims.

You have provided NO basis for most of your claims. You will quote a
classical definition, and then NOT follow it.

Like how Halting is about a Turing Machine reaching its final state, and
then "using it" by not talking about the Turing Machine, but some other
programs incomplete simulation of that machine.

This proves that you don't really understand what you are talking about
and just lying through your teeth.

>>
>>> This non-terminating behavior pattern is verified as correct when it
>>> proves that a correct and complete simulation of this input would never
>>> stop running.
>>
>> When you swap a running-forever H with an aborting H, you are no
>> longer doing a correct simulation, because you are not simulating H
>> correctly. Others have explained this in much greater detail.
>
>

On Wednesday, 24 August 2022 at 00:59:31 UTC+2, richar...@gmail.com wrote:
> No, because he SPEICIFICALLY points to the classic Halting Theorem and
> Proof, and says that is framework he is working in.
There is nothing "SPECIFIC" about it! "THE" framework is incomplete, ergo it has infinite interpretations/models.

> > The "actuaal behavior" of P is not specified; or rather - the actual behavior of P is unspecified and open to interpretation UNTIL one also specifies the semantics of the programming language; the runtime in which P is to be interpreted.
> Which he does (at times)
Yeah! And the model he's working in is explicit. Some computational concoction of his own making.

That is the lens from which he's interpreting his results. Not the "SPECIFIC" framework he says he's using.

He SAYS he is using framework X, but that's obviously not the case.
It's no different to you SAYING that you are using the framework of "Real numbers", while it's obvious to me that you are have no idea which framework you are using.

On Wednesday, 24 August 2022 at 03:06:23 UTC+2, richar...@gmail.com wrote:
> I didn't say this GROUP was just about classical computation theory (and
> the name would be comp.theory.classical, you don't seem to even know the
> naming conventions of the medium you are posting in)
Equivalent naming conventions are equivalent.

> I was saying that this PARTICULAR discussion, by the original posters
> own declaration, is in the domain of classical computation theory.
But the original poster's own declaration makes the computational model explicit. And the model is NOT the "classical model".

Seems you are interpreting his results in a model different to the one he used to generate them.

> Because if you are talking about a SPECIFIC theory, you need to talking
> within the field that the theory is framed in.
He is talking about a SPECIFIC theory. And even more precisely - he is talking about his SPECIFIC model of computation.

Seems you are interpreting his results in a model different to the one he used to generate them.

> >> IF you can't figure that out, your even dumber than you seem.
> > I have figured out THAT you are doing it. I can't figure out WHY you are doing it.
> Maybe the problem is you don't actually understand what YOU are talking
> about.
Maybe you a projecting your problems onto me?

> >
> If you claim that what you are talking about has no knowledge, what else
> does it mean?
It doesn't mean "anything else". It means precisely what it means. There is no knowledge in mathematics.

What knowledge is there in the Peano axiom-schema? None - they are just declarations.

> You are knowledge free, because you reject to concept of First
> Principles, and thus EVERYTHING you talk about has nothing to be based on.
Well, what are your First Principles based on? What knowlede do they rest upon?

> Eitehr that or you are LYING about rejecting all first orincples, and
> thus everything you say is built on a LIE.
Idiot. Mathematics is not built on a LIE - it's built on arbitrary, unsupported declarations. Axioms!

Axioms are made up! That doesn't make them LIES. It makes them neither true, nor false.

It makes them statements of faith, not knowledge.

> Either way, your statements have know actual knowledge behind them.
That's an obvious misrepresentation.

Peano declared THAT 0 is a natural number! Based on. nothing! Fuckall knowledge behind that declaration.

Given THAT there is no knowledge in the Peano axioms, and the constructions that follow thereof; then it is merely a statement of fact. A true claim about Mathematics THAT there is no knowledge in axiomatics/Mathematics.