Op 15.aug.2024 om 14:59 schreef olcott:

On 8/15/2024 3:20 AM, Fred. Zwarts wrote:

Op 14.aug.2024 om 23:08 schreef olcott:

On 8/14/2024 3:56 PM, Mike Terry wrote:

On 14/08/2024 18:45, olcott wrote:

On 8/14/2024 11:31 AM, joes wrote:

Am Wed, 14 Aug 2024 08:42:33 -0500 schrieb olcott:

On 8/14/2024 2:30 AM, Mikko wrote:

On 2024-08-13 13:30:08 +0000, olcott said:

On 8/13/2024 6:23 AM, Richard Damon wrote:

On 8/12/24 11:45 PM, olcott wrote:

*DDD correctly emulated by HHH cannot possibly reach its* *own >>>>>>>>>>> "return" instruction final halt state, thus never halts* >>>>>>>>>>>

Which is only correct if HHH actuallly does a complete and >>>>>>>>>> correct
emulation, or the behavior DDD (but not the emulation of DDD >>>>>>>>>> by HHH)
will reach that return.

A complete emulation of a non-terminating input has always been a >>>>>>>>> contradiction in terms.
HHH correctly predicts that a correct and unlimited emulation >>>>>>>>> of DDD
by HHH cannot possibly reach its own "return" instruction final >>>>>>>>> halt
state.

That is not a meaningful prediction because a complete and
unlimited
emulation of DDD by HHH never happens.

A complete emulation is not required to correctly predict that a >>>>>>> complete emulation would never halt.

What do we care about a complete simulation? HHH isn't doing one.

Please go read how Mike corrected you.

Lol, dude...  I mentioned nothing about complete/incomplete
simulations.

*You corrected Joes most persistent error*
She made sure to ignore this correction.

But while we're here - a complete simulation of input D() would
clearly halt.

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

A complete simulation *by HHH* remains stuck in
infinite recursion until aborted.

It is aborted, so the infinite recursion is just a dream.

All simulating termination analyzers are required
to predict what the behavior would be when the
emulation is unlimited (never aborted) otherwise
they could never report on the behavior of this function:

void Infinite_Loop()
{
  HERE: goto HERE;
}

Irrelevant when there is a halting input. The HHH that aborts halts, so
forget about the HHH that does not halt.

Also something that you consistently ignore is that
HHH is not reporting on its own behavior. HHH is only
predicting whether or not an unlimited emulation of
DDD would reach the "return" instruction of DDD.

void DDD()
{
  HHH(DDD);
  return;
}

And it is wrong, as is proved by the unlimited simulation of HHH by HHH1.

What you ignore is that DDD is completely irrelevant.
DDD is a misleading and unneeded complication. It is easy to eliminate DDD:

int main() {
return HHH(main);
}

This has the same problem. This proves that the problem is not in DDD,
but in HHH, which halts when it aborts the simulation, but it decides
that the simulation of itself does not halt.
It shows that HHH cannot possibly simulate itself correctly.

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

Am Thu, 15 Aug 2024 07:59:30 -0500 schrieb olcott:

On 8/15/2024 3:20 AM, Fred. Zwarts wrote:

Op 14.aug.2024 om 23:08 schreef olcott:

On 8/14/2024 3:56 PM, Mike Terry wrote:

On 14/08/2024 18:45, olcott wrote:

On 8/14/2024 11:31 AM, joes wrote:

Am Wed, 14 Aug 2024 08:42:33 -0500 schrieb olcott:

On 8/14/2024 2:30 AM, Mikko wrote:

On 2024-08-13 13:30:08 +0000, olcott said:

On 8/13/2024 6:23 AM, Richard Damon wrote:

On 8/12/24 11:45 PM, olcott wrote:

*DDD correctly emulated by HHH cannot possibly reach its* *own >>>>>>>>>>> "return" instruction final halt state, thus never halts* >>>>>>>>>>>

Which is only correct if HHH actuallly does a complete and >>>>>>>>>> correct emulation, or the behavior DDD (but not the emulation >>>>>>>>>> of DDD by HHH) will reach that return.

A complete emulation of a non-terminating input has always been >>>>>>>>> a contradiction in terms.
HHH correctly predicts that a correct and unlimited emulation of >>>>>>>>> DDD by HHH cannot possibly reach its own "return" instruction >>>>>>>>> final halt state.

That is not a meaningful prediction because a complete and
unlimited emulation of DDD by HHH never happens.

A complete emulation is not required to correctly predict that a >>>>>>> complete emulation would never halt.

What do we care about a complete simulation? HHH isn't doing one.

Please go read how Mike corrected you.

Lol, dude...  I mentioned nothing about complete/incomplete
simulations.

*You corrected Joes most persistent error*
She made sure to ignore this correction.

But while we're here - a complete simulation of input D() would
clearly halt.

A complete simulation *by HHH* remains stuck in infinite recursion
until aborted.

It is aborted, so the infinite recursion is just a dream.

All simulating termination analyzers are required to predict what the behavior would be when the emulation is unlimited (never aborted)

Also something that you consistently ignore is that HHH is not reporting
on its own behavior. HHH is only predicting whether or not an unlimited emulation of DDD would reach the "return" instruction of DDD.

Which it would, because HHH aborts, both the one simulating DDD as well
as the one called by DDD.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

On 2024-08-15 12:59:30 +0000, olcott said:

On 8/15/2024 3:20 AM, Fred. Zwarts wrote:

Op 14.aug.2024 om 23:08 schreef olcott:

On 8/14/2024 3:56 PM, Mike Terry wrote:

On 14/08/2024 18:45, olcott wrote:

On 8/14/2024 11:31 AM, joes wrote:

Am Wed, 14 Aug 2024 08:42:33 -0500 schrieb olcott:

On 8/14/2024 2:30 AM, Mikko wrote:

On 2024-08-13 13:30:08 +0000, olcott said:

On 8/13/2024 6:23 AM, Richard Damon wrote:

On 8/12/24 11:45 PM, olcott wrote:

*DDD correctly emulated by HHH cannot possibly reach its* *own >>>>>>>>>>> "return" instruction final halt state, thus never halts* >>>>>>>>>>>

Which is only correct if HHH actuallly does a complete and correct >>>>>>>>>> emulation, or the behavior DDD (but not the emulation of DDD by HHH) >>>>>>>>>> will reach that return.

A complete emulation of a non-terminating input has always been a >>>>>>>>> contradiction in terms.
HHH correctly predicts that a correct and unlimited emulation of DDD >>>>>>>>> by HHH cannot possibly reach its own "return" instruction final halt >>>>>>>>> state.

That is not a meaningful prediction because a complete and unlimited >>>>>>>> emulation of DDD by HHH never happens.

