On 4/23/2022 7:27 PM, Ben wrote:
> 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.
>

That you cannot comprehend that the correctly simulated input to H(P,P)
specifies a non-halting sequence of configurations conclusively proves
that your understanding of the x86 language is woefully inadequate for
the purposes of understanding my proof.

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

> On 4/22/2022 7:00 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> 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.
>> Let's imagine we are in PO land... We've finally understood the mistake
>> that everyone else has been making -- it's not about what P(P) does but
>
> about the actual behavior of the actual input: H(P,P)
> int X = sum(3,4); must produce 7 or it is wrong.

No, the answer must be 12. No, sorry, it should be g, surely? Perhaps
you should specify this "addition problem" properly?

>> that <mindless monotone>the input to H(P,P) specifies non-halting
>> behaviour</mindless monotone>. We publish. No one cares. We are
>> surprised; people /still/ want to know if a function call halts or not.
>> They /still/ want a function D such that D(X,Y) returns true iff X(Y)
>> halts and false otherwise and our telling them that what matters is that
>> <mindless monotone>the input to H(P,P) specifies non-halting
>> behaviour</mindless monotone> seems to leave them cold.
>> Strange, I know, but they seem to want to now of their programs halt,
>> not if <mindless monotone>the input to H specifies non-halting
>> behaviour</mindless monotone>. There's no accounting for taste.

No comment on the substantive point, as usual: the problem you are now
ignoring -- the halting problem -- does not go away. It's still there,
even in PO land.

--
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:38 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/22/2022 7:00 PM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> 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.
>>> Let's imagine we are in PO land... We've finally understood the mistake
>>> that everyone else has been making -- it's not about what P(P) does but
>>
>> about the actual behavior of the actual input: H(P,P)
>> int X = sum(3,4); must produce 7 or it is wrong.
>
> No, the answer must be 12. No, sorry, it should be g, surely? Perhaps
> you should specify this "addition problem" properly?
>
>>> that <mindless monotone>the input to H(P,P) specifies non-halting
>>> behaviour</mindless monotone>. We publish. No one cares. We are
>>> surprised; people /still/ want to know if a function call halts or not.
>>> They /still/ want a function D such that D(X,Y) returns true iff X(Y)
>>> halts and false otherwise and our telling them that what matters is that
>>> <mindless monotone>the input to H(P,P) specifies non-halting
>>> behaviour</mindless monotone> seems to leave them cold.
>>> Strange, I know, but they seem to want to now of their programs halt,
>>> not if <mindless monotone>the input to H specifies non-halting
>>> behaviour</mindless monotone>. There's no accounting for taste.
>
> No comment on the substantive point, as usual: the problem you are now
> ignoring -- the halting problem -- does not go away. It's still there,
> even in PO land.
>

The key fact (that is perpetually over your head) is that the input to
H(P,P) specifies a non-halting sequence of configurations making it
necessarily correct for H to reject this input.

It is your failure to acknowledge this key fact (because of your
woefully inadequate technical competence on the x86 language) that keeps
us stuck on this point.

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

> On 4/23/2022 7:07 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>> (attribution lost. This is Malcolm McLean:)

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

An honest person would answer the question.

--
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:36 PM, olcott wrote:
> On 4/23/2022 7:27 PM, Ben wrote:
>> 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.
>>
>
> That you cannot comprehend that the correctly simulated input to H(P,P)
> specifies a non-halting sequence of configurations conclusively proves
> that your understanding of the x86 language is woefully inadequate for
> the purposes of understanding my proof.
>

Except you normally don't show a "Correct Simulation". you show an
aborted simulation (which is by definition not correct). You did once
show a correct simulation, and it showed the input Halts.

Your problem is that you want to define something besides what the
halting problem defines as a "correct simulation" as what you will treat
as a correct simulation, so it just means you aren't working on the
halting problem.

You sometimes almost clearly state that you disagree with how the
Halting Problem is stated, and admit you are replacing it with something
different. The problem is you aren't allowed to change the definition of
the problem, all you have done is ADMIT that the halting problem, as
classically defined actually is impossible and attempt to replace it
with something we might call "PO-Halting", and show that this proof
doesn't show that PO-Halting is impossible.

Ultimate, the failure of that method is that it doesn't actually
disprove the classical Halting Problem, and all the reasons you seem to
want to remove it are still in place, as they still refer to the
classical problem, and not your revised PO-Halting Problem.

