XPost: sci.logic

Op 22.jun.2024 om 20:47 schreef olcott:

On 6/22/2024 1:39 PM, Fred. Zwarts wrote:

Op 21.jun.2024 om 15:21 schreef olcott:

On 6/21/2024 2:16 AM, Mikko wrote:

On 2024-06-20 15:04:35 +0000, olcott said:

On 6/20/2024 9:42 AM, Mikko wrote:

On 2024-06-20 05:15:37 +0000, olcott said:

On 6/20/2024 12:04 AM, Mikko wrote:

Sitll inclear whether you know what "termination analyzer" means. >>>>>>

I really don't care what you believe.
It is not about belief.
It is about correct reasoning.

No, it is not. It is about language maintenance. If you cannot
present
your reasoning in Common Language it does not matter whether your
reasoning is correct.

I cannot possibly present my reasoning in a convincing way
to people that have already made up their mind and closed it
thus fail to trace through each step of this reasoning looking
for an error and finding none.

If you can't convince the reviewers of a journal that your article is
well thought and well written you cannot get it published in a
respected journal.

The trick is to get people that say I am wrong
to point out the exact mistake. When they really
try to do this they find no mistake and all of
their rebbutal was pure bluster with no actual basis.

It seems you do not even try to answer questions to show errors in the
reasoning of your opponents, in order to protect yourself against
finding no errors in their rebuttal.

I quit bothering to point out the strawman deception fake
rebuttal and instead I just ignore the whole reply. If you
change the subject away from DDD correctly emulated by H0
your reply will be ignored.

When we stipulate that the only measure of a correct emulation
is the semantics of the x86 programming language then we see
that when DDD is correctly emulated by H0 that its call to
H0(DDD) cannot possibly return.

_DDD()
[00002172] 55               push ebp      ; housekeeping [00002173] 8bec             mov ebp,esp   ; housekeeping [00002175] 6872210000       push 00002172 ; push DDD
[0000217a] e853f4ffff       call 000015d2 ; call H0(DDD)
[0000217f] 83c404           add esp,+04
[00002182] 5d               pop ebp
[00002183] c3               ret
Size in bytes:(0018) [00002183]

When we define H1 as identical to H0 except that DDD does not
call H1 then we see that when DDD is correctly emulated by H1
that its call to H0(DDD) does return. This is the same behavior
as the directly executed DDD().

Probably. Which shows that the simulation of H0 by H0 is incorrect. H1
shows that a correct simulation of H0 halts, but H0 is unable to
simulate itself up to its final state. It aborts one cycle before the simulation would end, as is shown by H1.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

On 6/22/24 2:56 PM, olcott wrote:

On 6/22/2024 1:53 PM, Fred. Zwarts wrote:

Op 22.jun.2024 om 20:47 schreef olcott:

On 6/22/2024 1:39 PM, Fred. Zwarts wrote:

Op 21.jun.2024 om 15:21 schreef olcott:

On 6/21/2024 2:16 AM, Mikko wrote:

On 2024-06-20 15:04:35 +0000, olcott said:

On 6/20/2024 9:42 AM, Mikko wrote:

On 2024-06-20 05:15:37 +0000, olcott said:

On 6/20/2024 12:04 AM, Mikko wrote:

Sitll inclear whether you know what "termination analyzer" means. >>>>>>>>

I really don't care what you believe.
It is not about belief.
It is about correct reasoning.

No, it is not. It is about language maintenance. If you cannot >>>>>>>> present
your reasoning in Common Language it does not matter whether your >>>>>>>> reasoning is correct.

I cannot possibly present my reasoning in a convincing way
to people that have already made up their mind and closed it
thus fail to trace through each step of this reasoning looking
for an error and finding none.

If you can't convince the reviewers of a journal that your article is >>>>>> well thought and well written you cannot get it published in a
respected journal.

The trick is to get people that say I am wrong
to point out the exact mistake. When they really
try to do this they find no mistake and all of
their rebbutal was pure bluster with no actual basis.

It seems you do not even try to answer questions to show errors in
the reasoning of your opponents, in order to protect yourself
against finding no errors in their rebuttal.

I quit bothering to point out the strawman deception fake
rebuttal and instead I just ignore the whole reply. If you
change the subject away from DDD correctly emulated by H0
your reply will be ignored.

