The key aspects of x86utm are now finally complete (Refuting the HP proofs) [ definition of H ]

[olcott]

x86utm is as much as possible a Universal Turing Machine UTM that has
the x86 language as its Turing Machine Description language.

It is common knowledge that the RASP architecture is equivalent to a
universal Turing machine. It is self-evident that the x86 language is a
finite implementation of the Random Access Stored Program (RASP) model.

x86 UTM has these four key operating system functions providing the
functionality to transform an x86 emulator into a finite Universal
Turing Machine: (Source code will be provided)

u32* Allocate(u32 size); // Allocate bytes of memory
void SaveState(Registers* state);
void LoadState(Registers* state);
u32 DebugStep(Registers* master_state, Registers* slave_state);

To make x86utm easy to use it directly executes the COFF object file
output of the Microsoft C compiler. The entire x86UTM system works on
both Windows and Linux. It will also directly execute the output of the
GCC compiler when this output has been converted to the COFF format. An
open source utility is provided for this purpose.

x86utm is based on a very superb x86 emulator. The only change the
needed to be made to the emulator was to very slightly adapt it to
compile under windows and add the feature of disassembling an object
file. All of the adaptations to transform this emulator into a master
UTM are contained in a single C++ source file.

Here is how x86UTM is applied to the Peter Linz H() and H_Hat() to
correctly decide halting of H_Hat()

H() continues to DebugStep() though H_Hat() until H_Hat() terminates or
H() decides that H_Hat() would not otherwise terminate. In this case H()
would stop executing H_Hat() and report Not_Halting behavior.

H() executes H_Hat() as if H() was a UTM. H() and H_Hat() are separate
processes having their own: {Memory, registers and stack}
To make things simple the halt deciding aspect of H() and H_Hat() is the
same function. (see below)

#define HALT __asm hlt
// N and M have address of H_Hat()
int H(u32 M, u32 N)
{
int Abort = DebugTrace(M, N);
if (Abort)
{
MOV_EAX_0
HALT
}
else
{
MOV_EAX_1
HALT
}
}


int main()
{
u32 M = (u32)H_Hat;
H(M, M);
HALT;
}


--
Copyright 2020 Pete Olcott

[Mike Terry]

So what is this "the same function"? It looks like that function is
DebugTrace(), right? (A better name might be Decide(), which expresses
its role in the program, but no biggie.)

[olcott]

Both H() and H_Hat() invoke the same DebugTrace() function.
DebugTrace() continues a DebugStep() of M(N) unless M(N) would not
otherwise terminate.

At the first point that DebugTrace() determines that M(N) would not
otherwise terminate it aborts the DebugStep() of M(N).

- #define MOV_EAX_0 __asm mov eax,0
- #define MOV_EAX_1 __asm mov eax,1
- #define HALT __asm hlt
- // N and M have the address of H_Hat()
- int H(u32 M, u32 N)
- {
-   int Abort = DebugTrace(M, N);
-   if (Abort)
-   {
-     MOV_EAX_0 // M(N) would not otherwise terminate
-     HALT
-   }
-   else
-   {
-     MOV_EAX_1 // M(N) has terminated
-     HALT
-   }
- }
-
-
- int main()
- {
-   u32 M = (u32)H_Hat;
-   H(M, M);
-   HALT;
- }

[olcott]

All of the Input pairs {M, N} to H() that actually halt reach

MOV_EAX_1 // M(N) has terminated

All of the Input pairs {M, N} to H() that are decided would not
otherwise halt reach MOV_EAX_0 // M(N) would not otherwise terminate

Although there may be some cases that are very difficult to decide there
are no cases left that are impossible to decide.

[Chris M. Thomasson]

How does it determine that an unknown function will never terminate?

[Mike Terry]

OK. I've added a valid implementation for H_Hat below. I've also added
an appropriate invocation for H_Hat in main(), but obviously main()
will only actually invoke one or the other, depending on whether we've
built the "run H" or "run H_Hat" machine.
(Hopefully this is equivalent to what you are doing... My actual
question at the end.)

>
> - #define MOV_EAX_0 __asm mov eax,0
> - #define MOV_EAX_1 __asm mov eax,1
> - #define HALT __asm hlt
> - // N and M have the address of H_Hat()
> - int H(u32 M, u32 N)
> - {
> - int Abort = DebugTrace(M, N);
> - if (Abort)
> - {

// DebugTrace says M(M) does not halt

> - MOV_EAX_0 // M(N) would not otherwise terminate
> - HALT
> - }
> - else
> - {

// DebugTrace says M(M) halts

> - MOV_EAX_1 // M(N) has terminated
> - HALT
> - }
> - }
> -

int H_Hat(u32 M)
{
int Abort = DebugTrace(M, M);
if (Abort)
{
// DebugTrace says M(M) does not halt
HALT // ..so we halt
}
else
{
// DebugTrace says M(M) halts
for (;;); // ..so we loop

}
}

> -
> - int main()
> - {
> - u32 M = (u32)H_Hat;

# ifdef RUN_H
> - H(M, M); // run H (H_Hat, H_Hat)
# else
H_Hat (M); // run H_Hat (H_Hat)
# endif

> - HALT;
> - }
>

So there are two execution contexts to consider where DebugTrace is
called - either from within H, or from within H_Hat. (Yes, these will
actually be in different "machines".) In both contexts, the DebugTrace
call receives the same parameters (H_Hat, H_Hat).

Can you confirm that in both the above execution paths, the
DebugTrace(H_Hat, H_Hat) returns the same return code? I don't know
what's in your DebugTrace(), but unless it's blatently cheating it will
return the same result if called with the same parameters, right?

Regards,
Mike.

[olcott]

I liked your simplest possible H_Hat() so I used it.
Immediately before I saw your simplest possible H_Hat() I had just
reduced the complexity of mine to be exactly the same so we are of one
mind on this.


// M has address of H_Hat()

int H_Hat(u32 M)
{
int Abort = DebugTrace(M, M);
if (Abort)
{

MOV_EAX_0 // DebugTrace says that M(M)
HALT // has been aborted
}
else
{
MOV_EAX_1 // M(M) has halted
HERE: goto HERE;
HALT
}
}


// M and N have the address of H_Hat()

int H(u32 M, u32 N)

{

int Abort = DebugTrace(M, N);

if (Abort)
{
MOV_EAX_0 // DebugTrace says that M(N)
HALT // has been aborted
}
else
{
MOV_EAX_1 // M(N) has halted

HALT
}
}

int main()
{
u32 M = (u32)H_Hat;
H(M, M);
HALT;
}

To make things easy I provided the actual code.
We don't need any compile time switch to execute H() and H_Hat().

H() executes H_Hat() in DebugTrace() mode which causes H_Hat() to
execute itself in DebugTrace() mode.

The invocation of H() is in one process context, the first invocation of
H_Hat() is in another process context, and the second invocation of
H_Hat() is in the third process context.

> So there are two execution contexts to consider where DebugTrace is
> called - either from within H, or from within H_Hat.  (Yes, these will
> actually be in different "machines".)  In both contexts, the DebugTrace
> call receives the same parameters (H_Hat, H_Hat).
>
> Can you confirm that in both the above execution paths, the
> DebugTrace(H_Hat, H_Hat) returns the same return code?

Yes.

> I don't know
> what's in your DebugTrace(), but unless it's blatently cheating it will
> return the same result if called with the same parameters, right?
>
> Regards,
> Mike.
>

[Mike Terry]

In the Linz proof, there are two separate TMs whose execution is considered:

H which runs with input (H^, H^), and halts in an
accept state or in a reject state

H^ which runs with input (H^) and either halts or
never halts

These two TMs, in your C program world, correspond to two COFF files:
one for H and one for H^. In my example you could generate the two COFF
files by defining (or not) the preprocessor symbol RUN_H. The C code
used for both COFF files is the same.

You have given the code for the H COFF file, and say there is no need
for any precompiler symbols, but you have not given the code for the H^
COFF file.

>
> H() executes H_Hat() in DebugTrace() mode

From a high level perspective, we can say H calls DebugTrace() which
returns an RC (return code) which is either zero or nonzero indicating
its decision that the examined calculation either halts [RC != 0] or
does not halt [RC=0].

What DebugTrace does internally matters to you (because you are writing
it), but not so much at this high level (which should turn out to be
enough to see your overall claim will not succeed).

> which causes H_Hat() to
> execute itself in DebugTrace() mode.
>
> The invocation of H() is in one process context, the first invocation of
> H_Hat() is in another process context, and the second invocation of
> H_Hat() is in the third process context.
>

(OK, but those low level details are not the focus of my post)

>> So there are two execution contexts to consider where DebugTrace is
>> called - either from within H, or from within H_Hat. (Yes, these will
>> actually be in different "machines".) In both contexts, the
>> DebugTrace call receives the same parameters (H_Hat, H_Hat).
>>
>> Can you confirm that in both the above execution paths, the
>> DebugTrace(H_Hat, H_Hat) returns the same return code?
>
> Yes.
>

You have said "yes", but I'm not certain that we're communicating
correctly. So far it seems to me you are only considering /one/ COFF
file? (The H COFF file).

Above, I mentioned execution contexts (or paths) and there are two of
these that matter at the high level I am interested in.

CONTEXT 1: In the *H* COFF file execution, DebugTrace(H_Hat,H_Hat) is
called ONCE at the highest level (from main()). [If DebugTrace()
internally results in further DebugTrace() invocations, at the high
level I'm considering those don't matter...]