olcott <NoOne@NoWhere.com> writes:

> On 4/23/2022 7:27 PM, Ben wrote:
>> 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.
>
> That you cannot comprehend that the correctly simulated input to
> H(P,P) specifies a non-halting sequence of configurations conclusively
> proves that your understanding of the x86 language is woefully
> inadequate for the purposes of understanding my proof.

Don't be a spoil-sport! Let's see who really knows x86 "language"
better!

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

Jeff Barnett <jbb@notatt.com> writes:

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

Second year undergraduates: "B22 Models of Computation".

--
Ben.

On 4/23/2022 8:00 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/23/2022 7:07 PM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>> (attribution lost. This is Malcolm McLean:)
>
>>>>> 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.
>
> An honest person would answer the question.
>

The traces that I post are direct output.

--
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 8:25 PM, olcott wrote:
> 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.
>

Except the logic that "detected" this repeating pattern was unsound, and
presumes that the simulated H doesn't behave the same as the simulating H.

A competent software engineer would see through your ruse and realise
your error.

The fact that you can't says something about your own skill.

On 4/23/22 8:54 PM, olcott wrote:
> On 4/23/2022 7:38 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/22/2022 7:00 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> 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.
>>>> Let's imagine we are in PO land...  We've finally understood the
>>>> mistake
>>>> that everyone else has been making -- it's not about what P(P) does but
>>>
>>> about the actual behavior of the actual input: H(P,P)
>>> int X = sum(3,4); must produce 7 or it is wrong.
>>
>> No, the answer must be 12.  No, sorry, it should be g, surely?  Perhaps
>> you should specify this "addition problem" properly?
>>
>>>> that <mindless monotone>the input to H(P,P) specifies non-halting
>>>> behaviour</mindless monotone>.  We publish.  No one cares.  We are
>>>> surprised; people /still/ want to know if a function call halts or not.
>>>> They /still/ want a function D such that D(X,Y) returns true iff X(Y)
>>>> halts and false otherwise and our telling them that what matters is
>>>> that
>>>> <mindless monotone>the input to H(P,P) specifies non-halting
>>>> behaviour</mindless monotone> seems to leave them cold.
>>>> Strange, I know, but they seem to want to now of their programs halt,
>>>> not if <mindless monotone>the input to H specifies non-halting
>>>> behaviour</mindless monotone>.  There's no accounting for taste.
>>
>> No comment on the substantive point, as usual: the problem you are now
>> ignoring -- the halting problem -- does not go away.  It's still there,
>> even in PO land.
>>
>
> The key fact (that is perpetually over your head) is that the input to
> H(P,P) specifies a non-halting sequence of configurations making it
> necessarily correct for H to reject this input.
>
> It is your failure to acknowledge this key fact (because of your
> woefully inadequate technical competence on the x86 language) that keeps
> us stuck on this point.
>

Except that yo fail to see that the input to H(P,P) actually specifies a
HALTING computation if H(P,P) returns 0, as even you have previously proven.

On 4/23/2022 8:02 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/23/2022 7:27 PM, Ben wrote:
>>> 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.
>>
>> That you cannot comprehend that the correctly simulated input to
>> H(P,P) specifies a non-halting sequence of configurations conclusively
>> proves that your understanding of the x86 language is woefully
>> inadequate for the purposes of understanding my proof.
>
> Don't be a spoil-sport! Let's see who really knows x86 "language"
> better!
>

The only possible way to solve difficult problems such as refuting the
halting problem proof requires me to be at least 1000-fold more focused
on the point. Everyone else in the world has 90 years and that was not
nearly enough time for them.

You are missing the knowledge of the x86 language sufficient to
understand what I am saying, everything else that you may know about it
is beside the point.

--
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 8:33 PM, olcott wrote:
> 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 think they differ is proof that you aren't working on the
Halting Problem.
>
> 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 !!!
>

How do you deal with:

H applied to <M> w -> Qy iff M applied to w Halts and
H applied to <M> w -> Qn iff M applied to w never Halts.

This DEFINES the "behavior" of the input that H is supposed to look at
as being exactly the computation M applied to w.

This translates to the behavior of the input to H(P,P) refers to P(P).

That you disagree, either says you totally don't understand the theory
at all, or you have discarded that definitions and working on some other
problem.

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