A complete emulation is not required to correctly predict that a >>>>>>> complete emulation would never halt.

What do we care about a complete simulation? HHH isn't doing one.

Please go read how Mike corrected you.

Lol, dude...  I mentioned nothing about complete/incomplete simulations. >>>>

*You corrected Joes most persistent error*
She made sure to ignore this correction.

But while we're here - a complete simulation of input D() would clearly halt.

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

A complete simulation *by HHH* remains stuck in
infinite recursion until aborted.

It is aborted, so the infinite recursion is just a dream.

All simulating termination analyzers are required
to predict what the behavior would be when the
emulation is unlimited (never aborted) otherwise
they could never report on the behavior of this function:

void Infinite_Loop()
{
HERE: goto HERE;
}

Also something that you consistently ignore is that
HHH is not reporting on its own behavior. HHH is only
predicting whether or not an unlimited emulation of
DDD would reach the "return" instruction of DDD.

void DDD()
{
HHH(DDD);
return;
}

Actually HHH does not report at all. HHH just returns one value for
some inputs and another vaule for other inputs. HHH does not tell
how those values correlate with any features of the input. It is
the user's problem to interprete the inputs. The author of the
program should tell what the inputs mean but the user should be
aware that the infromation given by the author may be incorrect.
The author has not proven anything abut the interpretation of
the answers by HHH.

--
Mikko

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

On 2024-08-16 12:02:00 +0000, olcott said:

On 8/16/2024 6:06 AM, Mikko wrote:

On 2024-08-15 12:59:30 +0000, olcott said:

On 8/15/2024 3:20 AM, Fred. Zwarts wrote:

Op 14.aug.2024 om 23:08 schreef olcott:

On 8/14/2024 3:56 PM, Mike Terry wrote:

On 14/08/2024 18:45, olcott wrote:

On 8/14/2024 11:31 AM, joes wrote:

Am Wed, 14 Aug 2024 08:42:33 -0500 schrieb olcott:

On 8/14/2024 2:30 AM, Mikko wrote:

On 2024-08-13 13:30:08 +0000, olcott said:

On 8/13/2024 6:23 AM, Richard Damon wrote:

On 8/12/24 11:45 PM, olcott wrote:

*DDD correctly emulated by HHH cannot possibly reach its* *own >>>>>>>>>>>>> "return" instruction final halt state, thus never halts* >>>>>>>>>>>>>

Which is only correct if HHH actuallly does a complete and correct >>>>>>>>>>>> emulation, or the behavior DDD (but not the emulation of DDD by HHH)
will reach that return.

A complete emulation of a non-terminating input has always been a >>>>>>>>>>> contradiction in terms.
HHH correctly predicts that a correct and unlimited emulation of DDD
by HHH cannot possibly reach its own "return" instruction final halt
state.

That is not a meaningful prediction because a complete and unlimited >>>>>>>>>> emulation of DDD by HHH never happens.

A complete emulation is not required to correctly predict that a >>>>>>>>> complete emulation would never halt.

What do we care about a complete simulation? HHH isn't doing one. >>>>>>>>

Please go read how Mike corrected you.

Lol, dude...  I mentioned nothing about complete/incomplete simulations.

*You corrected Joes most persistent error*
She made sure to ignore this correction.

But while we're here - a complete simulation of input D() would clearly halt.

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

A complete simulation *by HHH* remains stuck in
infinite recursion until aborted.

It is aborted, so the infinite recursion is just a dream.

All simulating termination analyzers are required
to predict what the behavior would be when the
emulation is unlimited (never aborted) otherwise
they could never report on the behavior of this function:

void Infinite_Loop()
{
   HERE: goto HERE;
}

Also something that you consistently ignore is that
HHH is not reporting on its own behavior. HHH is only
predicting whether or not an unlimited emulation of
DDD would reach the "return" instruction of DDD.

void DDD()
{
   HHH(DDD);
   return;
}

Actually HHH does not report at all. HHH just returns one value for
some inputs and another vaule for other inputs. HHH does not tell
how those values correlate with any features of the input. It is
the user's problem to interprete the inputs. The author of the
program should tell what the inputs mean but the user should be
aware that the infromation given by the author may be incorrect.
The author has not proven anything abut the interpretation of
the answers by HHH.

I must go one step at a time.

That's reasonable in a discussion. The one thing you were discussing
above is what is the meaning of the output of HHH. Its OK to stay
at that step until we are sure it is understood.

--
Mikko

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

On 8/16/24 10:09 AM, olcott wrote:

On 8/16/2024 8:34 AM, Mikko wrote:

On 2024-08-16 12:02:00 +0000, olcott said:

I must go one step at a time.

That's reasonable in a discussion. The one thing you were discussing
above is what is the meaning of the output of HHH. Its OK to stay
at that step until we are sure it is understood.

void DDD()
{
  HHH(DDD);
  return;
}

Unless an unlimited emulation of DDD by HHH
can reach the "return" instruction of DDD it is
construed that this instance of DDD never halts.

But that also construes that HHH is a program that DOES an unlimited
emulation of DDD, and thus isn't a decider

For three years now at least most reviewers insisted
on disagreeing with the semantics of the x86 language.

No, the problem is HHH can't be two different things at once, and since
DDD includes its HHH as part of its definition, the DDD that the HHH
that DDD calls, can see any other DDD than the one that called IT, and
not some other HHH.


The fact that you just don't understand that proper way to setup a
correct emulator that can emulate any program given to it just wrecks
your argument and renders your logic void.

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

On 8/16/24 10:42 AM, olcott wrote:

On 8/16/2024 9:28 AM, Richard Damon wrote:

On 8/16/24 10:09 AM, olcott wrote:

On 8/16/2024 8:34 AM, Mikko wrote:

On 2024-08-16 12:02:00 +0000, olcott said:

I must go one step at a time.

That's reasonable in a discussion. The one thing you were discussing
above is what is the meaning of the output of HHH. Its OK to stay
at that step until we are sure it is understood.

void DDD()
{
   HHH(DDD);
   return;
}

Unless an unlimited emulation of DDD by HHH
can reach the "return" instruction of DDD it is
construed that this instance of DDD never halts.

But that also construes that HHH is a program that DOES an unlimited
emulation of DDD, and thus isn't a decider

Not at all. never has.
HHH must predict what the behavior of an unlimited
simulation would be.

Right, unlimited emulation of the EXACT input that HHH got, that is the
DDD that calls the HHH that is the decider

Not the input with HHH changed for an unlimited emulator.

You just don't understand what the PROGRAM DDD is.

It seems you have a funny-mental problem understanding what "same" and "different" are.

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

Am Fri, 16 Aug 2024 09:42:13 -0500 schrieb olcott:

On 8/16/2024 9:28 AM, Richard Damon wrote:

On 8/16/24 10:09 AM, olcott wrote:

On 8/16/2024 8:34 AM, Mikko wrote:

On 2024-08-16 12:02:00 +0000, olcott said:

Unless an unlimited emulation of DDD by HHH can reach the "return"
instruction of DDD it is construed that this instance of DDD never
halts.

But that also construes that HHH is a program that DOES an unlimited
emulation of DDD, and thus isn't a decider

Not at all. never has.

Yes, because DDD is defined to call its simulator. If you change the
simulator to abort, you also change the simulated HHH. Nobody cares
about HHH aborting a pure simulator.

HHH must predict what the behavior of an unlimited simulation would be.

The HHH that aborts must predict what DDD calling an aborting HHH does - halting. It's fine if it aborts, as long as it gives the correct result.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

On 8/16/24 11:05 AM, olcott wrote:

On 8/16/2024 9:56 AM, Richard Damon wrote:

On 8/16/24 10:42 AM, olcott wrote:

On 8/16/2024 9:28 AM, Richard Damon wrote:

On 8/16/24 10:09 AM, olcott wrote:

On 8/16/2024 8:34 AM, Mikko wrote:

On 2024-08-16 12:02:00 +0000, olcott said:

I must go one step at a time.

That's reasonable in a discussion. The one thing you were discussing >>>>>> above is what is the meaning of the output of HHH. Its OK to stay
at that step until we are sure it is understood.

void DDD()
{
   HHH(DDD);
   return;
}

Unless an unlimited emulation of DDD by HHH
can reach the "return" instruction of DDD it is
construed that this instance of DDD never halts.

But that also construes that HHH is a program that DOES an unlimited
emulation of DDD, and thus isn't a decider

Not at all. never has.
HHH must predict what the behavior of an unlimited
simulation would be.

Right, unlimited emulation of the EXACT input that HHH got, that is
the DDD that calls the HHH that is the decider

PREDICT WHAT THE BEHAVIOR WOULD BE
PREDICT WHAT THE BEHAVIOR WOULD BE
PREDICT WHAT THE BEHAVIOR WOULD BE
PREDICT WHAT THE BEHAVIOR WOULD BE

IF IT WAS AN UNLIMITED EMULATION
IF IT WAS AN UNLIMITED EMULATION
IF IT WAS AN UNLIMITED EMULATION
IF IT WAS AN UNLIMITED EMULATION

So, I guess you aren't working on the Halting Problem, or any problem in computation theory, as all of those ask about the behavior of the
program as it is.

Sorry, you are just proving your stupidity, and that you are so stupid
you don't understand your stupidity, which is the worse kind of stupd.

Where did you get your false problem from?

I think is can out of your behind, which is why it is the POOP problem.

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

On 8/16/24 11:45 AM, olcott wrote:

On 8/16/2024 10:39 AM, Richard Damon wrote:

On 8/16/24 11:05 AM, olcott wrote:

On 8/16/2024 9:56 AM, Richard Damon wrote:

On 8/16/24 10:42 AM, olcott wrote:

On 8/16/2024 9:28 AM, Richard Damon wrote:

On 8/16/24 10:09 AM, olcott wrote:

On 8/16/2024 8:34 AM, Mikko wrote:

On 2024-08-16 12:02:00 +0000, olcott said:

I must go one step at a time.

That's reasonable in a discussion. The one thing you were
discussing
above is what is the meaning of the output of HHH. Its OK to stay >>>>>>>> at that step until we are sure it is understood.

void DDD()
{
   HHH(DDD);
   return;
}

Unless an unlimited emulation of DDD by HHH
can reach the "return" instruction of DDD it is
construed that this instance of DDD never halts.

But that also construes that HHH is a program that DOES an
unlimited emulation of DDD, and thus isn't a decider

Not at all. never has.
HHH must predict what the behavior of an unlimited
simulation would be.

Right, unlimited emulation of the EXACT input that HHH got, that is
the DDD that calls the HHH that is the decider

PREDICT WHAT THE BEHAVIOR WOULD BE
PREDICT WHAT THE BEHAVIOR WOULD BE
PREDICT WHAT THE BEHAVIOR WOULD BE
PREDICT WHAT THE BEHAVIOR WOULD BE

IF IT WAS AN UNLIMITED EMULATION
IF IT WAS AN UNLIMITED EMULATION
IF IT WAS AN UNLIMITED EMULATION
IF IT WAS AN UNLIMITED EMULATION

So, I guess you aren't working on the Halting Problem,

Halt deciders have always been required to predict what the
behavior of their input would be.

Right, and the input to the Halt Decider HHH is the DDD that calls the
Halt Decider HHH, not the DDD that calls the unlimited emulator HHH.

If we have an unlimited Emulator U, then U(DDD) will have U emulate DDD
calling HHH, which will then emulated DDD calling HHH, and HHH deciding (incorrectly) that it won't halt, and then HHH returns to DDD which then
Halts.

Thus, the CORRECT answer that HHH should have gotten, if it was a
correct Halt Decider is that its input Halts.

You problem is you seem to have a funny-mental block on the concept of a program, and don't understand that as a program, the thing that a Halt
Decider needs as its input, includes all the code of the program, which
is the HHH that DDD calls.

This causes you to use just lying logic claiming that all version of DDD
that call different HHHs are "the same", when they are not.

The confusion of things that are different as being the same is one form
of insnaity, showing what you mental state actually is.

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

Am Fri, 16 Aug 2024 10:07:08 -0500 schrieb olcott:

On 8/16/2024 9:59 AM, joes wrote:

Am Fri, 16 Aug 2024 09:42:13 -0500 schrieb olcott:

On 8/16/2024 9:28 AM, Richard Damon wrote:

On 8/16/24 10:09 AM, olcott wrote:

On 8/16/2024 8:34 AM, Mikko wrote:

On 2024-08-16 12:02:00 +0000, olcott said:

Unless an unlimited emulation of DDD by HHH can reach the "return"
instruction of DDD it is construed that this instance of DDD never
halts.

But that also construes that HHH is a program that DOES an unlimited
emulation of DDD, and thus isn't a decider

Not at all. never has.

Yes, because DDD is defined to call its simulator. If you change the
simulator to abort, you also change the simulated HHH. Nobody cares
about HHH aborting a pure simulator.

HHH must predict what the behavior of an unlimited simulation would
be.

The HHH that aborts must predict what DDD calling an aborting HHH does

NOT AT ALL, NEVER HAS.
PREDICT WHAT THE BEHAVIOR WOULD BE
IF IT WAS AN UNLIMITED EMULATION

Yes, an unlimited simulation of an aborting HHH. This simulation does
not need to be aborted, because the simulated HHH halts.

