It is known that a correct halt decider must return false (in this case)[V4](Linz)

[olcott]

The following shows exactly how the Peter Linz H would correctly decide
halting on the Peter Linz Ĥ. This is fully operational code that has
been executed in the x86utm operating system that I wrote.

To make the Linz counter-example conform to the standard halting problem
counter-examples the input is not copied as it is in Linz.

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

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

x86 language ≡ von Neumann architecture ≡ UTM ≡ RASP Machine
The x86 language is computationally equivalent to a UTM for all
computations that do not require more memory than is available.

Recursion can be directly simulated by a UTM that simulates its own
Turing machine Description. Infinite recursion would repeat the same
state transitions every time the UTM simulates its own Turing machine
Description.

// Defined at the bottom of page 319 of Linz
void Ĥ(u32 P)
{
u32 Input_Halts = H(P, P);
if (!Input_Halts)
HALT
else
HERE: goto HERE;
}


int main()
{
u32 P = (u32)Ĥ;
H(P, P);
HALT;
}


Disassembled x86 machine language of the above pair of C functions.

Ĥ()
[000004f7](01) 55 push ebp
[000004f8](02) 8bec mov ebp,esp
[000004fa](01) 51 push ecx
[000004fb](03) 8b4508 mov eax,[ebp+08]
[000004fe](01) 50 push eax
[000004ff](03) 8b4d08 mov ecx,[ebp+08]
[00000502](01) 51 push ecx
[00000503](05) e86ffeffff call 00000377
[00000508](03) 83c408 add esp,+08
[0000050b](03) 8945fc mov [ebp-04],eax
[0000050e](04) 837dfc00 cmp dword [ebp-04],+00
[00000512](02) 7403 jz 00000517
[00000514](01) f4 hlt
[00000515](02) eb02 jmp 00000519
[00000517](02) ebfe jmp 00000517
[00000519](02) 8be5 mov esp,ebp
[0000051b](01) 5d pop ebp
[0000051c](01) c3 ret

_main()
[00000527](01) 55 push ebp
[00000528](02) 8bec mov ebp,esp
[0000052a](01) 51 push ecx
[0000052b](07) c745fcf7040000 mov [ebp-04],000004f7
[00000532](03) 8b45fc mov eax,[ebp-04]
[00000535](01) 50 push eax
[00000536](03) 8b4dfc mov ecx,[ebp-04]
[00000539](01) 51 push ecx
[0000053a](05) e838feffff call 00000377
[0000053f](03) 83c408 add esp,+08
[00000542](01) f4 hlt
[00000543](02) 8be5 mov esp,ebp
[00000545](01) 5d pop ebp
[00000546](01) c3 ret



Output_Debug_Trace() [00010abc] size(148) capacity(65536)
[00000527](01) 55 push ebp
[00000528](02) 8bec mov ebp,esp
[0000052a](01) 51 push ecx
[0000052b](07) c745fcf7040000 mov [ebp-04],000004f7
[00000532](03) 8b45fc mov eax,[ebp-04]
[00000535](01) 50 push eax
[00000536](03) 8b4dfc mov ecx,[ebp-04]
[00000539](01) 51 push ecx
[0000053a](05) e838feffff call 00000377
[000004f7](01) 55 push ebp
[000004f8](02) 8bec mov ebp,esp
[000004fa](01) 51 push ecx
[000004fb](03) 8b4508 mov eax,[ebp+08]
[000004fe](01) 50 push eax
[000004ff](03) 8b4d08 mov ecx,[ebp+08]
[00000502](01) 51 push ecx
[00000503](05) e86ffeffff call 00000377
[000004f7](01) 55 push ebp
[000004f8](02) 8bec mov ebp,esp
[000004fa](01) 51 push ecx
[000004fb](03) 8b4508 mov eax,[ebp+08]
[000004fe](01) 50 push eax
[000004ff](03) 8b4d08 mov ecx,[ebp+08]
[00000502](01) 51 push ecx
[00000503](05) e86ffeffff call 00000377
25 instructions

The above is where the halt decider aborts the whole Ĥ(Ĥ) invocation
sequence because the halt decider detects infinite recursion.

In this case infinite recursion is a function call to the same function
from the same machine address without any conditional branch
instructions that would terminate this recursion.


--
Copyright 2020 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

[Richard Damon]

On 11/22/20 8:24 PM, olcott wrote:
> The following shows exactly how the Peter Linz H would correctly decide
> halting on the Peter Linz Ĥ. This is fully operational code that has
> been executed in the x86utm operating system that I wrote.

What Peter Linz H? The paper does NOT present any indication of how H is
supposed to do it job. It shows a simple outline of a start state that
moves in some unspecified manner to one of two output states.

It is only something in YOUR mind that somehow says this must be
something based on a UTM.

>
> To make the Linz counter-example conform to the standard halting problem
> counter-examples the input is not copied as it is in Linz.

Omitting the copy says this can NOT possible be a Turing Machine as in
the definition of Linz. What other 'standard Halting Problem' are you
refering to.

All the verison I know you pass to the Halt Decider, a representation of
the program and a representation of the input, that is Two Things.

The Linz counter example, and the similer ones, you have a program that
is passed a representation of itself. Since the Halting Decider needs
two representations, you need to in some way dupicate the counter
example input to provide these two seperate input.

>
> http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company.
>
> x86 language ≡ von Neumann architecture ≡ UTM ≡ RASP Machine
> The x86 language is computationally equivalent to a UTM for all
> computations that do not require more memory than is available.

Again, a von Neumann machine can't be a UTM since it is not even a
Turing Machine.

There also isn't anything that would be called the x86 'language'. Yes,
the x86 processor is computationally equivalent to a Turing Machine,
within resource limits. We can use a number of languages on an x86
processor. Maybe you mean by x86 language the x86 assembly language, ok,
but you do understand that there really isn't *A* x86 assembly language
that is actually used on anything. It is a short hand for a wide family
of processors and assembly languages.

> Recursion can be directly simulated by a UTM that simulates its own
> Turing machine Description. Infinite recursion would repeat the same
> state transitions every time the UTM simulates its own Turing machine
> Description.

Yes, you can write broken code in many forms.

Yes, your trace shows that YOUR H has a flaw of infinite recursion when
evaluation a machine that has a copy of itself in it.

By the trace, there appears to be no code in H to detect this situation
so it just keep running, and then some magic force not shown anywhere
aborts the computation, so H actually never returned an answer, thus H
has FAILED at its job to be a Halt Decider.

Maybe you have created a system that is a Halter, which will just abort
any program that it determines will never halt. That might have some
use, but isn't the Halt Decider from Linz.

[Ben Bacarisse]

Richard Damon <Ric...@Damon-Family.org> writes:

> Maybe you have created a system that is a Halter, which will just abort
> any program that it determines will never halt. That might have some
> use, but isn't the Halt Decider from Linz.

The irony is that that algorith -- the algorithm that determines if a
computation must be aborted -- is also impossible. He's not written it
yet so we are focusing on the wrapper function that he's call variously
H and Halts, but as I told PO some time ago, that code must end up
"aborting" an infinity to computations that are, in fact, finite.

--
Ben.

[olcott]

On 11/22/2020 9:14 PM, Ben Bacarisse wrote:
> Richard Damon <Ric...@Damon-Family.org> writes:
>
>> Maybe you have created a system that is a Halter, which will just abort
>> any program that it determines will never halt. That might have some
>> use, but isn't the Halt Decider from Linz.
>
> The irony is that that algorith -- the algorithm that determines if a
> computation must be aborted -- is also impossible. He's not written it > yet

IT IS IN THE FIRST POST OF THIS THREAD.
This is my 2018-12-13 solution.

We merely scan the complete execution trace after each instruction is
executed and see if there have been any function calls to the same
function from the same address without any intervening conditional
branch instructions.

Here is what Mike said about correctly deciding H_Hat:

On 11/20/2020 9:30 PM, Mike Terry wrote:
> input (H_Hat,H_Hat) is non-halting, assuming your Halts() is as
> described. This is all baby stuff. [So the correct halting decision
> for the input is non-halting].

[Ben Bacarisse]

olcott <No...@NoWhere.com> writes:

> On 11/22/2020 9:14 PM, Ben Bacarisse wrote:
>> Richard Damon <Ric...@Damon-Family.org> writes:
>>
>>> Maybe you have created a system that is a Halter, which will just abort
>>> any program that it determines will never halt. That might have some
>>> use, but isn't the Halt Decider from Linz.
>>
>> The irony is that that algorith -- the algorithm that determines if a
>> computation must be aborted -- is also impossible. He's not written
>> it yet
>
> IT IS IN THE FIRST POST OF THIS THREAD.

You have not yet written it (so you said) which it why you have not yet
noticed that it won't work. If you have written it, then you need to do
more testing, (or ask an expert to tell you why it won't work).

> This is my 2018-12-13 solution.

(You have no solution.)

> We merely scan the complete execution trace after each instruction is
> executed and see if there have been any function calls to the same
> function from the same address without any intervening conditional
> branch instructions.

Yes, it's true you can be wrong the other way as well -- your test could
simply fail to spot many non-finite computations, so the H (or Halts)
built from it would not always return. But being wrong in another way
to the one I pointed does not make you right.

If you want H/Halts to be a decider it must always return. That means
your decision to abort must not miss any non-halting cases. To do that,
it must also incorrectly abort an infinity of halting cases.

--
Ben.

[olcott]

On 11/22/2020 10:03 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
>> On 11/22/2020 9:14 PM, Ben Bacarisse wrote:
>>> Richard Damon <Ric...@Damon-Family.org> writes:
>>>
>>>> Maybe you have created a system that is a Halter, which will just abort
>>>> any program that it determines will never halt. That might have some
>>>> use, but isn't the Halt Decider from Linz.
>>>
>>> The irony is that that algorith -- the algorithm that determines if a
>>> computation must be aborted -- is also impossible. He's not written
>>> it yet
>>
>> IT IS IN THE FIRST POST OF THIS THREAD.
>
> You have not yet written it (so you said) which it why you have not yet
> noticed that it won't work. If you have written it, then you need to do
> more testing, (or ask an expert to tell you why it won't work).
>

Here is what Mike said about my way of correctly deciding H_Hat:
Here is what Mike said about my way of correctly deciding H_Hat:
Here is what Mike said about my way of correctly deciding H_Hat:
Here is what Mike said about my way of correctly deciding H_Hat:
Here is what Mike said about my way of correctly deciding H_Hat:

[Mike Terry]

On 23/11/2020 03:33, olcott wrote:
> On 11/22/2020 9:14 PM, Ben Bacarisse wrote:
>> Richard Damon <Ric...@Damon-Family.org> writes:
>>
>>> Maybe you have created a system that is a Halter, which will just abort
>>> any program that it determines will never halt. That might have some
>>> use, but isn't the Halt Decider from Linz.
>>
>> The irony is that that algorith -- the algorithm that determines if a
>> computation must be aborted -- is also impossible. He's not written
>> it > yet
>
> IT IS IN THE FIRST POST OF THIS THREAD.
> This is my 2018-12-13 solution.
>
> We merely scan the complete execution trace after each instruction is
> executed and see if there have been any function calls to the same
> function from the same address without any intervening conditional
> branch instructions.
>
> Here is what Mike said about correctly deciding H_Hat:
>
> On 11/20/2020 9:30 PM, Mike Terry wrote:
>> input (H_Hat,H_Hat) is non-halting, assuming your Halts() is as
>> described. This is all baby stuff. [So the correct halting decision
>> for the input is non-halting].

STOP QUOTING ME OUT OF CONTEXT.

THE H_Hat OF THE POST TO WHICH YOU REFER IS A *COMPLETELY DIFFERENT*
H_Hat TO THE ONE IN THIS THREAD. You are misrepresenting my position to
falsely support your own.

The H_Hat that I said was non-halting was A SPECIFIC CODE SAMPLE you
gave (but have omitted from your misreprestation), in which Halts() was
specified to be a pure UTM: no NeedsToBeAborted() calls etc..

OF COURSE that particular H_Hat() never halts, and nobody would say
otherwise. Your H_Hat() above contains a call to H() which clearly
contains infinite recursion detection logic, making it A COMPLETELY
DIFFERENT H_Hat. You must understand that just because you use the same
label for two different objects, that does not actually make them the
same object!

I suggest to you that /deliberately/ misrepresenting someones position
on a topic is a form of "bearing false witness" against that person, and
so I'll be charitable and assume you are doing it because you have
simply misunderstood the thread you are quoting. I expect you to stop
this behaviour now you are aware.


Mike.

[Mike Terry]

STOP QUOTING ME OUT OF CONTEXT.

THE H_Hat OF THE POST TO WHICH YOU REFER IS A *COMPLETELY DIFFERENT*
H_Hat TO THE ONE IN THIS THREAD. You are misrepresenting my position to
falsely support your own.

The H_Hat that I said was non-halting was A SPECIFIC CODE SAMPLE you
gave (but have omitted from your misreprestation), in which Halts() was
specified to be a pure UTM: no NeedsToBeAborted() calls etc..

OF COURSE that particular H_Hat() never halts, and nobody would say

otherwise. Your H_Hat() above contains a Needs_To_Be_Aborted() call,

[olcott]

The two versions of H_Hat are computationally equivalent, thus your
claim that they are *COMPLETELY DIFFERENT* is proved to be false.

Here is the one that you responded to:
On Friday, November 20, 2020 at 8:45:59 PM UTC-6, olcott wrote:
void H_Hat(u32 P)
{
u32 Aborted = Halts(P, P);
if (Aborted)

HALT
else
HERE: goto HERE;
}


int main()
{

u32 P = (u32)H_Hat;
Halts(P, P);
HALT;
}
https://groups.google.com/g/comp.theory/c/1uKuMgjxJTM/m/c3HEt-UWAAAJ


Here is the one in this thread:

On 11/22/2020 7:24 PM, olcott wrote:
// Defined at the bottom of page 319 of Linz
void Ĥ(u32 P)
{
u32 Input_Halts = H(P, P);
if (!Input_Halts)
HALT
else
HERE: goto HERE;
}


int main()
{
u32 P = (u32)Ĥ;
H(P, P);
HALT;
}

> The H_Hat that I said was non-halting was A SPECIFIC CODE SAMPLE you
> gave (but have omitted from your misreprestation), in which Halts() was
> specified to be a pure UTM: no NeedsToBeAborted() calls etc..
>
> OF COURSE that particular H_Hat() never halts, and nobody would say
> otherwise.

Therefore

On 11/20/2020 9:30 PM, Mike Terry wrote:
> [So the correct halting decision for the input is non-halting].

> Your H_Hat() above contains a call to H() which clearly
> contains infinite recursion detection logic, making it A COMPLETELY
> DIFFERENT H_Hat.

As I have already proven it does not make it a completely different
H_Hat. The execution trace of neither H_Hat ever reaches the point of
the difference.

> You must understand that just because you use the same
> label for two different objects, that does not actually make them the
> same object!

I understand that. The fact that their execution traces are identical
makes them the same execution.

> I suggest to you that /deliberately/ misrepresenting someones position
> on a topic is a form of "bearing false witness" against that person, and
> so I'll be charitable and assume you are doing it because you have
> simply misunderstood the thread you are quoting.  I expect you to stop
> this behaviour now you are aware.
>
>
> Mike.

The actual case is that I proved that the difference that you assert
does not actually exist. Also I forgot that you even asserted a difference.

[Mike Terry]

I don't care what you /think/ I said or implied. YOU ARE
MISREPRESENTING MY POSITION, whether honestly or dishonestly.

STOP DOING THAT.

I will probably reply in more detail to your other remarks separately.

Mike.

[olcott]

The execution trace where H_Hat calls Halts(H_Hat, _H_Hat) and Halts is
a UTM

The execution trace where H_Hat calls Halts(H_Hat, _H_Hat) and Halts is
a Halt decider

are identical because neither H_Hat ever reaches the point of the
difference: the return value from Halts().

[Richard Damon]

If the execution trace of H_Hat(H_Hat) where H_Hat calls Halts, and
Halts is purportedly a Halting Decider, and Halts never get to analyzing
the return value of itself in the trace sounds like a real good reason
to doubt that it is a proper halting decider. How can it possible claim
to do its job if it never gets around to actually looking at the
important points of the program.

Remember, how Halts works is totally up to its designer, the
restrictions on it are what it is to expect as inputs and how it must
deliver its answer, so its failure to get the information that it needs,
must a a failure in it design.

I have shown alternate designs that will happen to handle this
particular problem (but makes the Linz contradiction failure painfully
obvious, so that may be why you ignore them), so there is no way to
claim that it is an inherent part of the problem.

[Mike Terry]

On 23/11/2020 17:37, olcott wrote:

Ahem, you've "conveniently" omitted the important context of the
original thread. Let me restore it for you:

> (2) It is known that the above code is infinitely recursive if Halts()
> *acts like a UTM and simulates its input returning true if and*
> *only if its input halts.*

I.e. Halts() in the thread you quote IS A PURE UTM. *As a result of
this* it is clear that THIS H_Hat(H_Hat) never halts.

>
>
> Here is the one in this thread:
> On 11/22/2020 7:24 PM, olcott wrote:
> // Defined at the bottom of page 319 of Linz
> void Ĥ(u32 P)
> {
> u32 Input_Halts = H(P, P);
> if (!Input_Halts)
> HALT
> else
> HERE: goto HERE;
> }
>
>
> int main()
> {
> u32 P = (u32)Ĥ;
> H(P, P);
> HALT;
> }
>

The code above calls H() which is NOT A PURE UTM. Your H contains code
to detect infinite recursive emulation. IT IS NOT THE SAME AS THE
Halts() OF THE THREAD WITH MY WORDS WHICH YOU QUOTE.

Consequently the H^ above is a different function from the H_Hat I was
referring to.

>
>> The H_Hat that I said was non-halting was A SPECIFIC CODE SAMPLE you
>> gave (but have omitted from your misreprestation), in which Halts()
>> was specified to be a pure UTM: no NeedsToBeAborted() calls etc..
>>
>> OF COURSE that particular H_Hat() never halts, and nobody would say
>> otherwise.
>
> Therefore
> On 11/20/2020 9:30 PM, Mike Terry wrote:
>> [So the correct halting decision for the input is non-halting].
>

..and this is NOT the same H^ as in this thread.

>> Your H_Hat() above contains a call to H() which clearly contains
>> infinite recursion detection logic, making it A COMPLETELY DIFFERENT
>> H_Hat.
>
> As I have already proven it does not make it a completely different
> H_Hat. The execution trace of neither H_Hat ever reaches the point of
> the difference.
>
>> You must understand that just because you use the same label for two
>> different objects, that does not actually make them the same object!
>
> I understand that. The fact that their execution traces are identical
> makes them the same execution.

They are not the same function. Their (full) execution traces will
definitely be different. In the case of my quote, the H_Hat(H_Hat)
never terminates, while in the case of your H^, H^(H^) terminates after
finitely many steps. (That's assuming your halt decider H has tests for
detecting infinite recursive emulation. It does, doesn't it?)

>
>> I suggest to you that /deliberately/ misrepresenting someones position
>> on a topic is a form of "bearing false witness" against that person,
>> and so I'll be charitable and assume you are doing it because you have
>> simply misunderstood the thread you are quoting. I expect you to stop
>> this behaviour now you are aware.
>>
>>
>> Mike.
>
> The actual case is that I proved that the difference that you assert
> does not actually exist. Also I forgot that you even asserted a difference.

Of course it exists. In the thread you quote, Halts() was a PURE UTM
with nothing to terminate infinite recursion. In this thread, your H^
was a halt decider with a UTM customised with ADDED TESTS for infinite
recursion.

Anyway, it doesn't matter - you are misrepresenting my postion, so STOP
DOING IT. :)

Mike.

[olcott]

This above link IS THE WHOLE MESSAGE NO DETAILS ARE MISSING.

The execution trace where H_Hat calls Halts(H_Hat, _H_Hat) and Halts is

a UTM and

The execution trace where H_Hat calls Halts(H_Hat, _H_Hat) and Halts is
a Halt decider

are identical because neither H_Hat ever reaches the point of the
difference: the return value from Halts().

Identical execution traces are identical computations thus H_Hat is the
same in both cases.

[olcott]

On 11/23/2020 12:47 PM, Mike Terry wrote:

> On 23/11/2020 17:37, olcott wrote:

>>> You must understand that just because you use the same label for two
>>> different objects, that does not actually make them the same object!
>>
>> I understand that. The fact that their execution traces are identical
>> makes them the same execution.
>
> They are not the same function.  Their (full) execution traces will
> definitely be different.  In the case of my quote, the H_Hat(H_Hat)
> never terminates, while in the case of your H^, H^(H^) terminates after
> finitely many steps.  (That's assuming your halt decider H has tests for
> detecting infinite recursive emulation.  It does, doesn't it?)

In the case where Halts() acts as a UTM we see this same execution
sequence of H_Hat repeated infinitely:

[00000503](05) e86ffeffff call 00000377
[000004f7](01) 55 push ebp
[000004f8](02) 8bec mov ebp,esp
[000004fa](01) 51 push ecx
[000004fb](03) 8b4508 mov eax,[ebp+08]
[000004fe](01) 50 push eax
[000004ff](03) 8b4d08 mov ecx,[ebp+08]
[00000502](01) 51 push ecx
[00000503](05) e86ffeffff call 00000377

In the case where Halts() is a halt decider we see that exact H_Hat
sequence exactly one time. This proves that Halts() decided H_Hat
correctly.

[olcott]

You don't have to believe or disbelieve simply look at the actual facts
of the provided execution trace itself.

[Richard Damon]

You mean this trace which is what the requirement require?


1) Enter H_Hat(H_Hat)
2) duplicate H_Hat (this step 'optimized' out in your machine)
3) Enter Halts(H_Hat, H_Hat)
4) Halts does its decision and decides tht H_Hat is non-halting
5) Halts returns false to indicate non-halting
6) H_Hat goes to the else clause
7) H_Hat Halts.

