On 2022-04-22 20:54, olcott wrote:
> On 4/22/2022 4:42 PM, André G. Isaak wrote:
>> On 2022-04-22 14:58, olcott wrote:
>>> On 4/22/2022 3:42 PM, André G. Isaak wrote:
>>>> On 2022-04-22 14:09, olcott wrote:
>>>>> On 4/22/2022 2:37 PM, Ben wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/21/2022 8:23 PM, Ben wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/21/2022 6:10 PM, Ben wrote:
>>>>>>>>
>>>>>>>>>> Still, I expect there's a few years more chatting to be done
>>>>>>>>>> before you
>>>>>>>>>> get to an editor's day.
>>>>>>>>>>
>>>>>>>>> People here have gotten the conventional halting problem dogma so
>>>>>>>>> ingrained in their psyche that they believe that even when it is
>>>>>>>>> proven to be a verified fact that the input to H(P,P) specifies a
>>>>>>>>> non-halting sequence of configurations it is somehow incorrect
>>>>>>>>> for H
>>>>>>>>> to report this.
>>>>>>>>
>>>>>>>> H(P,P) == false is wrong because P(P) halts.  The problem of
>>>>>>>> exhibiting
>>>>>>>> an H such that H(X,Y) == false if, and only if, X(Y) does not
>>>>>>>> halt has
>>>>>>>> not gone away.  It's called the halting problem.  There are famous
>>>>>>>> theorems about it.  At one time you were interested in
>>>>>>>> addressing it.
>>>>>>>
>>>>>>> If the correctly simulated input to H(P,P) specifies a non-halting
>>>>>>> sequence of configurations on the basis of its actual behavior then
>>>>>>> this actual behavior supersedes and overrules anything any
>>>>>>> everything
>>>>>>> else that disagrees.
>>>>>>
>>>>>> The halting problem is about H(P,P) being right about P(P), not about
>>>>>> anything else you might find to waffle about.
>>>>>
>>>>> The halting problem *is not* about P(P) when P(P) is not
>>>>> computationally equivalent to the correct simulation of the input
>>>>> to H(P,P).
>>>>
>>>> This is simply an ignorant statement. Rather, it was initially an
>>>> ignorant statement but since there have been many attempts made to
>>>> remedy your ignorance, it has since graduated to a
>>>> willfully-ignorant-grasping-at-straws-statement.
>>>>
>>>> A halt decider is a Turing Machine which computes the halting
>>>> *function*.
>>>>
>>>> The halting function is a mathematical function. it is not defined
>>>> in terms of 'inputs' or 'simulators'. It is not defined in terms of
>>>> halt deciders at all since a function is logically prior to any
>>>> algorithm for computing that function.
>>>>
>>>> The halting *function* is simply a mathematical mapping from
>>>> computations to {yes, no} based on whether they halt.
>>>>
>>>
>>> No. A decider computes the mapping from (finite string) inputs to an
>>> accept or reject state.
>>
>> I was defining the halting *function*. That is an entirely different
>> animal from a halt *decider*. Do you still not grasp the distinction
>> between a Turing Machine and the function which it computes?
>
> So the halt decider computes the halting *function* on some other basis
> than what its input actually specifies (What is it a mind reader?)
> You really don't think these things through do you?

The halting *function* is defined entirely independently of any halt
decider or computer program. It maps computations to yes or no based on
whether they halt.

Whether it is possible to design a Turing Machine or program which
actually computes this function, or whether it is possible to encode
elements of the domain of the halting function in a way which allows
them to even be passed as inputs to such a Turing Machine or program are
entirely separate questions.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 4/22/2022 10:06 PM, André G. Isaak wrote:
> On 2022-04-22 20:54, olcott wrote:
>> On 4/22/2022 4:42 PM, André G. Isaak wrote:
>>> On 2022-04-22 14:58, olcott wrote:
>>>> On 4/22/2022 3:42 PM, André G. Isaak wrote:
>>>>> On 2022-04-22 14:09, olcott wrote:
>>>>>> On 4/22/2022 2:37 PM, Ben wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/21/2022 8:23 PM, Ben wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/21/2022 6:10 PM, Ben wrote:
>>>>>>>>>
>>>>>>>>>>> Still, I expect there's a few years more chatting to be done
>>>>>>>>>>> before you
>>>>>>>>>>> get to an editor's day.
>>>>>>>>>>>
>>>>>>>>>> People here have gotten the conventional halting problem dogma so
>>>>>>>>>> ingrained in their psyche that they believe that even when it is
>>>>>>>>>> proven to be a verified fact that the input to H(P,P) specifies a
>>>>>>>>>> non-halting sequence of configurations it is somehow incorrect
>>>>>>>>>> for H
>>>>>>>>>> to report this.
>>>>>>>>>
>>>>>>>>> H(P,P) == false is wrong because P(P) halts.  The problem of
>>>>>>>>> exhibiting
>>>>>>>>> an H such that H(X,Y) == false if, and only if, X(Y) does not
>>>>>>>>> halt has
>>>>>>>>> not gone away.  It's called the halting problem.  There are famous
>>>>>>>>> theorems about it.  At one time you were interested in
>>>>>>>>> addressing it.
>>>>>>>>
>>>>>>>> If the correctly simulated input to H(P,P) specifies a non-halting
>>>>>>>> sequence of configurations on the basis of its actual behavior then
>>>>>>>> this actual behavior supersedes and overrules anything any
>>>>>>>> everything
>>>>>>>> else that disagrees.
>>>>>>>
>>>>>>> The halting problem is about H(P,P) being right about P(P), not
>>>>>>> about
>>>>>>> anything else you might find to waffle about.
>>>>>>
>>>>>> The halting problem *is not* about P(P) when P(P) is not
>>>>>> computationally equivalent to the correct simulation of the input
>>>>>> to H(P,P).
>>>>>
>>>>> This is simply an ignorant statement. Rather, it was initially an
>>>>> ignorant statement but since there have been many attempts made to
>>>>> remedy your ignorance, it has since graduated to a
>>>>> willfully-ignorant-grasping-at-straws-statement.
>>>>>
>>>>> A halt decider is a Turing Machine which computes the halting
>>>>> *function*.
>>>>>
>>>>> The halting function is a mathematical function. it is not defined
>>>>> in terms of 'inputs' or 'simulators'. It is not defined in terms of
>>>>> halt deciders at all since a function is logically prior to any
>>>>> algorithm for computing that function.
>>>>>
>>>>> The halting *function* is simply a mathematical mapping from
>>>>> computations to {yes, no} based on whether they halt.
>>>>>
>>>>
>>>> No. A decider computes the mapping from (finite string) inputs to an
>>>> accept or reject state.
>>>
>>> I was defining the halting *function*. That is an entirely different
>>> animal from a halt *decider*. Do you still not grasp the distinction
>>> between a Turing Machine and the function which it computes?
>>
>> So the halt decider computes the halting *function* on some other
>> basis than what its input actually specifies (What is it a mind reader?)
>> You really don't think these things through do you?
>
> The halting *function* is defined entirely independently of any halt
> decider or computer program. It maps computations to yes or no based on
> whether they halt.
>

Yet this must be communicated (encoded in some form) to the TM that
computes this function.

You continue to believe that the halt decider is a mind reader.

It is an easily verified fact that the correctly simulated input to
H(P,P) specifies a non-halting sequence of configurations, therefore H
is correct to reject its input.

> Whether it is possible to design a Turing Machine or program which
> actually computes this function, or whether it is possible to encode
> elements of the domain of the halting function in a way which allows
> them to even be passed as inputs to such a Turing Machine or program are
> entirely separate questions.
>
> André
>

You are dodging the key point that H(P,P)==0 is correct.

--
Copyright 2022 Pete Olcott

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

On 4/22/2022 10:06 PM, André G. Isaak wrote:
> On 2022-04-22 20:54, olcott wrote:
>> On 4/22/2022 4:42 PM, André G. Isaak wrote:
>>> On 2022-04-22 14:58, olcott wrote:
>>>> On 4/22/2022 3:42 PM, André G. Isaak wrote:
>>>>> On 2022-04-22 14:09, olcott wrote:
>>>>>> On 4/22/2022 2:37 PM, Ben wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/21/2022 8:23 PM, Ben wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/21/2022 6:10 PM, Ben wrote:
>>>>>>>>>
>>>>>>>>>>> Still, I expect there's a few years more chatting to be done
>>>>>>>>>>> before you
>>>>>>>>>>> get to an editor's day.
>>>>>>>>>>>
>>>>>>>>>> People here have gotten the conventional halting problem dogma so
>>>>>>>>>> ingrained in their psyche that they believe that even when it is
>>>>>>>>>> proven to be a verified fact that the input to H(P,P) specifies a
>>>>>>>>>> non-halting sequence of configurations it is somehow incorrect
>>>>>>>>>> for H
>>>>>>>>>> to report this.
>>>>>>>>>
>>>>>>>>> H(P,P) == false is wrong because P(P) halts.  The problem of
>>>>>>>>> exhibiting
>>>>>>>>> an H such that H(X,Y) == false if, and only if, X(Y) does not
>>>>>>>>> halt has
>>>>>>>>> not gone away.  It's called the halting problem.  There are famous
>>>>>>>>> theorems about it.  At one time you were interested in
>>>>>>>>> addressing it.
>>>>>>>>
>>>>>>>> If the correctly simulated input to H(P,P) specifies a non-halting
>>>>>>>> sequence of configurations on the basis of its actual behavior then
>>>>>>>> this actual behavior supersedes and overrules anything any
>>>>>>>> everything
>>>>>>>> else that disagrees.
>>>>>>>
>>>>>>> The halting problem is about H(P,P) being right about P(P), not
>>>>>>> about
>>>>>>> anything else you might find to waffle about.
>>>>>>
>>>>>> The halting problem *is not* about P(P) when P(P) is not
>>>>>> computationally equivalent to the correct simulation of the input
>>>>>> to H(P,P).
>>>>>
>>>>> This is simply an ignorant statement. Rather, it was initially an
>>>>> ignorant statement but since there have been many attempts made to
>>>>> remedy your ignorance, it has since graduated to a
>>>>> willfully-ignorant-grasping-at-straws-statement.
>>>>>
>>>>> A halt decider is a Turing Machine which computes the halting
>>>>> *function*.
>>>>>
>>>>> The halting function is a mathematical function. it is not defined
>>>>> in terms of 'inputs' or 'simulators'. It is not defined in terms of
>>>>> halt deciders at all since a function is logically prior to any
>>>>> algorithm for computing that function.
>>>>>
>>>>> The halting *function* is simply a mathematical mapping from
>>>>> computations to {yes, no} based on whether they halt.
>>>>>
>>>>
>>>> No. A decider computes the mapping from (finite string) inputs to an
>>>> accept or reject state.
>>>
>>> I was defining the halting *function*. That is an entirely different
>>> animal from a halt *decider*. Do you still not grasp the distinction
>>> between a Turing Machine and the function which it computes?
>>
>> So the halt decider computes the halting *function* on some other
>> basis than what its input actually specifies (What is it a mind reader?)
>> You really don't think these things through do you?
>
> The halting *function* is defined entirely independently of any halt
> decider or computer program. It maps computations to yes or no based on
> whether they halt.
>

A halt decider must only compute the halt status that is specified by
its actual input.

If some element of the domain cannot be encoded as a finite string then
this element is a mere vague idea lacking a specific definition.

> Whether it is possible to design a Turing Machine or program which
> actually computes this function, or whether it is possible to encode
> elements of the domain of the halting function in a way which allows
> them to even be passed as inputs to such a Turing Machine or program are
> entirely separate questions.
>
> André
>

--
Copyright 2022 Pete Olcott

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

