XPost: sci.logic

On 5/22/24 10:07 PM, olcott wrote:

On 5/22/2024 6:01 PM, Richard Damon wrote:

On 5/22/24 5:19 PM, olcott wrote:

On 6/24/2022 2:53 AM, Malcolm McLean wrote:

He's dry-run P(P) and established that it doesn't halt. He's invoked
H on it
and H reports that it doesn't halt. He's run P(P) and it halts.

So something odd is going on there that needs an explanation.

*MUCH BETTER WORDS THAN ONE YEAR AGO*
*MUCH BETTER WORDS THAN ONE YEAR AGO*
*MUCH BETTER WORDS THAN ONE YEAR AGO*

typedef int (*ptr)();  // ptr is pointer to int function in C
00       int H(ptr p, ptr i);
01       int D(ptr p)
02       {
03         int Halt_Status = H(p, p);
04         if (Halt_Status)
05           HERE: goto HERE;
06         return Halt_Status;
07       }
08
09       int main()
10       {
11         H(D,D);
12         return 0;
13       }

In the above case a simulator is an x86 emulator that correctly emulates >>> at least one of the x86 instructions of D in the order specified by the
x86 instructions of D.

This may include correctly emulating the x86 instructions of H in the
order specified by the x86 instructions of H thus calling H(D,D) in
recursive simulation.

It is trivial to see that for every H/D pair of the infinite
set of H/D pairs that match the above template that

D correctly simulated by H cannot possibly reach its own final
state at line 06 and halt because D correctly simulated by
H remains stuck in recursive simulation.

Deciders are only accountable for the behavior of their inputs
and are thus not allowed to report on the behavior of the computation
that they themselves are contained within.

No. "Behavior of their inputss" MEANS for Turing Machines that are
computing properties of Turing Machines (like Halt Deciders) have the
"behavior of their input" defined as the Behavior of the machine their
input represents/describes/specifies.

Only specifies and no matter how many times you deny it,
it remains a verified fact that:
the input to H
the input to H
the input to H
the input to H
the input to H
the input to H
the input to H
specifies that it never reaches its own final state and halts.

No since when the input is run, and that is the behavior the input
SPECIFIED (per the definiton) it will HALT.

THAT is the behavior that it specifies.

It may be that H can not simulate to that point, but that is just a
limitation in your design for H. I have shown you a design, which is implementable as a Turing Machine equivalent (at least if you assume you
can handle the detection of the D(D) calling H(D,D) problem) that can
get past that point. And for other versions of D where the is an answer
that H could give and be correct, can actually prove that it has a
corret answer.

This shows that you don't understand what you are talking about, and
just p=spouting off your normal garbage.

And, there is no rule that prohibits that machine given as a
representation from including a copy of the machine that is deciding
on it.

The rule is the deciders operate on inputs and thus cannot possibly
operate on their own actual selves.

Right, but they CAN operation on a description of themselves.

You forget, Deciders don't operation directly on machines, and since
they ARE a machine, we can't give "themselves" to them, or ANY other
machine as an input. What we can do is give a representation/description/specification that can just as easily be of
what they are as any other machine.

Yes, you litterally can't phrase the question as being about "The
machine you are contained within",

Everyone has always implicitly assumed this false assumption.

Nope. It seems only YOU think it is that question.

but you can give the description of that machine and ask about it.

That is one level of indirection away from the actual machine and
provides the incorrect basis for saying that "this sentence is not true"
is true on the basis of:
This sentence is not true: "This sentence is not true" is true.

Which is just red herring and shows you don't understand what the
problems is.

This is why I have asked you to actually write out a FORMAL
SPECIFICATION for what H is, what its input is, and what it is trying to
decide on.

The point is that Turing Machines don't have that sort of "reference"
to allow the use of the pronoun to reference the machine, you need to
actually give the machine (by an encoding of it).

When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

embedded_H is not operating on itself it is operating
one level of indirect reference away from its actual self.
*THIS CHANGES EVERYTHING*

It is operating on a description of itself.

It STILL Must give the same answer as H, and must pass that answer to
H^, which will make that answer wrong.

Of course, all of this is beyound your understanding because it seems
you STILL don't understand what it means to be a Turing Machine.

There is no Turing machine that can possibly take its actual
self as an input because actual Turing Machines are not allowed
as inputs to other Turing Machines.

But representations of them are, so we CAN ask Turing Machine about
the behavior of a Turing Machine that includes a copy of itself.

*thus the behavior of D(D) executed from main() has always been moot*
*thus the behavior of D(D) executed from main() has always been moot*
*thus the behavior of D(D) executed from main() has always been moot*