On 4/23/22 9:15 PM, olcott wrote:
> On 4/23/2022 8:02 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/23/2022 7:27 PM, Ben wrote:
>>>> 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.
>>>
>>> That you cannot comprehend that the correctly simulated input to
>>> H(P,P) specifies a non-halting sequence of configurations conclusively
>>> proves that your understanding of the x86 language is woefully
>>> inadequate for the purposes of understanding my proof.
>>
>> Don't be a spoil-sport!  Let's see who really knows x86 "language"
>> better!
>>
>
> The only possible way to solve difficult problems such as refuting the
> halting problem proof requires me to be at least 1000-fold more focused
> on the point. Everyone else in the world has 90 years and that was not
> nearly enough time for them.
>
> You are missing the knowledge of the x86 language sufficient to
> understand what I am saying, everything else that you may know about it
> is beside the point.
>

No, you are missing basic knowledge of the problem you are trying to
work on.

olcott <NoOne@NoWhere.com> writes:

> On 4/23/2022 8:00 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/23/2022 7:07 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>> (attribution lost. This is Malcolm McLean:)
>>
>>>>>> 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.
>> An honest person would answer the question.
>
> The traces that I post are direct output.

Oh dear. The traces you post show no evidence of any simulation. What
are we to make of that?

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

olcott <NoOne@NoWhere.com> writes:

> The key fact (that is perpetually over your head) is that the input to
> H(P,P) specifies a non-halting sequence of configurations making it
> necessarily correct for H to reject this input.

By prior definition, the two pointers passed to H denote a computation
whose halting or otherwise H should determine. H(P,P)==false is wrong
because P(P) halts. The question of finding a C-like function H such
that H(X,Y) is true iff X(Y) halts and false otherwise existed before
you even decided to start wasting time on it, and it continues to exist
even though you've decided to waffle about what inputs specify. It
won't go away.

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

On 4/24/2022 6:56 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> The key fact (that is perpetually over your head) is that the input to
>> H(P,P) specifies a non-halting sequence of configurations making it
>> necessarily correct for H to reject this input.
>
> By prior definition, the two pointers passed to H denote a computation
> whose halting or otherwise H should determine.

Yes and their correct simulation conclusively proves that the input is
non-halting. This is over your head so we are stuck.

> H(P,P)==false is wrong
> because P(P) halts. The question of finding a C-like function H such
> that H(X,Y) is true iff X(Y) halts and false otherwise existed before
> you even decided to start wasting time on it, and it continues to exist
> even though you've decided to waffle about what inputs specify. It
> won't go away.
>

--
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/24/2022 6:56 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> The key fact (that is perpetually over your head) is that the input to
>> H(P,P) specifies a non-halting sequence of configurations making it
>> necessarily correct for H to reject this input.
>
> By prior definition, the two pointers passed to H denote a computation
> whose halting or otherwise H should determine. H(P,P)==false is wrong
> because P(P) halts.

Only if we assume that P(P) is computationally equivalent to the correct
simulation of the input to H(P,P).

When we understand that that P(P) is NOT computationally equivalent to
the correct simulation of the input to H(P,P) THEN THEY ARE NOT REQUIRED
TO HAVE THE SAME HALTING BEHAVIOR.

Do you comprehend this much or is this over your head too?

> The question of finding a C-like function H such
> that H(X,Y) is true iff X(Y) halts and false otherwise existed before
> you even decided to start wasting time on it, and it continues to exist
> even though you've decided to waffle about what inputs specify. It
> won't go away.
>

--
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/24/22 11:04 PM, olcott wrote:
> On 4/24/2022 6:56 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> The key fact (that is perpetually over your head) is that the input to
>>> H(P,P) specifies a non-halting sequence of configurations making it
>>> necessarily correct for H to reject this input.
>>
>> By prior definition, the two pointers passed to H denote a computation
>> whose halting or otherwise H should determine.  H(P,P)==false is wrong
>> because P(P) halts.
>
> Only if we assume that P(P) is computationally equivalent to the correct
> simulation of the input to H(P,P).

Then what do you consider the correct simulation of the input, and does
that make you definition of a Halt Decider match the classic theory.

Since the DEFINITION of a Halt Decider is that

H applied to <M> w returns Halting iff M applied to w Halts, and
H applied to <M> w returns Non_Halting iff M applied to w never halts,

Unless the correct simulation of the input <M> w means the behavior of a
UTM applied to <M> w which is DEFINED to match M applied to w, then your
decision criteria is NOT the Halting problem, but something else.

You are welcome to define another problem, but it isn't Halting.