CONTEXT 2: DebugTrace(H_Hat,H_Hat) is also called in the *H^* COFF
file. It is called ONCE at the highest level, from H_Hat which in turn
has just been called by main(). [Again, if DebugTrace() internally
results in further DebugTrace() invocations, at the high level I'm
considering those don't matter...]

My question was whether /those/ two specific calls to DebugTrace returns
the same RC.

Mike.

[Mike Terry]

Darn it! Despite trying to be careful it looks like I've still got the
RCs the wrong way round :(

DebugTrace RC=0: examined calculation terminates
RC nonzero: examined calculation does not terminate

[olcott]

Because every function that is invoked by DebugTrace() is executed in
its own separate process the source code that I provided specifies three
separate virtual machines:
(a) main() that executes H()
(b) The H_Hat() that is executed by H()
(c) The H_Hat() that is executed by itself.

The most difficult aspect of this was to make sure that DebugTrace()
could invoke itself recursively to an arbitrary depth. Each one of these
invocations is in its own separate process.

>>
>> H() executes H_Hat() in DebugTrace() mode
>
> From a high level perspective, we can say H calls DebugTrace() which
> returns an RC (return code) which is either zero or nonzero indicating
> its decision that the examined calculation either halts [RC != 0] or
> does not halt [RC=0].
>
> What DebugTrace does internally matters to you (because you are writing
> it), but not so much at this high level (which should turn out to be
> enough to see your overall claim will not succeed).
>

Yes I believe that is true.
The key to this is noticing that the halting question has been changed:
(a) Does H_Hat() halt on its input?

(b) Does the execution of H_Hat() have to be aborted to prevent the halt
decider from getting stuck in infinite execution?

I have one more key element that can best be demonstrated by fully
functional code.

>> which causes H_Hat() to
>> execute itself in DebugTrace() mode.
>>
>> The invocation of H() is in one process context, the first invocation of
>> H_Hat() is in another process context, and the second invocation of
>> H_Hat() is in the third process context.
>>
>
> (OK, but those low level details are not the focus of my post)

Those low level details are only required to understand that the source
code already specifies the execution of three separate virtual machines
thus no need for any compile-time switch.

>
>>> So there are two execution contexts to consider where DebugTrace is
>>> called - either from within H, or from within H_Hat.  (Yes, these will
>>> actually be in different "machines".)  In both contexts, the
>>> DebugTrace call receives the same parameters (H_Hat, H_Hat).
>>>
>>> Can you confirm that in both the above execution paths, the
>>> DebugTrace(H_Hat, H_Hat) returns the same return code?
>>
>> Yes.
>>
>
> You have said "yes", but I'm not certain that we're communicating
> correctly.  So far it seems to me you are only considering /one/ COFF
> file?  (The H COFF file).
>

As I have now fully elaborated the source file that I provided specifies
x86utm executing main() which executes H() which invokes H_Hat() in its
own separate process which invokes another H_Hat() in its own separate
process.

> Above, I mentioned execution contexts (or paths) and there are two of
> these that matter at the high level I am interested in.
>
> CONTEXT 1:   In the *H* COFF file execution, DebugTrace(H_Hat,H_Hat) is
> called ONCE at the highest level (from main()).  [If DebugTrace()
> internally results in further DebugTrace() invocations, at the high
> level I'm considering those don't matter...]
>

A new and totally separate execution context is created every single
time that DebugTrace() is invoked.

> CONTEXT 2:   DebugTrace(H_Hat,H_Hat) is also called in the *H^* COFF
> file.  It is called ONCE at the highest level, from H_Hat which in turn
> has just been called by main().  [Again, if DebugTrace() internally
> results in further DebugTrace() invocations, at the high level I'm
> considering those don't matter...]
>
> My question was whether /those/ two specific calls to DebugTrace returns
> the same RC.
>
> Mike.
>

As Ben has very carefully elaborated twice the invocation of a function
with the same input must result in the same output. The return value
from H_Hat() and the return value from H() are the same return value.
Like the Linz proof these "return values" are provided as halting in a
final state.

EAX = 0 means that the input program was aborted. EAX = 1 means that the
input program terminated.

[Mike Terry]

Your claim is that you have two "TM-like-thingies" H and H^ where the
two calculations
H running with input (H^, H^)
H^ running with input (H^)
refute the Linz proof.

In your paradigm TM-like-entities translates to COFF files (with an
emulator providing the calculation side of things). So the /natural/
products you should deliver to support this are the two COFF files
demonstrating the claimed behaviour.

OK you're not going to do that, although it seems to me you /could/ do
that, at the cost of just 10 minutes of extra effort, and then your
delivery would logically match up with the claim you are making.

Instead you are effectively saying, "I don't need to spend those 10
minutes, because in fact if you understood the internals of how I've
implemented XXXXX you would see that the results that /would/ occur if I
spent the extra 10 minutes can instead be /deduced/ by looking at
particular subsets of the behaviour of the single COFF file. [Even
though the code provided so far, does not even shows any call H_Hat
(H_Hat).]

I won't bother arguing with any of that, although it's a strange.

Hopefully this is a typo - I asked about return codes from DebugTrace,
not from H or H_Hat. H^ in the Linz proof is not a decider of anything,
so output from H^ is irrelevant; all that matters is whether it halts.

I'll take it that you mean:

"The calls to DebugTrace() in the two contexts you've
described both return the same return code"

(It being understood that when my contexts refer to two COFF files, you
have equivalents in your single COFF file...)

Yes, both Ben and I and others have all elaborated that this /should/ be
the case, but I have to ask you, because it isn't clear to me that you
would necessarily agree on this point. If you did agree, your claim
would effectively be sunk, and you haven't withdrawn your claim of
refuting the Linz proof.


OK, so you say the calls to DebugTrace() in Context (1) and (2) return
the same result. There are just two possibilities:

*Both DebugTrace() RCs are zero* :

In Context (1) this indicates that H will decide that
calculation H_Hat (H_Hat) halts. (MOV_EAX_1; HALT; will
be executed.)

In Context (2) this means that the H_Hat code will take
the branch containing HERE: goto HERE;, and so H_Hat will
loop at this point.

So H clearly made the wrong halt decision for the calculation. OK, so
the other possibility is...

*Both DebugTrace() RCs are non-zero* :

In Context (1) this indicates that H will decide that
calculation H_Hat (H_Hat) does not halt. (MOV_EAX_0; HALT; will
be executed.)

In Context (2) this means that the H_Hat code will take
the branch containing MOV_EAX_0; HALT;, and so H_Hat(H_Hat)
will halt at this point.

Again H has made the wrong decision for the calculation.

Those are the only possibilities! So your "TM"s agree in behaviour with
the Linz proof. No refuting going on here! :)

Mike.

[olcott]

No you are wrong and have been corrected on this several times.

The return value from DebugTrace() is the same for H() and H_Hat().

> not from H or H_Hat.  H^ in the Linz proof is not a decider of anything,
> so output from H^ is irrelevant; all that matters is whether it halts.
>



> I'll take it that you mean:
>
>    "The calls to DebugTrace() in the two contexts you've
>     described both return the same return code"
>

Yes.

> (It being understood that when my contexts refer to two COFF files, you
> have equivalents in your single COFF file...)
>
> Yes, both Ben and I and others have all elaborated that this /should/ be
> the case,

No. Every software function having the same input can't possisbly have
different output.

> but I have to ask you, because it isn't clear to me that you
> would necessarily agree on this point.  If you did agree, your claim
> would effectively be sunk, and you haven't withdrawn your claim of
> refuting the Linz proof.
>
>
> OK, so you say the calls to DebugTrace() in Context (1) and (2) return
> the same result.  There are just two possibilities:
>
> *Both DebugTrace() RCs are zero* :
>
>    In Context (1) this indicates that H will decide that
>    calculation H_Hat (H_Hat) halts.  (MOV_EAX_1; HALT; will
>    be executed.)
>
>    In Context (2) this means that the H_Hat code will take
>    the branch containing HERE: goto HERE;, and so H_Hat will
>    loop at this point.
>
> So H clearly made the wrong halt decision for the calculation.  OK, so
> the other possibility is...
>
> *Both DebugTrace() RCs are non-zero* :
>
>    In Context (1) this indicates that H will decide that
>    calculation H_Hat (H_Hat) does not halt.  (MOV_EAX_0; HALT; will
>    be executed.)
>
>    In Context (2) this means that the H_Hat code will take
>    the branch containing MOV_EAX_0; HALT;, and so H_Hat(H_Hat)
>    will halt at this point.
>
> Again H has made the wrong decision for the calculation.
>

No you have this incorrectly.

When I change the halting problem question:

(a) Does H_Hat() halt on its input?

(b) Does the execution of H_Hat() have to be aborted to prevent the halt
decider from getting stuck in infinite execution?

The previously undecidable halting problem becomes decidable.

There are no longer any cases that are impossible to decide:
(a) The input program must have its execution aborted.

(b) The input program continues to execute until its execution terminates.

> Those are the only possibilities!  So your "TM"s agree in behaviour with
> the Linz proof.  No refuting going on here!  :)
>
> Mike.
>
>> Like the Linz proof these "return values" are provided as halting in a
>> final state.
>>
>> EAX = 0 means that the input program was aborted. EAX = 1 means that the
>> input program terminated.
>>
>>

[André G. Isaak]

On 2020-10-21 14:27, olcott wrote:

> When I change the halting problem question:
> (a) Does H_Hat() halt on its input?
>
> (b) Does the execution of H_Hat() have to be aborted to prevent the halt
> decider from getting stuck in infinite execution?
>
> The previously undecidable halting problem becomes decidable.

When you change the halting problem question, then you are no longer
addressing the halting problem. You are addressing some entirely
different problem.

> There are no longer any cases that are impossible to decide:
> (a) The input program must have its execution aborted.

Must have why? Because you got tired of waiting? How do you know it
wouldn't have eventually halted on its own?

I mean there may be cases where a given program is obviously stuck in an
infinite loop (i.e. a very short loop), but there will also be cases
where the program goes through a variety of states which don't end up
repeating themselves until years or millennia into the future.

André

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

[olcott]

On 10/21/2020 3:57 PM, André G. Isaak wrote:
> On 2020-10-21 14:27, olcott wrote:
>
>> When I change the halting problem question:
>> (a) Does H_Hat() halt on its input?
>>
>> (b) Does the execution of H_Hat() have to be aborted to prevent the
>> halt decider from getting stuck in infinite execution?
>>
>> The previously undecidable halting problem becomes decidable.
>
> When you change the halting problem question, then you are no longer
> addressing the halting problem. You are addressing some entirely
> different problem.
>

Not when I change the question into an equlvalent question.

>> There are no longer any cases that are impossible to decide:
>> (a) The input program must have its execution aborted.
>
> Must have why? Because you got tired of waiting? How do you know it
> wouldn't have eventually halted on its own?
>

The halt decider examines its input program and decides that it would
never halt. When it does this it reports that its input program was
aborted.

This is the exact same question as the orginal halting problem question
except that this equivalent question is not subject to pathological self
reference.

It divides all of its inputs into halting and not halting.

> I mean there may be cases where a given program is obviously stuck in an
> infinite loop (i.e. a very short loop), but there will also be cases
> where the program goes through a variety of states which don't end up
> repeating themselves until years or millennia into the future.
>
> André
>

I have not made solving the halting problem easy.
I merely refuted the proofs that show it is impossible.

[André G. Isaak]

On 2020-10-21 15:12, olcott wrote:
> On 10/21/2020 3:57 PM, André G. Isaak wrote:
>> On 2020-10-21 14:27, olcott wrote:
>>
>>> When I change the halting problem question:
>>> (a) Does H_Hat() halt on its input?
>>>
>>> (b) Does the execution of H_Hat() have to be aborted to prevent the
>>> halt decider from getting stuck in infinite execution?
>>>
>>> The previously undecidable halting problem becomes decidable.
>>
>> When you change the halting problem question, then you are no longer
>> addressing the halting problem. You are addressing some entirely
>> different problem.
>>
>
> Not when I change the question into an equlvalent question.

If it really were the case that changing the question from (a) to (b)
makes what was previously undecidable decidable, then obviously they
cannot be equivalent questions.

>>> There are no longer any cases that are impossible to decide:
>>> (a) The input program must have its execution aborted.
>>
>> Must have why? Because you got tired of waiting? How do you know it
>> wouldn't have eventually halted on its own?
>>
>
> The halt decider examines its input program and decides that it would
> never halt. When it does this it reports that its input program was
> aborted.

And it decides this how? That sounds like a restatement of the halting
problem that you purport to be solving, so the above is entirely
uninformative.

[Mike Terry]

On 21/10/2020 21:27, olcott wrote:
> On 10/21/2020 2:30 PM, Mike Terry wrote:
>> On 21/10/2020 17:48, olcott wrote:
>>> On 10/21/2020 10:28 AM, Mike Terry wrote:
>>>> On 21/10/2020 04:07, olcott wrote:

[... snip ...]

[... snip ...]

[... snip ...]

>> OK, so you say the calls to DebugTrace() in Context (1) and (2) return
>> the same result. There are just two possibilities:
>>
>> *Both DebugTrace() RCs are zero* :
>>
>> In Context (1) this indicates that H will decide that
>> calculation H_Hat (H_Hat) halts. (MOV_EAX_1; HALT; will
>> be executed.)
>>
>> In Context (2) this means that the H_Hat code will take
>> the branch containing HERE: goto HERE;, and so H_Hat will
>> loop at this point.
>>
>> So H clearly made the wrong halt decision for the calculation. OK, so
>> the other possibility is...
>>
>> *Both DebugTrace() RCs are non-zero* :
>>
>> In Context (1) this indicates that H will decide that
>> calculation H_Hat (H_Hat) does not halt. (MOV_EAX_0; HALT; will
>> be executed.)
>>
>> In Context (2) this means that the H_Hat code will take
>> the branch containing MOV_EAX_0; HALT;, and so H_Hat(H_Hat)
>> will halt at this point.
>>
>> Again H has made the wrong decision for the calculation.
>>
>
> No you have this incorrectly.

You say that I have this incorrectly, without giving any indication of
what you think is incorrect. That looks like being deliberately unhelpful!

I'll have one more go - to save considering two alternatives for
everything, which of the above possibilities will actually occur in the
code you intend to finally deliver?

Will both the DebugTrace() return codes be ZERO, or will they be
NON-ZERO? (You previously agreed they would be the same...)

Mike.

[olcott]

Now that I have completed my x86utm operating system I finally have the
required infrastructure to provide all the programming steps to decide
whether or not H_Hat() must have its execution trace aborted because it
would otherwise cause H() to be stuck in infinite execution or continue
to DebugStep() H_Hat() until it completes its finite execution.

The most difficult part of this was designing and implemented
DebugTrace() so that it could DebugTrace() itself to an arbitrary
recursive depth.

All in all creating x86utm took about 2000 labor hours. The first 500
were wasted on trying to do everything from scratch.

Even without providing anything more than I have already provided in
this thread it should be able to be understood that the impossibility of
solving the halting problem has been refuted by transforming the
original question into an equivalent question that is not subject to
pathological self-reference.

[olcott]

Carefully study my words immediately below again and again until you
fully understand exactly how I transformed a question subject to
pathological self-reference into a question that is not subject to
pathological self-reference thus eliminating the impossibility of
solving the halting problem.

>> When I change the halting problem question:
>> (a) Does H_Hat() halt on its input?
>>
>> (b) Does the execution of H_Hat() have to be aborted to prevent the halt
>> decider from getting stuck in infinite execution?
>>
>> The previously undecidable halting problem becomes decidable.
>>
>> There are no longer any cases that are impossible to decide:
>> (a) The input program must have its execution aborted.
>>
>> (b) The input program continues to execute until its execution
>> terminates.

[olcott]

On 10/21/2020 6:16 PM, Ben Bacarisse wrote:

> olcott <No...@NoWhere.com> writes:
>
>> Even without providing anything more than I have already provided in
>> this thread it should be able to be understood that the impossibility
>> of solving the halting problem has been refuted by transforming the
>> original question into an equivalent question that is not subject to
>> pathological self-reference.
>

> Now that your method has been revealed, please post what you had two
> years ago.
>

I am going beyond that. What I had two years ago was far too terse for
anyone here to understand. Now that the man-years worth of work creating
the x86utm operating system is totally complete I can write much more
robust halt deciding code.

If you can't see how I have already refuted the halting problem proofs
by transforming the halting question:

(a) Does H_Hat() halt on its input?

Into an equivalent question that is not subject to pathological
self-reference:

(b) Does the execution of H_Hat() have to be aborted to prevent the halt
decider from getting stuck in infinite execution?

Then it makes no sense to provide the halt decider code.

[olcott]

On 10/21/2020 8:22 PM, Richard Damon wrote:

> On 10/21/20 12:48 PM, olcott wrote:
>> On 10/21/2020 10:28 AM, Mike Terry wrote:
>>>
>>> What DebugTrace does internally matters to you (because you are
>>> writing it), but not so much at this high level (which should turn out
>>> to be enough to see your overall claim will not succeed).
>>>
>>
>> Yes I believe that is true.
>> The key to this is noticing that the halting question has been changed:
>> (a) Does H_Hat() halt on its input?
>>
>> (b) Does the execution of H_Hat() have to be aborted to prevent the halt
>> decider from getting stuck in infinite execution?
>>
>> I have one more key element that can best be demonstrated by fully
>> functional code.
>>
>

> Note, you do not have the 'right' to redefine the Halting Question, at
> least not if you want to be talking about the 'classical' Halt Decider
> and Linz's proof of impossibility. The machine which he showed to be
> impossible was the machine that could be given the description of any
> Turing machine, and its input, and be able to ALWAYS tell, in finite
> time, if said machine with said input would halt, or if it would process
> forever an not halt.
>
> Thus, the machine H, must never get stuck in an 'infinite loop' for any
> legal input.
>
> If you have decided that as part of that implementation, that it somehow
> can detect that it has gotten itself in a loop and aborts that
> calculation, and declare that the described machine will not halt, it
> can, but that means that if someone can come up with a sufficiently
> complicated machine that triggers this condition when given to H, but if
> run by itself does eventual halt, that H wasn't the needed halt detector
> (but for Linz's proof, this isn't really needed, at the Linz H^ when it
> loops can be fairly easily detected,
>
> Note, that your new wording seems to leave open some possibilities that
> are not allowed in the original construction:
>
> The implementation of your function that implements the decision of H(),
> your DebugStep isn't allowed to know which program called it, but must
> return the same code to both H and H_Hat.
>
> Your implementation of your function can't halt in and of itself, but
> MUST return the answer to its caller (The Turing machine H had just two
> terminal states, both of which were accounted for in H_Hat).
>
> The answer that it returns needs to reflect what H_Hat actually ends up
> doing, and the program H_Hat needs to act in the manner that Linz described.
>
> Note, that I don;'t really care how it actually gets the answer, as it
> only really needs to provide the answer for this one case, being given
> the machine/Input H_Hat/H_Hat, as far as I am concerned, Linz proof
> still holds even if the function is just a return 0;, or a return 1;
>
> There are only a few things that are really important:
>
> Both the calls to it in H and in H_Hat need to return the same value,
> and in finite time.
>
> That H indicates the correct halting indication for H_Hat.
>
> That H_Hat was constructed and executes per Linz's specification (It
> must halt if H will indicate that it looped, and it must loop if H will
> indicate it halted)
>
> Any attempt to mark H_Hat is an 'improper program' will just prove
> Linz's statement, as if there IS an H, then the construction of H_Hat is
> clearly a legal modification, so any problems with it must have been
> contained in H, so saying H can't exist is exactly what Linz was trying
> to prove.
>

When we make the single change that I suggest the halting problem ceases
to be impossible to solve because this revised question is not subject
to pathological self-reference.

All of the inputs are divided into halting and not halting and the halt
decider cannot be fooled by a program based on itself that does the
opposite of whatever it decides.

[Mike Terry]

You forgot to answer the question! Here it is again:

Will both the DebugTrace() return codes be ZERO, or will they be
NON-ZERO? (You previously agreed they would be the same...)

Mike.

>

[olcott]

That question will only be answered by fully operational code.

The key proof has already been provided. No matter what return value
that DebugTrace() provides if it is always answering the question:

Was your input aborted because it would not otherwise halt?
The halting problem becomes decidable.

>>>> When I change the halting problem question:
>>>> (a) Does H_Hat() halt on its input?
>>>>
>>>> (b) Does the execution of H_Hat() have to be aborted to prevent the
>>>> halt
>>>> decider from getting stuck in infinite execution?
>>>>
>>>> The previously undecidable halting problem becomes decidable.
>>>>
>>>> There are no longer any cases that are impossible to decide:
>>>> (a) The input program must have its execution aborted.
>>>>
>>>> (b) The input program continues to execute until its execution
>>>> terminates.
>>

[Mike Terry]

That's what I expected you to say. It won't make the slightest
difference to how your work is received if you answer now or in a few
weeks, but it's your choice.

> The key proof has already been provided.

?!

All you've provided so far is: a) the skeleton C code, which clearly is
going to support the Linz proof, if what you've said about how
DebugTrace() behaves is true; and b) what you've said below about
changing the question, which makes no difference to anything at all.

Have I missed an actual proof of something? The Usenet server I use
(Giganews) does that from time to time - it has a bug in its "add new
message to database" logic where certain updates are not atomic (w.r.t
client enquiries) when they should be.

(Or is your "changing the question" supposed to be some kind of proof?)

> No matter what return value
> that DebugTrace() provides if it is always answering the question:
>
> Was your input aborted because it would not otherwise halt?
> The halting problem becomes decidable.
>

Sorry, but that's nonsense. Oh well, guess we'll just have to wait and
see the full code.

Mike.

[olcott]

The difference is that it is no longer possible for H_Hat() to do the
opposite of what H() decides. This transforms an undecidable problem
into a decidable problem.

> Have I missed an actual proof of something?  The Usenet server I use
> (Giganews) does that from time to time - it has a bug in its "add new
> message to database" logic where certain updates are not atomic (w.r.t
> client enquiries) when they should be.
>
> (Or is your "changing the question" supposed to be some kind of proof?)

By changing the question H_Hat() can no longer do the opposite of what
H() decides making an undecidable problem into a decidable problem.

>
>> No matter what return value
>> that DebugTrace() provides if it is always answering the question:
>>
>> Was your input aborted because it would not otherwise halt?
>> The halting problem becomes decidable.
>>
>
> Sorry, but that's nonsense.  Oh well, guess we'll just have to wait and
> see the full code.
>
> Mike.
>

The full code will not be provided until you (and others) understand how
I already proved my point.

By searching the comp.theory forum for "olcott" (11,415 messages from
me) it can be verified that it took me about 12,000 hours since 2004 to
come up with this simple "change the question" refutation.

In the mean time I will complete the code that uses a key detail about
the halting problem that no one ever noticed for 80 years to correctly
decide the halting of H_Hat().

I already showed THAT the halting problem is decidable.

Next I will show HOW the conventional self-referential halting problem
counter examples are decided.

[Richard Damon]

On 10/22/20 12:33 AM, olcott wrote:
>
> The difference is that it is no longer possible for H_Hat() to do the
> opposite of what H() decides. This transforms an undecidable problem
> into a decidable problem.

If H_Hat no longer does what the proof defined, then your demonstration
is no longer applicable to the proof.

One possible counter might be showing that the steps that Linz did to
make H_Hat aren't allowed by the definition of Turning Machines, but
they clearly are, being a fairly simple augmentation to the state table
of H.

Showing that some thing you call "H_Hat" doesn't contradict something
you call "H", which doesn't do what H is required to do proves
absolutely nothing. At best it provides some evidence that the creation
of a universal halt detector is in fact impossible, because you are
going to such off-beat arguments that it is possible.

[olcott]

On 10/22/2020 7:00 AM, Richard Damon wrote:
> On 10/22/20 12:33 AM, olcott wrote:
>>
>> The difference is that it is no longer possible for H_Hat() to do the
>> opposite of what H() decides. This transforms an undecidable problem
>> into a decidable problem.
>
> If H_Hat no longer does what the proof defined, then your demonstration
> is no longer applicable to the proof.
>

If the halt decider is to report whether or not its input halts another
program can be constructed on the the basis of this halt decider that
does the opposite of whatever the halt decider decides.

This is how H() and H_Hat() are defined in the Linz proof.

If the halt decider is to report whether or not it aborted its input
program because its input program would otherwise cause the halt decider
to get stuck in infinite execution then this other program can no longer
fool its halt decider and do the opposite of whatever it decides.

If H() aborts the execution of H_Hat() then H_Hat() cannot continue to
execute because H() has complete control over H_Hat.

The end result of this slight change is that the halting problem can no
longer be shown to be undecidable.