No, because that is what DEFINES Halting.

I already proved otherwise. That you ignored or failed to
understand this proof does not mean that I didn't already
prove otherwise.

IMPOSSIBLE, becasuse the DEFINITION IS THE DEFINITION.

So, you are just admitting to being a LIAR that doesn't understand what
things mean.

It is categorically impossible to prove a definition is "incorrect', at
best you can prove a definition make the system inconsistant, but you
haven't done that for halting either.

All you prove to be inconsistent, is your own logic.

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

XPost: sci.logic

On 5/22/24 10:33 PM, olcott wrote:

On 5/22/2024 9:27 PM, Richard Damon wrote:

On 5/22/24 10:07 PM, olcott wrote:

On 5/22/2024 6:01 PM, Richard Damon wrote:

On 5/22/24 5:19 PM, olcott wrote:

On 6/24/2022 2:53 AM, Malcolm McLean wrote:

He's dry-run P(P) and established that it doesn't halt. He's
invoked H on it
and H reports that it doesn't halt. He's run P(P) and it halts.

So something odd is going on there that needs an explanation.

*MUCH BETTER WORDS THAN ONE YEAR AGO*
*MUCH BETTER WORDS THAN ONE YEAR AGO*
*MUCH BETTER WORDS THAN ONE YEAR AGO*

typedef int (*ptr)();  // ptr is pointer to int function in C
00       int H(ptr p, ptr i);
01       int D(ptr p)
02       {
03         int Halt_Status = H(p, p);
04         if (Halt_Status)
05           HERE: goto HERE;
06         return Halt_Status;
07       }
08
09       int main()
10       {
11         H(D,D);
12         return 0;
13       }

In the above case a simulator is an x86 emulator that correctly
emulates
at least one of the x86 instructions of D in the order specified by
the
x86 instructions of D.

This may include correctly emulating the x86 instructions of H in the >>>>> order specified by the x86 instructions of H thus calling H(D,D) in
recursive simulation.

It is trivial to see that for every H/D pair of the infinite
set of H/D pairs that match the above template that

D correctly simulated by H cannot possibly reach its own final
state at line 06 and halt because D correctly simulated by
H remains stuck in recursive simulation.

Deciders are only accountable for the behavior of their inputs
and are thus not allowed to report on the behavior of the computation >>>>> that they themselves are contained within.

No. "Behavior of their inputss" MEANS for Turing Machines that are
computing properties of Turing Machines (like Halt Deciders) have
the "behavior of their input" defined as the Behavior of the machine
their input represents/describes/specifies.

Only specifies and no matter how many times you deny it,
it remains a verified fact that:
the input to H
the input to H
the input to H
the input to H
the input to H
the input to H
the input to H
specifies that it never reaches its own final state and halts.

No since when the input is run,

*That has nothing to do with*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*

*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*

Sure it does.

What else does the question: Does the program described to the decider
halt mean other than that?

You just don't understand the maning of the words, because you never
studied them, but are just GUESSING, and guessing wrong.

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

XPost: sci.logic

Op 23.mei.2024 om 04:52 schreef olcott:

On 5/22/2024 9:38 PM, Richard Damon wrote:

On 5/22/24 10:33 PM, olcott wrote:

On 5/22/2024 9:27 PM, Richard Damon wrote:

On 5/22/24 10:07 PM, olcott wrote:

On 5/22/2024 6:01 PM, Richard Damon wrote:

On 5/22/24 5:19 PM, olcott wrote:

On 6/24/2022 2:53 AM, Malcolm McLean wrote:

He's dry-run P(P) and established that it doesn't halt. He's
invoked H on it
and H reports that it doesn't halt. He's run P(P) and it halts. >>>>>>>>
So something odd is going on there that needs an explanation.

*MUCH BETTER WORDS THAN ONE YEAR AGO*
*MUCH BETTER WORDS THAN ONE YEAR AGO*
*MUCH BETTER WORDS THAN ONE YEAR AGO*

typedef int (*ptr)();  // ptr is pointer to int function in C
00       int H(ptr p, ptr i);
01       int D(ptr p)
02       {
03         int Halt_Status = H(p, p);
04         if (Halt_Status)
05           HERE: goto HERE;
06         return Halt_Status;
07       }
08
09       int main()
10       {
11         H(D,D);
12         return 0;
13       }

In the above case a simulator is an x86 emulator that correctly
emulates
at least one of the x86 instructions of D in the order specified >>>>>>> by the
x86 instructions of D.