>
> When we understand that that P(P) is NOT computationally equivalent to
> the correct simulation of the input to H(P,P) THEN THEY ARE NOT REQUIRED
> TO HAVE THE SAME HALTING BEHAVIOR.

Then how does it match the Halting Problem?

Different requirements, different problem.

>
> Do you comprehend this much or is this over your head too?

Do you understand the meaning of requirements and definitions?

If the correct simulation of the input is NOT precisely the same as an
ACTUAL UTM simulation, then your criteria is provably DIFFERENT than the
Halting Problem and thus you H is NOT even actually claiming to be a
Halt Decider.

Your argument that the definition is wrong is incorrect, if we aren't
allowed to ask a Turing Machine Decider this question, then that just
proves from the start that no such Turing Machine exsists.

You don't get to replace to problem. That violates the basic rules of
logic (which you don't seem to understand either).

On 4/24/22 10:17 PM, olcott wrote:
> On 4/24/2022 6:56 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> The key fact (that is perpetually over your head) is that the input to
>>> H(P,P) specifies a non-halting sequence of configurations making it
>>> necessarily correct for H to reject this input.
>>
>> By prior definition, the two pointers passed to H denote a computation
>> whose halting or otherwise H should determine.
>
> Yes and their correct simulation conclusively proves that the input is
> non-halting. This is over your head so we are stuck.

No, the CORRECT simulation (aka UTM) shows that it is Halting if H
applied to <H^> <H^> or H(P,P) return the non-halting value.

Only H's INCOMPLETE (and thus incorrect) simulation never reached the
final state, but only becuase it stopped too soon because it was
programmed with a bad rule set.

Halting is defined for Turing Machines, and the Turing Machine doesn't
stop running until it reaches a final state, so a correct simulation
doesn't stop before it reaches a final state.

Also, ALL copies of a computation give the same answer with the same
input, so if one H aborts its simulation, ALL copies will for the same
input, so either H never aborts and doesn't answer, or it aborts too
early and the correct simulation will see halting.

>
>> H(P,P)==false is wrong
>> because P(P) halts.  The question of finding a C-like function H such
>> that H(X,Y) is true iff X(Y) halts and false otherwise existed before
>> you even decided to start wasting time on it, and it continues to exist
>> even though you've decided to waffle about what inputs specify.  It
>> won't go away.
>>
>
>

On 4/24/2022 10:38 PM, Richard Damon wrote:
> On 4/24/22 11:04 PM, olcott wrote:
>> On 4/24/2022 6:56 PM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> The key fact (that is perpetually over your head) is that the input to
>>>> H(P,P) specifies a non-halting sequence of configurations making it
>>>> necessarily correct for H to reject this input.
>>>
>>> By prior definition, the two pointers passed to H denote a computation
>>> whose halting or otherwise H should determine.  H(P,P)==false is wrong
>>> because P(P) halts.
>>
>> Only if we assume that P(P) is computationally equivalent to the
>> correct simulation of the input to H(P,P).
>
> Then what do you consider the correct simulation of the input, and does
> that make you definition of a Halt Decider match the classic theory.
>

void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
return;
}

int main()
{ Output("Input_Halts = ", H((u32)P, (u32)P));
}

The above two match the classical theory.

_P()
[000009d6](01) 55 push ebp
[000009d7](02) 8bec mov ebp,esp
[000009d9](03) 8b4508 mov eax,[ebp+08]
[000009dc](01) 50 push eax // push P
[000009dd](03) 8b4d08 mov ecx,[ebp+08]
[000009e0](01) 51 push ecx // push P
[000009e1](05) e840feffff call 00000826 // call H
[000009e6](03) 83c408 add esp,+08
[000009e9](02) 85c0 test eax,eax
[000009eb](02) 7402 jz 000009ef
[000009ed](02) ebfe jmp 000009ed
[000009ef](01) 5d pop ebp
[000009f0](01) c3 ret // Final state
Size in bytes:(0027) [000009f0]

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

The above two specify the actual behavior of the simulated input, when
we understand that H only simulates its input until it reaches
[000009e1] again.