On 4/23/22 12:33 AM, olcott wrote:
> On 4/22/2022 10:06 PM, André G. Isaak wrote:
>> On 2022-04-22 20:54, olcott wrote:
>>> On 4/22/2022 4:42 PM, André G. Isaak wrote:
>>>> On 2022-04-22 14:58, olcott wrote:
>>>>> On 4/22/2022 3:42 PM, André G. Isaak wrote:
>>>>>> On 2022-04-22 14:09, olcott wrote:
>>>>>>> On 4/22/2022 2:37 PM, Ben wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/21/2022 8:23 PM, Ben wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/21/2022 6:10 PM, Ben wrote:
>>>>>>>>>>
>>>>>>>>>>>> Still, I expect there's a few years more chatting to be done
>>>>>>>>>>>> before you
>>>>>>>>>>>> get to an editor's day.
>>>>>>>>>>>>
>>>>>>>>>>> People here have gotten the conventional halting problem
>>>>>>>>>>> dogma so
>>>>>>>>>>> ingrained in their psyche that they believe that even when it is
>>>>>>>>>>> proven to be a verified fact that the input to H(P,P)
>>>>>>>>>>> specifies a
>>>>>>>>>>> non-halting sequence of configurations it is somehow
>>>>>>>>>>> incorrect for H
>>>>>>>>>>> to report this.
>>>>>>>>>>
>>>>>>>>>> H(P,P) == false is wrong because P(P) halts.  The problem of
>>>>>>>>>> exhibiting
>>>>>>>>>> an H such that H(X,Y) == false if, and only if, X(Y) does not
>>>>>>>>>> halt has
>>>>>>>>>> not gone away.  It's called the halting problem.  There are
>>>>>>>>>> famous
>>>>>>>>>> theorems about it.  At one time you were interested in
>>>>>>>>>> addressing it.
>>>>>>>>>
>>>>>>>>> If the correctly simulated input to H(P,P) specifies a non-halting
>>>>>>>>> sequence of configurations on the basis of its actual behavior
>>>>>>>>> then
>>>>>>>>> this actual behavior supersedes and overrules anything any
>>>>>>>>> everything
>>>>>>>>> else that disagrees.
>>>>>>>>
>>>>>>>> The halting problem is about H(P,P) being right about P(P), not
>>>>>>>> about
>>>>>>>> anything else you might find to waffle about.
>>>>>>>
>>>>>>> The halting problem *is not* about P(P) when P(P) is not
>>>>>>> computationally equivalent to the correct simulation of the input
>>>>>>> to H(P,P).
>>>>>>
>>>>>> This is simply an ignorant statement. Rather, it was initially an
>>>>>> ignorant statement but since there have been many attempts made to
>>>>>> remedy your ignorance, it has since graduated to a
>>>>>> willfully-ignorant-grasping-at-straws-statement.
>>>>>>
>>>>>> A halt decider is a Turing Machine which computes the halting
>>>>>> *function*.
>>>>>>
>>>>>> The halting function is a mathematical function. it is not defined
>>>>>> in terms of 'inputs' or 'simulators'. It is not defined in terms
>>>>>> of halt deciders at all since a function is logically prior to any
>>>>>> algorithm for computing that function.
>>>>>>
>>>>>> The halting *function* is simply a mathematical mapping from
>>>>>> computations to {yes, no} based on whether they halt.
>>>>>>
>>>>>
>>>>> No. A decider computes the mapping from (finite string) inputs to
>>>>> an accept or reject state.
>>>>
>>>> I was defining the halting *function*. That is an entirely different
>>>> animal from a halt *decider*. Do you still not grasp the distinction
>>>> between a Turing Machine and the function which it computes?
>>>
>>> So the halt decider computes the halting *function* on some other
>>> basis than what its input actually specifies (What is it a mind reader?)
>>> You really don't think these things through do you?
>>
>> The halting *function* is defined entirely independently of any halt
>> decider or computer program. It maps computations to yes or no based
>> on whether they halt.
>>
>
> A halt decider must only compute the halt status that is specified by
> its actual input.

Right, but the DEFINITION of the halt status of the input <M> w is
DEFINED as whether or not M applied to w will halt.

The fact tha this behavior isn't computable by a finite set of
manipulations of this string is what makes the function un-computable,
not that it makes is an incorrect definition of a mapping.

You confuse possible with allowed. It is impossible for a Decider to
figure out if the actual computation will halt (in some cases), but
there is no issue with asking it to do so by defining the Function it
must compute by that. All this means is that this function is not
computable, and no such machine exists.

You seem to have trouble with this sort of thing, perhaps a limitation
in your ability to think abstractly.

>
> If some element of the domain cannot be encoded as a finite string then
> this element is a mere vague idea lacking a specific definition.

And All Turing Machines, once defined, can be encoded as a Finite
string, in fact any given Turing Machine can be encoded in MANY
different finite string.

>
>> Whether it is possible to design a Turing Machine or program which
>> actually computes this function, or whether it is possible to encode
>> elements of the domain of the halting function in a way which allows
>> them to even be passed as inputs to such a Turing Machine or program
>> are entirely separate questions.
>>
>> André
>>
>
>

On 4/22/2022 10:06 PM, André G. Isaak wrote:
> On 2022-04-22 20:54, olcott wrote:
>> On 4/22/2022 4:42 PM, André G. Isaak wrote:
>>> On 2022-04-22 14:58, olcott wrote:
>>>> On 4/22/2022 3:42 PM, André G. Isaak wrote:
>>>>> On 2022-04-22 14:09, olcott wrote:
>>>>>> On 4/22/2022 2:37 PM, Ben wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/21/2022 8:23 PM, Ben wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/21/2022 6:10 PM, Ben wrote:
>>>>>>>>>
>>>>>>>>>>> Still, I expect there's a few years more chatting to be done
>>>>>>>>>>> before you
>>>>>>>>>>> get to an editor's day.
>>>>>>>>>>>
>>>>>>>>>> People here have gotten the conventional halting problem dogma so
>>>>>>>>>> ingrained in their psyche that they believe that even when it is
>>>>>>>>>> proven to be a verified fact that the input to H(P,P) specifies a
>>>>>>>>>> non-halting sequence of configurations it is somehow incorrect
>>>>>>>>>> for H
>>>>>>>>>> to report this.
>>>>>>>>>
>>>>>>>>> H(P,P) == false is wrong because P(P) halts.  The problem of
>>>>>>>>> exhibiting
>>>>>>>>> an H such that H(X,Y) == false if, and only if, X(Y) does not
>>>>>>>>> halt has
>>>>>>>>> not gone away.  It's called the halting problem.  There are famous
>>>>>>>>> theorems about it.  At one time you were interested in
>>>>>>>>> addressing it.
>>>>>>>>
>>>>>>>> If the correctly simulated input to H(P,P) specifies a non-halting
>>>>>>>> sequence of configurations on the basis of its actual behavior then
>>>>>>>> this actual behavior supersedes and overrules anything any
>>>>>>>> everything
>>>>>>>> else that disagrees.
>>>>>>>
>>>>>>> The halting problem is about H(P,P) being right about P(P), not
>>>>>>> about
>>>>>>> anything else you might find to waffle about.
>>>>>>
>>>>>> The halting problem *is not* about P(P) when P(P) is not
>>>>>> computationally equivalent to the correct simulation of the input
>>>>>> to H(P,P).
>>>>>
>>>>> This is simply an ignorant statement. Rather, it was initially an
>>>>> ignorant statement but since there have been many attempts made to
>>>>> remedy your ignorance, it has since graduated to a
>>>>> willfully-ignorant-grasping-at-straws-statement.
>>>>>
>>>>> A halt decider is a Turing Machine which computes the halting
>>>>> *function*.
>>>>>
>>>>> The halting function is a mathematical function. it is not defined
>>>>> in terms of 'inputs' or 'simulators'. It is not defined in terms of
>>>>> halt deciders at all since a function is logically prior to any
>>>>> algorithm for computing that function.
>>>>>
>>>>> The halting *function* is simply a mathematical mapping from
>>>>> computations to {yes, no} based on whether they halt.
>>>>>
>>>>
>>>> No. A decider computes the mapping from (finite string) inputs to an
>>>> accept or reject state.
>>>
>>> I was defining the halting *function*. That is an entirely different
>>> animal from a halt *decider*. Do you still not grasp the distinction
>>> between a Turing Machine and the function which it computes?
>>
>> So the halt decider computes the halting *function* on some other
>> basis than what its input actually specifies (What is it a mind reader?)
>> You really don't think these things through do you?
>
> The halting *function* is defined entirely independently of any halt
> decider or computer program. It maps computations to yes or no based on
> whether they halt.
>
> Whether it is possible to design a Turing Machine or program which
> actually computes this function, or whether it is possible to encode
> elements of the domain of the halting function in a way which allows
> them to even be passed as inputs to such a Turing Machine or program are
> entirely separate questions.
>
> André
>

None-the-less H(P,P) does correctly compute the mapping from its inputs
to its own reject state therefore H(P,P) correctly decides the halt
status of the halting problem's "impossible" input.

Anyone that is an expert in the C programming language, the x86
programming language, exactly how C translates into x86 and what an x86
processor emulator is can easily verify that the correctly simulated
input to H(P,P) by H specifies a non-halting sequence of configurations.

All of my reviewers expect H(P,P) to compute the halt status of P(P),
yet the behavior specified by the input to H(P,P) is not the same as the
behavior specified by P(P).

Since my reviewers expect the halt decider to compute the halt status of
P(P) yet the input to H(P,P) specifies a different halt status my
reviewers expect H to read their mind so that it can compute different
behavior than the behavior that the input actually specifies.

Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

--
Copyright 2022 Pete Olcott

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

On 4/22/22 7:07 PM, olcott wrote:
> On 4/22/2022 6:00 PM, Malcolm McLean wrote:
>> On Friday, 22 April 2022 at 19:52:06 UTC+1, Ben wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> This is clearer:
>>>> With H(P,P) H is invoked before P(P) is simulated.
>>>> With P(P) P is invoked before H(P,P) is invoked.
>>>>
>>>> Because H and P are invoked in a different order this changes their
>>>> behavior.
>>> Everyone has been quite sure that this is the trick you have been trying
>>> to pull ever since you flatly denied it to Mike Terry more than three
>>> years ago. What's puzzling is why you don't use this trick to have H
>>> return the correct answer!
>>>
>> You assume bad faith. But since PO admits that P(P) halts whilst H(P,P)
>> reports non-halting, the obvious explantion is that he is posting in good
>> faith.
>> You have an x86 emulator. You modify it with infinite cycle detection
>> logic,
>> and create a reasonably accurate halt decider. But of course it chokes on
>> H_Hat<H_Hat>as it must do.
>
> It does not freaking choke, look at the actual execution of the code.

So, giving the WRONG answer by deciding to abort an input that is going
to halt is not choking?

>
> Completely rewritten today, focusing on a software engineering target
> audience: *Halting problem undecidability and infinitely nested
> simulation* (V5)
>
> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

Same old problems.

If the "input" to H(P,P) doesn't represent the computation P(P), then
what input does, i.e., how do you ask that qustion, and what computation
does that input represent?

Since P(P) does return, the correct answer for H(P,P) needs to be 1, not 0.

You aren't defining a "Halt Decider", but using an INCORRECT simulation
to determine an INCORRECT answer.
>
>
>> However if you are not very well educated in thse matters, you might
>> examine
>> H for errors. And it's not obvious where the error is. The infinite
>> cycle detection
>> logic holds up in the vast majority of cases, after all. And the code
>> is quite
>> complicated.
>
>> It's easy to see how someone could declare that they see no error in the
>> processing of H_Hat<H_Hat>. But in fact it halts, whilst H classifies it
>> as non-halting. Now here, it is true, it takes a certain obtuseness
>> not to
>> draw the obvious conclusion. But if you insist that the infinite cycle
>> detecction
>> code is correct, then you are reduced to the absurdity of saying it is
>> correct
>> whilst your own run produces the opposite result.
>
> It is not an absurdity P(P) and the correct simulation of the input to
> H(P,P) are not computationally equivalent even though intuition really
> seems to say that they must be computationally equivalent. It is a
> verifiable fact that they are not computationally equivalent.
>
>

Then you aren't using a correct defintion of correct simulation, or what
the halt decider is supposed to be doing.

IF H(P,P) is NOT asking about P(P), then, what is it asking about, and
what input do you need to give to ask about P(P).

Note, everything works out when you remember that a "Correct Simulation"
of an input needs to represent the exact behavior of the program the
input represents, and thus must never 'abort'.

On 4/22/22 3:47 PM, olcott wrote:
> On 4/22/2022 1:49 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> It does not matter at all that P(P) halts when we have proven that the
>>> input to H(P,P) specifies a non-halting sequence of configurations.
>>
>> The halting problem -- a function D such that D(X,Y) returns true iff
>> X(Y) halts and false otherwise -- does not go away just because you
>> decide to address some other question, even if it sounds superficially a
>> bit similar.
>>
>
> This is merely a very persistent {learned by rote from the book}
> misunderstanding of the actual halting problem definition.
>
> It has always been the case that the halt decider must compute the
> mapping from its input finite strings to its own accept or reject state
> on the basis of whether this input specifies a halting computation or a
> non-halting sequence of configurations.
>
> The direct execution of P(P) has different behavior than the correct
> simulation of the input to H(P,P), thus it is the actual behavior of the
> actual input that is the ultimate measure of the actual behavior of the
> actual input.

And what is your definition of a "Correct Simulation" that allows for
your result.

The classical definition of a "Correct Simulation" is that it must
recreate the actual behavior of that which is being simulated.

Thus Sim(P,P) will be exactly the same result as P(P).

>
> It can be verified that the input to H(P,P) is simulated correctly
> entirely on the basis of the x86 source code for P, the x86 execution
> trace of P by H, and the definition of H that it only simulates its
> input until it sees the same infinitely repeating pattern that we can
> all see in this same execution trace.

Nope, it shows that H is using an incorrect infinitely repeating
pattern, as the pattern it is using causes P to Halt when actually run
or correctly simulated, and thus not infinitily repeating.

>
> That no one here knows the x86 language well enough to confirm the fact
> (besides me) that the input to H(P,P) really does specify a non-halting
> sequence of configurations provides less that no basis what-so-ever to
> rebut this fact.
>

FLAT LIE.