This may include correctly emulating the x86 instructions of H in >>>>>>> the
order specified by the x86 instructions of H thus calling H(D,D) in >>>>>>> recursive simulation.

It is trivial to see that for every H/D pair of the infinite
set of H/D pairs that match the above template that

D correctly simulated by H cannot possibly reach its own final
state at line 06 and halt because D correctly simulated by
H remains stuck in recursive simulation.

Deciders are only accountable for the behavior of their inputs
and are thus not allowed to report on the behavior of the
computation
that they themselves are contained within.

No. "Behavior of their inputss" MEANS for Turing Machines that are >>>>>> computing properties of Turing Machines (like Halt Deciders) have
the "behavior of their input" defined as the Behavior of the
machine their input represents/describes/specifies.

Only specifies and no matter how many times you deny it,
it remains a verified fact that:
the input to H
the input to H
the input to H
the input to H
the input to H
the input to H
the input to H
specifies that it never reaches its own final state and halts.

No since when the input is run,

*That has nothing to do with*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*

*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*

Sure it does.

What else does the question: Does the program described to the decider
halt mean other than that?

*That is the FREAKING WRONG QUESTION*

*NO ONE KNEW THAT IS WAS THE WRONG QUESTION*
*ONLY BECAUSE EVERYONE REJECTED A SIMULATING*
*TERMINATION ANALYZER OUT-OF-HAND WITHOUT REVIEW*

D of every H/D pair where D is correctly simulated
by H cannot possibly reach is own line 06 and halt.

The failure to provide a counter-example will be
construed as proof of this.

The failure to provide a counter example is not a proof.

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

XPost: sci.logic

On 5/22/24 10:52 PM, olcott wrote:

On 5/22/2024 9:38 PM, Richard Damon wrote:

On 5/22/24 10:33 PM, olcott wrote:

On 5/22/2024 9:27 PM, Richard Damon wrote:

On 5/22/24 10:07 PM, olcott wrote:

On 5/22/2024 6:01 PM, Richard Damon wrote:

On 5/22/24 5:19 PM, olcott wrote:

On 6/24/2022 2:53 AM, Malcolm McLean wrote:

He's dry-run P(P) and established that it doesn't halt. He's
invoked H on it
and H reports that it doesn't halt. He's run P(P) and it halts. >>>>>>>>
So something odd is going on there that needs an explanation.

*MUCH BETTER WORDS THAN ONE YEAR AGO*
*MUCH BETTER WORDS THAN ONE YEAR AGO*
*MUCH BETTER WORDS THAN ONE YEAR AGO*

typedef int (*ptr)();  // ptr is pointer to int function in C
00       int H(ptr p, ptr i);
01       int D(ptr p)
02       {
03         int Halt_Status = H(p, p);
04         if (Halt_Status)
05           HERE: goto HERE;
06         return Halt_Status;
07       }
08
09       int main()
10       {
11         H(D,D);
12         return 0;
13       }

In the above case a simulator is an x86 emulator that correctly
emulates
at least one of the x86 instructions of D in the order specified >>>>>>> by the
x86 instructions of D.

This may include correctly emulating the x86 instructions of H in >>>>>>> the
order specified by the x86 instructions of H thus calling H(D,D) in >>>>>>> recursive simulation.

It is trivial to see that for every H/D pair of the infinite
set of H/D pairs that match the above template that

D correctly simulated by H cannot possibly reach its own final
state at line 06 and halt because D correctly simulated by
H remains stuck in recursive simulation.

Deciders are only accountable for the behavior of their inputs
and are thus not allowed to report on the behavior of the
computation
that they themselves are contained within.

No. "Behavior of their inputss" MEANS for Turing Machines that are >>>>>> computing properties of Turing Machines (like Halt Deciders) have
the "behavior of their input" defined as the Behavior of the
machine their input represents/describes/specifies.

Only specifies and no matter how many times you deny it,
it remains a verified fact that:
the input to H
the input to H
the input to H
the input to H
the input to H
the input to H
the input to H
specifies that it never reaches its own final state and halts.

No since when the input is run,

*That has nothing to do with*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*

*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*

Sure it does.

What else does the question: Does the program described to the decider
halt mean other than that?

*That is the FREAKING WRONG QUESTION*

Then you aren't talking about the HALTING PROBLEM.

You don't get to tell people the problem they want to solve is the wrong problem, and it is a LIE to say some other different problem answers the
one they have.

*NO ONE KNEW THAT IS WAS THE WRONG QUESTION*
*ONLY BECAUSE EVERYONE REJECTED A SIMULATING*
*TERMINATION ANALYZER OUT-OF-HAND WITHOUT REVIEW*