halting. It's fine if it aborts, as long as it gives the correct
result.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

On 8/16/24 12:12 PM, olcott wrote:

On 8/16/2024 11:00 AM, Richard Damon wrote:

On 8/16/24 11:45 AM, olcott wrote:

On 8/16/2024 10:39 AM, Richard Damon wrote:

On 8/16/24 11:05 AM, olcott wrote:

On 8/16/2024 9:56 AM, Richard Damon wrote:

On 8/16/24 10:42 AM, olcott wrote:

On 8/16/2024 9:28 AM, Richard Damon wrote:

On 8/16/24 10:09 AM, olcott wrote:

On 8/16/2024 8:34 AM, Mikko wrote:

On 2024-08-16 12:02:00 +0000, olcott said:

I must go one step at a time.

That's reasonable in a discussion. The one thing you were
discussing
above is what is the meaning of the output of HHH. Its OK to stay >>>>>>>>>> at that step until we are sure it is understood.

void DDD()
{
   HHH(DDD);
   return;
}

Unless an unlimited emulation of DDD by HHH
can reach the "return" instruction of DDD it is
construed that this instance of DDD never halts.

But that also construes that HHH is a program that DOES an
unlimited emulation of DDD, and thus isn't a decider

Not at all. never has.
HHH must predict what the behavior of an unlimited
simulation would be.

Right, unlimited emulation of the EXACT input that HHH got, that
is the DDD that calls the HHH that is the decider

PREDICT WHAT THE BEHAVIOR WOULD BE
PREDICT WHAT THE BEHAVIOR WOULD BE
PREDICT WHAT THE BEHAVIOR WOULD BE
PREDICT WHAT THE BEHAVIOR WOULD BE

IF IT WAS AN UNLIMITED EMULATION
IF IT WAS AN UNLIMITED EMULATION
IF IT WAS AN UNLIMITED EMULATION
IF IT WAS AN UNLIMITED EMULATION

So, I guess you aren't working on the Halting Problem,

Halt deciders have always been required to predict what the
behavior of their input would be.

Right, and the input to the Halt Decider HHH is the DDD that calls the
Halt Decider HHH, not the DDD that calls the unlimited emulator HHH.

You can't get away with disagreeing with the semantics
of the x86 language.

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

Which isn't a program, so doesn't HAVE a complete behavior per the
semantics of the x86 language,

You need to include the code of HHH at 000015d2, and since that code, as
you have provided it elsewhere DOES return to its caller when given this
input, shows that by the x86 semantics, DDD is a halting program.

Of course, ultimately, you HHH violates the requrements of a decider in
that it is not a pure function of its explicit input, but uses memory
defined outside of its self to determine its behavior says that even if
HHH tried to do a "complete and correct" emulation of its input, that
would not be the same behavior as that of its input, as the HHH seen in
the emulation gets different hidden inputs to the HHH from the DDD
called directly, so your criteria is just broken,

Sorry, but it has been clearly shown that you have just wasted these
last years of your life working on things that are just incorrect
because you believed your own lies, and didn't code to the right
specificaiton.

You are just continuing to demonstrate your total ignorance of the
topics you are trying to talk about, and your inability to understand
this just shws that you are the worse kind of stupid, the stupid that
can't see what it doesn't know, but is certain of things that are wrong
because it refuses to look at the actual facts.

Sorry, that is just the facts, facts you likely just can't see because
you brainwashed and gaslight yourself.

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

On 8/16/24 1:11 PM, olcott wrote:

On 8/16/2024 11:47 AM, joes wrote:

Am Fri, 16 Aug 2024 10:07:08 -0500 schrieb olcott:

On 8/16/2024 9:59 AM, joes wrote:

Am Fri, 16 Aug 2024 09:42:13 -0500 schrieb olcott:

On 8/16/2024 9:28 AM, Richard Damon wrote:

On 8/16/24 10:09 AM, olcott wrote:

On 8/16/2024 8:34 AM, Mikko wrote:

On 2024-08-16 12:02:00 +0000, olcott said:

Unless an unlimited emulation of DDD by HHH can reach the "return" >>>>>>> instruction of DDD it is construed that this instance of DDD never >>>>>>> halts.

But that also construes that HHH is a program that DOES an unlimited >>>>>> emulation of DDD, and thus isn't a decider

Not at all. never has.

Yes, because DDD is defined to call its simulator. If you change the
simulator to abort, you also change the simulated HHH. Nobody cares
about HHH aborting a pure simulator.

HHH must predict what the behavior of an unlimited simulation would
be.

The HHH that aborts must predict what DDD calling an aborting HHH does

NOT AT ALL, NEVER HAS.
PREDICT WHAT THE BEHAVIOR WOULD BE
IF IT WAS AN UNLIMITED EMULATION

Yes, an unlimited simulation of an aborting HHH.

Prediction of behavior of unlimited emulation
means prediction of behavior that never aborts.

Right, but the unlimited emulation of the DDD that calls the HHH that
says non-halting will reach a final state.

You are just proving that you don't understand the meaning of the words
you are using, and don't care about the actual meaing, making you into a pathological liar.

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

Am Fri, 16 Aug 2024 13:04:38 -0500 schrieb olcott:

On 8/16/2024 12:54 PM, Richard Damon wrote:

On 8/16/24 1:11 PM, olcott wrote:

On 8/16/2024 11:47 AM, joes wrote:

Am Fri, 16 Aug 2024 10:07:08 -0500 schrieb olcott:

On 8/16/2024 9:59 AM, joes wrote:

Am Fri, 16 Aug 2024 09:42:13 -0500 schrieb olcott:

On 8/16/2024 9:28 AM, Richard Damon wrote:

On 8/16/24 10:09 AM, olcott wrote:

On 8/16/2024 8:34 AM, Mikko wrote:

On 2024-08-16 12:02:00 +0000, olcott said:

But that also construes that HHH is a program that DOES an
unlimited emulation of DDD, and thus isn't a decider

Yes, because DDD is defined to call its simulator. If you change
the simulator to abort, you also change the simulated HHH. Nobody
cares about HHH aborting a pure simulator.

HHH must predict what the behavior of an unlimited simulation
would be.

The HHH that aborts must predict what DDD calling an aborting HHH
does

NOT AT ALL, NEVER HAS.
PREDICT WHAT THE BEHAVIOR WOULD BE IF IT WAS AN UNLIMITED EMULATION

Yes, an unlimited simulation of an aborting HHH.

Prediction of behavior of unlimited emulation means prediction of
behavior that never aborts.

*is never aborted
I think you are confusing the simulator and the simulated HHH.

Right, but the unlimited emulation of the DDD that calls the HHH that
says non-halting will reach a final state.

I think that you are just twisting my words again.