On 4/22/22 4:09 PM, olcott wrote:
> On 4/22/2022 2:37 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/21/2022 8:23 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/21/2022 6:10 PM, Ben wrote:
>>>>
>>>>>> Still, I expect there's a few years more chatting to be done
>>>>>> before you
>>>>>> get to an editor's day.
>>>>>>
>>>>> People here have gotten the conventional halting problem dogma so
>>>>> ingrained in their psyche that they believe that even when it is
>>>>> proven to be a verified fact that the input to H(P,P) specifies a
>>>>> non-halting sequence of configurations it is somehow incorrect for H
>>>>> to report this.
>>>>
>>>> H(P,P) == false is wrong because P(P) halts.  The problem of exhibiting
>>>> an H such that H(X,Y) == false if, and only if, X(Y) does not halt has
>>>> not gone away.  It's called the halting problem.  There are famous
>>>> theorems about it.  At one time you were interested in addressing it.
>>>
>>> If the correctly simulated input to H(P,P) specifies a non-halting
>>> sequence of configurations on the basis of its actual behavior then
>>> this actual behavior supersedes and overrules anything any everything
>>> else that disagrees.
>>
>> The halting problem is about H(P,P) being right about P(P), not about
>> anything else you might find to waffle about.
>
> The halting problem *is not* about P(P) when P(P) is not computationally
> equivalent to the correct simulation of the input to H(P,P).

Then you aren't looking at a correct definition, as the definition of
the halting problem specifically says it does.

>
> It is a very very weird case that these two are not computationally
> equivalent, none-the-less it is a verified fact that they are not
> computationally equivalent. This fact can only be verified by someone
> with sufficient technical competence:
>
> To fully understand this paper a software engineer must be an expert in
> the C programming language, the x86 programming language, exactly how C
> translates into x86 and what an x86 process emulator is. No knowledge of
> the halting problem is required.
>

So, you are just admitting that you are just defining a DIFFERENT
problem that is almost the halting problem, but redefined for this case.

Fine, just says that you are admitting that your results don't apply to
the actual halting problem and thus don't disprove the proofs that use
the REAL halting problem to show things like not all True Statements are
provable.

>
>
>
> Halting problem undecidability and infinitely nested simulation (V5)
>
> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>
>

On 4/22/2022 8:00 PM, Ben wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Friday, 22 April 2022 at 19:52:06 UTC+1, Ben wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> This is clearer:
>>>> With H(P,P) H is invoked before P(P) is simulated.
>>>> With P(P) P is invoked before H(P,P) is invoked.
>>>>
>>>> Because H and P are invoked in a different order this changes their
>>>> behavior.
>>> Everyone has been quite sure that this is the trick you have been trying
>>> to pull ever since you flatly denied it to Mike Terry more than three
>>> years ago. What's puzzling is why you don't use this trick to have H
>>> return the correct answer!
>>>
>> You assume bad faith.
>
> Yes.
>
>> But since PO admits that P(P) halts whilst H(P,P) reports non-halting,
>> the obvious explantion is that he is posting in good faith.
>
> An alternative is that he as no option because previous
> "solutions" were about explaining the wrong answer away. Having done
> that, he's stuck with it.
>
> He's never admitted that any of his other ruses were wrong. 18 years
> we've been battling various "solutions", each one logically sufficient
> in itself, but each abandoned because all were as daft as this latest
> attempt. Do you think he has forgotten these ploys? Is his mind so
> feeble as to have no recollection of how he overturned a major result in
> CS 36 times before? Or maybe his delusions are so strong that they can
> sustain this degree of cognitive dissonance for years? It's bad faith
> or serious mental health issues.
>
> If I'm honest, I suspect it's the latter, but then what does it say
> about my still talking to him? Resolving my own cognitive dissonance
> requires I pretend it's bad faith.
>
>> You have an x86 emulator. You modify it with infinite cycle detection logic,
>> and create a reasonably accurate halt decider. But of course it chokes on
>> H_Hat<H_Hat>as it must do.
>> However if you are not very well educated in thse matters, you might examine
>> H for errors. And it's not obvious where the error is. The infinite cycle detection
>> logic holds up in the vast majority of cases, after all. And the code is quite
>> complicated.
>
> Do you really think he has some complicated cycle detection code? No,
> he has code /outside of H/ that spots one obvious and simple pattern.
> His H just calls it's first argument passing it the second. The
> "halt-detecting OS" (the modified emulator) spots the recursion (which
> is, of course, there) and aborts H. At various times, I think he's
> assumed that he could put this detection code into H and it would not
> matter (obviously wrong) or that false is correct because the code
> without the abort is indeed non-halting.
>
> Most importantly -- there no nested simulation. Maybe he tired, but I
> suspect he simply could not work out how to make the simulator
> re-entrant.
This was the most difficult part of the whole project.

Since I explained "how" I made my simulator re-entrant:
Each simulation has its own registers, RAM and stack,
and this is what is required to make my simulator re-entrant and every
post that I have provided for many months shows that each subsequent
simulation does have its own 64K stack your guess has been refuted.

Begin Local Halt Decider Simulation

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
....[000009d6][00211368][0021136c] 55 push ebp // enter P
....[000009d7][00211368][0021136c] 8bec mov ebp,esp
....[000009d9][00211368][0021136c] 8b4508 mov eax,[ebp+08]
....[000009dc][00211364][000009d6] 50 push eax // Push P
....[000009dd][00211364][000009d6] 8b4d08 mov ecx,[ebp+08]
....[000009e0][00211360][000009d6] 51 push ecx // Push P
....[000009e1][0021135c][000009e6] e840feffff call 00000826 // Call H
....[000009d6][0025bd90][0025bd94] 55 push ebp // enter P
....[000009d7][0025bd90][0025bd94] 8bec mov ebp,esp
....[000009d9][0025bd90][0025bd94] 8b4508 mov eax,[ebp+08]
....[000009dc][0025bd8c][000009d6] 50 push eax // Push P
....[000009dd][0025bd8c][000009d6] 8b4d08 mov ecx,[ebp+08]
....[000009e0][0025bd88][000009d6] 51 push ecx // Push P
....[000009e1][0025bd84][000009e6] e840feffff call 00000826 // Call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

--
Copyright 2022 Pete Olcott

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

On 4/23/2022 12:20 PM, olcott wrote:
> On 4/22/2022 8:00 PM, Ben wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> On Friday, 22 April 2022 at 19:52:06 UTC+1, Ben wrote:
>>>> olcott <No...@NoWhere.com> writes:
>>>>
>>>>> This is clearer:
>>>>> With H(P,P) H is invoked before P(P) is simulated.
>>>>> With P(P) P is invoked before H(P,P) is invoked.
>>>>>
>>>>> Because H and P are invoked in a different order this changes their
>>>>> behavior.
>>>> Everyone has been quite sure that this is the trick you have been
>>>> trying
>>>> to pull ever since you flatly denied it to Mike Terry more than three
>>>> years ago. What's puzzling is why you don't use this trick to have H
>>>> return the correct answer!
>>>>
>>> You assume bad faith.
>>
>> Yes.
>>
>>> But since PO admits that P(P) halts whilst H(P,P) reports non-halting,
>>> the obvious explantion is that he is posting in good faith.
>>
>> An alternative is that he as no option because previous
>> "solutions" were about explaining the wrong answer away.  Having done
>> that, he's stuck with it.
>>
>> He's never admitted that any of his other ruses were wrong.  18 years
>> we've been battling various "solutions", each one logically sufficient
>> in itself, but each abandoned because all were as daft as this latest
>> attempt.  Do you think he has forgotten these ploys?  Is his mind so
>> feeble as to have no recollection of how he overturned a major result in
>> CS 36 times before?  Or maybe his delusions are so strong that they can
>> sustain this degree of cognitive dissonance for years?  It's bad faith
>> or serious mental health issues.
>>
>> If I'm honest, I suspect it's the latter, but then what does it say
>> about my still talking to him?  Resolving my own cognitive dissonance
>> requires I pretend it's bad faith.
>>
>>> You have an x86 emulator. You modify it with infinite cycle detection
>>> logic,
>>> and create a reasonably accurate halt decider. But of course it
>>> chokes on
>>> H_Hat<H_Hat>as it must do.
>>> However if you are not very well educated in thse matters, you might
>>> examine
>>> H for errors. And it's not obvious where the error is. The infinite
>>> cycle detection
>>> logic holds up in the vast majority of cases, after all. And the code
>>> is quite
>>> complicated.
>>
>> Do you really think he has some complicated cycle detection code?  No,
>> he has code /outside of H/ that spots one obvious and simple pattern.
>> His H just calls it's first argument passing it the second.  The
>> "halt-detecting OS" (the modified emulator) spots the recursion (which
>> is, of course, there) and aborts H.  At various times, I think he's
>> assumed that he could put this detection code into H and it would not
>> matter (obviously wrong) or that false is correct because the code
>> without the abort is indeed non-halting.
>>
>> Most importantly -- there no nested simulation.  Maybe he tired, but I
>> suspect he simply could not work out how to make the simulator
>> re-entrant.
> This was the most difficult part of the whole project.
>
> Since I explained "how" I made my simulator re-entrant:
> Each simulation has its own registers, RAM and stack,
> and this is what is required to make my simulator re-entrant and every
> post that I have provided for many months shows that each subsequent
> simulation does have its own 64K stack your guess has been refuted.
So to tell if you were in a loop, you needed to compare for equality 1)
the "mapped" address of the instructions counter, 2) the contents of all
programmable registers and all interior non-programmable registers
mapped as necessary, 3) the total 64K stacks (can't count on tame
references in user level code), 4) whether you are in a state were the
hardware is doing an interior execution, aka, one for the road, and 5) a
lot more. Oh yes; you have one simulator executing another that's
executing the test program. So you are doing all of this!!!!! Where are
you storing the 64K++ remembered state for each inner instruction
instruction execution? (Hint, that state includes the instruction
executions of inner simulator. Whoops!)
Basically do you have enough combined memory and secondary storage to
simulate 100 instructions of the test program? And if so, where are you
storing all that state and state of the other level??? You might do it
by delta modulation and hashing but we know that isn't the case. You
would have been so excited to discover such a way of saving orders and
orders of magnitude storage, that you would have proclaimed it loudly to
the world and put a copyright on the pronouncement as soon as your
congratulatory masturbation session was over.
No. Couldn't happen that way. No coding recently. Too busy spewing
nonsense. No real simulation and loop detection. Just eye ball the trace
and look for duplicate addresses. Aha! That's why you can't run any one
else's test cases - you can't automatically spot even simple loops for
sure. Well at least your current production is up to that high standards
that you've set for yourself.
--
Jeff Barnett

On 4/23/22 2:20 PM, olcott wrote:
> On 4/22/2022 8:00 PM, Ben wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> On Friday, 22 April 2022 at 19:52:06 UTC+1, Ben wrote:
>>>> olcott <No...@NoWhere.com> writes:
>>>>
>>>>> This is clearer:
>>>>> With H(P,P) H is invoked before P(P) is simulated.
>>>>> With P(P) P is invoked before H(P,P) is invoked.
>>>>>
>>>>> Because H and P are invoked in a different order this changes their
>>>>> behavior.
>>>> Everyone has been quite sure that this is the trick you have been
>>>> trying
>>>> to pull ever since you flatly denied it to Mike Terry more than three
>>>> years ago. What's puzzling is why you don't use this trick to have H
>>>> return the correct answer!
>>>>
>>> You assume bad faith.
>>
>> Yes.
>>
>>> But since PO admits that P(P) halts whilst H(P,P) reports non-halting,
>>> the obvious explantion is that he is posting in good faith.
>>
>> An alternative is that he as no option because previous
>> "solutions" were about explaining the wrong answer away.  Having done
>> that, he's stuck with it.
>>
>> He's never admitted that any of his other ruses were wrong.  18 years
>> we've been battling various "solutions", each one logically sufficient
>> in itself, but each abandoned because all were as daft as this latest
>> attempt.  Do you think he has forgotten these ploys?  Is his mind so
>> feeble as to have no recollection of how he overturned a major result in
>> CS 36 times before?  Or maybe his delusions are so strong that they can
>> sustain this degree of cognitive dissonance for years?  It's bad faith
>> or serious mental health issues.
>>
>> If I'm honest, I suspect it's the latter, but then what does it say
>> about my still talking to him?  Resolving my own cognitive dissonance
>> requires I pretend it's bad faith.
>>
>>> You have an x86 emulator. You modify it with infinite cycle detection
>>> logic,
>>> and create a reasonably accurate halt decider. But of course it
>>> chokes on
>>> H_Hat<H_Hat>as it must do.
>>> However if you are not very well educated in thse matters, you might
>>> examine
>>> H for errors. And it's not obvious where the error is. The infinite
>>> cycle detection
>>> logic holds up in the vast majority of cases, after all. And the code
>>> is quite
>>> complicated.
>>
>> Do you really think he has some complicated cycle detection code?  No,
>> he has code /outside of H/ that spots one obvious and simple pattern.
>> His H just calls it's first argument passing it the second.  The
>> "halt-detecting OS" (the modified emulator) spots the recursion (which
>> is, of course, there) and aborts H.  At various times, I think he's
>> assumed that he could put this detection code into H and it would not
>> matter (obviously wrong) or that false is correct because the code
>> without the abort is indeed non-halting.
>>
>> Most importantly -- there no nested simulation.  Maybe he tired, but I
>> suspect he simply could not work out how to make the simulator
>> re-entrant.
> This was the most difficult part of the whole project.
>
> Since I explained "how" I made my simulator re-entrant:
> Each simulation has its own registers, RAM and stack,
> and this is what is required to make my simulator re-entrant and every
> post that I have provided for many months shows that each subsequent
> simulation does have its own 64K stack your guess has been refuted.

But it doesn't have its own memory space, so it can only simulate a
machine that includes a copy of itself at its same address.