When we stipulate that the only measure of a correct emulation
is the semantics of the x86 programming language then we see
that when DDD is correctly emulated by H0 that its call to
H0(DDD) cannot possibly return.

_DDD()
[00002172] 55               push ebp      ; housekeeping >>> [00002173] 8bec             mov ebp,esp   ; housekeeping
[00002175] 6872210000       push 00002172 ; push DDD
[0000217a] e853f4ffff       call 000015d2 ; call H0(DDD)
[0000217f] 83c404           add esp,+04
[00002182] 5d               pop ebp
[00002183] c3               ret
Size in bytes:(0018) [00002183]

When we define H1 as identical to H0 except that DDD does not
call H1 then we see that when DDD is correctly emulated by H1
that its call to H0(DDD) does return. This is the same behavior
as the directly executed DDD().

Probably. Which shows that the simulation of H0 by H0 is incorrect.

Incorrect and Strawman deception

Nope, Correct and shows the error in your logic.

If you want to admit to be working on POOP, you can call it correct POOP deciding, but it isn't correct HALT deciding.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

On 6/22/24 3:45 PM, olcott wrote:

On 6/22/2024 2:22 PM, Richard Damon wrote:

On 6/22/24 2:53 PM, olcott wrote:

On 6/22/2024 1:50 PM, Fred. Zwarts wrote:

Op 22.jun.2024 om 15:11 schreef olcott:

It is a verified fact that the behavior that finite string DDD
presents
to HH0 is that when DDD correctly simulated by HH0 calls HH0(DDD) that >>>>> this call DOES NOT RETURN.

It is a verified fact that the behavior that finite string DDD
presents
to HH1 is that when DDD correctly simulated by HH0 calls HH1(DDD) that >>>>> this call DOES RETURN.

I don't get why people here insist on lying about verified facts.

We know that 'verified fact' for you means 'my wish'.

Ignoramus?

When we stipulate that the only measure of a correct emulation is the
semantics of the x86 programming language then we see that when DDD
is correctly emulated by H0 that its call to H0(DDD) cannot possibly
return.

_DDD()
[00002172] 55               push ebp      ; housekeeping >>> [00002173] 8bec             mov ebp,esp   ; housekeeping
[00002175] 6872210000       push 00002172 ; push DDD
[0000217a] e853f4ffff       call 000015d2 ; call H0(DDD)
[0000217f] 83c404           add esp,+04
[00002182] 5d               pop ebp
[00002183] c3               ret
Size in bytes:(0018) [00002183]

When we define H1 as identical to H0 except that DDD does not call H1
then we see that when DDD is correctly emulated by H1 that its call
to H0(DDD) does return. This is the same behavior as the directly
executed DDD().

By a strict interpreation of your measure, this input has UNDEFIINED
BEHAVIOR, so it is improper to ask about it.

That is a stupid thing to say. The behavior of THE INPUT
is specified by the semantics of the x86 programming language.

Right, so what does a call to a location of memory that doesn't exist do?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

On 6/22/24 8:01 PM, olcott wrote:

On 6/22/2024 3:10 PM, Richard Damon wrote:

On 6/22/24 3:45 PM, olcott wrote:

On 6/22/2024 2:22 PM, Richard Damon wrote:

On 6/22/24 2:53 PM, olcott wrote:

On 6/22/2024 1:50 PM, Fred. Zwarts wrote:

Op 22.jun.2024 om 15:11 schreef olcott:

It is a verified fact that the behavior that finite string DDD
presents
to HH0 is that when DDD correctly simulated by HH0 calls HH0(DDD) >>>>>>> that
this call DOES NOT RETURN.

It is a verified fact that the behavior that finite string DDD
presents
to HH1 is that when DDD correctly simulated by HH0 calls HH1(DDD) >>>>>>> that
this call DOES RETURN.

I don't get why people here insist on lying about verified facts. >>>>>>>

We know that 'verified fact' for you means 'my wish'.

Ignoramus?

When we stipulate that the only measure of a correct emulation is
the semantics of the x86 programming language then we see that when
DDD is correctly emulated by H0 that its call to H0(DDD) cannot
possibly return.

_DDD()
[00002172] 55               push ebp      ; housekeeping
[00002173] 8bec             mov ebp,esp   ; housekeeping >>>>> [00002175] 6872210000       push 00002172 ; push DDD
[0000217a] e853f4ffff       call 000015d2 ; call H0(DDD)
[0000217f] 83c404           add esp,+04
[00002182] 5d               pop ebp
[00002183] c3               ret
Size in bytes:(0018) [00002183]

