XPost: sci.logic

On 1/13/24 7:22 PM, olcott wrote:

In computability theory, the halting problem is the problem of
determining, whether an input finite string pair of program/input
specifies a computation that would reach a final state and terminate normally.

01 int D(ptr x)  // ptr is pointer to int function
02 {
03   int Halt_Status = H(x, x);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }

The input to H(D,D) specifies that D calls its own termination
analyzer as a part of this computation. The prior definition
of the halting problem allowed people to incorrectly ignore this.

A decider computes the mapping from its input...
*The prior definition of the halting problem ignored this*

Except that your D can't be the requried "Computation" as it isn't
dependent on only its defined input, but also what program is deciding it.

Thus, it can't be "Run" on its own, since when running as a program, it
doesn't HAVE a "termination analyzer.

So, you have just started on a wrong foot with a bad starting point.

The ACTUAL program you are trying to represent, is built from a SPECIFIC "Termination Analyzer" that it is being designed to prove wrong.

Every Termination Analyzer will have such a program, but the program
isn't limited to that Analyzer, but is a full program on its own right.

Said program to be provided as input, ALWAYS has a correct answer to the question, andwill always be exactly the opposite of the answer the one
specific decider it was built on says.

You are just showing that you have wasted 20 years of your life on a
simple mistake.

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

XPost: sci.logic

On 1/13/24 8:23 PM, olcott wrote:

On 1/13/2024 6:30 PM, Richard Damon wrote:

On 1/13/24 7:22 PM, olcott wrote:

In computability theory, the halting problem is the problem of
determining, whether an input finite string pair of program/input
specifies a computation that would reach a final state and terminate
normally.

01 int D(ptr x)  // ptr is pointer to int function
02 {
03   int Halt_Status = H(x, x);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }

The input to H(D,D) specifies that D calls its own termination
analyzer as a part of this computation. The prior definition
of the halting problem allowed people to incorrectly ignore this.

A decider computes the mapping from its input...
*The prior definition of the halting problem ignored this*

Except that your D can't be the requried "Computation"

D specifies that it calls H *THIS CANNOT BE IGNORED* and
is a mandatory aspect of the computation specified by D.

*My corrected halting problem specification makes this more clear*

The original specification <IS WRONG> in that it does not require
that all deciders MUST COMPUTE THE MAPPING FROM THEIR INPUT...

A simple think to point out.

If you took your code for D, and JUST that code, and tried to compile
it, can you run it?

NO, because it refers to an undefined symbol, that of H.

Thus, this D is NOT a "Program" or a "Computation" and thus is not of
the domain that the Halting Problem looks at.

This makes your arguement just a dishonest strawman.

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

XPost: sci.logic

On 1/13/24 8:23 PM, olcott wrote:

On 1/13/2024 6:30 PM, Richard Damon wrote:

On 1/13/24 7:22 PM, olcott wrote:

In computability theory, the halting problem is the problem of
determining, whether an input finite string pair of program/input
specifies a computation that would reach a final state and terminate
normally.

01 int D(ptr x)  // ptr is pointer to int function
02 {
03   int Halt_Status = H(x, x);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }

The input to H(D,D) specifies that D calls its own termination
analyzer as a part of this computation. The prior definition
of the halting problem allowed people to incorrectly ignore this.

A decider computes the mapping from its input...
*The prior definition of the halting problem ignored this*

Except that your D can't be the requried "Computation"

D specifies that it calls H *THIS CANNOT BE IGNORED* and
is a mandatory aspect of the computation specified by D.

But it is a SPECIFIC H, not the H that happens to be deciding it at the
time.

Thus, your code isn't complete and doesn't define the "Computation" that
is being decided on.

You don't seem to understand that you keep on talking about a bunch of different things you call H, when, to be logical, you need to make the
symbol H refer to a specific thing in the context where it has been
selected.

*My corrected halting problem specification makes this more clear*

The original specification <IS WRONG> in that it does not require
that all deciders MUST COMPUTE THE MAPPING FROM THEIR INPUT...

How is that? The input is the description of the machine and input they
are deciding on.

That could be the complete listing of state transitions, and a copy of
the input tape for the machine to decide on.

For a "Computer Program", it could be the COMPLETE assembly code of the
PROGRAM being decided on. That would be the COMPLETE assembly code,
including all levels of subroutines that it calls, including, for this
D, the code of the H that D was defined to be built on.


The properly defined input has no "reference" in it, so is incapable of
having your pathological self-reference.

That only comes because you have built your input incorrectly.

The fact that your "D" isn't a computation any more just shows that you
are just to stupid to understand what you are supposed to be doing.

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

XPost: sci.logic

On 1/14/24 01:22, olcott wrote:

In computability theory, the halting problem is the problem of
determining, whether an input finite string pair of program/input
specifies a computation that would reach a final state and terminate normally.

01 int D(ptr x)  // ptr is pointer to int function
02 {
03   int Halt_Status = H(x, x);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }

The input to H(D,D) specifies that D calls its own termination
analyzer as a part of this computation. The prior definition
of the halting problem allowed people to incorrectly ignore this.

A decider computes the mapping from its input...
*The prior definition of the halting problem ignored this*

your definition still ignores it

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

XPost: sci.logic

On 1/14/24 10:31 AM, olcott wrote:

On 1/14/2024 4:42 AM, Mikko wrote:

On 2024-01-14 00:22:10 +0000, olcott said:

In computability theory, the halting problem is the problem of
determining, whether an input finite string pair of program/input
specifies a computation that would reach a final state and terminate
normally.

The definition of the halting problem does not specify "normally".
Termination just means a situation where continuation is not possible.
Non-termination means that such situation does ever occur even when
the program runs forever.

computation that halts… “the Turing machine will halt whenever it enters a final state” (Linz:1990:234)  In other words Line 06 of D shown below.

Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)

Most people here are making the mistake of believing that when
the simulation of D is aborted then this simulated D halts.
This is wrong. D correctly simulated by H cannot possibly reach
its own final state at line 06.

There is no error in the problem specification. The problem is
well defined. It just is not Turing-solvable.

The key error is that everyone believes that it is not
required to report on the finite string that its input
*SPECIFIES*, thus is allowed to report on the direct
execution of D(D).