>
>
> Begin Local Halt Decider Simulation
>
>     machine   stack     stack     machine    assembly
>     address   address   data      code       language
>     ========  ========  ========  =========  =============
> ...[000009d6][00211368][0021136c] 55         push ebp         // enter P
> ...[000009d7][00211368][0021136c] 8bec       mov ebp,esp
> ...[000009d9][00211368][0021136c] 8b4508     mov eax,[ebp+08]
> ...[000009dc][00211364][000009d6] 50         push eax         // Push P
> ...[000009dd][00211364][000009d6] 8b4d08     mov ecx,[ebp+08]
> ...[000009e0][00211360][000009d6] 51         push ecx         // Push P
> ...[000009e1][0021135c][000009e6] e840feffff call 00000826    // Call H
> ...[000009d6][0025bd90][0025bd94] 55         push ebp         // enter P
> ...[000009d7][0025bd90][0025bd94] 8bec       mov ebp,esp
> ...[000009d9][0025bd90][0025bd94] 8b4508     mov eax,[ebp+08]
> ...[000009dc][0025bd8c][000009d6] 50         push eax         // Push P
> ...[000009dd][0025bd8c][000009d6] 8b4d08     mov ecx,[ebp+08]
> ...[000009e0][0025bd88][000009d6] 51         push ecx         // Push P
> ...[000009e1][0025bd84][000009e6] e840feffff call 00000826    // Call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
>
>

On 4/23/2022 4:47 PM, Jeff Barnett wrote:
> On 4/23/2022 12:20 PM, olcott wrote:
>> On 4/22/2022 8:00 PM, Ben wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>
>>>> On Friday, 22 April 2022 at 19:52:06 UTC+1, Ben wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> This is clearer:
>>>>>> With H(P,P) H is invoked before P(P) is simulated.
>>>>>> With P(P) P is invoked before H(P,P) is invoked.
>>>>>>
>>>>>> Because H and P are invoked in a different order this changes their
>>>>>> behavior.
>>>>> Everyone has been quite sure that this is the trick you have been
>>>>> trying
>>>>> to pull ever since you flatly denied it to Mike Terry more than three
>>>>> years ago. What's puzzling is why you don't use this trick to have H
>>>>> return the correct answer!
>>>>>
>>>> You assume bad faith.
>>>
>>> Yes.
>>>
>>>> But since PO admits that P(P) halts whilst H(P,P) reports non-halting,
>>>> the obvious explantion is that he is posting in good faith.
>>>
>>> An alternative is that he as no option because previous
>>> "solutions" were about explaining the wrong answer away.  Having done
>>> that, he's stuck with it.
>>>
>>> He's never admitted that any of his other ruses were wrong.  18 years
>>> we've been battling various "solutions", each one logically sufficient
>>> in itself, but each abandoned because all were as daft as this latest
>>> attempt.  Do you think he has forgotten these ploys?  Is his mind so
>>> feeble as to have no recollection of how he overturned a major result in
>>> CS 36 times before?  Or maybe his delusions are so strong that they can
>>> sustain this degree of cognitive dissonance for years?  It's bad faith
>>> or serious mental health issues.
>>>
>>> If I'm honest, I suspect it's the latter, but then what does it say
>>> about my still talking to him?  Resolving my own cognitive dissonance
>>> requires I pretend it's bad faith.
>>>
>>>> You have an x86 emulator. You modify it with infinite cycle
>>>> detection logic,
>>>> and create a reasonably accurate halt decider. But of course it
>>>> chokes on
>>>> H_Hat<H_Hat>as it must do.
>>>> However if you are not very well educated in thse matters, you might
>>>> examine
>>>> H for errors. And it's not obvious where the error is. The infinite
>>>> cycle detection
>>>> logic holds up in the vast majority of cases, after all. And the
>>>> code is quite
>>>> complicated.
>>>
>>> Do you really think he has some complicated cycle detection code?  No,
>>> he has code /outside of H/ that spots one obvious and simple pattern.
>>> His H just calls it's first argument passing it the second.  The
>>> "halt-detecting OS" (the modified emulator) spots the recursion (which
>>> is, of course, there) and aborts H.  At various times, I think he's
>>> assumed that he could put this detection code into H and it would not
>>> matter (obviously wrong) or that false is correct because the code
>>> without the abort is indeed non-halting.
>>>
>>> Most importantly -- there no nested simulation.  Maybe he tired, but I
>>> suspect he simply could not work out how to make the simulator
>>> re-entrant.
>> This was the most difficult part of the whole project.
>>
>> Since I explained "how" I made my simulator re-entrant:
>> Each simulation has its own registers, RAM and stack,
>> and this is what is required to make my simulator re-entrant and every
>> post that I have provided for many months shows that each subsequent
>> simulation does have its own 64K stack your guess has been refuted.

> So to tell if you were in a loop, you needed to compare for equality 1)
> the "mapped" address of the instructions counter, 2) the contents of all
> programmable registers and all interior non-programmable registers
> mapped as necessary, 3) the total 64K stacks (can't count on tame
> references in user level code), 4) whether you are in a state were the
> hardware is doing an interior execution, aka, one for the road, and 5) a
> lot more.

<sarcasm>
Yes that is true, to be able to tell that the follwing code has an
infinite loop we must check at least 100,000 different things
</sarcasm>

_Infinite_Loop()
[00000946](01) 55 push ebp
[00000947](02) 8bec mov ebp,esp
[00000949](02) ebfe jmp 00000949
[0000094b](01) 5d pop ebp
[0000094c](01) c3 ret
Size in bytes:(0007) [0000094c]

> Oh yes; you have one simulator executing another that's
> executing the test program. So you are doing all of this!!!!! Where are
> you storing the 64K++ remembered state for each inner instruction
> instruction execution? (Hint, that state includes the instruction
> executions of inner simulator. Whoops!)
>
> Basically do you have enough combined memory and secondary storage to
> simulate 100 instructions of the test program? And if so, where are you

4GB is available to the simulator it operates in 32-bit mode.

> storing all that state and state of the other level??? You might do it
> by delta modulation and hashing but we know that isn't the case. You
> would have been so excited to discover such a way of saving orders and
> orders of magnitude storage, that you would have proclaimed it loudly to
> the world and put a copyright on the pronouncement as soon as your
> congratulatory masturbation session was over.
>
> No. Couldn't happen that way. No coding recently. Too busy spewing
> nonsense. No real simulation and loop detection. Just eye ball the trace
> and look for duplicate addresses. Aha! That's why you can't run any one
> else's test cases - you can't automatically spot even simple loops for
> sure. Well at least your current production is up to that high standards
> that you've set for yourself.

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
....[000009d6][00211368][0021136c] 55 push ebp // enter P
....[000009d7][00211368][0021136c] 8bec mov ebp,esp
....[000009d9][00211368][0021136c] 8b4508 mov eax,[ebp+08]
....[000009dc][00211364][000009d6] 50 push eax // Push P
....[000009dd][00211364][000009d6] 8b4d08 mov ecx,[ebp+08]
....[000009e0][00211360][000009d6] 51 push ecx // Push P
....[000009e1][0021135c][000009e6] e840feffff call 00000826 // Call H
....[000009d6][0025bd90][0025bd94] 55 push ebp // enter P
....[000009d7][0025bd90][0025bd94] 8bec mov ebp,esp
....[000009d9][0025bd90][0025bd94] 8b4508 mov eax,[ebp+08]
....[000009dc][0025bd8c][000009d6] 50 push eax // Push P
....[000009dd][0025bd8c][000009d6] 8b4d08 mov ecx,[ebp+08]
....[000009e0][0025bd88][000009d6] 51 push ecx // Push P
....[000009e1][0025bd84][000009e6] e840feffff call 00000826 // Call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

It is totally obvious that P calls H twice with the same params, thus
proving that the call will never return.

--
Copyright 2022 Pete Olcott

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

On Saturday, 23 April 2022 at 23:07:56 UTC+1, olcott wrote:
> On 4/23/2022 4:47 PM, Jeff Barnett wrote:
> > On 4/23/2022 12:20 PM, olcott wrote:
> >> On 4/22/2022 8:00 PM, Ben wrote:
> >>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>
> >>>> On Friday, 22 April 2022 at 19:52:06 UTC+1, Ben wrote:
> >>>>> olcott <No...@NoWhere.com> writes:
> >>>>>
> >>>>>> This is clearer:
> >>>>>> With H(P,P) H is invoked before P(P) is simulated.
> >>>>>> With P(P) P is invoked before H(P,P) is invoked.
> >>>>>>
> >>>>>> Because H and P are invoked in a different order this changes their
> >>>>>> behavior.
> >>>>> Everyone has been quite sure that this is the trick you have been
> >>>>> trying
> >>>>> to pull ever since you flatly denied it to Mike Terry more than three
> >>>>> years ago. What's puzzling is why you don't use this trick to have H
> >>>>> return the correct answer!
> >>>>>
> >>>> You assume bad faith.
> >>>
> >>> Yes.
> >>>
> >>>> But since PO admits that P(P) halts whilst H(P,P) reports non-halting,
> >>>> the obvious explantion is that he is posting in good faith.
> >>>
> >>> An alternative is that he as no option because previous
> >>> "solutions" were about explaining the wrong answer away. Having done
> >>> that, he's stuck with it.
> >>>
> >>> He's never admitted that any of his other ruses were wrong. 18 years
> >>> we've been battling various "solutions", each one logically sufficient
> >>> in itself, but each abandoned because all were as daft as this latest
> >>> attempt. Do you think he has forgotten these ploys? Is his mind so
> >>> feeble as to have no recollection of how he overturned a major result in
> >>> CS 36 times before? Or maybe his delusions are so strong that they can
> >>> sustain this degree of cognitive dissonance for years? It's bad faith
> >>> or serious mental health issues.
> >>>
> >>> If I'm honest, I suspect it's the latter, but then what does it say
> >>> about my still talking to him? Resolving my own cognitive dissonance
> >>> requires I pretend it's bad faith.
> >>>
> >>>> You have an x86 emulator. You modify it with infinite cycle
> >>>> detection logic,
> >>>> and create a reasonably accurate halt decider. But of course it
> >>>> chokes on
> >>>> H_Hat<H_Hat>as it must do.
> >>>> However if you are not very well educated in thse matters, you might
> >>>> examine
> >>>> H for errors. And it's not obvious where the error is. The infinite
> >>>> cycle detection
> >>>> logic holds up in the vast majority of cases, after all. And the
> >>>> code is quite
> >>>> complicated.
> >>>
> >>> Do you really think he has some complicated cycle detection code? No,
> >>> he has code /outside of H/ that spots one obvious and simple pattern.
> >>> His H just calls it's first argument passing it the second. The
> >>> "halt-detecting OS" (the modified emulator) spots the recursion (which
> >>> is, of course, there) and aborts H. At various times, I think he's
> >>> assumed that he could put this detection code into H and it would not
> >>> matter (obviously wrong) or that false is correct because the code
> >>> without the abort is indeed non-halting.
> >>>
> >>> Most importantly -- there no nested simulation. Maybe he tired, but I
> >>> suspect he simply could not work out how to make the simulator
> >>> re-entrant.
> >> This was the most difficult part of the whole project.
> >>
> >> Since I explained "how" I made my simulator re-entrant:
> >> Each simulation has its own registers, RAM and stack,
> >> and this is what is required to make my simulator re-entrant and every
> >> post that I have provided for many months shows that each subsequent
> >> simulation does have its own 64K stack your guess has been refuted.
>
> > So to tell if you were in a loop, you needed to compare for equality 1)
> > the "mapped" address of the instructions counter, 2) the contents of all
> > programmable registers and all interior non-programmable registers
> > mapped as necessary, 3) the total 64K stacks (can't count on tame
> > references in user level code), 4) whether you are in a state were the
> > hardware is doing an interior execution, aka, one for the road, and 5) a
> > lot more.
> <sarcasm>
> Yes that is true, to be able to tell that the follwing code has an
> infinite loop we must check at least 100,000 different things
> </sarcasm>
>
> _Infinite_Loop()
> [00000946](01) 55 push ebp
> [00000947](02) 8bec mov ebp,esp
> [00000949](02) ebfe jmp 00000949
> [0000094b](01) 5d pop ebp
> [0000094c](01) c3 ret
> Size in bytes:(0007) [0000094c]
> > Oh yes; you have one simulator executing another that's
> > executing the test program. So you are doing all of this!!!!! Where are
> > you storing the 64K++ remembered state for each inner instruction
> > instruction execution? (Hint, that state includes the instruction
> > executions of inner simulator. Whoops!)
> >
> > Basically do you have enough combined memory and secondary storage to
> > simulate 100 instructions of the test program? And if so, where are you
> 4GB is available to the simulator it operates in 32-bit mode.
> > storing all that state and state of the other level??? You might do it
> > by delta modulation and hashing but we know that isn't the case. You
> > would have been so excited to discover such a way of saving orders and
> > orders of magnitude storage, that you would have proclaimed it loudly to
> > the world and put a copyright on the pronouncement as soon as your
> > congratulatory masturbation session was over.
> >
> > No. Couldn't happen that way. No coding recently. Too busy spewing
> > nonsense. No real simulation and loop detection. Just eye ball the trace
> > and look for duplicate addresses. Aha! That's why you can't run any one
> > else's test cases - you can't automatically spot even simple loops for
> > sure. Well at least your current production is up to that high standards
> > that you've set for yourself.
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> ...[000009d6][00211368][0021136c] 55 push ebp // enter P
> ...[000009d7][00211368][0021136c] 8bec mov ebp,esp
> ...[000009d9][00211368][0021136c] 8b4508 mov eax,[ebp+08]
> ...[000009dc][00211364][000009d6] 50 push eax // Push P
> ...[000009dd][00211364][000009d6] 8b4d08 mov ecx,[ebp+08]
> ...[000009e0][00211360][000009d6] 51 push ecx // Push P
> ...[000009e1][0021135c][000009e6] e840feffff call 00000826 // Call H
> ...[000009d6][0025bd90][0025bd94] 55 push ebp // enter P
> ...[000009d7][0025bd90][0025bd94] 8bec mov ebp,esp
> ...[000009d9][0025bd90][0025bd94] 8b4508 mov eax,[ebp+08]
> ...[000009dc][0025bd8c][000009d6] 50 push eax // Push P
> ...[000009dd][0025bd8c][000009d6] 8b4d08 mov ecx,[ebp+08]
> ...[000009e0][0025bd88][000009d6] 51 push ecx // Push P
> ...[000009e1][0025bd84][000009e6] e840feffff call 00000826 // Call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
> It is totally obvious that P calls H twice with the same params, thus
> proving that the call will never return.
>
Superfically it looks totally obvious that H is just popping P and P
from the stack, and calling them. Then it is indeed stuck in infinite
recursion. And that's what Ben claims it is doing. But, in that case,
H isn't a halt decider. And you've said that H simulates P(P).