When we define H1 as identical to H0 except that DDD does not call
H1 then we see that when DDD is correctly emulated by H1 that its
call to H0(DDD) does return. This is the same behavior as the
directly executed DDD().

By a strict interpreation of your measure, this input has UNDEFIINED
BEHAVIOR, so it is improper to ask about it.

That is a stupid thing to say. The behavior of THE INPUT
is specified by the semantics of the x86 programming language.

Right, so what does a call to a location of memory that doesn't exist do?

Liar

How is a QUESTION a LIE?

I guess you feel it must be because I put you on the spot about your
deciet in your framing of the problem.

When we stipulate that the only measure of a correct emulation
is the semantics of the x86 programming language then we see
that when DDD is correctly emulated by H0 that its call to
H0(DDD) cannot possibly return.

Right, so what do you do when you run out of instructions to simulate?

Your logic just BLOWS UP.

_DDD()
[00002172] 55               push ebp      ; housekeeping [00002173] 8bec             mov ebp,esp   ; housekeeping [00002175] 6872210000       push 00002172 ; push DDD
[0000217a] e853f4ffff       call 000015d2 ; call H0(DDD)
[0000217f] 83c404           add esp,+04
[00002182] 5d               pop ebp
[00002183] c3               ret
Size in bytes:(0018) [00002183]

This exposes the LIE of your system. YOu CAN'T correctly x86 emulate a
partial program, becuase it isn't prpgram with behavior to emulate.

PERIOD.

That means, the call to H0(DDD), to have any actual meaning, must
incluede *ALL* the instrutions in memory that are going to be used as
part of the input, and thus, DDD is TIED to the H0 that we started with,
so your "trick" of changing it is shows to just be a LIE.


You just don't understand that behavior is determined of an SPECIFIC
program, a specific instance of the template AFTER pairing it with the
decider it is to foil, and when you ask about other deciders looking at
THIS input, the input can't change.

There goes your two decades down the drain.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

On 6/22/24 11:28 PM, olcott wrote:

On 6/22/2024 7:14 PM, Richard Damon wrote:

On 6/22/24 8:01 PM, olcott wrote:

When we stipulate that the only measure of a correct emulation
is the semantics of the x86 programming language then we see
that when DDD is correctly emulated by H0 that its call to
H0(DDD) cannot possibly return.

Right, so what do you do when you run out of instructions to simulate?

Your logic just BLOWS UP.

That you are too stupid to see an infinite recursion behavior
pattern does not mean that I am not correct.

Except it is proven to not be the infinite recursion behavior if H0 is a decider.

Just a finite recursion pattern.

So, which LIE are you holding to:

That this is an infinite recursion pattern, when every level of H0 will
break the pattern as it is a decider and not let itself go on forever

That H0 is a decider, because it isn't "smart" enough to see it is
caught in an infinte loop an get out of it, so it just fails to answer
at ANY level

That H0 is a "Pure Function" and thus *ALL* calls to it with the same parameters will act the same.


So, which *LIE* is it?


(Confirmed liar Peter Olcott)

_DDD()
[00002172] 55               push ebp      ; housekeeping >>> [00002173] 8bec             mov ebp,esp   ; housekeeping
[00002175] 6872210000       push 00002172 ; push DDD
[0000217a] e853f4ffff       call 000015d2 ; call H0(DDD)
[0000217f] 83c404           add esp,+04
[00002182] 5d               pop ebp
[00002183] c3               ret
Size in bytes:(0018) [00002183]

This exposes the LIE of your system. YOu CAN'T correctly x86 emulate a
partial program, becuase it isn't prpgram with behavior to emulate.

PERIOD.

That means, the call to H0(DDD), to have any actual meaning, must
incluede *ALL* the instrutions in memory that are going to be used as
part of the input, and thus, DDD is TIED to the H0 that we started
with, so your "trick" of changing it is shows to just be a LIE.


You just don't understand that behavior is determined of an SPECIFIC
program, a specific instance of the template AFTER pairing it with the
decider it is to foil, and when you ask about other deciders looking
at THIS input, the input can't change.

There goes your two decades down the drain.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

On 6/23/24 9:38 AM, olcott wrote:

On 6/23/2024 6:28 AM, Richard Damon wrote:

On 6/22/24 11:28 PM, olcott wrote:

On 6/22/2024 7:14 PM, Richard Damon wrote:

On 6/22/24 8:01 PM, olcott wrote:

When we stipulate that the only measure of a correct emulation
is the semantics of the x86 programming language then we see
that when DDD is correctly emulated by H0 that its call to
H0(DDD) cannot possibly return.

Right, so what do you do when you run out of instructions to simulate? >>>>
Your logic just BLOWS UP.

That you are too stupid to see an infinite recursion behavior
pattern does not mean that I am not correct.

Except it is proven to not be the infinite recursion behavior if H0 is
a decider.

Just a finite recursion pattern.

So, which LIE are you holding to:

That this is an infinite recursion pattern, when every level of H0
will break the pattern as it is a decider and not let itself go on
forever

That H0 is a decider, because it isn't "smart" enough to see it is
caught in an infinte loop an get out of it, so it just fails to answer
at ANY level

That H0 is a "Pure Function" and thus *ALL* calls to it with the same
parameters will act the same.


So, which *LIE* is it?


(Confirmed liar Peter Olcott)

_DDD()
[00002172] 55               push ebp      ; housekeeping
[00002173] 8bec             mov ebp,esp   ; housekeeping >>>>> [00002175] 6872210000       push 00002172 ; push DDD
[0000217a] e853f4ffff       call 000015d2 ; call H0(DDD)
[0000217f] 83c404           add esp,+04
[00002182] 5d               pop ebp
[00002183] c3               ret
Size in bytes:(0018) [00002183]

This exposes the LIE of your system. YOu CAN'T correctly x86 emulate
a partial program, becuase it isn't prpgram with behavior to emulate.

PERIOD.

That means, the call to H0(DDD), to have any actual meaning, must
incluede *ALL* the instrutions in memory that are going to be used
as part of the input, and thus, DDD is TIED to the H0 that we
started with, so your "trick" of changing it is shows to just be a LIE. >>>>

You just don't understand that behavior is determined of an SPECIFIC
program, a specific instance of the template AFTER pairing it with
the decider it is to foil, and when you ask about other deciders
looking at THIS input, the input can't change.

There goes your two decades down the drain.

_DDD()
[00002172] 55               push ebp
[00002173] 8bec             mov ebp,esp
[00002175] 6872210000       push 00002172 ; push DDD
[0000217a] e853f4ffff       call 000015d2 ; call HHH0
[0000217f] 83c404           add esp,+04
[00002182] 5d               pop ebp
[00002183] c3               ret
Size in bytes:(0018) [00002183]

According to the semantics of the x86 programming language
when DDD correctly emulated by H0 calls H0(DDD) this call
cannot possibly return.

Likewise according to the semantics of arithmetic for
decimal integers: 2 + 3 = 5.

Anyone disagreeing with these two statements is WRONG.

Now, if you REALLY mean just can HHH0 simulate this input to a final
state, the answer is WHO CARES.

But I will put out a few comments on errors in your presentation\.

First, if you ONLY have the bytes presented, then the answer becomes
trivial, as H0 HAS to stop emulating when it gets to the call
instruction, as there is no data at address 000015d2 defined to simulate.

This means you need to fix your problem statement to include the
instructions of HHH0, and everything that it calls as part of the
"input", or your question isn't the one you mean to be asking.

Of course, this means that each HHH0 that you try, is processing a
DIFFERENT input, so you can't argue from one about the behavior of a
different one.

Second, you forgot to specify what HHH0 has as requirements. Once you
include its code, so can simulate it, the "non-pure" function tricks
allow it to correctly simulate to the return instruction.

Reminder, you complain when we point out assumptions made on previous statements that you didn't want to carry forward, so you can't also
complain about us forgetting about requirements that you didn't bring
forward.

If you want to pull in the past, we can just point out that we KNOW you
are talking about a Halt Decider, and that your question is the wrong
question for a Halt decider.

So, your statement is wrong for two logical reasons as described above,
so your statement that anyone who disagrees is wrong is just wrong.

You don't know how to properly state a problem.

The last point to make, is that this is NOT a "proof" but just an
argument claiming something should be obviously true.

That may be a "proof" in the wild west of Philosophy, but it isn't in
the realm of Formal Logic, which is what the field you are talking about is.

So, you are making a statement, that when fixed to correct the deficits
in it, becomes a statement that might be plausably true, but not proven.

