On Tuesday, 23 August 2022 at 21:47:56 UTC+2, olcott wrote:
> The way that formal semantics works in computer programming is that the
> behavior associated with finite strings of machine instruction is
> specified.
Yes indeed. And the semantics of this particular instruction

[00000fdd](02) 7402 jz 00000fe1

Depends on the CPU's zero flag ( https://en.wikipedia.org/wiki/Zero_flag )

IF the CPU zero-flag is set, then your P would terminate.

Observe THAT the CPU's zero flag is not defined anywhere in your code.

> Semantics describes the processes a computer follows when executing a
> program in that specific language.
Which does nothing to address conditional branching. Such as

[00000fdd](02) 7402 jz 00000fe1

In a language where all the variables are made explicit it would read something like if x = 0: goto 00000fe1 else goto 00000fdf

Skep Dick <skepdick22@gmail.com> writes:

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

Like most cranks, PO's aim is to show that the classical problem, in the
classical model, is resolved/nonsense/wrong. He has no interest in
being right about something different.

Review just some of the last 18 years of his postings and this will
become clear. For example, in 2018 he claimed to have something

"showing exactly how the actual Linz H would correctly decide the
actual Linz (Ĥ, Ĥ)"

and that

"Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
specs does not exist. I now have a fully encoded pair of Turing
Machines H / Ĥ proving them wrong."

"I now have an actual H that decides actual halting for an actual (Ĥ,
Ĥ) input pair. [...] The key thing is the H and Ĥ are 100% fully
encoded as actual Turing machines."

"it is exactly and precisely the Peter Linz H and Ĥ, with H actually
deciding input pair: (Ĥ, Ĥ)"

Of course no one ever saw, and no one ever will see, any such H.

--
Ben.

On Tuesday, August 23, 2022 at 11:59:25 PM UTC+1, 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.

As you yourself have said, changing the subject is no rebuttal.