NO, because your "Termination Analyzers" don't solve the problem that
was being asked of the Halting Decider.

D of every H/D pair where D is correctly simulated
by H cannot possibly reach is own line 06 and halt.

And who cares abot that, if it can be true but when we actually run D(D)
it halts.

The failure to provide a counter-example will be
construed as proof of this.

Your last claim == proof that you don't understand how logic works.

You have wasted your last 20 years, because you just didn't understand
what you were talking about.

You have turned yourself into a pathological liar because you have
taught yourself to ignore things that disagree with you, and you pretend
they don't exist, and then you think you can correctly say they don't,
when it is just a lie.

Your are worse then the election deniers. You refuse to look at the
evidence. At least there claim has a possibility of having a chance to
be logically true, since absence of proof is not a proof of absence, and
there could be a deep state lying machine hiding the evidence.

In your case, evidence is put before you, but you just can't understand
it because you have closed your mind to to truth.

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

XPost: sci.logic

On 5/23/24 9:18 AM, olcott wrote:

On 5/23/2024 2:12 AM, Fred. Zwarts wrote:

Op 23.mei.2024 om 04:52 schreef olcott:

On 5/22/2024 9:38 PM, Richard Damon wrote:

On 5/22/24 10:33 PM, olcott wrote:

On 5/22/2024 9:27 PM, Richard Damon wrote:

On 5/22/24 10:07 PM, olcott wrote:

On 5/22/2024 6:01 PM, Richard Damon wrote:

On 5/22/24 5:19 PM, olcott wrote:

On 6/24/2022 2:53 AM, Malcolm McLean wrote:

He's dry-run P(P) and established that it doesn't halt. He's >>>>>>>>>> invoked H on it
and H reports that it doesn't halt. He's run P(P) and it halts. >>>>>>>>>>
So something odd is going on there that needs an explanation. >>>>>>>>>

*MUCH BETTER WORDS THAN ONE YEAR AGO*
*MUCH BETTER WORDS THAN ONE YEAR AGO*
*MUCH BETTER WORDS THAN ONE YEAR AGO*

typedef int (*ptr)();  // ptr is pointer to int function in C >>>>>>>>> 00       int H(ptr p, ptr i);
01       int D(ptr p)
02       {
03         int Halt_Status = H(p, p);
04         if (Halt_Status)
05           HERE: goto HERE;
06         return Halt_Status;
07       }
08
09       int main()
10       {
11         H(D,D);
12         return 0;
13       }

In the above case a simulator is an x86 emulator that correctly >>>>>>>>> emulates
at least one of the x86 instructions of D in the order
specified by the
x86 instructions of D.

This may include correctly emulating the x86 instructions of H >>>>>>>>> in the
order specified by the x86 instructions of H thus calling
H(D,D) in
recursive simulation.

It is trivial to see that for every H/D pair of the infinite >>>>>>>>> set of H/D pairs that match the above template that

D correctly simulated by H cannot possibly reach its own final >>>>>>>>> state at line 06 and halt because D correctly simulated by
H remains stuck in recursive simulation.

Deciders are only accountable for the behavior of their inputs >>>>>>>>> and are thus not allowed to report on the behavior of the
computation
that they themselves are contained within.

No. "Behavior of their inputss" MEANS for Turing Machines that >>>>>>>> are computing properties of Turing Machines (like Halt Deciders) >>>>>>>> have the "behavior of their input" defined as the Behavior of
the machine their input represents/describes/specifies.

Only specifies and no matter how many times you deny it,
it remains a verified fact that:
the input to H
the input to H
the input to H
the input to H
the input to H
the input to H
the input to H
specifies that it never reaches its own final state and halts.

No since when the input is run,

*That has nothing to do with*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*

*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*

Sure it does.

What else does the question: Does the program described to the
decider halt mean other than that?

*That is the FREAKING WRONG QUESTION*

*NO ONE KNEW THAT IS WAS THE WRONG QUESTION*
*ONLY BECAUSE EVERYONE REJECTED A SIMULATING*
*TERMINATION ANALYZER OUT-OF-HAND WITHOUT REVIEW*

D of every H/D pair where D is correctly simulated
by H cannot possibly reach is own line 06 and halt.

The failure to provide a counter-example will be
construed as proof of this.

The failure to provide a counter example is not a proof.

OK then Church-Turing is a wild guess.

Which is why it is "Thesis", accepted as most probably true, but not
proven, and not a Theorem, like the Halting Theorem, which HAS been conclusively proven.

You are just making it clear you don't understand the basics of logic.

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