Deciders are not allowed to do this they compute the
mapping from their inputs on the basis of what these
inputs specify.

01 int D(ptr x)  // ptr is pointer to int function
02 {
03   int Halt_Status = H(x, x);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }

The input to H(D,D) specifies that D calls its own termination
analyzer as a part of this computation. The prior definition
of the halting problem allowed people to incorrectly ignore this.

Somebody may ignore that particular case but the specification of
the halting problem

Is wrong. All deciders must compute the mapping from their input...
They are not allowed to report on non inputs.

But the input is supposed to be a full specification of an actual
program (which your above is NOT, since it doesn't specify what H
actually is), and that full program does have a mapping of behavior.

So, your above definition must FIRST be augmented with the source code
of the H that is part of this program to be the input to the decider.

*Because of this my corrected version says*
determining, whether an input finite string pair of program/input
*SPECIFIES* a computation that would reach a final state...

Right, so the input must specify a computation, which your above is NOT
unless you also include in it the full code of H.

So, it is assumed that we are also including in the definition of D, the
H that you are going build this D on.

Input D correctly simulated by H *SPECIFIES* a computation
that cannot possibly halt.

Right, but that only applies to the Halting Problem if your H you are
claiming is the correct Halting Decider is exactly a UTM, that actually
does a correct simulation, and never aborts, so you prove THAT version
of D is non-halting, it says nothing about any othe D built on some other H.

Remember, the H that D is built on is part of the input, so one H can
not look at a D built on some other version of H and claim to be doing
the decision from the proof.

I dared everyone here to show the detailed execution trace
where D correctly simulated by H halts and they could not
because this is not possible.

No, its has been done, and you are right, if D is correctly simulated by
H, then neither D(D) or H(D,D) ever return an answer.

*Instead they continue to make COUNTER-FACTUAL ASSUMPTIONS*
*IT IS A VERIFIED FACT THAT D correctly simulated by H DOES NOT HALT*

And such an H fails to be a decider, so isn't a conter example.

Once you try to change H to abort, you have changes your D and you no
longer hae

says unambigously that
unless (H(D, D) != 1) <-> D(D) halts
then H is not a halting decider.

Right, IF D(D) Halts, then H(D,D) must return 1 or H is not a correct
halting decider. Since your H(D,D) returns 0, and the D built on that H
halts when run, your H is not a correct halting decider.

and if D(D) doesn't halt, then H(D,D) must return 0, so, your H that
actually does the correct simulation and thus creates a D(D) that
doesn't halt, must return 0, but it doesn't, so it isn't a correct
Halting Decider.

Thus, you haven't shown a correct halting decider to be the counter
example you claim.

Mikko

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

XPost: sci.logic

On 1/14/24 16:31, olcott wrote:

On 1/14/2024 4:42 AM, Mikko wrote:

On 2024-01-14 00:22:10 +0000, olcott said:

In computability theory, the halting problem is the problem of
determining, whether an input finite string pair of program/input
specifies a computation that would reach a final state and terminate
normally.

The definition of the halting problem does not specify "normally".
Termination just means a situation where continuation is not possible.
Non-termination means that such situation does ever occur even when
the program runs forever.

computation that halts… “the Turing machine will halt whenever it enters a final state” (Linz:1990:234)  In other words Line 06 of D shown below.

Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)

Most people here are making the mistake of believing that when
the simulation of D is aborted then this simulated D halts.

Nobody is making this mistake. You are making the mistake of believing
that if the simulation is aborted then the directly executed D does not
halt OR you are making the mistake of believing that a simulation which
differs from a direct execution can possibly be correct.

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

XPost: sci.logic

On 1/14/24 16:45, olcott wrote:

On 1/14/2024 1:31 AM, immibis wrote:

On 1/14/24 01:22, olcott wrote:

In computability theory, the halting problem is the problem of
determining, whether an input finite string pair of program/input
specifies a computation that would reach a final state and terminate
normally.

01 int D(ptr x)  // ptr is pointer to int function
02 {
03   int Halt_Status = H(x, x);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }

The input to H(D,D) specifies that D calls its own termination
analyzer as a part of this computation. The prior definition
of the halting problem allowed people to incorrectly ignore this.

A decider computes the mapping from its input...
*The prior definition of the halting problem ignored this*

your definition still ignores it

whether an input finite string pair of program/input

specifies a computation that would reach a final state<<<

All deciders are required to compute the mapping from their inputs
in this case on the basis of the behavior SPECIFIED by this input.

do you understand waht these words mean?

*This input specifies that it calls H in recursive simulation*

your input in x86utm does. Linz's input which is a Turing machine does
not. His one is actually a modified copy of H.

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

XPost: sci.logic

On 1/14/24 02:23, olcott wrote:

On 1/13/2024 6:30 PM, Richard Damon wrote:

On 1/13/24 7:22 PM, olcott wrote:

In computability theory, the halting problem is the problem of
determining, whether an input finite string pair of program/input
specifies a computation that would reach a final state and terminate
normally.

01 int D(ptr x)  // ptr is pointer to int function
02 {
03   int Halt_Status = H(x, x);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }

The input to H(D,D) specifies that D calls its own termination
analyzer as a part of this computation. The prior definition
of the halting problem allowed people to incorrectly ignore this.

A decider computes the mapping from its input...
*The prior definition of the halting problem ignored this*

Except that your D can't be the requried "Computation"

D specifies that it calls H *THIS CANNOT BE IGNORED* and
is a mandatory aspect of the computation specified by D.

"Calls H" is not an allowed Turing machine transition so you have
admitted your program has nothing to do with the Turing machine halting problem. A transition specifies a tape direction, next state, and symbol
to write. It cannot specify "calls H".

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

XPost: sci.logic

On 1/14/24 1:53 PM, olcott wrote:

On 1/14/2024 12:37 PM, immibis wrote:

On 1/14/24 16:45, olcott wrote:

On 1/14/2024 1:31 AM, immibis wrote:

On 1/14/24 01:22, olcott wrote:

In computability theory, the halting problem is the problem of
determining, whether an input finite string pair of program/input
specifies a computation that would reach a final state and terminate >>>>> normally.

01 int D(ptr x)  // ptr is pointer to int function
02 {
03   int Halt_Status = H(x, x);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }

The input to H(D,D) specifies that D calls its own termination
analyzer as a part of this computation. The prior definition
of the halting problem allowed people to incorrectly ignore this.

A decider computes the mapping from its input...
*The prior definition of the halting problem ignored this*

your definition still ignores it

;whether an input finite string pair of program/input

specifies a computation that would reach a final state<<<

All deciders are required to compute the mapping from their inputs
in this case on the basis of the behavior SPECIFIED by this input.

do you understand waht these words mean?

*This input specifies that it calls H in recursive simulation*

your input in x86utm does. Linz's input which is a Turing machine does
not. His one is actually a modified copy of H.

⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach its
own simulated final state of ⟨Ĥ.qn⟩. I had to study the Linz
proof for 18 years before I noticed this.

In other words, NO, you do not understand what the words mean.

Since your H doesn't "Correctly Simulate" its input, that results dosn't matter.

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

XPost: sci.logic

On 1/14/24 1:51 PM, olcott wrote:

On 1/14/2024 12:31 PM, immibis wrote:

On 1/14/24 16:31, olcott wrote:

On 1/14/2024 4:42 AM, Mikko wrote:

On 2024-01-14 00:22:10 +0000, olcott said:

In computability theory, the halting problem is the problem of
determining, whether an input finite string pair of program/input
specifies a computation that would reach a final state and terminate >>>>> normally.

The definition of the halting problem does not specify "normally".
Termination just means a situation where continuation is not possible. >>>> Non-termination means that such situation does ever occur even when
the program runs forever.

computation that halts… “the Turing machine will halt whenever it
enters a final state” (Linz:1990:234)  In other words Line 06 of D
shown below.

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)

Most people here are making the mistake of believing that when
the simulation of D is aborted then this simulated D halts.

Nobody is making this mistake. You are making the mistake of believing
that if the simulation is aborted then the directly executed D does
not halt OR you are making the mistake of believing that a simulation
which differs from a direct execution can possibly be correct.

Mike Terry agrees that every step of the older H that simulates
itself simulating D is correct. He examined the x86 machine code
to verify this.

Which makes it a correct PARTIAL simulation, not a correct simulation.

Thus, your logic is still invalid.

H has NOT correctly determined that a correct simulation of the input
would not halt.

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

XPost: sci.logic

On 1/14/24 3:05 PM, olcott wrote:

On 1/14/2024 1:10 PM, Richard Damon wrote:

On 1/14/24 1:51 PM, olcott wrote:

On 1/14/2024 12:31 PM, immibis wrote:

On 1/14/24 16:31, olcott wrote:

On 1/14/2024 4:42 AM, Mikko wrote:

On 2024-01-14 00:22:10 +0000, olcott said:

In computability theory, the halting problem is the problem of
determining, whether an input finite string pair of program/input >>>>>>> specifies a computation that would reach a final state and terminate >>>>>>> normally.

The definition of the halting problem does not specify "normally". >>>>>> Termination just means a situation where continuation is not
possible.
Non-termination means that such situation does ever occur even when >>>>>> the program runs forever.

computation that halts… “the Turing machine will halt whenever it >>>>> enters a final state” (Linz:1990:234)  In other words Line 06 of D >>>>> shown below.

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)

Most people here are making the mistake of believing that when
the simulation of D is aborted then this simulated D halts.

Nobody is making this mistake. You are making the mistake of
believing that if the simulation is aborted then the directly
executed D does not halt OR you are making the mistake of believing
that a simulation which differs from a direct execution can possibly
be correct.

Mike Terry agrees that every step of the older H that simulates
itself simulating D is correct. He examined the x86 machine code
to verify this.

Which makes it a correct PARTIAL simulation, not a correct simulation.

Thus, your logic is still invalid.

H has NOT correctly determined that a correct simulation of the input
would not halt.

Anyone that is an expert at the C programming language
can verify that this execution trace proves that D
correctly simulated by H never reaches its own simulated
line 06.

01 int D(ptr x)  // ptr is pointer to int function
02 {
03   int Halt_Status = H(x, x);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }
08
09 void main()
10 {
11   H(D,D);
12 }

*Execution Trace*
Line 11: main() invokes H(D,D);

*keeps repeating* (unless aborted)
Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)

*Simulation invariant*
D correctly simulated by H cannot possibly reach past its own line 03.

Which is only true *IF* the H that D calls actually DOES this correct simulation, which means it doesn't abort and thus H(D,D) never ever
returns an answer, and thus H is not a decider.

So yes, you can show that for a particular H, the D based on it is
non-halting, but then also that H fails to answer.

And, we can also show that if H DOES give an answer, what ever it gives
will be wrong.

So, you have proven nothing of your actual claim.

Either H is wrong, or it doesn't answer, and thus also is wrong.

Or, you have just proved that you are nothing but a LIAR.

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

XPost: sci.logic

On 1/14/24 19:53, olcott wrote:

On 1/14/2024 12:37 PM, immibis wrote:

On 1/14/24 16:45, olcott wrote:

On 1/14/2024 1:31 AM, immibis wrote:

On 1/14/24 01:22, olcott wrote:

In computability theory, the halting problem is the problem of
determining, whether an input finite string pair of program/input
specifies a computation that would reach a final state and terminate >>>>> normally.

01 int D(ptr x)  // ptr is pointer to int function
02 {
03   int Halt_Status = H(x, x);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }

The input to H(D,D) specifies that D calls its own termination
analyzer as a part of this computation. The prior definition
of the halting problem allowed people to incorrectly ignore this.

A decider computes the mapping from its input...
*The prior definition of the halting problem ignored this*

your definition still ignores it

;whether an input finite string pair of program/input

specifies a computation that would reach a final state<<<

All deciders are required to compute the mapping from their inputs
in this case on the basis of the behavior SPECIFIED by this input.

do you understand waht these words mean?

*This input specifies that it calls H in recursive simulation*

your input in x86utm does. Linz's input which is a Turing machine does
not. His one is actually a modified copy of H.

⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach its
own simulated final state of ⟨Ĥ.qn⟩.

⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach its
own simulated final state of ⟨Ĥ.qy⟩.

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

XPost: sci.logic

On 1/15/24 06:17, olcott wrote:

On 1/14/2024 11:00 PM, immibis wrote:

On 1/14/24 19:53, olcott wrote:

On 1/14/2024 12:37 PM, immibis wrote:

On 1/14/24 16:45, olcott wrote:

On 1/14/2024 1:31 AM, immibis wrote:

On 1/14/24 01:22, olcott wrote:

In computability theory, the halting problem is the problem of
determining, whether an input finite string pair of program/input >>>>>>> specifies a computation that would reach a final state and terminate >>>>>>> normally.

01 int D(ptr x)  // ptr is pointer to int function
02 {
03   int Halt_Status = H(x, x);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }

The input to H(D,D) specifies that D calls its own termination
analyzer as a part of this computation. The prior definition
of the halting problem allowed people to incorrectly ignore this. >>>>>>>
A decider computes the mapping from its input...
*The prior definition of the halting problem ignored this*

your definition still ignores it

;whether an input finite string pair of program/input

specifies a computation that would reach a final state<<<

All deciders are required to compute the mapping from their inputs
in this case on the basis of the behavior SPECIFIED by this input.

do you understand waht these words mean?

*This input specifies that it calls H in recursive simulation*

your input in x86utm does. Linz's input which is a Turing machine
does not. His one is actually a modified copy of H.

⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach its
own simulated final state of ⟨Ĥ.qn⟩.

⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach its
own simulated final state of ⟨Ĥ.qy⟩.

This state has an infinite loop appended, thus it is not a final state.

My bad. ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach its own simulated state of ⟨Ĥ.qy⟩.

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

XPost: sci.logic

On 1/15/24 06:23, immibis wrote:

On 1/15/24 06:17, olcott wrote:

On 1/14/2024 11:00 PM, immibis wrote:

On 1/14/24 19:53, olcott wrote:

On 1/14/2024 12:37 PM, immibis wrote:

On 1/14/24 16:45, olcott wrote:

On 1/14/2024 1:31 AM, immibis wrote:

On 1/14/24 01:22, olcott wrote:

In computability theory, the halting problem is the problem of >>>>>>>> determining, whether an input finite string pair of program/input >>>>>>>> specifies a computation that would reach a final state and
terminate
normally.

01 int D(ptr x)  // ptr is pointer to int function
02 {
03   int Halt_Status = H(x, x);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }

The input to H(D,D) specifies that D calls its own termination >>>>>>>> analyzer as a part of this computation. The prior definition
of the halting problem allowed people to incorrectly ignore this. >>>>>>>>
A decider computes the mapping from its input...
*The prior definition of the halting problem ignored this*

your definition still ignores it

;whether an input finite string pair of program/input

specifies a computation that would reach a final state<<<

All deciders are required to compute the mapping from their inputs >>>>>> in this case on the basis of the behavior SPECIFIED by this input.

do you understand waht these words mean?

*This input specifies that it calls H in recursive simulation*

your input in x86utm does. Linz's input which is a Turing machine
does not. His one is actually a modified copy of H.

⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach its
own simulated final state of ⟨Ĥ.qn⟩.

⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach its
own simulated final state of ⟨Ĥ.qy⟩.

This state has an infinite loop appended, thus it is not a final state.

My bad. ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach its own simulated state of ⟨Ĥ.qy⟩.

And ⟨Ĥ⟩ directly executed cannot possibly reach its own state of ⟨Ĥ.qy⟩
or ⟨Ĥ.qn⟩

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

XPost: sci.logic

Op 14.jan.2024 om 21:05 schreef olcott:

On 1/14/2024 1:10 PM, Richard Damon wrote:

On 1/14/24 1:51 PM, olcott wrote:

On 1/14/2024 12:31 PM, immibis wrote:

On 1/14/24 16:31, olcott wrote:

On 1/14/2024 4:42 AM, Mikko wrote:

On 2024-01-14 00:22:10 +0000, olcott said:

In computability theory, the halting problem is the problem of
determining, whether an input finite string pair of program/input >>>>>>> specifies a computation that would reach a final state and terminate >>>>>>> normally.

The definition of the halting problem does not specify "normally". >>>>>> Termination just means a situation where continuation is not
possible.
Non-termination means that such situation does ever occur even when >>>>>> the program runs forever.

computation that halts… “the Turing machine will halt whenever it >>>>> enters a final state” (Linz:1990:234)  In other words Line 06 of D >>>>> shown below.

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)

Most people here are making the mistake of believing that when
the simulation of D is aborted then this simulated D halts.

Nobody is making this mistake. You are making the mistake of
believing that if the simulation is aborted then the directly
executed D does not halt OR you are making the mistake of believing
that a simulation which differs from a direct execution can possibly
be correct.

Mike Terry agrees that every step of the older H that simulates
itself simulating D is correct. He examined the x86 machine code
to verify this.

Which makes it a correct PARTIAL simulation, not a correct simulation.

Thus, your logic is still invalid.

H has NOT correctly determined that a correct simulation of the input
would not halt.

Anyone that is an expert at the C programming language
can verify that this execution trace proves that D
correctly simulated by H never reaches its own simulated
line 06.

01 int D(ptr x)  // ptr is pointer to int function
02 {
03   int Halt_Status = H(x, x);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }
08
09 void main()
10 {
11   H(D,D);
12 }

*Execution Trace*
Line 11: main() invokes H(D,D);

*keeps repeating* (unless aborted) > Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)

Apparently, Olcott does not realize that H does abort. Because of that
"*keeps repeating* (unless aborted)" can be replaced with "Does not repeat".

*Simulation invariant*
D correctly simulated by H cannot possibly reach past its own line 03.

And apparently he does not realize that that H, which is part of D and therefore part of the input, does return, so that D continues with line 04.

I an afraid he will never understand this and just keeps repeating
(unless aborted).

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

XPost: sci.logic

On 1/15/24 10:47, Fred. Zwarts wrote:

Op 14.jan.2024 om 21:05 schreef olcott:

*keeps repeating* (unless aborted) > Line 03: simulated D(D) invokes
simulated H(D,D) that simulates D(D)

Apparently, Olcott does not realize that H does abort. Because of that "*keeps repeating* (unless aborted)" can be replaced with "Does not
repeat".

