On 8/29/24 10:04 AM, olcott wrote:

On 8/29/2024 3:00 AM, Mikko wrote:

On 2024-08-28 11:46:58 +0000, olcott said:

On 8/28/2024 2:33 AM, Mikko wrote:

On 2024-08-27 13:04:26 +0000, olcott said:

On 8/27/2024 12:45 AM, joes wrote:

Am Mon, 26 Aug 2024 18:03:41 -0500 schrieb olcott:

On 8/26/2024 7:42 AM, Ben Bacarisse wrote:

Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>>> On 23/08/2024 22:07, Ben Bacarisse wrote:

We don't really know what context Sipser was given.  I got in >>>>>>>>>> touch
at the time so I do know he had enough context to know that PO's >>>>>>>>>> ideas were "wacky" and that had agreed to what he considered a >>>>>>>>>> "minor
remark". Since PO considers his words finely crafted and key >>>>>>>>>> to his
so-called work I think it's clear that Sipser did not take the >>>>>>>>>> "minor
remark" he agreed to to mean what PO takes it to mean!  My own >>>>>>>>>> take
if that he (Sipser) read it as a general remark about how to >>>>>>>>>> determine some cases, i.e. that D names an input that H can >>>>>>>>>> partially
simulate to determine it's halting or otherwise.  We all know or >>>>>>>>>> could construct some such cases.

Exactly my reading.  It makes Sipser's agreement natural,
because it
is both correct [with sensible interpretation of terms], and >>>>>>>>> moreover
describes an obvious strategy that a partial decider might use >>>>>>>>> that
can decide halting for some specific cases.  No need for Sipser >>>>>>>>> to be
deceptive or misleading here, when the truth suffices.  (In >>>>>>>>> particular
no need to employ "tricksy" vacuous truth get out clauses just >>>>>>>>> to get
PO off his back as some have suggested.)

Yes, and it fits with his thinking it a "trivial remark".

That aside, it's such an odd way to present an argument: "I
managed to
trick X into saying 'yes' to something vague".  In any reasonable >>>>>>>> collegiate exchange you'd go back and check: "So even when D is >>>>>>>> constructed from H, H can return based on what /would/ happen if >>>>>>>> H did
not stop simulating so that H(D,D) == false is correct even
though D(D)
halts?".  Just imagine what Sipser would say to that!

Is this an accurate phrasing, pete?

Deciders never compute the mapping of the computation
that they themselves are contained within.

Why not? A decider always either accepts or rejects its input.

The computation that they themselves are contained within cannot
possibly be an input.

What would prevent that if the input language permits computations?

When a TM takes its own machine description as input
this is not always that same behavior as the direct
execution of the machine. It is not the same because
it is one level of indirect reference away.

LIE.

And you have accepted that it is a lie because you have failed to point
out the step correctly emulated that differed.

*How one level of indirect reference changes the answer*
Does this sentence:
"This sentence is not true"
have a truth value? No, it is not a truth bearer.

Does this sentence:
This sentence is not true: "This sentence is not true"
have a truth value? Yes it is true.

For example, every computation can be given to an UTM. That computation
may involve a decider X that uses the same input language. What
What prevents giving X the same input as the UTM was given?

One level of indirect reference away from the
computation itself can have different behavior

But there isn't a "indirect reference" in the input, there is an actual
copy.

The direct execution of DDD() has the benefit of
HHH having already aborted its emulation of DDD.

DDD emulated by HHH does not have this same benefit.

Which doesn't change the BEHAVIOR of the input, just the ability to
compute that behavior.

The correct emulation of the input doesn't differ from the behavior of
the direct execution.

You just confuse what the decider can compute with what is reality as
you confuse truth with knowledge.

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

On 2024-08-29 14:04:05 +0000, olcott said:

On 8/29/2024 3:00 AM, Mikko wrote:

On 2024-08-28 11:46:58 +0000, olcott said:

On 8/28/2024 2:33 AM, Mikko wrote:

On 2024-08-27 13:04:26 +0000, olcott said:

On 8/27/2024 12:45 AM, joes wrote:

Am Mon, 26 Aug 2024 18:03:41 -0500 schrieb olcott:

On 8/26/2024 7:42 AM, Ben Bacarisse wrote:

Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>>> On 23/08/2024 22:07, Ben Bacarisse wrote:

We don't really know what context Sipser was given.  I got in touch >>>>>>>>>> at the time so I do know he had enough context to know that PO's >>>>>>>>>> ideas were "wacky" and that had agreed to what he considered a "minor
remark". Since PO considers his words finely crafted and key to his >>>>>>>>>> so-called work I think it's clear that Sipser did not take the "minor
remark" he agreed to to mean what PO takes it to mean!  My own take >>>>>>>>>> if that he (Sipser) read it as a general remark about how to >>>>>>>>>> determine some cases, i.e. that D names an input that H can partially
simulate to determine it's halting or otherwise.  We all know or >>>>>>>>>> could construct some such cases.

Exactly my reading.  It makes Sipser's agreement natural, because it >>>>>>>>> is both correct [with sensible interpretation of terms], and moreover >>>>>>>>> describes an obvious strategy that a partial decider might use that >>>>>>>>> can decide halting for some specific cases.  No need for Sipser to be
deceptive or misleading here, when the truth suffices.  (In particular
no need to employ "tricksy" vacuous truth get out clauses just to get >>>>>>>>> PO off his back as some have suggested.)

Yes, and it fits with his thinking it a "trivial remark".

That aside, it's such an odd way to present an argument: "I managed to >>>>>>>> trick X into saying 'yes' to something vague".  In any reasonable >>>>>>>> collegiate exchange you'd go back and check: "So even when D is >>>>>>>> constructed from H, H can return based on what /would/ happen if H did >>>>>>>> not stop simulating so that H(D,D) == false is correct even though D(D)
halts?".  Just imagine what Sipser would say to that!

Is this an accurate phrasing, pete?

Deciders never compute the mapping of the computation
that they themselves are contained within.

Why not? A decider always either accepts or rejects its input.

The computation that they themselves are contained within cannot
possibly be an input.

What would prevent that if the input language permits computations?

When a TM takes its own machine description as input
this is not always that same behavior as the direct
execution of the machine. It is not the same because
it is one level of indirect reference away.

Now you contradict what you said above. You said that deciders never
conpute the mapping of the computation they themselves are contained
within. Now you are saying that they do in a way that might not be
as expected.

--
Mikko

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

Op 31.aug.2024 om 14:50 schreef olcott:

On 8/30/2024 8:31 AM, Mikko wrote:

On 2024-08-29 14:04:05 +0000, olcott said:

On 8/29/2024 3:00 AM, Mikko wrote:

On 2024-08-28 11:46:58 +0000, olcott said:

On 8/28/2024 2:33 AM, Mikko wrote:

On 2024-08-27 13:04:26 +0000, olcott said:

On 8/27/2024 12:45 AM, joes wrote:

Am Mon, 26 Aug 2024 18:03:41 -0500 schrieb olcott:

On 8/26/2024 7:42 AM, Ben Bacarisse wrote:

Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>>>>> On 23/08/2024 22:07, Ben Bacarisse wrote:

We don't really know what context Sipser was given.  I got >>>>>>>>>>>> in touch
at the time so I do know he had enough context to know that >>>>>>>>>>>> PO's
ideas were "wacky" and that had agreed to what he considered >>>>>>>>>>>> a "minor
remark". Since PO considers his words finely crafted and key >>>>>>>>>>>> to his
so-called work I think it's clear that Sipser did not take >>>>>>>>>>>> the "minor
remark" he agreed to to mean what PO takes it to mean!  My >>>>>>>>>>>> own take
if that he (Sipser) read it as a general remark about how to >>>>>>>>>>>> determine some cases, i.e. that D names an input that H can >>>>>>>>>>>> partially
simulate to determine it's halting or otherwise.  We all >>>>>>>>>>>> know or
could construct some such cases.

Exactly my reading.  It makes Sipser's agreement natural, >>>>>>>>>>> because it
is both correct [with sensible interpretation of terms], and >>>>>>>>>>> moreover
describes an obvious strategy that a partial decider might >>>>>>>>>>> use that
can decide halting for some specific cases.  No need for >>>>>>>>>>> Sipser to be
deceptive or misleading here, when the truth suffices.  (In >>>>>>>>>>> particular
no need to employ "tricksy" vacuous truth get out clauses >>>>>>>>>>> just to get
PO off his back as some have suggested.)

Yes, and it fits with his thinking it a "trivial remark".

That aside, it's such an odd way to present an argument: "I >>>>>>>>>> managed to
trick X into saying 'yes' to something vague".  In any reasonable >>>>>>>>>> collegiate exchange you'd go back and check: "So even when D is >>>>>>>>>> constructed from H, H can return based on what /would/ happen >>>>>>>>>> if H did
not stop simulating so that H(D,D) == false is correct even >>>>>>>>>> though D(D)
halts?".  Just imagine what Sipser would say to that!

Is this an accurate phrasing, pete?

Deciders never compute the mapping of the computation
that they themselves are contained within.

Why not? A decider always either accepts or rejects its input.

The computation that they themselves are contained within cannot
possibly be an input.

What would prevent that if the input language permits computations?

When a TM takes its own machine description as input
this is not always that same behavior as the direct
execution of the machine. It is not the same because
it is one level of indirect reference away.

Now you contradict what you said above. You said that deciders never
conpute the mapping of the computation they themselves are contained
within.

Although deciders cannot possibly see their own behavior
other people can see this behavior.

Now you are saying that they do in a way that might not be
as expected.

If is a verified fact that DDD has different behavior
before it is aborted in the same way that people are
hungry before they eat.

No, the behaviour specified by the finite string does not change when a simulator decides to do the simulation only halfway. It is just an
incorrect simulation.

than the behavior of DDD after it has been aborted,
people are not hungry after they eat.

If two people are hungry and one of them eats, the other one is still
hungry and needs to eat. It is stupid to say that they are no longer
hungry because they have eaten.
Similarly the simulating HHH is not longer hungry, but the simulated HHH
still is hungry and has not yet eaten.

The direct execution of DDD includes the behavior
of the emulated DDD after it has been aborted.

And the simulator should also simulate until it sees the behaviour of
after the simulated HHH has aborted its simulator. But, of course, it
can't do that.
HHH cannot possibly simulate itself correctly up to the end.
I told you so many times. When will you finally understand it?

The emulation of DDD includes the behavior of DDD
before it has been aborted.

Which makes it an incomplete simulation, which does not tell anything
about how a correct simulation would continue. Any prediction is just a
wild guess. An incorrect guess in this case.

The behavior of infinite recursion is different
before its second recursive call has been aborted
than after this second call has been aborted.

Dreaming again of an infinite recursion? Stop dreaming. HHH is
programmed to prevent an infinite recursion. That holds for both the
simulating and the simulated HHH.
Dreams are no substitute for facts.
That the simulating HHH fails to see that the simulated HHH would also
prevent the infinite recursion, is just a programming error and not a justification for deciding that it sees an infinite recursion.
HHH cannot possibly simulate itself correctly up to the end.

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

On 8/31/24 8:50 AM, olcott wrote:

On 8/30/2024 8:31 AM, Mikko wrote:

On 2024-08-29 14:04:05 +0000, olcott said:

On 8/29/2024 3:00 AM, Mikko wrote:

On 2024-08-28 11:46:58 +0000, olcott said:

On 8/28/2024 2:33 AM, Mikko wrote:

On 2024-08-27 13:04:26 +0000, olcott said:

On 8/27/2024 12:45 AM, joes wrote:

Am Mon, 26 Aug 2024 18:03:41 -0500 schrieb olcott:

On 8/26/2024 7:42 AM, Ben Bacarisse wrote:

Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>>>>> On 23/08/2024 22:07, Ben Bacarisse wrote:

We don't really know what context Sipser was given.  I got >>>>>>>>>>>> in touch
at the time so I do know he had enough context to know that >>>>>>>>>>>> PO's
ideas were "wacky" and that had agreed to what he considered >>>>>>>>>>>> a "minor
remark". Since PO considers his words finely crafted and key >>>>>>>>>>>> to his
so-called work I think it's clear that Sipser did not take >>>>>>>>>>>> the "minor
remark" he agreed to to mean what PO takes it to mean!  My >>>>>>>>>>>> own take
if that he (Sipser) read it as a general remark about how to >>>>>>>>>>>> determine some cases, i.e. that D names an input that H can >>>>>>>>>>>> partially
simulate to determine it's halting or otherwise.  We all >>>>>>>>>>>> know or
could construct some such cases.

Exactly my reading.  It makes Sipser's agreement natural, >>>>>>>>>>> because it
is both correct [with sensible interpretation of terms], and >>>>>>>>>>> moreover
describes an obvious strategy that a partial decider might >>>>>>>>>>> use that
can decide halting for some specific cases.  No need for >>>>>>>>>>> Sipser to be
deceptive or misleading here, when the truth suffices.  (In >>>>>>>>>>> particular
no need to employ "tricksy" vacuous truth get out clauses >>>>>>>>>>> just to get
PO off his back as some have suggested.)

Yes, and it fits with his thinking it a "trivial remark".

That aside, it's such an odd way to present an argument: "I >>>>>>>>>> managed to
trick X into saying 'yes' to something vague".  In any reasonable >>>>>>>>>> collegiate exchange you'd go back and check: "So even when D is >>>>>>>>>> constructed from H, H can return based on what /would/ happen >>>>>>>>>> if H did
not stop simulating so that H(D,D) == false is correct even >>>>>>>>>> though D(D)
halts?".  Just imagine what Sipser would say to that!

Is this an accurate phrasing, pete?

Deciders never compute the mapping of the computation
that they themselves are contained within.

Why not? A decider always either accepts or rejects its input.

The computation that they themselves are contained within cannot
possibly be an input.

What would prevent that if the input language permits computations?

When a TM takes its own machine description as input
this is not always that same behavior as the direct
execution of the machine. It is not the same because
it is one level of indirect reference away.

Now you contradict what you said above. You said that deciders never
conpute the mapping of the computation they themselves are contained
within.

Although deciders cannot possibly see their own behavior
other people can see this behavior.

But, by definition, they need to answer about *ANY* machine givem to them.

Are you just admitting at the beginning that fundamentally

Now you are saying that they do in a way that might not be
as expected.

If is a verified fact that DDD has different behavior
before it is aborted in the same way that people are
hungry before they eat.

Which is just proof that you logic is based on lies and category errors.

Sorry, you are just proving you don't understand what you are talking
about and showing that you think that "Logic" (at least in the PO sense)
allows LYING about things that you don't actually know about.

than the behavior of DDD after it has been aborted,
people are not hungry after they eat.

The direct execution of DDD includes the behavior
of the emulated DDD after it has been aborted.

The emulation of DDD includes the behavior of DDD
before it has been aborted.

And thus isn't the COMPLETE behavior, and thus isn't the BEHAVIOR of the
input.

I guess you think you could be God because God is immortal, and you
haven't dies YET, so are currently "imo

The behavior of infinite recursion is different
before its second recursive call has been aborted
than after this second call has been aborted.

Only in logic that doesn't undertstad the nature of programs, and the
fact that they are deterministic.

typedef void (*ptr)();

void HHH(ptr P)
{
// might abort here or not

And so, this is NOT an actual description of a real program.
And thus we can NOT determine the behavior of DDD.

You are just sinking your reputation.

  P();
  return 1;
}

void DDD()
{
  HHH(DDD);  // second recursive call
  return;
}

int main()
{
  DDD();     // first recursive call
}

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

On 8/31/24 11:22 AM, olcott wrote:

On 8/31/2024 10:15 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:50 schreef olcott:

On 8/30/2024 8:31 AM, Mikko wrote:

On 2024-08-29 14:04:05 +0000, olcott said:

On 8/29/2024 3:00 AM, Mikko wrote:

On 2024-08-28 11:46:58 +0000, olcott said:

On 8/28/2024 2:33 AM, Mikko wrote:

On 2024-08-27 13:04:26 +0000, olcott said:

On 8/27/2024 12:45 AM, joes wrote:

Am Mon, 26 Aug 2024 18:03:41 -0500 schrieb olcott:

On 8/26/2024 7:42 AM, Ben Bacarisse wrote:

Mike Terry <news.dead.person.stones@darjeeling.plus.com> >>>>>>>>>>>> writes:

On 23/08/2024 22:07, Ben Bacarisse wrote:

We don't really know what context Sipser was given.  I got >>>>>>>>>>>>>> in touch
at the time so I do know he had enough context to know >>>>>>>>>>>>>> that PO's
ideas were "wacky" and that had agreed to what he
considered a "minor
remark". Since PO considers his words finely crafted and >>>>>>>>>>>>>> key to his
so-called work I think it's clear that Sipser did not take >>>>>>>>>>>>>> the "minor
remark" he agreed to to mean what PO takes it to mean!  My >>>>>>>>>>>>>> own take
if that he (Sipser) read it as a general remark about how to >>>>>>>>>>>>>> determine some cases, i.e. that D names an input that H >>>>>>>>>>>>>> can partially
simulate to determine it's halting or otherwise.  We all >>>>>>>>>>>>>> know or
could construct some such cases.

Exactly my reading.  It makes Sipser's agreement natural, >>>>>>>>>>>>> because it
is both correct [with sensible interpretation of terms], >>>>>>>>>>>>> and moreover
describes an obvious strategy that a partial decider might >>>>>>>>>>>>> use that
can decide halting for some specific cases.  No need for >>>>>>>>>>>>> Sipser to be
deceptive or misleading here, when the truth suffices.  (In >>>>>>>>>>>>> particular
no need to employ "tricksy" vacuous truth get out clauses >>>>>>>>>>>>> just to get
PO off his back as some have suggested.)

Yes, and it fits with his thinking it a "trivial remark". >>>>>>>>>>
That aside, it's such an odd way to present an argument: "I >>>>>>>>>>>> managed to
trick X into saying 'yes' to something vague".  In any >>>>>>>>>>>> reasonable
collegiate exchange you'd go back and check: "So even when D is >>>>>>>>>>>> constructed from H, H can return based on what /would/ >>>>>>>>>>>> happen if H did
not stop simulating so that H(D,D) == false is correct even >>>>>>>>>>>> though D(D)
halts?".  Just imagine what Sipser would say to that!

Is this an accurate phrasing, pete?

Deciders never compute the mapping of the computation
that they themselves are contained within.

Why not? A decider always either accepts or rejects its input.

The computation that they themselves are contained within cannot >>>>>>> possibly be an input.

What would prevent that if the input language permits computations? >>>>>>

When a TM takes its own machine description as input
this is not always that same behavior as the direct
execution of the machine. It is not the same because
it is one level of indirect reference away.