I pointed out that your H is wrong. In response, you have produced a different function, "Simulate", which you have not previously mentioned in this discussion (or at all, as far as I can see), and claimed it is different. Claiming (even if you provided proof, which you haven't) that H is different from some other, previously unmentioned, function, is in no way a rebuttal to the points I have made explaining why H is wrong.

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

On Wednesday, 24 August 2022 at 12:50:47 UTC+2, Ben Bacarisse wrote:
> Like most cranks, PO's aim is to show that the classical problem, in the
> classical model, is resolved/nonsense/wrong. He has no interest in
> being right about something different.
Which cannot possible be true, since he is not working in the classical model - so his results are not transferrable.

Once you acknowledge this fact it becomes trivial to realise that you have misconstrued his intentions.
Personally, I think he's just exploiting Cunningham's law. He's exploiting everybody who "wants to be right".

And since he's actually admitted this to me on another forum I figure I even have evidence to claim it.

But, of course - there is no such a thing as "right" and "wrong" from the point of view of relativistic Mathematics. You can always negate any axiom, and you can always exploit undefined behaviour.

Because incompleteness.

On 8/24/22 4:54 AM, Skep Dick wrote:
> 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.

No, he starts by claiming that he is in the classical model, and that
his work is fully compatible with it.

The fact that he then does things that violate that model, says he is WRONG.

That is like saying you are working on a problem in Plane Geometry, and
then move a point from the X-Y plane in the Z direction. IT is breaking
the rules of the field you said you are were working in.

Since you don't beleive in Rules, you of course can't see that, or in
that fact be able to know anything.

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

Nope, he isn't using the model he says he is, thus making his results
not apply to it.

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

On Wednesday, 24 August 2022 at 13:35:48 UTC+2, richar...@gmail.com wrote:
> No, he starts by claiming that he is in the classical model, and that
> his work is fully compatible with it.
Can you actually read/understand English?

He is not claiming that he is in the classical model (how anyone other than Turing himself could claim this is beyond me!?!)

He is claiming that BECAUSE it's "commonly accepted" that all models of computation are equivalent to Turing Machines, and BECAUSE the model of computation commonly
known as the "C programming languages" is commonly accepted to be Turing Complete (and therefore equivalent to a Turing Machine) it trivially follows that
his program (whatever it does) can also be encoded on a Turing Machine.

> The fact that he then does things that violate that model, says he is WRONG.
How is that even possible in your idiot-brain?!?!?

IF The programming language C is Turing Complete and equivalent to a Turing Machine THEN nothing anyone ever does does in C could possibly amount to model-violation.

> That is like saying you are working on a problem in Plane Geometry, and
> then move a point from the X-Y plane in the Z direction. IT is breaking
> the rules of the field you said you are were working in.
Holy shit! The rules are immaterial in linear logic/proof nets! It's literally the point of linear logic.

it side-steps the syntax/grammar/bureaucracy and goes straight for the semantics.

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

> Since you don't beleive in Rules, you of course can't see that, or in
> that fact be able to know anything.
idiot. Please show me the computational rules by which you may parse the English sentence "I know that I don't know anything".

Do I have knowledge; or don't I have knowledge?

Undecidability. You don't understand it.

> > Seems you are interpreting his results in a model different to the one he used to generate them.
> Nope, he isn't using the model he says he is, thus making his results
> not apply to it.
But he is using a model commonly accepted to be EQUIVALENT to a Turing Machine. Equivalence implies equivalence of semantic properties.

The immediate implication of which is that ANY C program is portable to a Turing Machine.
So you aren't arguing over whether his program works or not. Obviously - his program detects loops/duplicate function calls between H and P.

You are arguing over what the result means.

On 8/24/22 7:59 AM, Skep Dick wrote:
> On Wednesday, 24 August 2022 at 13:35:48 UTC+2, richar...@gmail.com wrote:
>> No, he starts by claiming that he is in the classical model, and that
>> his work is fully compatible with it.
> Can you actually read/understand English?
>
> He is not claiming that he is in the classical model (how anyone other than Turing himself could claim this is beyond me!?!)
>
> He is claiming that BECAUSE it's "commonly accepted" that all models of computation are equivalent to Turing Machines, and BECAUSE the model of computation commonly
> known as the "C programming languages" is commonly accepted to be Turing Complete (and therefore equivalent to a Turing Machine) it trivially follows that
> his program (whatever it does) can also be encoded on a Turing Machine.

And then he claims that his program is correct about behavior that
doesn't actually happen.

>
>> The fact that he then does things that violate that model, says he is WRONG.
> How is that even possible in your idiot-brain?!?!?
>
> IF The programming language C is Turing Complete and equivalent to a Turing Machine THEN nothing anyone ever does does in C could possibly amount to model-violation.

Because he says that his program correctly predicts that the input, when
interpreted according to that model, does something different then what
it actually does by that model.

Maybe YOU should read and not just comment.

He claims that a computation that Halts is correctly predicted to not halt.

>
>> That is like saying you are working on a problem in Plane Geometry, and
>> then move a point from the X-Y plane in the Z direction. IT is breaking
>> the rules of the field you said you are were working in.
> Holy shit! The rules are immaterial in linear logic/proof nets! It's literally the point of linear logic.
>
> it side-steps the syntax/grammar/bureaucracy and goes straight for the semantics.
>
> https://en.wikipedia.org/wiki/Proof_net
>
>> Since you don't beleive in Rules, you of course can't see that, or in
>> that fact be able to know anything.
> idiot. Please show me the computational rules by which you may parse the English sentence "I know that I don't know anything".
>
> Do I have knowledge; or don't I have knowledge?
>
> Undecidability. You don't understand it.
>
>>> Seems you are interpreting his results in a model different to the one he used to generate them.
>> Nope, he isn't using the model he says he is, thus making his results
>> not apply to it.
> But he is using a model commonly accepted to be EQUIVALENT to a Turing Machine. Equivalence implies equivalence of semantic properties.
>
> The immediate implication of which is that ANY C program is portable to a Turing Machine.
> So you aren't arguing over whether his program works or not. Obviously - his program detects loops/duplicate function calls between H and P.
>
> You are arguing over what the result means.
>
>

On Wednesday, 24 August 2022 at 14:03:44 UTC+2, richar...@gmail.com wrote:
> And then he claims that his program is correct about behavior that
> doesn't actually happen.
That's because source code doesn't encode behaviour!!!

Behaviour is the byproduct of your syntax and semantics interacting with each other!

Does the sentence "0" produce halting or non-halting behaviour in language P?
Does the sentence "1" produce halting or non-halting behaviour in language R?

Rice's theorem. FFS!

> > IF The programming language C is Turing Complete and equivalent to a Turing Machine THEN nothing anyone ever does does in C could possibly amount to model-violation.
> Because he says that his program correctly predicts that the input, when
> interpreted according to that model, does something different then what
> it actually does by that model.
Fucking Idiot! The halting problem is reducible to the blank tape problem.

Given unlimited time, does a Turing Machine terminate on a blank tape?

The behaviour is NOT decidable in the model!

> Maybe YOU should read and not just comment.
Strawman. I am doing more than just reading. I am also understanding. You should try it sometimes.

> He claims that a computation that Halts is correctly predicted to not halt.
Idiot. P and H are mutually recursive, circularly dependent functions.

Neither P nor H halts unless aborted. Any model which predicts otherwise is wrong.

So that's your model.

On 8/24/2022 6:10 AM, Paul N wrote:
> On Tuesday, August 23, 2022 at 11:59:25 PM UTC+1, 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.
>
> As you yourself have said, changing the subject is no rebuttal.
>

*Everyone also knows that*
(a) The correct and complete simulation of a machine description always
provides the actual behavior specified by this machine description.

(b) A halt decider must base its halt status decision on the actual
behavior of its actual input.

This is the behavior of the correct and complete simulation of the input
to H(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)... (on and on)

This proves that I am correct.

> I pointed out that your H is wrong. In response, you have produced a different function, "Simulate", which you have not previously mentioned in this discussion (or at all, as far as I can see), and claimed it is different. Claiming (even if you provided proof, which you haven't) that H is different from some other, previously unmentioned, function, is in no way a rebuttal to the points I have made explaining why H is wrong.
>
>> 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

Skep Dick <skepdick22@gmail.com> writes:

> On Wednesday, 24 August 2022 at 12:50:47 UTC+2, Ben Bacarisse wrote:
>> Like most cranks, PO's aim is to show that the classical problem, in the
>> classical model, is resolved/nonsense/wrong. He has no interest in
>> being right about something different.
>
> Which cannot possible be true, since he is not working in the
> classical model - so his results are not transferrable.

Long ago he stated that H(P,P) == false is correct even though P(P)
halts. If you want to say he's wrong about the theorem he want to
"refute" because that's his "model" so be it. Since he denies using
another model, it's simpler to say he is wrong by definition of the
problem, he claimed to be addressing. Either way, he does not have what
he wants to have.

> But, of course - there is no such a thing as "right" and "wrong" from
> the point of view of relativistic Mathematics. You can always negate
> any axiom, and you can always exploit undefined behaviour.

But he does not want to be right in some "relativistic Mathematics"
where anything can be asserted. That would be a trivial and, for him
particularly, pointless exercise. He wants to be right (in the sense of
the well-known theorem /not/ being a theorem) is the hard world of an
accepted set of axioms and definitions.

But maybe he's moved on and we can just forget the last 18 years. Have
you asked him if he now thinks that the theorem as proved in Linz is
indeed a theorem of the model of computation presented in that book?
That would be huge step forward.

--
Ben.

Skep Dick <skepdick22@gmail.com> writes:

> On Wednesday, 24 August 2022 at 14:03:44 UTC+2, richar...@gmail.com wrote:
>> And then he claims that his program is correct about behavior that
>> doesn't actually happen.
>
> That's because source code doesn't encode behaviour!!!

PO would like to agree with you, but you are both wrong about the
halting problem. HP is about the decidability of a subset of N based
entirely on a specified encoding of behaviour. The syntax and the
semantics of, say 81924555413098 are both fully specified.

(In this sense there are an infinity of halting problems, but each one
has the same answer.)

--
Ben.

On Wednesday, August 24, 2022 at 3:43:46 PM UTC+1, olcott wrote:
> On 8/24/2022 6:10 AM, Paul N wrote:
> > On Tuesday, August 23, 2022 at 11:59:25 PM UTC+1, 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.
> >
> > As you yourself have said, changing the subject is no rebuttal.
> >
> *Everyone also knows that*
> (a) The correct and complete simulation of a machine description always
> provides the actual behavior specified by this machine description.

Yes, but you admit that H does not do a complete simulation.

> (b) A halt decider must base its halt status decision on the actual
> behavior of its actual input.

Yes, so if P(P) halts, then H(P, P) must return non-zero. It doesn't.

> This is the behavior of the correct and complete simulation of the input
> to H(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)... (on and on)

No it isn't. You've said numerous times that your actual H does not do this..

> This proves that I am correct.

It proves nothing of the sort. And it is all stuff you have said numerous times before. It was wrong then and it's still wrong now.

> > I pointed out that your H is wrong. In response, you have produced a different function, "Simulate", which you have not previously mentioned in this discussion (or at all, as far as I can see), and claimed it is different.. Claiming (even if you provided proof, which you haven't) that H is different from some other, previously unmentioned, function, is in no way a rebuttal to the points I have made explaining why H is wrong.
> >
> >> 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.

On Wednesday, 24 August 2022 at 19:00:54 UTC+2, Paul N wrote:
> Yes, so if P(P) halts, then H(P, P) must return non-zero. It doesn't.
Here's a leading question:

IF (big IF) P is a pure function, and IF proof-by-induction is a valid proof technique; does P calling P with argument P more than once serve as inductively valid proof that P is in a loop?

On 8/24/2022 12:00 PM, Paul N wrote:
> On Wednesday, August 24, 2022 at 3:43:46 PM UTC+1, olcott wrote:
>> On 8/24/2022 6:10 AM, Paul N wrote:
>>> On Tuesday, August 23, 2022 at 11:59:25 PM UTC+1, 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.
>>>
>>> As you yourself have said, changing the subject is no rebuttal.
>>>
>> *Everyone also knows that*
>> (a) The correct and complete simulation of a machine description always
>> provides the actual behavior specified by this machine description.
>
> Yes, but you admit that H does not do a complete simulation.

When-so-ever a simulating halt decider (SHD) correctly performs a
partial simulation of its input and the behavior of this partial
simulation correctly matches a correct non-halting behavior pattern then
the SHD halt decider can correctly report non-halting.

A non-halting behavior pattern is correct when-so-ever matching this
behavior pattern proves that the correct and complete simulation of the
input by SHD would never reach the final state of this simulated input.

--
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 Wednesday, August 24, 2022 at 6:12:10 PM UTC+1, olcott wrote:
> On 8/24/2022 12:00 PM, Paul N wrote:
> > On Wednesday, August 24, 2022 at 3:43:46 PM UTC+1, olcott wrote:
> >> On 8/24/2022 6:10 AM, Paul N wrote:
> >>> On Tuesday, August 23, 2022 at 11:59:25 PM UTC+1, 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.
> >>>
> >>> As you yourself have said, changing the subject is no rebuttal.
> >>>
> >> *Everyone also knows that*
> >> (a) The correct and complete simulation of a machine description always
> >> provides the actual behavior specified by this machine description.
> >
> > Yes, but you admit that H does not do a complete simulation.
> When-so-ever a simulating halt decider (SHD) correctly performs a
> partial simulation of its input and the behavior of this partial
> simulation correctly matches a correct non-halting behavior pattern then
> the SHD halt decider can correctly report non-halting.

Since P(P) halts, H can never correctly report that it doesn't.

> A non-halting behavior pattern is correct when-so-ever matching this
> behavior pattern proves that the correct and complete simulation of the
> input by SHD would never reach the final state of this simulated input.

H is not simulating itself correctly. If H recognises that it is stuck in a loop and stops, it is not correct to pretend that H never realises it is stuck in a loop and hence ploughs on regardless.

On 8/24/2022 1:02 PM, Paul N wrote:
> On Wednesday, August 24, 2022 at 6:12:10 PM UTC+1, olcott wrote:
>> On 8/24/2022 12:00 PM, Paul N wrote:
>>> On Wednesday, August 24, 2022 at 3:43:46 PM UTC+1, olcott wrote:
>>>> On 8/24/2022 6:10 AM, Paul N wrote:
>>>>> On Tuesday, August 23, 2022 at 11:59:25 PM UTC+1, 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.
>>>>>
>>>>> As you yourself have said, changing the subject is no rebuttal.
>>>>>
>>>> *Everyone also knows that*
>>>> (a) The correct and complete simulation of a machine description always
>>>> provides the actual behavior specified by this machine description.
>>>
>>> Yes, but you admit that H does not do a complete simulation.
>> When-so-ever a simulating halt decider (SHD) correctly performs a
>> partial simulation of its input and the behavior of this partial
>> simulation correctly matches a correct non-halting behavior pattern then
>> the SHD halt decider can correctly report non-halting.
>
> Since P(P) halts, H can never correctly report that it doesn't.
>

H(P,P) is not reporting whether or not
int main() { P(P); } halts because it has entirely different behavior
than the actual behavior specified by its actual input.

The correct and complete simulation of a machine description always
provides the actual behavior specified by this machine description.

*The correct and complete simulation of the input to H(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)...

>> A non-halting behavior pattern is correct when-so-ever matching this
>> behavior pattern proves that the correct and complete simulation of the
>> input by SHD would never reach the final state of this simulated input.
>
> H is not simulating itself correctly. If H recognises that it is stuck in a loop and stops, it is not correct to pretend that H never realises it is stuck in a loop and hence ploughs on regardless.

H only must report on whether or not the correct and complete simulation
of its input would ever reach the final state of this simulated input.

--
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/24/22 8:21 AM, Skep Dick wrote:
> On Wednesday, 24 August 2022 at 14:03:44 UTC+2, richar...@gmail.com wrote:
>> And then he claims that his program is correct about behavior that
>> doesn't actually happen.
> That's because source code doesn't encode behaviour!!!

Really? You mean the C Standard (combined often with implementation
documentation) doesn't mandate certain behavior for certain source code?

Rejection of the Rules means nothing actually means anything to you.

>
> Behaviour is the byproduct of your syntax and semantics interacting with each other!
>
> Does the sentence "0" produce halting or non-halting behaviour in language P?
> Does the sentence "1" produce halting or non-halting behaviour in language R?

Need to define the languages.

>
> Rice's theorem. FFS!
>
>>> IF The programming language C is Turing Complete and equivalent to a Turing Machine THEN nothing anyone ever does does in C could possibly amount to model-violation.
>> Because he says that his program correctly predicts that the input, when
>> interpreted according to that model, does something different then what
>> it actually does by that model.
> Fucking Idiot! The halting problem is reducible to the blank tape problem.
>
> Given unlimited time, does a Turing Machine terminate on a blank tape?
>
> The behaviour is NOT decidable in the model!
>
>> Maybe YOU should read and not just comment.
> Strawman. I am doing more than just reading. I am also understanding. You should try it sometimes.

No, clearly you are not, as you think that C source code doesn't define
in any way the behavior of the program.

>
>> He claims that a computation that Halts is correctly predicted to not halt.
> Idiot. P and H are mutually recursive, circularly dependent functions.
>
> Neither P nor H halts unless aborted. Any model which predicts otherwise is wrong.
>
> So that's your model.
>
>

Shows how dumb you are, since it has been SHOWN that P(P) will halt with
his currect definiton of H because it is defined to abort its simulation
when it sees the call to H(P,P) inside P(P). (Which is NOT "aborting"
the actual execution of P)

Thus, the PROGRAM P(P) will reach it finial state without needed to be
"aborted" (since there is nothing available TO abort that program), and
the function H(P,P) will also "halt" (aka return a value) since it stops
its simulation of its input when it sees that input calling H(P,P), and
it INCORRECT determining that this means that P(P) will be non-halting,
and returns that incorrect answer.

The fact that Olcott doesn't see it either, just puts you to in the same
Dumb camp.

On 8/24/22 10:43 AM, olcott wrote:
> On 8/24/2022 6:10 AM, Paul N wrote:
>> On Tuesday, August 23, 2022 at 11:59:25 PM UTC+1, 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.
>>
>> As you yourself have said, changing the subject is no rebuttal.
>>
>
> *Everyone also knows that*
> (a) The correct and complete simulation of a machine description always
> provides the actual behavior specified by this machine description.

Right (see below)

>
> (b) A halt decider must base its halt status decision on the actual
> behavior of its actual input.

Right, and the ACUTAL BEHAVIOR of the input to H(P,d) is DEFINED to be
the behavior of Simuate(P,d), since H doesn't complete its simulation of
the input if it decides it is non-halting.

>
> This is the behavior of the correct and complete simulation of the input
> to H(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)... (on and on)
>
> This proves that I am correct.
>
>

Nope, that isn't what your H actually does

The correct and complete simulation of the input of H(P,P) is:

(a) simulation of P(P) that calls a simulate H(P,P)
(b) That simulated H(P,P) will simulate anoter copy of P(P)
(c) That simulation of simulated P(P) will call H(P,P)
(d) The Simulated H will abort its simulation and return 0
(e) The simulation of P(P) started in (a) will get that answer and return

Thus showing that the COMPLETE and correct simulaiton of the input to
H(P,P) does Halt.

>> I pointed out that your H is wrong. In response, you have produced a
>> different function, "Simulate", which you have not previously
>> mentioned in this discussion (or at all, as far as I can see), and
>> claimed it is different. Claiming (even if you provided proof, which
>> you haven't) that H is different from some other, previously
>> unmentioned, function, is in no way a rebuttal to the points I have
>> made explaining why H is wrong.
>>
>>> 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.
>
>

On 8/24/22 1:10 PM, Skep Dick wrote:
> On Wednesday, 24 August 2022 at 19:00:54 UTC+2, Paul N wrote:
>> Yes, so if P(P) halts, then H(P, P) must return non-zero. It doesn't.
> Here's a leading question:
>
> IF (big IF) P is a pure function, and IF proof-by-induction is a valid proof technique; does P calling P with argument P more than once serve as inductively valid proof that P is in a loop?
>

Except that P(P) doesn't call P(P), it calls H(P,P), which is a decider,
that if it meets its requirement ALWAYS returns a value in finite time.

Thus, you don't have anything to base your proof-by-induction steps.

On 8/24/22 1:12 PM, olcott wrote:
> On 8/24/2022 12:00 PM, Paul N wrote:
>> On Wednesday, August 24, 2022 at 3:43:46 PM UTC+1, olcott wrote:
>>> On 8/24/2022 6:10 AM, Paul N wrote:
>>>> On Tuesday, August 23, 2022 at 11:59:25 PM UTC+1, 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.
>>>>
>>>> As you yourself have said, changing the subject is no rebuttal.
>>>>
>>> *Everyone also knows that*
>>> (a) The correct and complete simulation of a machine description always
>>> provides the actual behavior specified by this machine description.
>>
>> Yes, but you admit that H does not do a complete simulation.
>
> When-so-ever a simulating halt decider (SHD) correctly performs a
> partial simulation of its input and the behavior of this partial
> simulation correctly matches a correct non-halting behavior pattern then
> the SHD halt decider can correctly report non-halting.
>
> A non-halting behavior pattern is correct when-so-ever matching this
> behavior pattern proves that the correct and complete simulation of the
> input by SHD would never reach the final state of this simulated input.
>

And the fact that P(P) Halts, says that H could NOT have seen an
actually correct non-halting pattern.

Note, that since the SHD H, as you have provied the code of, doesn't
actually DO a complete simulation of the input, by your definition, the
pattern has not be proved to be correct.

It aay be able tp prove that for the OTHER H you have defined, the one
that doesn't actually answer, it can be shown the pattern is correct,
but that isn't the input that the pattern is actually trying to match.

Note, that since your current H aborts before it even gets to simulating
any of H, they is no way the pattern can detect which H it is looking
at, so the pattern can not be correct if it is just looking at the
simulation trace.

FAIL.

On 8/24/22 2:47 PM, olcott wrote:
> On 8/24/2022 1:02 PM, Paul N wrote:
>> On Wednesday, August 24, 2022 at 6:12:10 PM UTC+1, olcott wrote:
>>> On 8/24/2022 12:00 PM, Paul N wrote:
>>>> On Wednesday, August 24, 2022 at 3:43:46 PM UTC+1, olcott wrote:
>>>>> On 8/24/2022 6:10 AM, Paul N wrote:
>>>>>> On Tuesday, August 23, 2022 at 11:59:25 PM UTC+1, 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.
>>>>>>
>>>>>> As you yourself have said, changing the subject is no rebuttal.
>>>>>>
>>>>> *Everyone also knows that*
>>>>> (a) The correct and complete simulation of a machine description
>>>>> always
>>>>> provides the actual behavior specified by this machine description.
>>>>
>>>> Yes, but you admit that H does not do a complete simulation.
>>> When-so-ever a simulating halt decider (SHD) correctly performs a
>>> partial simulation of its input and the behavior of this partial
>>> simulation correctly matches a correct non-halting behavior pattern then
>>> the SHD halt decider can correctly report non-halting.
>>
>> Since P(P) halts, H can never correctly report that it doesn't.
>>
>
> H(P,P) is not reporting whether or not
> int main() { P(P); } halts because it has entirely different behavior
> than the actual behavior specified by its actual input.
>
> The correct and complete simulation of a machine description always
> provides the actual behavior specified by this machine description.
>
> *The correct and complete simulation of the input to H(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)...

Shows you lie, as that is NOT a simulation you can get out of the code
you have provided for H.

Your H is DEFINED to abort its simulation at the end of step (a).

So saying (b) happens is just a blatent LIE.

>
>>> A non-halting behavior pattern is correct when-so-ever matching this
>>> behavior pattern proves that the correct and complete simulation of the
>>> input by SHD would never reach the final state of this simulated input.
>>
>> H is not simulating itself correctly. If H recognises that it is stuck
>> in a loop and stops, it is not correct to pretend that H never
>> realises it is stuck in a loop and hence ploughs on regardless.
>
> H only must report on whether or not the correct and complete simulation
> of its input would ever reach the final state of this simulated input.
>

And is wrong, since the correct and complete simulation of its input
(done by Simulate, since H doesn't do it) will Halt.

On Thursday, 25 August 2022 at 01:22:01 UTC+2, richar...@gmail.com wrote:
> Really? You mean the C Standard (combined often with implementation
> documentation) doesn't mandate certain behavior for certain source code?
Yes, you shit-for-brains fucking retard.

It mandates CERTAIN behavior for CERTAIN source code.
It DOESN'T mandate ALL behavior for ALL source code.

> Rejection of the Rules means nothing actually means anything to you.
Circumvention of the rules is not rejection of the rules. it's circumvention of the rules.

You shit-for-brains fucking retard.

> > Does the sentence "0" produce halting or non-halting behaviour in language P?
> > Does the sentence "1" produce halting or non-halting behaviour in language R?
> Need to define the languages.
I have defined them! P is an instance of a language. R is an instance of a language.

P = Language()
R = Language()

Are you now going to tell me that you struggle with instantiation also ?!?

> > Strawman. I am doing more than just reading. I am also understanding. You should try it sometimes.
> No, clearly you are not, as you think that C source code doesn't define
> in any way the behavior of the program.
Strawman ^ 2.

Defining the behavior is SOME way is not defining the behaviour in ALL ways.

Which is why we can implement any programming language in any other programming language.

> >
> Shows how dumb you are, since it has been SHOWN that P(P) will halt with
> his currect definiton of H because it is defined to abort its simulation
> when it sees the call to H(P,P) inside P(P). (Which is NOT "aborting"
> the actual execution of P)
You shit-for-brains fucking retard!

On the one hand you want to argue that the definition of P in a particular programming language captures P's exact behavior;
And at the exact same time you want to argue that an IDENTICAL COPY of P's source code compiled+executed on a different system DOESN'T reflect the behavior of P.

Which one is it?

It's almost as if you don't understand the difference between static and dynamic analysis.

On 8/25/22 3:08 AM, Skep Dick wrote:
> On Thursday, 25 August 2022 at 01:22:01 UTC+2, richar...@gmail.com wrote:
>> Really? You mean the C Standard (combined often with implementation
>> documentation) doesn't mandate certain behavior for certain source code?
> Yes, you shit-for-brains fucking retard.
>
> It mandates CERTAIN behavior for CERTAIN source code.
> It DOESN'T mandate ALL behavior for ALL source code.

Which isn't what you first said, which was:

> That's because source code doesn't encode behaviour!!!

But now you admit that source code can encode some behavior.

Seems

>
>> Rejection of the Rules means nothing actually means anything to you.
> Circumvention of the rules is not rejection of the rules. it's circumvention of the rules.
>
> You shit-for-brains fucking retard.

You are just showing who you are.

>
>>> Does the sentence "0" produce halting or non-halting behaviour in language P?
>>> Does the sentence "1" produce halting or non-halting behaviour in language R?
>> Need to define the languages.
> I have defined them! P is an instance of a language. R is an instance of a language.
>
> P = Language()
> R = Language()
>
> Are you now going to tell me that you struggle with instantiation also ?!?

So, you don't understand what it means to define something?

>
>
>>> Strawman. I am doing more than just reading. I am also understanding. You should try it sometimes.
>> No, clearly you are not, as you think that C source code doesn't define
>> in any way the behavior of the program.
> Strawman ^ 2.
>
> Defining the behavior is SOME way is not defining the behaviour in ALL ways.
>
> Which is why we can implement any programming language in any other programming language.

Nope, because not all Programming Languages are Turing Complete.

>
>>>
>> Shows how dumb you are, since it has been SHOWN that P(P) will halt with
>> his currect definiton of H because it is defined to abort its simulation
>> when it sees the call to H(P,P) inside P(P). (Which is NOT "aborting"
>> the actual execution of P)
> You shit-for-brains fucking retard!
>
> On the one hand you want to argue that the definition of P in a particular programming language captures P's exact behavior;
> And at the exact same time you want to argue that an IDENTICAL COPY of P's source code compiled+executed on a different system DOESN'T reflect the behavior of P.
>
> Which one is it?
>
> It's almost as if you don't understand the difference between static and dynamic analysis.

Because you seem to forget the definitions include context. The source
code of P defines the behavior of P in the CONTEXST of the definition of
the H which it calls.

Olcott is just making a smaller version of the error you are living,
assuming that he can ignore the affect of the context.

He is making *A* mistake, you are showing that you ARE a mistake.

On Thursday, 25 August 2022 at 13:34:58 UTC+2, richar...@gmail.com wrote:
> Which isn't what you first said, which was:
> > That's because source code doesn't encode behaviour!!!
> But now you admit that source code can encode some behavior.
>
> Seems
The ALL was implicit you uncharitable twat! Are you 100% committed to misinterpret absolutely everything I say?

That's because source code doesn't encode (ALL) behaviour!!! <--- Charitable interpretaion.
That's because source code doesn't encode (ANY) behaviour!!! <---- Uncharitable misinterpretation.
That's because source code doesn't encode (SOME) behaviour!!! <---- Uncharitable misinterpretation.

> >> Rejection of the Rules means nothing actually means anything to you.
> > Circumvention of the rules is not rejection of the rules. it's circumvention of the rules.
> >
> > You shit-for-brains fucking retard.
> You are just showing who you are.
I've told you who I am upfront - there was no additional need for me to show it.

> > Are you now going to tell me that you struggle with instantiation also ?!?
> So, you don't understand what it means to define something?
I understand perfectly what I mean by "define".
I've asked you 10+ times to explain what YOU mean by "define"!

Define "define" already!

> > Which is why we can implement any programming language in any other programming language.
> Nope, because not all Programming Languages are Turing Complete.
Uncharitable fucking twat! Is it not obvious (from the context) that we are talking about Turing Complete languages?

Why does everything need to be spelled out for you?

You demant precision from others while you offer none.
I think you are just a closet hypocrite.

> > It's almost as if you don't understand the difference between static and dynamic analysis.
> Because you seem to forget the definitions include context.
Yes, you shit for brains! It's called lexical scoping.

I pointed this out to you already when I asked you for the definition of ∞ in the scope/context of lim(x -> ∞)

>The source code of P defines the behavior of P in the CONTEXST of the definition of
> the H which it calls.
Yes, you shit for brains moron. Do you actually understand mutual recursion?

Do you understand that ONE definition (let statement) can produce TWO functions?!?

let rec p x = match x with
| _ -> h x
and h x = match x with
| _ -> p x;;
val p : 'a -> 'b = <fun>
val h : 'a -> 'b = <fun>

> Olcott is just making a smaller version of the error you are living,
> assuming that he can ignore the affect of the context.
Define 'error' you shit for brains idiot.
> He is making *A* mistake, you are showing that you ARE a mistake.
What I am is undecidable, you shit for brains fucking idiot.

On 8/25/22 7:53 AM, Skep Dick wrote:
> On Thursday, 25 August 2022 at 13:34:58 UTC+2, richar...@gmail.com wrote:
>> Which isn't what you first said, which was:
>>> That's because source code doesn't encode behaviour!!!
>> But now you admit that source code can encode some behavior.
>>
>> Seems
> The ALL was implicit you uncharitable twat! Are you 100% committed to misinterpret absolutely everything I say?

Then you are talking non-sense as NOTHING defines ALL behavior, because
not all behavior is definable.

You just broke your system.

>
> That's because source code doesn't encode (ALL) behaviour!!! <--- Charitable interpretaion.
> That's because source code doesn't encode (ANY) behaviour!!! <---- Uncharitable misinterpretation.
> That's because source code doesn't encode (SOME) behaviour!!! <---- Uncharitable misinterpretation.
>
>
>>>> Rejection of the Rules means nothing actually means anything to you.
>>> Circumvention of the rules is not rejection of the rules. it's circumvention of the rules.
>>>
>>> You shit-for-brains fucking retard.
>> You are just showing who you are.
> I've told you who I am upfront - there was no additional need for me to show it.
>
>
>>> Are you now going to tell me that you struggle with instantiation also ?!?
>> So, you don't understand what it means to define something?
> I understand perfectly what I mean by "define".
> I've asked you 10+ times to explain what YOU mean by "define"!
>
> Define "define" already!
>
>>> Which is why we can implement any programming language in any other programming language.
>> Nope, because not all Programming Languages are Turing Complete.
> Uncharitable fucking twat! Is it not obvious (from the context) that we are talking about Turing Complete languages?
>
> Why does everything need to be spelled out for you?
>
> You demant precision from others while you offer none.
> I think you are just a closet hypocrite.
>
>
>>> It's almost as if you don't understand the difference between static and dynamic analysis.
>> Because you seem to forget the definitions include context.
> Yes, you shit for brains! It's called lexical scoping.
>
> I pointed this out to you already when I asked you for the definition of ∞ in the scope/context of lim(x -> ∞)
>
>> The source code of P defines the behavior of P in the CONTEXST of the definition of
>> the H which it calls.
> Yes, you shit for brains moron. Do you actually understand mutual recursion?
>
> Do you understand that ONE definition (let statement) can produce TWO functions?!?
>
> let rec p x = match x with
> | _ -> h x
> and h x = match x with
> | _ -> p x;;
> val p : 'a -> 'b = <fun>
> val h : 'a -> 'b = <fun>
>
>> Olcott is just making a smaller version of the error you are living,
>> assuming that he can ignore the affect of the context.
> Define 'error' you shit for brains idiot.
>
>> He is making *A* mistake, you are showing that you ARE a mistake.
> What I am is undecidable, you shit for brains fucking idiot.
>
>