Funny how you say that.

The unlimited emulation of DDD by HHH never stops running.

The complete simulation of the aborting HHH (called by DDD)
well, halts due to the simulated abort.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

Am Fri, 16 Aug 2024 12:09:38 -0500 schrieb olcott:

On 8/16/2024 11:41 AM, Richard Damon wrote:

On 8/16/24 12:12 PM, olcott wrote:

On 8/16/2024 11:00 AM, Richard Damon wrote:

On 8/16/24 11:45 AM, olcott wrote:

On 8/16/2024 10:39 AM, Richard Damon wrote:

On 8/16/24 11:05 AM, olcott wrote:

On 8/16/2024 9:56 AM, Richard Damon wrote:

On 8/16/24 10:42 AM, olcott wrote:

On 8/16/2024 9:28 AM, Richard Damon wrote:

On 8/16/24 10:09 AM, olcott wrote:

On 8/16/2024 8:34 AM, Mikko wrote:

On 2024-08-16 12:02:00 +0000, olcott said:

But that also construes that HHH is a program that DOES an >>>>>>>>>> unlimited emulation of DDD, and thus isn't a decider

Not at all. never has.
HHH must predict what the behavior of an unlimited simulation >>>>>>>>> would be.

Right, unlimited emulation of the EXACT input that HHH got, that >>>>>>>> is the DDD that calls the HHH that is the decider

PREDICT WHAT THE BEHAVIOR WOULD BE IF IT WAS AN UNLIMITED

EMULATION
To clarify: if itself wouldn't abort, not: if it's input wouldn't abort.

Right, and the input to the Halt Decider HHH is the DDD that calls
the Halt Decider HHH, not the DDD that calls the unlimited emulator
HHH.

THIS

You can't get away with disagreeing with the semantics of the x86
language.

Not even happening.

Which isn't a program, so doesn't HAVE a complete behavior per the
semantics of the x86 language,

It is isomorphic to a program and to a Turing Machine.

See below:

You need to include the code of HHH at 000015d2, and since that code,
as you have provided it elsewhere DOES return to its caller when given
this input, shows that by the x86 semantics, DDD is a halting program.

I have conclusively proved that it has been obviously doing this for
three years.

Unfortunately you must have misread.

THE INPUT TO HHH(DDD) CANNOT POSSIBLY REACH ITS RETURN INSTRUCTION THUS
DOES NOT HALT.

The input DDD does halt.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

On 8/16/24 2:04 PM, olcott wrote:

On 8/16/2024 12:54 PM, Richard Damon wrote:

On 8/16/24 1:11 PM, olcott wrote:

On 8/16/2024 11:47 AM, joes wrote:

Am Fri, 16 Aug 2024 10:07:08 -0500 schrieb olcott:

On 8/16/2024 9:59 AM, joes wrote:

Am Fri, 16 Aug 2024 09:42:13 -0500 schrieb olcott:

On 8/16/2024 9:28 AM, Richard Damon wrote:

On 8/16/24 10:09 AM, olcott wrote:

On 8/16/2024 8:34 AM, Mikko wrote:

On 2024-08-16 12:02:00 +0000, olcott said:

Unless an unlimited emulation of DDD by HHH can reach the "return" >>>>>>>>> instruction of DDD it is construed that this instance of DDD never >>>>>>>>> halts.

But that also construes that HHH is a program that DOES an
unlimited
emulation of DDD, and thus isn't a decider

Not at all. never has.

Yes, because DDD is defined to call its simulator. If you change the >>>>>> simulator to abort, you also change the simulated HHH. Nobody cares >>>>>> about HHH aborting a pure simulator.

HHH must predict what the behavior of an unlimited simulation would >>>>>>> be.

The HHH that aborts must predict what DDD calling an aborting HHH
does

NOT AT ALL, NEVER HAS.
PREDICT WHAT THE BEHAVIOR WOULD BE
IF IT WAS AN UNLIMITED EMULATION

Yes, an unlimited simulation of an aborting HHH.

Prediction of behavior of unlimited emulation
means prediction of behavior that never aborts.

Right, but the unlimited emulation of the DDD that calls the HHH that
says non-halting will reach a final state.

I think that you are just twisting my words again.

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

The unlimited emulation of DDD by HHH never stops running.

IF you are going to change an define that *THE* HHH is just a program
that does unlimited emulation, than it fails to give the answer that the
input is non-halting.

That's your problem, you only get to have one definition of what HHH is,
as the definition of DDD includes the HHH that it is calling.

For you to claim that HHH needs to answer about something other than
what HHH is acually given, which is the DDD that calls the HHH that is
there, is just a LIE.

So, you have to choose which way you are wrong.

Eitehr HHH does the unlimited emulation, and thus fails to answer, or

HHH does a partial emulation of the DDD that calls the partially
emulating HHH which makes DDD halting, and thus your HHH gives the wrong answer.

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

On 8/16/24 2:57 PM, olcott wrote:

On 8/16/2024 1:49 PM, Richard Damon wrote:

On 8/16/24 2:04 PM, olcott wrote:

On 8/16/2024 12:54 PM, Richard Damon wrote:

On 8/16/24 1:11 PM, olcott wrote:

On 8/16/2024 11:47 AM, joes wrote:

Am Fri, 16 Aug 2024 10:07:08 -0500 schrieb olcott:

On 8/16/2024 9:59 AM, joes wrote:

Am Fri, 16 Aug 2024 09:42:13 -0500 schrieb olcott:

On 8/16/2024 9:28 AM, Richard Damon wrote:

On 8/16/24 10:09 AM, olcott wrote:

On 8/16/2024 8:34 AM, Mikko wrote:

On 2024-08-16 12:02:00 +0000, olcott said:

Unless an unlimited emulation of DDD by HHH can reach the >>>>>>>>>>> "return"
instruction of DDD it is construed that this instance of DDD >>>>>>>>>>> never
halts.

But that also construes that HHH is a program that DOES an >>>>>>>>>> unlimited
emulation of DDD, and thus isn't a decider

Not at all. never has.

Yes, because DDD is defined to call its simulator. If you change >>>>>>>> the
simulator to abort, you also change the simulated HHH. Nobody cares >>>>>>>> about HHH aborting a pure simulator.

HHH must predict what the behavior of an unlimited simulation >>>>>>>>> would
be.

The HHH that aborts must predict what DDD calling an aborting
HHH does

NOT AT ALL, NEVER HAS.
PREDICT WHAT THE BEHAVIOR WOULD BE
IF IT WAS AN UNLIMITED EMULATION

Yes, an unlimited simulation of an aborting HHH.

Prediction of behavior of unlimited emulation
means prediction of behavior that never aborts.

Right, but the unlimited emulation of the DDD that calls the HHH
that says non-halting will reach a final state.