Now you contradict what you said above. You said that deciders never
conpute the mapping of the computation they themselves are contained
within.

Although deciders cannot possibly see their own behavior
other people can see this behavior.

Now you are saying that they do in a way that might not be
as expected.

If is a verified fact that DDD has different behavior
before it is aborted in the same way that people are
hungry before they eat.

No, the behaviour specified by the finite string does not change when
a simulator decides to do the simulation only halfway. It is just an
incorrect simulation.

than the behavior of DDD after it has been aborted,
people are not hungry after they eat.

If two people are hungry and one of them eats, the other one is still
hungry and needs to eat. It is stupid to say that they are no longer
hungry because they have eaten.
Similarly the simulating HHH is not longer hungry, but the simulated
HHH still is hungry and has not yet eaten.

The direct execution of DDD includes the behavior
of the emulated DDD after it has been aborted.

And the simulator should also simulate until it sees the behaviour of
after the simulated HHH has aborted its simulator.

THIS IS ONLY YOUR OWN FREAKING STUPIDITY.

No, it is *YOUR* (as in Peter Olcott, the man that thinks he might be
God) FREAKING STUPIDITY because he doesn't know a thing about what is
actually truth or factual.

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

Op 31.aug.2024 om 17:22 schreef olcott:

On 8/31/2024 10:15 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:50 schreef olcott:

On 8/30/2024 8:31 AM, Mikko wrote:

On 2024-08-29 14:04:05 +0000, olcott said:

On 8/29/2024 3:00 AM, Mikko wrote:

On 2024-08-28 11:46:58 +0000, olcott said:

On 8/28/2024 2:33 AM, Mikko wrote:

On 2024-08-27 13:04:26 +0000, olcott said:

On 8/27/2024 12:45 AM, joes wrote:

Am Mon, 26 Aug 2024 18:03:41 -0500 schrieb olcott:

On 8/26/2024 7:42 AM, Ben Bacarisse wrote:

Mike Terry <news.dead.person.stones@darjeeling.plus.com> >>>>>>>>>>>> writes:

On 23/08/2024 22:07, Ben Bacarisse wrote:

We don't really know what context Sipser was given.  I got >>>>>>>>>>>>>> in touch
at the time so I do know he had enough context to know >>>>>>>>>>>>>> that PO's
ideas were "wacky" and that had agreed to what he
considered a "minor
remark". Since PO considers his words finely crafted and >>>>>>>>>>>>>> key to his
so-called work I think it's clear that Sipser did not take >>>>>>>>>>>>>> the "minor
remark" he agreed to to mean what PO takes it to mean!  My >>>>>>>>>>>>>> own take
if that he (Sipser) read it as a general remark about how to >>>>>>>>>>>>>> determine some cases, i.e. that D names an input that H >>>>>>>>>>>>>> can partially
simulate to determine it's halting or otherwise.  We all >>>>>>>>>>>>>> know or
could construct some such cases.

Exactly my reading.  It makes Sipser's agreement natural, >>>>>>>>>>>>> because it
is both correct [with sensible interpretation of terms], >>>>>>>>>>>>> and moreover
describes an obvious strategy that a partial decider might >>>>>>>>>>>>> use that
can decide halting for some specific cases.  No need for >>>>>>>>>>>>> Sipser to be
deceptive or misleading here, when the truth suffices.  (In >>>>>>>>>>>>> particular
no need to employ "tricksy" vacuous truth get out clauses >>>>>>>>>>>>> just to get
PO off his back as some have suggested.)

Yes, and it fits with his thinking it a "trivial remark". >>>>>>>>>>
That aside, it's such an odd way to present an argument: "I >>>>>>>>>>>> managed to
trick X into saying 'yes' to something vague".  In any >>>>>>>>>>>> reasonable
collegiate exchange you'd go back and check: "So even when D is >>>>>>>>>>>> constructed from H, H can return based on what /would/ >>>>>>>>>>>> happen if H did
not stop simulating so that H(D,D) == false is correct even >>>>>>>>>>>> though D(D)
halts?".  Just imagine what Sipser would say to that!

Is this an accurate phrasing, pete?

Deciders never compute the mapping of the computation
that they themselves are contained within.

Why not? A decider always either accepts or rejects its input.

The computation that they themselves are contained within cannot >>>>>>> possibly be an input.

What would prevent that if the input language permits computations? >>>>>>

When a TM takes its own machine description as input
this is not always that same behavior as the direct
execution of the machine. It is not the same because
it is one level of indirect reference away.

Now you contradict what you said above. You said that deciders never
conpute the mapping of the computation they themselves are contained
within.

Although deciders cannot possibly see their own behavior
other people can see this behavior.

Now you are saying that they do in a way that might not be
as expected.

If is a verified fact that DDD has different behavior
before it is aborted in the same way that people are
hungry before they eat.

No, the behaviour specified by the finite string does not change when
a simulator decides to do the simulation only halfway. It is just an
incorrect simulation.

than the behavior of DDD after it has been aborted,
people are not hungry after they eat.

If two people are hungry and one of them eats, the other one is still
hungry and needs to eat. It is stupid to say that they are no longer
hungry because they have eaten.
Similarly the simulating HHH is not longer hungry, but the simulated
HHH still is hungry and has not yet eaten.

The direct execution of DDD includes the behavior
of the emulated DDD after it has been aborted.

And the simulator should also simulate until it sees the behaviour of
after the simulated HHH has aborted its simulator.

THIS IS ONLY YOUR OWN FREAKING STUPIDITY.

No evidence for this ad hominem attack. So, my claim still stands.

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

On 8/31/24 12:15 PM, olcott wrote:

On 8/31/2024 10:47 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 17:22 schreef olcott:

On 8/31/2024 10:15 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:50 schreef olcott:

On 8/30/2024 8:31 AM, Mikko wrote:

On 2024-08-29 14:04:05 +0000, olcott said:

On 8/29/2024 3:00 AM, Mikko wrote:

On 2024-08-28 11:46:58 +0000, olcott said:

On 8/28/2024 2:33 AM, Mikko wrote:

On 2024-08-27 13:04:26 +0000, olcott said:

On 8/27/2024 12:45 AM, joes wrote:

Am Mon, 26 Aug 2024 18:03:41 -0500 schrieb olcott:

On 8/26/2024 7:42 AM, Ben Bacarisse wrote:

Mike Terry <news.dead.person.stones@darjeeling.plus.com> >>>>>>>>>>>>>> writes:

On 23/08/2024 22:07, Ben Bacarisse wrote:

We don't really know what context Sipser was given.  I >>>>>>>>>>>>>>>> got in touch
at the time so I do know he had enough context to know >>>>>>>>>>>>>>>> that PO's
ideas were "wacky" and that had agreed to what he >>>>>>>>>>>>>>>> considered a "minor
remark". Since PO considers his words finely crafted and >>>>>>>>>>>>>>>> key to his
so-called work I think it's clear that Sipser did not >>>>>>>>>>>>>>>> take the "minor
remark" he agreed to to mean what PO takes it to mean! >>>>>>>>>>>>>>>> My own take
if that he (Sipser) read it as a general remark about >>>>>>>>>>>>>>>> how to
determine some cases, i.e. that D names an input that H >>>>>>>>>>>>>>>> can partially
simulate to determine it's halting or otherwise.  We all >>>>>>>>>>>>>>>> know or
could construct some such cases.

Exactly my reading.  It makes Sipser's agreement natural, >>>>>>>>>>>>>>> because it
is both correct [with sensible interpretation of terms], >>>>>>>>>>>>>>> and moreover
describes an obvious strategy that a partial decider >>>>>>>>>>>>>>> might use that
can decide halting for some specific cases.  No need for >>>>>>>>>>>>>>> Sipser to be
deceptive or misleading here, when the truth suffices. >>>>>>>>>>>>>>> (In particular
no need to employ "tricksy" vacuous truth get out clauses >>>>>>>>>>>>>>> just to get
PO off his back as some have suggested.)

Yes, and it fits with his thinking it a "trivial remark". >>>>>>>>>>>>
That aside, it's such an odd way to present an argument: >>>>>>>>>>>>>> "I managed to
trick X into saying 'yes' to something vague".  In any >>>>>>>>>>>>>> reasonable
collegiate exchange you'd go back and check: "So even when >>>>>>>>>>>>>> D is
constructed from H, H can return based on what /would/ >>>>>>>>>>>>>> happen if H did
not stop simulating so that H(D,D) == false is correct >>>>>>>>>>>>>> even though D(D)
halts?".  Just imagine what Sipser would say to that! >>>>>>>>>>>> Is this an accurate phrasing, pete?

Deciders never compute the mapping of the computation
that they themselves are contained within.

Why not? A decider always either accepts or rejects its input. >>>>>>>>>

The computation that they themselves are contained within cannot >>>>>>>>> possibly be an input.

What would prevent that if the input language permits computations? >>>>>>>>

When a TM takes its own machine description as input
this is not always that same behavior as the direct
execution of the machine. It is not the same because
it is one level of indirect reference away.

Now you contradict what you said above. You said that deciders never >>>>>> conpute the mapping of the computation they themselves are contained >>>>>> within.

Although deciders cannot possibly see their own behavior
other people can see this behavior.

Now you are saying that they do in a way that might not be
as expected.

If is a verified fact that DDD has different behavior
before it is aborted in the same way that people are
hungry before they eat.

No, the behaviour specified by the finite string does not change
when a simulator decides to do the simulation only halfway. It is
just an incorrect simulation.

than the behavior of DDD after it has been aborted,
people are not hungry after they eat.

If two people are hungry and one of them eats, the other one is
still hungry and needs to eat. It is stupid to say that they are no
longer hungry because they have eaten.
Similarly the simulating HHH is not longer hungry, but the simulated
HHH still is hungry and has not yet eaten.

The direct execution of DDD includes the behavior
of the emulated DDD after it has been aborted.

And the simulator should also simulate until it sees the behaviour
of after the simulated HHH has aborted its simulator.

THIS IS ONLY YOUR OWN FREAKING STUPIDITY.

No evidence for this ad hominem attack. So, my claim still stands.

People that are not as stupid can see that HHH cannot
wait for itself to abort its own simulation.

And people that are not as stupid as YOU can see that that isn't the
proper question. You are just stuck in the world of your lies, because
you have brainwashed yourself.

Your denial of the facts just proves your funny-mental condition of the
denial of reality. Since DDD Halts when HHH returns 0 to its caller,
that answer can not be correct for the DDD that calls that HHH, which
*IS* the question that HHH is being asked.

Sorry, you are just PROVING your stupidity. That isn't an ad nominem
attack, that is a proof of your mental state based on the proven facts.

You are not shown to be wrong because you are stupid, you are shown to
be stupid because you are wrong and keep on insisting that you must be
right.

An not-stupid person could realize they were wrong.

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

Op 31.aug.2024 om 18:15 schreef olcott:

On 8/31/2024 10:47 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 17:22 schreef olcott:

On 8/31/2024 10:15 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:50 schreef olcott:

On 8/30/2024 8:31 AM, Mikko wrote:

On 2024-08-29 14:04:05 +0000, olcott said:

On 8/29/2024 3:00 AM, Mikko wrote:

On 2024-08-28 11:46:58 +0000, olcott said:

On 8/28/2024 2:33 AM, Mikko wrote:

On 2024-08-27 13:04:26 +0000, olcott said:

On 8/27/2024 12:45 AM, joes wrote:

Am Mon, 26 Aug 2024 18:03:41 -0500 schrieb olcott:

On 8/26/2024 7:42 AM, Ben Bacarisse wrote:

Mike Terry <news.dead.person.stones@darjeeling.plus.com> >>>>>>>>>>>>>> writes:

On 23/08/2024 22:07, Ben Bacarisse wrote:

We don't really know what context Sipser was given.  I >>>>>>>>>>>>>>>> got in touch
at the time so I do know he had enough context to know >>>>>>>>>>>>>>>> that PO's
ideas were "wacky" and that had agreed to what he >>>>>>>>>>>>>>>> considered a "minor
remark". Since PO considers his words finely crafted and >>>>>>>>>>>>>>>> key to his
so-called work I think it's clear that Sipser did not >>>>>>>>>>>>>>>> take the "minor
remark" he agreed to to mean what PO takes it to mean! >>>>>>>>>>>>>>>> My own take
if that he (Sipser) read it as a general remark about >>>>>>>>>>>>>>>> how to
determine some cases, i.e. that D names an input that H >>>>>>>>>>>>>>>> can partially
simulate to determine it's halting or otherwise.  We all >>>>>>>>>>>>>>>> know or
could construct some such cases.

Exactly my reading.  It makes Sipser's agreement natural, >>>>>>>>>>>>>>> because it
is both correct [with sensible interpretation of terms], >>>>>>>>>>>>>>> and moreover
describes an obvious strategy that a partial decider >>>>>>>>>>>>>>> might use that
can decide halting for some specific cases.  No need for >>>>>>>>>>>>>>> Sipser to be
deceptive or misleading here, when the truth suffices. >>>>>>>>>>>>>>> (In particular
no need to employ "tricksy" vacuous truth get out clauses >>>>>>>>>>>>>>> just to get
PO off his back as some have suggested.)

Yes, and it fits with his thinking it a "trivial remark". >>>>>>>>>>>>
That aside, it's such an odd way to present an argument: >>>>>>>>>>>>>> "I managed to
trick X into saying 'yes' to something vague".  In any >>>>>>>>>>>>>> reasonable
collegiate exchange you'd go back and check: "So even when >>>>>>>>>>>>>> D is
constructed from H, H can return based on what /would/ >>>>>>>>>>>>>> happen if H did
not stop simulating so that H(D,D) == false is correct >>>>>>>>>>>>>> even though D(D)
halts?".  Just imagine what Sipser would say to that! >>>>>>>>>>>> Is this an accurate phrasing, pete?

Deciders never compute the mapping of the computation
that they themselves are contained within.

Why not? A decider always either accepts or rejects its input. >>>>>>>>>

The computation that they themselves are contained within cannot >>>>>>>>> possibly be an input.

What would prevent that if the input language permits computations? >>>>>>>>

When a TM takes its own machine description as input
this is not always that same behavior as the direct
execution of the machine. It is not the same because
it is one level of indirect reference away.

Now you contradict what you said above. You said that deciders never >>>>>> conpute the mapping of the computation they themselves are contained >>>>>> within.

Although deciders cannot possibly see their own behavior
other people can see this behavior.

Now you are saying that they do in a way that might not be
as expected.

If is a verified fact that DDD has different behavior
before it is aborted in the same way that people are
hungry before they eat.

No, the behaviour specified by the finite string does not change
when a simulator decides to do the simulation only halfway. It is
just an incorrect simulation.

than the behavior of DDD after it has been aborted,
people are not hungry after they eat.

If two people are hungry and one of them eats, the other one is
still hungry and needs to eat. It is stupid to say that they are no
longer hungry because they have eaten.
Similarly the simulating HHH is not longer hungry, but the simulated
HHH still is hungry and has not yet eaten.

The direct execution of DDD includes the behavior
of the emulated DDD after it has been aborted.

And the simulator should also simulate until it sees the behaviour
of after the simulated HHH has aborted its simulator.

THIS IS ONLY YOUR OWN FREAKING STUPIDITY.

No evidence for this ad hominem attack. So, my claim still stands.

People that are not as stupid can see that HHH cannot
wait for itself to abort its own simulation.

And people (except the stupid ones) can see that, because HHH cannot
wait for itself, this means that HHH failed to simulate itself correctly
up to the end. HHH cannot possibly simulate itself correctly up to the end.

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

On 2024-08-31 15:47:46 +0000, Fred. Zwarts said:

Op 31.aug.2024 om 17:22 schreef olcott:

On 8/31/2024 10:15 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:50 schreef olcott:

On 8/30/2024 8:31 AM, Mikko wrote:

On 2024-08-29 14:04:05 +0000, olcott said:

On 8/29/2024 3:00 AM, Mikko wrote:

On 2024-08-28 11:46:58 +0000, olcott said:

On 8/28/2024 2:33 AM, Mikko wrote:

On 2024-08-27 13:04:26 +0000, olcott said:

On 8/27/2024 12:45 AM, joes wrote:

Am Mon, 26 Aug 2024 18:03:41 -0500 schrieb olcott:

On 8/26/2024 7:42 AM, Ben Bacarisse wrote:

Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>>>>>>>> On 23/08/2024 22:07, Ben Bacarisse wrote:

We don't really know what context Sipser was given.  I got in touch
at the time so I do know he had enough context to know that PO's
ideas were "wacky" and that had agreed to what he considered a "minor
remark". Since PO considers his words finely crafted and key to his
so-called work I think it's clear that Sipser did not take the "minor
remark" he agreed to to mean what PO takes it to mean!  My own take
if that he (Sipser) read it as a general remark about how to >>>>>>>>>>>>>>> determine some cases, i.e. that D names an input that H can partially
simulate to determine it's halting or otherwise.  We all know or
could construct some such cases.

Exactly my reading.  It makes Sipser's agreement natural, because it
is both correct [with sensible interpretation of terms], and moreover
describes an obvious strategy that a partial decider might use that
can decide halting for some specific cases.  No need for Sipser to be
deceptive or misleading here, when the truth suffices.  (In particular
no need to employ "tricksy" vacuous truth get out clauses just to get
PO off his back as some have suggested.)

Yes, and it fits with his thinking it a "trivial remark". >>>>>>>>>>>
That aside, it's such an odd way to present an argument: "I managed to
trick X into saying 'yes' to something vague".  In any reasonable
collegiate exchange you'd go back and check: "So even when D is >>>>>>>>>>>>> constructed from H, H can return based on what /would/ happen if H did
not stop simulating so that H(D,D) == false is correct even though D(D)
halts?".  Just imagine what Sipser would say to that! >>>>>>>>>>> Is this an accurate phrasing, pete?

Deciders never compute the mapping of the computation
that they themselves are contained within.

Why not? A decider always either accepts or rejects its input. >>>>>>>>

The computation that they themselves are contained within cannot >>>>>>>> possibly be an input.

What would prevent that if the input language permits computations? >>>>>>>

When a TM takes its own machine description as input
this is not always that same behavior as the direct
execution of the machine. It is not the same because
it is one level of indirect reference away.

Now you contradict what you said above. You said that deciders never >>>>> conpute the mapping of the computation they themselves are contained >>>>> within.

Although deciders cannot possibly see their own behavior
other people can see this behavior.

Now you are saying that they do in a way that might not be
as expected.

If is a verified fact that DDD has different behavior
before it is aborted in the same way that people are
hungry before they eat.