Olcott's "aborted" means the outermost simulation layer chooses to abort
the simulation. Because of his design, the outermost simulation can
choose to abort, but the inner simulations know they are inner
simulations and will never abort. Of course, this leads to an incorrect
halting decision.

The outer H can be said to correctly decide the inner D doesn't abort,
but that means nothing since the inner D is a different program than the
one which it was asked to evaluate.



To put it in a way Olcott might understand, his simulator works like
this one:

void loop(ptr input) {
HERE: goto HERE;
}
int H(ptr program, ptr input) {
begin_simulation(loop, input);
run_until_halt_or_loop_detected();
if(loop_detected)
return 0;
else
return 1;
}

It correctly simulates a looping program and detects a loop, but that
program isn't the one that was input so who cares?

I an afraid he will never understand this and just keeps repeating
(unless aborted).

Heh. Good one.

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

XPost: sci.logic

On 1/15/24 12:26 AM, immibis wrote:

On 1/15/24 06:23, immibis wrote:

On 1/15/24 06:17, olcott wrote:

On 1/14/2024 11:00 PM, immibis wrote:

On 1/14/24 19:53, olcott wrote:

On 1/14/2024 12:37 PM, immibis wrote:

On 1/14/24 16:45, olcott wrote:

On 1/14/2024 1:31 AM, immibis wrote:

On 1/14/24 01:22, olcott wrote:

In computability theory, the halting problem is the problem of >>>>>>>>> determining, whether an input finite string pair of program/input >>>>>>>>> specifies a computation that would reach a final state and
terminate
normally.

01 int D(ptr x)  // ptr is pointer to int function
02 {
03   int Halt_Status = H(x, x);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }

The input to H(D,D) specifies that D calls its own termination >>>>>>>>> analyzer as a part of this computation. The prior definition >>>>>>>>> of the halting problem allowed people to incorrectly ignore this. >>>>>>>>>
A decider computes the mapping from its input...
*The prior definition of the halting problem ignored this*

your definition still ignores it

;whether an input finite string pair of program/input

specifies a computation that would reach a final state<<<

All deciders are required to compute the mapping from their inputs >>>>>>> in this case on the basis of the behavior SPECIFIED by this input. >>>>>>

do you understand waht these words mean?

*This input specifies that it calls H in recursive simulation*

your input in x86utm does. Linz's input which is a Turing machine
does not. His one is actually a modified copy of H.

⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach its >>>>> own simulated final state of ⟨Ĥ.qn⟩.

⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach its
own simulated final state of ⟨Ĥ.qy⟩.

This state has an infinite loop appended, thus it is not a final state.

My bad. ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach
its own simulated state of ⟨Ĥ.qy⟩.

And ⟨Ĥ⟩ directly executed cannot possibly reach its own state of ⟨Ĥ.qy⟩
or ⟨Ĥ.qn⟩

But if it fails to reach one of those states, the only possible reason
is that H failed to be a decider, which is a precondition for it being a
Halt Decider.

Seems you have proven that a machine can't be both a "Correct Simulator"
and a Decider, so a Correct Simulation based Halt Decider is merely a contradiction of terms, like the Barber who shaves everyone who doesn't
shave themselves.

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

XPost: sci.logic

On 1/15/24 15:46, olcott wrote:

The function named D *correctly simulated by H* cannot possibly
reach its own line 06 (final state) and halt. If a function
does not reach its own final state then IT DOES NOT HALT.

What is the definition of "correctly simulated by H"?

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

XPost: sci.logic

Op 15.jan.2024 om 15:46 schreef olcott:

On 1/15/2024 3:47 AM, Fred. Zwarts wrote:

Op 14.jan.2024 om 21:05 schreef olcott:

Anyone that is an expert at the C programming language
can verify that this execution trace proves that D
correctly simulated by H never reaches its own simulated
line 06.

01 int D(ptr x)  // ptr is pointer to int function
02 {
03   int Halt_Status = H(x, x);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }
08
09 void main()
10 {
11   H(D,D);
12 }

*Execution Trace*
Line 11: main() invokes H(D,D);

*keeps repeating* (unless aborted) > Line 03: simulated D(D) invokes
simulated H(D,D) that simulates D(D)

Apparently, Olcott does not realize that H does abort. Because of that
"*keeps repeating* (unless aborted)" can be replaced with "Does not
repeat".

*Simulation invariant*
D correctly simulated by H cannot possibly reach past its own line 03.

And apparently he does not realize that that H, which is part of D and
therefore part of the input, does return, so that D continues with
line 04.

I an afraid he will never understand this and just keeps repeating
(unless aborted).

The function named D *correctly simulated by H* cannot possibly
reach its own line 06 (final state) and halt. If a function
does not reach its own final state then IT DOES NOT HALT.

Apparently, Olcott does not understand that the function H(D,D)
*correctly simulated by H* does return and therefore the function named
D *correctly simulated by H* reaches its own line 04 and then line 06.
This is the H that is included in D and therefore part of the input. The
H that does not return is not part of the input. H must decide on its
input, not on its non-input.

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

XPost: sci.logic

On 1/15/24 17:07, olcott wrote:

[something]

What is the definition of a correct simulation?

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

XPost: sci.logic

On 1/15/24 18:29, olcott wrote:

On 1/15/2024 10:43 AM, immibis wrote:

On 1/15/24 17:07, olcott wrote:

[something]

What is the definition of a correct simulation?

H executes the instructions of D as they are specified in D.

No it doesn't.

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

XPost: sci.logic

On 1/15/24 20:20, olcott wrote:

On 1/15/2024 1:01 PM, immibis wrote:

On 1/15/24 18:29, olcott wrote:

On 1/15/2024 10:43 AM, immibis wrote:

On 1/15/24 17:07, olcott wrote:

[something]

What is the definition of a correct simulation?

H executes the instructions of D as they are specified in D.

No it doesn't.

I think that you know that it does otherwise you could show what these
steps should be.

They are the same steps that are simulated by your program when H1
simulates D. You can easily create the execution trace yourself, if you
want it.

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

XPost: sci.logic

On 1/15/24 21:11, olcott wrote:

On 1/15/2024 1:26 PM, immibis wrote:

On 1/15/24 20:20, olcott wrote:

On 1/15/2024 1:01 PM, immibis wrote:

On 1/15/24 18:29, olcott wrote:

On 1/15/2024 10:43 AM, immibis wrote:

On 1/15/24 17:07, olcott wrote:

[something]

What is the definition of a correct simulation?

H executes the instructions of D as they are specified in D.

No it doesn't.

I think that you know that it does otherwise you could show what
these steps should be.

They are the same steps that are simulated by your program when H1
simulates D. You can easily create the execution trace yourself, if
you want it.

main() invokes D(D) that invokes H(D,D) that returns to D.

main() invokes H(D,D) that simulates D(D) that calls a simulated
H(D,D) that cannot possibly return to its caller. When the invoked
H(D,D) returns to main() this is an entirely different instance
of H thus not the simulated H.

If you change it so main() invokes H1(D,D) you will get the execution
trace you are looking for.

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

XPost: sci.logic

On 1/15/24 7:10 PM, olcott wrote:

On 1/15/2024 1:26 PM, immibis wrote:

On 1/15/24 20:20, olcott wrote:

On 1/15/2024 1:01 PM, immibis wrote:

On 1/15/24 18:29, olcott wrote:

On 1/15/2024 10:43 AM, immibis wrote:

On 1/15/24 17:07, olcott wrote:

[something]

What is the definition of a correct simulation?

H executes the instructions of D as they are specified in D.

No it doesn't.

I think that you know that it does otherwise you could show what
these steps should be.

They are the same steps that are simulated by your program when H1
simulates D. You can easily create the execution trace yourself, if
you want it.

When you try and show every single line number of D correctly
simulated by H then you find out that you are wrong.

Dishonest DODGE of a strawman.

D(D) Halts.

Therefore H(D,D) returning 0 is wrong

To deny that is to admit to being a LIAR as those are the definitions.

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

XPost: sci.logic

On 1/16/24 01:05, olcott wrote:

The inner simulations never have enough information to abort.

They would if you didn't abort them. If you didn't abort the simulation
of them, they would abort, and then halt. Detecting them as non-halting
is incorrect.

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

XPost: sci.logic

On 1/16/24 01:00, olcott wrote:

On 1/14/2024 11:23 PM, immibis wrote:

On 1/15/24 06:17, olcott wrote:

On 1/14/2024 11:00 PM, immibis wrote:

On 1/14/24 19:53, olcott wrote:

On 1/14/2024 12:37 PM, immibis wrote:

On 1/14/24 16:45, olcott wrote:

On 1/14/2024 1:31 AM, immibis wrote:

On 1/14/24 01:22, olcott wrote:

In computability theory, the halting problem is the problem of >>>>>>>>> determining, whether an input finite string pair of program/input >>>>>>>>> specifies a computation that would reach a final state and
terminate
normally.

01 int D(ptr x)  // ptr is pointer to int function
02 {
03   int Halt_Status = H(x, x);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }

The input to H(D,D) specifies that D calls its own termination >>>>>>>>> analyzer as a part of this computation. The prior definition >>>>>>>>> of the halting problem allowed people to incorrectly ignore this. >>>>>>>>>
A decider computes the mapping from its input...
*The prior definition of the halting problem ignored this*

your definition still ignores it

;whether an input finite string pair of program/input

specifies a computation that would reach a final state<<<

All deciders are required to compute the mapping from their inputs >>>>>>> in this case on the basis of the behavior SPECIFIED by this input. >>>>>>

do you understand waht these words mean?

*This input specifies that it calls H in recursive simulation*

your input in x86utm does. Linz's input which is a Turing machine
does not. His one is actually a modified copy of H.

⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach its >>>>> own simulated final state of ⟨Ĥ.qn⟩.

⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach its
own simulated final state of ⟨Ĥ.qy⟩.

This state has an infinite loop appended, thus it is not a final state.

My bad. ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach
its own simulated state of ⟨Ĥ.qy⟩.

⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly halt.

What does "correctly simulated" mean?

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

XPost: sci.logic

On 1/16/24 16:54, olcott wrote:

On 1/16/2024 1:54 AM, immibis wrote:

On 1/16/24 01:05, olcott wrote:

The inner simulations never have enough information to abort.

They would if you didn't abort them.

The inner simulations are one recursive simulation away from
the next outer simulation.

This means that the outermost simulation always has one
recursive simulation more execution trace data than any
inner simulation.

The outermost simulation reaches its abort criteria one
recursive simulation sooner than the next inner one.

The ONLY reason the inner simulation doesn't abort is that the outer
simulation aborts first.

If the outer simulation didn't abort the inner simulation would abort.

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

XPost: sci.logic

On 1/16/24 10:33 AM, olcott wrote:

On 1/16/2024 1:51 AM, immibis wrote:

On 1/16/24 01:00, olcott wrote:

On 1/14/2024 11:23 PM, immibis wrote:

On 1/15/24 06:17, olcott wrote:

On 1/14/2024 11:00 PM, immibis wrote:

On 1/14/24 19:53, olcott wrote:

On 1/14/2024 12:37 PM, immibis wrote:

On 1/14/24 16:45, olcott wrote:

On 1/14/2024 1:31 AM, immibis wrote:

On 1/14/24 01:22, olcott wrote:

In computability theory, the halting problem is the problem of >>>>>>>>>>> determining, whether an input finite string pair of
program/input
specifies a computation that would reach a final state and >>>>>>>>>>> terminate
normally.

01 int D(ptr x)  // ptr is pointer to int function
02 {
03   int Halt_Status = H(x, x);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }

The input to H(D,D) specifies that D calls its own termination >>>>>>>>>>> analyzer as a part of this computation. The prior definition >>>>>>>>>>> of the halting problem allowed people to incorrectly ignore >>>>>>>>>>> this.

A decider computes the mapping from its input...
*The prior definition of the halting problem ignored this* >>>>>>>>>>>

your definition still ignores it

;whether an input finite string pair of program/input

specifies a computation that would reach a final state<<<

All deciders are required to compute the mapping from their inputs >>>>>>>>> in this case on the basis of the behavior SPECIFIED by this input. >>>>>>>>

do you understand waht these words mean?

*This input specifies that it calls H in recursive simulation* >>>>>>>>

your input in x86utm does. Linz's input which is a Turing
machine does not. His one is actually a modified copy of H.

⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach its >>>>>>> own simulated final state of ⟨Ĥ.qn⟩.

⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach its >>>>>> own simulated final state of ⟨Ĥ.qy⟩.

This state has an infinite loop appended, thus it is not a final
state.

My bad. ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach >>>> its own simulated state of ⟨Ĥ.qy⟩.

⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly halt.

What does "correctly simulated" mean?

Correctly simulated means that H correctly executes ear

_DD()
[00001c42] 55         push ebp
[00001c43] 8bec       mov ebp,esp
[00001c45] 51         push ecx
[00001c46] 8b4508     mov eax,[ebp+08] ; DD
[00001c49] 50         push eax         ; DD
[00001c4a] 8b4d08     mov ecx,[ebp+08] ; DD
[00001c4d] 51         push ecx         ; DD
[00001c4e] e80ff7ffff call 00001362    ; HH
[00001c53] 83c408     add esp,+08
[00001c56] 8945fc     mov [ebp-04],eax
[00001c59] 837dfc00   cmp dword [ebp-04],+00
[00001c5d] 7402       jz 00001c61
[00001c5f] ebfe       jmp 00001c5f
[00001c61] 8b45fc     mov eax,[ebp-04]
[00001c64] 8be5       mov esp,ebp
[00001c66] 5d         pop ebp
[00001c67] c3         ret
Size in bytes:(0038) [00001c67]

01 int DD(void (*x)())
02 {
03   int Halt_Status = HH(x, x);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }
08
09 int main()
10 {
11   Output("Input_Halts = ", HH(DD,DD));
12 }

Correct simulation means that the build-in third party x86
emulator emulates the above x86 instructions of DD as they
are specified in DD.

For HH this means that HH simulates itself simulating DD.
The detailed x86 execution trace proves that HH does
simulate itself simulating DD.

Begin Local Halt Decider Simulation        Execution Trace Stored at:113027
[00001c42][00113013][00113017] 55          push ebp [00001c43][00113013][00113017] 8bec        mov ebp,esp [00001c45][0011300f][00102fe3] 51          push ecx [00001c46][0011300f][00102fe3] 8b4508      mov eax,[ebp+08] ; DD [00001c49][0011300b][00001c42] 50          push eax         ; DD
[00001c4a][0011300b][00001c42] 8b4d08      mov ecx,[ebp+08] ; DD [00001c4d][00113007][00001c42] 51          push ecx         ; DD
[00001c4e][00113003][00001c53] e80ff7ffff  call 00001362    ; HH
New slave_stack at:14da47
[00001c42][0015da3b][0015da3f] 55          push ebp [00001c43][0015da3b][0015da3f] 8bec        mov ebp,esp [00001c45][0015da37][0014da0b] 51          push ecx [00001c46][0015da37][0014da0b] 8b4508      mov eax,[ebp+08] ; DD [00001c49][0015da33][00001c42] 50          push eax         ; DD
[00001c4a][0015da33][00001c42] 8b4d08      mov ecx,[ebp+08] ; DD [00001c4d][0015da2f][00001c42] 51          push ecx         ; DD
[00001c4e][0015da2b][00001c53] e80ff7ffff  call 00001362    ; HH

main() invokes HH(DD,DD)
that simulates DD(DD)
that calls a simulated HH(DD,DD)
that simulates DD(DD)
that cannot possibly return to its caller.

And HH(DD,DD) can't ever give an answer, so fails to be a deccider.

The D built on the H that aborts its simulation is a different input
than the DD that was built on the HH that doesn't, so you can't use the
mapping calculated from DD for D (unless you think that 1 == 2)

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

XPost: sci.logic

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

On 1/16/2024 6:11 PM, immibis wrote:

On 1/16/24 16:54, olcott wrote:

On 1/16/2024 1:54 AM, immibis wrote:

On 1/16/24 01:05, olcott wrote:

The inner simulations never have enough information to abort.

They would if you didn't abort them.

The inner simulations are one recursive simulation away from
the next outer simulation.

This means that the outermost simulation always has one
recursive simulation more execution trace data than any
inner simulation.

The outermost simulation reaches its abort criteria one
recursive simulation sooner than the next inner one.

The ONLY reason the inner simulation doesn't abort is that the outer
simulation aborts first.

If the outer simulation didn't abort the inner simulation would abort.

You simply don't understand these things well enough.

No, YOU don't understand that the problem is about the ACTUAL MACHINE,
and not a fantasy version that only exists in simulation.

The machine that is being simulated, has a D that calls an H(D,D) that
aborts its simulation and returns to D.

The H sees its input call H(D,D) and gives up at that point with bad
logic, and thus gets the wrong answer.

It doesn't matter that the simulation never got to that point, what
matters is what the real machine does, and since it reaches the final
state, that is what matters.

You are just stuck in your fantasy world.

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

XPost: sci.logic

On 1/17/24 03:36, Richard Damon wrote:

No, YOU don't understand that the problem is about the ACTUAL MACHINE,
and not a fantasy version that only exists in simulation.

The machine that is being simulated, has a D that calls an H(D,D) that
aborts its simulation and returns to D.

The H sees its input call H(D,D) and gives up at that point with bad
logic, and thus gets the wrong answer.

It doesn't matter that the simulation never got to that point, what
matters is what the real machine does, and since it reaches the final
state, that is what matters.

You are just stuck in your fantasy world.

Very good way to put it. The halting problem is about whether or not the
direct execution halts. Anything else is dishonest.

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

XPost: sci.logic

On 1/17/24 02:22, olcott wrote:

On 1/16/2024 6:11 PM, immibis wrote:

On 1/16/24 16:54, olcott wrote:

On 1/16/2024 1:54 AM, immibis wrote:

On 1/16/24 01:05, olcott wrote:

The inner simulations never have enough information to abort.

They would if you didn't abort them.

The inner simulations are one recursive simulation away from
the next outer simulation.

This means that the outermost simulation always has one
recursive simulation more execution trace data than any
inner simulation.

The outermost simulation reaches its abort criteria one
recursive simulation sooner than the next inner one.

The ONLY reason the inner simulation doesn't abort is that the outer
simulation aborts first.

If the outer simulation didn't abort the inner simulation would abort.

You simply don't understand these things well enough.