I think that you are just twisting my words again.

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

The unlimited emulation of DDD by HHH never stops running.

IF you are going to change an define that *THE* HHH is just a program
that does unlimited emulation, than it fails to give the answer that
the input is non-halting.

HHH correctly predicts...
HHH correctly predicts...
HHH correctly predicts...
HHH correctly predicts...
HHH correctly predicts...

I will get the another piece of this sentence
after you fully understand this first piece.

How can HHH correctly predict something that won't happen?

If we do an unlimited emulation of the DDD that calls the HHH that you
have that aborts and returns, that unlimited emulation will reach a
final state, and thus the correct prediction is to halt.

To claim that it corectly predicts about an input that isn't the input
it was actually give is just a lie.

Remember, Halting is about programs, and programs include ALL the code
they use, so the input DDD include ALL the code of the HHH that it calls.

Since the HHH that aborts was given a DDD that calls the HHH that
aborts, it is not proper for it to answer about a DIFFERENT DDD that
calls the HHH that does an unlimited emulation of it.

You are just trying to assert that LYING is valid logic, sorry, that is
juat a LIE and not valid logic.

You are just proving you fail at the basic test of fundamental knowledge
of the field.

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

Op 16.aug.2024 om 16:42 schreef olcott:

On 8/16/2024 9:28 AM, Richard Damon wrote:

On 8/16/24 10:09 AM, olcott wrote:

On 8/16/2024 8:34 AM, Mikko wrote:

On 2024-08-16 12:02:00 +0000, olcott said:

I must go one step at a time.

That's reasonable in a discussion. The one thing you were discussing
above is what is the meaning of the output of HHH. Its OK to stay
at that step until we are sure it is understood.

void DDD()
{
   HHH(DDD);
   return;
}

Unless an unlimited emulation of DDD by HHH
can reach the "return" instruction of DDD it is
construed that this instance of DDD never halts.

But that also construes that HHH is a program that DOES an unlimited
emulation of DDD, and thus isn't a decider

Not at all. never has.
HHH must predict what the behavior of an unlimited
simulation would be.

Yes, and when HHH that aborts simulates *itself* it must predict what
the behaviour of an unlimited simulation of the HHH that aborts would be.
But we know you are cheating with the Root variable, which causes that
the simulating HHH and the simulated HHH have different behaviour.

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

Op 16.aug.2024 om 17:07 schreef olcott:

On 8/16/2024 9:59 AM, joes wrote:

Am Fri, 16 Aug 2024 09:42:13 -0500 schrieb olcott:

On 8/16/2024 9:28 AM, Richard Damon wrote:

On 8/16/24 10:09 AM, olcott wrote:

On 8/16/2024 8:34 AM, Mikko wrote:

On 2024-08-16 12:02:00 +0000, olcott said:

Unless an unlimited emulation of DDD by HHH can reach the "return"
instruction of DDD it is construed that this instance of DDD never
halts.

But that also construes that HHH is a program that DOES an unlimited
emulation of DDD, and thus isn't a decider

Not at all. never has.

Yes, because DDD is defined to call its simulator. If you change the
simulator to abort, you also change the simulated HHH. Nobody cares
about HHH aborting a pure simulator.

HHH must predict what the behavior of an unlimited simulation would be.

The HHH that aborts must predict what DDD calling an aborting HHH does -

NOT AT ALL, NEVER HAS.

PREDICT WHAT THE BEHAVIOR WOULD BE
PREDICT WHAT THE BEHAVIOR WOULD BE
PREDICT WHAT THE BEHAVIOR WOULD BE
PREDICT WHAT THE BEHAVIOR WOULD BE

IF IT WAS AN UNLIMITED EMULATION
IF IT WAS AN UNLIMITED EMULATION
IF IT WAS AN UNLIMITED EMULATION
IF IT WAS AN UNLIMITED EMULATION

The correct meaning is: If the simulator was an unlimited simulation.
But you are not allowed to change input of an aborting simulator to an unlimited simulation. That is cheating. We know you do it with the Root variable.

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

Op 16.aug.2024 om 19:09 schreef olcott:

On 8/16/2024 11:41 AM, Richard Damon wrote:

On 8/16/24 12:12 PM, olcott wrote:

On 8/16/2024 11:00 AM, Richard Damon wrote:

On 8/16/24 11:45 AM, olcott wrote:

On 8/16/2024 10:39 AM, Richard Damon wrote:

On 8/16/24 11:05 AM, olcott wrote:

On 8/16/2024 9:56 AM, Richard Damon wrote:

On 8/16/24 10:42 AM, olcott wrote:

On 8/16/2024 9:28 AM, Richard Damon wrote:

On 8/16/24 10:09 AM, olcott wrote:

On 8/16/2024 8:34 AM, Mikko wrote:

On 2024-08-16 12:02:00 +0000, olcott said:

I must go one step at a time.

That's reasonable in a discussion. The one thing you were >>>>>>>>>>>> discussing
above is what is the meaning of the output of HHH. Its OK to >>>>>>>>>>>> stay
at that step until we are sure it is understood.

void DDD()
{
   HHH(DDD);
   return;
}

Unless an unlimited emulation of DDD by HHH
can reach the "return" instruction of DDD it is
construed that this instance of DDD never halts.

But that also construes that HHH is a program that DOES an >>>>>>>>>> unlimited emulation of DDD, and thus isn't a decider

Not at all. never has.
HHH must predict what the behavior of an unlimited
simulation would be.

Right, unlimited emulation of the EXACT input that HHH got, that >>>>>>>> is the DDD that calls the HHH that is the decider

PREDICT WHAT THE BEHAVIOR WOULD BE
PREDICT WHAT THE BEHAVIOR WOULD BE
PREDICT WHAT THE BEHAVIOR WOULD BE
PREDICT WHAT THE BEHAVIOR WOULD BE

IF IT WAS AN UNLIMITED EMULATION
IF IT WAS AN UNLIMITED EMULATION
IF IT WAS AN UNLIMITED EMULATION
IF IT WAS AN UNLIMITED EMULATION

So, I guess you aren't working on the Halting Problem,

Halt deciders have always been required to predict what the
behavior of their input would be.

Right, and the input to the Halt Decider HHH is the DDD that calls
the Halt Decider HHH, not the DDD that calls the unlimited emulator
HHH.

You can't get away with disagreeing with the semantics
of the x86 language.

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

Which isn't a program, so doesn't HAVE a complete behavior per the
semantics of the x86 language,

It is isomorphic to a program and to a Turing Machine.

You need to include the code of HHH at 000015d2, and since that code,
as you have provided it elsewhere DOES return to its caller when given
this input, shows that by the x86 semantics, DDD is a halting program.