Thus, Halts was wrong.


Your trace shows a variance, thus there MUST be something wrong in it.

Yes, YOUR program says that H_Hat is non-halting. It says it multiple
ways. The above trace shows that they are wrong.

Do you wish to hire me to debug your code? Rate is $100/Hour, double
that if you help.

Of course, I will need a detailed statement of work of exactly what is
required, and considering you history of bad wording, making sure the
definitions are fully agreed on.

[olcott]

I mean the actual execution trace from fully operational code not any
mere misconceptions.

The last 9 lines of this show the part that infinitely repeats unless
aborted. We can tell that it infinitely repeats:

(1) By not stopping it and seeing it keep repeating.

(2) The fact that there are no conditional branch instructions in this
sequence that could possibly exit this infinite recursion.

I don't really have time for [fact free people] that are anchored in
misconceptions.

[Richard Damon]

Right, you have an infinite recursion due to a fault in the design of
you Halts function.

Your trace is omitting the conditional that the trace inside the trace
is providing, thus your trace is defective. This is likely because it
appears that you have moved the halting decision to be global and your
halts just executes the tape. This breaks you machine as a UTM and makes
your halts function inoperative (can the call to halts now ever really
return false, or does any call to halts that would return false abort
the whole program?

You have been putting a lot of effort into breaking you programs ability
to run according to the requirements.

Your trace does NOT show that H_Hat has non-halting behavior with a
working halting decider, because it shows a non-working halt decider.

The trace I provided shows that H_Hat WILL be halting if the halt
decider meets its decision requirements and says non-halting.

As you mentioned elsewhere, your Halts got aborted before it ever got to
see what happens after it returns, thus it got into a non-halting loop
based on its own bad design.

Maybe the problem is that you just can't conceive of any way to tell
that a given program will halt or run forever besides just running it,
but there are methods that can do a lot better (they of course still
can't totally meet the requirements, that is factually proved impossible).

[Mike Terry]

Hey, you're totally CHEATING here. There ARE conditional branch
intstructions, but you've just silently snipped them from the trace
output you've shown. There are HUGE gaps in your trace!!


Mike.

[olcott]

Unless we maintain a line-of-demarcation between the halt decider and
its input pathological self-reference(Olcott 2004) makes the halting
problem have undecidable inputs in the same way that the Liar Paradox is
neither true nor false.

https://groups.google.com/g/comp.theory/c/RO9Z9eCabeE/m/Ka8-xS2rdEEJ

Instead of asking the question: Does the input halt on its input?
that is subject to pathological self-reference.

We ask the question: Does the execution of the input have to be aborted
to prevent its infinite execution?

When we ask this latter question then we can ignore all of the
conditional branch instructions that are in the halt decider and only
pay attention to the ones that are in the input.

The input to H will be the description (encoded in some form)
of M, say WM, as well as the input w. The requirement is then
that, given any (WM, w), the Turing machine H will halt with
either a yes or no answer.

H.q0 wMw ⊢* H.yes if M applied to w halts, and
H.q0 wMw ⊢* H.no if M applied to w does not halt.
(Linz 1990:318)

Any input TMD that would never halt unless a UTM stopped simulating it
expresses behavior that is not halting behavior.

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

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

[Richard Damon]

Yes, Turing Machines ALLOW for a 'pathological' self-reference, that is
true. You can't just define that away. Because of this, we have the
actual fact that we absolutely can't have a correct universal halt decider.

>
> https://groups.google.com/g/comp.theory/c/RO9Z9eCabeE/m/Ka8-xS2rdEEJ
>
> Instead of asking the question: Does the input halt on its input?
> that is subject to pathological self-reference.
>
> We ask the question: Does the execution of the input have to be aborted
> to prevent its infinite execution?

Ok, So you DO want to ask a different question. Fine, Just admit that
this means you are working on a DIFFERERNT question, and then admit that
means that all you results have no application to things that use the
REAL question.

It would be best if you adopt a distinctive name for this alternate
question. Maybe this could be the needed-abort problem?

I would still quibble with your 'need', as I can show alternate deciders
based largely on your plan that don't need to abort in this same manner.

>
> When we ask this latter question then we can ignore all of the
> conditional branch instructions that are in the halt decider and only
> pay attention to the ones that are in the input.
>
>     The input to H will be the description (encoded in some form)
>     of M, say WM, as well as the input w. The requirement is then
>     that, given any (WM, w), the Turing machine H will halt with
>     either a yes or no answer.
>
>     H.q0 wMw ⊢* H.yes   if M applied to w halts, and
>     H.q0 wMw ⊢* H.no    if M applied to w does not halt.
>     (Linz 1990:318)
>
> Any input TMD that would never halt unless a UTM stopped simulating it
> expresses behavior that is not halting behavior.
>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company.
>
> http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>

Of course, when you adopt the admission of a different question, you
will need to stop making reference to the Linz proof, as it has nothing
to do with you question, since it is about the Halting problem, not the
need-to-abort problem.

[olcott]

[Richard Damon]

BUT the program in question doesn't ask for a UTM, it asks for a Halt
Decider. If you give it a UTM, then any misbehavior is your fault for
not meeting your side of the contract.

Linz only talks about behavior given a Machine that claims to be a
Halting Decider by the classical definition of a Halting Decider. If the
machine you provide doesn't meet those requirements, it doesn't apply.

Since you seem to want to talk about some different question than the
classical halting problem, you need to stop trying to apply your results
to things that are talking about the classical halting problem.

PO-aborting is NOT the same as classical halting.

[olcott]

So you still fail to comprehend that the simulation of the TMD of a TM
by a UTM is an equivalent computation to directly execution the TM?

> Linz only talks about behavior given a Machine that claims to be a
> Halting Decider by the classical definition of a Halting Decider. If the
> machine you provide doesn't meet those requirements, it doesn't apply.

-Any input TMD that would never halt unless a UTM stopped
-simulating it expresses behavior that is not halting behavior.

> Since you seem to want to talk about some different question than the
> classical halting problem,

You can never seem to understand the difference between the actual
classical halting problem and the conventional proofs of its
undecidability.

The halting problem itself is only about determining whether or not an
input TMD would halt on its input.

Here is the would not halt part right here:
-Any input TMD that would never halt unless a UTM stopped
-simulating it expresses behavior that is not halting behavior.

> you need to stop trying to apply your results
> to things that are talking about the classical halting problem.
>
> PO-aborting is NOT the same as classical halting.
>

[Richard Damon]

Except it isn't Directly execution of a Turing Machine can continue
indefinitately. It seems you Decider Machine choose to abort a machine
early, even though the halt decider in it is supposed to make its
decision in finite time.

Maybe I shouldn't be saying your machine got the answer wrong, because
from the trace you provided, it never got the answer but aborted the
whole shebang and thus failed to give any answer as a classical halt
decider.

Maybe having you machine blow up counts as a non-halting decision in the
PO-aborting problem, but then we shouldn't be invoking Linz.

>
>> Linz only talks about behavior given a Machine that claims to be a
>> Halting Decider by the classical definition of a Halting Decider. If the
>> machine you provide doesn't meet those requirements, it doesn't apply.
>
> -Any input TMD that would never halt unless a UTM stopped
> -simulating it expresses behavior that is not halting behavior.

The key point I was making is the IF your decider meets the basic
requirement of a decider, which I now doubt, then H_Hat would be
non-halting. I would say from all the evidnece given now, Halts fails to
meet the requirements of a decider because it fails to proper give its
answer.

>
>> Since you seem to want to talk about some different question than the
>> classical halting problem,
>
> You can never seem to understand the difference between the actual
> classical halting problem and the conventional proofs of its
> undecidability.
>
> The halting problem itself is only about determining whether or not an
> input TMD would halt on its input.

YOU don't get it. The Halting Problem is STRICTLY about wheter the
ACTUAL machine will halt or not, and building a machine to answer that
question and give it answer to something to use. The decider, needing to
make it correct decision in finite time.

Your Halting decider fails at this task.

Now, because of the major mess you have made of the machine, it is a bit
more work to show, but that is mostly because you have totally removed
the ability to use your machine as a regular UTM, while still keeping a
supposedly working halt decider.

This says that to actual perform the right test, we need to take your
WHOLE machine (since the whole thing is now the halt decider), and
covert it into a Turing Machine, make the modification as described by
Linz, and then reconvert it back into your notation. My first guess is
that you machine is going to choke on trying to step thorugh the
protected mode code that makes up you emulator.

Now, since you seem to want to be claiming some other problem so that
all this isn't actually needed to be done, you just have to stop saying
you mean anything to Linz.

>
> Here is the would not halt part right here:
> -Any input TMD that would never halt unless a UTM stopped
> -simulating it expresses behavior that is not halting behavior.

Yes, your decider detects that your decider didn't decide in time.
FAIL.

[olcott]

The execution trace that I provided proves that the input would be
infinitely recursive if it was allowed to continue.

[Richard Damon]

Right, it abort the execution inside the supposed halt decider because
the halt decider failed to decide in finite time.

If you are working in stanard theory, your halt decider is broken.

If you are in some alternate theory, Linz has no part in it.

[Jeff Barnett]

In other words, you fucked up. Give it a rest. Enter student mode and no
more demarcing for you. Too much effort. Too intellectual. Relax.
Approach truth with a resigned attitude. Programming and analyses of
programs is simply beyond your ken. And your barbie too. That's it!!!
Play with dolls for a while. It might help.
--
Jeff Barnett

[olcott]

On 11/23/2020 4:45 PM, Richard Damon wrote:
> On 11/23/20 5:38 PM, olcott wrote:
>> On 11/23/2020 4:35 PM, Richard Damon wrote:
>>> On 11/23/20 5:06 PM, olcott wrote:
>
>>>> So you still fail to comprehend that the simulation of the TMD of a TM
>>>> by a UTM is an equivalent computation to directly execution the TM?
>>>
>>> Except it isn't Directly execution of a Turing Machine can continue
>>> indefinitately. It seems you Decider Machine choose to abort a machine
>>> early, even though the halt decider in it is supposed to make its
>>> decision in finite time.
>>>
>>> Maybe I shouldn't be saying your machine got the answer wrong, because
>>> from the trace you provided, it never got the answer but aborted the
>>> whole shebang and thus failed to give any answer as a classical halt
>>> decider.
>>>
>>> Maybe having you machine blow up counts as a non-halting decision in the
>>> PO-aborting problem, but then we shouldn't be invoking Linz.
>> The execution trace that I provided proves that the input would be
>> infinitely recursive if it was allowed to continue.
>>
>>
>
> Right, it abort the execution inside the supposed halt decider because
> the halt decider failed to decide in finite time.

You are really seeming to act as if you are dumber than a box of rocks.

How can a decider that makes its decision in 25 steps possibly be
construed as not doing this in finite time?

> If you are working in stanard theory, your halt decider is broken.
>
> If you are in some alternate theory, Linz has no part in it.
>

[Richard Damon]

On 11/23/20 5:51 PM, olcott wrote:
> On 11/23/2020 4:45 PM, Richard Damon wrote:

>>
>> Right, it abort the execution inside the supposed halt decider because
>> the halt decider failed to decide in finite time.
>
> You are really seeming to act as if you are dumber than a box of rocks.
>
> How can a decider that makes its decision in 25 steps possibly be
> construed as not doing this in finite time?

Because it didn't meet the requirements. The requirements of the decider
is to provide it answer to the program that called it, not to just abort
the machine.

In Linz terms, it didn't go to H.No, it just halted.

[olcott]

On 11/23/2020 5:02 PM, Richard Damon wrote:
> On 11/23/20 5:51 PM, olcott wrote:
>> On 11/23/2020 4:45 PM, Richard Damon wrote:
>
>>>
>>> Right, it abort the execution inside the supposed halt decider because
>>> the halt decider failed to decide in finite time.
>>
>> You are really seeming to act as if you are dumber than a box of rocks.
>>
>> How can a decider that makes its decision in 25 steps possibly be
>> construed as not doing this in finite time?
>
> Because it didn't meet the requirements. The requirements of the decider
> is to provide it answer to the program that called it, not to just abort
> the machine.
>
> In Linz terms, it didn't go to H.No, it just halted.

Anyone understanding assembly language knows that this is not true.

int main()
{
u32 P = (u32)H_Hat;
if (Halts(P, P))
Output("Input Halted");
else
Output("Input did not halt");
HALT;
}

Outputs: Input did not halt

>
>>
>>> If you are working in stanard theory, your halt decider is broken.
>>>
>>> If you are in some alternate theory, Linz has no part in it.
>>>
>>
>>
>

[Mike Terry]

We can indeed ignore the halt decider outer-level trace entries, and
concentrate on just what the halt decider embedded emulator sees its
input doing.

The point is that that is exactly what I was talking about - there are
STILL HUGE gaps in the trace you present, which mean that we cannot see
any evidence for a supposed "lack of conditional branches". EVEN AFTER
FILTERING OUT THE DECIDER-LEVEL TRACE ENTRIES.

Also, a practical suggestion, which is going to be a must for any final
delivery you make: your trace is going to be totally unreadable without
an indication of which nested emulation level the entries belong to.
Rather than adding a "nested emulation level" (1,2,3...) it would be
most logical to add instead some kind of "emulation id", since multiple
emulations could in principle exist simultaneously at the same level at
the same time. (You could still make the id numeric, just as long as
it's unique for each emulation in the trace.)


Mike.

[olcott]

All that I have right now is a DebugTrace() of all the user specified
code. This provides a very obvious basis for a halt decider's correct
halting decision of the H_Hat code specified in this execution trace.

There will not be an embedded decider because an embedded decider
permits what would seem to causal observers as inconsistent halting
decisions. By not allowing any execution trace data to exist that the
halt decider cannot see then even the apperance of inconsistency ceases
to exist.

In this case could have specified main() line this:
int main()
{

u32 P = (u32)H_Hat;
if (Halts(P, P))
Output("Input Halted");
else
Output("Input did not halt");
HALT;
}

> The point is that that is exactly what I was talking about - there are
> STILL HUGE gaps in the trace you present, which mean that we cannot see
> any evidence for a supposed "lack of conditional branches".  EVEN AFTER
> FILTERING OUT THE DECIDER-LEVEL TRACE ENTRIES.

This is a complete trace of all of the user specified instructions up to
the point where the halt deciding operating system aborts the execution
trace of its input.

The execution of all operating system code was screened out from the
analysis: Number of Instructions Executed(10671)
It is 171 pages of code.

> Also, a practical suggestion, which is going to be a must for any final
> delivery you make:  your trace is going to be totally unreadable without
> an indication of which nested emulation level the entries belong to.

That is irrelevant.
Any function call from the same machine address to the same function
without intervening conditional branch instructions in-between is
infinite recursion. This is my 2018-12-13 design.

> Rather than adding a "nested emulation level" (1,2,3...) it would be
> most logical to add instead some kind of "emulation id", since multiple
> emulations could in principle exist simultaneously at the same level at
> the same time.  (You could still make the id numeric, just as long as
> it's unique for each emulation in the trace.)
>
>
> Mike.
>

To understand that my solution is correct you must interpret the details
within this grande scheme:

Any input TMD that would never halt unless its UTM stopped simulating it

expresses behavior that is not halting behavior.

H.q0 wMw ⊢* H.yes if M applied to w halts, and
H.q0 wMw ⊢* H.no if M applied to w does not halt.
(Linz 1990:318)

An ordinary UTM that executes its input one-state-transition at a time
and has the additional functionality of determining (yet not deciding)
the halting of its input can transition to some intermediate state to
indicate its "not halting" determination and it would still be a UTM.

Wanting a machine to simultaneously be a decider and a UTM is like
wanted a black cat that it only white and thus not black at all.

[Richard Damon]

On 11/23/20 6:31 PM, olcott wrote:
> On 11/23/2020 5:02 PM, Richard Damon wrote:
>> On 11/23/20 5:51 PM, olcott wrote:
>>> On 11/23/2020 4:45 PM, Richard Damon wrote:
>>
>>>>
>>>> Right, it abort the execution inside the supposed halt decider because
>>>> the halt decider failed to decide in finite time.
>>>
>>> You are really seeming to act as if you are dumber than a box of rocks.
>>>
>>> How can a decider that makes its decision in 25 steps possibly be
>>> construed as not doing this in finite time?
>>
>> Because it didn't meet the requirements. The requirements of the decider
>> is to provide it answer to the program that called it, not to just abort
>> the machine.
>>
>> In Linz terms, it didn't go to H.No, it just halted.
>
> Anyone understanding assembly language knows that this is not true.
>
> int main()
> {
>   u32 P = (u32)H_Hat;
>   if (Halts(P, P))
>     Output("Input Halted");
>   else
>     Output("Input did not halt");
>   HALT;
> }
>
> Outputs: Input did not halt
>
>

But didn't your trace show that you went down the recursion and then the
whole machine just halted because of infinite recursion.

If this program prints "Input did not halt", then H_Hat will halt and
show that the answer was wrong.

Which Lie is it?

[Richard Damon]

On 11/23/20 7:37 PM, olcott wrote:

> All that I have right now is a DebugTrace() of all the user specified
> code. This provides a very obvious basis for a halt decider's correct
> halting decision of the H_Hat code specified in this execution trace.
>
> There will not be an embedded decider because an embedded decider
> permits what would seem to causal observers as inconsistent halting
> decisions. By not allowing any execution trace data to exist that the
> halt decider cannot see then even the apperance of inconsistency ceases
> to exist.

If it can't be embeded, it isn't that answer to the halting problem used
in Linz, so you better stop making reference to it, and it makes it
basically incompatible with most uses of it in Mathematics.

Glad we have that straight. Stop talking about it like it was.

>
> In this case could have specified main() line this:
> int main()
> {
>   u32 P = (u32)H_Hat;
>   if (Halts(P, P))
>     Output("Input Halted");
>   else
>     Output("Input did not halt");
>   HALT;
> }
>

But, since you just said it is not embedded, why do you show it as
embeded and make claims that such a function can return 'not halt'?

[olcott]

I have not written the halt deciding code yet so I cannot show a full
execution trace to the above outputs.

It seems that you are not smart enough to understand that when these
lines of code infinitely repeat that this is infinite execution:

[00000503](05) e86ffeffff call 00000377
[000004f7](01) 55 push ebp
[000004f8](02) 8bec mov ebp,esp
[000004fa](01) 51 push ecx
[000004fb](03) 8b4508 mov eax,[ebp+08]
[000004fe](01) 50 push eax
[000004ff](03) 8b4d08 mov ecx,[ebp+08]
[00000502](01) 51 push ecx
[00000503](05) e86ffeffff call 00000377

That would make sense for someone that does not understand assembly
language.

[olcott]

On 11/23/2020 7:04 PM, Richard Damon wrote:
> On 11/23/20 7:37 PM, olcott wrote:
>
>> All that I have right now is a DebugTrace() of all the user specified
>> code. This provides a very obvious basis for a halt decider's correct
>> halting decision of the H_Hat code specified in this execution trace.
>>
>> There will not be an embedded decider because an embedded decider
>> permits what would seem to causal observers as inconsistent halting
>> decisions. By not allowing any execution trace data to exist that the
>> halt decider cannot see then even the apperance of inconsistency ceases
>> to exist.
>
> If it can't be embeded, it isn't that answer to the halting problem used
> in Linz, so you better stop making reference to it, and it makes it
> basically incompatible with most uses of it in Mathematics.

> Glad we have that straight. Stop talking about it like it was.
>>
>> In this case could have specified main() line this:
>> int main()
>> {
>>   u32 P = (u32)H_Hat;

HERE: goto HERE; // the global halt decider catchs this

>>   if (Halts(P, P))
>>     Output("Input Halted");
>>   else
>>     Output("Input did not halt");
>>   HALT;
>> }
>>
>
> But, since you just said it is not embedded, why do you show it as
> embeded and make claims that such a function can return 'not halt'?

That is not embedded. That is a separate function call to the global
halt decider.

[Richard Damon]

I was writting assembly code 50 years ago. I suspect I know the assembly
languages of more processors than you do (not positive, just a good guess).

Yes, that trace, if complete, shows an infinite recursion and thus
non-halting behavior, but that recursion seems to be inside the claimed
halt decider, not H_Hat, so more shows a flaw there.

I do note that you seem to be saying that things you have said very
definitely may not actually be that way. For example, in that code
above, you state that we DO get to the print statements, but in the
basically same code of H_Hat, that we did NOT get to that same else clause.

This seems to be sign of uncertainty. Do you plan to go back over your
past statements and admit which ones no longer apply? Or do we need to
keep on guessing?

I think the biggest thing you have said is a sort of admission that you
have NO intent to try to make you system behave in the manner of the
halting problem used in Linz, so you REALLY need to clean up your
terminalogy and make it clear that you do NOT intend that your results
apply to the classical halting problem.

[Richard Damon]

On 11/23/20 8:20 PM, olcott wrote:
> On 11/23/2020 7:04 PM, Richard Damon wrote:
>> On 11/23/20 7:37 PM, olcott wrote:
>>
>>> All that I have right now is a DebugTrace() of all the user specified
>>> code. This provides a very obvious basis for a halt decider's correct
>>> halting decision of the H_Hat code specified in this execution trace.
>>>
>>> There will not be an embedded decider because an embedded decider
>>> permits what would seem to causal observers as inconsistent halting
>>> decisions. By not allowing any execution trace data to exist that the
>>> halt decider cannot see then even the apperance of inconsistency ceases
>>> to exist.
>>
>> If it can't be embeded, it isn't that answer to the halting problem used
>> in Linz, so you better stop making reference to it, and it makes it
>> basically incompatible with most uses of it in Mathematics.
>
>> Glad we have that straight. Stop talking about it like it was.
>>>
>>> In this case could have specified main() line this:
>>> int main()
>>> {
>>>    u32 P = (u32)H_Hat;
>
>       HERE: goto HERE;  // the global halt decider catchs this

But that statement didn't show up in the trace at all.
(At least not the one posted in this branch recently)

>
>>>    if (Halts(P, P))
>>>      Output("Input Halted");
>>>    else
>>>      Output("Input did not halt");
>>>    HALT;
>>> }
>>>
>>
>> But, since you just said it is not embedded, why do you show it as
>> embeded and make claims that such a function can return 'not halt'?
>
> That is not embedded. That is a separate function call to the global
> halt decider.
>
>

But if we make it a Turing Machine it will get embedded, right? (Hint,
Turing Machines do not have a call operator).

Also, do you machine yet have a way to run it that disables the Halt
Detector around main, but still allows a working halt detector elsewhere
in the program?

You still haven't answered why this call ended up in the else clause,
but the basically identical code with H_Hat didn't.

[olcott]

It looks like your skills are not nearly as good as you claimed or you
would never make the obvious mistake of claiming that an execution trace
was not from the specified function when all of the code of this
function has been provided.

To help focus your attention I only listed the repeating portion of the
full disassmbly shown on the original post.

Ĥ()

[000004f7](01) 55 push ebp
[000004f8](02) 8bec mov ebp,esp
[000004fa](01) 51 push ecx
[000004fb](03) 8b4508 mov eax,[ebp+08]
[000004fe](01) 50 push eax
[000004ff](03) 8b4d08 mov ecx,[ebp+08]
[00000502](01) 51 push ecx
[00000503](05) e86ffeffff call 00000377

[Mike Terry]

There has to be an embedded decider, because that is how the Linz proof
specifies H^. When you say "seem to causal [sic] observers as
inconsistent halting decisions" that is because the decisions really are
inconsistent! You can't magic them to be consistent by making the
decider part of the OS. (If that's your plan.)

>
> In this case could have specified main() line this:
> int main()
> {
> u32 P = (u32)H_Hat;
> if (Halts(P, P))
> Output("Input Halted");
> else
> Output("Input did not halt");
> HALT;
> }
>
>> The point is that that is exactly what I was talking about - there are
>> STILL HUGE gaps in the trace you present, which mean that we cannot
>> see any evidence for a supposed "lack of conditional branches". EVEN
>> AFTER FILTERING OUT THE DECIDER-LEVEL TRACE ENTRIES.
>
> This is a complete trace of all of the user specified instructions up to
> the point where the halt deciding operating system aborts the execution
> trace of its input.

ok, I see. So 00000377 is the address of H(), and you have deliberately
omitted the trace for H(). But H will contain the conditional code that
breaks the recursion, and you are just trying to hide it from people
reading the trace.

You need to put the H trace entries back in to support your claim that
there are no unconditional branches.

When I said "We can indeed ignore the halt decider /outer-level/ trace
entries" what that means is that we can ignore the entries in the trace
up to the first call "emulation call". That occurs either IN H, or you
have made H effectively an emulation call (replacing your previous
emulate OS call). In either case, H contains conditional branches which
lead to the infinite recursion being broken so we need to see those
trace entries. (We can't ignore trace entries for the copy of H within
H^, as that is part of the H^(H^) calculation being decided.)

All you've done is try to hide those away so nobody can see them, hoping
that means if nobody can point to anything then you've succeeded.

The opposite is true - if you /don't/ show them, then your trace shows
nothing of interest, so you have failed to refute anything.

I'm afraid people will need to see all that, because that is the level
at which the Linz proof works.

>
>> Also, a practical suggestion, which is going to be a must for any
>> final delivery you make: your trace is going to be totally unreadable
>> without an indication of which nested emulation level the entries
>> belong to.
>
> That is irrelevant.
> Any function call from the same machine address to the same function
> without intervening conditional branch instructions in-between is
> infinite recursion. This is my 2018-12-13 design.
>

BUT THERE /ARE/ INTERVENING CONDITIONAL BRANCH INSTRUCTIONS.

One of the problems here is that your "non-terminating-behaviour" test
in H is unsound. Simply hiding the trace entries that show this is a
waste of time, because people aren't just going to take your word for
it. You have to provide all the evidence!

(I have pointed out this unsoundness half a dozen times previously, but
you've never addressed it.)

Also, you OBVIOUSLY need to have some way of indicating the emulation
depth, otherwise people won't be able to make any sense of what's going
on. The way your trace reads at the moment, it looks like the call to H
just JUMPS to H^, whereas in fact those H^ trace entries are in a
completely different virtual process which is being emulated! And some
loop somewhere is stepping through that emulation and we need to see
that, at the inner emulation levels, at least...


Mike.

[Richard Damon]

In your message: <gradnc6CZNx2wiHC...@giganews.com>

you said:
HERE: goto HERE; // the global halt decider catchs this

From you program listings, this statement is at address 00000517

That address never appeared in the trace, so your halt decider
apparently made its decision based on information it never got.

Curious. Maybe a lie. Do you actually have code for the ESP module?

Also, the code you list for H is CLEARLY not the code for the real halt
decider, that has all been snipped from the trace.

Note that once the execution trace has gone into an embeded version of
this call, if somehow this function H is going to be able to return the
halting/need-to-be-aborted status there needs to be some interface to
you system function, and because we are now inside an internal H, all
that code (for the purpose of code OUTSIDE that call, has a conditional
on it, as part of the 'global' halt decider. Thus can not be used to
decide that the outer code has non-halting behavior.

Also, you still haven't explained how you went from aborting on a call
to returning from a Halts call **someties** (it returned to the print
but not to the HALT in H_Hat),

It is clear that you are throwing out incomplete results where you have
tweeked things to prove your points. You evidience doesn't really match
your conclusions.

>
> To help focus your attention I only listed the repeating portion of the
> full disassmbly shown on the original post.
>
> Ĥ()
> [000004f7](01)  55                  push ebp
> [000004f8](02)  8bec                mov ebp,esp
> [000004fa](01)  51                  push ecx
> [000004fb](03)  8b4508              mov eax,[ebp+08]
> [000004fe](01)  50                  push eax
> [000004ff](03)  8b4d08              mov ecx,[ebp+08]
> [00000502](01)  51                  push ecx
> [00000503](05)  e86ffeffff          call 00000377
>
>

In one sense, none of this matters, because you seem to be claiming that
you are answering a different question, so none of this applies to the
classical halting problem.

The only issue with this is that even though you claim to have removed
the halts function from being 'embedded' to prevent the paradoxical Linz
proof, you seem to still show it in the code and show examples calling
it. If H_Hat can call it, it can be paradoxical, and you keep mentioning
the classical halting problem as if what you are doing as any meaning
for it.

The one thing you do to try to save face is 'break' your machine so if
we actually try to run H_Hat, you abort it claiming infinite execution,
but we have at this point enough data to show that IF your Halts does
succeed at being close enough to a halt decider to have returned the
answer, it was wrong, of the issue might be that it does never return
the answer to H_Hat, and thus fails that way.

Thus we can say that one of the following is true (and maybe both)

1) You are claiming applicability to the classical halting problem, and
thus under its stipulations, in which case you machine eather fail to
deliver the answer in finite time or give the wrong answer.

2) You are actually working on a different problem, and thus are wrong
at claiming any connection to the classical halting problem, and really
should be changing your terminology.

[Ben Bacarisse]

olcott <No...@NoWhere.com> writes:

> On 11/22/2020 10:03 PM, Ben Bacarisse wrote:

>> olcott <No...@NoWhere.com> writes:
>>
>>> On 11/22/2020 9:14 PM, Ben Bacarisse wrote:
>>>> Richard Damon <Ric...@Damon-Family.org> writes:
>>>>
>>>>> Maybe you have created a system that is a Halter, which will just abort
>>>>> any program that it determines will never halt. That might have some
>>>>> use, but isn't the Halt Decider from Linz.
>>>>
>>>> The irony is that that algorith -- the algorithm that determines if a
>>>> computation must be aborted -- is also impossible. He's not written
>>>> it yet
>>>
>>> IT IS IN THE FIRST POST OF THIS THREAD.
>>

>> You have not yet written it (so you said) which it why you have not yet
>> noticed that it won't work. If you have written it, then you need to do
>> more testing, (or ask an expert to tell you why it won't work).
>>
> Here is what Mike said about my way of correctly deciding H_Hat:

Do you really think the lying about other people's position helps your
case one iota? No, in fact it is shameful behaviour which, sadly, is no
longer unusual for you. I suspect you know you have nothing, so lying
is all you have left. You lied two years about having H and H^ "fully
encoded as actual Turing machines" "exactly and precisely as in Linz"
when you had no such thing, and you have nothing now so you lie about
Mike's position.

> Here is what Mike said about my way of correctly deciding H_Hat:
> Here is what Mike said about my way of correctly deciding H_Hat:
> Here is what Mike said about my way of correctly deciding H_Hat:
> Here is what Mike said about my way of correctly deciding H_Hat:

Oh, and you are being childish again, too. Grow up.

> On 11/20/2020 9:30 PM, Mike Terry wrote:
>> input (H_Hat,H_Hat) is non-halting, assuming your Halts() is as
>> described. This is all baby stuff. [So the correct halting decision
>> for the input is non-halting].

If anyone with a proper newsreader needs to confirm you mendacity, the
link is Message-ID: <pP-dnWFAVJ0hFCXC...@brightview.co.uk>

Mike is confirming what everyone knows: of course the H_Hat(H_Hat) from
that post is non-halting -- it calls a function that is not a decider
but one that just simulates the computation of applying the argument to
itself.

Tellingly, that post did not include any code you could reasonably call
a halt decider because you now know that as soon as you show that code,
I (or indeed anyone else but you) will produce the confounding example
for it. The H_Hat you show is in fact irrelevant since it calls a
function that is not even a decider (let alone a halt decider), but you
hope naive readers will be fooled by the silly name you gave it: Halts.

You didn't show the function you actually claim (erroneously, of course)
to be a halt decider in that post. That function, also called Halts in
a deliberate attempt to muddy the waters, gets the right answer for the
H_Hat(H_Hat) case written with the other Halts. But it gets the wrong
answer for a similar computation built from it. Why? Because anytime
you dare to post any code the claims to be a halt decider, someone will
instantly post the confounding example, AND IT WILL USE YOUR HALT
DECIDER, AND NOT ANOTHER FUNCTION WITH THE SAME NAME.

Of course you did not respond to the points I made about the
impossibility of the code you have not yet shown anyone -- the code that
decides a computation must be aborted. That code is as impossible as a
halt decider, unless it gets an infinity of cases wrong.

--
Ben.

[Ben Bacarisse]

olcott <No...@NoWhere.com> writes:

> All that I have right now is a DebugTrace() of all the user specified
> code. This provides a very obvious basis for a halt decider's correct
> halting decision of the H_Hat code specified in this execution trace.

Gosh. Is that a lie, or is that just very, very stupid? Lying or dumb,
dumb or lying? I can never quite tell.

Having only the code that loops around the single stepping DebugTrace()
(presumably a simple modification to someone else's emulator) is exactly
the wrong basis for a halt decider. Its the version that makes the
"Hat" computation non-finite BY NOT BEING A DECIDER. The "HAT"
computation you are analysing is irrelevant because it's not built on a
finite decider.

Only when you add the impossible "abort if needed" code would you have
anything that even resembles a decider. But it's not a halt decider,
because that code has ITS OWN "HAT" computation which it decides
incorrectly.

--
Ben.

[olcott]

I do not have to conform to any conventions but this one:

H.q0 wMw ⊢* H.yes if M applied to w halts, and

H.q0 wMw ⊢* H.no if M applied to w would not halt.

Any input TMD that would never halt unless a UTM stopped simulating it

expresses behavior that is not halting behavior.

>> In this case could have specified main() line this:
>> int main()
>> {
>>   u32 P = (u32)H_Hat;
>>   if (Halts(P, P))
>>     Output("Input Halted");
>>   else
>>     Output("Input did not halt");
>>   HALT;
>> }
>>
>>> The point is that that is exactly what I was talking about - there are
>>> STILL HUGE gaps in the trace you present, which mean that we cannot
>>> see any evidence for a supposed "lack of conditional branches".  EVEN
>>> AFTER FILTERING OUT THE DECIDER-LEVEL TRACE ENTRIES.
>>
>> This is a complete trace of all of the user specified instructions up to
>> the point where the halt deciding operating system aborts the execution
>> trace of its input.
>
> ok, I see.  So 00000377 is the address of H(), and you have deliberately
> omitted the trace for H().  But H will contain the conditional code that
> breaks the recursion, and you are just trying to hide it from people
> reading the trace.

Not not at all. From my trace as you have already said:

On 11/20/2020 9:30 PM, Mike Terry wrote:
> input (H_Hat,H_Hat) is non-halting, assuming your Halts() is as
> described. This is all baby stuff.

The underlying algorithm is very obvious, thus far too simple to hide.

> You need to put the H trace entries back in to support your claim that
> there are no unconditional branches.

The only conditional branch that is not required to create the
DebugStep() mode is the decision to abort otherwise infinite simulation.

The DebugStep() mode is enormously more complex that the simplified
example that have I provided. I intend to publish the full source code
of the entire system as a part of my formal presentation.

It compiles under both Windows and Linux.

> When I said "We can indeed ignore the halt decider /outer-level/ trace
> entries" what that means is that we can ignore the entries in the trace
> up to the first call "emulation call".  That occurs either IN H, or you
> have made H effectively an emulation call (replacing your previous
> emulate OS call).  In either case, H contains conditional branches which
> lead to the infinite recursion being broken so we need to see those
> trace entries.  (We can't ignore trace entries for the copy of H within
> H^, as that is part of the H^(H^) calculation being decided.)

You already said (and it is quite obviously true) that this is baby
stuff. As soon as any function is called twice from the same machine
address without any conditional branches in-between the simulator stops
simulating its input.

> All you've done is try to hide those away so nobody can see them, hoping
> that means if nobody can point to anything then you've succeeded.

You already said this is "baby stuff". It really is baby stuff. I just
gave you all of the steps.

> The opposite is true - if you /don't/ show them, then your trace shows
> nothing of interest, so you have failed to refute anything.

The simulator merely watches its simulation of the following
instructions until it sees a function call to 377 from 503 the second
time with no JCC (Jump-Condition_Code) in-between.

This is the last 9 instructions shown below.

People can eventually look at all of my code and the thousands of lines
of code of the x86 emulator and they can look at the hundreds of pages
out output. It all boils down to this:

The simulator merely watches its simulation of the following
instructions until it sees a function call to 377 from 503 the second
time with no JCC (Jump-Condition_Code) in-between.

>>
>>> Also, a practical suggestion, which is going to be a must for any
>>> final delivery you make:  your trace is going to be totally unreadable
>>> without an indication of which nested emulation level the entries
>>> belong to.
>>
>> That is irrelevant.
>> Any function call from the same machine address to the same function
>> without intervening conditional branch instructions in-between is
>> infinite recursion. This is my 2018-12-13 design.
>>
>
> BUT THERE /ARE/ INTERVENING CONDITIONAL BRANCH INSTRUCTIONS.

Only those intervening conditional branch instructions required to
implement this design:

Any input TMD that would never halt unless a UTM stopped simulating it

expresses behavior that is not halting behavior.

> One of the problems here is that your "non-terminating-behaviour" test
> in H is unsound.  Simply hiding the trace entries that show this is a
> waste of time, because people aren't just going to take your word for
> it.  You have to provide all the evidence!

I have not written this code yet, and I you already said this really is
"baby stuff" and I have given you ALL the steps many times.

BABY-STUFF !!!
The simulator merely watches its simulation of the above instructions
until it sees a function call to 377 from 503 the second time with no
JCC (Jump-Condition_Code) in-between.

> (I have pointed out this unsoundness half a dozen times previously, but
> you've never addressed it.)

BABY-STUFF !!!
BABY-STUFF !!!
BABY-STUFF !!!
BABY-STUFF !!!
BABY-STUFF !!!

> Also, you OBVIOUSLY need to have some way of indicating the emulation
> depth, otherwise people won't be able to make any sense of what's going
> on.  The way your trace reads at the moment, it looks like the call to H

So in other words if code makes a call to the same function from the
same address with no conditional branch instructions in-between it might
somehow magically break out of the infinite recursion anyway?

That is not the way that reality actually works.

> just JUMPS to H^, whereas in fact those H^ trace entries are in a
> completely different virtual process which is being emulated!  And some
> loop somewhere is stepping through that emulation and we need to see
> that, at the inner emulation levels, at least...

When we see every single instruction that is executed by any and all
user code including its function calls to the operating system then we
can definitively determine with our own eyes that the halt decider
decided correctly.

All of the extraneous complexity of these other details does not change
the fact that we can independently verify that halting decision for
ourselves from what we can see.

>
>
> Mike.
>

I have been working on finishing the "baby steps" of the halt decider. I
have the control flow instruction decoder designed and nearly
sufficiently complete for the infinite recursion detector.

[olcott]

Mike did not understand that the execution of H_Hat under a simulator
and under a halt decider are identical executions.

In both cases H_Hat has no way to tell the difference, thus H_Hat cannot
change its behavior under the two cases because H_Hat never reaches the
point where it would get a different return value from Halts.

Mike still does not understand this yet that does not make his
misunderstanding correct and my understanding incorrect.

[olcott]

[olcott]

[olcott]

No it does not and you know that it does not.
It neither has its own H_Hat computation and the one H_Hat that exists
is decided correctly and you know that it is decided correctly.

[Mike Terry]

Wrong.

You are talking here about H, whereas I was talking about H^. If you
want to say anything about the Linz proof, you need to talk about H
*and* H^, and H^ must follow the Linz spec for how it relates to H. Duh.

>>> In this case could have specified main() line this:
>>> int main()
>>> {
>>> u32 P = (u32)H_Hat;
>>> if (Halts(P, P))
>>> Output("Input Halted");
>>> else
>>> Output("Input did not halt");
>>> HALT;
>>> }
>>>
>>>> The point is that that is exactly what I was talking about - there are
>>>> STILL HUGE gaps in the trace you present, which mean that we cannot
>>>> see any evidence for a supposed "lack of conditional branches". EVEN
>>>> AFTER FILTERING OUT THE DECIDER-LEVEL TRACE ENTRIES.
>>>
>>> This is a complete trace of all of the user specified instructions up to
>>> the point where the halt deciding operating system aborts the execution
>>> trace of its input.
>>
>> ok, I see. So 00000377 is the address of H(), and you have
>> deliberately omitted the trace for H(). But H will contain the
>> conditional code that breaks the recursion, and you are just trying to
>> hide it from people reading the trace.
>
> Not not at all. From my trace as you have already said:
>
> On 11/20/2020 9:30 PM, Mike Terry wrote:
>> input (H_Hat,H_Hat) is non-halting, assuming your Halts() is as
>> described. This is all baby stuff.

You still don't understand what I said. That "baby stuff" remark
applies to the halting of the H_Hat(H_Hat) with H_Hat as specified in
that thread: the Halts() routine is a pure UTM with no "non-halting
behaviour" detection code. The H^ in this thread is different, so my
remark doesn't apply. (That's not to say it's not baby stuff - just
that my remark was specifically intended for a different H_Hat.)

I have told you many times that your test must be UNSOUND. You have
never responded to this, so I've assumed you don't really know whether
your test is sound or unsound (or probably, what that even means,
although I've also explained that to you before).

Now you are getting closer to actually coding the test (which you
claimed to have "fully coded" two years ago), you are finally giving
more details.

So... what do you think. Is the following test a SOUND test for
non-halting?

TEST: "monitor the simulation until there is a function
call to 377 from 503 a second time, with no conditional
branch inbetween"

Putting it more directly - if some calculation P(I) triggers the TEST
(so it contains two calls from 377 from 503, with no conditional branch
inbetween), does this genuinely imply that the calculation will never
halt?

Bear in mind that the two calls in question do not necessarily occur in
the same "virtual address space", that is to say the two calls can [and
in the case of T_Hat(T_Hat) *do* ] occur at /different levels of
emulation/. [Your trace notation obscures this simple fact, making
everything appear to be in one single virtual process, when it's not.]

What do you think? This seems to be your primary intuition that
triggered all this "refuting" activity, BUT IS IT ACTUALLY CORRECT?

Of course, you will say "All my intuitions are correct by definition -
I'm never wrong" but that doesn't make it true! :)

Is TEST *SOUND* ?

>>>
>>>> Also, a practical suggestion, which is going to be a must for any
>>>> final delivery you make: your trace is going to be totally unreadable
>>>> without an indication of which nested emulation level the entries
>>>> belong to.
>>>
>>> That is irrelevant.
>>> Any function call from the same machine address to the same function
>>> without intervening conditional branch instructions in-between is
>>> infinite recursion. This is my 2018-12-13 design.
>>>
>>
>> BUT THERE /ARE/ INTERVENING CONDITIONAL BRANCH INSTRUCTIONS.
>
> Only those intervening conditional branch instructions required to
> implement this design:
>
> Any input TMD that would never halt unless a UTM stopped simulating it
> expresses behavior that is not halting behavior.
>

But you are basing your opinion that H_Hat(H_Hat) "would never halt" on
your intuition that TEST (above) is a /sound/ test - if it matches, then
that genuinely implies that the calculation never halts.

IF your intuition is wrong your argument falls apart at this point. The
whole rationale for checking TEST is refuted. If TEST is unsound, you
might as well replace TEST with any old code that just decides
non-halting! (Such a replacement test would also be unsound - no better
or worse than applying TEST, but having the advantage of clarifying your
argument.) This is what I meant in a previous post that you got uppity
about - an /unsound/ test is effectively just your code "seeing
something it doesn't like".

A sound test, on the other hand, would have some justification in a halt
decider - an example would be a tight loop detector that looks for a
"HERE: goto HERE;" statement (or equivalent x86 code). If this
tight-loop test matches for calculation trace, then that calculation is
guaranteed to be non-halting. (The proof for this is easy.)

>> One of the problems here is that your "non-terminating-behaviour" test
>> in H is unsound. Simply hiding the trace entries that show this is a
>> waste of time, because people aren't just going to take your word for
>> it. You have to provide all the evidence!
>
> I have not written this code yet, and I you already said this really is
> "baby stuff" and I have given you ALL the steps many times.
>
> BABY-STUFF !!!
> The simulator merely watches its simulation of the above instructions
> until it sees a function call to 377 from 503 the second time with no
> JCC (Jump-Condition_Code) in-between.
>
>> (I have pointed out this unsoundness half a dozen times previously,
>> but you've never addressed it.)
>
> BABY-STUFF !!!
> BABY-STUFF !!!
> BABY-STUFF !!!
> BABY-STUFF !!!
> BABY-STUFF !!!

Dude, get a grip! :)

>
>> Also, you OBVIOUSLY need to have some way of indicating the emulation
>> depth, otherwise people won't be able to make any sense of what's
>> going on. The way your trace reads at the moment, it looks like the
>> call to H
>
> So in other words if code makes a call to the same function from the
> same address with no conditional branch instructions in-between it might
> somehow magically break out of the infinite recursion anyway?
>
> That is not the way that reality actually works.
>

Aha, you seem to be trying to answer the question I asked above - is
TEST a /sound/ test. Perhaps this is some kind of answer???? (I'm not
sure...)


Mike.

[olcott]

Before we can proceed we need to have agreement on this general
principle: (It is a mandatory prerequisite).

Any input TMD that would never halt unless a UTM stopped simulating it
expresses behavior that is not halting behavior.

[Ben Bacarisse]

olcott <No...@NoWhere.com> writes:

> On 11/23/2020 9:53 PM, Ben Bacarisse wrote:
>> olcott <No...@NoWhere.com> writes:
>>
>>> All that I have right now is a DebugTrace() of all the user specified
>>> code. This provides a very obvious basis for a halt decider's correct
>>> halting decision of the H_Hat code specified in this execution trace.
>>
>> Gosh. Is that a lie, or is that just very, very stupid? Lying or dumb,
>> dumb or lying? I can never quite tell.
>>
>> Having only the code that loops around the single stepping DebugTrace()
>> (presumably a simple modification to someone else's emulator) is exactly
>> the wrong basis for a halt decider. Its the version that makes the
>> "Hat" computation non-finite BY NOT BEING A DECIDER. The "HAT"
>> computation you are analysing is irrelevant because it's not built on a
>> finite decider.
>>
>> Only when you add the impossible "abort if needed" code would you have
>> anything that even resembles a decider. But it's not a halt decider,
>> because that code has ITS OWN "HAT" computation which it decides
>> incorrectly.
>
> No it does not and you know that it does not.

If you dare post the code, I'll show you, explicitly (again).

> It neither has its own H_Hat computation and the one H_Hat that exists
> is decided correctly and you know that it is decided correctly.

Of course it has it's own -- you don't get to say I can't write one if I
want. Your ruse -- to use one H_Hat and two different called functions
is simply dishonest. You know about it now, but you keep pushing it
because you have nothing else. Twenty years and this is all you have.

Any time you fancy posting what you think is a halt decider (even if it
refers to impossible-to-write code like your "needs_to_be_aborted"
function), I will post the confounding example. You dare not even try
because you know I'm right. Need we add intellectual cowardice to your
character traits?

--
Ben.

[Mike Terry]

That's a bad wording for lots of reasons. If I agree to it as it
stands, I know you will take that quote and post it all over the
newsgroup claiming it means something it doesn't. Because that's the
kind of guy that you are.

However, I'll happily agree to the better worded:

Any input (TMD, DATA) which, when run under a (pure) UTM
never halts, expresses behaviour that is not halting behaviour.

Mike.

[olcott]

On 11/24/2020 9:53 AM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
>> On 11/23/2020 9:53 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> All that I have right now is a DebugTrace() of all the user specified
>>>> code. This provides a very obvious basis for a halt decider's correct
>>>> halting decision of the H_Hat code specified in this execution trace.
>>>
>>> Gosh. Is that a lie, or is that just very, very stupid? Lying or dumb,
>>> dumb or lying? I can never quite tell.
>>>
>>> Having only the code that loops around the single stepping DebugTrace()
>>> (presumably a simple modification to someone else's emulator) is exactly
>>> the wrong basis for a halt decider. Its the version that makes the
>>> "Hat" computation non-finite BY NOT BEING A DECIDER. The "HAT"
>>> computation you are analysing is irrelevant because it's not built on a
>>> finite decider.
>>>
>>> Only when you add the impossible "abort if needed" code would you have
>>> anything that even resembles a decider. But it's not a halt decider,
>>> because that code has ITS OWN "HAT" computation which it decides
>>> incorrectly.
>>
>> No it does not and you know that it does not.
>
> If you dare post the code, I'll show you, explicitly (again).

The simplified code that I posted never has been the actual code. The
actual code is far too complex to use as an example.

Line 14 requires an enormously complex set up to enable x86utm to be a
multi-tasking operating system. This was the most difficult part of the
development whole x86utm operating system.

08 bool Halts(u32 P, u32 I)
09 {
10 bool Halted = false;
11 bool Aborted = false;
12 while (!Halted && !Aborted)
13 {
14 Halted = DebugStep(P, I);
15 Aborted = Needs_To_Be_Aborted();
16 }
17 return !Aborted;
18 }

>> It neither has its own H_Hat computation and the one H_Hat that exists
>> is decided correctly and you know that it is decided correctly.
>
> Of course it has it's own -- you don't get to say I can't write one if I
> want.

There is only one set of machine code in the whole system that comprises
the intruction of H_Hat. I have very great disrespect for people that
deny easily verifiable facts.

> Your ruse -- to use one H_Hat and two different called functions
> is simply dishonest.

It is fricking fully operational code.

> You know about it now, but you keep pushing it
> because you have nothing else. Twenty years and this is all you have.

Your only rebuttal seems to be based on denying easily verifiable facts.

> Any time you fancy posting what you think is a halt decider (even if it
> refers to impossible-to-write code like your "needs_to_be_aborted"
> function), I will post the confounding example.

Whataboutism, also known as whataboutery, is a variant of the tu quoque
logical fallacy that attempts to discredit an opponent's position by
charging them with hypocrisy without directly refuting or disproving
their argument.

Whataboutism is particularly associated with Soviet and Russian
propaganda. https://en.wikipedia.org/wiki/Whataboutism

This is the input to the decider that we are talking about diverting
away from this is the same kind of dishonest dodge used by Soviet
propaganda.

01 void H_Hat(u32 P)
02 {
03 if (Halts(P, P))
04 HERE: goto HERE;
05 else
06 HALT
07 }

> You dare not even try
> because you know I'm right. Need we add intellectual cowardice to your
> character traits?
>





--

[olcott]

I will start quoting it this way:

Any input (TMD, DATA) which, when run under a (pure) UTM

never halts, expresses behavior that is not halting behavior.
(Mike Terry 11/24/2020 10:19 AM)

Yeah !!! Great job !!!

[olcott]

That one won't work for me, but it does show that you understand the
principle. It is no good that we say "never halts" because we cannot
wait an eternity to see that it never halts.

Since this statement is to be formulated for a general audience that has
never been a part of these conversations we must remove the word "pure"
because without the context of these conversations the word "pure" would
be quite confusing. When we say UTM to a general audience of computer
scientists "pure" is already understood.

Any input (TMD / DATA) that would never halt unless its (UTM) stopped

simulating it expresses behavior that is not halting behavior.

TMD = Turing Machine Description
UTM = Universal Turing Machine

[Mike Terry]

The fact that you would want to quote someone agreeing to such an
obvious statement, when NOBODY HAS EXPRESSED DISAGREEMENT WITH IT,
speaks volumes about your desparation.

Also, the fact that you feel you need resort to "appeal to an authority"
in your arguments, rather than stating the case yourself speaks volumes
for your lack of confidence - if you agree with what I said, just say it
as your own words! (As I say, nobody is going to deny such an obvious
fact, unless perhaps they just dislike the phrasing around "exhibits
behaviour" for something which in the end is not actually concrete...)

Of course, I know that really you're just looking for a way to piss me
off! Because, well, that's the kind of guy you are... :)


Mike.

[Mike Terry]

[Mike Terry]

On 24/11/2020 16:46, olcott wrote:

Just to be clear - that is your statement, not mine.
Mike.

[olcott]

Everyone here besides you is narrowing focused on forming some sort of
rebuttal no matter what. They don't give a rats ass about the truth or
forming any sort of mutual understanding. Both Ben and Richard have made
it a habit to very consistently deny very obviously verifiable facts.

You are the one person that will not go to the extent of denying very
obviously verifiable facts for the sole purpose of contriving some basis
for denigrating my work.

[olcott]

Can you find some flaw in it?

[olcott]

Both Ben and Richard have made it a habit of denying easily verifiable
facts as long as doing this would contrive some rhetorical basis for the
denigration of my work that would convince casual observers (that are
not paying any attention to the actual reasoning) that I am incorrect.

When I prove my point Ben typically erases this whole point and responds
with ad hominem attacks that have nothing to do with the actual point.

Both Ben and Richard have disagreed that this is an infinitely repeating
sequence even though is is an obviously verifiable fact that it is an
infinitely repeating sequence:

_H_Hat()

[000004f7](01) 55 push ebp
[000004f8](02) 8bec mov ebp,esp
[000004fa](01) 51 push ecx
[000004fb](03) 8b4508 mov eax,[ebp+08]
[000004fe](01) 50 push eax
[000004ff](03) 8b4d08 mov ecx,[ebp+08]
[00000502](01) 51 push ecx
[00000503](05) e86ffeffff call 00000377

[Mike Terry]

Not that it matters, but since you ask...

It's the whole phrasing "..would never XXX unless..". I'll be honest -
that kind of wording is a bit of a red flag for identifying cranks.
Cranks for some reason love to say things like "The ONLY reason xxx is
true is yyy", not appreciating that true statements are typically "just
true" and picking out a single reason why they are true is normally
nonsensical. I guess it's because they've at some time been forced into
accepting something they don't like, and want to say "yeah, ok xxx is
'true' but it's not 'properly true' in some way..."

HP is a mathematical problem, and maths people make clear and concise
definitions of things. In your case what does the phrase "WOULD never
halt UNLESS" mean? (i.e., mathematically?)

Mathematically the definition of halting/non-halting does not involve
anything emulating the calculation, so the whole phrasing is a bit naff
and suggests the author is confused about what halting means. Like, the
author thinks the definition of halting/non-halting is some kind of
experimental result or something, rather than a mathematical definition...

Or... perhaps the author is deliberately choosing a vague wording in
order to later introduce some further confusing irrelevancy.

All the above is just my overall opinion, not really relevant to the
main topic of this thread.

Mike.

[Richard Damon]

I will point out that my objection to it showing evidence of non-halting
behavior IN THE TOP LEVEL H_HAT was based on the apparently possibly
false assumption that this result was then going to be given to H_Hat
and it would then halt.

As I have pointed out, the other possible situation is that the the
Halts detector doesn't report this to H_Hat that called it and thus the
Halt Decider failed on more basic grounds.

Note, I did NOT say this wasn't an infinitely repeating sequence, what I
disagreed with is that this infinitely repeating sequence, since it
occured INSIDE the halt detector, is not proof that H_Hat itself is
non-halting. H_Hst can be non-halting if the Halt Detector fails to do
its job, or it can be halting if the Halt Detector does its basic job of
returning that result, but it is then just wrong.

One objection to calling in infinitely repeating is that the trace
doesn't show the conditional that is between every instruction where the
halting decider decides to continue or not, so this is NOT proof of
non-halting behavior of the top level invocation. It does provide
evidence that the Halt Decider appears to have non-halting behavior (the
lack of clear indication of how this decider works keeps me from saying
it really proves it. Instead of non-halting behavior, it might be saving
itself from that and just be wrong.

[olcott]

So to paraphrase you found no logical error.

[Richard Damon]

On 11/24/20 11:46 AM, olcott wrote:
>
> That one won't work for me, but it does show that you understand the
> principle. It is no good that we say "never halts" because we cannot
> wait an eternity to see that it never halts.
>
> Since this statement is to be formulated for a general audience that has
> never been a part of these conversations we must remove the word "pure"
> because without the context of these conversations the word "pure" would
> be quite confusing. When we say UTM to a general audience of computer
> scientists "pure" is already understood.
>
> Any input (TMD / DATA) that would never halt unless its (UTM) stopped
> simulating it expresses behavior that is not halting behavior.
>
> TMD = Turing Machine Description
> UTM = Universal Turing Machine
>

My objection to that wording is that would not halt unless ... has a
less clear test than will never halt

The key here is that unless implies that the current system has done the
second clause, and to prove it was right we need to change the system,
and whenever people have proposed to make the change in the system, you
have objected to how the change was made, insisting that other things
need to be changed also.

Now, because of the structure of your Halt Decider, running that same
program is a 'real' UTM, is exactly the test of the unless the UTM
stopped simulating it.

The need for the adjective on the UTM is because you seemed to have
co-opted the term UTM as your UTM seems to be able to make a stopping
decision on its own by your phrasing.

You REALLY need to put a distinction between the UTM that is running
things from the Halt Detector, and this wrapping of Main in a call to
the halt detector. Once you have forced that, you have disqualified your
code from running the verification test, since that needs a 'real' or
'pure' UTM, not one that can decide to abort code.

[Richard Damon]

He found too many weasel words that make it too easy to twist to mean
something differnt than what was assumed intended.

[Mike Terry]

On 24/11/2020 17:34, olcott wrote:
> On 11/24/2020 10:48 AM, Mike Terry wrote:
>> On 24/11/2020 16:32, olcott wrote:
>>> On 11/24/2020 10:19 AM, Mike Terry wrote:
>>>> On 24/11/2020 15:51, olcott wrote:

<.. snip ..>

>>>>>
>>>>> Before we can proceed we need to have agreement on this general
>>>>> principle: (It is a mandatory prerequisite).
>>>>>
>>>>> Any input TMD that would never halt unless a UTM stopped simulating it
>>>>> expresses behavior that is not halting behavior.
>>>>
>>>> That's a bad wording for lots of reasons. If I agree to it as it
>>>> stands, I know you will take that quote and post it all over the
>>>> newsgroup claiming it means something it doesn't. Because that's the
>>>> kind of guy that you are.
>>>>
>>>> However, I'll happily agree to the better worded:
>>>>
>>>> Any input (TMD, DATA) which, when run under a (pure) UTM
>>>> never halts, expresses behaviour that is not halting behaviour.
>>>>
>>>> Mike.
>>>>
>>>
>>> I will start quoting it this way:
>>> Any input (TMD, DATA) which, when run under a (pure) UTM
>>> never halts, expresses behavior that is not halting behavior.
>>> (Mike Terry 11/24/2020 10:19 AM)
>>>
>>> Yeah !!! Great job !!!
>>>
>>
>> The fact that you would want to quote someone agreeing to such an
>> obvious statement, when NOBODY HAS EXPRESSED DISAGREEMENT WITH IT,
>> speaks volumes about your desparation.
>
> Both Ben and Richard have made it a habit of denying easily verifiable
> facts as long as doing this would contrive some rhetorical basis for the
> denigration of my work that would convince casual observers (that are
> not paying any attention to the actual reasoning) that I am incorrect.

That's not right. Both Ben and Richard point out perfectly correct
problems with your arguments. The problem is that you don't understand
what they point out, so you think they are making it up, ignoring your
arguments, generally "tricking" readers, and so on.

It's you who are biased here in the way you view those discussions. I
don't recall any "trickery" on their part - just honest discussion of
problems with your arguments.

>
> When I prove my point Ben typically erases this whole point and responds
> with ad hominem attacks that have nothing to do with the actual point.

> Both Ben and Richard have disagreed that this is an infinitely repeating
> sequence even though is is an obviously verifiable fact that it is an
> infinitely repeating sequence:
>
> _H_Hat()
> [000004f7](01) 55 push ebp
> [000004f8](02) 8bec mov ebp,esp
> [000004fa](01) 51 push ecx
> [000004fb](03) 8b4508 mov eax,[ebp+08]
> [000004fe](01) 50 push eax
> [000004ff](03) 8b4d08 mov ecx,[ebp+08]
> [00000502](01) 51 push ecx
> [00000503](05) e86ffeffff call 00000377

Well, this is a good example. You think this is an example of your
"denying easily verifiable facts", but this is just showing your biases.
You believe there is infinite recursion, so what you have provided
must "prove" this, because in your mind the "infinite" claim is correct.

But those do those trace entries actually prove what you claim? No. So
your claim isn't "easily verifiable" after all.

In a recent post I asked you a key question which I've asked several
times before - is your "repeated calls to a function with no intervening
conditional branches" test actually a SOUND test? You've never answered
this, so why should anyone take a trace such as the one above as
indicating infinite recursion? And that's before anyone asks whether
there are hidden trace entries they're not seeing.


Mike.

[olcott]

Even though it fricking infinitely repeats they deny that it is infinite.

> But those do those trace entries actually prove what you claim?  No.  So
> your claim isn't "easily verifiable" after all.

Look at this example.
Validating the halt deciding criteria with a totally concrete example

> In a recent post I asked you a key question which I've asked several
> times before - is your "repeated calls to a function with no intervening
> conditional branches" test actually a SOUND test?

The execution trace that I provided unequivocally prove beyond all
possible doubt that my assessment is correct.

Look at this simpler example:
Validating the halt deciding criteria with a totally concrete example

> You've never answered

You ask me is my assessment in my opinion is my reasoning sound after I
have already proven beyond all possible ddunt that my assessment is
necessarily completely correct.

That is like asking how sure are you the 2 + 3 = 5?
Are you pretty sure, very sure, really really sure?

Please look at this simpler example.
Validating the halt deciding criteria with a totally concrete example

> this, so why should anyone take a trace such as the one above as
> indicating infinite recursion?

It proves that it is infinite recursion.

Please look at this simpler example:
Validating the halt deciding criteria with a totally concrete example

> And that's before anyone asks whether
> there are hidden trace entries they're not seeing.
>
>
> Mike.
>

Yeah like when we say that 2 + 3 = 5 some mytsterious space alien might
have snuck a 6 in-between the 2 and the 3 so we can never we totally
sure that 2 + 3 = 5.

[dklei...@gmail.com]

I wonder - doesn't the "input" to a Turing Machine simulation also
need an initial head position specification? It is trivial to design a
tape that halts for some initial head positions but not for others.

[olcott]

The (just now verified) fact that the debug trace produced by executing
the following code is identical to the execution trace produced by the
actual simulator:


int DebugTrace(u32 N, u32 M)
{
return ((int(*)(int))N)(M);
}


void H_Hat(u32 P)
{
u32 Aborted = DebugTrace(P, P);
if (Aborted)

HALT
else
HERE: goto HERE;
}


int main()
{

u32 P = (u32)H_Hat;
DebugTrace(P, P);
HALT;
}


This proves the following:
(1) The x86utm simulator does faithfully simulate its input.

(2) H_Hat is infinitely recursive.

(3) The infinite recursion of H_Hat can be analytically be determined in
advance.

(4) If the simulator decides to stop simulating its input and return
false this would be a correct not-halting decision on H_Hat.

[Richard Damon]

Yes, the specification of the tape would include the initial position.
For some machines, it starts at a physical end of the tape, and the tape
only goes on infinitely in one direction. For machines with bidirection
tapes, there is a '0' cell which is the starting point.

[olcott]

I think that most people assume that the initial tape head position for
a UTM's input is the beginning of its tape for tapes that are boundless
in one direction.

[olcott]

When we can see that the debug trace produced by the very complex
DebugTrace() that we cannot see produces exactly the same sequences of
instructions as the one that we can see then be have empirical proof
that the hidden DebugTrace() is doing as claimed.

int DebugTrace(u32 N, u32 M)
{
return ((int(*)(int))N)(M);
}

I just verified this. This proves that my x86utm DebugTrace() is a
faithful UTM.

[Mike Terry]

Well, you must see that this isn't reasonable behaviour on your part,
and you're getting all worked up over it. Let's take a step back and
see what we've actually got here...

You have published a trace that shows two repeats (or perhaps three,
whatever) of a chunk of code and then stops at that point. You did not
show the trace repeating infinitely often - of course nobody can do
that, and nobody suggests anybody can do that. The point is, though,
that you're saying over and over that the trace /proves/ your point, but
the trace only proves the point that it repeats twice.

I'm not being funny here, just literal, to help you see things from
others' perspectives. I could ask how you make a jump from repeating
twice to infinite recursion, but the point is /however/ you do it you
are not "just seeing it in the trace", right? So there is some
reasoning on your part which you are not sharing. Some "proof" even?
(Maybe you feel you /are/ sharing it, but I've not seen anything, and
you pointedly refuse to expand on this when I ask about it.)

So to me it seems quite reasonable for someone else to deny that there
is infinite recursion based just on the basis of your trace - because
the trace really /doesn't/ show or even "imply" that there is infinite
recursion. Maybe you've made the jump somehow from "trace shows two
repetitions" to "infinite recursion", but that's /your/ intuition, or
perhaps even your proof, if you had a proof (I can't believe that you do...)

Do you think it's reasonable that just because you say "Even though it
fricking infinitely repeats they deny that it is infinite." that means
people should just accept it? Why don't you try to /prove/ it somehow?
Or investigate why people are saying it's not true, or whatever. Those
approaches would all be reasonable.

I see you've started a new thread with a simple example - that's a
better response than accusing people of dishonesty/stupidity/whatever.
I'll look at the new thread later. (I see you've got two more replies
to my same post for me to deal with first!)

>
>> But those do those trace entries actually prove what you claim? No.
>> So your claim isn't "easily verifiable" after all.
>
> Look at this example.
> Validating the halt deciding criteria with a totally concrete example
>

Yeah, I'll look at that later...

>> In a recent post I asked you a key question which I've asked several
>> times before - is your "repeated calls to a function with no
>> intervening conditional branches" test actually a SOUND test?
>
> The execution trace that I provided unequivocally prove beyond all
> possible doubt that my assessment is correct.

I don't see that, but maybe the new thread will help.

>
> Look at this simpler example:
> Validating the halt deciding criteria with a totally concrete example
>
>> You've never answered
>
> You ask me is my assessment in my opinion is my reasoning sound after I
> have already proven beyond all possible ddunt that my assessment is
> necessarily completely correct.

I have not seen any proof. Maybe your idea of proof is less exacting
than everyone else's...

>
> That is like asking how sure are you the 2 + 3 = 5?
> Are you pretty sure, very sure, really really sure?

No it's not, because if someone asked my /why/ I believed 2+3=5 or asked
me to prove it, I would go ahead and explain. What you do is just
repeat the claim over and over, claiming you've absolutely frickin
proved it 100 times already, when you haven't. All you've done is
repeat many times that your Halt() is looking for repeated calls to the
same address with no intervening conditional branches. (That is at best
an observation, not a proof of anything, although perhaps you might like
to expand that into a proper proof.)

>
> Please look at this simpler example.
> Validating the halt deciding criteria with a totally concrete example
>
>> this, so why should anyone take a trace such as the one above as
>> indicating infinite recursion?
>
> It proves that it is infinite recursion.

We'll see!

Mike.

[olcott]

Although you have sometimes been quite denigrating there has never been
a point where you have been dishonest. I can't say that about the
others. Anyone that denies verifiable facts is a (according to the
bible) damned (going to Hell) liar.

> You have published a trace that shows two repeats (or perhaps three,
> whatever) of a chunk of code and then stops at that point.  You did not
> show the trace repeating infinitely often - of course nobody can do
> that, and nobody suggests anybody can do that.  The point is, though,
> that you're saying over and over that the trace /proves/ your point, but
> the trace only proves the point that it repeats twice.

They can see the same code that you agreed was infinite recursive and
accept rather than deny that it is infinitely recursive.

I am breaking it down into simpler steps stating here:

Validating the halt deciding criteria with a totally concrete example

--- Step(1)

> I'm not being funny here, just literal, to help you see things from
> others' perspectives.  I could ask how you make a jump from repeating
> twice to infinite recursion, but the point is /however/ you do it you

By seeing the infinite recursion in the source code and by seeing the
infinite recursion in the object code.

> are not "just seeing it in the trace", right?  So there is some
> reasoning on your part which you are not sharing.  Some "proof" even?
> (Maybe you feel you /are/ sharing it, but I've not seen anything, and
> you pointedly refuse to expand on this when I ask about it.)

The exact same thing that you said is "baby stuff" So obvious that
anyone knows it is true, they flat out deny as true.

I am breaking it down into simpler steps stating here:

Validating the halt deciding criteria with a totally concrete example

--- Step(1)

> So to me it seems quite reasonable for someone else to deny that there
> is infinite recursion based just on the basis of your trace - because
> the trace really /doesn't/ show or even "imply" that there is infinite
> recursion.

This one leave zero doubt.

Validating the halt deciding criteria with a totally concrete example

--- Step(1)

I still need to add a few more steps to prove my point, yet I must do
them in micro increments because by reviewers (besides you) have less
than zero interest in understanding me and focus all their attention on
denigration.

> Maybe you've made the jump somehow from "trace shows two
> repetitions" to "infinite recursion", but that's /your/ intuition, or
> perhaps even your proof, if you had a proof (I can't believe that you
> do...)

The source code and the object code prove it. What is "baby stuff" to
you is impossibly difficult for everyone else.

> Do you think it's reasonable that just because you say "Even though it
> fricking infinitely repeats they deny that it is infinite." that means
> people should just accept it?  Why don't you try to /prove/ it somehow?
> Or investigate why people are saying it's not true, or whatever.  Those
> approaches would all be reasonable.

The source code proves that it is infinitely recursive is "baby stuff".

> I see you've started a new thread with a simple example - that's a
> better response than accusing people of dishonesty/stupidity/whatever.
> I'll look at the new thread later.  (I see you've got two more replies
> to my same post for me to deal with first!)

It is too difficult to have any dialogue with people that are entirely
focused on denigration and have no interest in anything besides
denigration.

>>
>>> But those do those trace entries actually prove what you claim?  No.
>>> So your claim isn't "easily verifiable" after all.
>>
>> Look at this example.
>> Validating the halt deciding criteria with a totally concrete example
>>
> Yeah, I'll look at that later...
>
>>> In a recent post I asked you a key question which I've asked several
>>> times before - is your "repeated calls to a function with no
>>> intervening conditional branches" test actually a SOUND test?
>>
>> The execution trace that I provided unequivocally prove beyond all
>> possible doubt that my assessment is correct.
>
> I don't see that, but maybe the new thread will help.

int DebugTrace(u32 N, u32 M)
{
return ((int(*)(int))N)(M);
}

void H_Hat(u32 P)
{
u32 Aborted = DebugTrace(P, P);
if (Aborted)

HALT
else
HERE: goto HERE;
}


int main()
{

u32 P = (u32)H_Hat;
DebugTrace(P, P);
HALT;

}

>>
>> Look at this simpler example:
>> Validating the halt deciding criteria with a totally concrete example
>>
>>> You've never answered
>>
>> You ask me is my assessment in my opinion is my reasoning sound after I
>> have already proven beyond all possible ddunt that my assessment is
>> necessarily completely correct.
>
> I have not seen any proof.  Maybe your idea of proof is less exacting
> than everyone else's...

int DebugTrace(u32 N, u32 M)
{
return ((int(*)(int))N)(M);
}

void H_Hat(u32 P)
{
u32 Aborted = DebugTrace(P, P);
if (Aborted)

HALT
else
HERE: goto HERE;
}


int main()
{

u32 P = (u32)H_Hat;
DebugTrace(P, P);
HALT;

}


>>
>> That is like asking how sure are you the 2 + 3 = 5?
>> Are you pretty sure, very sure, really really sure?
>
> No it's not, because if someone asked my /why/ I believed 2+3=5 or asked
> me to prove it, I would go ahead and explain.  What you do is just
> repeat the claim over and over, claiming you've absolutely frickin
> proved it 100 times already, when you haven't.  All you've done is
> repeat many times that your Halt() is looking for repeated calls to the
> same address with no intervening conditional branches.  (That is at best
> an observation, not a proof of anything, although perhaps you might like
> to expand that into a proper proof.)
>
>>
>> Please look at this simpler example.
>> Validating the halt deciding criteria with a totally concrete example
>>
>>> this, so why should anyone take a trace such as the one above as
>>> indicating infinite recursion?
>>
>> It proves that it is infinite recursion.
>
> We'll see!
>
> Mike.
>

[Ben Bacarisse]

(And line 15 is harder still. It's either impossible or it must get an
infinity of cases wrong. Curiously, though, it doesn't matter. I am
happy to assume that it is 100% accurate -- no false positives or
negatives.)

> 08 bool Halts(u32 P, u32 I)
> 09 {
> 10 bool Halted = false;
> 11 bool Aborted = false;
> 12 while (!Halted && !Aborted)
> 13 {
> 14 Halted = DebugStep(P, I);
> 15 Aborted = Needs_To_Be_Aborted();
> 16 }
> 17 return !Aborted;
> 18 }

Given

void Confound_Halts(u32 P) { if (Halts(P, P)) while (1); }

The confounding example for Halts is the computation
Confound_Halts(Confound_Halts) whose halting status is not correctly
determined by the function call Halts(Confound_Halts, Confound_Halts).

>>> It neither has its own H_Hat computation and the one H_Hat that exists
>>> is decided correctly and you know that it is decided correctly.
>>
>> Of course it has it's own -- you don't get to say I can't write one if I
>> want.
>
> There is only one set of machine code in the whole system that
> comprises the intruction of H_Hat. I have very great disrespect for
> people that deny easily verifiable facts.

You have written, at various times, at least half a dozen subtly
different functions called H_Hat. But that does not matter, because you
don't get to pick the confounding example, I do.

>> Your ruse -- to use one H_Hat and two different called functions
>> is simply dishonest.
>
> It is fricking fully operational code.

So what? It's still a ruse, and it's still the case that a sound
Needs_To_Be_Aborted function can't be written.

To be clear: the ruse is to say that the correct answer for the halting
status of a computation is to be determined by the behaviour of a
/different/ computation -- often shown using the same function names (to
add to the smoke and mirrors) -- but a different one none the less.

--
Ben.

[olcott]

Halts(Confound_Halts, Confound_Halts) returns false.

Clearly you have not been paying any attention at all.

I have shown the complete execution trace basis for Halts to correctly
decide any any all instances like your Confound_Halts, quite a few times
now. The best one is in the original post of this thread.

[dklei...@gmail.com]

I like to think of the tape as a pair of stacks plus a head. This does
provide a clear initial position. But without a specific position how
can one know which cell the initial cell under the head is? Are we
assuming that the tape is an array indexed by all integers?

[olcott]

I try to think of it as a list that has a first element.

[Mike Terry]

I rather doubt that. More likely you're confused about what code you're
talking about? Or /they/ are? If they are, the way out is to be
clearer about what you mean [some ideas below]

Hmm, ok I've gone back to the start of this thread, and sure enough
there's code there, and the trace in question. Here it is restored:

// Defined at the bottom of page 319 of Linz
void Ĥ(u32 P)
{
u32 Input_Halts = H(P, P);
if (!Input_Halts)

HALT
else
HERE: goto HERE;
}


int main()
{

u32 P = (u32)Ĥ;
H(P, P);
HALT;
}

Here H^ calls a function H, which isn't given in the trace. If you want
people to know that H is just a pure UTM, then given the history of all
your Hs, H_Hats, and renames etc. it would be sensible for you to choose
a completely new name like UTM().

Alternatively, if you really want to use H in this thread for a pure
UTM, then you should have GIANT WARNINGS all over the place.

But I don't think the H above is a UTM, because you refer in the same
post to "the halt decider detecting xxx" and in Linz the halt decide is
H. So a perfectly reasonable interpretation here is that this H is NOT
a UTM, and so is not the same as the code I previously commented on.

I also think there's a possibility that you really did intend it to be
just a UTM, but if so you've gone about it in an apalling way (not
intentionally). You have all the talk about halt deciders (which might
just refer to your OS wrapper code?) and Linz and H (the Linz decider)
when you could just have called it UTM. You also could have given a big
CAPS WARNING to make sure that people understood what was being
discussed, given the considerable potential for confusion.

If that is what you intended, I'd have to say I don't feel too sorry for
you, because you've chopped and changed your notations so many times,
and then introduced your overseeing "wrapper" halt decider to confuse
things. People are fatigued by all these changes, and there's often
little consistency across different threads etc...

BTW - I've had an idea for why you made your Halts() "global"! You
realised that it was really quite tricky to get your ABNHBD() to see
what was going on within your /nested/ levels of execution, and rather
than make it all work as it should you just thought you'd make the new
ABNHBD/Halts global, and change your OS interface so that it sees /all/
the emulation levels at once? Just a guess- doesn't really matter. If
that's right, you didn't really need to make it global to achieve that,
although you almost certainly would need to change your OS interface
calls to enable it.

>
> I am breaking it down into simpler steps stating here:
> Validating the halt deciding criteria with a totally concrete example
> --- Step(1)
>
>> I'm not being funny here, just literal, to help you see things from
>> others' perspectives. I could ask how you make a jump from repeating
>> twice to infinite recursion, but the point is /however/ you do it you
>
> By seeing the infinite recursion in the source code and by seeing the
> infinite recursion in the object code.

I don't believe anyone is interpreting your H source code in this thread
as pure UTM source code. I'm not even sure whether /you/ mean it to be
such?

IF YOU DO mean it to be a pure UTM, then the code would be non-halting
as previously agreed, and everybody else would also agree, if they
understood that is what you were saying.

If your H is a proper halt decider with recursion detection logic (which
is how I have interpretted things) then you really /cannot/ see the
infinite recursion in the object code. (Perhaps you think you can?)

Um, ok, now we're back to a recurring problem - I asked you whether you
believe that your INFINITE_RECURSION_TEST in your decider is only
detecting /actual/ infinite recursion in its inputs, and you STILL
haven't properly answered that yet. (You said, look in the new thread,
but there's no explanation there, so far at least.)

You did provide something only by implication in another post which
talked about 3+2=5 : the inference I got from that example is that you
DO believe that your test (checking for calls to the same address with
no intervening conditional branches) is "sound", but why you don't JUST
SAY THAT, and EXPLAIN WHY YOU BELIEVE IT, (or even /prove/ that it is
sound!!) is beyond me. I've been asking about this for weeks now, on
and off.

>
>> are not "just seeing it in the trace", right? So there is some
>> reasoning on your part which you are not sharing. Some "proof" even?
>> (Maybe you feel you /are/ sharing it, but I've not seen anything, and
>> you pointedly refuse to expand on this when I ask about it.)
>
> The exact same thing that you said is "baby stuff" So obvious that
> anyone knows it is true, they flat out deny as true.
>
> I am breaking it down into simpler steps stating here:
> Validating the halt deciding criteria with a totally concrete example
> --- Step(1)
>

If you really do mean your H in this thread to be specifically a pure
UTM, then it is probably best to abandon this thread and start again,
because I don't think it has been interpreted that way throughout the
thread. [And I wouldn't put any blame on this for readers of the thread.]

>> So to me it seems quite reasonable for someone else to deny that there
>> is infinite recursion based just on the basis of your trace - because
>> the trace really /doesn't/ show or even "imply" that there is infinite
>> recursion.
>
> This one leave zero doubt.
> Validating the halt deciding criteria with a totally concrete example
> --- Step(1)
>
> I still need to add a few more steps to prove my point, yet I must do
> them in micro increments because by reviewers (besides you) have less
> than zero interest in understanding me and focus all their attention on
> denigration.
>

The main thing I think is to be clear about what you're doing at each
step. I'd use UTM() [and doubly explain what that means] if you mean a
routine to be exactly a UTM with no added logic, rather than H.
(Probably it's too late for that.)

Mike.

[Mike Terry]

People would probably take that on trust, at least initially, up to the
point where some unexplainable problem points to a bug or other
"feature" of x86utm.

BTW, I'm assuming by x86utm, you mean just the UTM "emulation"
functionality, and you're not lumping any "decider" logic into
x86utm.exe itself. If you /are/ then who knows what that hidden decider
logic might be doing? And so there would be no proof (or even
"confidence building") from looking at traces that it is faithfully
simulating its input - because one input might come out ok, but some
other input might be "halt detected" and so interfered with.

> (2) H_Hat is infinitely recursive.
>

I don't think anyone would dispute that... (I don't dispute it, and I'm
"just this guy")

> (3) The infinite recursion of H_Hat can be analytically be determined in
> advance.

No, it *doesn't* prove that! All you have presented is a trace
involving infinite recursion. You need to say (and hopefully *prove*)
whatever it is about that trace that means the recursion can be
(soundly) determined in advance.

Actually, in THIS SPECIFIC EXAMPLE, it should be easy enough to specify
the criterion for analysing the trace! After all, what we have here is
a variation of tight-loop detection, which can be implemented soundly.
Even given this is the case, it does not imply the same for your "real"
halting detector code, which is after all not detecting tight loops due
to the involvement of emulation in the trace output.

>
> (4) If the simulator decides to stop simulating its input and return
> false this would be a correct not-halting decision on H_Hat.

:) For THIS SPECIFIC INPUT (H_Hat,H_Hat) yes.

But you should know by now that if you change DebugTrace() in the code
above, e.g. to return false, it is no longer THIS SPECIFIC INPUT
(H_Hat,H_Hat) any more. It will become SPECIFIC INPUT (H_Hat2,H_Hat2),
and that might or might not be halting, depending on the exact change...


Mike.

[olcott]

First I show them this code:

int DebugTrace(u32 N, u32 M)
{
return ((int(*)(int))N)(M);
}


void H_Hat(u32 P)
{
u32 Aborted = DebugTrace(P, P);
if (Aborted)

HALT
else
HERE: goto HERE;
}


int main()
{

u32 P = (u32)H_Hat;
DebugTrace(P, P);
HALT;
}

Anyone knowing C can tell that the above code is infinitely recursive.
Richard did agree to this yet was so sure of what I was going to say
next that he didn't want to hear it.

Next I tell them about the x86utm operating system version of
DebugTrace() that actually simulates the machine code of the COFF object
file output of the Microsoft C compiler compilation of the above code.

Everything else that you said must back up to this step right here to
this step.

(1) We have code that is obviously infinitely recursive immediately above.

(2) There is another version of DebugTrace() that for all practical
purposes <is> an x86 based UTM. It actually simulates the code of H_Hat
one machine instruction at a time.

The execution trace of the the above user code is identical between the
two vastly different versions of DebugTrace() proving that these two
versions are functionally equivalent.

We cannot proceed to step (3) until after we have perfect agreement with
step (2).

[olcott]

I don't have the decider code written yet. DebugTrace() has alway been
the name of this function since the beginning. The above version of
DebugTrace() was the first stub version of the actual code.

The next step is to provide very robust decoding of all of the x86
control flow instructions. Thankfully conditional branch is the easiest.

> If you /are/ then who knows what that hidden decider
> logic might be doing?  And so there would be no proof (or even
> "confidence building") from looking at traces that it is faithfully
> simulating its input - because one input might come out ok, but some
> other input might be "halt detected" and so interfered with.

If the execution trace of the user portion of the code executed by the
above white box version of DebugTrace() is identical to the black box
one this proves that the black box one only simulates. I verified this.

>> (2) H_Hat is infinitely recursive.
>>
> I don't think anyone would dispute that... (I don't dispute it, and I'm
> "just this guy")

You are the only one that agreed until I posted the white box version.

>> (3) The infinite recursion of H_Hat can be analytically be determined in
>> advance.
>
> No, it *doesn't* prove that!

So the above code is not infinitely recursive?
No sense proceeding beyond this point.

[Ben Bacarisse]

This is, of course, exactly the ruse he is trying to pull off. The H
that is a UTM gives H_Hat the behaviour that the H that is a decider
will "correctly" report. Being clear by giving the two Hs different
names would blow his cover.

I am trying to think that this is just PO being clumsy with notation and
ignorant of what a halting decider is, but I can't shake the feeling he
knows its nonsense. Could he really not know?

--
Ben.

[olcott]

There is no ruse. I have to break my presentation down into smaller steps.

Here is the new first step:
Does the following code specify infinite recursion?

int DebugTrace(u32 N, u32 M)
{
return ((int(*)(int))N)(M);
}


void H_Hat(u32 P)
{
u32 Aborted = DebugTrace(P, P);
if (Aborted)

HALT
else
HERE: goto HERE;
}


int main()
{

u32 P = (u32)H_Hat;
DebugTrace(P, P);
HALT;

[Richard Damon]

Interesting that you have posted what was claimed to be the results of
this decider that hasn't yet be finished. I guess that explains why its
results have been a bit contradictory.

>
> The next step is to provide very robust decoding of all of the x86
> control flow instructions. Thankfully conditional branch is the easiest.
>
>> If you /are/ then who knows what that hidden decider logic might be
>> doing?  And so there would be no proof (or even "confidence building")
>> from looking at traces that it is faithfully simulating its input -
>> because one input might come out ok, but some other input might be
>> "halt detected" and so interfered with.
>
> If the execution trace of the user portion of the code executed by the
> above white box version of DebugTrace() is identical to the black box
> one this proves that the black box one only simulates. I verified this.

Exept that Black Box testing can NEVER prove conclusively the totality
of behavior of the code in the black box. That is the nature of a black box.

>
>>> (2) H_Hat is infinitely recursive.
>>>
>> I don't think anyone would dispute that... (I don't dispute it, and
>> I'm "just this guy")
>
> You are the only one that agreed until I posted the white box version.
>
>>> (3) The infinite recursion of H_Hat can be analytically be determined in
>>> advance.
>>
>> No, it *doesn't* prove that! 
>
> So the above code is not infinitely recursive?
> No sense proceeding beyond this point.
>

Here is why the name H_Hat is bad. The name H_Hat has a global standard
meaning in this context, and we KNOW that to try to define a result to
this H_Hat that isn't really H_Hat is going to later be tried to be
imposed on an H_Hat that isn't this H_Hat.

Yes, for THIS particular H_Hat, it is clear that we have an infinte
recursion, based on BOTH the definition of H_Hat and Debug_Step.

[Richard Damon]

As I said, for some machines, the tape is single directional, with a
normal default of starting at the end.

For other cases, the tape is specified relative to the head. One way to
do this is to provide index numbers, another is to just list them with
an indicated (or implied) position for the head.
>

[Richard Damon]

At which point the if skips the while loop and the machine halts, so the
decider was wrong.

>
> Clearly you have not been paying any attention at all.

Clearly YOU haven't been.

[olcott]

Only because we change the question from:

Does the input halt on its input?

to
Must the input be aborted to prevent its otherwise infinite execution?

Are the key counter-examples of the HP proofs made halting decidable.

[Richard Damon]

But, as has been shown, this are truly exact opposites, at least if you
want your results to apply to the same thing as the conventional halting
problem. If you agree that you are working on a different question, and
thus your results do not apply to things based on the conventional
halting problem, go ahead and change it, so the the aborting of a
recursively nested version of the code allows you to decide that the
machine is 'need to be aborted'. Just remeber if you do, that you can't
claim any of this applies to the conventional halting problem or things
based on it.

[olcott]

A program that only halts if it is aborted has opposite halting behavior
to a program that halts without being aborted.

[Richard Damon]

Yes, a program that ONLY halts if it is aborted is the opposite of a
pogrmam that halts without being aborted.

A program that haltes because it was aborted is something very
different. It might have halted anyway if given more time.

The key words here are things like MUST and ONLY. Just because you come
up with some 'logical' justification that make it seems like it needs to
be. The REAL test is to actually run it and see. If the actual program
when run does halt, then the logic has been proved to be unsound.

Yes, proving a given computation is indeed non-halting can be difficult,
even impossible (otherwise we COULD have halting deciders), but very
many cases can be proven with a few simple rules. Things like repeating
state or loops with no way out (absolutely no way out, not even an OS
monetering them with the ability to abort them), so we can answer many
cases, and in particular, if we can find the halting behavior, we can
disprove the non-halting determination.
>

[olcott]

On 11/25/2020 6:39 AM, Richard Damon wrote:
> On 11/25/20 12:12 AM, olcott wrote:
>> On 11/24/2020 10:53 PM, Richard Damon wrote:
>>> On 11/24/20 11:43 PM, olcott wrote:
>
>>>> Only because we change the question from:
>>>>
>>>> Does the input halt on its input?
>>>>     to
>>>> Must the input be aborted to prevent its otherwise infinite execution?
>>>>
>>>> Are the key counter-examples of the HP proofs made halting decidable.
>>>>
>>>
>>> But, as has been shown, this are truly exact opposites,
>>
>> A program that only halts if it is aborted has opposite halting behavior
>> to a program that halts without being aborted.
>
> Yes, a program that ONLY halts if it is aborted is the opposite of a
> pogrmam that halts without being aborted.
>
> A program that haltes because it was aborted is something very
> different. It might have halted anyway if given more time.

There are a set of programs that can be determined in advance to never
halt. Here is one of them:

int main()
{
HERE: goto HERE;

}

> The key words here are things like MUST and ONLY. Just because you come
> up with some 'logical' justification that make it seems like it needs to
> be. The REAL test is to actually run it and see. If the actual program
> when run does halt, then the logic has been proved to be unsound.

There are a set of computations that can be determined in advance that
will never halt and this can be determined with 100% logical certainty.

> Yes, proving a given computation is indeed non-halting can be difficult,
> even impossible (otherwise we COULD have halting deciders), but very

This kind of pure speculation is no sort of counter-example proof of
undecidability.

> many cases can be proven with a few simple rules. Things like repeating
> state or loops with no way out (absolutely no way out, not even an OS
> monetering them with the ability to abort them), so we can answer many
> cases, and in particular, if we can find the halting behavior, we can
> disprove the non-halting determination.

[Richard Damon]

On 11/25/20 9:17 AM, olcott wrote:
> On 11/25/2020 6:39 AM, Richard Damon wrote:
>> On 11/25/20 12:12 AM, olcott wrote:
>>> On 11/24/2020 10:53 PM, Richard Damon wrote:
>>>> On 11/24/20 11:43 PM, olcott wrote:
>>
>>>>> Only because we change the question from:
>>>>>
>>>>> Does the input halt on its input?
>>>>>      to
>>>>> Must the input be aborted to prevent its otherwise infinite execution?
>>>>>
>>>>> Are the key counter-examples of the HP proofs made halting decidable.
>>>>>
>>>>
>>>> But, as has been shown, this are truly exact opposites,
>>>
>>> A program that only halts if it is aborted has opposite halting behavior
>>> to a program that halts without being aborted.
>>
>> Yes, a program that ONLY halts if it is aborted is the opposite of a
>> pogrmam that halts without being aborted.
>>
>> A program that haltes because it was aborted is something very
>> different. It might have halted anyway if given more time.
>
> There are a set of programs that can be determined in advance to never
> halt. Here is one of them:
>
> int main()
> {
>   HERE: goto HERE;
> }
>

Never denied that.

>> The key words here are things like MUST and ONLY. Just because you come
>> up with some 'logical' justification that make it seems like it needs to
>> be. The REAL test is to actually run it and see. If the actual program
>> when run does halt, then the logic has been proved to be unsound.
>
> There are a set of computations that can be determined in advance that
> will never halt and this can be determined with 100% logical certainty.
>

Never denied that, there is a set of computation that can be determined
in adanced that will never halt. That set might not include every
computation that WILL not halt. (in fact, because the halting problem
HAS been proved to be unsolvable, we know that there will be members in
the set of non-halting computations that can not be proven to be
non-halting).

>> Yes, proving a given computation is indeed non-halting can be difficult,
>> even impossible (otherwise we COULD have halting deciders), but very
>
> This kind of pure speculation is no sort of counter-example proof of
> undecidability.

Until you can PROVE that you can decide EVERY case correctly, you don't
have ground to stand on. I can stand on the grounds of Linz (and
others_, and say the statement is proven.

Since we have a case that your machine still does not decide correctly,
by the criteria of the classical halting problem, which by your
arguments, you seem to be working on, you counter proof is disproved.

The traces you have provided, in part because they are only partial
since you haven't finished, show one of two failures. Either you fail by
failing to proved the answer to the computation asking for it, or you
fail by giving it the wrong answer (you say it will be non-halting when
it actually halts).

As I have said many times before, if you CLEARLY state that you admit to
be working on a different problem, and that therefore your results are
not applicable to the classical halting problem or the theories based on
it, then we can look at your alternate definition.

[olcott]

(1)I did correctly show how to decide halting for the x86utm
computational equivalent of a simplified form of the Linz Ĥ.

(2) This simplified form of the Linz H_Hat is the basis for all of the
conventional halting problem proofs.

∴ I have proved that none of these conventional proofs (including Linz)
have any basis for their conclusion.

void H_Hat(u32 P)
{
u32 Aborted = DebugTrace(P, P);
if (Aborted)

HALT
else
HERE: goto HERE;
}

All of the current rebuttals take the form that because Halts() does
correct decide its input and it is common knowledge that this is
impossible therefore Halts must be incorrect.

>>> Yes, proving a given computation is indeed non-halting can be difficult,
>>> even impossible (otherwise we COULD have halting deciders), but very
>>
>> This kind of pure speculation is no sort of counter-example proof of
>> undecidability.
>
> Until you can PROVE that you can decide EVERY case correctly, you don't
> have ground to stand on. I can stand on the grounds of Linz (and
> others_, and say the statement is proven.

Yes if you ignore the verified fact that the above code is decided
correctly you can bury your head in the sand and say that Linz still
applies.

> Since we have a case that your machine still does not decide correctly,
> by the criteria of the classical halting problem, which by your
> arguments, you seem to be working on, you counter proof is disproved.

We have no such case. You said that Halts must be wrong BECAUSE it gets
the correct answer.

> The traces you have provided, in part because they are only partial
> since you haven't finished, show one of two failures. Either you fail by
> failing to proved the answer to the computation asking for it,

Simply ignoring my rebuttals is not any actual rebuttal at all, you seem
to thinks that it is. I have asked you this at least three times and and
you simply ignore my question.


What return value does H_Hat() receive from DebugTrace() ?
What return value does H_Hat() receive from DebugTrace() ?
What return value does H_Hat() receive from DebugTrace() ?
What return value does H_Hat() receive from DebugTrace() ?
What return value does H_Hat() receive from DebugTrace() ?
What return value does H_Hat() receive from DebugTrace() ?
What return value does H_Hat() receive from DebugTrace() ?
What return value does H_Hat() receive from DebugTrace() ?
What return value does H_Hat() receive from DebugTrace() ?
What return value does H_Hat() receive from DebugTrace() ?

int DebugTrace(u32 N, u32 M)
{
return ((int(*)(int))N)(M);

return 1;

}


void H_Hat(u32 P)
{
u32 Aborted = DebugTrace(P, P);
if (Aborted)

HALT
else
HERE: goto HERE;
}


int main()
{

u32 P = (u32)H_Hat;
DebugTrace(P, P);
HALT;

[Mike Terry]

On 23/11/2020 19:00, olcott wrote:
> On 11/23/2020 12:47 PM, Mike Terry wrote:
>> On 23/11/2020 17:37, olcott wrote:
>>> On 11/23/2020 11:07 AM, Mike Terry wrote:
>>>> On 23/11/2020 03:33, olcott wrote:
>>>>> On 11/22/2020 9:14 PM, Ben Bacarisse wrote:
>>>>>> Richard Damon <Ric...@Damon-Family.org> writes:
>>>>>>
>>>>>>> Maybe you have created a system that is a Halter, which will just
>>>>>>> abort
>>>>>>> any program that it determines will never halt. That might have some
>>>>>>> use, but isn't the Halt Decider from Linz.
>>>>>>
>>>>>> The irony is that that algorith -- the algorithm that determines if a
>>>>>> computation must be aborted -- is also impossible. He's not written
>>>>>> it > yet
>>>>>
>>>>> IT IS IN THE FIRST POST OF THIS THREAD.
>>>>> This is my 2018-12-13 solution.
>>>>>
>>>>> We merely scan the complete execution trace after each instruction is
>>>>> executed and see if there have been any function calls to the same
>>>>> function from the same address without any intervening conditional
>>>>> branch instructions.
>>>>>
>>>>> Here is what Mike said about correctly deciding H_Hat:
>>>>>
>>>>> On 11/20/2020 9:30 PM, Mike Terry wrote:
>>>>>> input (H_Hat,H_Hat) is non-halting, assuming your Halts() is as
>>>>>> described. This is all baby stuff. [So the correct halting decision
>>>>>> for the input is non-halting].
>>>>
>>>>
>>>> STOP QUOTING ME OUT OF CONTEXT.
>>>>
>>>> THE H_Hat OF THE POST TO WHICH YOU REFER IS A *COMPLETELY DIFFERENT*
>>>> H_Hat TO THE ONE IN THIS THREAD. You are misrepresenting my position
>>>> to falsely support your own.
>>>
>>> The two versions of H_Hat are computationally equivalent, thus your
>>> claim that they are *COMPLETELY DIFFERENT* is proved to be false.
>>>
>>> Here is the one that you responded to:

>>> On Friday, November 20, 2020 at 8:45:59 PM UTC-6, olcott wrote:
>>> void H_Hat(u32 P)
>>> {

>>> u32 Aborted = Halts(P, P);

>>> if (Aborted)
>>> HALT
>>> else
>>> HERE: goto HERE;
>>> }
>>>
>>>
>>> int main()
>>> {
>>> u32 P = (u32)H_Hat;

>>> Halts(P, P);
>>> HALT;
>>> }
>>> https://groups.google.com/g/comp.theory/c/1uKuMgjxJTM/m/c3HEt-UWAAAJ
>>
>> Ahem, you've "conveniently" omitted the important context of the
>> original thread. Let me restore it for you:
>
> This above link IS THE WHOLE MESSAGE NO DETAILS ARE MISSING.

Wrong. There is stuff which was in earlier posts that had been snipped
in earlier posts. If you'd read a few lines further in my post it is
perfectly clear what I was saying.

You're just being obstructive here.

Mike.

[Mike Terry]

On 24/11/2020 15:41, Mike Terry wrote:
> On 24/11/2020 04:18, olcott wrote:

<.. snip ..>
>>
>> People can eventually look at all of my code and the thousands of lines
>> of code of the x86 emulator and they can look at the hundreds of pages
>> out output. It all boils down to this:
>>
>> The simulator merely watches its simulation of the following
>> instructions until it sees a function call to 377 from 503 the second
>> time with no JCC (Jump-Condition_Code) in-between.
>>
>
> I have told you many times that your test must be UNSOUND. You have
> never responded to this, so I've assumed you don't really know whether
> your test is sound or unsound (or probably, what that even means,
> although I've also explained that to you before).
>
> Now you are getting closer to actually coding the test (which you
> claimed to have "fully coded" two years ago), you are finally giving
> more details.
>
> So... what do you think. Is the following test a SOUND test for
> non-halting?
>
> TEST: "monitor the simulation until there is a function
> call to 377 from 503 a second time, with no conditional
> branch inbetween"
>
> Putting it more directly - if some calculation P(I) triggers the TEST
> (so it contains two calls from 377 from 503, with no conditional branch
> inbetween), does this genuinely imply that the calculation will never halt?
>
> Bear in mind that the two calls in question do not necessarily occur in
> the same "virtual address space", that is to say the two calls can [and
> in the case of T_Hat(T_Hat) *do* ] occur at /different levels of
> emulation/. [Your trace notation obscures this simple fact, making
> everything appear to be in one single virtual process, when it's not.]
>
> What do you think? This seems to be your primary intuition that
> triggered all this "refuting" activity, BUT IS IT ACTUALLY CORRECT?
>
> Of course, you will say "All my intuitions are correct by definition -
> I'm never wrong" but that doesn't make it true! :)
>
> Is TEST *SOUND* ?
>

Noted: still no response to this basic question.

Mike.

[olcott]

Here is the full context by direct cut-and-paste:

On 11/24/2020 8:04 PM, Mike Terry wrote:
> On 24/11/2020 20:44, olcott wrote:

>> int DebugTrace(u32 N, u32 M)
>> {
>> return ((int(*)(int))N)(M);
>> }
>>
>>

>> void H_Hat(u32 P)
>> {
>> u32 Aborted = DebugTrace(P, P);

>> if (Aborted)
>> HALT
>> else
>> HERE: goto HERE;
>> }
>>
>>
>> int main()
>> {
>> u32 P = (u32)H_Hat;

>> DebugTrace(P, P);
>> HALT;
>> }
>>
>>
>> This proves the following:

>> (2) H_Hat is infinitely recursive.
>>
> I don't think anyone would dispute that...
> (I don't dispute it, and I'm "just this guy")
>

>> (3) The infinite recursion of H_Hat can be analytically
>> be determined in advance.
>
> No, it *doesn't* prove that!