> One possible counter might be showing that the steps that Linz did to
> make H_Hat aren't allowed by the definition of Turning Machines, but
> they clearly are, being a fairly simple augmentation to the state table
> of H.
>
> Showing that some thing you call "H_Hat" doesn't contradict something
> you call "H", which doesn't do what H is required to do proves
> absolutely nothing. At best it provides some evidence that the creation
> of a universal halt detector is in fact impossible, because you are
> going to such off-beat arguments that it is possible.
>

[Mike Terry]

On 22/10/2020 15:36, olcott wrote:
> On 10/22/2020 7:00 AM, Richard Damon wrote:
>> On 10/22/20 12:33 AM, olcott wrote:
>>>
>>> The difference is that it is no longer possible for H_Hat() to do the
>>> opposite of what H() decides. This transforms an undecidable problem
>>> into a decidable problem.
>>
>> If H_Hat no longer does what the proof defined, then your demonstration
>> is no longer applicable to the proof.
>>
>
> If the halt decider is to report whether or not its input halts another
> program can be constructed on the the basis of this halt decider that
> does the opposite of whatever the halt decider decides.
>
> This is how H() and H_Hat() are defined in the Linz proof.
>
> If the halt decider is to report whether or not it aborted its input
> program because its input program would otherwise cause the halt decider
> to get stuck in infinite execution then this other program can no longer
> fool its halt decider and do the opposite of whatever it decides.
>
> If H() aborts the execution of H_Hat() then H_Hat() cannot continue to
> execute because H() has complete control over H_Hat.
>
> The end result of this slight change is that the halting problem can no
> longer be shown to be undecidable.
>

It is suspicious that in none of this have you ever stated what is
actually wrong in the Linz proof. It's almost as though you accept
there is nothing wrong with it, and yet you still think its conclusion
is incorrect! Or that you can't see anything wrong with it, and in your
head the mistake in the proof is that its conclusion is wrong?
(Thinking a conclusion is wrong does not refute anything...)

Anyhow, you talk about the halt decider reporting that it "aborted its
input program, because blah blah". If you read the Linz proof, you'll
notice that it is completely unaffected of any internal reasoning as to
WHY H might have made whatever decision it made. All it depends on is
that H actually makes a decision!

In your example, as long as H actually makes /some/ decision, the H_Hat
will do the opposite of what H decided, and so the Linz proof will be
confirmed, not refuted. If H loops, never making any decision, then H
is not a decider for the H_Hat(H_Hat) question (contrary to what you
have always explicitly stated) and so is irrelevant to the Linz proof.

You have said you won't reveal your final code unless I (and others)
agree that what you've said so far already proves your point. Well, you
haven't proved anything, so that's that.

So... this was to be the culmination of your life's work, and now you're
simply not going to publish it? I thought the whole purpose of
producing the actual TMs was that it would override any objections
people raised to a mere verbal claim, and prove you right despite the
objections?

Two years ago I told you that if you just gave your reasoning and
perhaps some high-level pseudo-code, and forgot about producing actual
"TM"s and traces and whatnot, people would quickly tell you your mistake
and you could save months of effort. And it turns out (no surprise)
that this was correct! Had you posted 2 years ago just what you've said
in this thread people would have said exactly the same as they're saying
now, and nothing whatsoever would be different, except you would have
saved a year's work on your part. :)

Regards,
Mike.

[olcott]

On 10/22/2020 9:57 AM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>

>> On 10/22/2020 7:00 AM, Richard Damon wrote:
>>> On 10/22/20 12:33 AM, olcott wrote:
>>>>
>>>> The difference is that it is no longer possible for H_Hat() to do the
>>>> opposite of what H() decides. This transforms an undecidable problem
>>>> into a decidable problem.
>>>
>>> If H_Hat no longer does what the proof defined, then your demonstration
>>> is no longer applicable to the proof.
>>
>> If the halt decider is to report whether or not its input halts
>> another program can be constructed on the the basis of this halt
>> decider that does the opposite of whatever the halt decider decides.
>>
>> This is how H() and H_Hat() are defined in the Linz proof.
>

> Yes, and this is what you have been claiming to have had for nearly two
> years and everyone else has been saying is impossible. Do you now
> accept that it is impossible and that you were wrong to say you had such
> a pair?

>
>> If the halt decider is to report whether or not it aborted its input
>> program because its input program would otherwise cause the halt
>> decider to get stuck in infinite execution then this other program can
>> no longer fool its halt decider and do the opposite of whatever it
>> decides.
>>
>> If H() aborts the execution of H_Hat() then H_Hat() cannot continue to
>> execute because H() has complete control over H_Hat.
>>
>> The end result of this slight change is that the halting problem can
>> no longer be shown to be undecidable.
>

> Unfortunately, pairs like this -- where H and H^ are not related exactly
> as in Linz, or where they are but H gets the answer wrong -- are
> ten-a-penny. What you wasted everyone's time with was a clear claim to
> have a pair, H and H^, related exactly as in Linz, where H gives the
> correct halting answer for H(H^, H^). Do you now see that such a pair
> is impossible?
>

I think that the problem is that you are not even glancing at what I say
before you form your baseless rebuttal.

I have already proven that the H() to H_Hat() relationship is the same
as the conventional self-referential halting problem counter-example
relationship by providing its exact source code.

I adapted Mike's version of H_Hat(),
His comments regarding the halting decision were incorrect.

On 10/20/2020 8:57 PM, Mike Terry wrote:
> OK. I've added a valid implementation for H_Hat below.

> int H_Hat(u32 M)
> {
> int Abort = DebugTrace(M, M);
> if (Abort)
> {

> // DebugTrace says M(M) does not halt
> HALT // ..so we halt
> }
> else
> {
> // DebugTrace says M(M) halts
> for (;;); // ..so we loop
> }
> }

// M has address of H_Hat()
int H_Hat(u32 M)
{
int Abort = DebugTrace(M, M);
if (Abort)
{
MOV_EAX_0 // DebugTrace says that M(M)
HALT // has been aborted
}
else
{
MOV_EAX_1 // M(M) has halted
HERE: goto HERE;
HALT
}
}

The much more subtle nuance that cannot be understood by anyone that is
not an expert in this field and only then with very intense focused
concentration is that my simple change to the halting question converts
the halting problem from an undecidable problem into a decidable problem.

Did the input program have to be aborted to prevent the halt decider

from getting stuck in infinite execution?

Cannot be thwarted by pathological self-reference.

It is no longer impossible for a halt decider to divide all of its
inputs into (a) halting and (b) would not otherwise halt.

[olcott]

On 10/22/2020 10:25 AM, Mike Terry wrote:
> On 22/10/2020 15:36, olcott wrote:
>> On 10/22/2020 7:00 AM, Richard Damon wrote:
>>> On 10/22/20 12:33 AM, olcott wrote:
>>>>
>>>> The difference is that it is no longer possible for H_Hat() to do the
>>>> opposite of what H() decides. This transforms an undecidable problem
>>>> into a decidable problem.
>>>
>>> If H_Hat no longer does what the proof defined, then your demonstration
>>> is no longer applicable to the proof.
>>>
>>
>> If the halt decider is to report whether or not its input halts another
>> program can be constructed on the the basis of this halt decider that
>> does the opposite of whatever the halt decider decides.
>>
>> This is how H() and H_Hat() are defined in the Linz proof.
>>
>> If the halt decider is to report whether or not it aborted its input
>> program because its input program would otherwise cause the halt decider
>> to get stuck in infinite execution then this other program can no longer
>> fool its halt decider and do the opposite of whatever it decides.
>>
>> If H() aborts the execution of H_Hat() then H_Hat() cannot continue to
>> execute because H() has complete control over H_Hat.
>>
>> The end result of this slight change is that the halting problem can no
>> longer be shown to be undecidable.
>>
>
> It is suspicious that in none of this have you ever stated what is
> actually wrong in the Linz proof.

When the halting problem is defined as:
bool Does_It_Halt(u32 P, u32 I)
another program can be constructed on the basis of Does_It_Halt() that
does the opposite of whatever Does_It_Halt() decides.

When the halting problem is defined as:
bool Was_Its_Execution_Aborted(u32 P, u32 I)

another program CANNOT be constructed on the basis of
Was_Its_Execution_Aborted() that does the opposite of whatever
Was_Its_Execution_Aborted() decides.

All of the cases where Was_Its_Execution_Aborted() returns true are
cases of non-halting behavior.

All of the cases where Was_Its_Execution_Aborted() returns false are
cases of halting behavior.

> It's almost as though you accept
> there is nothing wrong with it, and yet you still think its conclusion
> is incorrect!  Or that you can't see anything wrong with it, and in your
> head the mistake in the proof is that its conclusion is wrong? (Thinking
> a conclusion is wrong does not refute anything...)
>
> Anyhow, you talk about the halt decider reporting that it "aborted its
> input program, because blah blah".  If you read the Linz proof, you'll
> notice that it is completely unaffected of any internal reasoning as to
> WHY H might have made whatever decision it made.  All it depends on is
> that H actually makes a decision!
>

In the Linz case if a program would not halt and we are asking would it
halt and we abort the execution of H_Hat() then H() gets the wrong
answer because H() says that it would not halt and it does halt.

If we keep everything else the same except change the question to:
Was the input program aborted because it would not otherwise terminate?

Now when we answer yes we get the right answer. H_hat() cannot possibly
do the opposite of what H() decides because H_Hat() is under the
complete control of H().

> In your example, as long as H actually makes /some/ decision, the H_Hat
> will do the opposite of what H decided, and so the Linz proof will be

No not at all, not in the least little bit, as exaplained above.

> confirmed, not refuted.  If H loops, never making any decision, then H

That violates the defintion of a halt decider.

> is not a decider for the H_Hat(H_Hat) question (contrary to what you
> have always explicitly stated) and so is irrelevant to the Linz proof.
>
> You have said you won't reveal your final code unless I (and others)
> agree that what you've said so far already proves your point.  Well, you
> haven't proved anything, so that's that.
>

I took me 12,000 hours to derive this simple little proof so it is OK if
you don't get it right away.

> So... this was to be the culmination of your life's work, and now you're
> simply not going to publish it?  I thought the whole purpose of

I didn't say that. As soon as people pay enough attention they will see
that I am correct.

> producing the actual TMs was that it would override any objections
> people raised to a mere verbal claim, and prove you right despite the
> objections?
>

The "objections" are merely not paying enough attention to understand
what I am saying.

> Two years ago I told you that if you just gave your reasoning and
> perhaps some high-level pseudo-code, and forgot about producing actual
> "TM"s and traces and whatnot, people would quickly tell you your mistake
> and you could save months of effort.  And it turns out (no surprise)
> that this was correct!  Had you posted 2 years ago just what you've said
> in this thread people would have said exactly the same as they're saying
> now, and nothing whatsoever would be different, except you would have
> saved a year's work on your part.  :)
>
> Regards,
> Mike.
>

[Mr Flibble]

Excellent question; in fact it is the ONLY question that matters .. we await Olcott's answer... ;D

/Flibble

--
¬

[Mr Flibble]

On 20/10/2020 17:33, olcott wrote:
> x86utm is as much as possible a Universal Turing Machine UTM that has the x86 language as its Turing Machine Description language.

Occam's Razor suggests that my assumption that Turing is correct and you, random Usenet person, are incorrect is a fair assumption so I don't have the time to read your refutation. If your "solution" to the HP is an "oracle" then:

"A machine with an oracle for the halting problem can determine whether particular Turing machines will halt on particular inputs, but they cannot determine, in general, if machines equivalent to themselves will halt."

/Flibble

--
¬

[olcott]

On 10/22/2020 11:54 AM, Mr Flibble wrote:
> On 20/10/2020 17:33, olcott wrote:
>> x86utm is as much as possible a Universal Turing Machine UTM that has
>> the x86 language as its Turing Machine Description language.
>
> Occam's Razor suggests that my assumption that Turing is correct and

Perhaps you are totally unaware that Occam's Razor is merely a heuristic
used to save time and money and no aspect what-so-ever of correct
reasoning.

> you, random Usenet person, are incorrect is a fair assumption so I don't
> have the time to read your refutation.  If your "solution" to the HP is
> an "oracle" then:
>
> "A machine with an oracle for the halting problem can determine whether
> particular Turing machines will halt on particular inputs, but they
> cannot determine, in general, if machines equivalent to themselves will
> halt."
>
> /Flibble
>


--

Copyright 2020 Pete Olcott

[Mr Flibble]

On 22/10/2020 17:57, olcott wrote:
> On 10/22/2020 11:54 AM, Mr Flibble wrote:
>> On 20/10/2020 17:33, olcott wrote:
>>> x86utm is as much as possible a Universal Turing Machine UTM that has the x86 language as its Turing Machine Description language.
>>
>> Occam's Razor suggests that my assumption that Turing is correct and
>
> Perhaps you are totally unaware that Occam's Razor is merely a heuristic used to save time and money and no aspect what-so-ever of correct reasoning.

Yes I am aware that it a heuristic which I can use to decide on what I spend my time doing or thinking about. Life is fucking finite and time is fucking precious, mate, and there is no fucking afterlife. Stop wasting our time.

/Flibble

--
¬

[olcott]

On 10/22/2020 11:56 AM, Malcolm McLean wrote:

> On Thursday, 22 October 2020 at 17:38:49 UTC+1, olcott wrote:
>> On 10/22/2020 10:25 AM, Mike Terry wrote:
>>> On 22/10/2020 15:36, olcott wrote:
>>>> On 10/22/2020 7:00 AM, Richard Damon wrote:
>>
>>>> The end result of this slight change is that the halting problem can no
>>>> longer be shown to be undecidable.
>>>>
>>>
>>> It is suspicious that in none of this have you ever stated what is
>>> actually wrong in the Linz proof.
>> When the halting problem is defined as:
>> bool Does_It_Halt(u32 P, u32 I)
>> another program can be constructed on the basis of Does_It_Halt() that
>> does the opposite of whatever Does_It_Halt() decides.
>>
>> When the halting problem is defined as:
>> bool Was_Its_Execution_Aborted(u32 P, u32 I)
>>
>> another program CANNOT be constructed on the basis of
>> Was_Its_Execution_Aborted() that does the opposite of whatever
>> Was_Its_Execution_Aborted() decides.
>>

> As I said, you're right. If we change the question from "will the program
> halt?" to "will DebugTrace raise an abortion anywhere on the call stack?"
> the paradox goes away.
>
> I'll leave it to others to explain why this only seems to refute the LInz
> proof that halting is undecideable.
>

It refutes the general assertion that the halting problem is undecidable
by showing how the halting question can be transformed into an
equivalent question that cannot be thwarted by pathological self-reference.

So within Linz's faulty assumption that the only possible way to create
a universal halt decider is to directly ask the question:
Does the input program halt on its input?
The Linz proof is correct.

When we realize that this assumption is faulty and instead ask the
question: Was the execution of the input program on its input aborted?

Then creating a universal halt decider is no longer "proved" to be
impossible on the basis of the conventional self-referential halting
problem counter-examples.

The halt decider either detects non-halting behavior and reports it or
allows the input program to terminate on its own.

[olcott]

The only question that matters more than any other question is whether
or not changing the question from:
(a) Does the program halt on its input?
(b) Was the program aborted because non-halting behavior was detected?

eliminates the undecidability of all of the conventional
self-referential halting problem proof counter-examples?

How the halt decider actually decides these conventional
self-referential halting problem proof counter-examples is icing on the
cake because its basis is a crucial detail about the halting problem
counter-examples that no one (besides me) ever noticed for 80 years.

[Mr Flibble]

hubris
/ˈhjuːbrɪs/

noun

excessive pride or self-confidence.

"the self-assured hubris among economists was shaken in the late 1980s"

Similar:
arrogance
conceit
conceitedness
haughtiness
pride
vanity
self-importance
self-conceit
pomposity
superciliousness
feeling of superiority
hauteur
uppitiness
big-headedness

Opposite:
modesty
(in Greek tragedy) excessive pride towards or defiance of the gods, leading to nemesis.

/Flibble

--
¬

[olcott]

On 10/22/2020 11:57 AM, Mike Terry wrote:
> On 22/10/2020 16:45, Ben Bacarisse wrote:

>> He has!  He's wrong, of course, but he /has/ said.  The part PO disputes
>> is asserting that H can not give the correct halting answer for the
>> input pair <[H^], [H^]>.  And to show that that assertion is wrong he
>> was going to produce two actual Turing machines, fully encoded, exactly
>> as in Linz, but where H correctly decides the <[H^], [H^]> case.  We
>> will never see that.
>>
>
> That doesn't count as stating what is wrong with the Linz proof, because
> "H can not give the correct halting answer for the input pair <[H^],
> [H^]>" is a /conclusion/ within the proof, based on a contradiction
> generated in turn by the previous state transition diagrams.
>

Within Linz's faulty assumption that the only possible way to create a

universal halt decider is to directly ask the question:
Does the input program halt on its input?
The Linz proof is correct.

When we realize that this assumption is faulty and instead ask the
question: Was the execution of the input program on its input aborted

because non halting behavior was detected?

Then creating a universal halt decider is no longer "proved" to be
impossible on the basis of the conventional self-referential halting
problem counter-examples.

The halt decider either detects non-halting behavior and reports it or
allows the input program to terminate on its own.