Now we've just had a political discussion about lying in the UK. I
want to emphasis that if in fact H calls P(P), that doesn't necessarily
mean that you were lying when you said it "simulated it". Maybe you
weren't clear in your own mind what a nested simulator does.
However you do need to take this opportunity to clarify the point.

On 4/23/22 6:07 PM, olcott wrote:
> On 4/23/2022 4:47 PM, Jeff Barnett wrote:
>> On 4/23/2022 12:20 PM, olcott wrote:
>>> On 4/22/2022 8:00 PM, Ben wrote:
>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>
>>>>> On Friday, 22 April 2022 at 19:52:06 UTC+1, Ben wrote:
>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>
>>>>>>> This is clearer:
>>>>>>> With H(P,P) H is invoked before P(P) is simulated.
>>>>>>> With P(P) P is invoked before H(P,P) is invoked.
>>>>>>>
>>>>>>> Because H and P are invoked in a different order this changes their
>>>>>>> behavior.
>>>>>> Everyone has been quite sure that this is the trick you have been
>>>>>> trying
>>>>>> to pull ever since you flatly denied it to Mike Terry more than three
>>>>>> years ago. What's puzzling is why you don't use this trick to have H
>>>>>> return the correct answer!
>>>>>>
>>>>> You assume bad faith.
>>>>
>>>> Yes.
>>>>
>>>>> But since PO admits that P(P) halts whilst H(P,P) reports non-halting,
>>>>> the obvious explantion is that he is posting in good faith.
>>>>
>>>> An alternative is that he as no option because previous
>>>> "solutions" were about explaining the wrong answer away.  Having done
>>>> that, he's stuck with it.
>>>>
>>>> He's never admitted that any of his other ruses were wrong.  18 years
>>>> we've been battling various "solutions", each one logically sufficient
>>>> in itself, but each abandoned because all were as daft as this latest
>>>> attempt.  Do you think he has forgotten these ploys?  Is his mind so
>>>> feeble as to have no recollection of how he overturned a major
>>>> result in
>>>> CS 36 times before?  Or maybe his delusions are so strong that they can
>>>> sustain this degree of cognitive dissonance for years?  It's bad faith
>>>> or serious mental health issues.
>>>>
>>>> If I'm honest, I suspect it's the latter, but then what does it say
>>>> about my still talking to him?  Resolving my own cognitive dissonance
>>>> requires I pretend it's bad faith.
>>>>
>>>>> You have an x86 emulator. You modify it with infinite cycle
>>>>> detection logic,
>>>>> and create a reasonably accurate halt decider. But of course it
>>>>> chokes on
>>>>> H_Hat<H_Hat>as it must do.
>>>>> However if you are not very well educated in thse matters, you
>>>>> might examine
>>>>> H for errors. And it's not obvious where the error is. The infinite
>>>>> cycle detection
>>>>> logic holds up in the vast majority of cases, after all. And the
>>>>> code is quite
>>>>> complicated.
>>>>
>>>> Do you really think he has some complicated cycle detection code?  No,
>>>> he has code /outside of H/ that spots one obvious and simple pattern.
>>>> His H just calls it's first argument passing it the second.  The
>>>> "halt-detecting OS" (the modified emulator) spots the recursion (which
>>>> is, of course, there) and aborts H.  At various times, I think he's
>>>> assumed that he could put this detection code into H and it would not
>>>> matter (obviously wrong) or that false is correct because the code
>>>> without the abort is indeed non-halting.
>>>>
>>>> Most importantly -- there no nested simulation.  Maybe he tired, but I
>>>> suspect he simply could not work out how to make the simulator
>>>> re-entrant.
>>> This was the most difficult part of the whole project.
>>>
>>> Since I explained "how" I made my simulator re-entrant:
>>> Each simulation has its own registers, RAM and stack,
>>> and this is what is required to make my simulator re-entrant and
>>> every post that I have provided for many months shows that each
>>> subsequent simulation does have its own 64K stack your guess has been
>>> refuted.
>
>> So to tell if you were in a loop, you needed to compare for equality
>> 1) the "mapped" address of the instructions counter, 2) the contents
>> of all programmable registers and all interior non-programmable
>> registers mapped as necessary, 3) the total 64K stacks (can't count on
>> tame references in user level code), 4) whether you are in a state
>> were the hardware is doing an interior execution, aka, one for the
>> road, and 5) a lot more.
>
> <sarcasm>
> Yes that is true, to be able to tell that the follwing code has an
> infinite loop we must check at least 100,000 different things
> </sarcasm>
>
> _Infinite_Loop()
> [00000946](01)  55              push ebp
> [00000947](02)  8bec            mov ebp,esp
> [00000949](02)  ebfe            jmp 00000949
> [0000094b](01)  5d              pop ebp
> [0000094c](01)  c3              ret
> Size in bytes:(0007) [0000094c]
>
>> Oh yes; you have one simulator executing another that's executing the
>> test program. So you are doing all of this!!!!! Where are you storing
>> the 64K++ remembered state for each inner instruction instruction
>> execution? (Hint, that state includes the instruction executions of
>> inner simulator. Whoops!)
>>
>> Basically do you have enough combined memory and secondary storage to
>> simulate 100 instructions of the test program? And if so, where are you
>
> 4GB is available to the simulator it operates in 32-bit mode.
>
>> storing all that state and state of the other level??? You might do it
>> by delta modulation and hashing but we know that isn't the case. You
>> would have been so excited to discover such a way of saving orders and
>> orders of magnitude storage, that you would have proclaimed it loudly
>> to the world and put a copyright on the pronouncement as soon as your
>> congratulatory masturbation session was over.
>>
>> No. Couldn't happen that way. No coding recently. Too busy spewing
>> nonsense. No real simulation and loop detection. Just eye ball the
>> trace and look for duplicate addresses. Aha! That's why you can't run
>> any one else's test cases - you can't automatically spot even simple
>> loops for sure. Well at least your current production is up to that
>> high standards that you've set for yourself.
>
>     machine   stack     stack     machine    assembly
>     address   address   data      code       language
>     ========  ========  ========  =========  =============
> ...[000009d6][00211368][0021136c] 55         push ebp         // enter P
> ...[000009d7][00211368][0021136c] 8bec       mov ebp,esp
> ...[000009d9][00211368][0021136c] 8b4508     mov eax,[ebp+08]
> ...[000009dc][00211364][000009d6] 50         push eax         // Push P
> ...[000009dd][00211364][000009d6] 8b4d08     mov ecx,[ebp+08]
> ...[000009e0][00211360][000009d6] 51         push ecx         // Push P
> ...[000009e1][0021135c][000009e6] e840feffff call 00000826    // Call H
> ...[000009d6][0025bd90][0025bd94] 55         push ebp         // enter P
> ...[000009d7][0025bd90][0025bd94] 8bec       mov ebp,esp
> ...[000009d9][0025bd90][0025bd94] 8b4508     mov eax,[ebp+08]
> ...[000009dc][0025bd8c][000009d6] 50         push eax         // Push P
> ...[000009dd][0025bd8c][000009d6] 8b4d08     mov ecx,[ebp+08]
> ...[000009e0][0025bd88][000009d6] 51         push ecx         // Push P
> ...[000009e1][0025bd84][000009e6] e840feffff call 00000826    // Call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> It is totally obvious that P calls H twice with the same params, thus
> proving that the call will never return.
>

No, there is not rule that this satisfies, because the trace is "edited"
because it doesn't show the conditional that happen starting at the call
to H.

Since H is conditionally simulating the second copy of P, then every
instruction has a "if need to abort" condition between then, thus the
"infinite loop" condition is NOT satisfied, and the second set of
execution isn't the same as the first, so the second call to H is NOT
just the same for looping consideration as the first.

On 4/23/2022 6:24 PM, Malcolm McLean wrote:
> On Saturday, 23 April 2022 at 23:07:56 UTC+1, olcott wrote:
>> On 4/23/2022 4:47 PM, Jeff Barnett wrote:
>>> On 4/23/2022 12:20 PM, olcott wrote:
>>>> On 4/22/2022 8:00 PM, Ben wrote:
>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>
>>>>>> On Friday, 22 April 2022 at 19:52:06 UTC+1, Ben wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>
>>>>>>>> This is clearer:
>>>>>>>> With H(P,P) H is invoked before P(P) is simulated.
>>>>>>>> With P(P) P is invoked before H(P,P) is invoked.
>>>>>>>>
>>>>>>>> Because H and P are invoked in a different order this changes their
>>>>>>>> behavior.
>>>>>>> Everyone has been quite sure that this is the trick you have been
>>>>>>> trying
>>>>>>> to pull ever since you flatly denied it to Mike Terry more than three
>>>>>>> years ago. What's puzzling is why you don't use this trick to have H
>>>>>>> return the correct answer!
>>>>>>>
>>>>>> You assume bad faith.
>>>>>
>>>>> Yes.
>>>>>
>>>>>> But since PO admits that P(P) halts whilst H(P,P) reports non-halting,
>>>>>> the obvious explantion is that he is posting in good faith.
>>>>>
>>>>> An alternative is that he as no option because previous
>>>>> "solutions" were about explaining the wrong answer away. Having done
>>>>> that, he's stuck with it.
>>>>>
>>>>> He's never admitted that any of his other ruses were wrong. 18 years
>>>>> we've been battling various "solutions", each one logically sufficient
>>>>> in itself, but each abandoned because all were as daft as this latest
>>>>> attempt. Do you think he has forgotten these ploys? Is his mind so
>>>>> feeble as to have no recollection of how he overturned a major result in
>>>>> CS 36 times before? Or maybe his delusions are so strong that they can
>>>>> sustain this degree of cognitive dissonance for years? It's bad faith
>>>>> or serious mental health issues.
>>>>>
>>>>> If I'm honest, I suspect it's the latter, but then what does it say
>>>>> about my still talking to him? Resolving my own cognitive dissonance
>>>>> requires I pretend it's bad faith.
>>>>>
>>>>>> You have an x86 emulator. You modify it with infinite cycle
>>>>>> detection logic,
>>>>>> and create a reasonably accurate halt decider. But of course it
>>>>>> chokes on
>>>>>> H_Hat<H_Hat>as it must do.
>>>>>> However if you are not very well educated in thse matters, you might
>>>>>> examine
>>>>>> H for errors. And it's not obvious where the error is. The infinite
>>>>>> cycle detection
>>>>>> logic holds up in the vast majority of cases, after all. And the
>>>>>> code is quite
>>>>>> complicated.
>>>>>
>>>>> Do you really think he has some complicated cycle detection code? No,
>>>>> he has code /outside of H/ that spots one obvious and simple pattern.
>>>>> His H just calls it's first argument passing it the second. The
>>>>> "halt-detecting OS" (the modified emulator) spots the recursion (which
>>>>> is, of course, there) and aborts H. At various times, I think he's
>>>>> assumed that he could put this detection code into H and it would not
>>>>> matter (obviously wrong) or that false is correct because the code
>>>>> without the abort is indeed non-halting.
>>>>>
>>>>> Most importantly -- there no nested simulation. Maybe he tired, but I
>>>>> suspect he simply could not work out how to make the simulator
>>>>> re-entrant.
>>>> This was the most difficult part of the whole project.
>>>>
>>>> Since I explained "how" I made my simulator re-entrant:
>>>> Each simulation has its own registers, RAM and stack,
>>>> and this is what is required to make my simulator re-entrant and every
>>>> post that I have provided for many months shows that each subsequent
>>>> simulation does have its own 64K stack your guess has been refuted.
>>
>>> So to tell if you were in a loop, you needed to compare for equality 1)
>>> the "mapped" address of the instructions counter, 2) the contents of all
>>> programmable registers and all interior non-programmable registers
>>> mapped as necessary, 3) the total 64K stacks (can't count on tame
>>> references in user level code), 4) whether you are in a state were the
>>> hardware is doing an interior execution, aka, one for the road, and 5) a
>>> lot more.
>> <sarcasm>
>> Yes that is true, to be able to tell that the follwing code has an
>> infinite loop we must check at least 100,000 different things
>> </sarcasm>
>>
>> _Infinite_Loop()
>> [00000946](01) 55 push ebp
>> [00000947](02) 8bec mov ebp,esp
>> [00000949](02) ebfe jmp 00000949
>> [0000094b](01) 5d pop ebp
>> [0000094c](01) c3 ret
>> Size in bytes:(0007) [0000094c]
>>> Oh yes; you have one simulator executing another that's
>>> executing the test program. So you are doing all of this!!!!! Where are
>>> you storing the 64K++ remembered state for each inner instruction
>>> instruction execution? (Hint, that state includes the instruction
>>> executions of inner simulator. Whoops!)
>>>
>>> Basically do you have enough combined memory and secondary storage to
>>> simulate 100 instructions of the test program? And if so, where are you
>> 4GB is available to the simulator it operates in 32-bit mode.
>>> storing all that state and state of the other level??? You might do it
>>> by delta modulation and hashing but we know that isn't the case. You
>>> would have been so excited to discover such a way of saving orders and
>>> orders of magnitude storage, that you would have proclaimed it loudly to
>>> the world and put a copyright on the pronouncement as soon as your
>>> congratulatory masturbation session was over.
>>>
>>> No. Couldn't happen that way. No coding recently. Too busy spewing
>>> nonsense. No real simulation and loop detection. Just eye ball the trace
>>> and look for duplicate addresses. Aha! That's why you can't run any one
>>> else's test cases - you can't automatically spot even simple loops for
>>> sure. Well at least your current production is up to that high standards
>>> that you've set for yourself.
>> machine stack stack machine assembly
>> address address data code language
>> ======== ======== ======== ========= =============
>> ...[000009d6][00211368][0021136c] 55 push ebp // enter P
>> ...[000009d7][00211368][0021136c] 8bec mov ebp,esp
>> ...[000009d9][00211368][0021136c] 8b4508 mov eax,[ebp+08]
>> ...[000009dc][00211364][000009d6] 50 push eax // Push P
>> ...[000009dd][00211364][000009d6] 8b4d08 mov ecx,[ebp+08]
>> ...[000009e0][00211360][000009d6] 51 push ecx // Push P
>> ...[000009e1][0021135c][000009e6] e840feffff call 00000826 // Call H
>> ...[000009d6][0025bd90][0025bd94] 55 push ebp // enter P
>> ...[000009d7][0025bd90][0025bd94] 8bec mov ebp,esp
>> ...[000009d9][0025bd90][0025bd94] 8b4508 mov eax,[ebp+08]
>> ...[000009dc][0025bd8c][000009d6] 50 push eax // Push P
>> ...[000009dd][0025bd8c][000009d6] 8b4d08 mov ecx,[ebp+08]
>> ...[000009e0][0025bd88][000009d6] 51 push ecx // Push P
>> ...[000009e1][0025bd84][000009e6] e840feffff call 00000826 // Call H
>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>> It is totally obvious that P calls H twice with the same params, thus
>> proving that the call will never return.
>>
> Superfically it looks totally obvious that H is just popping P and P
> from the stack, and calling them. Then it is indeed stuck in infinite
> recursion. And that's what Ben claims it is doing. But, in that case,
> H isn't a halt decider. And you've said that H simulates P(P).
>