I have conclusively proved that it has been obviously
doing this for three years.

THE INPUT TO HHH(DDD) CANNOT POSSIBLY REACH ITS
RETURN INSTRUCTION THUS DOES NOT HALT.

You don't understand that if it fails to reach the end, the simulation
is incorrect.
HHH cannot possibly simulate itself correctly. You probably know it,
therefore you cheat with the Root variable, to give the simulated HHH a behaviour different from the behaviour of the simulating HHH, so that
you can keep dreaming of an infinite recursion.

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

Op 16.aug.2024 om 20:04 schreef olcott:

On 8/16/2024 12:54 PM, Richard Damon wrote:

On 8/16/24 1:11 PM, olcott wrote:

On 8/16/2024 11:47 AM, joes wrote:

Am Fri, 16 Aug 2024 10:07:08 -0500 schrieb olcott:

On 8/16/2024 9:59 AM, joes wrote:

Am Fri, 16 Aug 2024 09:42:13 -0500 schrieb olcott:

On 8/16/2024 9:28 AM, Richard Damon wrote:

On 8/16/24 10:09 AM, olcott wrote:

On 8/16/2024 8:34 AM, Mikko wrote:

On 2024-08-16 12:02:00 +0000, olcott said:

Unless an unlimited emulation of DDD by HHH can reach the "return" >>>>>>>>> instruction of DDD it is construed that this instance of DDD never >>>>>>>>> halts.

But that also construes that HHH is a program that DOES an
unlimited
emulation of DDD, and thus isn't a decider

Not at all. never has.

Yes, because DDD is defined to call its simulator. If you change the >>>>>> simulator to abort, you also change the simulated HHH. Nobody cares >>>>>> about HHH aborting a pure simulator.

HHH must predict what the behavior of an unlimited simulation would >>>>>>> be.

The HHH that aborts must predict what DDD calling an aborting HHH
does

NOT AT ALL, NEVER HAS.
PREDICT WHAT THE BEHAVIOR WOULD BE
IF IT WAS AN UNLIMITED EMULATION

Yes, an unlimited simulation of an aborting HHH.

Prediction of behavior of unlimited emulation
means prediction of behavior that never aborts.

Right, but the unlimited emulation of the DDD that calls the HHH that
says non-halting will reach a final state.

I think that you are just twisting my words again.

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

The unlimited emulation of DDD by HHH never stops running.

But the aborting HHH stops running. When this aborting HHH is simulated,
the simulator must predict the behaviour the unlimited simulation of the *aborting* HHH . It is not allowed to change the input (an aborting HHH)
into an non-aborting HHH. That is cheating. That is exactly what you do
with the Root variable, which changes the behaviour of the input.

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

On 8/16/24 3:47 PM, olcott wrote:

On 8/16/2024 2:23 PM, Richard Damon wrote:

On 8/16/24 2:57 PM, olcott wrote:

On 8/16/2024 1:49 PM, Richard Damon wrote:

On 8/16/24 2:04 PM, olcott wrote:

On 8/16/2024 12:54 PM, Richard Damon wrote:

On 8/16/24 1:11 PM, olcott wrote:

On 8/16/2024 11:47 AM, joes wrote:

Am Fri, 16 Aug 2024 10:07:08 -0500 schrieb olcott:

On 8/16/2024 9:59 AM, joes wrote:

Am Fri, 16 Aug 2024 09:42:13 -0500 schrieb olcott:

On 8/16/2024 9:28 AM, Richard Damon wrote:

On 8/16/24 10:09 AM, olcott wrote:

On 8/16/2024 8:34 AM, Mikko wrote:

On 2024-08-16 12:02:00 +0000, olcott said:

Unless an unlimited emulation of DDD by HHH can reach the >>>>>>>>>>>>> "return"
instruction of DDD it is construed that this instance of >>>>>>>>>>>>> DDD never
halts.

But that also construes that HHH is a program that DOES an >>>>>>>>>>>> unlimited
emulation of DDD, and thus isn't a decider

Not at all. never has.

Yes, because DDD is defined to call its simulator. If you
change the
simulator to abort, you also change the simulated HHH. Nobody >>>>>>>>>> cares
about HHH aborting a pure simulator.

HHH must predict what the behavior of an unlimited simulation >>>>>>>>>>> would
be.

The HHH that aborts must predict what DDD calling an aborting >>>>>>>>>> HHH does

NOT AT ALL, NEVER HAS.
PREDICT WHAT THE BEHAVIOR WOULD BE
IF IT WAS AN UNLIMITED EMULATION

Yes, an unlimited simulation of an aborting HHH.

Prediction of behavior of unlimited emulation
means prediction of behavior that never aborts.

Right, but the unlimited emulation of the DDD that calls the HHH
that says non-halting will reach a final state.

I think that you are just twisting my words again.

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

The unlimited emulation of DDD by HHH never stops running.

IF you are going to change an define that *THE* HHH is just a
program that does unlimited emulation, than it fails to give the
answer that the input is non-halting.

HHH correctly predicts...
HHH correctly predicts...
HHH correctly predicts...
HHH correctly predicts...
HHH correctly predicts...

I will get the another piece of this sentence
after you fully understand this first piece.

How can HHH correctly predict something that won't happen?

How do we know there is no greatest prime?

Because we can form a proof that show it.

Something that seems to be beyond your ability to comprehend,


We CAN form a proof from a partial emulation that Infinite_Loop and Infinite_Recursion that the unlimited emultion of them will not halt, in
part because they do not depend on the emulator they are paired with
(since they are not defined to be paired with an emulator).

A Given DDD, that has been paired wtih a given HHH, can be shown to Halt
if that HHH(DDD) returns an answer, and to not halt if (and only if)
that HHH(DDD) will never return. This means we can PROVE that no HHH can correctly predict that the DDD that calls it is non-halting, becuase the
act of making that prediction renders it false.

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

On 2024-08-16 18:57:41 +0000, olcott said:

On 8/16/2024 1:49 PM, Richard Damon wrote:

On 8/16/24 2:04 PM, olcott wrote:

On 8/16/2024 12:54 PM, Richard Damon wrote:

On 8/16/24 1:11 PM, olcott wrote:

On 8/16/2024 11:47 AM, joes wrote:

Am Fri, 16 Aug 2024 10:07:08 -0500 schrieb olcott:

On 8/16/2024 9:59 AM, joes wrote:

Am Fri, 16 Aug 2024 09:42:13 -0500 schrieb olcott:

On 8/16/2024 9:28 AM, Richard Damon wrote:

On 8/16/24 10:09 AM, olcott wrote:

On 8/16/2024 8:34 AM, Mikko wrote:

On 2024-08-16 12:02:00 +0000, olcott said:

Unless an unlimited emulation of DDD by HHH can reach the "return" >>>>>>>>>>> instruction of DDD it is construed that this instance of DDD never >>>>>>>>>>> halts.

But that also construes that HHH is a program that DOES an unlimited >>>>>>>>>> emulation of DDD, and thus isn't a decider

Not at all. never has.

Yes, because DDD is defined to call its simulator. If you change the >>>>>>>> simulator to abort, you also change the simulated HHH. Nobody cares >>>>>>>> about HHH aborting a pure simulator.

HHH must predict what the behavior of an unlimited simulation would >>>>>>>>> be.

The HHH that aborts must predict what DDD calling an aborting HHH does >>>>>>> NOT AT ALL, NEVER HAS.

PREDICT WHAT THE BEHAVIOR WOULD BE
IF IT WAS AN UNLIMITED EMULATION

Yes, an unlimited simulation of an aborting HHH.

Prediction of behavior of unlimited emulation
means prediction of behavior that never aborts.

Right, but the unlimited emulation of the DDD that calls the HHH that
says non-halting will reach a final state.

I think that you are just twisting my words again.

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

The unlimited emulation of DDD by HHH never stops running.

IF you are going to change an define that *THE* HHH is just a program
that does unlimited emulation, than it fails to give the answer that
the input is non-halting.

HHH correctly predicts...
HHH correctly predicts...
HHH correctly predicts...
HHH correctly predicts...
HHH correctly predicts...

I will get the another piece of this sentence
after you fully understand this first piece.

The important part to understand is "predicts". If someone says
that HHH "predicts" means that HHH tells about something that
has not yet happened before HHH terminates. Once this pint is
understood we may discus the meaning of "correctly".

--
Mikko

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

On 2024-08-16 14:09:40 +0000, olcott said:

On 8/16/2024 8:34 AM, Mikko wrote:

On 2024-08-16 12:02:00 +0000, olcott said:

I must go one step at a time.

That's reasonable in a discussion. The one thing you were discussing
above is what is the meaning of the output of HHH. Its OK to stay
at that step until we are sure it is understood.

void DDD()
{
HHH(DDD);
return;
}

Unless an unlimited emulation of DDD by HHH
can reach the "return" instruction of DDD it is
construed that this instance of DDD never halts.

Whaatever you "construe" does not change the fact that DDD specifies
a halting computation if HHH does.

For three years now at least most reviewers insisted
on disagreeing with the semantics of the x86 language.

If you claim that HHH halts and DDD doesn't you disagree with
the semantics of both C and x86 languages.

--
Mikko

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

Am Fri, 16 Aug 2024 07:02:00 -0500 schrieb olcott:

On 8/16/2024 6:06 AM, Mikko wrote:

On 2024-08-15 12:59:30 +0000, olcott said:

On 8/15/2024 3:20 AM, Fred. Zwarts wrote:

Op 14.aug.2024 om 23:08 schreef olcott:

On 8/14/2024 3:56 PM, Mike Terry wrote:

On 14/08/2024 18:45, olcott wrote:

On 8/14/2024 11:31 AM, joes wrote:

Am Wed, 14 Aug 2024 08:42:33 -0500 schrieb olcott:

On 8/14/2024 2:30 AM, Mikko wrote:

On 2024-08-13 13:30:08 +0000, olcott said:

On 8/13/2024 6:23 AM, Richard Damon wrote:

On 8/12/24 11:45 PM, olcott wrote:

*DDD correctly emulated by HHH cannot possibly reach its* >>>>>>>>>>>>> *own "return" instruction final halt state, thus never >>>>>>>>>>>>> halts*

Which is only correct if HHH actuallly does a complete and >>>>>>>>>>>> correct emulation, or the behavior DDD (but not the emulation >>>>>>>>>>>> of DDD by HHH)
will reach that return.

A complete emulation of a non-terminating input has always >>>>>>>>>>> been a contradiction in terms.
HHH correctly predicts that a correct and unlimited emulation >>>>>>>>>>> of DDD by HHH cannot possibly reach its own "return"
instruction final halt state.

That is not a meaningful prediction because a complete and >>>>>>>>>> unlimited emulation of DDD by HHH never happens.

A complete emulation is not required to correctly predict that a >>>>>>>>> complete emulation would never halt.

What do we care about a complete simulation? HHH isn't doing one. >>>>>>>>

Please go read how Mike corrected you.

Lol, dude...  I mentioned nothing about complete/incomplete
simulations.

*You corrected Joes most persistent error*
She made sure to ignore this correction.

But while we're here - a complete simulation of input D() would
clearly halt.

A complete simulation *by HHH* remains stuck in infinite recursion
until aborted.

It is aborted, so the infinite recursion is just a dream.

All simulating termination analyzers are required to predict what the
behavior would be when the emulation is unlimited (never aborted)
otherwise they could never report on the behavior of this function:
void Infinite_Loop()
{
   HERE: goto HERE;
}

Also something that you consistently ignore is that HHH is not
reporting on its own behavior. HHH is only predicting whether or not
an unlimited emulation of DDD would reach the "return" instruction of
DDD.

Yes it is, as part of DDD (being called by it). An unlimited simulation
of DDD calling an aborting HHH would halt, see my trace.

Actually HHH does not report at all. HHH just returns one value for
some inputs and another vaule for other inputs. HHH does not tell how
those values correlate with any features of the input. It is the user's
problem to interprete the inputs. The author of the program should tell
what the inputs mean but the user should be aware that the infromation
given by the author may be incorrect. The author has not proven
anything abut the interpretation of the answers by HHH.

I must go one step at a time.
So far most people have not understood the first step.
What correct simulation is and how it is correctly measured.

In this recursion(!), changing the simulator also changes the simulated.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

On 2024-08-17 13:41:39 +0000, olcott said:

On 8/17/2024 1:42 AM, Mikko wrote:

On 2024-08-16 14:09:40 +0000, olcott said:

On 8/16/2024 8:34 AM, Mikko wrote:

On 2024-08-16 12:02:00 +0000, olcott said:

I must go one step at a time.

That's reasonable in a discussion. The one thing you were discussing
above is what is the meaning of the output of HHH. Its OK to stay
at that step until we are sure it is understood.

void DDD()
{
   HHH(DDD);
   return;
}

Unless an unlimited emulation of DDD by HHH
can reach the "return" instruction of DDD it is
construed that this instance of DDD never halts.

Whaatever you "construe" does not change the fact that DDD specifies
a halting computation if HHH does.

For three years now at least most reviewers insisted
on disagreeing with the semantics of the x86 language.

If you claim that HHH halts and DDD doesn't you disagree with
the semantics of both C and x86 languages.

Please see my new post.

Which new post? Message ID? Subject? Date and time?

--
Mikko

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