> PO would need to do one of the following:  identify one of the state
> transition claims which is wrong; agree that the state transition
> diagrams are correct, but there is no contradiction in them; or say that
> there is a contradiction, but this doesn't mean that one of the
> assumptions leading to the contradiction is wrong; or say that one of
> the assumptions leading to the contradiction is wrong, but it is some
> other assumption than "H is a halt decider"; etc..
>
> Just saying "It's wrong that H can not give the correct halting answer
> for the input pair <[H^], [H^]>" is just disagreeing with a conclusion.
>
> Perhaps I should have said that he has never identified the specific
> /reasoning/ step in the proof which is wrong.  (If he had, we could have
> expanded any missing/unclear reasoning steps to the point where he would
> have to agree that particular step was in fact ok.  Hmm, ok maybe we
> couldn't do that as for some people there's really no convincing them,
> but I don't believe he's ever been this specific about the problem.  I
> could be wrong on that I guess.)
>
> Mike.

[olcott]

Ad hominem attacks are the first resort of clueless wonders.

> noun
>
> excessive pride or self-confidence.
>
> "the self-assured hubris among economists was shaken in the late 1980s"
>
> Similar:
> arrogance
> conceit
> conceitedness
> haughtiness
> pride
> vanity
> self-importance
> self-conceit
> pomposity
> superciliousness
> feeling of superiority
> hauteur
> uppitiness
> big-headedness
>
> Opposite:
> modesty
> (in Greek tragedy) excessive pride towards or defiance of the gods,
> leading to nemesis.
>
> /Flibble
>


--

Copyright 2020 Pete Olcott

[Mr Flibble]

And you still haven't answered the question: how does it "detect" that the unknown function never terminates, clueless WANKER?

/Flibble

--
¬

[olcott]

On 10/22/2020 12:27 PM, Malcolm McLean wrote:

> I transforms it into what looks like an equivalent question.

>>
>> So within Linz's faulty assumption that the only possible way to create
>> a universal halt decider is to directly ask the question:
>> Does the input program halt on its input?
>> The Linz proof is correct.
>>
>> When we realize that this assumption is faulty and instead ask the
>> question: Was the execution of the input program on its input aborted?
>>

> You're asking a different question.

>>
>> Then creating a universal halt decider is no longer "proved" to be
>> impossible on the basis of the conventional self-referential halting
>> problem counter-examples.
>>

> Linz proved the a halt decider cannot be a Turing machine. Not that no
> halt decider is possible. You've managed to smuggle into H information
> about whether H is called directly or not. So far, no-one has called you
> out on it, so you're doing well.

>>
>> The halt decider either detects non-halting behavior and reports it or
>> allows the input program to terminate on its own.
>>

> Sure. The details of the infinite loop detection aren't important here.
>

When-so-ever the halting problem question is stated as:
Was the execution of the input program on its input aborted because
non-halting behavior was detected?

The undecidability of the halting problem has been refuted.

[Mr Flibble]

I am calling TROLL at this point. Move on, nothing to see here.

/Flibble

--
¬

[olcott]

Unless what I have currently presented is sufficiently understood no one
is paying enough attention to appreciate the next step of how halting is
decided.

[Mr Flibble]

I recommend you read my definition of the word "hubris" again and then spend some time in quiet self-reflection.

/Flibble

--
¬

[Jeff Barnett]

Alright. I conclude that you haven't paid enough attention to what you
said; but that's okay, it's gibberish. What is the real problem is you
haven't paid enough attention to what your betters have said.

See? I just agreed with you. Well I've agreed with what you said but
pointed the pronouns more accurately. I hope that doesn't mean we have
to justify the self reference in this case.
--
Jeff Barnett

[olcott]

I recommend that you earnestly try to actually understand what I am
saying before providing any foolishly baseless attempts at rebuttal.

[Mr Flibble]

Rebut what exactly? You repeatedly refuse to give a straight answer to the questions that get to the heart of the matter. You have no refutation to rebut, dear.

/Flibble

--
¬

[olcott]

On 10/22/2020 12:45 PM, Malcolm McLean wrote:

> On Thursday, 22 October 2020 at 18:30:33 UTC+1, Mr Flibble wrote:
>>
>> And you still haven't answered the question: how does it "detect" that the unknown function never terminates, clueless WANKER?
>>

> The claim is to have refuted the Linz proof that no universal halt detector is possible. Not to have a completely functional
> halt detector.
>

The actual revised claim is that the Linz proof is correct based on its
false assumption that the only way to define a universal halt decider is
to create a program that answers the following question:
Does the input program halt on its input?

When-so-ever the halting problem question is stated as:

Was the execution of the input program on its input aborted because
non-halting behavior was detected?

The undecidability of the halting problem has been refuted.

[Mr Flibble]

On 22/10/2020 19:13, olcott wrote:

You are now on automatic and are just restating the same thing without addressing the actual question.

I can also restate things in a similar way:

TROLL DETECTED.

/Flibble

--
¬

[olcott]

On 10/22/2020 12:58 PM, Malcolm McLean wrote:

> On Thursday, 22 October 2020 at 18:32:25 UTC+1, olcott wrote:
>> On 10/22/2020 12:27 PM, Malcolm McLean wrote:
>>> On Thursday, 22 October 2020 at 18:09:33 UTC+1, olcott wrote:
>>>> On 10/22/2020 11:56 AM, Malcolm McLean wrote:
>>
>>>> It refutes the general assertion that the halting problem is undecidable
>>>> by showing how the halting question can be transformed into an
>>>> equivalent question that cannot be thwarted by pathological self-reference.
>>>>
>>> I transforms it into what looks like an equivalent question.
>>

>> When-so-ever the halting problem question is stated as:
>> Was the execution of the input program on its input aborted because
>> non-halting behavior was detected?
>>
>> The undecidability of the halting problem has been refuted.
>>

> Sounds reasonable, doesn't it?

Most people here have not gotten anywhere near the point where it seems
that what I am saying is reasonable.

They are all stuck on I know that you must be wrong because I really
really believe that you are wrong therefore there is no need to pay any
attention to what you say.

> As I said, if you want H to make the correct call
> on H_Hat, you have to smuggle into H the information about whether it is
> being called directly or through H_Hat. You appear to have done that quite well.
>
> People are distracted because you don't say how DebugTrace detects the "no-
> halt" condition, but that's not relevant here.

[olcott]

On 10/22/2020 1:17 PM, Malcolm McLean wrote:
> On Thursday, 22 October 2020 at 19:12:30 UTC+1, Mr Flibble wrote:
>> olcott

>>
>>> I recommend that you earnestly try to actually understand what I am saying before providing any foolishly baseless attempts at rebuttal.
>> Rebut what exactly? You repeatedly refuse to give a straight answer to the questions that get to the heart of the matter. You have no refutation to rebut, dear.
>>

> You've attempted to rebut his refutation of Linz, and in my view failed. He doesn't need to describe how his halt
> detector works to refute Linz.
> When we change the question from "does this program halt?" to "does DebugTrace raise an abortion condition on
> this program because it would otherwise never terminate?" we don't change anything important, right?
> Or do we?
>

You are the only one that is getting it, congratulations!

[olcott]

On 10/22/2020 1:17 PM, Malcolm McLean wrote:
> He doesn't need to describe how his halt detector works to
> refute Linz.

[olcott]

On 10/22/2
020 12:58 PM, Malcolm McLean wrote:

> On Thursday, 22 October 2020 at 18:32:25 UTC+1, olcott wrote:
>> On 10/22/2020 12:27 PM, Malcolm McLean wrote:
>>> On Thursday, 22 October 2020 at 18:09:33 UTC+1, olcott wrote:
>>>> On 10/22/2020 11:56 AM, Malcolm McLean wrote:
>>
>>>> It refutes the general assertion that the halting problem is undecidable
>>>> by showing how the halting question can be transformed into an
>>>> equivalent question that cannot be thwarted by pathological self-reference.
>>>>
>>> I transforms it into what looks like an equivalent question.
>>

>> When-so-ever the halting problem question is stated as:
>> Was the execution of the input program on its input aborted because
>> non-halting behavior was detected?
>>
>> The undecidability of the halting problem has been refuted.
>>

> Sounds reasonable, doesn't it? As I said, if you want H to make the correct call

> on H_Hat, you have to smuggle into H the information about whether it is
> being called directly or through H_Hat. You appear to have done that quite well.
>

Executing von Neumann architecture machine in DebugStep() mode or
executing a UTM inside another UTM is a perfectly legitimate thing to
do. By doing this a halt decider can directly see all the relevant details.

> People are distracted because you don't say how DebugTrace detects the "no-
> halt" condition, but that's not relevant here.
>

[Mr Flibble]

On 22/10/2020 19:30, olcott wrote:
> On 10/22/2
> 020 12:58 PM, Malcolm McLean wrote:
>> On Thursday, 22 October 2020 at 18:32:25 UTC+1, olcott wrote:
>>> On 10/22/2020 12:27 PM, Malcolm McLean wrote:
>>>> On Thursday, 22 October 2020 at 18:09:33 UTC+1, olcott wrote:
>>>>> On 10/22/2020 11:56 AM, Malcolm McLean wrote:
>>>
>>>>> It refutes the general assertion that the halting problem is undecidable
>>>>> by showing how the halting question can be transformed into an
>>>>> equivalent question that cannot be thwarted by pathological self-reference.
>>>>>
>>>> I transforms it into what looks like an equivalent question.
>>>
>>> When-so-ever the halting problem question is stated as:
>>> Was the execution of the input program on its input aborted because
>>> non-halting behavior was detected?
>>>
>>> The undecidability of the halting problem has been refuted.
>>>
>> Sounds reasonable, doesn't it? As I said, if you want H to make the correct call
>> on H_Hat, you have to smuggle into H the information about whether it is
>> being called directly or through H_Hat. You appear to have done that quite well.
>>
>
> Executing von Neumann architecture machine in DebugStep() mode or executing a UTM inside another UTM is a perfectly legitimate thing to do. By doing this a halt decider can directly see all the relevant details.

Mate, you need to do three things:

1) Re-read what a UTM actually is;
2) Re-read what the halting problem actually is;
3) take your meds.

I could add:

4) Fuck off.

But that would be rude.

/Flibble

--
¬

[olcott]

On 10/22/2020 1:30 PM, Malcolm McLean wrote:

> I think that's going a bit far. There will be other people who understand exactly what you have done.

"Will be", yes for sure, eventually.

The first step of this "will be" is to drop the idea that I am certainly
incorrect long enough to actually pay attention to what I am saying.

> But at least some posters are unable to provide a refutation of what you have achieved.So it
> isn't trivial.
>

Yes it looks like I am on the right track so far.

[Joe Pfeiffer]

Crackpots will always be among us. There is no one to blame for
engaging this one but yourself. You've established he's not worth your
time; let those who wish to try to teach the unteachable spend their
time as they wish. Killfile him and move on.

[Mr Flibble]

You are right: I have wasted enough time on this troll (assuming he is a troll and not simply batshit crazy like you suggest).

/Flibble

--
¬

[Lew Pitcher]

On Thu, 22 Oct 2020 19:59:17 +0100, Mr Flibble wrote:

> On 22/10/2020 19:55, Joe Pfeiffer wrote:

[snip]

>> Crackpots will always be among us. There is no one to blame for
>> engaging this one but yourself. You've established he's not worth your
>> time; let those who wish to try to teach the unteachable spend their
>> time as they wish. Killfile him and move on.
>
> You are right: I have wasted enough time on this troll (assuming he is a
> troll and not simply batshit crazy like you suggest).

In this case, there doesn't seem to be much of a difference. He passed
the "duck test" ("If it looks like a duck, and quacks like a duck, then
we can call it a duck."), anyway.

--
Lew Pitcher
"In Skills, We Trust"

[olcott]

On 10/22/2020 2:43 PM, André G. Isaak wrote:
> On 2020-10-22 08:41, olcott wrote:
>> On 10/22/2020 7:12 AM, Richard Damon wrote:
>
>>> Your argument seems to basically devolve into redefining the Halt
>>> Detector definition to have a trinary output, Yes, it Halt, No it
>>> doesn't, or I can't determine because it 'cheats'.
>>
>> No it is binary:
>> (a) Its execution was aborted because it would not otherwise halt.
>> (b) Its execution was allowed to continue until it terminated.
>
> So how exactly does that avoid the contradiction inherent in Linz proof?
>
> If the relation between your H and Ĥ is the same as in the Linz proof,
> the same contradiction results despite your change of wording.
>
> André
>

If we keep everything in the Linz proof the same** except we change the
name of what the halt decider decides:

(a) Decision:Not_Halting and
Behavior:Halts (a contradiction)

(b) Decision:Aborted_Execution_Because_Not_Halting_Detected and
Behavior:Aborted Execution (not a contradiction)

http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf

** We also assume that the halt decider works on the basis of executing
its input program in DebugStep() mode until it detects non-halting
behavior or its input program terminates.

If the halt decider detects non halting behavior it immediately stops
executing its input in DebugStep() mode and returns its Boolean value.

If it returns a value meaning Not_Halting then a contradiction of formed
because its input program did halt.

If it returns a value meaning Aborted_Execution_Because_Not_Halting_Detected
then no contradiction is formed because its input program was aborted.

[olcott]

On 10/22/2020 2:53 PM, Ben Bacarisse wrote:

> olcott <No...@NoWhere.com> writes:
>
>> So within Linz's faulty assumption that the only possible way to
>> create a universal halt decider is to directly ask the question: Does
>> the input program halt on its input? The Linz proof is correct.
>

> So, just get at least one thing clear, when you said:
>
> "I provide the exact ⊢* wildcard states after the Linz H.q0 and after
> Ĥ.qx ... showing exactly how the actual Linz H would correctly decide
> the actual Linz (Ĥ, Ĥ)"
>
> and
>
> "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
> specs does not exist. I now have a fully encoded pair of Turing
> Machines H / Ĥ proving them wrong."
>
> and
>
> "I am waiting to encode the UTM in C++ so that I can actually execute
> H on the input pair: (Ĥ, Ĥ). This should take a week or two. It is not
> a universal halt decider, yet it is exactly and precisely the Peter
> Linz H and Ĥ, with H actually deciding input pair: (Ĥ, Ĥ) on the basis
> of Ĥ actually deciding itself."
>
> you were wrong? Do you now acknowledge that Linz is right about his
> construction of H^ from H, and you were ... mistaken ... when you said
> you had "exactly and precisely" what Linz was talking about?
>

The more general claim that I made is that I would show exactly how the
conventional self-referential halting problem proof counter-examples do
not prove that the halting problem is undecidable.

This has now been totally fulfilled.

As soon as you acknowledge this we can move on to talking about other
aspects.

[André G. Isaak]

On 2020-10-22 14:13, olcott wrote:
> On 10/22/2020 2:43 PM, André G. Isaak wrote:
>> On 2020-10-22 08:41, olcott wrote:
>>> On 10/22/2020 7:12 AM, Richard Damon wrote:
>>
>>>> Your argument seems to basically devolve into redefining the Halt
>>>> Detector definition to have a trinary output, Yes, it Halt, No it
>>>> doesn't, or I can't determine because it 'cheats'.
>>>
>>> No it is binary:
>>> (a) Its execution was aborted because it would not otherwise halt.
>>> (b) Its execution was allowed to continue until it terminated.
>>
>> So how exactly does that avoid the contradiction inherent in Linz proof?
>>
>> If the relation between your H and Ĥ is the same as in the Linz proof,
>> the same contradiction results despite your change of wording.

No. If your H() returns 'terminated normally', then Ĥ(Ĥ) must have been
forced to abort if they were really using the same halt deciding code.

And if your H() returns 'forced to abort', then Ĥ(Ĥ) must have
terminated normally if they were really using the same halt deciding code.

The contradiction is there despite your change of wording.

André


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

[olcott]

On 10/22/2020 3:34 PM, André G. Isaak wrote:
> On 2020-10-22 14:13, olcott wrote:
>> On 10/22/2020 2:43 PM, André G. Isaak wrote:
>>> On 2020-10-22 08:41, olcott wrote:
>>>> On 10/22/2020 7:12 AM, Richard Damon wrote:
>>>
>>>>> Your argument seems to basically devolve into redefining the Halt
>>>>> Detector definition to have a trinary output, Yes, it Halt, No it
>>>>> doesn't, or I can't determine because it 'cheats'.
>>>>
>>>> No it is binary:
>>>> (a) Its execution was aborted because it would not otherwise halt.
>>>> (b) Its execution was allowed to continue until it terminated.
>>>
>>> So how exactly does that avoid the contradiction inherent in Linz proof?
>>>
>>> If the relation between your H and Ĥ is the same as in the Linz
>>> proof, the same contradiction results despite your change of wording.
>
> No. If your H() returns 'terminated normally', then Ĥ(Ĥ) must have been
> forced to abort if they were really using the same halt deciding code.
>
> And if your H() returns 'forced to abort', then Ĥ(Ĥ) must have
> terminated normally if they were really using the same halt deciding code.

bool DebugTrace() only returns forced to abort or not forced to abort.

[André G. Isaak]

So replace 'terminated normally' with 'not forced to abort' in what I
say above. There is still a contradiction.

[olcott]

(1) Original self-referential halting problem counter example
(a) Decision: ~Halting and Behavior: Halts (a contradiction)
(b) Decision: Halting and Behavior: Loops (a contradiction)

(2) Revised halting problem decision
(a) Decision: Aborted_Execution and Behavior: Aborted Execution
(b) Decision: ~Aborted_Execution and Behavior: ~Aborted Execution

In the first case the decision and the behavior contradict each other.
In the second case the decision and the behavior DO NOT contradict each
other.

It is only hard if it is welded into your brain that I must be wrong.

[olcott]

On 10/22/2020 5:14 PM, Mike Terry wrote:
> On 22/10/2020 17:38, olcott wrote:

>> On 10/22/2020 10:25 AM, Mike Terry wrote:
>>> On 22/10/2020 15:36, olcott wrote:
>>>> On 10/22/2020 7:00 AM, Richard Damon wrote:

>>>>> On 10/22/20 12:33 AM, olcott wrote:
>>>>>>
>>>>>> The difference is that it is no longer possible for H_Hat() to do the
>>>>>> opposite of what H() decides. This transforms an undecidable problem
>>>>>> into a decidable problem.
>>>>>
>>>>> If H_Hat no longer does what the proof defined, then your
>>>>> demonstration
>>>>> is no longer applicable to the proof.
>>>>>
>>>>
>>>> If the halt decider is to report whether or not its input halts another
>>>> program can be constructed on the the basis of this halt decider that
>>>> does the opposite of whatever the halt decider decides.
>>>>
>>>> This is how H() and H_Hat() are defined in the Linz proof.
>>>>
>>>> If the halt decider is to report whether or not it aborted its input
>>>> program because its input program would otherwise cause the halt
>>>> decider
>>>> to get stuck in infinite execution then this other program can no
>>>> longer
>>>> fool its halt decider and do the opposite of whatever it decides.
>>>>
>>>> If H() aborts the execution of H_Hat() then H_Hat() cannot continue to
>>>> execute because H() has complete control over H_Hat.

>>>>
>>>> The end result of this slight change is that the halting problem can no
>>>> longer be shown to be undecidable.
>>>>
>>>
>>> It is suspicious that in none of this have you ever stated what is
>>> actually wrong in the Linz proof.
>>
>> When the halting problem is defined as:
>> bool Does_It_Halt(u32 P, u32 I)
>> another program can be constructed on the basis of Does_It_Halt() that
>> does the opposite of whatever Does_It_Halt() decides.
>>
>

> Yes, regardless of the internal details of Does_It_Halt().

>
>> When the halting problem is defined as:
>> bool Was_Its_Execution_Aborted(u32 P, u32 I)
>>
>> another program CANNOT be constructed on the basis of
>> Was_Its_Execution_Aborted() that does the opposite of whatever
>> Was_Its_Execution_Aborted() decides.
>

> Sure, if you interpret your question literally as asking whether P would
> actually be aborted if it executes under the UTM within
> Was_Its_Execution_Aborted()!
>
> However, another program CAN be constructed on the basis of
> Was_Its_Execution_Aborted() that:
> -   halts if Was_Its_Execution_Aborted() decides "aborted"
> -   loops if Was_Its_Execution_Aborted() decides "halted"
>
> (right?)

Wrong. There is no way to make the revised halting question contradictory.

DebugTrace() either reports that it has aborted the execution of its
input or it reports that its input has not been aborted after its input
has terminated.

> So your new question literally interpreted is irrelevant to the "does it
> /actually/ halt" problem.  (I.e. the one discussed in the literature and
> specifically the Linz proof.)
>
> Let me give an example which makes that obvious...
>
> Suppose I wrote an implementation of bool Was_Its_Execution_Aborted(u32
> P, u32 I) which works like this:
> 1.  Run P in our UTM until either it halts by itself,
>     or 5 instructions have been executed.
> 2.  If P halted by itself, report back that P halted.
> 3.  Otherwise abort P, and report back that P was aborted.
>
> As you say, Was_Its_Execution_Aborted() can (will!) give a correct
> answer to the question "Would P's execution under the UTM within
> Was_Its_Execution_Aborted() be aborted?"
>
> For example, let's suppose that P actually does halt but it takes 500
> instructions.  OK, we now have to perform two experiments to check
> whether Was_Its_Execution_Aborted() is answering correctly:
> -  first we run Was_Its_Execution_Aborted(P, I) and
>    note that it returns "execution was aborted".
> -  next we trace step by step through
>    Was_Its_Execution_Aborted(H_Hat, H_Hat), and note that
>    indeed the execution of H_Hat WAS aborted!
>
> Was_Its_Execution_Aborted() managed to answer correctly!  Yipeee.
>
> (Alternatively we could combine both of these experiments into one,
> looking for two things at once, but conceptually we have two separate
> experiments.)
>
> Unfortunately, it is now obvious that asking the question "Would P's
> execution under the UTM within Was_Its_Execution_Aborted() be aborted?"
> is not equivalent to the halting question, and the fact that such a new
> question can be correctly answered has no relevence to the HP question
> or to Linz proof.
>