On 4/23/2022 4:07 PM, olcott wrote:
> On 4/23/2022 4:47 PM, Jeff Barnett wrote:
<SNIP?
>>> Since I explained "how" I made my simulator re-entrant:
>>> Each simulation has its own registers, RAM and stack,
>>> and this is what is required to make my simulator re-entrant and
>>> every post that I have provided for many months shows that each
>>> subsequent simulation does have its own 64K stack your guess has been
>>> refuted.
>
>> So to tell if you were in a loop, you needed to compare for equality
>> 1) the "mapped" address of the instructions counter, 2) the contents
>> of all programmable registers and all interior non-programmable
>> registers mapped as necessary, 3) the total 64K stacks (can't count on
>> tame references in user level code), 4) whether you are in a state
>> were the hardware is doing an interior execution, aka, one for the
>> road, and 5) a lot more.
>
> <sarcasm>
> Yes that is true, to be able to tell that the follwing code has an
> infinite loop we must check at least 100,000 different things
> </sarcasm>
>
> _Infinite_Loop()
> [00000946](01)  55              push ebp
> [00000947](02)  8bec            mov ebp,esp
> [00000949](02)  ebfe            jmp 00000949
> [0000094b](01)  5d              pop ebp
> [0000094c](01)  c3              ret
> Size in bytes:(0007) [0000094c]
You can be as sarcastic and as foolish as you want but it wont help you
detect loops. To detect much other than jump to self involves comparing
total state - if they differ and you cannot *prove* the difference makes
no difference, you can't declare "loop". I don't think you knew that and
I think you will now make some sort of non relevant retort or just go away.
"State" is a software engineering and computation concept that is not
part of your background. In stead of spreading so much BS, you might
engage your brain instead of your mouth for a minute. Of course, this
assumes you have a functional nervous system but that is questionable.
It also explains why the projects you were able to cite for your SE
background were dismal failures according to the articles you cited to
describe them. They looked like the typical PO design, code, and fail
cycle that all have noted here for years.
>> Oh yes; you have one simulator executing another that's executing the
>> test program. So you are doing all of this!!!!! Where are you storing
>> the 64K++ remembered state for each inner instruction instruction
>> execution? (Hint, that state includes the instruction executions of
>> inner simulator. Whoops!)
>>
>> Basically do you have enough combined memory and secondary storage to
>> simulate 100 instructions of the test program? And if so, where are you
>
> 4GB is available to the simulator it operates in 32-bit mode.
So how many test-program instruction executions can you execute and
maintain state for before running out of memory? Since the interior
simulator is probably executing several dozen (maybe several hundred)
instructions for every test-program instruction, I doubt that you could
trace a simple sort of a list of a 100 strings of average length 10
characters. That's assuming you maintain complete state which of course
you are not doing. (Common belief of readers here is that you are using
your untrustworthy eyeball.)
>> storing all that state and state of the other level??? You might do it
>> by delta modulation and hashing but we know that isn't the case. You
>> would have been so excited to discover such a way of saving orders and
>> orders of magnitude storage, that you would have proclaimed it loudly
>> to the world and put a copyright on the pronouncement as soon as your
>> congratulatory masturbation session was over.
>>
>> No. Couldn't happen that way. No coding recently. Too busy spewing
>> nonsense. No real simulation and loop detection. Just eye ball the
>> trace and look for duplicate addresses. Aha! That's why you can't run
>> any one else's test cases - you can't automatically spot even simple
>> loops for sure. Well at least your current production is up to that
>> high standards that you've set for yourself.
>
>     machine   stack     stack     machine    assembly
>     address   address   data      code       language
>     ========  ========  ========  =========  =============
> ...[000009d6][00211368][0021136c] 55         push ebp         // enter P
> ...[000009d7][00211368][0021136c] 8bec       mov ebp,esp
> ...[000009d9][00211368][0021136c] 8b4508     mov eax,[ebp+08]
> ...[000009dc][00211364][000009d6] 50         push eax         // Push P
> ...[000009dd][00211364][000009d6] 8b4d08     mov ecx,[ebp+08]
> ...[000009e0][00211360][000009d6] 51         push ecx         // Push P
> ...[000009e1][0021135c][000009e6] e840feffff call 00000826    // Call H
> ...[000009d6][0025bd90][0025bd94] 55         push ebp         // enter P
> ...[000009d7][0025bd90][0025bd94] 8bec       mov ebp,esp
> ...[000009d9][0025bd90][0025bd94] 8b4508     mov eax,[ebp+08]
> ...[000009dc][0025bd8c][000009d6] 50         push eax         // Push P
> ...[000009dd][0025bd8c][000009d6] 8b4d08     mov ecx,[ebp+08]
> ...[000009e0][0025bd88][000009d6] 51         push ecx         // Push P
> ...[000009e1][0025bd84][000009e6] e840feffff call 00000826    // Call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> It is totally obvious that P calls H twice with the same params, thus
> proving that the call will never return.
Of course it isn't obvious! Are you that goofy???? P might, for example,
reference a global store that has changed or the overflow bit or, or,
or, and or, and so on. No matter what you say or write to defend your
nonsense, you just dig further into the POOP. (Is that a pun son?)
--
Jeff Barnett

On 4/23/2022 6:52 PM, Jeff Barnett wrote:
> On 4/23/2022 4:07 PM, olcott wrote:
>> On 4/23/2022 4:47 PM, Jeff Barnett wrote:
>
> <SNIP?
>
>>>> Since I explained "how" I made my simulator re-entrant:
>>>> Each simulation has its own registers, RAM and stack,
>>>> and this is what is required to make my simulator re-entrant and
>>>> every post that I have provided for many months shows that each
>>>> subsequent simulation does have its own 64K stack your guess has
>>>> been refuted.
>>
>>> So to tell if you were in a loop, you needed to compare for equality
>>> 1) the "mapped" address of the instructions counter, 2) the contents
>>> of all programmable registers and all interior non-programmable
>>> registers mapped as necessary, 3) the total 64K stacks (can't count
>>> on tame references in user level code), 4) whether you are in a state
>>> were the hardware is doing an interior execution, aka, one for the
>>> road, and 5) a lot more.
>>
>> <sarcasm>
>> Yes that is true, to be able to tell that the follwing code has an
>> infinite loop we must check at least 100,000 different things
>> </sarcasm>
>>
>> _Infinite_Loop()
>> [00000946](01)  55              push ebp
>> [00000947](02)  8bec            mov ebp,esp
>> [00000949](02)  ebfe            jmp 00000949
>> [0000094b](01)  5d              pop ebp
>> [0000094c](01)  c3              ret
>> Size in bytes:(0007) [0000094c]
>
> You can be as sarcastic and as foolish as you want but it wont help you
> detect loops. To detect much other than jump to self involves comparing
> total state - if they differ and you cannot *prove* the difference makes
> no difference, you can't declare "loop". I don't think you knew that and
> I think you will now make some sort of non relevant retort or just go away.
>

I have already had this extensively reviewed.

> "State" is a software engineering and computation concept that is not
> part of your background. In stead of spreading so much BS, you might
> engage your brain instead of your mouth for a minute. Of course, this
> assumes you have a functional nervous system but that is questionable.
> It also explains why the projects you were able to cite for your SE
> background were dismal failures according to the articles you cited to
> describe them. They looked like the typical PO design, code, and fail
> cycle that all have noted here for years.
>

I have two patents on finite state machines.

>>> Oh yes; you have one simulator executing another that's executing the
>>> test program. So you are doing all of this!!!!! Where are you storing
>>> the 64K++ remembered state for each inner instruction instruction
>>> execution? (Hint, that state includes the instruction executions of
>>> inner simulator. Whoops!)
>>>
>>> Basically do you have enough combined memory and secondary storage to
>>> simulate 100 instructions of the test program? And if so, where are you
>>
>> 4GB is available to the simulator it operates in 32-bit mode.
>
> So how many test-program instruction executions can you execute and
> maintain state for before running out of memory? Since the interior
> simulator is probably executing several dozen (maybe several hundred)
> instructions for every test-program instruction, I doubt that you could
> trace a simple sort of a list of a 100 strings of average length 10
> characters. That's assuming you maintain complete state which of course
> you are not doing. (Common belief of readers here is that you are using
> your untrustworthy eyeball.)
>

I configure my system for its specific purpose, it can be configured
differently.

>>> storing all that state and state of the other level??? You might do
>>> it by delta modulation and hashing but we know that isn't the case.
>>> You would have been so excited to discover such a way of saving
>>> orders and orders of magnitude storage, that you would have
>>> proclaimed it loudly to the world and put a copyright on the
>>> pronouncement as soon as your congratulatory masturbation session was
>>> over.
>>>
>>> No. Couldn't happen that way. No coding recently. Too busy spewing
>>> nonsense. No real simulation and loop detection. Just eye ball the
>>> trace and look for duplicate addresses. Aha! That's why you can't run
>>> any one else's test cases - you can't automatically spot even simple
>>> loops for sure. Well at least your current production is up to that
>>> high standards that you've set for yourself.
>>
>>      machine   stack     stack     machine    assembly
>>      address   address   data      code       language
>>      ========  ========  ========  =========  =============
>> ...[000009d6][00211368][0021136c] 55         push ebp         // enter P
>> ...[000009d7][00211368][0021136c] 8bec       mov ebp,esp
>> ...[000009d9][00211368][0021136c] 8b4508     mov eax,[ebp+08]
>> ...[000009dc][00211364][000009d6] 50         push eax         // Push P
>> ...[000009dd][00211364][000009d6] 8b4d08     mov ecx,[ebp+08]
>> ...[000009e0][00211360][000009d6] 51         push ecx         // Push P
>> ...[000009e1][0021135c][000009e6] e840feffff call 00000826    // Call H
>> ...[000009d6][0025bd90][0025bd94] 55         push ebp         // enter P
>> ...[000009d7][0025bd90][0025bd94] 8bec       mov ebp,esp
>> ...[000009d9][0025bd90][0025bd94] 8b4508     mov eax,[ebp+08]
>> ...[000009dc][0025bd8c][000009d6] 50         push eax         // Push P
>> ...[000009dd][0025bd8c][000009d6] 8b4d08     mov ecx,[ebp+08]
>> ...[000009e0][0025bd88][000009d6] 51         push ecx         // Push P
>> ...[000009e1][0025bd84][000009e6] e840feffff call 00000826    // Call H
>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>
>> It is totally obvious that P calls H twice with the same params, thus
>> proving that the call will never return.
>
> Of course it isn't obvious! Are you that goofy???? P might, for example,
> reference a global store that has changed or the overflow bit or, or,
> or, and or, and so on. No matter what you say or write to defend your
> nonsense, you just dig further into the POOP. (Is that a pun son?)