I understand perfectly, and you understand nothing.

If the only reason a simulation doesn't reach a final state is that the simulation is aborted, the correct return value from the halting decider
is 1.

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

XPost: sci.logic

On 1/16/24 01:08, olcott wrote:

On 1/15/2024 8:59 AM, immibis wrote:

On 1/15/24 15:46, olcott wrote:

The function named D *correctly simulated by H* cannot possibly
reach its own line 06 (final state) and halt. If a function
does not reach its own final state then IT DOES NOT HALT.

What is the definition of "correctly simulated by H"?

H correctly simulates the exact sequence of instructions
that D specifies until it correctly matches a non-halting
behavior pattern.

H doesn't do that so it isn't a correct simulator.

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

XPost: sci.logic

On 1/16/24 01:00, olcott wrote:

⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly halt.

⟨Ĥ⟩ cannot possibly be correctly simulated by embedded_H.

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

XPost: sci.logic

On 1/17/24 16:05, olcott wrote:

On 1/17/2024 5:40 AM, immibis wrote:

On 1/17/24 02:22, olcott wrote:

On 1/16/2024 6:11 PM, immibis wrote:

On 1/16/24 16:54, olcott wrote:

On 1/16/2024 1:54 AM, immibis wrote:

On 1/16/24 01:05, olcott wrote:

The inner simulations never have enough information to abort.

They would if you didn't abort them.

The inner simulations are one recursive simulation away from
the next outer simulation.

This means that the outermost simulation always has one
recursive simulation more execution trace data than any
inner simulation.

The outermost simulation reaches its abort criteria one
recursive simulation sooner than the next inner one.

The ONLY reason the inner simulation doesn't abort is that the outer
simulation aborts first.

If the outer simulation didn't abort the inner simulation would abort.

You simply don't understand these things well enough.

I understand perfectly, and you understand nothing.

If the only reason a simulation doesn't reach a final state is that
the simulation is aborted,

*THAT IS NOT THE ONLY REASON, THUS PROVING YOU ARE CLUELESS*

It is the only reason, thus proving you are clueless.

the correct return value from the halting decider is 1.

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

XPost: sci.logic

On 1/17/24 16:02, olcott wrote:

On 1/17/2024 5:40 AM, immibis wrote:

On 1/17/24 03:36, Richard Damon wrote:

No, YOU don't understand that the problem is about the ACTUAL
MACHINE, and not a fantasy version that only exists in simulation.

The machine that is being simulated, has a D that calls an H(D,D)
that aborts its simulation and returns to D.

The H sees its input call H(D,D) and gives up at that point with bad
logic, and thus gets the wrong answer.

It doesn't matter that the simulation never got to that point, what
matters is what the real machine does, and since it reaches the final
state, that is what matters.

You are just stuck in your fantasy world.

Very good way to put it. The halting problem is about whether or not
the direct execution halts. Anything else is dishonest.

If that was true then the halting problem is about D incorrectly
simulated by H such that H simulates instructions that are not in D
or H does not simulate instruction that are in D.

The halting problem is about whether or not the direct execution halts. Anything else is dishonest.

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

XPost: sci.logic

On 1/17/24 17:16, olcott wrote:

On 1/17/2024 9:46 AM, immibis wrote:

On 1/17/24 16:02, olcott wrote:

On 1/17/2024 5:40 AM, immibis wrote:

On 1/17/24 03:36, Richard Damon wrote:

No, YOU don't understand that the problem is about the ACTUAL
MACHINE, and not a fantasy version that only exists in simulation.

The machine that is being simulated, has a D that calls an H(D,D)
that aborts its simulation and returns to D.

The H sees its input call H(D,D) and gives up at that point with
bad logic, and thus gets the wrong answer.

It doesn't matter that the simulation never got to that point, what
matters is what the real machine does, and since it reaches the
final state, that is what matters.

You are just stuck in your fantasy world.

Very good way to put it. The halting problem is about whether or not
the direct execution halts. Anything else is dishonest.

If that was true then the halting problem is about D incorrectly
simulated by H such that H simulates instructions that are not in D
or H does not simulate instruction that are in D.

The halting problem is about whether or not the direct execution
halts. Anything else is dishonest.

Just like ZFC corrected the faulty definition of {set}
to eliminate the undecidability of Russell's Paradox
this correction to the definition of the halting problem:

In computability theory, the halting problem is the problem of
determining, whether an input finite string pair of program/input
specifies a computation that would reach a final state and terminate normally.

Yes, the halting problem is about whether or not the direct execution
reaches a final state and terminates normally.

*Eliminates the undecidability of the halting problem*

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

XPost: sci.logic

On 1/17/24 10:02 AM, olcott wrote:

On 1/17/2024 5:40 AM, immibis wrote:

On 1/17/24 03:36, Richard Damon wrote:

No, YOU don't understand that the problem is about the ACTUAL
MACHINE, and not a fantasy version that only exists in simulation.

The machine that is being simulated, has a D that calls an H(D,D)
that aborts its simulation and returns to D.

The H sees its input call H(D,D) and gives up at that point with bad
logic, and thus gets the wrong answer.

It doesn't matter that the simulation never got to that point, what
matters is what the real machine does, and since it reaches the final
state, that is what matters.

You are just stuck in your fantasy world.

Very good way to put it. The halting problem is about whether or not
the direct execution halts. Anything else is dishonest.

If that was true then the halting problem is about D incorrectly
simulated by H such that H simulates instructions that are not in D
or H does not simulate instruction that are in D.

No, the Halting Problem is about H trying to figure out what D actual
does, or what an actual correct simulation of the input would do, even
if it can't do that itself.

D correctly simulated by H cannot possibly halt.
The directly executed D(D) depends on D correctly
simulated by H aborting its simulation otherwise
D(D) remains stuck in recursive simulation.

Which is only applicable if H does correctly simulate its input, which
means it can't abort

In other words D(D) only halts because H recognizes
the D correctly simulated by H DOES NOT HALT.

Except you just had two different H's and D's in that sentence, since H
is talking about a DIFFERENT D based on a DIFFERENT H than itself, as
the H that correctly simulates doesn't abort, so can't be this.

You are just admitting that you are just a pathological liar that would
know a true statement if it tried to bite your nose.

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