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*

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

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.

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

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

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.

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.

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

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.

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

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

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.

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

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

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

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.

*This input specifies that it calls H in recursive simulation*
The call from D to H <is> an aspect of the computation that
D *SPECIFIES*.

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

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

On 1/14/24 10:45 AM, 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.
>
> *This input specifies that it calls H in recursive simulation*
> The call from D to H <is> an aspect of the computation that
> D *SPECIFIES*.
>

But it calls the H that it was built on, which to be the proof program,
is the H that you claim gives the right answer, and that one aborts its
simulation and returns, so doesn't specify the infinite recursion you
claim, because the H it uses DOES abort its simulation (so the unless
aborted means the logic doesn't apply).

And not, the behavior of the directly executed program IS a behavior
specified by the input, as that can be determined by appling the input
to a UTM.

Note "Behavior Specified by the Input" does NOT refer to behavior
created by this decider, but behavior universally spedified by the input
based on universal specification (thus things like "if applied to a UTM"
is valid, verses "correctly simulated by myse;f" is invalid).

The "Behavior" specified is JUST a function of the input, not who it is
being asked to, that is the fundamental property of the field.

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.

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.

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

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.

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

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.

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

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.

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.

On 1/14/2024 12:42 PM, immibis wrote:
> 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".

D calls H is changed in the TM version where Ĥ transitions
to its own embedded_H internal state. None-the-less we
get the exact same result:

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

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

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.

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

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.

On 1/14/24 3:01 PM, olcott wrote:
> On 1/14/2024 12:42 PM, immibis wrote:
>> 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".
>
> D calls H is changed in the TM version where Ĥ transitions
> to its own embedded_H internal state. None-the-less we
> get the exact same result:

And thus H is a fixed program that can not be changed without
invalidating what has been determined about D.

Different H means different D.

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

Right, if embedded_H (and thus H) IS a machine that does a correct
simulation (and thus doesn't abort) then the Ĥ machine generated is
non-haltingand if H did return 0, it sourld be corrct, but we just said
H was a machine that didn't abort its simulation, so it doesn't return
that value 0.

Change H, and you have changed the machine Ĥ, and thus that answer is no
longer valid.

So, all you have done is proved that by your definition, H can't give
the right answer, and thus the Theorem is still proven.

You are just showing that your arguement has been based on dishonest
dodges and lies.

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

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.

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

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

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⟩