A proof can likely be made, but it seems that is beyond your ability
since you didn't even try, Of course, without the second fix, the
statement is just false, and without the first fix, the statment is meaningless, as of course you can't simulate to a return from a call
that you are unable to simulate past.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

Am Sat, 22 Jun 2024 13:47:24 -0500 schrieb olcott:

On 6/22/2024 1:39 PM, Fred. Zwarts wrote:

Op 21.jun.2024 om 15:21 schreef olcott:

When we stipulate that the only measure of a correct emulation is the semantics of the x86 programming language then we see that when DDD is correctly emulated by H0 that its call to H0(DDD) cannot possibly
return.

Yes. Which is wrong, because H0 should terminate.

--
Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche Mathematik
sind sie vollkommen nutzlos. --Wolfgang Mückenheim

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

[ Followup-To: set ]

In comp.theory olcott <polcott333@gmail.com> wrote:

On 6/25/2024 4:22 AM, joes wrote:

Am Sat, 22 Jun 2024 13:47:24 -0500 schrieb olcott:

On 6/22/2024 1:39 PM, Fred. Zwarts wrote:

Op 21.jun.2024 om 15:21 schreef olcott:

When we stipulate that the only measure of a correct emulation is the
semantics of the x86 programming language then we see that when DDD is
correctly emulated by H0 that its call to H0(DDD) cannot possibly
return.

Yes. Which is wrong, because H0 should terminate.

[ .... ]

The call from DDD to H0(DDD) when DDD is correctly emulated
by H0 cannot possibly return.

Until you acknowledge this is true, this is the
only thing that I am willing to talk to you about.

I think you are talking at cross purposes. Joes's point is that H0
should terminate because it's a decider. You're saying that when H0 is "correctly" emulating, it won't terminate. I don't recall seeing anybody arguing against that.

So you're saying, in effect, H0 is not a decider. I don't think anybody
else would argue against that, either.

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

--
Alan Mackenzie (Nuremberg, Germany).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Alan Mackenzie <acm@muc.de> writes:

[ Followup-To: set ]

In comp.theory olcott <polcott333@gmail.com> wrote:

On 6/25/2024 4:22 AM, joes wrote:

Am Sat, 22 Jun 2024 13:47:24 -0500 schrieb olcott:

On 6/22/2024 1:39 PM, Fred. Zwarts wrote:

Op 21.jun.2024 om 15:21 schreef olcott:

When we stipulate that the only measure of a correct emulation is the
semantics of the x86 programming language then we see that when DDD is >>>> correctly emulated by H0 that its call to H0(DDD) cannot possibly
return.

Yes. Which is wrong, because H0 should terminate.

[ .... ]

The call from DDD to H0(DDD) when DDD is correctly emulated
by H0 cannot possibly return.

Until you acknowledge this is true, this is the
only thing that I am willing to talk to you about.

I think you are talking at cross purposes. Joes's point is that H0
should terminate because it's a decider. You're saying that when H0 is "correctly" emulating, it won't terminate. I don't recall seeing anybody arguing against that.

So you're saying, in effect, H0 is not a decider. I don't think anybody
else would argue against that, either.

He's been making exactly the same nonsense argument for years. It
became crystal clear a little over three years ago when he made the
mistake of posting the pseudo-code for H -- a step by step simulator
that stopped simulating (famously on line 15) when some pattern was
detected. He declared false (not halting) to be the correct result for
the halting computation H(H_Hat(), H_Hat()) because of what H(H_Hat(),
H_Hat()) would do "if line 15 were commented out"!

PO does occasionally make it clear what the shell game is.

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

[ Followup-To: set ]

In comp.theory olcott <polcott333@gmail.com> wrote:

On 6/25/2024 8:46 AM, Alan Mackenzie wrote:

In comp.theory olcott <polcott333@gmail.com> wrote:

On 6/25/2024 4:22 AM, joes wrote:

Am Sat, 22 Jun 2024 13:47:24 -0500 schrieb olcott:

On 6/22/2024 1:39 PM, Fred. Zwarts wrote:

Op 21.jun.2024 om 15:21 schreef olcott:

When we stipulate that the only measure of a correct emulation is the >>>>> semantics of the x86 programming language then we see that when DDD is >>>>> correctly emulated by H0 that its call to H0(DDD) cannot possibly
return.