> Since the DEFINITION of a Halt Decider is that
>
> H applied to <M> w returns Halting iff M applied to w Halts, and
> H applied to <M> w returns Non_Halting iff M applied to w never halts,
>
> Unless the correct simulation of the input <M> w means the behavior of a
> UTM applied to <M> w which is DEFINED to match M applied to w, then your
> decision criteria is NOT the Halting problem, but something else.
>
> You are welcome to define another problem, but it isn't Halting.
>
>>
>> When we understand that that P(P) is NOT computationally equivalent to
>> the correct simulation of the input to H(P,P) THEN THEY ARE NOT
>> REQUIRED TO HAVE THE SAME HALTING BEHAVIOR.
>
> Then how does it match the Halting Problem?
>
> Different requirements, different problem.
>
>>
>> Do you comprehend this much or is this over your head too?
>
> Do you understand the meaning of requirements and definitions?
>
> If the correct simulation of the input is NOT precisely the same as an
> ACTUAL UTM simulation, then your criteria is provably DIFFERENT than the
> Halting Problem and thus you H is NOT even actually claiming to be a
> Halt Decider.
>
> Your argument that the definition is wrong is incorrect, if we aren't
> allowed to ask a Turing Machine Decider this question, then that just
> proves from the start that no such Turing Machine exsists.
>
> You don't get to replace to problem. That violates the basic rules of
> logic (which you don't seem to understand either).

--
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/25/22 12:06 AM, olcott wrote:
> On 4/24/2022 10:38 PM, Richard Damon wrote:
>> On 4/24/22 11:04 PM, olcott wrote:
>>> On 4/24/2022 6:56 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> The key fact (that is perpetually over your head) is that the input to
>>>>> H(P,P) specifies a non-halting sequence of configurations making it
>>>>> necessarily correct for H to reject this input.
>>>>
>>>> By prior definition, the two pointers passed to H denote a computation
>>>> whose halting or otherwise H should determine.  H(P,P)==false is wrong
>>>> because P(P) halts.
>>>
>>> Only if we assume that P(P) is computationally equivalent to the
>>> correct simulation of the input to H(P,P).
>>
>> Then what do you consider the correct simulation of the input, and
>> does that make you definition of a Halt Decider match the classic theory.
>>
>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> The above two match the classical theory.
>
> _P()
> [000009d6](01) 55         push ebp
> [000009d7](02) 8bec       mov ebp,esp
> [000009d9](03) 8b4508     mov eax,[ebp+08]
> [000009dc](01) 50         push eax         // push P
> [000009dd](03) 8b4d08     mov ecx,[ebp+08]
> [000009e0](01) 51         push ecx         // push P
> [000009e1](05) e840feffff call 00000826    // call H
> [000009e6](03) 83c408     add esp,+08
> [000009e9](02) 85c0       test eax,eax
> [000009eb](02) 7402       jz 000009ef
> [000009ed](02) ebfe       jmp 000009ed
> [000009ef](01) 5d         pop ebp
> [000009f0](01) c3         ret              // Final state
> Size in bytes:(0027) [000009f0]
>
> 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
>
> The above two specify the actual behavior of the simulated input, when
> we understand that H only simulates its input until it reaches
> [000009e1] again.

And why is that CORRECT?

Since if H is defined that way, it becomes trivial to prove that P(P)
will Halt, and thus the results of the Halting Function Halts(P(P)) is
Halting, so the correct asnwer for H if it claims to be computing that
function is Halting.

Remember the definition of a Computable Function. There needs to exist
an effective procedure/method that computes the mapping of the function.

If H doesn't map P,P -> Halts, then it doesn't compute the Halting
Function, so it isn't a Halt Decider.

olcott <polcott2@gmail.com> writes:

> On 4/24/2022 6:56 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> The key fact (that is perpetually over your head) is that the input to
>>> H(P,P) specifies a non-halting sequence of configurations making it
>>> necessarily correct for H to reject this input.
>> By prior definition, the two pointers passed to H denote a computation
>> whose halting or otherwise H should determine.
>
> Yes

That's a start. What computation to you agree they denote?

> and their correct simulation conclusively proves that the input is
> non-halting. This is over your head so we are stuck.

The correct response to this depends on your answer to the above, so I
don't expect I'll ever have to respond to this.

>> H(P,P)==false is wrong
>> because P(P) halts. The question of finding a C-like function H such
>> that H(X,Y) is true iff X(Y) halts and false otherwise existed before
>> you even decided to start wasting time on it, and it continues to exist
>> even though you've decided to waffle about what inputs specify. It
>> won't go away.

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

olcott <NoOne@NoWhere.com> writes:

> On 4/24/2022 6:56 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> The key fact (that is perpetually over your head) is that the input to
>>> H(P,P) specifies a non-halting sequence of configurations making it
>>> necessarily correct for H to reject this input.
>> By prior definition, the two pointers passed to H denote a computation
>> whose halting or otherwise H should determine. H(P,P)==false is wrong
>> because P(P) halts.
>
> Only if we assume that P(P) is computationally equivalent to the
> correct simulation of the input to H(P,P).

The halting problem is as stated regardless of whether P(P) is or not
computationally equivalent to anything else. The issue is that no
C-like code can return true for H(X,Y) if and only if X(Y) halts
(technically returns) and false otherwise. You H fails by definition.

Every crank thread eventually comes down to rejected definitions. You
are free to address the other problem which deals with whatever other
you think is not "computationally equivalent" to P(P), but there is no
pressing reason for anyone to care about it. The rest of the world want
H(X,Y) to be correct about X(Y).

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

On 4/25/2022 4:19 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/24/2022 6:56 PM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> The key fact (that is perpetually over your head) is that the input to
>>>> H(P,P) specifies a non-halting sequence of configurations making it
>>>> necessarily correct for H to reject this input.
>>> By prior definition, the two pointers passed to H denote a computation
>>> whose halting or otherwise H should determine. H(P,P)==false is wrong
>>> because P(P) halts.
>>
>> Only if we assume that P(P) is computationally equivalent to the
>> correct simulation of the input to H(P,P).
>
> The halting problem is as stated regardless of whether P(P) is or not
> computationally equivalent to anything else. The issue is that no
> C-like code can return true for H(X,Y) if and only if X(Y) halts
> (technically returns) and false otherwise. You H fails by definition.
>

A halt decider cannot be a mind reader. It must report on the actual
behavior of the actual input.

Because of pathological self-reference P(P) has different behavior than
the correct simulation of the input to H(P,P). That you deny this when
you don't know the x86 language is dishonest.

> Every crank thread eventually comes down to rejected definitions. You
> are free to address the other problem which deals with whatever other
> you think is not "computationally equivalent" to P(P), but there is no
> pressing reason for anyone to care about it. The rest of the world want
> H(X,Y) to be correct about X(Y).
>

--
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/25/22 5:24 PM, olcott wrote:
> On 4/25/2022 4:19 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/24/2022 6:56 PM, Ben wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> The key fact (that is perpetually over your head) is that the input to
>>>>> H(P,P) specifies a non-halting sequence of configurations making it
>>>>> necessarily correct for H to reject this input.
>>>> By prior definition, the two pointers passed to H denote a computation
>>>> whose halting or otherwise H should determine.  H(P,P)==false is wrong
>>>> because P(P) halts.
>>>
>>> Only if we assume that P(P) is computationally equivalent to the
>>> correct simulation of the input to H(P,P).
>>
>> The halting problem is as stated regardless of whether P(P) is or not
>> computationally equivalent to anything else.  The issue is that no
>> C-like code can return true for H(X,Y) if and only if X(Y) halts
>> (technically returns) and false otherwise.  You H fails by definition.
>>
>
> A halt decider cannot be a mind reader. It must report on the actual
> behavior of the actual input.

No, it must give the answer to the question that is actually asked.

If you can't translate the question to a proper input to your machine,
then that just proves that your machine doesn't meet the requirements.

The QUESTION is the controlling definition.

The QUESTION is "Does M(w) Halt?"

If you can't show how to computationally translate this question to a
finite string input for H, then you have failed to provide an H that is
even a candidate to be a Halt Decider.

Then, you need to show that H returns the right answer.

If H(P,P) doesn't ask if P(P) Halts, then H(P,P) isn't the right way to
ask the question, so we don't care what it does, but need you to define
how we actually ask the right question.

If it doesn't exist, then H fails to be the decider to answer the actual
question.

>
> Because of pathological self-reference P(P) has different behavior than
> the correct simulation of the input to H(P,P). That you deny this when
> you don't know the x86 language is dishonest.

No, it behaves just like the CORRECT simulation, that fact that H can't
correctly do that simulation is irrelevent, H must answer correctly or
be wrong.

>
>> Every crank thread eventually comes down to rejected definitions.  You
>> are free to address the other problem which deals with whatever other
>> you think is not "computationally equivalent" to P(P), but there is no
>> pressing reason for anyone to care about it.  The rest of the world want
>> H(X,Y) to be correct about X(Y).
>>
>
>