No, the behaviour specified by the finite string does not change when a
simulator decides to do the simulation only halfway. It is just an
incorrect simulation.

than the behavior of DDD after it has been aborted,
people are not hungry after they eat.

If two people are hungry and one of them eats, the other one is still
hungry and needs to eat. It is stupid to say that they are no longer
hungry because they have eaten.
Similarly the simulating HHH is not longer hungry, but the simulated
HHH still is hungry and has not yet eaten.

The direct execution of DDD includes the behavior
of the emulated DDD after it has been aborted.

And the simulator should also simulate until it sees the behaviour of
after the simulated HHH has aborted its simulator.

THIS IS ONLY YOUR OWN FREAKING STUPIDITY.

No evidence for this ad hominem attack. So, my claim still stands.

You have given more than enough evidence.

--
Mikko

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

On 2024-08-31 12:50:34 +0000, olcott said:

On 8/30/2024 8:31 AM, Mikko wrote:

On 2024-08-29 14:04:05 +0000, olcott said:

On 8/29/2024 3:00 AM, Mikko wrote:

On 2024-08-28 11:46:58 +0000, olcott said:

On 8/28/2024 2:33 AM, Mikko wrote:

On 2024-08-27 13:04:26 +0000, olcott said:

On 8/27/2024 12:45 AM, joes wrote:

Am Mon, 26 Aug 2024 18:03:41 -0500 schrieb olcott:

On 8/26/2024 7:42 AM, Ben Bacarisse wrote:

Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>>>>> On 23/08/2024 22:07, Ben Bacarisse wrote:

We don't really know what context Sipser was given.  I got in touch
at the time so I do know he had enough context to know that PO's >>>>>>>>>>>> ideas were "wacky" and that had agreed to what he considered a "minor
remark". Since PO considers his words finely crafted and key to his
so-called work I think it's clear that Sipser did not take the "minor
remark" he agreed to to mean what PO takes it to mean!  My own take
if that he (Sipser) read it as a general remark about how to >>>>>>>>>>>> determine some cases, i.e. that D names an input that H can partially
simulate to determine it's halting or otherwise.  We all know or >>>>>>>>>>>> could construct some such cases.

Exactly my reading.  It makes Sipser's agreement natural, because it
is both correct [with sensible interpretation of terms], and moreover
describes an obvious strategy that a partial decider might use that >>>>>>>>>>> can decide halting for some specific cases.  No need for Sipser to be
deceptive or misleading here, when the truth suffices.  (In particular
no need to employ "tricksy" vacuous truth get out clauses just to get
PO off his back as some have suggested.)

Yes, and it fits with his thinking it a "trivial remark".

That aside, it's such an odd way to present an argument: "I managed to
trick X into saying 'yes' to something vague".  In any reasonable >>>>>>>>>> collegiate exchange you'd go back and check: "So even when D is >>>>>>>>>> constructed from H, H can return based on what /would/ happen if H did
not stop simulating so that H(D,D) == false is correct even though D(D)
halts?".  Just imagine what Sipser would say to that!

Is this an accurate phrasing, pete?

Deciders never compute the mapping of the computation
that they themselves are contained within.

Why not? A decider always either accepts or rejects its input.

The computation that they themselves are contained within cannot
possibly be an input.

What would prevent that if the input language permits computations?

When a TM takes its own machine description as input
this is not always that same behavior as the direct
execution of the machine. It is not the same because
it is one level of indirect reference away.

Now you contradict what you said above. You said that deciders never
conpute the mapping of the computation they themselves are contained
within.

Although deciders cannot possibly see their own behavior
other people can see this behavior.

The designer of the decider knows the intended behavour of the decider
and may design the decider to contain and use that knowledge.

Now you are saying that they do in a way that might not be
as expected.

If is a verified fact that DDD has different behavior
before it is aborted in the same way that people are
hungry before they eat.

Different from what?

The behaviour of DDD before the point where the simulation is aborted
is a part of the behaviour of DDD. If the simulator simulates aoother
behaviour then the simulator does not simulate correctly.

than the behavior of DDD after it has been aborted,
people are not hungry after they eat.

That is not a sentence. Looks like an editing error.

The direct execution of DDD includes the behavior
of the emulated DDD after it has been aborted.

Both the directly executed DDD and the emulated DDD are DDD and
therefore the same, and its behaviour is the behaviour of DDD
regradless how you call it.

The emulation of DDD includes the behavior of DDD
before it has been aborted.

Which, if the emulation is correct, is a part of the behaviour of
DDD.

The behavior of infinite recursion is different
before its second recursive call has been aborted
than after this second call has been aborted.

A finitely recursive simulation is neither infinite nor recursion.

--
Mikko

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

On 9/2/24 9:05 AM, olcott wrote:

On 9/1/2024 6:41 AM, Mikko wrote:

On 2024-08-31 15:47:46 +0000, Fred. Zwarts said:

Op 31.aug.2024 om 17:22 schreef olcott:

On 8/31/2024 10:15 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:50 schreef olcott:

On 8/30/2024 8:31 AM, Mikko wrote:

On 2024-08-29 14:04:05 +0000, olcott said:

On 8/29/2024 3:00 AM, Mikko wrote:

On 2024-08-28 11:46:58 +0000, olcott said:

On 8/28/2024 2:33 AM, Mikko wrote:

On 2024-08-27 13:04:26 +0000, olcott said:

On 8/27/2024 12:45 AM, joes wrote:

Am Mon, 26 Aug 2024 18:03:41 -0500 schrieb olcott:

On 8/26/2024 7:42 AM, Ben Bacarisse wrote:

Mike Terry <news.dead.person.stones@darjeeling.plus.com> >>>>>>>>>>>>>>> writes:

On 23/08/2024 22:07, Ben Bacarisse wrote:

We don't really know what context Sipser was given.  I >>>>>>>>>>>>>>>>> got in touch
at the time so I do know he had enough context to know >>>>>>>>>>>>>>>>> that PO's
ideas were "wacky" and that had agreed to what he >>>>>>>>>>>>>>>>> considered a "minor
remark". Since PO considers his words finely crafted >>>>>>>>>>>>>>>>> and key to his
so-called work I think it's clear that Sipser did not >>>>>>>>>>>>>>>>> take the "minor
remark" he agreed to to mean what PO takes it to mean! >>>>>>>>>>>>>>>>> My own take
if that he (Sipser) read it as a general remark about >>>>>>>>>>>>>>>>> how to
determine some cases, i.e. that D names an input that H >>>>>>>>>>>>>>>>> can partially
simulate to determine it's halting or otherwise.  We >>>>>>>>>>>>>>>>> all know or
could construct some such cases.

Exactly my reading.  It makes Sipser's agreement >>>>>>>>>>>>>>>> natural, because it
is both correct [with sensible interpretation of terms], >>>>>>>>>>>>>>>> and moreover
describes an obvious strategy that a partial decider >>>>>>>>>>>>>>>> might use that
can decide halting for some specific cases.  No need for >>>>>>>>>>>>>>>> Sipser to be
deceptive or misleading here, when the truth suffices. >>>>>>>>>>>>>>>> (In particular
no need to employ "tricksy" vacuous truth get out >>>>>>>>>>>>>>>> clauses just to get
PO off his back as some have suggested.)

Yes, and it fits with his thinking it a "trivial remark". >>>>>>>>>>>>>
That aside, it's such an odd way to present an argument: >>>>>>>>>>>>>>> "I managed to
trick X into saying 'yes' to something vague".  In any >>>>>>>>>>>>>>> reasonable
collegiate exchange you'd go back and check: "So even >>>>>>>>>>>>>>> when D is
constructed from H, H can return based on what /would/ >>>>>>>>>>>>>>> happen if H did
not stop simulating so that H(D,D) == false is correct >>>>>>>>>>>>>>> even though D(D)
halts?".  Just imagine what Sipser would say to that! >>>>>>>>>>>>> Is this an accurate phrasing, pete?

Deciders never compute the mapping of the computation
that they themselves are contained within.

Why not? A decider always either accepts or rejects its input. >>>>>>>>>>

The computation that they themselves are contained within cannot >>>>>>>>>> possibly be an input.

What would prevent that if the input language permits
computations?

When a TM takes its own machine description as input
this is not always that same behavior as the direct
execution of the machine. It is not the same because
it is one level of indirect reference away.

Now you contradict what you said above. You said that deciders never >>>>>>> conpute the mapping of the computation they themselves are contained >>>>>>> within.

Although deciders cannot possibly see their own behavior
other people can see this behavior.

Now you are saying that they do in a way that might not be
as expected.

If is a verified fact that DDD has different behavior
before it is aborted in the same way that people are
hungry before they eat.

No, the behaviour specified by the finite string does not change
when a simulator decides to do the simulation only halfway. It is
just an incorrect simulation.

than the behavior of DDD after it has been aborted,
people are not hungry after they eat.

If two people are hungry and one of them eats, the other one is
still hungry and needs to eat. It is stupid to say that they are no
longer hungry because they have eaten.
Similarly the simulating HHH is not longer hungry, but the
simulated HHH still is hungry and has not yet eaten.

The direct execution of DDD includes the behavior
of the emulated DDD after it has been aborted.

And the simulator should also simulate until it sees the behaviour
of after the simulated HHH has aborted its simulator.

THIS IS ONLY YOUR OWN FREAKING STUPIDITY.

No evidence for this ad hominem attack. So, my claim still stands.

You have given more than enough evidence.

When I correct a false assumption many times and the
person insists on keeping the false assumption then
they are stupid or dishonest.

You need to SHOW how it is a false assumption,

Halting is reaching a final halt state thus the
fact that HHH halts has not one damn thing to do
with whether DDD halts or not.

But of course it does, sincd if the HHH that DDD calls halts, so will DDD.

Fred is either too stupid or too dishonest to get this.

No, YOU are too stupid AND too dishonest to understand that,

Your problem is you fundamentally disagree with how logic works, and how programs are defined.

Two instances of the exact same program given the exact same input, by
the definitions of the system, MUST give the same results.

Thus if HHH(DDD) returns 0 to one thing, it does to everything that
calls it, or it doesn't follow the rules of the system. (which
admittedly your HHH does follow, so you were disqualified from the start).

It seems your logic is just based on LYING, but since that is the
language of your adopted father, that makes sense.

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

Op 02.sep.2024 om 15:42 schreef olcott:

On 9/1/2024 5:48 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 18:15 schreef olcott:

On 8/31/2024 10:47 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 17:22 schreef olcott:

On 8/31/2024 10:15 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:50 schreef olcott:

On 8/30/2024 8:31 AM, Mikko wrote:

On 2024-08-29 14:04:05 +0000, olcott said:

On 8/29/2024 3:00 AM, Mikko wrote:

On 2024-08-28 11:46:58 +0000, olcott said:

On 8/28/2024 2:33 AM, Mikko wrote:

On 2024-08-27 13:04:26 +0000, olcott said:

On 8/27/2024 12:45 AM, joes wrote:

Am Mon, 26 Aug 2024 18:03:41 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 8/26/2024 7:42 AM, Ben Bacarisse wrote:

Mike Terry <news.dead.person.stones@darjeeling.plus.com> >>>>>>>>>>>>>>>> writes:

On 23/08/2024 22:07, Ben Bacarisse wrote:

We don't really know what context Sipser was given.  I >>>>>>>>>>>>>>>>>> got in touch
at the time so I do know he had enough context to know >>>>>>>>>>>>>>>>>> that PO's
ideas were "wacky" and that had agreed to what he >>>>>>>>>>>>>>>>>> considered a "minor
remark". Since PO considers his words finely crafted >>>>>>>>>>>>>>>>>> and key to his
so-called work I think it's clear that Sipser did not >>>>>>>>>>>>>>>>>> take the "minor
remark" he agreed to to mean what PO takes it to mean! >>>>>>>>>>>>>>>>>> My own take
if that he (Sipser) read it as a general remark about >>>>>>>>>>>>>>>>>> how to
determine some cases, i.e. that D names an input that >>>>>>>>>>>>>>>>>> H can partially
simulate to determine it's halting or otherwise.  We >>>>>>>>>>>>>>>>>> all know or
could construct some such cases.

Exactly my reading.  It makes Sipser's agreement >>>>>>>>>>>>>>>>> natural, because it
is both correct [with sensible interpretation of >>>>>>>>>>>>>>>>> terms], and moreover
describes an obvious strategy that a partial decider >>>>>>>>>>>>>>>>> might use that
can decide halting for some specific cases.  No need >>>>>>>>>>>>>>>>> for Sipser to be
deceptive or misleading here, when the truth suffices. >>>>>>>>>>>>>>>>> (In particular
no need to employ "tricksy" vacuous truth get out >>>>>>>>>>>>>>>>> clauses just to get
PO off his back as some have suggested.)

Yes, and it fits with his thinking it a "trivial remark". >>>>>>>>>>>>>>
That aside, it's such an odd way to present an argument: >>>>>>>>>>>>>>>> "I managed to
trick X into saying 'yes' to something vague".  In any >>>>>>>>>>>>>>>> reasonable
collegiate exchange you'd go back and check: "So even >>>>>>>>>>>>>>>> when D is
constructed from H, H can return based on what /would/ >>>>>>>>>>>>>>>> happen if H did
not stop simulating so that H(D,D) == false is correct >>>>>>>>>>>>>>>> even though D(D)
halts?".  Just imagine what Sipser would say to that! >>>>>>>>>>>>>> Is this an accurate phrasing, pete?

Deciders never compute the mapping of the computation >>>>>>>>>>>>> that they themselves are contained within.

Why not? A decider always either accepts or rejects its input. >>>>>>>>>>>

The computation that they themselves are contained within cannot >>>>>>>>>>> possibly be an input.

What would prevent that if the input language permits
computations?

When a TM takes its own machine description as input
this is not always that same behavior as the direct
execution of the machine. It is not the same because
it is one level of indirect reference away.

Now you contradict what you said above. You said that deciders >>>>>>>> never
conpute the mapping of the computation they themselves are
contained
within.

Although deciders cannot possibly see their own behavior
other people can see this behavior.

Now you are saying that they do in a way that might not be
as expected.

If is a verified fact that DDD has different behavior
before it is aborted in the same way that people are
hungry before they eat.

No, the behaviour specified by the finite string does not change
when a simulator decides to do the simulation only halfway. It is
just an incorrect simulation.

than the behavior of DDD after it has been aborted,
people are not hungry after they eat.

If two people are hungry and one of them eats, the other one is
still hungry and needs to eat. It is stupid to say that they are
no longer hungry because they have eaten.
Similarly the simulating HHH is not longer hungry, but the
simulated HHH still is hungry and has not yet eaten.

The direct execution of DDD includes the behavior
of the emulated DDD after it has been aborted.

And the simulator should also simulate until it sees the behaviour >>>>>> of after the simulated HHH has aborted its simulator.

THIS IS ONLY YOUR OWN FREAKING STUPIDITY.

No evidence for this ad hominem attack. So, my claim still stands.

People that are not as stupid can see that HHH cannot
wait for itself to abort its own simulation.

And people (except the stupid ones) can see that, because HHH cannot
wait for itself,

Because this would require it to wait forever,
thus HHH knows that to meet its own requirement
to halt it must abort its simulation.

this means that HHH failed to simulate itself correctly

You are either very stupid or a damned liar about this.
As long as HHH emulates its input according to the semantics
of the x86 language HHH is correctly emulating this input
even if this correct emulation causes the computer to catch
on fire.

AS I HAVE TOLD YOU FAR TOO MANY TIMES
CORRECT EMULATION IS ENTIRELY DETERMINED
BY THE SEMANTICS OF THE X86 LANGUAGE.

Yes, but I don't understand why HHH, programmed by Olcott himself
violates the semantics of the x86 language, by skipping the last few instructions of the halting program?

When DDD calls HHH(DDD) then HHH must emulate
itself emulating DDD. If this causes the emulated
HHH to never return

Which is not the case, because the HHH to be simulated is coded to see a 'special condition' after a few recursions, after which it will abort
and halt, after which DDD will halt, too.
Olcott is again still dreaming of the non-halting HHH, even though he
himself has added the abort code.
Somehow he things that this abort code does not change the program's
behaviour.

THEN THIS EMULATION IS
STIPULATED TO BE CORRECT BY THE ONLY MEASURE
OF CORRECT EMULATION, the semantics of the x86
language.

But since the simulated halts, it violates the semantics of the x86
language to skip these last few instructions.

up to the end. HHH cannot possibly simulate itself correctly up to the
end.

HHH cannot possibly correctly simulate itself to the end because
the x86 code of DDD and HHH specify that HHH cannot simulate
itself to the end. If HHH did simulate itself to the end then
HHH WOULD BE WRONG.

HHH cannot possibly simulate itself correctly up to the end.
Yes, but aborting does not fix the problem. It is still wrong, because
it now aborts an aborting and halting program, skipping the last few instructions.

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

Op 02.sep.2024 om 15:05 schreef olcott:

On 9/1/2024 6:41 AM, Mikko wrote:

On 2024-08-31 15:47:46 +0000, Fred. Zwarts said:

Op 31.aug.2024 om 17:22 schreef olcott:

On 8/31/2024 10:15 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:50 schreef olcott:

On 8/30/2024 8:31 AM, Mikko wrote:

On 2024-08-29 14:04:05 +0000, olcott said:

On 8/29/2024 3:00 AM, Mikko wrote:

On 2024-08-28 11:46:58 +0000, olcott said:

On 8/28/2024 2:33 AM, Mikko wrote:

On 2024-08-27 13:04:26 +0000, olcott said:

On 8/27/2024 12:45 AM, joes wrote:

Am Mon, 26 Aug 2024 18:03:41 -0500 schrieb olcott:

On 8/26/2024 7:42 AM, Ben Bacarisse wrote:

Mike Terry <news.dead.person.stones@darjeeling.plus.com> >>>>>>>>>>>>>>> writes:

On 23/08/2024 22:07, Ben Bacarisse wrote:

We don't really know what context Sipser was given.  I >>>>>>>>>>>>>>>>> got in touch
at the time so I do know he had enough context to know >>>>>>>>>>>>>>>>> that PO's
ideas were "wacky" and that had agreed to what he >>>>>>>>>>>>>>>>> considered a "minor
remark". Since PO considers his words finely crafted >>>>>>>>>>>>>>>>> and key to his
so-called work I think it's clear that Sipser did not >>>>>>>>>>>>>>>>> take the "minor
remark" he agreed to to mean what PO takes it to mean! >>>>>>>>>>>>>>>>> My own take
if that he (Sipser) read it as a general remark about >>>>>>>>>>>>>>>>> how to
determine some cases, i.e. that D names an input that H >>>>>>>>>>>>>>>>> can partially
simulate to determine it's halting or otherwise.  We >>>>>>>>>>>>>>>>> all know or
could construct some such cases.