Yes. Which is wrong, because H0 should terminate.

[ .... ]

The call from DDD to H0(DDD) when DDD is correctly emulated
by H0 cannot possibly return.

Until you acknowledge this is true, this is the
only thing that I am willing to talk to you about.

I think you are talking at cross purposes. Joes's point is that H0
should terminate because it's a decider.

We must go though my points one-at-a-time and in order otherwise
we continue to talk in circles for 15 years as I did with Ben.

Just who do you think you are? If we had to constrain ourselves to your intellectual level, progress in these threads would grind to a near
complete halt. Remember, you're the one who's spent nearly 20 years on something a typical undergraduate grasps in a few hours at most, and you
still don't get it.

We can get to Joes point only after my point is acknowledged as
correct. I am unwilling to play head games with people that
deny verified facts.

I think Joes's point is more interesting than yours.

I am unwilling to talk in endless circles. I must get 100%
complete closure on each point before moving on to the next
point.

You've been talking in endless circles on this newsgroup for many years,
and that's not (mainly) because of other people's responses to you.

You're saying that when H0 is "correctly" emulating, it won't
terminate. I don't recall seeing anybody arguing against that.

Not at all. I am not tolerating talking about that point until
after we have 100% closure on the prior point.

That's not an attitude likely to lead to fruitful discussions.

So you're saying, in effect, H0 is not a decider. I don't think anybody
else would argue against that, either.

I never said anything like that.

It is an implication of the point you're willing to discuss at the
moment.

It is all a matter of me not tolerating the slightest nuance of any
head games what-so-ever.

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

--
Alan Mackenzie (Nuremberg, Germany).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi, Ben.

Ben Bacarisse <ben@bsb.me.uk> wrote:

Alan Mackenzie <acm@muc.de> writes:

In comp.theory olcott <polcott333@gmail.com> wrote:

On 6/25/2024 4:22 AM, joes wrote:

Am Sat, 22 Jun 2024 13:47:24 -0500 schrieb olcott:

On 6/22/2024 1:39 PM, Fred. Zwarts wrote:

Op 21.jun.2024 om 15:21 schreef olcott:

When we stipulate that the only measure of a correct emulation is the >>>>> semantics of the x86 programming language then we see that when DDD is >>>>> correctly emulated by H0 that its call to H0(DDD) cannot possibly
return.

Yes. Which is wrong, because H0 should terminate.

[ .... ]

The call from DDD to H0(DDD) when DDD is correctly emulated
by H0 cannot possibly return.

Until you acknowledge this is true, this is the
only thing that I am willing to talk to you about.

I think you are talking at cross purposes. Joes's point is that H0
should terminate because it's a decider. You're saying that when H0 is
"correctly" emulating, it won't terminate. I don't recall seeing anybody
arguing against that.

So you're saying, in effect, H0 is not a decider. I don't think anybody
else would argue against that, either.

He's been making exactly the same nonsense argument for years. It
became crystal clear a little over three years ago when he made the
mistake of posting the pseudo-code for H -- a step by step simulator
that stopped simulating (famously on line 15) when some pattern was
detected. He declared false (not halting) to be the correct result for
the halting computation H(H_Hat(), H_Hat()) because of what H(H_Hat(), H_Hat()) would do "if line 15 were commented out"!

PO does occasionally make it clear what the shell game is.

I think it's important for (relative) newcomers to the newsgroup to
become aware of this. Each one of them is trying to help PO improve his
level of learning. They will eventually give up, as you and I have
done, recognising (as Mike Terry, in particular, has done) that
enriching PO's intellect is a quite impossible task.

What's the betting he'll respond to this post with his usual short
sequence of x86 assembly code together with a demand to recognise
something or other as non-terminating?

--
Ben.

--
Alan Mackenzie (Nuremberg, Germany).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 25/06/2024 14:46, Alan Mackenzie wrote:

[ Followup-To: set ]

In comp.theory olcott <polcott333@gmail.com> wrote:

On 6/25/2024 4:22 AM, joes wrote:

Am Sat, 22 Jun 2024 13:47:24 -0500 schrieb olcott:

On 6/22/2024 1:39 PM, Fred. Zwarts wrote:

Op 21.jun.2024 om 15:21 schreef olcott:

When we stipulate that the only measure of a correct emulation is the
semantics of the x86 programming language then we see that when DDD is >>>> correctly emulated by H0 that its call to H0(DDD) cannot possibly
return.