That you can define a halt decider that does not meet the conventional
specs of a halt decider provide zero rebuttal what-so-ever.

> In fact doesn't the new question, literally interpreted as above, seem a
> little facile?
>
> The only way to make your new question relevant to the Linz proof would
> be if your implementation of Was_Its_Execution_Aborted() had the
> additional characteristics:
>
> a)  if Was_Its_Execution_Aborted() returns "program halted"
>     then H_Hat(H_Hat) [IF RUN NATIVELY] will actually terminate
YES

> b)  if Was_Its_Execution_Aborted() returns "program aborted"
>     then H_Hat(H_Hat) [IF RUN NATIVELY] will never halt

Not really because H_Hat() has the same halt decider as H() so when we
run H_Hat() on itself it aborts itself.

> If Was_Its_Execution_Aborted() had those properties, it could just be
> name-changed to Does_It_Halt() and I think you've already admitted
> elsewhere the Linz argument is correct with the [IF RUN NATIVELY]
> proviso, and so this can't be possible.

We could say that the Linz proof is correct on the basis of its terribly
incorrect basic assumptions or we cold say that the Linz proof is
fundamentally incorrect because its foundational basis is incorrect.
These are two different ways of saying the same thing.

>>
>> All of the cases where Was_Its_Execution_Aborted() returns true are
>> cases of non-halting behavior.
>>
>> All of the cases where Was_Its_Execution_Aborted() returns false are
>> cases of halting behavior.
>>
>
> Um, ok, that /sounds/ like you're saying it has characteristics (a) and
> (b) above?  In which case although it may be answering your new
> question, IT WOULD AT THE SAME TIME BE CORRECTLY ANSWERING THE OLD
> QUESTION!

No because in the case where DebugTrace() decides to abort its input in
the prior language this would be a case where H() decides not halting
and then H_Hat() halts.

> ..And it can't be doing that, because then H_Hat could employ the "do
> the opposite of what H() says strategy, which I think you've agreed
> elsewhere works for the OLD question.
>
> Is the issue here that when you say "cases of non-halting behavior", you
> mean something other than "cases where P run with input I never halts
> [when run natively]"?
>

Not exactly.
Since the invocation of DebugTrace() by H_Hat() aborts H_Hat() we can't
really say that when it runs natively it never halts. We can say that
unless H_Hat() is aborted it would never halt.

> Thinking about it, your use of the term "non-halting *behavior*" seems a
> likely area of confusion!
>
> What exactly do you mean by "cases of non-halting behavior"?

The obvious one is infinite loop. Can you think of the other one?

> And just to be doubly clear, does this /mean/ the same as "program run
> /natively/ with given input never halts"?  (I.e. in the usual sense of
> "non-halting TMs" in the literature and HP proof?)
>

If H_Hat() is run and never aborted it would never halt.
If it is executed with itself as input its invocation of DebugTrace()
would abort this input.

>>> It's almost as though you accept there is nothing wrong with it, and
>>> yet you still think its conclusion is incorrect!  Or that you can't
>>> see anything wrong with it, and in your head the mistake in the proof
>>> is that its conclusion is wrong? (Thinking a conclusion is wrong does
>>> not refute anything...)
>>>
>>> Anyhow, you talk about the halt decider reporting that it "aborted its
>>> input program, because blah blah".  If you read the Linz proof, you'll
>>> notice that it is completely unaffected of any internal reasoning as
>>> to WHY H might have made whatever decision it made.  All it depends on
>>> is that H actually makes a decision!
>>>
>>
>> In the Linz case if a program would not halt and we are asking would it
>> halt and we abort the execution of H_Hat() then H() gets the wrong
>> answer because H() says that it would not halt and it does halt.
>>
>> If we keep everything else the same except change the question to:
>> Was the input program aborted because it would not otherwise terminate?
>>
>> Now when we answer yes we get the right answer. H_hat() cannot possibly
>> do the opposite of what H() decides because H_Hat() is under the
>> complete control of H().
>>
>
> ..but as explained above, H_Hat CAN have the behaviour that it halts if
> H() decides it was aborted, and it loops if H() decides it terminated.

As soon as H_Hat() is terminated and DebugTrace() returns a value the
H_Hat() process ceases to exist in memory because it was stored on the
DebugTrace() stack.

> (The H_Hat in your skeleton code is designed exactly this way.)

It is designed to precisely match the Linz templates.


> [... snip ...]
>>> So... this was to be the culmination of your life's work, and now
>>> you're simply not going to publish it?  I thought the whole purpose of
>>
>> I didn't say that. As soon as people pay enough attention they will see
>> that I am correct.
>
> I fear this is one of your delusions!  Your proof is almost nonexistent

My proof is very very concise yet infinitely more elborate than any
rebuttals of it.

Try and show how a non existent H_Hat() that no longer exists as a
process in memory can do anything at all and you will start to begin to
see that changing the halt deciding question converts an undecidable
problem into a decidable one.

> - stepping back a bit I can cast it as another version of your numerous
> attempts to refute various proofs by redefining key terms in the proof,
> then pointing out that the proof no longer works using those new terms.
> I don't believe /anyone/ has ever agreed with /any/ of those attempts,
> so I can't see them starting now.
>

That no one agrees with me is zero rebuttal at all.

> In the end you will be left with the choice of "proving them wrong" by
> publishing the code anyway (and I think you can see by now that will get
> you nowhere), or abandoning your life's work, having wasted 12,000 hours
> (your own reckoning) unnecessarily.
>

Take my challenge and show how the H_Hat() process that no longer exists
in memory can do anything at all that is the opposite of what
DebugTrace() decided.


> It's slightly interesting that 12,000 is exactly the figure Dudley
> quotes that one of his Trisectors spent on the trisection problem in his
> essay:
>
> <http://web.mst.edu/~lmhall/WhatToDoWhenTrisectorComes.pdf>
>
> He remarks (of the trisector of course, not of you):
>
> "Twelve thousand working hours!  Full time is forty hours a week for
> fifty weeks, so the poor deluded man had devoted the equivalent of six
> years of his life to something as useless as finding two even numbers
> whose sum is odd.  What wouldn't you or I give for an extra six years of
> time?  What couldn't we accomplish?  What a deplorable waste!"
>
> In your case it must seem doubly wasteful, in that you could be exactly
> where you are now if you had simply published your high level design at
> the start of all this.  (Well, I suppose then you wouldn't have your x86
> emulator program, so there's some compensation...)
>
> Mike.

[olcott]

On 10/22/2020 6:34 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>

>> On 10/22/2020 9:57 AM, Ben Bacarisse wrote:
> <cut>
>>> Unfortunately, pairs like this -- where H and H^ are not related exactly
>>> as in Linz, or where they are but H gets the answer wrong -- are
>>> ten-a-penny. What you wasted everyone's time with was a clear claim to
>>> have a pair, H and H^, related exactly as in Linz, where H gives the
>>> correct halting answer for H(H^, H^). Do you now see that such a pair
>>> is impossible?
>>
>> I think that the problem is that you are not even glancing at what I
>> say before you form your baseless rebuttal.
>
> I didn't rebut anything. Mike Terry is doing the rebutting (and doing
> it very well I might add).
>
> If you want someone else picking your claim apart, I am happy to join
> in, but as you know I'm a nit-picking details guy. You won't get the
> big-picture view of your mistakes that Mike Terry will give you.
>
>> // M has address of H_Hat()
>> int H_Hat(u32 M)
>> {
>> int Abort = DebugTrace(M, M);
>> if (Abort)
>> {
>> MOV_EAX_0 // DebugTrace says that M(M)
>> HALT // has been aborted
>> }
>> else
>> {
>> MOV_EAX_1 // M(M) has halted
>> HERE: goto HERE;
>> HALT
>> }
>> }
>
> I'd start by saying that H_Hat neither includes nor makes reference to H
> as Linz's H^ does. Yes, I know that H is just a thin shim over
> DebugTrace but I am sure you want to get the details right.
>

Linz's H^ is defined as a sequence of two sets of modifications to his
H. DebugTrace() contains all of the ⊢* state transtions.

> Further questions: is DebugTrace vapourware or do you have it written
> and running?

The reason for the great delay is that I waited until I got DebugTrace()
fully operational before I presented H() and H_Hat().

> It you have it running, can you run DebugTrace(H_Hat,
> H_Hat) to get a return value? If not why not? If you can, what is the
> return value?
>

It took me a man-year to write my x86utm operating system. Now I finally
have the full basis to write the most robust halt deciding code.

[olcott]

On 10/22/2020 6:51 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
>> On 10/22/2020 2:53 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> So within Linz's faulty assumption that the only possible way to
>>>> create a universal halt decider is to directly ask the question: Does
>>>> the input program halt on its input? The Linz proof is correct.
>>>
>>> So, just get at least one thing clear, when you said:
>>>
>>> "I provide the exact ⊢* wildcard states after the Linz H.q0 and after
>>> Ĥ.qx ... showing exactly how the actual Linz H would correctly decide
>>> the actual Linz (Ĥ, Ĥ)"
>>>
>>> and
>>>
>>> "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
>>> specs does not exist. I now have a fully encoded pair of Turing
>>> Machines H / Ĥ proving them wrong."
>>>
>>> and
>>>
>>> "I am waiting to encode the UTM in C++ so that I can actually execute
>>> H on the input pair: (Ĥ, Ĥ). This should take a week or two. It is not
>>> a universal halt decider, yet it is exactly and precisely the Peter
>>> Linz H and Ĥ, with H actually deciding input pair: (Ĥ, Ĥ) on the basis
>>> of Ĥ actually deciding itself."
>>>
>>> you were wrong?
>

> Unanswered.

>
>>> Do you now acknowledge that Linz is right about his
>>> construction of H^ from H, and you were ... mistaken ... when you said
>>> you had "exactly and precisely" what Linz was talking about?
>

> Unanswered.
>
>> The more general claim that I made... is that I would show exactly how

>> the conventional self-referential halting problem proof
>> counter-examples do not prove that the halting problem is undecidable.
>

> You made this claim after you made the claims above, and only when you
> realised you could not do what you originally claimed to have done.
>
> Stop deflecting and come clean, or post what you said you had two years
> ago.

>
>> This has now been totally fulfilled.
>>
>> As soon as you acknowledge this we can move on to talking about other
>> aspects.
>

> Ha! You are using the fact that you are wrong now (no one will agree to
> this new claim) to prevent you posting the code that would prove you
> right! If it weren't all a big con, it would be logic comedy gold.
>

Maybe you don't really understand this stuff very well after all.
A person that memorizes these sort of things purely by rote has no depth
of understanding.

People can very easily directly see that I am correct when they try to
show how to make the input program do the opposite of whatever the halt
decider decides and find that this is no longer possible.

When the halt decider aborts its input program this input program can't
do anything because the memory of its process has been released.

[Chris M. Thomasson]

On 10/22/2020 10:19 AM, olcott wrote:
> On 10/22/2020 11:41 AM, Mr Flibble wrote:
>> On 20/10/2020 22:26, Chris M. Thomasson wrote:
>>> On 10/20/2020 11:40 AM, olcott wrote:

>>>> On 10/20/2020 1:11 PM, Mike Terry wrote:
>>>>> On 20/10/2020 17:33, olcott wrote:
>>>>>> x86utm is as much as possible a Universal Turing Machine UTM that has
>>>>>> the x86 language as its Turing Machine Description language.
>>>>>>

> (a) Does the program halt on its input?
> (b) Was the program aborted because non-halting behavior was detected?

Wait a minute... How is non-halting behavior detected in an unknown
function? Lets say an unknown function has been running for 100 years,
and still going strong... Would you say it has non-halting behavior? The
function could be programmed to self terminate after 409 years... If you
said it is non-halting, well, you would be 100% wrong!

Although, you "might" be right because the unknown function just might
be programmed to run for infinity. It never terminates. So, would your
decider have to run infinitely long to tell if the unknown function
never terminates? ;^)

[olcott]

On 10/22/2020 6:55 PM, Malcolm McLean wrote:

> On Friday, 23 October 2020 at 00:05:38 UTC+1, olcott wrote:
>> On 10/22/2020 5:14 PM, Mike Terry wrote:
>
>>> Is the issue here that when you say "cases of non-halting behavior", you
>>> mean something other than "cases where P run with input I never halts
>>> [when run natively]"?
>>>
>> Not exactly.
>> Since the invocation of DebugTrace() by H_Hat() aborts H_Hat() we can't
>> really say that when it runs natively it never halts. We can say that
>> unless H_Hat() is aborted it would never halt.
>>

> Abortion is sticky. So one there is an abortion anywhere in the system, the
> whole thing aborts. If you are running DebugTrace, this isn't a problem -
> just shunt the "abortion" condition up the instances.
> However a Turing machine can't abort itself.

H() executes DebugTrace() that creates a separate virtual machine
process and executes H_Hat() that executes DebugTrace() that creates a
separate virtual machine process and executes another H_Hat() process.

If DebugTrace() returns a value where 1 == Halts and 0 == ~Halts then

the conventional self-referential halting problem proof counter-example

can be created where H_Hat() does the opposite of whatever H() decides.

H() decides Halts so H_Hat Loops
H() decides Loops so H_Hat Halts

If DebugTrace() returns a value where 1 == Aborted and 0 == ~Aborted
then the conventional self-referential halting problem proof
counter-example CANNOT be created and H_Hat() CANNOT do the opposite of
whatever H() decides.

H() decides Aborted so H_Hat has already ceased to exist.
H() decides ~Aborted so H_Hat is allowed to execute to completion.

There are no longer any halting problem cases that can be shown to be
undecidable with the revised definition of the halt decider.

[olcott]

As has already been pointed out this does not make any difference.

In the original definition of the halt decider:

H() decides Halts so H_Hat Loops
H() decides Loops so H_Hat Halts

In the revised definition of the halt decider:

H() decides Aborted so H_Hat has already ceased to exist.
H() decides ~Aborted so H_Hat is allowed to execute to completion.

There are no longer any halting problem cases that can be shown to be
undecidable with the revised definition of the halt decider

> Lets say an unknown function has been running for 100 years,
> and still going strong... Would you say it has non-halting behavior? The
> function could be programmed to self terminate after 409 years... If you
> said it is non-halting, well, you would be 100% wrong!
>
> Although, you "might" be right because the unknown function just might
> be programmed to run for infinity. It never terminates. So, would your
> decider have to run infinitely long to tell if the unknown function
> never terminates? ;^)

The key case of correctly deciding the Linz H_hat() Bottom of page 319
http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf

Is very easy to decide because of a key detail about the halting problem
proofs that no one noticed for 80 years.

>>
>> eliminates the undecidability of all of the conventional
>> self-referential halting problem proof counter-examples?
>>
>> How the halt decider actually decides these conventional
>> self-referential halting problem proof counter-examples is icing on
>> the cake because its basis is a crucial detail about the halting
>> problem counter-examples that no one (besides me) ever noticed for 80
>> years.
>>
>>
>

[Chris M. Thomasson]

What happens if the unknown function never completes because it runs
forever?

>

[olcott]

There may be very complex cases that are very difficult to correctly
decide.

All that I have shown is that deciding the halting problem is no longer
impossible. By showing that deciding the halting problem is no longer
impossible I have refuted all of the proofs of its impossibility.

[Chris M. Thomasson]

Indeed. Well, especially if an unknown function never terminates. Or
just runs for 1000 years before terminating.

> All that I have shown is that deciding the halting problem is no longer
> impossible.

How?

[olcott]

The halting problem has never been about an unknown function.
A halt decider is not required to be psychic.

>
>
>> All that I have shown is that deciding the halting problem is no
>> longer impossible.
>
> How?
>

The way that the halting problem works is another program that is
exactly like that halt decider is slightly changed so that it does the
opposite of whatever the halt decider decides.

If the halt decide decides that it will halt it loops.
If the halt decider decides that it loops it halts.

I changed this so that the halt decider executes its input program in
DebugStep() mode until it decides that its input would not halt.

Then it aborts the execution of its input. Once the execution of the
input program has been aborted it can't do anything at all. If it can't
do anything at all then it can't do the opposite of whatever the halt
decider decides.

The aborted input is the programs would never halt unless they are aborted.

>
>> By showing that deciding the halting problem is no longer impossible I
>> have refuted all of the proofs of its impossibility.
>
>

[olcott]

On 10/22/2020 8:06 PM, Malcolm McLean wrote:

> If we call H_Hat directly, there are two instances of H_Hat.
>
> There are several ways of looking at what you are doing, depending
> on the exact details of the "abort" logic. One is to say that the Halt decider
> isn't a Turing machine because it can destroy its own execution environment.

Think of it in terms of a UTM the simply decides to stop executing its TM.

> Then Linz's proof doesn't apply. Another way of looking at it is to say that
> you've a hidden parameter (the number of live instances of H_Hat) which
> allows you to toggle the behaviour.
>

x86utm execute main() that executes H() that executes DebugTrace() that
creates a whole new process that executes H_Hat() in DebugStep() mode
that executes DebugTrace() that creates a whole new process that
executes H_hat() in DebugStep() mode.

Nothing is hidden DebugStep() can see every single detail of every
process that it executes and it can store some (or all) of these details
to be used later.

Since DebugTrace() itself is executed in its own process it can keep the
details of its own slave process separate from every other invocation of
every other slave process.

[olcott]

> Still unanswered.

>
>>>>> Do you now acknowledge that Linz is right about his
>>>>> construction of H^ from H, and you were ... mistaken ... when you said
>>>>> you had "exactly and precisely" what Linz was talking about?
>>>
>>> Unanswered.
>

> Again, no answer.

>
>>>> The more general claim that I made... is that I would show exactly how
>>>> the conventional self-referential halting problem proof
>>>> counter-examples do not prove that the halting problem is undecidable.
>>>
>>> You made this claim after you made the claims above, and only when you
>>> realised you could not do what you originally claimed to have done.
>>>
>>> Stop deflecting and come clean, or post what you said you had two years
>>> ago.
>>>
>>>> This has now been totally fulfilled.
>>>>
>>>> As soon as you acknowledge this we can move on to talking about other
>>>> aspects.
>>>
>>> Ha! You are using the fact that you are wrong now (no one will agree to
>>> this new claim) to prevent you posting the code that would prove you
>>> right! If it weren't all a big con, it would be logic comedy gold.
>>
>> Maybe you don't really understand this stuff very well after all.
>

> Sixteen years of equivocating, ducking and diving with nothing concrete
> to show for it. I hope you can see why someone would want to see the
> tangible and verifiable result you pretended to have in Dec 2018. It
> made such a change from the empty boasts. But then it turned out to be
> an empty boast as well, but this time one that you had to lie about
> because there was no wriggle room in what you had claimed to have.

>
>> When the halt decider aborts its input program this input program
>> can't do anything because the memory of its process has been released.
>

> You, two years ago:

>
> "I am waiting to encode the UTM in C++ so that I can actually execute
> H on the input pair: (Ĥ, Ĥ). This should take a week or two. It is not
> a universal halt decider, yet it is exactly and precisely the Peter
> Linz H and Ĥ, with H actually deciding input pair: (Ĥ, Ĥ) on the basis
> of Ĥ actually deciding itself."
>

> No x86 code. No programs aborting others. No memory being released.
> No changed questions. Just Turing machines H and H^ exactly as in Linz
> doing something incredible! Don't you just wish you really had those
> two Turing machines so you could post them and stun your critics? What
> a shame you never did.
>

My current claim that I have already provided an unequivocal refutation
ALL of the conventional self-referential halting problem proofs and this
naturally takes precedence over all of your lesser points above.

There is a simple and direct path to a correct rebuttal of my current
claim if and only if I am incorrect.

The conventional definition of the halt decider can be easily thwarted
by making a program based on this halt decider that does the opposite of
whatever the halt decider decides.

(1) Original self-referential halting problem counter example
(a) Decision: ~Halting and Behavior: Halts (a contradiction)
(b) Decision: Halting and Behavior: Loops (a contradiction)

When the halt decider is a UTM that executes its TM one state transition
at a time and ceases executing this TM as soon as it detects non-halting
behavior, and then reports that it aborted the execution of this TM it
is reporting non-halting behavior that cannot be contradicted.

If you can show how its TM can be defined such that its input does the
opposite of whatever the halt decider UTM decides then you would have
refuted this new position.

On the other hand if it is impossible to derive any examples that this
redefined halt decider cannot decide, this would prove that I am correct.

[olcott]

On 10/22/2020 10:41 PM, Richard Damon wrote:

> On 10/22/20 4:24 PM, olcott wrote:
>>
>> The more general claim that I made is that I would show exactly how the
>> conventional self-referential halting problem proof counter-examples do
>> not prove that the halting problem is undecidable.
>>
>> This has now been totally fulfilled.
>>
>> As soon as you acknowledge this we can move on to talking about other
>> aspects.
>

> You ave done NO such thing. You have shown that a DIFFERENT,
> non-equivalent sort of halting problem statement can't be disproven by a
> Linz like system.
>
> Unfortunately, the original halting problem (that you haven't touched,
> and even seems to be that you admit the proof is actually valid for) has
> some mathematical interesting uses, while your revised statement has
> know known use, and without some major tightening of the conditions in
> it, is almost assuredly not to be mathematically interesting.
>

When I said that the original proof is correct yet was based on a
fundamentally incorrect assumption it is exactly the same thing
as the statement that "cats bark" is correct when we assume that all
cats are dogs.

Perhaps it is easier to understand it when I say that the original proof
is fundamentally incorrect because it is based on fundmentally incorrect
assumptions.

> A big part of this lack of interest is that detecting halting by
> simulating adds no information about the halting behavior above simply
> running the orginal machine and observing if it has halted.
>

This statement is incorrect. A halt decider can easily detect infinite
loops when the program under test is executed in debug step mode.

[olcott]

On 10/22/2020 11:10 PM, Richard Damon wrote:

> On 10/22/20 9:15 PM, olcott wrote:
>>
>> The halting problem has never been about an unknown function.
>> A halt decider is not required to be psychic.
>

> The USEFULNESS of a halting detector, is for cases where you have an
> problem, with an algorithm, which can be expressed as a Turing Machine,
> whose calculation is not know whether it will eventally terminate, and
> thus provide a proof of existence for something, or loop forever, and
> prove the non-existence of that thing. If we could make this halt
> decider, we could by running the halt decider on the algorithm instead
> of just trying to run the algorithm, and thus get the answer of a proof
> the existence or non-existence of that result.
>

I can't make out what you are saying.
The halting problem proofs are based on making an input that the halt
decider cannot possibly decide.

The input program is created from the halt decider and made to do the
opposite of whatever ht halt decider decides. This fools the halt decider.

If the halt decider decides its input will halt the input program loops.
If the halt decider decides its input will loop the input program halts.

When the halt decider executes its input in debug trace mode
(or a UTM executes its TM one state transition at a time).
then as soon as it detects non-halting behavior its stops executing its
input and reports non-halting behavior.

The input program cannot do the opposite of whatever the halt decider
decides because the input program cannot do anything at all because it
is no longer executing.

There is no longer any input that can fool this halt decider therefore
the halting problem proofs have been refuted.

> The inability to do this, thus becomes related to the incompleteness
> theory, where it seems that, at least for sufficient expressive system,
> that there are some properties that we can not proof whether they are
> true or not.

[olcott]

> You don't have what you claimed to have. That's why you will never post
> it.

>
>> There is a simple and direct path to a correct rebuttal of my current
>> claim if and only if I am incorrect.
>