H only emulates its input with an x86 emulator until it recognizes a
repeating pattern.

--
Copyright 2022 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> Ben used the correct term re-entrant. H is re-entrant.

Though I was not talking about H of course.

>> As part of the clarification, you need to explain why the second part of
>> the execution trace shows the instructions at P, making it look as though
>> H calls P, rather than the instructions executed by the simulator.
>
> To eliminate 264 pages of purely extraneous detail of the execution
> trace of H.

So you post edited traces?

--
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

On 4/23/22 8:02 PM, olcott wrote:
> On 4/23/2022 6:52 PM, Jeff Barnett wrote:
>> On 4/23/2022 4:07 PM, olcott wrote:
>>> On 4/23/2022 4:47 PM, Jeff Barnett wrote:
>>
>> <SNIP?
>>
>>>>> Since I explained "how" I made my simulator re-entrant:
>>>>> Each simulation has its own registers, RAM and stack,
>>>>> and this is what is required to make my simulator re-entrant and
>>>>> every post that I have provided for many months shows that each
>>>>> subsequent simulation does have its own 64K stack your guess has
>>>>> been refuted.
>>>
>>>> So to tell if you were in a loop, you needed to compare for equality
>>>> 1) the "mapped" address of the instructions counter, 2) the contents
>>>> of all programmable registers and all interior non-programmable
>>>> registers mapped as necessary, 3) the total 64K stacks (can't count
>>>> on tame references in user level code), 4) whether you are in a
>>>> state were the hardware is doing an interior execution, aka, one for
>>>> the road, and 5) a lot more.
>>>
>>> <sarcasm>
>>> Yes that is true, to be able to tell that the follwing code has an
>>> infinite loop we must check at least 100,000 different things
>>> </sarcasm>
>>>
>>> _Infinite_Loop()
>>> [00000946](01)  55              push ebp
>>> [00000947](02)  8bec            mov ebp,esp
>>> [00000949](02)  ebfe            jmp 00000949
>>> [0000094b](01)  5d              pop ebp
>>> [0000094c](01)  c3              ret
>>> Size in bytes:(0007) [0000094c]
>>
>> You can be as sarcastic and as foolish as you want but it wont help
>> you detect loops. To detect much other than jump to self involves
>> comparing total state - if they differ and you cannot *prove* the
>> difference makes no difference, you can't declare "loop". I don't
>> think you knew that and I think you will now make some sort of non
>> relevant retort or just go away.
>>
>
> I have already had this extensively reviewed.
>
>> "State" is a software engineering and computation concept that is not
>> part of your background. In stead of spreading so much BS, you might
>> engage your brain instead of your mouth for a minute. Of course, this
>> assumes you have a functional nervous system but that is questionable.
>> It also explains why the projects you were able to cite for your SE
>> background were dismal failures according to the articles you cited to
>> describe them. They looked like the typical PO design, code, and fail
>> cycle that all have noted here for years.
>>
>
> I have two patents on finite state machines.
>
>>>> Oh yes; you have one simulator executing another that's executing
>>>> the test program. So you are doing all of this!!!!! Where are you
>>>> storing the 64K++ remembered state for each inner instruction
>>>> instruction execution? (Hint, that state includes the instruction
>>>> executions of inner simulator. Whoops!)
>>>>
>>>> Basically do you have enough combined memory and secondary storage
>>>> to simulate 100 instructions of the test program? And if so, where
>>>> are you
>>>
>>> 4GB is available to the simulator it operates in 32-bit mode.
>>
>> So how many test-program instruction executions can you execute and
>> maintain state for before running out of memory? Since the interior
>> simulator is probably executing several dozen (maybe several hundred)
>> instructions for every test-program instruction, I doubt that you
>> could trace a simple sort of a list of a 100 strings of average length
>> 10 characters. That's assuming you maintain complete state which of
>> course you are not doing. (Common belief of readers here is that you
>> are using your untrustworthy eyeball.)
>>
>
> I configure my system for its specific purpose, it can be configured
> differently.

And your error was pointed out back then.

Your "Trace" is built on the UNSOUND assumption that the embedded H's
simulation will NEVER be aborted (not just not aborted before the
simulation H aborts its simulation).

That is the only condition where simulation can be treated as execution.

>
>>>> storing all that state and state of the other level??? You might do
>>>> it by delta modulation and hashing but we know that isn't the case.
>>>> You would have been so excited to discover such a way of saving
>>>> orders and orders of magnitude storage, that you would have
>>>> proclaimed it loudly to the world and put a copyright on the
>>>> pronouncement as soon as your congratulatory masturbation session
>>>> was over.
>>>>
>>>> No. Couldn't happen that way. No coding recently. Too busy spewing
>>>> nonsense. No real simulation and loop detection. Just eye ball the
>>>> trace and look for duplicate addresses. Aha! That's why you can't
>>>> run any one else's test cases - you can't automatically spot even
>>>> simple loops for sure. Well at least your current production is up
>>>> to that high standards that you've set for yourself.
>>>
>>>      machine   stack     stack     machine    assembly
>>>      address   address   data      code       language
>>>      ========  ========  ========  =========  =============
>>> ...[000009d6][00211368][0021136c] 55         push ebp         // enter P
>>> ...[000009d7][00211368][0021136c] 8bec       mov ebp,esp
>>> ...[000009d9][00211368][0021136c] 8b4508     mov eax,[ebp+08]
>>> ...[000009dc][00211364][000009d6] 50         push eax         // Push P
>>> ...[000009dd][00211364][000009d6] 8b4d08     mov ecx,[ebp+08]
>>> ...[000009e0][00211360][000009d6] 51         push ecx         // Push P
>>> ...[000009e1][0021135c][000009e6] e840feffff call 00000826    // Call H
>>> ...[000009d6][0025bd90][0025bd94] 55         push ebp         // enter P
>>> ...[000009d7][0025bd90][0025bd94] 8bec       mov ebp,esp
>>> ...[000009d9][0025bd90][0025bd94] 8b4508     mov eax,[ebp+08]
>>> ...[000009dc][0025bd8c][000009d6] 50         push eax         // Push P
>>> ...[000009dd][0025bd8c][000009d6] 8b4d08     mov ecx,[ebp+08]
>>> ...[000009e0][0025bd88][000009d6] 51         push ecx         // Push P
>>> ...[000009e1][0025bd84][000009e6] e840feffff call 00000826    // Call H
>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>
>>> It is totally obvious that P calls H twice with the same params, thus
>>> proving that the call will never return.
>>
>> Of course it isn't obvious! Are you that goofy???? P might, for
>> example, reference a global store that has changed or the overflow bit
>> or, or, or, and or, and so on. No matter what you say or write to
>> defend your nonsense, you just dig further into the POOP. (Is that a
>> pun son?)
>
> H only emulates its input with an x86 emulator until it recognizes a
> repeating pattern.
>

But it doesn't correct detect patterns that indicate infinite "looping",
because it uses the unsound logic mentioned above.

On 4/23/22 7:41 PM, olcott wrote:
> On 4/23/2022 6:24 PM, Malcolm McLean wrote:
>> On Saturday, 23 April 2022 at 23:07:56 UTC+1, olcott wrote:
>>> On 4/23/2022 4:47 PM, Jeff Barnett wrote:
>>>> On 4/23/2022 12:20 PM, olcott wrote:
>>>>> On 4/22/2022 8:00 PM, Ben wrote:
>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>
>>>>>>> On Friday, 22 April 2022 at 19:52:06 UTC+1, Ben wrote:
>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> This is clearer:
>>>>>>>>> With H(P,P) H is invoked before P(P) is simulated.
>>>>>>>>> With P(P) P is invoked before H(P,P) is invoked.
>>>>>>>>>
>>>>>>>>> Because H and P are invoked in a different order this changes
>>>>>>>>> their
>>>>>>>>> behavior.
>>>>>>>> Everyone has been quite sure that this is the trick you have been
>>>>>>>> trying
>>>>>>>> to pull ever since you flatly denied it to Mike Terry more than
>>>>>>>> three
>>>>>>>> years ago. What's puzzling is why you don't use this trick to
>>>>>>>> have H
>>>>>>>> return the correct answer!
>>>>>>>>
>>>>>>> You assume bad faith.
>>>>>>
>>>>>> Yes.
>>>>>>
>>>>>>> But since PO admits that P(P) halts whilst H(P,P) reports
>>>>>>> non-halting,
>>>>>>> the obvious explantion is that he is posting in good faith.
>>>>>>
>>>>>> An alternative is that he as no option because previous
>>>>>> "solutions" were about explaining the wrong answer away.  Having done
>>>>>> that, he's stuck with it.
>>>>>>
>>>>>> He's never admitted that any of his other ruses were wrong.  18 years
>>>>>> we've been battling various "solutions", each one logically
>>>>>> sufficient
>>>>>> in itself, but each abandoned because all were as daft as this latest
>>>>>> attempt.  Do you think he has forgotten these ploys?  Is his mind so
>>>>>> feeble as to have no recollection of how he overturned a major
>>>>>> result in
>>>>>> CS 36 times before?  Or maybe his delusions are so strong that
>>>>>> they can
>>>>>> sustain this degree of cognitive dissonance for years?  It's bad
>>>>>> faith
>>>>>> or serious mental health issues.
>>>>>>
>>>>>> If I'm honest, I suspect it's the latter, but then what does it say
>>>>>> about my still talking to him?  Resolving my own cognitive dissonance
>>>>>> requires I pretend it's bad faith.
>>>>>>
>>>>>>> You have an x86 emulator. You modify it with infinite cycle
>>>>>>> detection logic,
>>>>>>> and create a reasonably accurate halt decider. But of course it
>>>>>>> chokes on
>>>>>>> H_Hat<H_Hat>as it must do.
>>>>>>> However if you are not very well educated in thse matters, you might
>>>>>>> examine
>>>>>>> H for errors. And it's not obvious where the error is. The infinite
>>>>>>> cycle detection
>>>>>>> logic holds up in the vast majority of cases, after all. And the
>>>>>>> code is quite
>>>>>>> complicated.
>>>>>>
>>>>>> Do you really think he has some complicated cycle detection code?
>>>>>> No,
>>>>>> he has code /outside of H/ that spots one obvious and simple pattern.
>>>>>> His H just calls it's first argument passing it the second.  The
>>>>>> "halt-detecting OS" (the modified emulator) spots the recursion
>>>>>> (which
>>>>>> is, of course, there) and aborts H.  At various times, I think he's
>>>>>> assumed that he could put this detection code into H and it would not
>>>>>> matter (obviously wrong) or that false is correct because the code
>>>>>> without the abort is indeed non-halting.
>>>>>>
>>>>>> Most importantly -- there no nested simulation.  Maybe he tired,
>>>>>> but I
>>>>>> suspect he simply could not work out how to make the simulator
>>>>>> re-entrant.
>>>>> This was the most difficult part of the whole project.
>>>>>
>>>>> Since I explained "how" I made my simulator re-entrant:
>>>>> Each simulation has its own registers, RAM and stack,
>>>>> and this is what is required to make my simulator re-entrant and every
>>>>> post that I have provided for many months shows that each subsequent
>>>>> simulation does have its own 64K stack your guess has been refuted.
>>>
>>>> So to tell if you were in a loop, you needed to compare for equality 1)
>>>> the "mapped" address of the instructions counter, 2) the contents of
>>>> all
>>>> programmable registers and all interior non-programmable registers
>>>> mapped as necessary, 3) the total 64K stacks (can't count on tame
>>>> references in user level code), 4) whether you are in a state were the
>>>> hardware is doing an interior execution, aka, one for the road, and
>>>> 5) a
>>>> lot more.
>>> <sarcasm>
>>> Yes that is true, to be able to tell that the follwing code has an
>>> infinite loop we must check at least 100,000 different things
>>> </sarcasm>
>>>
>>> _Infinite_Loop()
>>> [00000946](01) 55 push ebp
>>> [00000947](02) 8bec mov ebp,esp
>>> [00000949](02) ebfe jmp 00000949
>>> [0000094b](01) 5d pop ebp
>>> [0000094c](01) c3 ret
>>> Size in bytes:(0007) [0000094c]
>>>> Oh yes; you have one simulator executing another that's
>>>> executing the test program. So you are doing all of this!!!!! Where are
>>>> you storing the 64K++ remembered state for each inner instruction
>>>> instruction execution? (Hint, that state includes the instruction
>>>> executions of inner simulator. Whoops!)
>>>>
>>>> Basically do you have enough combined memory and secondary storage to
>>>> simulate 100 instructions of the test program? And if so, where are you
>>> 4GB is available to the simulator it operates in 32-bit mode.
>>>> storing all that state and state of the other level??? You might do it
>>>> by delta modulation and hashing but we know that isn't the case. You
>>>> would have been so excited to discover such a way of saving orders and
>>>> orders of magnitude storage, that you would have proclaimed it
>>>> loudly to
>>>> the world and put a copyright on the pronouncement as soon as your
>>>> congratulatory masturbation session was over.
>>>>
>>>> No. Couldn't happen that way. No coding recently. Too busy spewing
>>>> nonsense. No real simulation and loop detection. Just eye ball the
>>>> trace
>>>> and look for duplicate addresses. Aha! That's why you can't run any one
>>>> else's test cases - you can't automatically spot even simple loops for
>>>> sure. Well at least your current production is up to that high
>>>> standards
>>>> that you've set for yourself.
>>> machine stack stack machine assembly
>>> address address data code language
>>> ======== ======== ======== ========= =============
>>> ...[000009d6][00211368][0021136c] 55 push ebp // enter P
>>> ...[000009d7][00211368][0021136c] 8bec mov ebp,esp
>>> ...[000009d9][00211368][0021136c] 8b4508 mov eax,[ebp+08]
>>> ...[000009dc][00211364][000009d6] 50 push eax // Push P
>>> ...[000009dd][00211364][000009d6] 8b4d08 mov ecx,[ebp+08]
>>> ...[000009e0][00211360][000009d6] 51 push ecx // Push P
>>> ...[000009e1][0021135c][000009e6] e840feffff call 00000826 // Call H
>>> ...[000009d6][0025bd90][0025bd94] 55 push ebp // enter P
>>> ...[000009d7][0025bd90][0025bd94] 8bec mov ebp,esp
>>> ...[000009d9][0025bd90][0025bd94] 8b4508 mov eax,[ebp+08]
>>> ...[000009dc][0025bd8c][000009d6] 50 push eax // Push P
>>> ...[000009dd][0025bd8c][000009d6] 8b4d08 mov ecx,[ebp+08]
>>> ...[000009e0][0025bd88][000009d6] 51 push ecx // Push P
>>> ...[000009e1][0025bd84][000009e6] e840feffff call 00000826 // Call H
>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>> It is totally obvious that P calls H twice with the same params, thus
>>> proving that the call will never return.
>>>
>> Superfically it looks totally obvious that H is just popping P and P
>> from the stack, and calling them. Then it is indeed stuck in infinite
>> recursion. And that's what Ben claims it is doing. But, in that case,
>> H isn't a halt decider. And you've said that H simulates P(P).
>>
>
> I spent 1.5 man-years on this.
>
>> Now we've just had a political discussion about lying in the UK. I
>> want to emphasis that if in fact H calls P(P), that doesn't necessarily
>> mean that you were lying when you said it "simulated it". Maybe you
>> weren't clear in your own mind what a nested simulator does.
>> However you do need to take this opportunity to clarify the point.
>>
>
> Ben used the correct term re-entrant. H is re-entrant.
> https://github.com/wfeldt/libx86emu
>
>> As part of the clarification, you need to explain why the second part of
>> the execution trace shows the instructions at P, making it look as though
>> H calls P, rather than the instructions executed by the simulator.
>>
>
> To eliminate 264 pages of purely extraneous detail of the execution
> trace of H.