Yes. Which is wrong, because H0 should terminate.

[ .... ]

The call from DDD to H0(DDD) when DDD is correctly emulated
by H0 cannot possibly return.

Until you acknowledge this is true, this is the
only thing that I am willing to talk to you about.

I think you are talking at cross purposes. Joes's point is that H0
should terminate because it's a decider. You're saying that when H0 is "correctly" emulating, it won't terminate. I don't recall seeing anybody arguing against that.

Hehe, everyone has an opinion on what PO is saying! :)

So here's mine: I think PO is saying that when DDD is correctly *emulated* [not "correctly
/emulating/"] then "it" will not return.

To be clear, that's saying that the /emulation/ does not get as far as the final return, i.e. outer
H0 will stop emulating (aka "abort") without having emulated DDD's return statement. PO has
acknowledged that the outer H0 will return after aborting its emulation.

So what? I hear everyone asking. So what indeed! The "behaviour" of a partial emulation is not the
behaviour of the computation itself [trivially] and not what the HP is about. But PO then gets
hopelessly muddled, thinking at least two wrong things:

1) That DDD would /never/ have terminated in "1-oo steps of emulation", i.e. that DDD really
doesn't halt, not simply that H0 aborted it before it returned. (Thats muddling all the different
examples of H in his head each with their own personalised (D,D) inputs into one single
super-H/super-D. Of course, the FIXED DDD under discussion /does/ in fact return in some finite
number of steps. H0 is also fixed and is coded in a way that aborts /before/ that number of steps
is emulated.)

2) PO knows that the /reason/ H0 decided to abort was that it matched his "infinite recursive
emulation" pattern in the emulation trace - therefore he believes it's correct to decide non-halting
because his pattern proves that. (That's just Wrong, but PO really really really believes the
pattern is sound, so that's the end of it. He has no intention or capability of ever attempting to
prove his rule is sound.)


Mike.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

Am Tue, 25 Jun 2024 09:03:38 -0500 schrieb olcott:

On 6/25/2024 8:46 AM, Alan Mackenzie wrote:

In comp.theory olcott <polcott333@gmail.com> wrote:

On 6/25/2024 4:22 AM, joes wrote:

Am Sat, 22 Jun 2024 13:47:24 -0500 schrieb olcott:

On 6/22/2024 1:39 PM, Fred. Zwarts wrote:

Op 21.jun.2024 om 15:21 schreef olcott:

When we stipulate that the only measure of a correct emulation is
the semantics of the x86 programming language then we see that when
DDD is correctly emulated by H0 that its call to H0(DDD) cannot
possibly return.

Yes. Which is wrong, because H0 should terminate.

I think you are talking at cross purposes. Joes's point is that H0
should terminate because it's a decider.

Thanks.

We can get to Joes point only after my point is acknowledged as correct.

It IS correct.

You're saying that when H0 is "correctly" emulating, it won't
terminate. I don't recall seeing anybody arguing against that.

Not at all. I am not tolerating talking about that point until after we
have 100% closure on the prior point.

What other point? This has been your only content for the last month.

So you're saying, in effect, H0 is not a decider. I don't think
anybody else would argue against that, either.

I never said anything like that. It is all a matter of me not tolerating
the slightest nuance of any head games what-so-ever.

You said H0 doesn't terminate.

--
Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche Mathematik
sind sie vollkommen nutzlos. --Wolfgang Mückenheim

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

Am Tue, 25 Jun 2024 12:21:25 -0500 schrieb olcott:

On 6/25/2024 11:28 AM, joes wrote:

Am Tue, 25 Jun 2024 09:03:38 -0500 schrieb olcott:

On 6/25/2024 8:46 AM, Alan Mackenzie wrote:

In comp.theory olcott <polcott333@gmail.com> wrote:

On 6/25/2024 4:22 AM, joes wrote:

Am Sat, 22 Jun 2024 13:47:24 -0500 schrieb olcott:

On 6/22/2024 1:39 PM, Fred. Zwarts wrote:

Op 21.jun.2024 om 15:21 schreef olcott:

You said H0 doesn't terminate.

*I never said that*

...

The call from DDD to H0(DDD) when DDD is correctly emulated by H0 cannot possibly return.

--
Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche Mathematik
sind sie vollkommen nutzlos. --Wolfgang Mückenheim

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)