Exactly my reading.  It makes Sipser's agreement >>>>>>>>>>>>>>>> natural, because it
is both correct [with sensible interpretation of terms], >>>>>>>>>>>>>>>> and moreover
describes an obvious strategy that a partial decider >>>>>>>>>>>>>>>> might use that
can decide halting for some specific cases.  No need for >>>>>>>>>>>>>>>> Sipser to be
deceptive or misleading here, when the truth suffices. >>>>>>>>>>>>>>>> (In particular
no need to employ "tricksy" vacuous truth get out >>>>>>>>>>>>>>>> clauses just to get
PO off his back as some have suggested.)

Yes, and it fits with his thinking it a "trivial remark". >>>>>>>>>>>>>
That aside, it's such an odd way to present an argument: >>>>>>>>>>>>>>> "I managed to
trick X into saying 'yes' to something vague".  In any >>>>>>>>>>>>>>> reasonable
collegiate exchange you'd go back and check: "So even >>>>>>>>>>>>>>> when D is
constructed from H, H can return based on what /would/ >>>>>>>>>>>>>>> happen if H did
not stop simulating so that H(D,D) == false is correct >>>>>>>>>>>>>>> even though D(D)
halts?".  Just imagine what Sipser would say to that! >>>>>>>>>>>>> Is this an accurate phrasing, pete?

Deciders never compute the mapping of the computation
that they themselves are contained within.

Why not? A decider always either accepts or rejects its input. >>>>>>>>>>

The computation that they themselves are contained within cannot >>>>>>>>>> possibly be an input.

What would prevent that if the input language permits
computations?

When a TM takes its own machine description as input
this is not always that same behavior as the direct
execution of the machine. It is not the same because
it is one level of indirect reference away.

Now you contradict what you said above. You said that deciders never >>>>>>> conpute the mapping of the computation they themselves are contained >>>>>>> within.

Although deciders cannot possibly see their own behavior
other people can see this behavior.

Now you are saying that they do in a way that might not be
as expected.

If is a verified fact that DDD has different behavior
before it is aborted in the same way that people are
hungry before they eat.

No, the behaviour specified by the finite string does not change
when a simulator decides to do the simulation only halfway. It is
just an incorrect simulation.

than the behavior of DDD after it has been aborted,
people are not hungry after they eat.

If two people are hungry and one of them eats, the other one is
still hungry and needs to eat. It is stupid to say that they are no
longer hungry because they have eaten.
Similarly the simulating HHH is not longer hungry, but the
simulated HHH still is hungry and has not yet eaten.

The direct execution of DDD includes the behavior
of the emulated DDD after it has been aborted.

And the simulator should also simulate until it sees the behaviour
of after the simulated HHH has aborted its simulator.

THIS IS ONLY YOUR OWN FREAKING STUPIDITY.

No evidence for this ad hominem attack. So, my claim still stands.

You have given more than enough evidence.

When I correct a false assumption many times and the
person insists on keeping the false assumption then
they are stupid or dishonest.

Halting is reaching a final halt state thus the
fact that HHH halts has not one damn thing to do
with whether DDD halts or not.

Fred is either too stupid or too dishonest to get this.

Great words again without evidence.
Preventing the program to halt, by stopping the simulation just before
it would halt, does not prove a non-halting behaviour.
Olcott seems to be blind for such simple logic.

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

Am Mon, 02 Sep 2024 08:42:56 -0500 schrieb olcott:

On 9/1/2024 5:48 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 18:15 schreef olcott:

On 8/31/2024 10:47 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 17:22 schreef olcott:

On 8/31/2024 10:15 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:50 schreef olcott:

On 8/30/2024 8:31 AM, Mikko wrote:

On 2024-08-29 14:04:05 +0000, olcott said:

On 8/29/2024 3:00 AM, Mikko wrote:

On 2024-08-28 11:46:58 +0000, olcott said:

On 8/28/2024 2:33 AM, Mikko wrote:

On 2024-08-27 13:04:26 +0000, olcott said:

On 8/27/2024 12:45 AM, joes wrote:

Am Mon, 26 Aug 2024 18:03:41 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 8/26/2024 7:42 AM, Ben Bacarisse wrote:

Mike Terry <news.dead.person.stones@darjeeling.plus.com> >>>>>>>>>>>>>>>> writes:

On 23/08/2024 22:07, Ben Bacarisse wrote:

We don't really know what context Sipser was given.  I >>>>>>>>>>>>>>>>>> got in touch at the time so I do know he had enough >>>>>>>>>>>>>>>>>> context to know that PO's ideas were "wacky" and that >>>>>>>>>>>>>>>>>> had agreed to what he considered a "minor remark". >>>>>>>>>>>>>>>>>> Since PO considers his words finely crafted and key to >>>>>>>>>>>>>>>>>> his so-called work I think it's clear that Sipser did >>>>>>>>>>>>>>>>>> not take the "minor remark" he agreed to to mean what >>>>>>>>>>>>>>>>>> PO takes it to mean! My own take if that he (Sipser) >>>>>>>>>>>>>>>>>> read it as a general remark about how to determine some >>>>>>>>>>>>>>>>>> cases, i.e. that D names an input that H can partially >>>>>>>>>>>>>>>>>> simulate to determine it's halting or otherwise.  We >>>>>>>>>>>>>>>>>> all know or could construct some such cases. >>>>>>>>>>>>>>>>> Exactly my reading.  It makes Sipser's agreement >>>>>>>>>>>>>>>>> natural, because it is both correct [with sensible >>>>>>>>>>>>>>>>> interpretation of terms], and moreover describes an >>>>>>>>>>>>>>>>> obvious strategy that a partial decider might use that >>>>>>>>>>>>>>>>> can decide halting for some specific cases.  No need for >>>>>>>>>>>>>>>>> Sipser to be deceptive or misleading here, when the >>>>>>>>>>>>>>>>> truth suffices. (In particular no need to employ >>>>>>>>>>>>>>>>> "tricksy" vacuous truth get out clauses just to get PO >>>>>>>>>>>>>>>>> off his back as some have suggested.)

Yes, and it fits with his thinking it a "trivial remark". >>>>>>>>>>>>>>
That aside, it's such an odd way to present an argument: >>>>>>>>>>>>>>>> "I managed to trick X into saying 'yes' to something >>>>>>>>>>>>>>>> vague".  In any reasonable collegiate exchange you'd go >>>>>>>>>>>>>>>> back and check: "So even when D is constructed from H, H >>>>>>>>>>>>>>>> can return based on what /would/ happen if H did not stop >>>>>>>>>>>>>>>> simulating so that H(D,D) == false is correct even though >>>>>>>>>>>>>>>> D(D)
halts?".  Just imagine what Sipser would say to that! >>>>>>>>>>>>>> Is this an accurate phrasing, pete?

Deciders never compute the mapping of the computation that >>>>>>>>>>>>> they themselves are contained within.

Why not? A decider always either accepts or rejects its >>>>>>>>>>>> input.

The computation that they themselves are contained within >>>>>>>>>>> cannot possibly be an input.

What would prevent that if the input language permits
computations?

When a TM takes its own machine description as input this is not >>>>>>>>> always that same behavior as the direct execution of the
machine. It is not the same because it is one level of indirect >>>>>>>>> reference away.

Now you contradict what you said above. You said that deciders >>>>>>>> never conpute the mapping of the computation they themselves are >>>>>>>> contained within.

Although deciders cannot possibly see their own behavior other
people can see this behavior.

Now you are saying that they do in a way that might not be as
expected.

If is a verified fact that DDD has different behavior before it is >>>>>>> aborted in the same way that people are hungry before they eat.

No, the behaviour specified by the finite string does not change
when a simulator decides to do the simulation only halfway. It is
just an incorrect simulation.

than the behavior of DDD after it has been aborted, people are not >>>>>>> hungry after they eat.

If two people are hungry and one of them eats, the other one is
still hungry and needs to eat. It is stupid to say that they are no >>>>>> longer hungry because they have eaten.
Similarly the simulating HHH is not longer hungry, but the
simulated HHH still is hungry and has not yet eaten.

The direct execution of DDD includes the behavior of the emulated >>>>>>> DDD after it has been aborted.

And the simulator should also simulate until it sees the behaviour >>>>>> of after the simulated HHH has aborted its simulator.

People that are not as stupid can see that HHH cannot wait for itself
to abort its own simulation.

And people (except the stupid ones) can see that, because HHH cannot
wait for itself,

Because this would require it to wait forever,
thus HHH knows that to meet its own requirement to halt it must abort
its simulation.

And because HHH is simulating itself, the simulated HHH also aborts.

this means that HHH failed to simulate itself correctly

As long as HHH emulates its input according to the semantics of the x86 language HHH is correctly emulating this input even if this correct
emulation causes the computer to catch on fire.
AS I HAVE TOLD YOU FAR TOO MANY TIMES CORRECT EMULATION IS ENTIRELY DETERMINED BY THE SEMANTICS OF THE X86 LANGUAGE.
When DDD calls HHH(DDD) then HHH must emulate itself emulating DDD. If
this causes the emulated HHH to never return THEN THIS EMULATION IS STIPULATED TO BE CORRECT BY THE ONLY MEASURE OF CORRECT EMULATION, the semantics of the x86 language.

Useless stipulation.

up to the end. HHH cannot possibly simulate itself correctly up to the
end.

HHH cannot possibly correctly simulate itself to the end because the x86
code of DDD and HHH specify that HHH cannot simulate itself to the end.
If HHH did simulate itself to the end then HHH WOULD BE WRONG.

No simulator can simulate itself.

--
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 9/4/24 8:37 AM, olcott wrote:

On 9/4/2024 3:19 AM, joes wrote:

Am Mon, 02 Sep 2024 08:42:56 -0500 schrieb olcott:

On 9/1/2024 5:48 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 18:15 schreef olcott:

On 8/31/2024 10:47 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 17:22 schreef olcott:

On 8/31/2024 10:15 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:50 schreef olcott:

On 8/30/2024 8:31 AM, Mikko wrote:

On 2024-08-29 14:04:05 +0000, olcott said:

On 8/29/2024 3:00 AM, Mikko wrote:

On 2024-08-28 11:46:58 +0000, olcott said:

On 8/28/2024 2:33 AM, Mikko wrote:

On 2024-08-27 13:04:26 +0000, olcott said:

On 8/27/2024 12:45 AM, joes wrote:

Am Mon, 26 Aug 2024 18:03:41 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 8/26/2024 7:42 AM, Ben Bacarisse wrote:

Mike Terry <news.dead.person.stones@darjeeling.plus.com> >>>>>>>>>>>>>>>>>> writes:

On 23/08/2024 22:07, Ben Bacarisse wrote:

We don't really know what context Sipser was given.  I >>>>>>>>>>>>>>>>>>>> got in touch at the time so I do know he had enough >>>>>>>>>>>>>>>>>>>> context to know that PO's ideas were "wacky" and that >>>>>>>>>>>>>>>>>>>> had agreed to what he considered a "minor remark". >>>>>>>>>>>>>>>>>>>> Since PO considers his words finely crafted and key to >>>>>>>>>>>>>>>>>>>> his so-called work I think it's clear that Sipser did >>>>>>>>>>>>>>>>>>>> not take the "minor remark" he agreed to to mean what >>>>>>>>>>>>>>>>>>>> PO takes it to mean! My own take if that he (Sipser) >>>>>>>>>>>>>>>>>>>> read it as a general remark about how to determine some >>>>>>>>>>>>>>>>>>>> cases, i.e. that D names an input that H can partially >>>>>>>>>>>>>>>>>>>> simulate to determine it's halting or otherwise.  We >>>>>>>>>>>>>>>>>>>> all know or could construct some such cases. >>>>>>>>>>>>>>>>>>> Exactly my reading.  It makes Sipser's agreement >>>>>>>>>>>>>>>>>>> natural, because it is both correct [with sensible >>>>>>>>>>>>>>>>>>> interpretation of terms], and moreover describes an >>>>>>>>>>>>>>>>>>> obvious strategy that a partial decider might use that >>>>>>>>>>>>>>>>>>> can decide halting for some specific cases.  No need for >>>>>>>>>>>>>>>>>>> Sipser to be deceptive or misleading here, when the >>>>>>>>>>>>>>>>>>> truth suffices. (In particular no need to employ >>>>>>>>>>>>>>>>>>> "tricksy" vacuous truth get out clauses just to get PO >>>>>>>>>>>>>>>>>>> off his back as some have suggested.)

Yes, and it fits with his thinking it a "trivial remark". >>>>>>>>>>>>>>>>
That aside, it's such an odd way to present an argument: >>>>>>>>>>>>>>>>>> "I managed to trick X into saying 'yes' to something >>>>>>>>>>>>>>>>>> vague".  In any reasonable collegiate exchange you'd go >>>>>>>>>>>>>>>>>> back and check: "So even when D is constructed from H, H >>>>>>>>>>>>>>>>>> can return based on what /would/ happen if H did not stop >>>>>>>>>>>>>>>>>> simulating so that H(D,D) == false is correct even though >>>>>>>>>>>>>>>>>> D(D)
halts?".  Just imagine what Sipser would say to that! >>>>>>>>>>>>>>>> Is this an accurate phrasing, pete?

Deciders never compute the mapping of the computation that >>>>>>>>>>>>>>> they themselves are contained within.

Why not? A decider always either accepts or rejects its >>>>>>>>>>>>>> input.

The computation that they themselves are contained within >>>>>>>>>>>>> cannot possibly be an input.

What would prevent that if the input language permits
computations?

When a TM takes its own machine description as input this is not >>>>>>>>>>> always that same behavior as the direct execution of the >>>>>>>>>>> machine. It is not the same because it is one level of indirect >>>>>>>>>>> reference away.

Now you contradict what you said above. You said that deciders >>>>>>>>>> never conpute the mapping of the computation they themselves are >>>>>>>>>> contained within.

Although deciders cannot possibly see their own behavior other >>>>>>>>> people can see this behavior.

Now you are saying that they do in a way that might not be as >>>>>>>>>> expected.

If is a verified fact that DDD has different behavior before it is >>>>>>>>> aborted in the same way that people are hungry before they eat. >>>>>>>> No, the behaviour specified by the finite string does not change >>>>>>>> when a simulator decides to do the simulation only halfway. It is >>>>>>>> just an incorrect simulation.

than the behavior of DDD after it has been aborted, people are not >>>>>>>>> hungry after they eat.

If two people are hungry and one of them eats, the other one is >>>>>>>> still hungry and needs to eat. It is stupid to say that they are no >>>>>>>> longer hungry because they have eaten.
Similarly the simulating HHH is not longer hungry, but the
simulated HHH still is hungry and has not yet eaten.

The direct execution of DDD includes the behavior of the emulated >>>>>>>>> DDD after it has been aborted.

And the simulator should also simulate until it sees the behaviour >>>>>>>> of after the simulated HHH has aborted its simulator.

People that are not as stupid can see that HHH cannot wait for itself >>>>> to abort its own simulation.

And people (except the stupid ones) can see that, because HHH cannot
wait for itself,

Because this would require it to wait forever,
thus HHH knows that to meet its own requirement to halt it must abort
its simulation.

And because HHH is simulating itself, the simulated HHH also aborts.

It can not possibly do this. The outermost directly executed
HHH always sees the abort criteria before the next inner
HHH sees it.

But if it must to get the correct answer, it just fails to give the
correct answer.

The abort criteria is that HHH sees the DDD has been
emulated twice in sequence.

Which doesn't prove the needed fact.

When the outer HHH sees that itself and its emulated HHH
has emulated DDD once the emulated HHH only sees that itself
has emulated DDD once.

But when the execution of the program being emulated continues to its
end, it WILL.

You are just proving you don't know what you are talking about, and it
seems just don't understand what a PROGRAM actually is, because you
decider to make yourself ignorant and refuse to study the material, just
making you just an ignorant pathological lying idiot.

this means that HHH failed to simulate itself correctly

As long as HHH emulates its input according to the semantics of the x86
language HHH is correctly emulating this input even if this correct
emulation causes the computer to catch on fire.
AS I HAVE TOLD YOU FAR TOO MANY TIMES CORRECT EMULATION IS ENTIRELY
DETERMINED BY THE SEMANTICS OF THE X86 LANGUAGE.
When DDD calls HHH(DDD) then HHH must emulate itself emulating DDD. If
this causes the emulated HHH to never return THEN THIS EMULATION IS
STIPULATED TO BE CORRECT BY THE ONLY MEASURE OF CORRECT EMULATION, the
semantics of the x86 language.

Useless stipulation.

up to the end. HHH cannot possibly simulate itself correctly up to the >>>> end.

HHH cannot possibly correctly simulate itself to the end because the x86 >>> code of DDD and HHH specify that HHH cannot simulate itself to the end.
If HHH did simulate itself to the end then HHH WOULD BE WRONG.

No simulator can simulate itself.

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

Op 04.sep.2024 om 14:37 schreef olcott:

On 9/4/2024 3:19 AM, joes wrote:

Am Mon, 02 Sep 2024 08:42:56 -0500 schrieb olcott:

On 9/1/2024 5:48 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 18:15 schreef olcott:

On 8/31/2024 10:47 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 17:22 schreef olcott:

On 8/31/2024 10:15 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:50 schreef olcott:

On 8/30/2024 8:31 AM, Mikko wrote:

On 2024-08-29 14:04:05 +0000, olcott said:

On 8/29/2024 3:00 AM, Mikko wrote:

On 2024-08-28 11:46:58 +0000, olcott said:

On 8/28/2024 2:33 AM, Mikko wrote:

On 2024-08-27 13:04:26 +0000, olcott said:

On 8/27/2024 12:45 AM, joes wrote:

Am Mon, 26 Aug 2024 18:03:41 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 8/26/2024 7:42 AM, Ben Bacarisse wrote:

Mike Terry <news.dead.person.stones@darjeeling.plus.com> >>>>>>>>>>>>>>>>>> writes:

On 23/08/2024 22:07, Ben Bacarisse wrote:

We don't really know what context Sipser was given.  I >>>>>>>>>>>>>>>>>>>> got in touch at the time so I do know he had enough >>>>>>>>>>>>>>>>>>>> context to know that PO's ideas were "wacky" and that >>>>>>>>>>>>>>>>>>>> had agreed to what he considered a "minor remark". >>>>>>>>>>>>>>>>>>>> Since PO considers his words finely crafted and key to >>>>>>>>>>>>>>>>>>>> his so-called work I think it's clear that Sipser did >>>>>>>>>>>>>>>>>>>> not take the "minor remark" he agreed to to mean what >>>>>>>>>>>>>>>>>>>> PO takes it to mean! My own take if that he (Sipser) >>>>>>>>>>>>>>>>>>>> read it as a general remark about how to determine some >>>>>>>>>>>>>>>>>>>> cases, i.e. that D names an input that H can partially >>>>>>>>>>>>>>>>>>>> simulate to determine it's halting or otherwise.  We >>>>>>>>>>>>>>>>>>>> all know or could construct some such cases. >>>>>>>>>>>>>>>>>>> Exactly my reading.  It makes Sipser's agreement >>>>>>>>>>>>>>>>>>> natural, because it is both correct [with sensible >>>>>>>>>>>>>>>>>>> interpretation of terms], and moreover describes an >>>>>>>>>>>>>>>>>>> obvious strategy that a partial decider might use that >>>>>>>>>>>>>>>>>>> can decide halting for some specific cases.  No need for >>>>>>>>>>>>>>>>>>> Sipser to be deceptive or misleading here, when the >>>>>>>>>>>>>>>>>>> truth suffices. (In particular no need to employ >>>>>>>>>>>>>>>>>>> "tricksy" vacuous truth get out clauses just to get PO >>>>>>>>>>>>>>>>>>> off his back as some have suggested.)

Yes, and it fits with his thinking it a "trivial remark". >>>>>>>>>>>>>>>>
That aside, it's such an odd way to present an argument: >>>>>>>>>>>>>>>>>> "I managed to trick X into saying 'yes' to something >>>>>>>>>>>>>>>>>> vague".  In any reasonable collegiate exchange you'd go >>>>>>>>>>>>>>>>>> back and check: "So even when D is constructed from H, H >>>>>>>>>>>>>>>>>> can return based on what /would/ happen if H did not stop >>>>>>>>>>>>>>>>>> simulating so that H(D,D) == false is correct even though >>>>>>>>>>>>>>>>>> D(D)
halts?".  Just imagine what Sipser would say to that! >>>>>>>>>>>>>>>> Is this an accurate phrasing, pete?

Deciders never compute the mapping of the computation that >>>>>>>>>>>>>>> they themselves are contained within.

Why not? A decider always either accepts or rejects its >>>>>>>>>>>>>> input.

The computation that they themselves are contained within >>>>>>>>>>>>> cannot possibly be an input.

What would prevent that if the input language permits
computations?

When a TM takes its own machine description as input this is not >>>>>>>>>>> always that same behavior as the direct execution of the >>>>>>>>>>> machine. It is not the same because it is one level of indirect >>>>>>>>>>> reference away.

Now you contradict what you said above. You said that deciders >>>>>>>>>> never conpute the mapping of the computation they themselves are >>>>>>>>>> contained within.

Although deciders cannot possibly see their own behavior other >>>>>>>>> people can see this behavior.

Now you are saying that they do in a way that might not be as >>>>>>>>>> expected.

If is a verified fact that DDD has different behavior before it is >>>>>>>>> aborted in the same way that people are hungry before they eat. >>>>>>>> No, the behaviour specified by the finite string does not change >>>>>>>> when a simulator decides to do the simulation only halfway. It is >>>>>>>> just an incorrect simulation.

than the behavior of DDD after it has been aborted, people are not >>>>>>>>> hungry after they eat.

If two people are hungry and one of them eats, the other one is >>>>>>>> still hungry and needs to eat. It is stupid to say that they are no >>>>>>>> longer hungry because they have eaten.
Similarly the simulating HHH is not longer hungry, but the
simulated HHH still is hungry and has not yet eaten.

The direct execution of DDD includes the behavior of the emulated >>>>>>>>> DDD after it has been aborted.

And the simulator should also simulate until it sees the behaviour >>>>>>>> of after the simulated HHH has aborted its simulator.

People that are not as stupid can see that HHH cannot wait for itself >>>>> to abort its own simulation.

And people (except the stupid ones) can see that, because HHH cannot
wait for itself,

Because this would require it to wait forever,
thus HHH knows that to meet its own requirement to halt it must abort
its simulation.

And because HHH is simulating itself, the simulated HHH also aborts.

It can not possibly do this. The outermost directly executed
HHH always sees the abort criteria before the next inner
HHH sees it.

The abort criteria is that HHH sees the DDD has been
emulated twice in sequence.

When the outer HHH sees that itself and its emulated HHH
has emulated DDD once the emulated HHH only sees that itself
has emulated DDD once.

Indeed. A very good explanation. That is what I told you many times. The
outer HHH fails to see that the inner HHH would abort as well, because
the outer HHH stops one cycle too soon.
If the outer HHH would be changed to do three cycles, it will give the
correct answer for the inner HHH that still does two cycles.
But then we can make another DDD with this new HHH and again it would
abort one cycle too soon and fail to see that the inner HHH will also
abort and halt.
If the outer HHH is programmed to do N cycles and the inner HHH is
programmed to do M cycle before the abort, then we see that N must be
greater than M for a correct simulation.
This proves that HHH cannot possibly correctly simulate *itself*.
It will always miss the end of the halting program.

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

Am Thu, 05 Sep 2024 08:48:24 -0500 schrieb olcott:

On 9/5/2024 5:04 AM, Fred. Zwarts wrote:

Op 04.sep.2024 om 14:37 schreef olcott:

On 9/4/2024 3:19 AM, joes wrote:

Am Mon, 02 Sep 2024 08:42:56 -0500 schrieb olcott:

On 9/1/2024 5:48 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 18:15 schreef olcott:

On 8/31/2024 10:47 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 17:22 schreef olcott:

On 8/31/2024 10:15 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:50 schreef olcott:

On 8/30/2024 8:31 AM, Mikko wrote:

On 2024-08-29 14:04:05 +0000, olcott said:

On 8/29/2024 3:00 AM, Mikko wrote:

On 2024-08-28 11:46:58 +0000, olcott said:

The direct execution of DDD includes the behavior of the >>>>>>>>>>> emulated DDD after it has been aborted.

And the simulator should also simulate until it sees the
behaviour of after the simulated HHH has aborted its simulator. >>>>>>> People that are not as stupid can see that HHH cannot wait for

itself to abort its own simulation.

And people (except the stupid ones) can see that, because HHH
cannot wait for itself,

Because this would require it to wait forever,
thus HHH knows that to meet its own requirement to halt it must
abort its simulation.

And because HHH is simulating itself, the simulated HHH also aborts.

It can not possibly do this. The outermost directly executed HHH
always sees the abort criteria before the next inner HHH sees it.
The abort criteria is that HHH sees the DDD has been emulated twice in
sequence.
When the outer HHH sees that itself and its emulated HHH has emulated
DDD once the emulated HHH only sees that itself has emulated DDD once.

Indeed. A very good explanation. That is what I told you many times.
The outer HHH fails to see that the inner HHH would abort as well,

IT WOULD NOT ABORT AS WELL. YOU HAVE THE FACTS INCORRECTLY.

The input to HHH calls that same HHH.

HHH MUST ABORT AFTER SOME FIXED NUMBER OF RECURSIVE EMULATIONS AND THE OUTERMOST HHH ALWAYS SEE ONE MORE THAN THE NEXT INNER ONE.

If the outermost didn’t abort, the next one would.
You can test this by setting Root to a small integer and aborting
when it is less than zero (decrementing per simulation level).
I would also be interested in flipping the condition, so that only
the outermost level did NOT abort. Or maybe a boolean Root being
flipped in each recursion.

If we have an infinite chain of people each waiting for the next one
down the line to do something then that thing is never done.

If we have an infinite chain of people all interrupting each other,
nothing gets done either.
--
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 9/5/24 9:48 AM, olcott wrote:

On 9/5/2024 5:04 AM, Fred. Zwarts wrote:

Op 04.sep.2024 om 14:37 schreef olcott:

On 9/4/2024 3:19 AM, joes wrote:

Am Mon, 02 Sep 2024 08:42:56 -0500 schrieb olcott:

On 9/1/2024 5:48 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 18:15 schreef olcott:

On 8/31/2024 10:47 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 17:22 schreef olcott:

On 8/31/2024 10:15 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:50 schreef olcott:

On 8/30/2024 8:31 AM, Mikko wrote:

On 2024-08-29 14:04:05 +0000, olcott said:

On 8/29/2024 3:00 AM, Mikko wrote:

On 2024-08-28 11:46:58 +0000, olcott said:

On 8/28/2024 2:33 AM, Mikko wrote:

On 2024-08-27 13:04:26 +0000, olcott said:

On 8/27/2024 12:45 AM, joes wrote:

Am Mon, 26 Aug 2024 18:03:41 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>> On 8/26/2024 7:42 AM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>>> Mike Terry

<news.dead.person.stones@darjeeling.plus.com> >>>>>>>>>>>>>>>>>>>> writes:

On 23/08/2024 22:07, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>

We don't really know what context Sipser was >>>>>>>>>>>>>>>>>>>>>> given.  I
got in touch at the time so I do know he had enough >>>>>>>>>>>>>>>>>>>>>> context to know that PO's ideas were "wacky" and that >>>>>>>>>>>>>>>>>>>>>> had agreed to what he considered a "minor remark". >>>>>>>>>>>>>>>>>>>>>> Since PO considers his words finely crafted and >>>>>>>>>>>>>>>>>>>>>> key to
his so-called work I think it's clear that Sipser did >>>>>>>>>>>>>>>>>>>>>> not take the "minor remark" he agreed to to mean what >>>>>>>>>>>>>>>>>>>>>> PO takes it to mean! My own take if that he (Sipser) >>>>>>>>>>>>>>>>>>>>>> read it as a general remark about how to determine >>>>>>>>>>>>>>>>>>>>>> some
cases, i.e. that D names an input that H can >>>>>>>>>>>>>>>>>>>>>> partially
simulate to determine it's halting or otherwise.  We >>>>>>>>>>>>>>>>>>>>>> all know or could construct some such cases. >>>>>>>>>>>>>>>>>>>>> Exactly my reading.  It makes Sipser's agreement >>>>>>>>>>>>>>>>>>>>> natural, because it is both correct [with sensible >>>>>>>>>>>>>>>>>>>>> interpretation of terms], and moreover describes an >>>>>>>>>>>>>>>>>>>>> obvious strategy that a partial decider might use that >>>>>>>>>>>>>>>>>>>>> can decide halting for some specific cases.  No >>>>>>>>>>>>>>>>>>>>> need for

Sipser to be deceptive or misleading here, when the >>>>>>>>>>>>>>>>>>>>> truth suffices. (In particular no need to employ >>>>>>>>>>>>>>>>>>>>> "tricksy" vacuous truth get out clauses just to get PO >>>>>>>>>>>>>>>>>>>>> off his back as some have suggested.) >>>>>>>>>>>>>>>>>>>> Yes, and it fits with his thinking it a "trivial >>>>>>>>>>>>>>>>>>>> remark".

That aside, it's such an odd way to present an >>>>>>>>>>>>>>>>>>>> argument:
"I managed to trick X into saying 'yes' to something >>>>>>>>>>>>>>>>>>>> vague".  In any reasonable collegiate exchange you'd go >>>>>>>>>>>>>>>>>>>> back and check: "So even when D is constructed from >>>>>>>>>>>>>>>>>>>> H, H
can return based on what /would/ happen if H did not >>>>>>>>>>>>>>>>>>>> stop
simulating so that H(D,D) == false is correct even >>>>>>>>>>>>>>>>>>>> though
D(D)
halts?".  Just imagine what Sipser would say to that! >>>>>>>>>>>>>>>>>> Is this an accurate phrasing, pete?

Deciders never compute the mapping of the computation that >>>>>>>>>>>>>>>>> they themselves are contained within.

Why not? A decider always either accepts or rejects its >>>>>>>>>>>>>>>> input.

The computation that they themselves are contained within >>>>>>>>>>>>>>> cannot possibly be an input.

What would prevent that if the input language permits >>>>>>>>>>>>>> computations?

When a TM takes its own machine description as input this >>>>>>>>>>>>> is not
always that same behavior as the direct execution of the >>>>>>>>>>>>> machine. It is not the same because it is one level of >>>>>>>>>>>>> indirect
reference away.

Now you contradict what you said above. You said that deciders >>>>>>>>>>>> never conpute the mapping of the computation they themselves >>>>>>>>>>>> are
contained within.

Although deciders cannot possibly see their own behavior other >>>>>>>>>>> people can see this behavior.

Now you are saying that they do in a way that might not be as >>>>>>>>>>>> expected.

If is a verified fact that DDD has different behavior before >>>>>>>>>>> it is
aborted in the same way that people are hungry before they eat. >>>>>>>>>> No, the behaviour specified by the finite string does not change >>>>>>>>>> when a simulator decides to do the simulation only halfway. It is >>>>>>>>>> just an incorrect simulation.

than the behavior of DDD after it has been aborted, people >>>>>>>>>>> are not
hungry after they eat.

If two people are hungry and one of them eats, the other one is >>>>>>>>>> still hungry and needs to eat. It is stupid to say that they >>>>>>>>>> are no
longer hungry because they have eaten.
Similarly the simulating HHH is not longer hungry, but the >>>>>>>>>> simulated HHH still is hungry and has not yet eaten.

The direct execution of DDD includes the behavior of the >>>>>>>>>>> emulated
DDD after it has been aborted.

And the simulator should also simulate until it sees the
behaviour
of after the simulated HHH has aborted its simulator.

People that are not as stupid can see that HHH cannot wait for
itself
to abort its own simulation.

And people (except the stupid ones) can see that, because HHH cannot >>>>>> wait for itself,

Because this would require it to wait forever,
thus HHH knows that to meet its own requirement to halt it must abort >>>>> its simulation.

And because HHH is simulating itself, the simulated HHH also aborts.

It can not possibly do this. The outermost directly executed
HHH always sees the abort criteria before the next inner
HHH sees it.

The abort criteria is that HHH sees the DDD has been
emulated twice in sequence.

When the outer HHH sees that itself and its emulated HHH
has emulated DDD once the emulated HHH only sees that itself
has emulated DDD once.

Indeed. A very good explanation. That is what I told you many times.
The outer HHH fails to see that the inner HHH would abort as well,

IT WOULD NOT ABORT AS WELL. YOU HAVE THE FACTS INCORRECTLY.
HHH MUST ABORT AFTER SOME FIXED NUMBER OF RECURSIVE EMULATIONS
AND THE OUTERMOST HHH ALWAYS SEE ONE MORE THAN THE NEXT INNER ONE.

And then it would be the HHH that *IS* here.

You forget thatwe STARTED with you needing to provide an HHH that you
are going to claim to be correct.

If we have an infinite chain of people each waiting for
the next one down the line to do something then that thing
is never done.

Right, so if HHH doesn't abort, it fails to be a decider.

If it DOES abort, it needs to understand that the HHH that it is
simulating WILL also abort, but yours fails to do that, and thus is
wrong for this non-pathological case.

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

Op 05.sep.2024 om 15:48 schreef olcott:

On 9/5/2024 5:04 AM, Fred. Zwarts wrote:

Op 04.sep.2024 om 14:37 schreef olcott:

On 9/4/2024 3:19 AM, joes wrote:

Am Mon, 02 Sep 2024 08:42:56 -0500 schrieb olcott:

On 9/1/2024 5:48 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 18:15 schreef olcott:

On 8/31/2024 10:47 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 17:22 schreef olcott:

On 8/31/2024 10:15 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:50 schreef olcott:

On 8/30/2024 8:31 AM, Mikko wrote:

On 2024-08-29 14:04:05 +0000, olcott said:

On 8/29/2024 3:00 AM, Mikko wrote:

On 2024-08-28 11:46:58 +0000, olcott said:

On 8/28/2024 2:33 AM, Mikko wrote:

On 2024-08-27 13:04:26 +0000, olcott said:

On 8/27/2024 12:45 AM, joes wrote:

Am Mon, 26 Aug 2024 18:03:41 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>> On 8/26/2024 7:42 AM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>>> Mike Terry

<news.dead.person.stones@darjeeling.plus.com> >>>>>>>>>>>>>>>>>>>> writes:

On 23/08/2024 22:07, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>

We don't really know what context Sipser was >>>>>>>>>>>>>>>>>>>>>> given.  I
got in touch at the time so I do know he had enough >>>>>>>>>>>>>>>>>>>>>> context to know that PO's ideas were "wacky" and that >>>>>>>>>>>>>>>>>>>>>> had agreed to what he considered a "minor remark". >>>>>>>>>>>>>>>>>>>>>> Since PO considers his words finely crafted and >>>>>>>>>>>>>>>>>>>>>> key to
his so-called work I think it's clear that Sipser did >>>>>>>>>>>>>>>>>>>>>> not take the "minor remark" he agreed to to mean what >>>>>>>>>>>>>>>>>>>>>> PO takes it to mean! My own take if that he (Sipser) >>>>>>>>>>>>>>>>>>>>>> read it as a general remark about how to determine >>>>>>>>>>>>>>>>>>>>>> some
cases, i.e. that D names an input that H can >>>>>>>>>>>>>>>>>>>>>> partially
simulate to determine it's halting or otherwise.  We >>>>>>>>>>>>>>>>>>>>>> all know or could construct some such cases. >>>>>>>>>>>>>>>>>>>>> Exactly my reading.  It makes Sipser's agreement >>>>>>>>>>>>>>>>>>>>> natural, because it is both correct [with sensible >>>>>>>>>>>>>>>>>>>>> interpretation of terms], and moreover describes an >>>>>>>>>>>>>>>>>>>>> obvious strategy that a partial decider might use that >>>>>>>>>>>>>>>>>>>>> can decide halting for some specific cases.  No >>>>>>>>>>>>>>>>>>>>> need for

Sipser to be deceptive or misleading here, when the >>>>>>>>>>>>>>>>>>>>> truth suffices. (In particular no need to employ >>>>>>>>>>>>>>>>>>>>> "tricksy" vacuous truth get out clauses just to get PO >>>>>>>>>>>>>>>>>>>>> off his back as some have suggested.) >>>>>>>>>>>>>>>>>>>> Yes, and it fits with his thinking it a "trivial >>>>>>>>>>>>>>>>>>>> remark".

That aside, it's such an odd way to present an >>>>>>>>>>>>>>>>>>>> argument:
"I managed to trick X into saying 'yes' to something >>>>>>>>>>>>>>>>>>>> vague".  In any reasonable collegiate exchange you'd go >>>>>>>>>>>>>>>>>>>> back and check: "So even when D is constructed from >>>>>>>>>>>>>>>>>>>> H, H
can return based on what /would/ happen if H did not >>>>>>>>>>>>>>>>>>>> stop
simulating so that H(D,D) == false is correct even >>>>>>>>>>>>>>>>>>>> though
D(D)
halts?".  Just imagine what Sipser would say to that! >>>>>>>>>>>>>>>>>> Is this an accurate phrasing, pete?