olcott <NoOne@NoWhere.com> writes:

>>> The halting problem *is not* about P(P) when P(P) is not
>>> computationally equivalent to the correct simulation of the input to
>>> H(P,P).
>>
>> Citation? Oh, you don't have one -- you just made this mantra up to
>> explain (or, failing that, deflect attention from) why the wrong answer
>> should be the right answer.
>
> Anyone knowing the x86 language can verify this.

That you claim the wrong answer is the right one has been crystal clear
when you talk about C, x86 assembler and Turing machines. There you are
saying as clear as day above.

>> You really should have worked harder at obscuring what the answer is.
>> When, over three years ago, you lied about... sorry, when you used
>> "poetic license" to say that you had a pair of actual Turing machines,
>> fully encoded that decides the key case, you would not say. I asked
>> again and again what answer your "poetically licenced" H gave for (Ĥ,Ĥ)
>> but you would not answer. /That's/ how it's done. Don't leak even a
>> single bit of information. Keep everything secret (like you keep the
>> magic code secret).
>> Ever since you were clear that H(P,P) == false "even though P(P) halts"
>> you have been fighting a rearguard action to defend this nonsense. It's
>> a losing battle, though like all bad generals, you won't leave the field
>> with honour.

--
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

On 4/23/2022 6:02 PM, olcott wrote:
> On 4/23/2022 6:52 PM, Jeff Barnett wrote:
>> On 4/23/2022 4:07 PM, olcott wrote:
>>> On 4/23/2022 4:47 PM, Jeff Barnett wrote:
>>
>> <SNIP?
>>
>>>>> Since I explained "how" I made my simulator re-entrant:
>>>>> Each simulation has its own registers, RAM and stack,
>>>>> and this is what is required to make my simulator re-entrant and
>>>>> every post that I have provided for many months shows that each
>>>>> subsequent simulation does have its own 64K stack your guess has
>>>>> been refuted.
>>>
>>>> So to tell if you were in a loop, you needed to compare for equality
>>>> 1) the "mapped" address of the instructions counter, 2) the contents
>>>> of all programmable registers and all interior non-programmable
>>>> registers mapped as necessary, 3) the total 64K stacks (can't count
>>>> on tame references in user level code), 4) whether you are in a
>>>> state were the hardware is doing an interior execution, aka, one for
>>>> the road, and 5) a lot more.
>>>
>>> <sarcasm>
>>> Yes that is true, to be able to tell that the follwing code has an
>>> infinite loop we must check at least 100,000 different things
>>> </sarcasm>
>>>
>>> _Infinite_Loop()
>>> [00000946](01)  55              push ebp
>>> [00000947](02)  8bec            mov ebp,esp
>>> [00000949](02)  ebfe            jmp 00000949
>>> [0000094b](01)  5d              pop ebp
>>> [0000094c](01)  c3              ret
>>> Size in bytes:(0007) [0000094c]
>>
>> You can be as sarcastic and as foolish as you want but it wont help
>> you detect loops. To detect much other than jump to self involves
>> comparing total state - if they differ and you cannot *prove* the
>> difference makes no difference, you can't declare "loop". I don't
>> think you knew that and I think you will now make some sort of non
>> relevant retort or just go away.
>>
>
> I have already had this extensively reviewed.
>
>> "State" is a software engineering and computation concept that is not
>> part of your background. In stead of spreading so much BS, you might
>> engage your brain instead of your mouth for a minute. Of course, this
>> assumes you have a functional nervous system but that is questionable.
>> It also explains why the projects you were able to cite for your SE
>> background were dismal failures according to the articles you cited to
>> describe them. They looked like the typical PO design, code, and fail
>> cycle that all have noted here for years.
>>
>
> I have two patents on finite state machines.
>
>>>> Oh yes; you have one simulator executing another that's executing
>>>> the test program. So you are doing all of this!!!!! Where are you
>>>> storing the 64K++ remembered state for each inner instruction
>>>> instruction execution? (Hint, that state includes the instruction
>>>> executions of inner simulator. Whoops!)
>>>>
>>>> Basically do you have enough combined memory and secondary storage
>>>> to simulate 100 instructions of the test program? And if so, where
>>>> are you
>>>
>>> 4GB is available to the simulator it operates in 32-bit mode.
>>
>> So how many test-program instruction executions can you execute and
>> maintain state for before running out of memory? Since the interior
>> simulator is probably executing several dozen (maybe several hundred)
>> instructions for every test-program instruction, I doubt that you
>> could trace a simple sort of a list of a 100 strings of average length
>> 10 characters. That's assuming you maintain complete state which of
>> course you are not doing. (Common belief of readers here is that you
>> are using your untrustworthy eyeball.)
>>
>
> I configure my system for its specific purpose, it can be configured
> differently.
I'd get busy since it's a incorrect pile of POOP at the moment.

>>>> storing all that state and state of the other level??? You might do
>>>> it by delta modulation and hashing but we know that isn't the case.
>>>> You would have been so excited to discover such a way of saving
>>>> orders and orders of magnitude storage, that you would have
>>>> proclaimed it loudly to the world and put a copyright on the
>>>> pronouncement as soon as your congratulatory masturbation session
>>>> was over.
>>>>
>>>> No. Couldn't happen that way. No coding recently. Too busy spewing
>>>> nonsense. No real simulation and loop detection. Just eye ball the
>>>> trace and look for duplicate addresses. Aha! That's why you can't
>>>> run any one else's test cases - you can't automatically spot even
>>>> simple loops for sure. Well at least your current production is up
>>>> to that high standards that you've set for yourself.
>>>
>>>      machine   stack     stack     machine    assembly
>>>      address   address   data      code       language
>>>      ========  ========  ========  =========  =============
>>> ...[000009d6][00211368][0021136c] 55         push ebp         // enter P
>>> ...[000009d7][00211368][0021136c] 8bec       mov ebp,esp
>>> ...[000009d9][00211368][0021136c] 8b4508     mov eax,[ebp+08]
>>> ...[000009dc][00211364][000009d6] 50         push eax         // Push P
>>> ...[000009dd][00211364][000009d6] 8b4d08     mov ecx,[ebp+08]
>>> ...[000009e0][00211360][000009d6] 51         push ecx         // Push P
>>> ...[000009e1][0021135c][000009e6] e840feffff call 00000826    // Call H
>>> ...[000009d6][0025bd90][0025bd94] 55         push ebp         // enter P
>>> ...[000009d7][0025bd90][0025bd94] 8bec       mov ebp,esp
>>> ...[000009d9][0025bd90][0025bd94] 8b4508     mov eax,[ebp+08]
>>> ...[000009dc][0025bd8c][000009d6] 50         push eax         // Push P
>>> ...[000009dd][0025bd8c][000009d6] 8b4d08     mov ecx,[ebp+08]
>>> ...[000009e0][0025bd88][000009d6] 51         push ecx         // Push P
>>> ...[000009e1][0025bd84][000009e6] e840feffff call 00000826    // Call H
>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>
>>> It is totally obvious that P calls H twice with the same params, thus
>>> proving that the call will never return.
>>
>> Of course it isn't obvious! Are you that goofy???? P might, for
>> example, reference a global store that has changed or the overflow bit
>> or, or, or, and or, and so on. No matter what you say or write to
>> defend your nonsense, you just dig further into the POOP. (Is that a
>> pun son?)
>
> H only emulates its input with an x86 emulator until it recognizes a
> repeating pattern.
Read the above messages in this thread. Turn on any remnants of brain if
any are present. Realize that your present unwieldy mess can do nothing
of the sort in the vast, vast majority of cases. This problem and even
its baby relatives are just too hard for you.
Try something easier like writing a parity checking TM. Ben gave the
whole show away when he suggested unary representation. (Makes a trivial
problem even more trivial.) Even that was too hard for you so no big boy
pants in your wardrobe yet. I'm not sure which level Ben was teaching
these things on but I'd guess first or second year undergraduates. That
seems too difficult for you. I know a fellow who was teaching High
School kids, If you ask, I'll see if he'll give me some of those
exercises to pass to you. But only if you ask.
--
Jeff Barnett

On 4/23/2022 7:07 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> Ben used the correct term re-entrant. H is re-entrant.
>
> Though I was not talking about H of course.
>
>>> As part of the clarification, you need to explain why the second part of
>>> the execution trace shows the instructions at P, making it look as though
>>> H calls P, rather than the instructions executed by the simulator.
>>
>> To eliminate 264 pages of purely extraneous detail of the execution
>> trace of H.
>
> So you post edited traces?
>

Since H merely simulates its input using an x86 emulator until after it
recognizes the repeating pattern H cannot possibly have any effect on
the behavior of this input thus these 264 pages of execution trace are
simply extraneous complexity.

A competent software engineer would understand that I am correct about
this.

--
Copyright 2022 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> That the x86 language is totally over your head does not mean that I
> have not totally proved this point.

Would you like to have a head-to-head x86 "language" programming
challenge? That would be fun! Who would your pick to set the exercise
and judge the results? (It would have to be OS neutral -- I'm not going
to run Windows just to prove a point.)

By the way, you are 100% correct: that you have not proved your point
has nothing whatsoever to do with my level of x86 knowledge.

--
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

On 4/23/2022 7:15 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>>>> The halting problem *is not* about P(P) when P(P) is not
>>>> computationally equivalent to the correct simulation of the input to
>>>> H(P,P).
>>>
>>> Citation? Oh, you don't have one -- you just made this mantra up to
>>> explain (or, failing that, deflect attention from) why the wrong answer
>>> should be the right answer.
>>
>> Anyone knowing the x86 language can verify this.
>
> That you claim the wrong answer is the right one has been crystal clear
> when you talk about C, x86 assembler and Turing machines. There you are
> saying as clear as day above.
>

That you are technically incompetent to validate my proof is no actual
rebuttal at all.

It is a verified fact that P(P) and the correctly simulated input to
H(P,P) are not computationally equivalent and thus have different
halting behavior because of this lack of computational equivalence.

That you believe that P(P) and the correctly simulated input to H(P,P)
are computationally equivalent is getting a little ridiculous, face the
facts man !!!

Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

--
Copyright 2022 Pete Olcott

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