> Yes there is. Here are H and H_Hat with some of the noise removed:
>
> void H(u32 M, u32 N)
> {
> if (DebugTrace(M, N))
> MOV_EAX_0 // M(N) would not otherwise terminate
> else
> MOV_EAX_1 // M(N) has terminated
> HALT
> }
>
> void H_Hat(u32 M)
> {
> if (!DebugTrace(M, M))
> HERE: goto HERE;
> HALT
> }
>
> Neither function returns a result they should be "void". The EAX
> settings in H_Hat are a distraction since H_Hat is not supposed to report
> anything at all. All that matters is whether is halts or not.
>
> Now, since you refuse to say what DebugTrace(H_Hat, H_Hat) returns (I
> don't think you know yet), we need to consider both cases:
>
> When DebugTrace(H_Hat, H_Hat) == 1 the two computations execute like this:
>
> H(H_Hat, H_Hat):
> MOV_EAX_0 // H_Hat(H_Hat) would not otherwise terminate
> HALT
>
> H_Hat(H_Hat):
> HALT
>
> and when DebugTrace(H_Hat, H_Hat) == 0 they execute
>
> H(H_Hat, H_Hat):
> MOV_EAX_1 // H_Hat(H_Hat) has terminated
> HALT
>
> H_Hat(H_Hat):
> HERE: goto HERE;
>
> Sure looks like H gets the wrong answer to me.
>


The input program is created from the halt decider and made to do the
opposite of whatever the halt decider decides. This fools the halt decider.

If the halt decider decides its input will halt the input program loops.
If the halt decider decides its input will loop the input program halts.

When the halt decider executes its input in debug trace mode
(or a UTM executes its TM one state transition at a time).
then as soon as it detects non-halting behavior its stops executing its
input and reports non-halting behavior.

The input program cannot do the opposite of whatever the halt decider
decides because the input program cannot do anything at all because it
is no longer executing.

There is no longer any input that can fool this halt decider therefore
the halting problem proofs have been refuted.

[olcott]

> You don't have what you claimed to have. That's why you will never post
> it.
>

>> There is a simple and direct path to a correct rebuttal of my current
>> claim if and only if I am incorrect.
>

> Yes there is. Here are H and H_Hat with some of the noise removed:
>
> void H(u32 M, u32 N)
> {
> if (DebugTrace(M, N))
> MOV_EAX_0 // M(N) would not otherwise terminate
> else
> MOV_EAX_1 // M(N) has terminated
> HALT
> }
>

Since I strive for complete honestly I do have to say this this is a
clear improvement.

> void H_Hat(u32 M)
> {
> if (!DebugTrace(M, M))
> HERE: goto HERE;
> HALT
> }
>

In this one we are losing the transition to (qy) or ((qn)) detail, yet
this is an inessential detail and since we are aiming to generalize
beyond Linz it is also an improvement. In both cases you removed
clumsiness, so good job.

> Neither function returns a result they should be "void".

Yes I initially tried for a return value but stack unwinding caused an
incorrect return value, so right again.

> The EAX
> settings in H_Hat are a distraction since H_Hat is not supposed to report
> anything at all. All that matters is whether is halts or not.
>

Yes good call.

> Now, since you refuse to say what DebugTrace(H_Hat, H_Hat) returns (I
> don't think you know yet), we need to consider both cases:
>

I have known for 3.5 years. We discussed this at great length yet you
were so sure that I must be wrong that you paid no attention at all.

> When DebugTrace(H_Hat, H_Hat) == 1 the two computations execute like this:
>
> H(H_Hat, H_Hat):
> MOV_EAX_0 // H_Hat(H_Hat) would not otherwise terminate
> HALT
>
> H_Hat(H_Hat):
> HALT
>
> and when DebugTrace(H_Hat, H_Hat) == 0 they execute
>
> H(H_Hat, H_Hat):
> MOV_EAX_1 // H_Hat(H_Hat) has terminated
> HALT
>
> H_Hat(H_Hat):
> HERE: goto HERE;
>
> Sure looks like H gets the wrong answer to me.

You actually did quite well in analyzing the above except for one very
glaring exception. One of the two return values from DebugTrace() is

[Tim Woodall]

On 2020-10-23, olcott <No...@NoWhere.com> wrote:

>
> This statement is incorrect. A halt decider can easily detect infinite
> loops when the program under test is executed in debug step mode.
>

Does the below function g() terminate?

N.B. this code is meant to be simple, not efficient.

int p(int n)
{
int p = 0;
int d;

if(n<=2)
return 0;

n--; //n is never increased therefore this function always returns a value less than its input
d = n;

while(d>2) //This loop always terminates as d or n decreases with each iteration and d<=n
{
d--;

p = n;

while(p >= d) //This loop always terminates as p decreases with each iteration
p -= d;

if(!p)
{
n--;
d = n;
}
}

return n;
}

void g()
{
int n = 6;

int p1 = n;

while( p(p1) + p(p1) >=n ) //Does this loop terminate?
{
p1 = p(p1); //p1 is always less than n

int p2 = p1;
while(p1 + p2 > n) //p2 monotonically decreases to zero and p1<n therefore this loop always terminates
p2 = p(p2);

if(p1+p2 == n)
{
n = n + 2;
p1 = n;
}

}
}

Does g terminate? (assuming ints never overflow)

[André G. Isaak]

The halting asks whether one can create a TM which will determine
whether an *arbitrary* TM will halt. I'm pretty sure that is meant above
by 'unknown function'.

> A halt decider is not required to be psychic.

No, but it has to provide the correct answer for any arbitrary TM.

>>
>>
>>> All that I have shown is that deciding the halting problem is no
>>> longer impossible.
>>
>> How?
>>
>
> The way that the halting problem works is another program that is
> exactly like that halt decider is slightly changed so that it does the
> opposite of whatever the halt decider decides.
>
> If the halt decide decides that it will halt it loops.

While Linz's proof uses a simple loop in his Ĥ, what is important to the
proof is that it enters a series of states which never halts, not that
looping is involved.

We can easily construct variants of Linz proof in which, in cases where
H determines that a TM will halt, Ĥ enters into some arbitrary
non-halting computation, like printing all digits of pi, or the sequence
of all primes, or the entire fibonacci series, or any other non-halting
computation, rather than entering into a simple loop.

All of these proofs would be just as valid as Linz's, and your
DebugTrace() strategy wouldn't be able to deal with these.

[olcott]

All that I have done is refuted the conventional self-referential
halting problem proofs that show that a universal halt decider is
impossible. I don't handle any difficult cases. I only handle the
impossible cases.

[olcott]

On 10/23/2020 4:29 AM, Malcolm McLean wrote:

> On Friday, 23 October 2020 at 04:41:59 UTC+1, Richard Damon wrote:
>>
>> A big part of this lack of interest is that detecting halting by
>> simulating adds no information about the halting behavior above simply
>> running the orginal machine and observing if it has halted.
>>

> Exactly. What happens if we have a physical Turing machine?
>
> It's set up by a human supervisor, who waits to see if it halts. One
> possibility is that it will run out of tape, in which case he, probably rightly,
> concludes that it has got stuck in an infinite loop. Another possibility
> is that it takes a long time and he gets bored. Another possibility is that
> it halts normally.
>
> Assuming it doesn't halt normally, the machine is destroyed or switched
> off in some manner. It never runs forever.
>
> So in fact we have a pretty good, though not perfect, halt detector. But
> it's not a Turing machine. A Turing machine can't abort.

A UTM can run its TM until it decides that its TM is would not halt.
Then the UTM stops running its TM and reports non-halting behavior.
The TM cannot then do the opposite of whatever the UTM decided because
it is no longer running. Bingo halting is decidable !

> PO is trying to
> get round this problem by saying that DebugTrace aborts the program
> this stepping through (which is possible), then shunts up the "abortion"
> state to H_Hat, which then aborts. That's not valid, of course. H_Hat can't
> abort itself or it's not a Turing machine.
>
> Remove the requirement that the halt detector be a Turing machine and
> the Linz proof fails. That's the basic point that seems to have been missed,
> and that's what PO is doing, though not so blatantly that most people
> have spotted the error.

[olcott]

On 10/23/2020 5:02 AM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>

>> A halt decider can easily detect infinite loops when the program under
>> test is executed in debug step mode.
>

> For the simple (and common) definition of "infinite loops" that's right.
> A program loops (in this simple sense) when it enters a configuration it
> has previously been in (the configuration being the sum total of all the
> state that can affect the outcome). But a halt decider must be able to
> decide computations that don't terminate, but which don't "loop" in this
> naive sense.
>
> The word is also used as a slightly clumsy synonym for non-terminating,
> so if you want to be clear (ha!) you should avoid the word or specify
> the meaning when you use it as one form of "looping" is easily
> detectable but the other is impossible to detect.
>

What form of looping is literally impossible to detect?

[olcott]

On 10/23/2020 5:47 AM, Malcolm McLean wrote:

> On Friday, 23 October 2020 at 06:12:37 UTC+1, olcott wrote:
>> On 10/22/2020 11:00 PM, Ben Bacarisse wrote:
>>
>>> The EAX
>>> settings in H_Hat are a distraction since H_Hat is not supposed to report
>>> anything at all. All that matters is whether is halts or not.
>>>
>> Yes good call.
>>

> No, that's essential to your system. H_Hat aborts, which it achieves by
> writing 0 to eax. That's your "abort path",or "exception return" or whatever
> you want to call it.

No. When DebugTrace() returns 1 it has indicated that the input program
has already been terminated.

> If H_Hat doesn't abort, then DebugTrace has to abort it.

Abort always means terminated by the operating system.

> Or Linz is right
> all along and behaviour is inconsistent. Either DebugTrace isn't a Turing
> machine or H_Hat isn't a Turing machine, and you've got round Linz.
> Linz's proof only applies to Turing machines, and Turing machines can't
> abort.
>

The exact same thing applies to UTMs executing UTMs. My whole system
models UTMs executing UTMs as much as can possibly be done when we want
to keep the algorithms at the high level of abstraction of C.

[olcott]

It always has complete access to the source code so that it can do
anything that it wants including execute this code.

>
>>>
>>>
>>>> All that I have shown is that deciding the halting problem is no
>>>> longer impossible.
>>>
>>> How?
>>>
>>
>> The way that the halting problem works is another program that is
>> exactly like that halt decider is slightly changed so that it does the
>> opposite of whatever the halt decider decides.
>>
>> If the halt decide decides that it will halt it loops.
>
> While Linz's proof uses a simple loop in his Ĥ, what is important to the
> proof is that it enters a series of states which never halts, not that
> looping is involved.
>
> We can easily construct variants of Linz proof in which, in cases where
> H determines that a TM will halt, Ĥ enters into some arbitrary
> non-halting computation, like printing all digits of pi, or the sequence
> of all primes, or the entire fibonacci series, or any other non-halting
> computation, rather than entering into a simple loop.
>

You are assuming the detecting these cases is impossible.
You are assuming that the smartest program in the world would not be
able to recognize that another program is calculating the digits of PI.

Alternatively I have refuted the conventional self-referential halting
problem proof counter-examples that show that a universal halt dedcider
is impossible. If there are no other unconventional halting problem
proof counter-examples then creating a universal halt decider is no
longer shown to be impossble.

> All of these proofs would be just as valid as Linz's, and your
> DebugTrace() strategy wouldn't be able to deal with these.
>
> André
>

No, not at all, not in the least bit.
Providing cases where deciding halting is difficult is not at all the
same thing as providing cases where deciding halting is impossible.

Even if there are cases where deciding halting is impossible I have
still refuted all of the conventional self-referential cases.

[André G. Isaak]

It can't simply execute the code. If it just executes the code, then the
halt decider isn't going to halt when given code that doesn't halt. It
has to somehow determine what the code would do if executed.

>>
>>>>
>>>>
>>>>> All that I have shown is that deciding the halting problem is no
>>>>> longer impossible.
>>>>
>>>> How?
>>>>
>>>
>>> The way that the halting problem works is another program that is
>>> exactly like that halt decider is slightly changed so that it does
>>> the opposite of whatever the halt decider decides.
>>>
>>> If the halt decide decides that it will halt it loops.
>>
>> While Linz's proof uses a simple loop in his Ĥ, what is important to
>> the proof is that it enters a series of states which never halts, not
>> that looping is involved.
>>
>> We can easily construct variants of Linz proof in which, in cases
>> where H determines that a TM will halt, Ĥ enters into some arbitrary
>> non-halting computation, like printing all digits of pi, or the
>> sequence of all primes, or the entire fibonacci series, or any other
>> non-halting computation, rather than entering into a simple loop.
>>
>
> You are assuming the detecting these cases is impossible.
> You are assuming that the smartest program in the world would not be
> able to recognize that another program is calculating the digits of PI.

Computer programs aren't smart. They have no intelligence whatsoever.

Recognizing that some other program calculates the digits of pi is
different from determining that whatever an arbitrary function is doing
will not halt.

> Alternatively I have refuted the conventional self-referential halting
> problem proof counter-examples that show that a universal halt dedcider
> is impossible. If there are no other unconventional halting problem
> proof counter-examples then creating a universal halt decider is no
> longer shown to be impossble.

But the contradiction which Linz's proof makes is still present in yours.

Let's assume that H returns 'forced to abort' when applied to Ĥ(Ĥ).

That would mean that Ĥ(Ĥ) is stuck in a loop which your H is able to
identify.

But Ĥ(Ĥ) enters an infinite loop when the underlying decision code
determines that Ĥ was *not* forced to abort.

So what you claim is the exact same decision code is giving opposite
answers when executed inside H than it is when executed inside Ĥ. So
either it is giving the wrong answer in H or it is giving the wrong
answer in Ĥ.

This is the same contradiction present in the Linz proof.

[olcott]

The UTM executes the code of its input UTM one state transition at a
time until it detects that its input UTM would not halt or until its
input UTM terminates on its own. As soon as the UTM detects that its
input UTM would not otherwise halt it stops executing its input UTM and
reports non-halting behavior.

>
>>>
>>>>>
>>>>>
>>>>>> All that I have shown is that deciding the halting problem is no
>>>>>> longer impossible.
>>>>>
>>>>> How?
>>>>>
>>>>
>>>> The way that the halting problem works is another program that is
>>>> exactly like that halt decider is slightly changed so that it does
>>>> the opposite of whatever the halt decider decides.
>>>>
>>>> If the halt decide decides that it will halt it loops.
>>>
>>> While Linz's proof uses a simple loop in his Ĥ, what is important to
>>> the proof is that it enters a series of states which never halts, not
>>> that looping is involved.
>>>
>>> We can easily construct variants of Linz proof in which, in cases
>>> where H determines that a TM will halt, Ĥ enters into some arbitrary
>>> non-halting computation, like printing all digits of pi, or the
>>> sequence of all primes, or the entire fibonacci series, or any other
>>> non-halting computation, rather than entering into a simple loop.
>>>
>>
>> You are assuming the detecting these cases is impossible.
>> You are assuming that the smartest program in the world would not be
>> able to recognize that another program is calculating the digits of PI.
>
> Computer programs aren't smart. They have no intelligence whatsoever.
>

Deep Blue was a chess-playing computer developed by IBM. It was the
first computer to win both a chess game and a chess match against a
reigning world champion under regular time controls.
https://en.wikipedia.org/wiki/Deep_Blue_(chess_computer)

> Recognizing that some other program calculates the digits of pi is
> different from determining that whatever an arbitrary function is doing
> will not halt.
>

Yes the latter requires much less knowledge.

>> Alternatively I have refuted the conventional self-referential halting
>> problem proof counter-examples that show that a universal halt
>> dedcider is impossible. If there are no other unconventional halting
>> problem proof counter-examples then creating a universal halt decider
>> is no longer shown to be impossble.
>
> But the contradiction which Linz's proof makes is still present in yours.
>

No it is not and you can continue to say that you really really believe
this yet cannot provide an example of this.

> Let's assume that H returns 'forced to abort' when applied to Ĥ(Ĥ).
>
> That would mean that Ĥ(Ĥ) is stuck in a loop which your H is able to
> identify.
>
> But Ĥ(Ĥ) enters an infinite loop when the underlying decision code
> determines that Ĥ was *not* forced to abort.
>

Since my program does not contain the mind of God there will be many
cases that it cannot decide correctly. None of these cases are
impossible to decide.

> So what you claim is the exact same decision code is giving opposite
> answers when executed inside H than it is when executed inside Ĥ. So
> either it is giving the wrong answer in H or it is giving the wrong
> answer in Ĥ.

If we take my redefined halting decider and interpret its return value
using the conventional interpretation:

DebugTrace() executes H_Hat() and decides that it would not otherwise
halt so it terminates the execution of H_Hat() and reports:

(1) Not_Halting.
Decision:Not_Halting
Behavior:Halting
a contradiction DebugTrace() got the wrong answer.

If we take my redefined halting decider and interpret its return value
using the redefined interpretation:

(2) Aborted_Because_Non_Halting_Behavior_Detected
Decision:Aborted_Because_Non_Halting_Behavior_Detected
Behavior:Aborted_Because_Non_Halting_Behavior_Detected
Not a contradiction and the right answer!

>
> This is the same contradiction present in the Linz proof.
>
> André
>


--

Copyright 2020 Pete Olcott

[André G. Isaak]

Deep blue had no intelligence. It used a purely mechanical chess-playing
algorithm.

>> Recognizing that some other program calculates the digits of pi is
>> different from determining that whatever an arbitrary function is
>> doing will not halt.
>>
>
> Yes the latter requires much less knowledge.
>
>>> Alternatively I have refuted the conventional self-referential
>>> halting problem proof counter-examples that show that a universal
>>> halt dedcider is impossible. If there are no other unconventional
>>> halting problem proof counter-examples then creating a universal halt
>>> decider is no longer shown to be impossble.
>>
>> But the contradiction which Linz's proof makes is still present in yours.
>>
>
> No it is not and you can continue to say that you really really believe
> this yet cannot provide an example of this.
>
>> Let's assume that H returns 'forced to abort' when applied to Ĥ(Ĥ).
>>
>> That would mean that Ĥ(Ĥ) is stuck in a loop which your H is able to
>> identify.
>>
>> But Ĥ(Ĥ) enters an infinite loop when the underlying decision code
>> determines that Ĥ was *not* forced to abort.
>>
>
> Since my program does not contain the mind of God there will be many
> cases that it cannot decide correctly. None of these cases are
> impossible to decide.

But here I am talking about the sole case that you claim to actually
have solved!

>> So what you claim is the exact same decision code is giving opposite
>> answers when executed inside H than it is when executed inside Ĥ. So
>> either it is giving the wrong answer in H or it is giving the wrong
>> answer in Ĥ.
>
> If we take my redefined halting decider and interpret its return value
> using the conventional interpretation:
>
> DebugTrace() executes H_Hat() and decides that it would not otherwise
> halt so it terminates the execution of H_Hat() and reports:

You keep talking about DebugTrace() without making it clear which
instance you are talking about; the one inside H or the one inside Ĥ.
Similarly, when you talk about 'behaviour' it isn't clear whether you
are talking about H or Ĥ.

> (1) Not_Halting.
>     Decision:Not_Halting
>     Behavior:Halting
>     a contradiction DebugTrace() got the wrong answer.
>
> If we take my redefined halting decider and interpret its return value
> using the redefined interpretation:
>
> (2) Aborted_Because_Non_Halting_Behavior_Detected
>     Decision:Aborted_Because_Non_Halting_Behavior_Detected
>     Behavior:Aborted_Because_Non_Halting_Behavior_Detected
>     Not a contradiction and the right answer!

[olcott]

On 10/23/2020 9:34 AM, Malcolm McLean wrote:

> On Friday, 23 October 2020 at 14:57:29 UTC+1, olcott wrote:
>> On 10/23/2020 5:47 AM, Malcolm McLean wrote:
>>> On Friday, 23 October 2020 at 06:12:37 UTC+1, olcott wrote:
>>>> On 10/22/2020 11:00 PM, Ben Bacarisse wrote:
>>>>
>>>>> The EAX
>>>>> settings in H_Hat are a distraction since H_Hat is not supposed to report
>>>>> anything at all. All that matters is whether is halts or not.
>>>>>
>>>> Yes good call.
>>>>
>>> No, that's essential to your system. H_Hat aborts, which it achieves by
>>> writing 0 to eax. That's your "abort path",or "exception return" or whatever
>>> you want to call it.
>> No. When DebugTrace() returns 1 it has indicated that the input program
>> has already been terminated.
>>

> You've got two choices. Either DebugTrace aborts its enclosing instance of
> H_Hat, of H_Hat detects that DebugTrace has aborted the instance of H_Hat
> it is stepping through, and aborts itself. Either way, H_Hat(H_Hat) aborts,
> and the behaviour is consistent.

DebugTrace() creates new process contexts and everything that it slave
process executes (including subsequent invocations of DebugTrace()) is
executed in this same process context.

Once DebugTrace() aborts the execution of its slave this slave cannot do
anything at all. The slave it always under the total and complete
control of DebugTrace().

The outermost DebugTrace() totally controls its slave and whatever code
that its slave may have invoked such as another instance of
DebugTrace(). Once the outermost DebugTrace() aborts its slave process
the whole hieararchy is aborted.

>>
>>> If H_Hat doesn't abort, then DebugTrace has to abort it.
>> Abort always means terminated by the operating system.
>>

> What do you mean here? I thought DebugTrace detected the "no halt" condition
> and raised the abortion.

>>
>> The exact same thing applies to UTMs executing UTMs. My whole system
>> models UTMs executing UTMs as much as can possibly be done when we want
>> to keep the algorithms at the high level of abstraction of C.
>>

> Linz's proof shows that H cannot be a Turing machine. What you've shown is that
> it doesn't apply if we make a small change to the specifications so that the
> machines are allowed to abort.

When you break the concept of a UTM and create an artificial limit you
changed the subject.

> A Turing machine can step through another machine
> and then abort it if certain conditions are met. But it can't abort itself. That makes
> all the difference.

Not really, not at all, not in the least little bit. In fact when
H_Hat() is executed with itself as input it does abort this input.

[olcott]

On 10/23/2020 9:51 AM, Ben Bacarisse wrote:

> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
>> So in fact we have a pretty good, though not perfect, halt detector. But
>> it's not a Turing machine. A Turing machine can't abort.
>

> That's a red herring. An abort is not magic. It's just another way of
> halting which we give an special name to. A TM can abort by halting in
> state we interpret as aborting.

>
>> PO is trying to
>> get round this problem by saying that DebugTrace aborts the program
>> this stepping through (which is possible), then shunts up the "abortion"
>> state to H_Hat, which then aborts. That's not valid, of course. H_Hat can't
>> abort itself or it's not a Turing machine.
>

> H_Hat is not a Turing machine because it is x86 code. Aborting has
> nothing to do with that.

>
>> Remove the requirement that the halt detector be a Turing machine and
>> the Linz proof fails. That's the basic point that seems to have been missed,
>> and that's what PO is doing, though not so blatantly that most people
>> have spotted the error.
>

> Of course Linz's proof fails. It fails for Turing machines if they are
> defined even slightly differently from the way Linz defines them!
> That's how proofs work. Why should anyone point that out?
>
> He's not simply relying on a poof literally not applying to some other
> model of computation. He's trying to invalidate the method behind the
> proof. What he is claiming is that he can make two computations,
> related in the same as the two in Linz's proof (and in other similar
> proofs), that do not fall foul of the obvious logic. He has not done
> that. It can't be done. It can't be done even in models where halting
> is decidable.

>

If we take my redefined halting decider and interpret its return value
using the conventional interpretation:

DebugTrace() executes H_Hat() and decides that it would not otherwise
halt so it terminates the execution of H_Hat() and reports:

(1) Not_Halting.
Decision:Not_Halting
Behavior:Halting
a contradiction DebugTrace() got the wrong answer.

If we take my redefined halting decider and interpret its return value
using the redefined interpretation:

(2) Aborted_Because_Non_Halting_Behavior_Detected
Decision:Aborted_Because_Non_Halting_Behavior_Detected
Behavior:Aborted_Because_Non_Halting_Behavior_Detected
Not a contradiction and the right answer!

Instead of the C function DebugTrace() we could simply have a UTM that
executes an (already on the tape) input UTM. This halt decider UTM would
execute its (already on the tape) input UTM one state transition at a
time. As soon as the halt decider UTM detects that its (already on the
tape) input UTM would not halt, the halt decider UTM stops executing its
(already on the tape) input UTM and transitions to its own final state
indicating Aborted_Because_Non_Halting_Behavior_Detected.

[olcott]

> The sort where the computation never enters a configuration it has been
> in before. /Some/ instances of this type can be detected, but there is
> no effective procedure to detect them all. There /is/ an effective
> procedure for the other kind where a previously entered configuration is
> entered again.
>

None-the-less I have refuted all of the conventional self-referential
halting problem proof counter-examples.

Also it is well known that machines such as this cannot physically exist.

[olcott]

On 10/23/2020 10:03 AM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>

>> Your answer does not have a correct yes or no answer.
> s/answer/question/
>> I have run DebugTrace() and it did correctly return a value is a
>> correct but misleading answer.
>>
>>> So what is the returned result from DebugTrace(H_Hat, H_Hat)?
>>
>> It is the fixed value of 1 that I used to test if it could correctly
>> return a value.
>
> I don't think you are taking this seriously. It's up to if you want to
> come across as a clown. If not, you can take the questions people ask
> seriously.
>

DebugTrace() is totally complete as a function that creates new process
contexts and executes virtual machines within this new process context.
The most difficult part was to get DebugTrace() to DebugTrace() itself
to an arbitrary recursive depth.

I had to do this because H() invokes DebugTrace() to invoke H_Hat() to
invoke DebugTrace() to invoke another H_Hat() process.

As I have said dozens of times now the halt decider code has not been
written. The x86utm operating system is complete. This took one
man-year. The halt deciding criteria for the Linz proof has been
complete since 2016. We spoke about this at very great length and you
made sure not to pay any attention at all.

[olcott]

You must be defining intelligence in some weird way.
I define intelligence as the ability to do what a human mind can do.

>>> Recognizing that some other program calculates the digits of pi is
>>> different from determining that whatever an arbitrary function is
>>> doing will not halt.
>>>
>>
>> Yes the latter requires much less knowledge.
>>
>>>> Alternatively I have refuted the conventional self-referential
>>>> halting problem proof counter-examples that show that a universal
>>>> halt dedcider is impossible. If there are no other unconventional
>>>> halting problem proof counter-examples then creating a universal
>>>> halt decider is no longer shown to be impossble.
>>>
>>> But the contradiction which Linz's proof makes is still present in
>>> yours.
>>>
>>
>> No it is not and you can continue to say that you really really
>> believe this yet cannot provide an example of this.
>>
>>> Let's assume that H returns 'forced to abort' when applied to Ĥ(Ĥ).
>>>
>>> That would mean that Ĥ(Ĥ) is stuck in a loop which your H is able to
>>> identify.
>>>
>>> But Ĥ(Ĥ) enters an infinite loop when the underlying decision code
>>> determines that Ĥ was *not* forced to abort.
>>>
>>
>> Since my program does not contain the mind of God there will be many
>> cases that it cannot decide correctly. None of these cases are
>> impossible to decide.
>
> But here I am talking about the sole case that you claim to actually
> have solved!
>

I already know whether or not H_Hat() would need to have its process
aborted and why since 2016. Once H_Hat() has its process aborted it
cannot do anything at all, thus it cannot do the opposite of whatever
the halt decider decides.

>>> So what you claim is the exact same decision code is giving opposite
>>> answers when executed inside H than it is when executed inside Ĥ. So
>>> either it is giving the wrong answer in H or it is giving the wrong
>>> answer in Ĥ.
>>
>> If we take my redefined halting decider and interpret its return value
>> using the conventional interpretation:
>>
>> DebugTrace() executes H_Hat() and decides that it would not otherwise
>> halt so it terminates the execution of H_Hat() and reports:
>
> You keep talking about DebugTrace() without making it clear which
> instance you are talking about; the one inside H or the one inside Ĥ.
> Similarly, when you talk about 'behaviour' it isn't clear whether you
> are talking about H or Ĥ.
>

The outside instance of DebugTrace() invoked from H() totally controls
its process and all of the sub processes invoked by its process. As soon
as it aborts its process the whole process hierarchy stops running.

>> (1) Not_Halting.
>>      Decision:Not_Halting
>>      Behavior:Halting
>>      a contradiction DebugTrace() got the wrong answer.
>>
>> If we take my redefined halting decider and interpret its return value
>> using the redefined interpretation:
>>
>> (2) Aborted_Because_Non_Halting_Behavior_Detected
>>      Decision:Aborted_Because_Non_Halting_Behavior_Detected
>>      Behavior:Aborted_Because_Non_Halting_Behavior_Detected
>>      Not a contradiction and the right answer!
>
> André
>
>


--

Copyright 2020 Pete Olcott

[André G. Isaak]

On 2020-10-23 09:49, olcott wrote:
> On 10/23/2020 10:04 AM, André G. Isaak wrote:

<snip>

>> Deep blue had no intelligence. It used a purely mechanical
>> chess-playing algorithm.
>>
>
> You must be defining intelligence in some weird way.
> I define intelligence as the ability to do what a human mind can do.

Deep Blue can play chess. Some human minds play chess, but they also do
all sorts of other things that Deep Blue can't do, and the way in which
humans approach chess is entirely different from how Deep Blue
accomplishes this.

<snip

>> You keep talking about DebugTrace() without making it clear which
>> instance you are talking about; the one inside H or the one inside Ĥ.
>> Similarly, when you talk about 'behaviour' it isn't clear whether you
>> are talking about H or Ĥ.
>>
>
> The outside instance of DebugTrace() invoked from H() totally controls
> its process and all of the sub processes invoked by its process. As soon
> as it aborts its process the whole process hierarchy stops running.

That doesn't clarify anything.

Why don't you indicate which result the instance of DebugTrace() running
inside Ĥ returns, along with the result which the instance running
inside H returns.

André

>>> (1) Not_Halting.
>>>      Decision:Not_Halting
>>>      Behavior:Halting
>>>      a contradiction DebugTrace() got the wrong answer.
>>>
>>> If we take my redefined halting decider and interpret its return
>>> value using the redefined interpretation:
>>>
>>> (2) Aborted_Because_Non_Halting_Behavior_Detected
>>>      Decision:Aborted_Because_Non_Halting_Behavior_Detected
>>>      Behavior:Aborted_Because_Non_Halting_Behavior_Detected
>>>      Not a contradiction and the right answer!

[Mr Flibble]

But, troll, you still haven't shown how you can determine that for a given arbitrary input UTM your solution can "detect" that the input UTM will not halt; you repeatedly assert, without evidence, that you can do this. I see elsewhere in your reply that you have introduced the concept of "God" into your so called refutation: the great atheist Christopher Hitchens once said that assertions made without evidence can dismissed without evidence.

/Flibble

--
¬

[olcott]

On 10/23/2020 11:18 AM, Mike Terry wrote:
> On 23/10/2020 05:13, olcott wrote:

>> On 10/22/2020 10:44 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 10/22/2020 9:09 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>

>>>>>> On 10/22/2020 6:34 PM, Ben Bacarisse wrote:
>>> <cut>
>>>>>>> Further questions: is DebugTrace vapourware or do you have it
>>>>>>> written
>>>>>>> and running?
>>>>>>
>>>>>> The reason for the great delay is that I waited until I got
>>>>>> DebugTrace() fully operational before I presented H() and H_Hat().
>>>>>>
>>>>>>>    It you have it running, can you run DebugTrace(H_Hat,
>>>>>>> H_Hat) to get a return value?  If not why not?  If you can, what
>>>>>>> is the
>>>>>>> return value?
>>>>>>
>>>>>> It took me a man-year to write my x86utm operating system. Now I
>>>>>> finally have the full basis to write the most robust halt deciding
>>>>>> code.
>>>>>
>>>>> Can you run DebugTrace(H_Hat, H_Hat) to get a return value?
>>>>
>>>> I have already answered this question completely.
>>>
>>> That's pure crank 101.  People who want to be understood are happy to
>>> repeat an answer: "sorry, did you miss it?  I said yes".  You see?
>>> Clear and unambiguous.  Cranks don't do that because they want as many
>>> get-out clauses left open as they can.
>>>
>>
>> It is bad for me to have patience with people to to pay so little
>> attention to what I am saying that after I have answered their question
>> five times they did not bother to notice the answer even a single time.

>>
>> Your answer does not have a correct yes or no answer.

>> I have run DebugTrace() and it did correctly return a value is a correct
>> but misleading answer.
>>
>

> LOL, I think I can see what's happened now!  :)
>
> Two years ago you genuinely thought you had a /design/ for a TM that
> would actually contradict the Linz logic, and so you announced that you
> had two fully coded TMs that worked, when in fact you just had an idea.
> [You clearly thought at the time it would only be a couple of weeks of
> coding to implement your idea, so what harm in lying about actually
> having the TMs?  That's not a lie, because you would have them soon and
> nobody would know otherwise.  And the lie sounds "more convincing" than
> the truth that it was just an idea you had, so you went for it...]
>
> Since then you've been playing catchup, realising you couldn't code a
> TM, and then even coding in a C environment would be months/years of work.
>
> Now (in the last week or so) for the first time, you've actually been
> able to try out your idea, and I provided you with an H_Hat skeleton
> which forced you to follow the Linz proof restrictions -


> and you FINALLY
> realised your idea didn't work, and WHY it didn't!

Not at all. Not in the least little bit.
You aren't paying very close attention are you?

> The decision of
> H_copy [the copy of H embedded in H_Hat] on running H_Hat with input
> <H_Hat> is made BEFORE H_Hat actually finishes running, so H_Hat's
> actual behaviour can be different, showing H's decision to be incorrect.
>

As in all of the conventional proofs the input program is based on
modifications made to the halt decider.

Next, we modify H to produce a Turing machine H' with the structure
shown in Figure 12.2.

http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf

// Simpifications of H() and H_Hat() provided by
// Ben Bacarisse wrote On 10/22/2020 11:00 PM


// M has address of H_Hat()
void H_Hat(u32 M)
{
if (!DebugTrace(M, M)) // M(M) Aborted?
HERE: goto HERE;
HALT
}


// M and N have the address of H_Hat()

void H(u32 M, u32 N)
{

if (DebugTrace(M, N)) // M(N) Aborted?
MOV_EAX_0 // Execution of M(N) has been aborted
else
MOV_EAX_1 // M(N) has halted
HALT
}


int main()
{
u32 M = (u32)H_Hat;
H(M, M);
HALT;
}

> FINALLY I think you (at least partially) understand the proof, which
> everybody else understood all along, and you are stuffed.  Rather than
> admit you'd just been a dumbo for 15 years, you did what you always do:
> just carry on regardless, changing whatever needs to be changed about
> your original claim and the meaning of the terms in the proof you're
> "refuting" to try to make your revised claim still true!  [I'd have to
> say that you are one of the most inflexible thinkers I've come across on
> UseNet when it comes to recognising mistakes/dead ends and switching to
> better approaches - totally the opposite behaviour exhibited by "true
> geniuses"...]
>
> Hence all the rubbish in the last week or so about "changing the
> question" to try to make your problem go away.  I think that what you're
> thinking is that you can make the problem of H_Hat finishing AFTER
> H_Copy has returned its decision JUST GO AWAY by

Forcing H_Hat() to terminate before the decision is returned.

This makes it impossible for H_Hat() to do anything at all, thus H_Hat()
cannot possibly do the opposite of whatever DebugTrace() decides.

> saying the decision of
> H_Copy is not "whether H_Hat halts", but in fact should be read as
> "whether or not I decided H_Hat would halt and aborted it".  And since

The unique discovery that I made in 2016 indicates that H_Hat() would
never terminate unless it was aborted.

> your H_Copy aborts it's emulation of H_Hat before the emulation actually
> finishes, we're for some reason not allowed to talk about what H_Hat
> /actually/ does.  (Duh!)
>

No. The DebugTrace() of H_Hat() that is invoked by H() aborts its
execution of H_Hat() because unless H_Hat() is aborted it would never
terminate.

> You can't make the basic problem you've suddenly encountered go away
> like that - Linz's proof worked all along, and you've only just
> understood (at least partially) how it works in the last couple of
> weeks.  And now you can't bring yourself to just admit it, because you
> are an unacknowledged genius who CAN'T be wrong, so you MUST have be
> right all along for some other reason... [now if only you could come up
> with a plausible reason, but you can't!  :) ]
>
> Regards,
> Mike.
>

The reason that I can't admit that I am wrong this that I am correct and
you can't show otherwise.

[olcott]

Others have pointed out that this in not necessary.

> you repeatedly assert, without evidence, that you can do
> this.  I see elsewhere in your reply that you have introduced the
> concept of "God" into your so called refutation: the great atheist
> Christopher Hitchens once said that assertions made without evidence can
> dismissed without evidence.
>
> /Flibble
>

I have already provided complete proof.

If we take my redefined halting decider and interpret its return value
using the conventional interpretation:

DebugTrace() executes H_Hat() and decides that it would not otherwise
halt so it terminates the execution of H_Hat() and reports:

(1) Not_Halting.
Decision:Not_Halting
Behavior:Halting
a contradiction DebugTrace() got the wrong answer.

If we take my redefined halting decider and interpret its return value
using the redefined interpretation:

(2) Aborted_Because_Non_Halting_Behavior_Detected
Decision:Aborted_Because_Non_Halting_Behavior_Detected
Behavior:Aborted_Because_Non_Halting_Behavior_Detected
Not a contradiction and the right answer!

Instead of the C function DebugTrace() we could simply have a UTM that
executes an (already on the tape) input UTM. This halt decider UTM would
execute its (already on the tape) input UTM one state transition at a
time. As soon as the halt decider UTM detects that its (already on the
tape) input UTM would not halt, the halt decider UTM stops executing its
(already on the tape) input UTM and transitions to its own final state
indicating Aborted_Because_Non_Halting_Behavior_Detected.

[olcott]

The DebugTrace() invoked by H() returns
Aborted_Because_Non_Halting_Behavior_Detected so the DebugTrace()
invoked by Ĥ() never reaches the point where it would return a value.

>
>>>> (1) Not_Halting.
>>>>      Decision:Not_Halting
>>>>      Behavior:Halting
>>>>      a contradiction DebugTrace() got the wrong answer.
>>>>
>>>> If we take my redefined halting decider and interpret its return
>>>> value using the redefined interpretation:
>>>>
>>>> (2) Aborted_Because_Non_Halting_Behavior_Detected
>>>>      Decision:Aborted_Because_Non_Halting_Behavior_Detected
>>>>      Behavior:Aborted_Because_Non_Halting_Behavior_Detected
>>>>      Not a contradiction and the right answer!
>
>


--

Copyright 2020 Pete Olcott

[Mr Flibble]

On 23/10/2020 17:43, olcott wrote:
[snip]

> Instead of the C function DebugTrace() we could simply have a UTM that executes an (already on the tape) input UTM. This halt decider UTM would execute its (already on the tape) input UTM one state transition at a time. As soon as the halt decider UTM detects that its (already on the tape) input UTM would not halt, the halt decider UTM stops executing its (already on the tape) input UTM and transitions to its own final state indicating Aborted_Because_Non_Halting_Behavior_Detected.

"As soon as the halt decider UTM detects that its (already on the tape) input UTM would not halt" -- how does it do this? You assert that you can do this: assertions made without evidence can be dismissed without evidence.

Until you show, to us, in this Usenet discussion, how your solution can "detect" the input UTM won't halt then your so called "refutation" is WORTHLESS.

If you reply asserting the same thing, again, then I will reply with the same correct observation, again, until I get bored.

You have nothing, mate.

/Flibble

--
¬