Deciders never compute the mapping of the computation that >>>>>>>>>>>>>>>>> they themselves are contained within.

Why not? A decider always either accepts or rejects its >>>>>>>>>>>>>>>> input.

The computation that they themselves are contained within >>>>>>>>>>>>>>> cannot possibly be an input.

What would prevent that if the input language permits >>>>>>>>>>>>>> computations?

When a TM takes its own machine description as input this >>>>>>>>>>>>> is not
always that same behavior as the direct execution of the >>>>>>>>>>>>> machine. It is not the same because it is one level of >>>>>>>>>>>>> indirect
reference away.

Now you contradict what you said above. You said that deciders >>>>>>>>>>>> never conpute the mapping of the computation they themselves >>>>>>>>>>>> are
contained within.

Although deciders cannot possibly see their own behavior other >>>>>>>>>>> people can see this behavior.

Now you are saying that they do in a way that might not be as >>>>>>>>>>>> expected.

If is a verified fact that DDD has different behavior before >>>>>>>>>>> it is
aborted in the same way that people are hungry before they eat. >>>>>>>>>> No, the behaviour specified by the finite string does not change >>>>>>>>>> when a simulator decides to do the simulation only halfway. It is >>>>>>>>>> just an incorrect simulation.

than the behavior of DDD after it has been aborted, people >>>>>>>>>>> are not
hungry after they eat.

If two people are hungry and one of them eats, the other one is >>>>>>>>>> still hungry and needs to eat. It is stupid to say that they >>>>>>>>>> are no
longer hungry because they have eaten.
Similarly the simulating HHH is not longer hungry, but the >>>>>>>>>> simulated HHH still is hungry and has not yet eaten.

The direct execution of DDD includes the behavior of the >>>>>>>>>>> emulated
DDD after it has been aborted.

And the simulator should also simulate until it sees the
behaviour
of after the simulated HHH has aborted its simulator.

People that are not as stupid can see that HHH cannot wait for
itself
to abort its own simulation.

And people (except the stupid ones) can see that, because HHH cannot >>>>>> wait for itself,

Because this would require it to wait forever,
thus HHH knows that to meet its own requirement to halt it must abort >>>>> its simulation.

And because HHH is simulating itself, the simulated HHH also aborts.

It can not possibly do this. The outermost directly executed
HHH always sees the abort criteria before the next inner
HHH sees it.

The abort criteria is that HHH sees the DDD has been
emulated twice in sequence.

When the outer HHH sees that itself and its emulated HHH
has emulated DDD once the emulated HHH only sees that itself
has emulated DDD once.

Indeed. A very good explanation. That is what I told you many times.
The outer HHH fails to see that the inner HHH would abort as well,

IT WOULD NOT ABORT AS WELL. YOU HAVE THE FACTS INCORRECTLY.

That is your dream,but reality is as I stated.

HHH MUST ABORT AFTER SOME FIXED NUMBER OF RECURSIVE EMULATIONS
AND THE OUTERMOST HHH ALWAYS SEE ONE MORE THAN THE NEXT INNER ONE.

And the outer one, when aborting after two cycles , misses the behaviour
of the inner one in the next cycle, where the inner one would see the
'special condition', abort, return to DDD, which would halt as well.
That HHH misses the last part of the behaviour of the program, does not
change the fact that this is the behaviour that was coded in the program

If we have an infinite chain of people each waiting for
the next one down the line to do something then that thing
is never done.

The infinite chain exists only in your dream. In fact there are only two recursions, so never more that a chain of three HHH in the simulation.
HHH is incorrect in assuming the there is an infinite chain, but this
incorrect assumption makes that it aborts and halts. This applies both
to the simulating and the simulated HHH.

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

On 9/6/24 7:31 AM, olcott wrote:

On 9/6/2024 4:36 AM, Fred. Zwarts wrote:

Op 05.sep.2024 om 15:48 schreef olcott:

HHH MUST ABORT AFTER SOME FIXED NUMBER OF RECURSIVE EMULATIONS
AND THE OUTERMOST HHH ALWAYS SEE ONE MORE THAN THE NEXT INNER ONE.

And the outer one, when aborting after two cycles , misses the
behaviour of the inner one in the next cycle, where the inner one
would see the 'special condition', abort, return to DDD, which would
halt as well.
That HHH misses the last part of the behaviour of the program, does
not change the fact that this is the behaviour that was coded in the
program

If we have an infinite chain of people each waiting for
the next one down the line to do something then that thing
is never done.

The infinite chain exists only in your dream. In fact there are only
two recursions, so never more that a chain of three HHH in the
simulation.
HHH is incorrect in assuming the there is an infinite chain, but this
incorrect assumption makes that it aborts and halts. This applies both
to the simulating and the simulated HHH.

The way it is encoded now there are only two recursions.

If we encode it as you suggest the outermost directly
executed HHH would wait for the first emulated HHH which
would wait for the second which would wait for third
on and on...

No, HHH does what it is coded to do. No matter how far it emulates, it
will NEVER get to the needed point to know what is to happen.

That means the algorithm you are proposing just fails to be able to get
the correct answer, it doesn't mean that it will simulate longer, only
that it SHOULD HAVE to get the right answer.

This concept seems to be beyond what you ignorant mind can handle,
making you just decide to tell LIES about what HHH actually does.

You description is of the HHH that choses not to decide, and thus nevef answers.

Sorry, that is just the facts, HHH does what it does and it will never
be enough, because it turns out the full problem is non-computable.

For THIS DDD, it turns out that a smarted decider could get the right
answer, it just needs to adopt the flibble method of seeing the call to
HHH in DDD, and try the two possible future paths to see if either is
correct. SInce one is in this case, since DDD is NOT "pathological"
there can be a decider that gets this template decided, just not the pathological one that defeats even the Flibble decider.

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

Op 06.sep.2024 om 13:31 schreef olcott:

On 9/6/2024 4:36 AM, Fred. Zwarts wrote:

Op 05.sep.2024 om 15:48 schreef olcott:

HHH MUST ABORT AFTER SOME FIXED NUMBER OF RECURSIVE EMULATIONS
AND THE OUTERMOST HHH ALWAYS SEE ONE MORE THAN THE NEXT INNER ONE.

And the outer one, when aborting after two cycles , misses the
behaviour of the inner one in the next cycle, where the inner one
would see the 'special condition', abort, return to DDD, which would
halt as well.
That HHH misses the last part of the behaviour of the program, does
not change the fact that this is the behaviour that was coded in the
program

If we have an infinite chain of people each waiting for
the next one down the line to do something then that thing
is never done.

The infinite chain exists only in your dream. In fact there are only
two recursions, so never more that a chain of three HHH in the
simulation.
HHH is incorrect in assuming the there is an infinite chain, but this
incorrect assumption makes that it aborts and halts. This applies both
to the simulating and the simulated HHH.

The way it is encoded now there are only two recursions.

If we encode it as you suggest the outermost directly
executed HHH would wait for the first emulated HHH which
would wait for the second which would wait for third
on and on...

What is olcott's problem with English?
If one way is incorrect, he thinks that it suggests that another way
must be correct.
I never suggested to change HHH, because there is *no* correct way to do
it. Every HHH that simulates itself is incorrect. No matter what clever
code it includes.
There are two types of HHH:
a) that waits till the simulation halts,
b) that does not wait but aborts and halts.

The HHHa is correct when its input is based on HHHb, but does not halt
if its input is based on HHHa.
The HHHb is correct when its input is based on HHHa, but incorrect when
its input is based on HHHb.
HHH cannot possibly simulate *itself* correctly up to the end.

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

On 9/7/24 10:00 AM, olcott wrote:

On 9/7/2024 5:19 AM, Fred. Zwarts wrote:

Op 06.sep.2024 om 13:31 schreef olcott:

On 9/6/2024 4:36 AM, Fred. Zwarts wrote:

Op 05.sep.2024 om 15:48 schreef olcott:

HHH MUST ABORT AFTER SOME FIXED NUMBER OF RECURSIVE EMULATIONS
AND THE OUTERMOST HHH ALWAYS SEE ONE MORE THAN THE NEXT INNER ONE.

And the outer one, when aborting after two cycles , misses the
behaviour of the inner one in the next cycle, where the inner one
would see the 'special condition', abort, return to DDD, which would
halt as well.
That HHH misses the last part of the behaviour of the program, does
not change the fact that this is the behaviour that was coded in the
program

If we have an infinite chain of people each waiting for
the next one down the line to do something then that thing
is never done.

The infinite chain exists only in your dream. In fact there are only
two recursions, so never more that a chain of three HHH in the
simulation.
HHH is incorrect in assuming the there is an infinite chain, but
this incorrect assumption makes that it aborts and halts. This
applies both to the simulating and the simulated HHH.

The way it is encoded now there are only two recursions.

If we encode it as you suggest the outermost directly
executed HHH would wait for the first emulated HHH which
would wait for the second which would wait for third
on and on...

What is olcott's problem with English?
If one way is incorrect, he thinks that it suggests that another way
must be correct.
I never suggested to change HHH, because there is *no* correct way to
do it. Every HHH that simulates itself is incorrect. No matter what
clever code it includes.

You must be a brain dead moron.
As long as HHH emulates the sequence of instructions
it was provided then HHH is correct even if it catches
your computer on fire.

Yes, and as soon as it aborts that simulation to give an answer, it is
no longer a correct emulator.

You need to make a choice about what HHH is, is it a correct emulator,
that creates a non-halting DDD and gets stuck emulating it forever, or
is it a decider, that therefore aborts its emulation at some point and
returns, and thus makes a HALTING DDD, but it gets the wrong answer
about DDD, because it was an incorrect emulator.

Trying to pretend that it is both is just lying to yourself.

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

On 2024-09-07 14:00:19 +0000, olcott said:

On 9/7/2024 5:19 AM, Fred. Zwarts wrote:

Op 06.sep.2024 om 13:31 schreef olcott:

On 9/6/2024 4:36 AM, Fred. Zwarts wrote:

Op 05.sep.2024 om 15:48 schreef olcott:

HHH MUST ABORT AFTER SOME FIXED NUMBER OF RECURSIVE EMULATIONS
AND THE OUTERMOST HHH ALWAYS SEE ONE MORE THAN THE NEXT INNER ONE.

And the outer one, when aborting after two cycles , misses the
behaviour of the inner one in the next cycle, where the inner one would >>>> see the 'special condition', abort, return to DDD, which would halt as >>>> well.
That HHH misses the last part of the behaviour of the program, does not >>>> change the fact that this is the behaviour that was coded in the program >>>>

If we have an infinite chain of people each waiting for
the next one down the line to do something then that thing
is never done.

The infinite chain exists only in your dream. In fact there are only
two recursions, so never more that a chain of three HHH in the
simulation.
HHH is incorrect in assuming the there is an infinite chain, but this
incorrect assumption makes that it aborts and halts. This applies both >>>> to the simulating and the simulated HHH.

The way it is encoded now there are only two recursions.

If we encode it as you suggest the outermost directly
executed HHH would wait for the first emulated HHH which
would wait for the second which would wait for third
on and on...

What is olcott's problem with English?
If one way is incorrect, he thinks that it suggests that another way
must be correct.
I never suggested to change HHH, because there is *no* correct way to
do it. Every HHH that simulates itself is incorrect. No matter what
clever code it includes.

You must be a brain dead moron.
As long as HHH emulates the sequence of instructions
it was provided then HHH is correct even if it catches
your computer on fire.

That is right. The error only occurs when HHH no longer emulates the
sequence of instructions it was provided.

--
Mikko

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

Op 07.sep.2024 om 16:00 schreef olcott:

On 9/7/2024 5:19 AM, Fred. Zwarts wrote:

Op 06.sep.2024 om 13:31 schreef olcott:

On 9/6/2024 4:36 AM, Fred. Zwarts wrote:

Op 05.sep.2024 om 15:48 schreef olcott:

HHH MUST ABORT AFTER SOME FIXED NUMBER OF RECURSIVE EMULATIONS
AND THE OUTERMOST HHH ALWAYS SEE ONE MORE THAN THE NEXT INNER ONE.

And the outer one, when aborting after two cycles , misses the
behaviour of the inner one in the next cycle, where the inner one
would see the 'special condition', abort, return to DDD, which would
halt as well.
That HHH misses the last part of the behaviour of the program, does
not change the fact that this is the behaviour that was coded in the
program

If we have an infinite chain of people each waiting for
the next one down the line to do something then that thing
is never done.

The infinite chain exists only in your dream. In fact there are only
two recursions, so never more that a chain of three HHH in the
simulation.
HHH is incorrect in assuming the there is an infinite chain, but
this incorrect assumption makes that it aborts and halts. This
applies both to the simulating and the simulated HHH.

The way it is encoded now there are only two recursions.

If we encode it as you suggest the outermost directly
executed HHH would wait for the first emulated HHH which
would wait for the second which would wait for third
on and on...

What is olcott's problem with English?
If one way is incorrect, he thinks that it suggests that another way
must be correct.
I never suggested to change HHH, because there is *no* correct way to
do it. Every HHH that simulates itself is incorrect. No matter what
clever code it includes.

You must be a brain dead moron.

Ad hominem attack without evidence. Does olcott really think that it
will convince anyone?

As long as HHH emulates the sequence of instructions
it was provided then HHH is correct even if it catches
your computer on fire.

HHH only made a correct start of the simulation, but failed to reach the
end of the halting program.
There is no need to set the computer in fire to halt a program, if the
program halts of its own.
No matter how clever HHH is coded, HHH cannot possibly simulate itself correctly up to the end and there is no way to fix it.
Even olcott himself has repeatedly proven that HHH cannot reach the end
of its own simulation, but he is unable to accept his own proofs.

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

On 2024-09-08 13:58:32 +0000, olcott said:

On 9/8/2024 4:25 AM, Mikko wrote:

On 2024-09-07 14:00:19 +0000, olcott said:

On 9/7/2024 5:19 AM, Fred. Zwarts wrote:

Op 06.sep.2024 om 13:31 schreef olcott:

On 9/6/2024 4:36 AM, Fred. Zwarts wrote:

Op 05.sep.2024 om 15:48 schreef olcott:

HHH MUST ABORT AFTER SOME FIXED NUMBER OF RECURSIVE EMULATIONS
AND THE OUTERMOST HHH ALWAYS SEE ONE MORE THAN THE NEXT INNER ONE. >>>>>>

And the outer one, when aborting after two cycles , misses the
behaviour of the inner one in the next cycle, where the inner one would >>>>>> see the 'special condition', abort, return to DDD, which would halt as >>>>>> well.
That HHH misses the last part of the behaviour of the program, does not >>>>>> change the fact that this is the behaviour that was coded in the program >>>>>>

If we have an infinite chain of people each waiting for
the next one down the line to do something then that thing
is never done.

The infinite chain exists only in your dream. In fact there are only >>>>>> two recursions, so never more that a chain of three HHH in the
simulation.
HHH is incorrect in assuming the there is an infinite chain, but this >>>>>> incorrect assumption makes that it aborts and halts. This applies both >>>>>> to the simulating and the simulated HHH.

The way it is encoded now there are only two recursions.

If we encode it as you suggest the outermost directly
executed HHH would wait for the first emulated HHH which
would wait for the second which would wait for third
on and on...

What is olcott's problem with English?
If one way is incorrect, he thinks that it suggests that another way
must be correct.
I never suggested to change HHH, because there is *no* correct way to
do it. Every HHH that simulates itself is incorrect. No matter what
clever code it includes.

You must be a brain dead moron.
As long as HHH emulates the sequence of instructions
it was provided then HHH is correct even if it catches
your computer on fire.

That is right. The error only occurs when HHH no longer emulates the
sequence of instructions it was provided.

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then

H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>

The above refers to determining that *its input D*
"specifies a non-halting sequence of configurations"
When people change this to a *non-input D* they are
trying to get away with deception.

We know except the only "people" that do so is you.

--
Mikko

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

On 9/8/24 9:58 AM, olcott wrote:

On 9/8/2024 4:25 AM, Mikko wrote:

On 2024-09-07 14:00:19 +0000, olcott said:

On 9/7/2024 5:19 AM, Fred. Zwarts wrote:

Op 06.sep.2024 om 13:31 schreef olcott:

On 9/6/2024 4:36 AM, Fred. Zwarts wrote:

Op 05.sep.2024 om 15:48 schreef olcott:

HHH MUST ABORT AFTER SOME FIXED NUMBER OF RECURSIVE EMULATIONS
AND THE OUTERMOST HHH ALWAYS SEE ONE MORE THAN THE NEXT INNER ONE. >>>>>>

And the outer one, when aborting after two cycles , misses the
behaviour of the inner one in the next cycle, where the inner one
would see the 'special condition', abort, return to DDD, which
would halt as well.
That HHH misses the last part of the behaviour of the program,
does not change the fact that this is the behaviour that was coded >>>>>> in the program

If we have an infinite chain of people each waiting for
the next one down the line to do something then that thing
is never done.

The infinite chain exists only in your dream. In fact there are
only two recursions, so never more that a chain of three HHH in
the simulation.
HHH is incorrect in assuming the there is an infinite chain, but
this incorrect assumption makes that it aborts and halts. This
applies both to the simulating and the simulated HHH.

The way it is encoded now there are only two recursions.

If we encode it as you suggest the outermost directly
executed HHH would wait for the first emulated HHH which
would wait for the second which would wait for third
on and on...

What is olcott's problem with English?
If one way is incorrect, he thinks that it suggests that another way
must be correct.
I never suggested to change HHH, because there is *no* correct way
to do it. Every HHH that simulates itself is incorrect. No matter
what clever code it includes.

You must be a brain dead moron.
As long as HHH emulates the sequence of instructions
it was provided then HHH is correct even if it catches
your computer on fire.

That is right. The error only occurs when HHH no longer emulates the
sequence of instructions it was provided.

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
    If simulating halt decider H correctly simulates its input D
    until H correctly determines that its simulated D would never
    stop running unless aborted then

    H can abort its simulation of D and correctly report that D
    specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>

The above refers to determining that *its input D*

Which BY DEFINITION uses THIS H, the one that uses this criteria to
INCORRECTLY about its simulation.

"specifies a non-halting sequence of configurations"

But it doesn't, since the condition is not satisfied. The CORRECT
SIMULATION of this input does halt, H can not do that simulation, since
it *WILL* choose to abort its simulation, since that *IS* the code you
have proposed for it.

When people change this to a *non-input D* they are
trying to get away with deception.

But the non-input is the D that calls the H that didn't abort, since it
calls THIS H, the one that eventually aborted. You arjust caught in the
fact that you are lying to yourself, but you are too stupid to see that blantent lie.

The pathological relationship where DDD calls its
own emulator DOES CHANGE THE BEHAVIOR OF DDD.

But that is just your LYING FALSE CLAIM that you have admitted is such
because you can not show the actual instruction that was CORRECTLY
emulated that began that difference. Your claims able the call
instruction acting differently just shows your utter pathologically
ignorant understanding of what you are talking about.

Note, just calling HHH is NOT a "pathological" relationship by most
normal definitions, as it is still possible to make an HHH that could
get the right answer, you are just too stupid to understand that method,
and have just rejected it out of stupidity. The D that does the opposite
could be called "pathological" since it makes an input that it is
IMPOSSIBLE to build a decider that can decide on an input built from it
by that template, but that doesn't make the problem invalid, or the
corret answer about the DEFINED behavior of that input. Such an input
*WILL* either diffinitively Halt, or never Halt, depending on the
algorithm in the decider it is built on, so there *IS* a correct answer
to the question, just not one that that particular decider happens to give.

A lot of prospective deciders give wrong answers to the question they
might have been aimed out. No problem with the fact that a given machine
that was claimed to be a foo-decider for miscomputing the fooness of its
input, that just makes it not a correct foo-decider.

Simply ignoring that this pathological relationship
DOES CHANGE THE BEHAVIOR OF DDD is ridiculously stupid.

Nope, Thinking thing that have been PROVEN incorrect, like the exact
emulation of the exact same deterministic instructions with the exact
same inputs can possible create divergent results.

You are just stuck with the problem that you belive your own lies to
yourself more than an honest evaluation of the world, which has made you clinically insane.

Sorry, but that *IS* the facts, and your inability to handle them just
proves your funny-mental inability to handle the truth. You have made
yourself into a pathological liar because your seem to have a blind spot
for seeing the truth.

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

On 9/9/24 2:15 PM, olcott wrote:

On 9/8/2024 9:44 AM, Mikko wrote:

On 2024-09-08 13:58:32 +0000, olcott said:

On 9/8/2024 4:25 AM, Mikko wrote:

On 2024-09-07 14:00:19 +0000, olcott said:

On 9/7/2024 5:19 AM, Fred. Zwarts wrote:

Op 06.sep.2024 om 13:31 schreef olcott:

On 9/6/2024 4:36 AM, Fred. Zwarts wrote:

Op 05.sep.2024 om 15:48 schreef olcott:

HHH MUST ABORT AFTER SOME FIXED NUMBER OF RECURSIVE EMULATIONS >>>>>>>>> AND THE OUTERMOST HHH ALWAYS SEE ONE MORE THAN THE NEXT INNER ONE. >>>>>>>>

And the outer one, when aborting after two cycles , misses the >>>>>>>> behaviour of the inner one in the next cycle, where the inner
one would see the 'special condition', abort, return to DDD,
which would halt as well.
That HHH misses the last part of the behaviour of the program, >>>>>>>> does not change the fact that this is the behaviour that was
coded in the program

If we have an infinite chain of people each waiting for
the next one down the line to do something then that thing
is never done.

The infinite chain exists only in your dream. In fact there are >>>>>>>> only two recursions, so never more that a chain of three HHH in >>>>>>>> the simulation.
HHH is incorrect in assuming the there is an infinite chain, but >>>>>>>> this incorrect assumption makes that it aborts and halts. This >>>>>>>> applies both to the simulating and the simulated HHH.

The way it is encoded now there are only two recursions.

If we encode it as you suggest the outermost directly
executed HHH would wait for the first emulated HHH which
would wait for the second which would wait for third
on and on...

What is olcott's problem with English?
If one way is incorrect, he thinks that it suggests that another
way must be correct.
I never suggested to change HHH, because there is *no* correct way >>>>>> to do it. Every HHH that simulates itself is incorrect. No matter
what clever code it includes.

You must be a brain dead moron.
As long as HHH emulates the sequence of instructions
it was provided then HHH is correct even if it catches
your computer on fire.

That is right. The error only occurs when HHH no longer emulates the
sequence of instructions it was provided.

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
     If simulating halt decider H correctly simulates its input D
     until H correctly determines that its simulated D would never
     stop running unless aborted then

     H can abort its simulation of D and correctly report that D
     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>

The above refers to determining that *its input D*
"specifies a non-halting sequence of configurations"
When people change this to a *non-input D* they are
trying to get away with deception.

We know except the only "people" that do so is you.

_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]

Try to show all of the details of how DDD emulated
by HHH ever reaches machine address  00002183

Sequences of machine addressed when DDD is emulated by HHH
00002172, 00002173, 00002175, 0000217a
which calls an emulated HHH(DDD).

What are the next instructions of DDD emulated by the emulated HHH ?

Not by HHH, because it aborts to soon showing your definition is
incoherent, but your 200 page trace shows what the correct emulation
would look like, if you change the addresses of the begining 4 lines to
be from DDD instead of main, and then the final steps of DDD after HHH
returns to it.

This has been told to you, and you have IGNORED it, proving you don't
actually care about the truth, you just want to spread your PATHOLOGICAL
LIES.

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

On 2024-09-09 18:15:26 +0000, olcott said:

On 9/8/2024 9:44 AM, Mikko wrote:

On 2024-09-08 13:58:32 +0000, olcott said:

On 9/8/2024 4:25 AM, Mikko wrote:

On 2024-09-07 14:00:19 +0000, olcott said:

On 9/7/2024 5:19 AM, Fred. Zwarts wrote:

Op 06.sep.2024 om 13:31 schreef olcott:

On 9/6/2024 4:36 AM, Fred. Zwarts wrote:

Op 05.sep.2024 om 15:48 schreef olcott:

HHH MUST ABORT AFTER SOME FIXED NUMBER OF RECURSIVE EMULATIONS >>>>>>>>> AND THE OUTERMOST HHH ALWAYS SEE ONE MORE THAN THE NEXT INNER ONE. >>>>>>>>

And the outer one, when aborting after two cycles , misses the >>>>>>>> behaviour of the inner one in the next cycle, where the inner one would
see the 'special condition', abort, return to DDD, which would halt as >>>>>>>> well.
That HHH misses the last part of the behaviour of the program, does not
change the fact that this is the behaviour that was coded in the program

If we have an infinite chain of people each waiting for
the next one down the line to do something then that thing
is never done.

The infinite chain exists only in your dream. In fact there are only >>>>>>>> two recursions, so never more that a chain of three HHH in the >>>>>>>> simulation.
HHH is incorrect in assuming the there is an infinite chain, but this >>>>>>>> incorrect assumption makes that it aborts and halts. This applies both >>>>>>>> to the simulating and the simulated HHH.

The way it is encoded now there are only two recursions.

If we encode it as you suggest the outermost directly
executed HHH would wait for the first emulated HHH which
would wait for the second which would wait for third
on and on...

What is olcott's problem with English?
If one way is incorrect, he thinks that it suggests that another way >>>>>> must be correct.
I never suggested to change HHH, because there is *no* correct way to >>>>>> do it. Every HHH that simulates itself is incorrect. No matter what >>>>>> clever code it includes.

You must be a brain dead moron.
As long as HHH emulates the sequence of instructions
it was provided then HHH is correct even if it catches
your computer on fire.

That is right. The error only occurs when HHH no longer emulates the
sequence of instructions it was provided.

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
     If simulating halt decider H correctly simulates its input D
     until H correctly determines that its simulated D would never
     stop running unless aborted then

     H can abort its simulation of D and correctly report that D
     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>

The above refers to determining that *its input D*
"specifies a non-halting sequence of configurations"
When people change this to a *non-input D* they are
trying to get away with deception.

We know except the only "people" that do so is you.

_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]

Try to show all of the details of how DDD emulated
by HHH ever reaches machine address 00002183

It is your emulator so you need to show what needs be shown.
For others it is sufficient to determine what HHH returns and
whether DDD halts and compare the two.

Sequences of machine addressed when DDD is emulated by HHH
00002172, 00002173, 00002175, 0000217a
which calls an emulated HHH(DDD).

What are the next instructions of DDD emulated by the emulated HHH ?

Here, too, it is your problem to show what needs be shown.
For the rest of us it is sufficient to note what you have not proven.

--
Mikko

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

Op 09.sep.2024 om 20:15 schreef olcott:

On 9/8/2024 9:44 AM, Mikko wrote:

On 2024-09-08 13:58:32 +0000, olcott said:

On 9/8/2024 4:25 AM, Mikko wrote:

On 2024-09-07 14:00:19 +0000, olcott said:

On 9/7/2024 5:19 AM, Fred. Zwarts wrote:

Op 06.sep.2024 om 13:31 schreef olcott:

On 9/6/2024 4:36 AM, Fred. Zwarts wrote:

Op 05.sep.2024 om 15:48 schreef olcott:

HHH MUST ABORT AFTER SOME FIXED NUMBER OF RECURSIVE EMULATIONS >>>>>>>>> AND THE OUTERMOST HHH ALWAYS SEE ONE MORE THAN THE NEXT INNER ONE. >>>>>>>>

And the outer one, when aborting after two cycles , misses the >>>>>>>> behaviour of the inner one in the next cycle, where the inner
one would see the 'special condition', abort, return to DDD,
which would halt as well.
That HHH misses the last part of the behaviour of the program, >>>>>>>> does not change the fact that this is the behaviour that was
coded in the program

If we have an infinite chain of people each waiting for
the next one down the line to do something then that thing
is never done.

The infinite chain exists only in your dream. In fact there are >>>>>>>> only two recursions, so never more that a chain of three HHH in >>>>>>>> the simulation.
HHH is incorrect in assuming the there is an infinite chain, but >>>>>>>> this incorrect assumption makes that it aborts and halts. This >>>>>>>> applies both to the simulating and the simulated HHH.

The way it is encoded now there are only two recursions.

If we encode it as you suggest the outermost directly
executed HHH would wait for the first emulated HHH which
would wait for the second which would wait for third
on and on...

What is olcott's problem with English?
If one way is incorrect, he thinks that it suggests that another
way must be correct.
I never suggested to change HHH, because there is *no* correct way >>>>>> to do it. Every HHH that simulates itself is incorrect. No matter
what clever code it includes.

You must be a brain dead moron.
As long as HHH emulates the sequence of instructions
it was provided then HHH is correct even if it catches
your computer on fire.

That is right. The error only occurs when HHH no longer emulates the
sequence of instructions it was provided.

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
     If simulating halt decider H correctly simulates its input D
     until H correctly determines that its simulated D would never
     stop running unless aborted then

     H can abort its simulation of D and correctly report that D
     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>

The above refers to determining that *its input D*
"specifies a non-halting sequence of configurations"
When people change this to a *non-input D* they are
trying to get away with deception.

We know except the only "people" that do so is you.

_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]

Try to show all of the details of how DDD emulated
by HHH ever reaches machine address  00002183

Sequences of machine addressed when DDD is emulated by HHH
00002172, 00002173, 00002175, 0000217a
which calls an emulated HHH(DDD).

What are the next instructions of DDD emulated by the emulated HHH ?

The instructions at 0000217f, 00002182, 00002183 and the program halt
are, among others, the ones that HHH fails to simulate, where a correct simulation (such as by HHH1 and the unmodified world class simulator)
shows that they are reachable.
But HHH fails to reach them. HHH cannot possibly simulate itself
correctly up to the end.

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

On 9/10/24 10:04 AM, olcott wrote:

On 9/10/2024 4:04 AM, Mikko wrote:

On 2024-09-09 18:15:26 +0000, olcott said:

On 9/8/2024 9:44 AM, Mikko wrote:

On 2024-09-08 13:58:32 +0000, olcott said:

On 9/8/2024 4:25 AM, Mikko wrote:

On 2024-09-07 14:00:19 +0000, olcott said:

On 9/7/2024 5:19 AM, Fred. Zwarts wrote:

Op 06.sep.2024 om 13:31 schreef olcott:

On 9/6/2024 4:36 AM, Fred. Zwarts wrote:

Op 05.sep.2024 om 15:48 schreef olcott:

HHH MUST ABORT AFTER SOME FIXED NUMBER OF RECURSIVE EMULATIONS >>>>>>>>>>> AND THE OUTERMOST HHH ALWAYS SEE ONE MORE THAN THE NEXT INNER >>>>>>>>>>> ONE.

And the outer one, when aborting after two cycles , misses the >>>>>>>>>> behaviour of the inner one in the next cycle, where the inner >>>>>>>>>> one would see the 'special condition', abort, return to DDD, >>>>>>>>>> which would halt as well.
That HHH misses the last part of the behaviour of the program, >>>>>>>>>> does not change the fact that this is the behaviour that was >>>>>>>>>> coded in the program

If we have an infinite chain of people each waiting for
the next one down the line to do something then that thing >>>>>>>>>>> is never done.

The infinite chain exists only in your dream. In fact there >>>>>>>>>> are only two recursions, so never more that a chain of three >>>>>>>>>> HHH in the simulation.
HHH is incorrect in assuming the there is an infinite chain, >>>>>>>>>> but this incorrect assumption makes that it aborts and halts. >>>>>>>>>> This applies both to the simulating and the simulated HHH.

The way it is encoded now there are only two recursions.

If we encode it as you suggest the outermost directly
executed HHH would wait for the first emulated HHH which
would wait for the second which would wait for third
on and on...

What is olcott's problem with English?
If one way is incorrect, he thinks that it suggests that another >>>>>>>> way must be correct.
I never suggested to change HHH, because there is *no* correct >>>>>>>> way to do it. Every HHH that simulates itself is incorrect. No >>>>>>>> matter what clever code it includes.

You must be a brain dead moron.
As long as HHH emulates the sequence of instructions
it was provided then HHH is correct even if it catches
your computer on fire.

That is right. The error only occurs when HHH no longer emulates the >>>>>> sequence of instructions it was provided.

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>      If simulating halt decider H correctly simulates its input D >>>>>      until H correctly determines that its simulated D would never >>>>>      stop running unless aborted then

     H can abort its simulation of D and correctly report that D >>>>>      specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>
The above refers to determining that *its input D*
"specifies a non-halting sequence of configurations"
When people change this to a *non-input D* they are
trying to get away with deception.

We know except the only "people" that do so is you.

_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]

Try to show all of the details of how DDD emulated
by HHH ever reaches machine address  00002183

It is your emulator so you need to show what needs be shown.

I am not making the false claim.
My claim in that 00002172, 00002173, 00002175, 0000217a
are emulated by the first executed emulator HHH then
HHH emulates itself emulating DDD and we get
00002172, 00002173, 00002175, 0000217a...

But that isn't what you are asked to do by the problem, or what you
solution claims.

You are claiming to be doing a correct x86 emultion of the program given
as the input, and thus you need to show HOW that second HHH did its
emulation, not the results of the emulation.

You are just making a MAJOR category error, and making yourself in to a
LIAR.

I proved this claim by showing the execution trace https://www.liarparadox.org/HHH(DDD).pdf

Which just proves that you aren't doing what you claim, perhaps becuase
ypu are too stupid to know what it is that you are claiming to do.

Disagreeing with verified facts seems to be a psychotic
break from reality to me. It is up to you to show otherwise.

No, the verified facts are that the ACTUAL correct emulation reaches the
end.

It is just your lies and fabircations that show otherwise.

For others it is sufficient to determine what HHH returns and
whether DDD halts and compare the two.

That is the fallacy of equivocation error.

No, YOU are making the equivocation error, and that is proving that you
are nothing but a LIAR.

The emulated HHH cannot possibly return and you
are trying to get away with lying about it by
changing to subject to a different HHH instance.

No, the emulated HHH most certainly returns, just only after the HHH
that is emulating it gives up.

YOU make the "equivocation" error of confounding the actual behavior of
the thing talked about (the program DDD or HHH) and the behavior of a
partial emulation of it.

Sorry, you are just proved to be an idiot.

Sequences of machine addressed when DDD is emulated by HHH
00002172, 00002173, 00002175, 0000217a
which calls an emulated HHH(DDD).

What are the next instructions of DDD emulated by the emulated HHH ?

Here, too, it is your problem to show what needs be shown.
For the rest of us it is sufficient to note what you have not proven.

When DDD calls HHH(DDD) do I need to say that DDD does not
make a milkshake? DDD does not dance the jig?

No, but you need to look at what DDD actually does, and that is more
than what the emulation by HHH of it does, since your HHH DOES abort its emulation.

Wouldn't someone that is not a liar say that when DDD calls
HHH(DDD) that HHH(DDD) would be invoked?

Yes, and *ALL* of HHH(DDD) and thus the emulation of that would show HOW HHH(DDD) does what it does, not the output that it produced.

Would you say the correct x86 emulation of:


void DDD() {
print("Starting\n");
HHH(DDD);
print("Done\n");
}

could be:

Starting
Done



No, it needs to show the instructions done, not the results generated.

Sorry, you are just proving your utter stupidity.

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

On 2024-09-10 14:04:28 +0000, olcott said:

On 9/10/2024 4:04 AM, Mikko wrote:

On 2024-09-09 18:15:26 +0000, olcott said:

On 9/8/2024 9:44 AM, Mikko wrote:

On 2024-09-08 13:58:32 +0000, olcott said:

On 9/8/2024 4:25 AM, Mikko wrote:

On 2024-09-07 14:00:19 +0000, olcott said:

On 9/7/2024 5:19 AM, Fred. Zwarts wrote:

Op 06.sep.2024 om 13:31 schreef olcott:

On 9/6/2024 4:36 AM, Fred. Zwarts wrote:

Op 05.sep.2024 om 15:48 schreef olcott:

HHH MUST ABORT AFTER SOME FIXED NUMBER OF RECURSIVE EMULATIONS >>>>>>>>>>> AND THE OUTERMOST HHH ALWAYS SEE ONE MORE THAN THE NEXT INNER ONE. >>>>>>>>>>

And the outer one, when aborting after two cycles , misses the >>>>>>>>>> behaviour of the inner one in the next cycle, where the inner one would
see the 'special condition', abort, return to DDD, which would halt as
well.
That HHH misses the last part of the behaviour of the program, does not
change the fact that this is the behaviour that was coded in the program

If we have an infinite chain of people each waiting for
the next one down the line to do something then that thing >>>>>>>>>>> is never done.

The infinite chain exists only in your dream. In fact there are only >>>>>>>>>> two recursions, so never more that a chain of three HHH in the >>>>>>>>>> simulation.
HHH is incorrect in assuming the there is an infinite chain, but this
incorrect assumption makes that it aborts and halts. This applies both
to the simulating and the simulated HHH.

The way it is encoded now there are only two recursions.

If we encode it as you suggest the outermost directly
executed HHH would wait for the first emulated HHH which
would wait for the second which would wait for third
on and on...

What is olcott's problem with English?
If one way is incorrect, he thinks that it suggests that another way >>>>>>>> must be correct.
I never suggested to change HHH, because there is *no* correct way to >>>>>>>> do it. Every HHH that simulates itself is incorrect. No matter what >>>>>>>> clever code it includes.

You must be a brain dead moron.
As long as HHH emulates the sequence of instructions
it was provided then HHH is correct even if it catches
your computer on fire.

That is right. The error only occurs when HHH no longer emulates the >>>>>> sequence of instructions it was provided.

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>      If simulating halt decider H correctly simulates its input D >>>>>      until H correctly determines that its simulated D would never >>>>>      stop running unless aborted then

     H can abort its simulation of D and correctly report that D >>>>>      specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>
The above refers to determining that *its input D*
"specifies a non-halting sequence of configurations"
When people change this to a *non-input D* they are
trying to get away with deception.

We know except the only "people" that do so is you.

_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]

Try to show all of the details of how DDD emulated
by HHH ever reaches machine address  00002183

It is your emulator so you need to show what needs be shown.

I am not making the false claim.
My claim in that 00002172, 00002173, 00002175, 0000217a
are emulated by the first executed emulator HHH then
HHH emulates itself emulating DDD and we get
00002172, 00002173, 00002175, 0000217a...

I proved this claim by showing the execution trace https://www.liarparadox.org/HHH(DDD).pdf

Disagreeing with verified facts seems to be a psychotic
break from reality to me. It is up to you to show otherwise.

For others it is sufficient to determine what HHH returns and
whether DDD halts and compare the two.

That is the fallacy of equivocation error.

No, it is exactly the thing they consider sufficient.

The emulated HHH cannot possibly return and you
are trying to get away with lying about it by
changing to subject to a different HHH instance.

Id you ara afaraid of a change of the subject then you should not
change the subject.

Sequences of machine addressed when DDD is emulated by HHH
00002172, 00002173, 00002175, 0000217a
which calls an emulated HHH(DDD).

What are the next instructions of DDD emulated by the emulated HHH ?

Here, too, it is your problem to show what needs be shown.
For the rest of us it is sufficient to note what you have not proven.

When DDD calls HHH(DDD) do I need to say that DDD does not
make a milkshake? DDD does not dance the jig?

Only if someone asks.

Wouldn't someone that is not a liar say that when DDD calls
HHH(DDD) that HHH(DDD) would be invoked?

I think someone that is not a liar has already said so.

--
Mikko

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

Op 11.sep.2024 om 14:06 schreef olcott:

On 9/10/2024 7:00 AM, Fred. Zwarts wrote:

Op 09.sep.2024 om 20:15 schreef olcott:

On 9/8/2024 9:44 AM, Mikko wrote:

On 2024-09-08 13:58:32 +0000, olcott said:

On 9/8/2024 4:25 AM, Mikko wrote:

On 2024-09-07 14:00:19 +0000, olcott said:

On 9/7/2024 5:19 AM, Fred. Zwarts wrote:

Op 06.sep.2024 om 13:31 schreef olcott:

On 9/6/2024 4:36 AM, Fred. Zwarts wrote:

Op 05.sep.2024 om 15:48 schreef olcott:

HHH MUST ABORT AFTER SOME FIXED NUMBER OF RECURSIVE EMULATIONS >>>>>>>>>>> AND THE OUTERMOST HHH ALWAYS SEE ONE MORE THAN THE NEXT INNER >>>>>>>>>>> ONE.

And the outer one, when aborting after two cycles , misses the >>>>>>>>>> behaviour of the inner one in the next cycle, where the inner >>>>>>>>>> one would see the 'special condition', abort, return to DDD, >>>>>>>>>> which would halt as well.
That HHH misses the last part of the behaviour of the program, >>>>>>>>>> does not change the fact that this is the behaviour that was >>>>>>>>>> coded in the program

If we have an infinite chain of people each waiting for
the next one down the line to do something then that thing >>>>>>>>>>> is never done.

The infinite chain exists only in your dream. In fact there >>>>>>>>>> are only two recursions, so never more that a chain of three >>>>>>>>>> HHH in the simulation.
HHH is incorrect in assuming the there is an infinite chain, >>>>>>>>>> but this incorrect assumption makes that it aborts and halts. >>>>>>>>>> This applies both to the simulating and the simulated HHH.

The way it is encoded now there are only two recursions.

If we encode it as you suggest the outermost directly
executed HHH would wait for the first emulated HHH which
would wait for the second which would wait for third
on and on...

What is olcott's problem with English?
If one way is incorrect, he thinks that it suggests that another >>>>>>>> way must be correct.
I never suggested to change HHH, because there is *no* correct >>>>>>>> way to do it. Every HHH that simulates itself is incorrect. No >>>>>>>> matter what clever code it includes.

You must be a brain dead moron.
As long as HHH emulates the sequence of instructions
it was provided then HHH is correct even if it catches
your computer on fire.

That is right. The error only occurs when HHH no longer emulates the >>>>>> sequence of instructions it was provided.

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>      If simulating halt decider H correctly simulates its input D >>>>>      until H correctly determines that its simulated D would never >>>>>      stop running unless aborted then

     H can abort its simulation of D and correctly report that D >>>>>      specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>
The above refers to determining that *its input D*
"specifies a non-halting sequence of configurations"
When people change this to a *non-input D* they are
trying to get away with deception.

We know except the only "people" that do so is you.

_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]

Try to show all of the details of how DDD emulated
by HHH ever reaches machine address  00002183

Sequences of machine addressed when DDD is emulated by HHH
00002172, 00002173, 00002175, 0000217a
which calls an emulated HHH(DDD).

What are the next instructions of DDD emulated by the emulated HHH ?

The instructions at 0000217f, 00002182, 00002183 and the program halt
are, among others, the ones that HHH fails to simulate, where a
correct simulation (such as by HHH1 and the unmodified world class
simulator) shows that they are reachable.
But HHH fails to reach them. HHH cannot possibly simulate itself
correctly up to the end.

You are too stupid to understand unreachable code.

void Infinite_Recursion()
{
  Infinite_Recursion();
  OutString("Can't possibly get here!");
}

Completely irrelevant example, because HHH aborts after two cycles. Two
is not infinite. The infinite recursion is only in your dream of the non-aborting simulator.


Olcott does not understand that

void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
printf ("Olcott thinks this is never printed.\n");
}

does not specify an infinite recursion. When he sees two cycles, he
starts to dream of an infinite recursion.

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

Op 11.sep.2024 om 13:54 schreef olcott:

On 9/10/2024 5:59 PM, Richard Damon wrote:

On 9/10/24 10:04 AM, olcott wrote:

On 9/10/2024 4:04 AM, Mikko wrote:

On 2024-09-09 18:15:26 +0000, olcott said:

On 9/8/2024 9:44 AM, Mikko wrote:

On 2024-09-08 13:58:32 +0000, olcott said:

On 9/8/2024 4:25 AM, Mikko wrote:

On 2024-09-07 14:00:19 +0000, olcott said:

On 9/7/2024 5:19 AM, Fred. Zwarts wrote:

Op 06.sep.2024 om 13:31 schreef olcott:

On 9/6/2024 4:36 AM, Fred. Zwarts wrote:

Op 05.sep.2024 om 15:48 schreef olcott:

HHH MUST ABORT AFTER SOME FIXED NUMBER OF RECURSIVE EMULATIONS >>>>>>>>>>>>> AND THE OUTERMOST HHH ALWAYS SEE ONE MORE THAN THE NEXT >>>>>>>>>>>>> INNER ONE.

And the outer one, when aborting after two cycles , misses >>>>>>>>>>>> the behaviour of the inner one in the next cycle, where the >>>>>>>>>>>> inner one would see the 'special condition', abort, return >>>>>>>>>>>> to DDD, which would halt as well.
That HHH misses the last part of the behaviour of the
program, does not change the fact that this is the behaviour >>>>>>>>>>>> that was coded in the program

If we have an infinite chain of people each waiting for >>>>>>>>>>>>> the next one down the line to do something then that thing >>>>>>>>>>>>> is never done.

The infinite chain exists only in your dream. In fact there >>>>>>>>>>>> are only two recursions, so never more that a chain of three >>>>>>>>>>>> HHH in the simulation.
HHH is incorrect in assuming the there is an infinite chain, >>>>>>>>>>>> but this incorrect assumption makes that it aborts and >>>>>>>>>>>> halts. This applies both to the simulating and the simulated >>>>>>>>>>>> HHH.

The way it is encoded now there are only two recursions. >>>>>>>>>>>
If we encode it as you suggest the outermost directly
executed HHH would wait for the first emulated HHH which >>>>>>>>>>> would wait for the second which would wait for third
on and on...

What is olcott's problem with English?
If one way is incorrect, he thinks that it suggests that
another way must be correct.
I never suggested to change HHH, because there is *no* correct >>>>>>>>>> way to do it. Every HHH that simulates itself is incorrect. No >>>>>>>>>> matter what clever code it includes.

You must be a brain dead moron.
As long as HHH emulates the sequence of instructions
it was provided then HHH is correct even if it catches
your computer on fire.

That is right. The error only occurs when HHH no longer emulates >>>>>>>> the
sequence of instructions it was provided.

<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
     If simulating halt decider H correctly simulates its input D >>>>>>>      until H correctly determines that its simulated D would never >>>>>>>      stop running unless aborted then

     H can abort its simulation of D and correctly report that D >>>>>>>      specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>

The above refers to determining that *its input D*
"specifies a non-halting sequence of configurations"
When people change this to a *non-input D* they are
trying to get away with deception.

We know except the only "people" that do so is you.

_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]

Try to show all of the details of how DDD emulated
by HHH ever reaches machine address  00002183

It is your emulator so you need to show what needs be shown.

I am not making the false claim.
My claim in that 00002172, 00002173, 00002175, 0000217a
are emulated by the first executed emulator HHH then
HHH emulates itself emulating DDD and we get
00002172, 00002173, 00002175, 0000217a...

But that isn't what you are asked to do by the problem, or what you
solution claims.

The problem is what behavior does the input specify?

That is clear. The finite string that is the input specifies a halting
program. Proven by direct execution, by the simulation by the world
class simulator and even by HHH1.

Only brain dead morons or despicable liars would think
that they can the away with simply ignoring the fact
that DDD its own emulator.

When I say that HHH cannot possibly simulate itself correctly up to the
end, I do not ignore that HHH simulates itself.
But olcott thinks, ignoring the overwhelming evidence, that the fact
that HHH stops the simulation before it reaches the end, proves that the simulation does not halt.


-

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

On 9/11/24 8:06 AM, olcott wrote:

On 9/10/2024 7:00 AM, Fred. Zwarts wrote:

Op 09.sep.2024 om 20:15 schreef olcott:

On 9/8/2024 9:44 AM, Mikko wrote:

On 2024-09-08 13:58:32 +0000, olcott said:

On 9/8/2024 4:25 AM, Mikko wrote:

On 2024-09-07 14:00:19 +0000, olcott said:

On 9/7/2024 5:19 AM, Fred. Zwarts wrote:

Op 06.sep.2024 om 13:31 schreef olcott:

On 9/6/2024 4:36 AM, Fred. Zwarts wrote:

Op 05.sep.2024 om 15:48 schreef olcott:

HHH MUST ABORT AFTER SOME FIXED NUMBER OF RECURSIVE EMULATIONS >>>>>>>>>>> AND THE OUTERMOST HHH ALWAYS SEE ONE MORE THAN THE NEXT INNER >>>>>>>>>>> ONE.

And the outer one, when aborting after two cycles , misses the >>>>>>>>>> behaviour of the inner one in the next cycle, where the inner >>>>>>>>>> one would see the 'special condition', abort, return to DDD, >>>>>>>>>> which would halt as well.
That HHH misses the last part of the behaviour of the program, >>>>>>>>>> does not change the fact that this is the behaviour that was >>>>>>>>>> coded in the program

If we have an infinite chain of people each waiting for
the next one down the line to do something then that thing >>>>>>>>>>> is never done.

The infinite chain exists only in your dream. In fact there >>>>>>>>>> are only two recursions, so never more that a chain of three >>>>>>>>>> HHH in the simulation.
HHH is incorrect in assuming the there is an infinite chain, >>>>>>>>>> but this incorrect assumption makes that it aborts and halts. >>>>>>>>>> This applies both to the simulating and the simulated HHH.

The way it is encoded now there are only two recursions.

If we encode it as you suggest the outermost directly
executed HHH would wait for the first emulated HHH which
would wait for the second which would wait for third
on and on...

What is olcott's problem with English?
If one way is incorrect, he thinks that it suggests that another >>>>>>>> way must be correct.
I never suggested to change HHH, because there is *no* correct >>>>>>>> way to do it. Every HHH that simulates itself is incorrect. No >>>>>>>> matter what clever code it includes.

You must be a brain dead moron.
As long as HHH emulates the sequence of instructions
it was provided then HHH is correct even if it catches
your computer on fire.

That is right. The error only occurs when HHH no longer emulates the >>>>>> sequence of instructions it was provided.

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>      If simulating halt decider H correctly simulates its input D >>>>>      until H correctly determines that its simulated D would never >>>>>      stop running unless aborted then

     H can abort its simulation of D and correctly report that D >>>>>      specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>
The above refers to determining that *its input D*
"specifies a non-halting sequence of configurations"
When people change this to a *non-input D* they are
trying to get away with deception.

We know except the only "people" that do so is you.

_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]

Try to show all of the details of how DDD emulated
by HHH ever reaches machine address  00002183

Sequences of machine addressed when DDD is emulated by HHH
00002172, 00002173, 00002175, 0000217a
which calls an emulated HHH(DDD).

What are the next instructions of DDD emulated by the emulated HHH ?

The instructions at 0000217f, 00002182, 00002183 and the program halt
are, among others, the ones that HHH fails to simulate, where a
correct simulation (such as by HHH1 and the unmodified world class
simulator) shows that they are reachable.
But HHH fails to reach them. HHH cannot possibly simulate itself
correctly up to the end.

You are too stupid to understand unreachable code.

void Infinite_Recursion()
{
  Infinite_Recursion();
  OutString("Can't possibly get here!");
}

And you are too stupid to understand the fallacy of bad analogies.

The fact that is seems you just live on lies is a likely cause of this.

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

On 9/11/24 7:54 AM, olcott wrote:

On 9/10/2024 5:59 PM, Richard Damon wrote:

On 9/10/24 10:04 AM, olcott wrote:

On 9/10/2024 4:04 AM, Mikko wrote:

On 2024-09-09 18:15:26 +0000, olcott said:

On 9/8/2024 9:44 AM, Mikko wrote:

On 2024-09-08 13:58:32 +0000, olcott said:

On 9/8/2024 4:25 AM, Mikko wrote:

On 2024-09-07 14:00:19 +0000, olcott said:

On 9/7/2024 5:19 AM, Fred. Zwarts wrote:

Op 06.sep.2024 om 13:31 schreef olcott:

On 9/6/2024 4:36 AM, Fred. Zwarts wrote:

Op 05.sep.2024 om 15:48 schreef olcott:

HHH MUST ABORT AFTER SOME FIXED NUMBER OF RECURSIVE EMULATIONS >>>>>>>>>>>>> AND THE OUTERMOST HHH ALWAYS SEE ONE MORE THAN THE NEXT >>>>>>>>>>>>> INNER ONE.

And the outer one, when aborting after two cycles , misses >>>>>>>>>>>> the behaviour of the inner one in the next cycle, where the >>>>>>>>>>>> inner one would see the 'special condition', abort, return >>>>>>>>>>>> to DDD, which would halt as well.
That HHH misses the last part of the behaviour of the
program, does not change the fact that this is the behaviour >>>>>>>>>>>> that was coded in the program

If we have an infinite chain of people each waiting for >>>>>>>>>>>>> the next one down the line to do something then that thing >>>>>>>>>>>>> is never done.

The infinite chain exists only in your dream. In fact there >>>>>>>>>>>> are only two recursions, so never more that a chain of three >>>>>>>>>>>> HHH in the simulation.
HHH is incorrect in assuming the there is an infinite chain, >>>>>>>>>>>> but this incorrect assumption makes that it aborts and >>>>>>>>>>>> halts. This applies both to the simulating and the simulated >>>>>>>>>>>> HHH.

The way it is encoded now there are only two recursions. >>>>>>>>>>>
If we encode it as you suggest the outermost directly
executed HHH would wait for the first emulated HHH which >>>>>>>>>>> would wait for the second which would wait for third
on and on...

What is olcott's problem with English?
If one way is incorrect, he thinks that it suggests that
another way must be correct.
I never suggested to change HHH, because there is *no* correct >>>>>>>>>> way to do it. Every HHH that simulates itself is incorrect. No >>>>>>>>>> matter what clever code it includes.

You must be a brain dead moron.
As long as HHH emulates the sequence of instructions
it was provided then HHH is correct even if it catches
your computer on fire.

That is right. The error only occurs when HHH no longer emulates >>>>>>>> the
sequence of instructions it was provided.

<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
     If simulating halt decider H correctly simulates its input D >>>>>>>      until H correctly determines that its simulated D would never >>>>>>>      stop running unless aborted then

     H can abort its simulation of D and correctly report that D >>>>>>>      specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>

The above refers to determining that *its input D*
"specifies a non-halting sequence of configurations"
When people change this to a *non-input D* they are
trying to get away with deception.

We know except the only "people" that do so is you.

_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]

Try to show all of the details of how DDD emulated
by HHH ever reaches machine address  00002183

It is your emulator so you need to show what needs be shown.

I am not making the false claim.
My claim in that 00002172, 00002173, 00002175, 0000217a
are emulated by the first executed emulator HHH then
HHH emulates itself emulating DDD and we get
00002172, 00002173, 00002175, 0000217a...

But that isn't what you are asked to do by the problem, or what you
solution claims.

The problem is what behavior does the input specify?
Only brain dead morons or despicable liars would think
that they can the away with simply ignoring the fact
that DDD its own emulator.

Nope, only a despicable liar would ignore the problem DEFINITION, that
the behavior of the input it the behavior of the direct execution of the program the input repesents.

Note specifically, the definition talk NOTHING about the emulation done
by the decider, because that just doesn't matter, except as a possible
way for the decider to try to determine the answer if it can (but it
turns out not to actually help that much for this input).

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