Halting Problem proof refutation is a tautology thus irrefutable

[olcott]

computation that halts … the Turing machine will halt whenever it enters
a final state. (Linz:1990:234)

A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior of these actual inputs.

When a simulating halt decider rejects all inputs as non-halting
whenever it correctly detects [in a finite number of steps] that its
correct and complete simulation of its input would never reach [a] final
state of this input then all [these] inputs (including pathological
inputs) are decided correctly.

*The above three sentences form a tautology that is proven to be true
entirely on the basis of the meaning of their words*

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


--
Copyright 2022 Pete Olcott

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

[Mr Flibble]

On Sun, 19 Jun 2022 10:13:00 -0500
olcott <No...@NoWhere.com> wrote:

> computation that halts … the Turing machine will halt whenever it
> enters a final state. (Linz:1990:234)
>
> A halt decider must compute the mapping from its inputs to an accept
> or reject state on the basis of the actual behavior of these actual
> inputs.
>
> When a simulating halt decider rejects all inputs as non-halting
> whenever it correctly detects [in a finite number of steps] that its
> correct and complete simulation of its input would never reach [a]
> final state of this input then all [these] inputs (including
> pathological inputs) are decided correctly.

void Px(u32 x)
{
H(x, x);
return;
}

int main()
{
Output("Input_Halts = ", H((u32)Px, (u32)Px));
}

...[000013e8][00102357][00000000] 83c408 add esp,+08
...[000013eb][00102353][00000000] 50 push eax
...[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
...[000013f6][00102357][00000000] 83c408 add esp,+08
...[000013f9][00102357][00000000] 33c0 xor eax,eax
...[000013fb][0010235b][00100000] 5d pop ebp
...[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)

It gets the answer wrong, i.e. input has not been decided correctly.
QED.

/Flibble

[olcott]

_P()
[000010fa](01) 55 push ebp
[000010fb](02) 8bec mov ebp,esp
[000010fd](03) 8b4508 mov eax,[ebp+08]
[00001100](01) 50 push eax // push P
[00001101](03) 8b4d08 mov ecx,[ebp+08]
[00001104](01) 51 push ecx // push P
[00001105](05) e800feffff call 00000f0a // call H
[0000110a](03) 83c408 add esp,+08
[0000110d](02) 85c0 test eax,eax
[0000110f](02) 7402 jz 00001113
[00001111](02) ebfe jmp 00001111
[00001113](01) 5d pop ebp
[00001114](01) c3 ret
Size in bytes:(0027) [00001114]

Begin Simulation Execution Trace Stored at:211ee2
...[000010da][00211ece][00211ed2] 55 push ebp
...[000010db][00211ece][00211ed2] 8bec mov ebp,esp
...[000010dd][00211ece][00211ed2] 8b4508 mov eax,[ebp+08]
...[000010e0][00211eca][000010da] 50 push eax // push P
...[000010e1][00211eca][000010da] 8b4d08 mov ecx,[ebp+08]
...[000010e4][00211ec6][000010da] 51 push ecx // push P
...[000010e5][00211ec2][000010ea] e820feffff call 00000f0a // call H
Infinitely Recursive Simulation Detected Simulation Stopped

*All technically competent software engineers* will see that when H
bases its halt status decision on whether or not its complete and
correct x86 emulation of its input would ever reach the "ret"
instruction of this input that H is correct to reject this input.

[olcott]

On 6/19/2022 10:54 AM, Mikko wrote:

> On 2022-06-19 15:13:00 +0000, olcott said:
>
>> computation that halts … the Turing machine will halt whenever it
>> enters a final state. (Linz:1990:234)
>

> This definition is incomplete. Therefore your refutation does not
> apply to Linz' proof.
>
> Mikko
>

It will halt whenever it reaches final state means
if and only if it reaches its final state it halts.

[Mr Flibble]

[olcott]

[Richard Damon]

On 6/19/22 11:13 AM, olcott wrote:
> computation that halts … the Turing machine will halt whenever it enters
> a final state. (Linz:1990:234)
>
> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior of these actual inputs.

And the call H(P,P) must be asking about the actual behavior of P(P) or
your P isn't built by the actual requirements of the Linz prrof.

>
> When a simulating halt decider rejects all inputs as non-halting
> whenever it correctly detects [in a finite number of steps] that its
> correct and complete simulation of its input would never reach [a] final
> state of this input then all [these] inputs (including pathological
> inputs) are decided correctly.

Except the decision needs to be CORRECT, based on what a CORRECT
simulation would do, which BY DEFINITION, matches the behaivor of the
program that it represents.

>
> *The above three sentences form a tautology that is proven to be true
> entirely on the basis of the meaning of their words*

Except that you never actually meet the requirements of its premises.

Since there does not exist a finite pattern in the execution trace of
P(P) that the H(P,P) that it uses can have that actually shows
non-halting behavior, as any pattern that is put into that H that
appears in the execution of P(P) causes that H(P,P) to return 0 to its
calling P(P) which makes that, and thus ALL, P(P)s halt.

[Richard Damon]

So, does it do a complete and correct emulation (and thus never aborts
so never returns the value 0) or does it not do a complete and correct
emulation so it can return 0 and thus has no true premise to base its
logic on.

Your arguement makes the flaw of assuming an impossible condition, that
H CAN do both a correct and complete emulation and at the same time
return the value 0.

Either you need to do infinite work in finite time or you are doing
something incorrectly and have unsound logic.

FAIL.

[Richard Damon]

On 6/19/22 12:23 PM, olcott wrote:

> *All technically competent software engineers*
>

Which means you are excluding yourself.

[Richard Damon]

On 6/19/22 11:59 AM, olcott wrote:
> On 6/19/2022 10:54 AM, Mikko wrote:
>> On 2022-06-19 15:13:00 +0000, olcott said:
>>
>>> computation that halts … the Turing machine will halt whenever it
>>> enters a final state. (Linz:1990:234)
>>
>> This definition is incomplete. Therefore your refutation does not
>> apply to Linz' proof.
>>
>> Mikko
>>
>
> It will halt whenever it reaches final state means
> if and only if it reaches its final state it halts.
>

But it needs to also include the fact that non-halting means that it
never reaches the final state without running for an unbounded number of
steps.

The definition as quoted presumes that nothing "pauses or stops" the
execution of the Turing Machine.

[Mr Flibble]

On Sun, 19 Jun 2022 11:23:24 -0500

[olcott]

Because it is an easily verified fact that the correct and complete x86
emulation of the input to H(P,P) by H would never reach the "ret"
instruction of P and this is the criterion measure for H to reject its
input how do you figure that H gets the wrong answer?

What I am saying is a logical tautology the same as when we know that X
is a black cat then we know that X is a cat.

[Richard Damon]

No, your "proof" of this is based on the assumption that H itself does a
complete and correct emulation of its input. SInce it doesn't if it
returns 0 from H(P,P), that proof doesn't apply.

Your logic is unsound.

You have an impossible to meet definition of an algorithm to put into H,
so it doesn't actually exist.

[Mr Flibble]

On Sun, 19 Jun 2022 12:16:05 -0500

We are talking about Px, not P. We are talking about your H not
analysing what its input actually does and instead assuming that an
input that calls H is always pathological.

[olcott]

DO YOU AGREE WITH THIS?
H(Px,Px) does correctly determine that the complete and correct x86
emulation of its input would never reach the "ret" instruction of Px.

[olcott]

On 6/19/2022 12:35 PM, Mikko wrote:

> On 2022-06-19 15:59:55 +0000, olcott said:
>
>> On 6/19/2022 10:54 AM, Mikko wrote:
>>> On 2022-06-19 15:13:00 +0000, olcott said:
>>>
>>>> computation that halts … the Turing machine will halt whenever it
>>>> enters a final state. (Linz:1990:234)
>>>
>>> This definition is incomplete. Therefore your refutation does not
>>> apply to Linz' proof.
>>>
>>> Mikko
>>>
>>
>> It will halt whenever it reaches final state means
>> if and only if it reaches its final state it halts.
>

> Dosn't matter if you can't write a publishable proof.
>
> Mikko
>

The code <is> the proof.

[Richard Damon]

That is only true if H never returns ANY answer (and thus fails to be a
decider).

If H aborts its emulation and returns an answer, then the right answer
would be 1.

This case is NOT pathological, and if you assume that H can detect
recursion to itself, can actually be solved, so not pathological.

[Richard Damon]

On 6/19/22 2:09 PM, olcott wrote:
> On 6/19/2022 12:35 PM, Mikko wrote:
>> On 2022-06-19 15:59:55 +0000, olcott said:
>>
>>> On 6/19/2022 10:54 AM, Mikko wrote:
>>>> On 2022-06-19 15:13:00 +0000, olcott said:
>>>>
>>>>> computation that halts … the Turing machine will halt whenever it
>>>>> enters a final state. (Linz:1990:234)
>>>>
>>>> This definition is incomplete. Therefore your refutation does not
>>>> apply to Linz' proof.
>>>>
>>>> Mikko
>>>>
>>>
>>> It will halt whenever it reaches final state means
>>> if and only if it reaches its final state it halts.
>>
>> Dosn't matter if you can't write a publishable proof.
>>
>> Mikko
>>
>
> The code <is> the proof.
>

WHAT code? You haven't shown any code that does the magic you claim.

You last code sample hide the magic halt detection in a function that
wasn't shown, just described as detecting the mythical halting pattern
that exists in P(P) that actually correctly detects that it doesn't
halt, even if H(P,P) return the 0 to it which causes it to halt.

[olcott]

Competent software engineers will understand that when the behavior of
Px matches this pattern that correct and complete x86 emulation of the
input to H(Px,Px) by H would never reach the "ret" instruction of Px:

H knows its own machine address and on this basis:
(a) H recognizes that Px is calling H with the same arguments that H was
called with.
(b) There are no instructions in Px that could possibly escape this
infinitely recursive emulation.
(c) H aborts its emulation of Px before Px its call to H is invoked.

[Richard Damon]

Only if H never aborts. If H does abort, then Px(Px), whose behavior
exactly matches the CORRECT emulation of the input to H(Px,Px) BY
DEFINITION shows this.

You just don't understand what you are saying, showing that you are NOT
a "Competent Software Engineer" I guess.

Sorry Charlie, we only really want the Truth, and that is truth that
matches the actual definitions.

H(M,x) needs to accept this input if M(x) Halts, and Reject if M(x)
never halts.

If you H(Px,Px) creates a non-halting input then that means that
H(Px,Px) never returned an answer, so failed to meet the definition.

If H(Px,Px) returned ANY answer, then by simple inspection we can see
that Px(Px) will Halt.

Thus, H is incorrect in returning a 0 value, just as it would be
incorrect to not return any value, so, you method is shown to fail for
this case.

Possible causes are H isn't actually a computation and thus behaves
differently for the same input in different environments, or H is just
not correct in its logic.

FAIL.

[olcott]

The question is: Would (future tense) the complete and correct x86
emulation of the input to H(Px,Px) by H ever reach the "ret" instruction
of Px.

You always change this question to a different question:

Does (present tense) the complete and correct x86 emulation of the input
to H(Px,Px) by H ever reach the "ret" instruction of Px.

A straw man (sometimes written as strawman) is a form of argument and an
informal fallacy of having the impression of refuting an argument,
whereas the real subject of the argument was not addressed or refuted,
but instead replaced with a false one.
https://en.wikipedia.org/wiki/Straw_man

[olcott]

The question is: Would (future tense) the complete and correct x86
emulation of the input to H(Px,Px) by H ever reach the "ret" instruction
of Px?

You always change this question to a different question:

Does (present tense) the complete and correct x86 emulation of the input
to H(Px,Px) by H ever reach the "ret" instruction of Px?

or

Does (present tense) the correct (and incomplete) x86 emulation of the
input to H(Px,Px) by H ever stop running?

A straw man (sometimes written as strawman) is a form of argument and an
informal fallacy of having the impression of refuting an argument,
whereas the real subject of the argument was not addressed or refuted,
but instead replaced with a false one.
https://en.wikipedia.org/wiki/Straw_man

[Mr Flibble]

On Sun, 19 Jun 2022 14:17:42 -0500

The complete and correct x86 emulation of the input to H(Px, Px) should
be to allow Px to halt, which is what Px is defined to do:

void Px(u32 x)
{
H(x, x);

return; // Px always halts, ignoring whatever H does
}

An emulated Px should behave the same as if Px was run directly (i.e.
not from a decider).

Your H simply cannot handle this case thus does not qualify as a
decider. The infinite recursion is a problem with your approach of
using an emulator for H and not a problem with Px itself.

/Flibble

[olcott]

You are doing the same thing Richard is doing, getting at least one
word of what I am saying incorrectly and then rebutting the incorrect
paraphrase. This is the strawman error.

The complete and correct x86 emulation of the input to H(Px, Px)

BY H
BY H
BY H
BY H
BY H

cannot possibly contradict the easily verified fact that Px would never
reach its "ret" instruction. This seems to be beyond your ordinary
software engineering technical competence.

[Mr Flibble]

On Sun, 19 Jun 2022 15:05:11 -0500

Px is defined to always halt; your H gets the answer wrong saying Px
doesn't halt. QED.

/Flibble

[olcott]

Every technically competent software engineer can easily confirm that
the correct and complete x86 emulation of the input to H(Px,Px) by H
would never reach the "ret" instruction of Px.

That you can not understand this proves that you are not a sufficiently
technically competent software engineer on this point. Very good COBOL
programmers might never be able to understand this.

To anyone that writes or maintains operating systems what I am claiming
would be as easy to verify as first grade arithmetic.

[Richard Damon]

What "Future Tense". Given a defined computation, there IS, as is there
exists, a correct and complete emulation result. That result is created
INSTANTLY thd moment teh computation is defined. (whether it existed
before we defined the machine gets into metaphysics). Nothing needs to
happen to determine this, it just exists. This is the nature of truths,
they just are.

Note, we might not have KNOWLEDGE of the result, and need to compute it
to know it, but the actual answer existed.

Are you saying we aren't allowed to FIRST do the emulation and then ask
H for its opinion? And isn't your arguement that H needs to first
determine this behavior to make its answer, so if anything, the
emulation behavior would be PAST tense, except that for these cases,
because the behavior needs the answer from H to be determined, all the
time collapses into the present.

You seem to have a mistaken idea that we need to actually perform in
some mechanical way a computation for it to have an answer. We need to
do the computation to KNOW the answer, but the exact value exists as
soon as it is defined.


And, the answer to your question, does the complete and correct x86
emulation of the input to H(Px,Px) ever reach the "ret: instruction, the
exact answer is if H(Px,Px) would return a value in finite steps, then
Px(Px) will Halt. If H(Px,Px) never returns a value then Px(Px) will not
halt.

This is because a correct and complete emulation of an input to a Halt
Decideer is only defined in terms of the machine the input represents.

>
> You always change this question to a different question:
>
> Does (present tense) the complete and correct x86 emulation of the input
> to H(Px,Px) by H ever reach the "ret" instruction of Px.

Because there is not tempral aspect to make it future!

>
> A straw man (sometimes written as strawman) is a form of argument and an
> informal fallacy of having the impression of refuting an argument,
> whereas the real subject of the argument was not addressed or refuted,
> but instead replaced with a false one.
> https://en.wikipedia.org/wiki/Straw_man
>

Right, and you are the master of that. As I said, what need is there for
there to be a "future tense", the answer existed as soon as the machine
in question was defined, if not before.

[Richard Damon]

So, you are admitting that you are not working on the Halting Problem?
as that wording isn't part of the definition of the Halting Problem?

Are you also requiring your H to DO a complete and correct x86 emulation?

If so, then it can NEVER correctly return a 0 in finite time as for it
to do a complete and correct emulation of a non-halting computation, it
must perform an infinite number of steps to get the result. Unless you
have a method to do a infinite number of steps in a finite number of
operations, this is impossible.

Thus, your H violates your own definitions, and thus an H by your
definiton doens't actually exist.

FAIL.

[Richard Damon]

Nope, no temporalality in the problem, there is no before or after.

>
> You always change this question to a different question:
>
> Does (present tense) the complete and correct x86 emulation of the input
> to H(Px,Px) by H ever reach the "ret" instruction of Px?
>
> or
>
> Does (present tense) the correct (and incomplete) x86 emulation of the
> input to H(Px,Px) by H ever stop running?
>
> A straw man (sometimes written as strawman) is a form of argument and an
> informal fallacy of having the impression of refuting an argument,
> whereas the real subject of the argument was not addressed or refuted,
> but instead replaced with a false one.
> https://en.wikipedia.org/wiki/Straw_man
>

So, are you saying that Px(Px) right NOW halts, but in the future doesn't?

That means H(Px,Px) changes its answer over time!!

That makes it NOT a computation, or even a Pure Function (as it must
have time as an extra input).

FAIL.

[Mr Flibble]

On Sun, 19 Jun 2022 15:16:05 -0500

[olcott]

A halt decider must always correctly determine whether or not its input
WOULD halt. If halt deciders reported what the behavior of its input
DOES then like you said it would never report on non halting inputs.

All non-simulating halt deciders can only report on what their input
WOULD do and not what their input DOES because non-simulating halt
deciders are static rather than dynamic analyzers.

[olcott]

Get an operating system programmer to explain to you that the correct

and complete x86 emulation of the input to H(Px,Px) by H would never

reach the "ret" instruction of Px. *This is totally over your head*

It is like I am saying that we know that black carts are cats and you
disagree saying the a black cat might be some kind of dog.

My whole system is now wrapped in 131K zip file as a Visual Studio
project on a downloadable link.

[Richard Damon]

Would only in the sense of condition of testing, not time.

You seem to be stuck on misunderstandings of the English Language.

Once you define a Turing Macine, its mapping for all inputs is instantly
established as fact, but not knowledge (until we actually run it).

From the definition of the Turing Machine, and the finite string of the
input, its behavior with that input IS defined and fixed. It DOES either
Halt or Not on that input.

Please read the definition you like to quote:

computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)

What is the tense of this sentence.

"Enters" is a present tense.

The "Will" isn't future tense, but determinism, perhaps you don't
understnad that.

Water will freeze when cooled below the freezing point. This doesn't
mean only the future, but that it always has and always will do that.

Turing Machines WILL Halt, there is no question about it, when its
execution sequence reaches a final state. This isn't saying only in the
future, because machines previously run halted when they reached their
final state.

Note, "Time" isn't a factor for a Turing Machine or a Computation
(unless "Time" was a defined input to the machine).

The instructions happen in sequence, so there is a sense of before and
after with respect to steps to each other, but those steps have no
temporal connection to anything outside that machine, as nothing outside
that machine will affect it, so we have nothing to establish a time
reference to it.

[olcott]

Halt deciders must always predict what their non-halting inputs would do
in the future if they were executed.

They can never report on the non-halting behavior of what their inputs
did do in the past.

You have been confused about this for your last 1000 messages.

[Richard Damon]

No, maybe you need an actual programmer to look at your logic.

First, by definition correct emulation of a program will match the
behavior of the program.

We KNOW that Px(x) will halt if H(x,x) returns anything.

Thus Px(Px) will halt if H(Px, Px) returns an answer.

Since H is defined to be a decider, that means it ALWAYS returns an
answer for all inputs, and thus Px(x) is defined to always halt (at
least as long as H meets its requirements).

The ONLY time Px(Px) fails to Halt is if H(Px,Px) fails to return an
answer. The idea of looking at the actualy defined behavior of the
functions you call seems beyond you.

[olcott]

When you disagree with this precisely stated verified fact you are
either a liar or incompetent:

the correct and complete x86 emulation of the input to H(Px,Px) by H
would never reach the "ret" instruction

When you disagree the the above precisely stated verified fact by
changing its words and showing that the changed words are not true then
between liar and incompetent you prove to be a liar.

[Mr Flibble]

On Sun, 19 Jun 2022 16:17:20 -0500

[Richard Damon]

Why?

There is no actual requirement to execute the machine, only know what
would happen if at some point we did do that execution either in the
past or the future.

>
> They can never report on the non-halting behavior of what their inputs
> did do in the past.

Why not? Does it change? In fact, doesn't your halt decider work on
emulating its input, and if it sees it halt report that. That halting
happened BEFORE H gave its answer.

>
> You have been confused about this for your last 1000 messages.
>

No, you are.

Which happened first, did 3+4 become equal to 7 before or after 2+5
became equal to 7

Mathematical facts are not temporal, so don't change over time, so
placing when they "happened" in time is non-sense.

Specific events, that depend on others may have "Order", but that isn't
the same as past and future to us.

[olcott]

DOES THAT MEAN THAT YOU ARE SAYING THAT THIS IS FALSE?

the correct and complete x86 emulation of the input to H(Px,Px) by H
would never reach the "ret" instruction

[Richard Damon]

When did you verify this statment for an H that returns 0?

You only show your logic that if H doesn't abort its emulation, the
result is non-halting. With that condition, H can't return a 0, so your
logic becomes unsound.

Yes, if H is constructed to not abort is simulation of the input to
H(Px,Px), the H WOULD HAVE BEEN (as a hypothetical conditional, not
future tense) correct to return a 0, but only because it in fact didn't.

Better stated, the correct answer for that case is 0, but H doesn't give
it, so is incorret.

IF H DOES return 0, then that answer is incorrect, because such an H
doesn't do a correct and complete emulation, so we can't use your broken
definition, but need to fall back to the original where we actually DO a
correct and complete emulation, and we see that this will Halt, thus the
0 answer is WRONG>

>
> When you disagree the the above precisely stated verified fact by
> changing its words and showing that the changed words are not true then
> between liar and incompetent you prove to be a liar.
>
>

WHAT verified facts? You don't even remember what you actually proved so
you don't use the facts correctly and thus fill your rhetorica;
"arguments" with unsound logic.

[olcott]

If they are simulating halt deciders they can
never report on
never report on
never report on
never report on

never report on

the non-halting behavior

the non-halting behavior
the non-halting behavior
the non-halting behavior

the non-halting behavior

of what their inputs did do in the past
of what their inputs did do in the past
of what their inputs did do in the past
of what their inputs did do in the past
of what their inputs did do in the past

Because as you have said 1000 times they would be
stuck simulating this non-halting input forever.

If they are not simulating halt deciders they can
never report on
never report on
never report on
never report on

never report on

the non-halting behavior

the non-halting behavior
the non-halting behavior
the non-halting behavior
the non-halting behavior

Because they are not even examining behavior they are
only static analyzers that do not look at dynamic behavior.

Therefore halt deciders can never report on the non-halting behavior of

what their inputs did do in the past.

Therefore halt deciders can never report on the non-halting behavior of

what their inputs did do in the past.

Therefore halt deciders can never report on the non-halting behavior of

what their inputs did do in the past.

Therefore halt deciders can never report on the non-halting behavior of

what their inputs did do in the past.

Therefore halt deciders can never report on the non-halting behavior of

what their inputs did do in the past.

[Richard Damon]

What he is pointing out is that your statement is nonsense, as if H
returns 0 it didn't do a correct and complete x86 emulation.

You can't have H do BOTH a correct and complete x86 emulation and return
0 at the same "time". One H can't do both unless you know how to do
infinite work in finite time.

[olcott]

When X is a cat then we know that X is an animal.
What if X is a white cat?

the correct and complete x86 emulation of the input to H(Px,Px) by H
would never reach the "ret" instruction

This is a truism thus remains true under all possible conditions.

[Mr Flibble]

On Sun, 19 Jun 2022 16:23:17 -0500

What I am saying is the following, no more, no less:

[Richard Damon]

Right, IF H actually does a correct and complete x86 emulation.

When H aborts to return 0, then H doesn't do a correct and complete x86
emualtion, and by your rule has nothing to show that it was correct.

>
> This is a truism thus remains true under all possible conditions.
>

Only in your mind. It is only a truism IF H actually does what you claim
H does, which means it can't abort its simulation and return 0.

You are creating your own liar's paradox, and are stuck in it.

Does H actually do a correct and complete emulation, if so, it can't
abort its simulation and return 0. If it aborts and returns 0, it didn't
do the correct and complete emulation it (falsesly) assumed that it
does, and thus it has used unsound logic.

H either uses UNSOUND logic or isn't a compution, either way you are
lying with yoru claims.

[Richard Damon]

Regressing back to a two year old again I see.

Why can't H report on the behavior of what its input represents did in
the past? Does it somehow change?

You are just showing that you don't understand a thing that you are
talking about.

The ultimate thing that Deciders decide on are mathemematical truths.

These are non-temporal, so time doesn't matter.

That you think it does just says you are totally in the wrong domain of
thinking.

[André G. Isaak]

On 2022-06-19 14:43, olcott wrote:

> My whole system is now wrapped in 131K zip file as a Visual Studio
> project on a downloadable link.

I see no link anywhere.

André

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

[Mr Flibble]

On Sun, 19 Jun 2022 16:02:51 -0600
André G. Isaak <agi...@gm.invalid> wrote:

> On 2022-06-19 14:43, olcott wrote:
>
> > My whole system is now wrapped in 131K zip file as a Visual Studio
> > project on a downloadable link.
>
> I see no link anywhere.

We no longer need to see his source to know what he's got is invalid as
it cannot handle the following case correctly:

[olcott]

You are not committing to a criterion measure of correctness thus your
claim is vague.

[olcott]

On 6/19/2022 5:02 PM, André G. Isaak wrote:
> On 2022-06-19 14:43, olcott wrote:
>
>> My whole system is now wrapped in 131K zip file as a Visual Studio
>> project on a downloadable link.
>
> I see no link anywhere.
>
> André
>

Are you sure maybe you didn't look hard enough?
Maybe there is an invisible link between "131K" and "zip"

[Mr Flibble]

On Sun, 19 Jun 2022 17:16:03 -0500

Vague? My "claim" is crystal clear: Px should ALWAYS HALT and your H
decides that it is non-halting.

/Flibble

[olcott]

That I have to tell you the same thing hundreds and hundreds of times
before you notice that I said it once is best handled by plonking you.

>
> Why can't H report on the behavior of what its input represents did in
> the past?

[olcott]

Flibble knows that he is so woefully incompetent that he refuses to
answer whether or not the following is true or false:

the correct and complete x86 emulation of the input to H(Px,Px) by
H would never reach the "ret" instruction

If one has no idea whether or not a statement is true or false and they
want to hide the fact that they have no idea then when repeatedly
pressed to provide an answer the best that they can possibly do is
continue to dodge the question.

it is no longer worth my time to continue to talk to you of Richard.

[Mr Flibble]

On Sun, 19 Jun 2022 17:31:40 -0500

I told you before: block away. Blocking me will not stop me pointing
the following out every time you start a "new" topic repeating the same
old shit:

[Richard Damon]

Flibble, Px doesn't "Always" Halt. If H(Px,Px) doesn't return because it
gets stuck in an infinite loop, then Px(Px) doesn't Halt.

Now, this H fails to be a decider, so can't be a counter example for a
Halt Decider.

Olcotts problem is his H falsely presumes that the H that Px calls is
that H not the actual H doing the decision, so it doesn't actually make
a correct evaluation of its input.

[Mr Flibble]

If H is a valid halt decider (and by that I mean returns an answer in
finite time) then Px *will* always halt: it doesn't because Olcott's H
is not a valid halt decider.

/Flibble

[Richard Damon]

No, it says you don't know how to justify your possition, so you can't
get into actual clarification, so you revert to just making the same
wrong/misleading statements over and over.


I note, you don't bother answering any of my questions, either because
they are above your understanding, or answering them would require you
to admit to your errors.

You will note that I don't need to keep repeating my own statements over
and over, but just point to fundamental principles that are part of the
field.

If you want to disagree with one of these, say so, and show why that
basic principle doesn't apply here. Just remember, you don't get to
change the basic rules and still be working on the Halting Problem in
Computation Theory.

That means, the correct answer is based on, and ONLY based on, the
behavior of the actual machine in question. In this case, that is the
PROGRAM P with arguemnt P, built as per Linz that asks H what the
program P with argument P would do, and then does the opposite, would do.

Symboolically, H(M,x) accepts (returns 1) if M(x) returns in finite
time, and H(M,x) rejects (returns 0 in finite steps) if M(x) will never
return even after being run for an umbounded number of steps.

Doesn't matter if this doesn't match what you think is fair to ask, that
is the question that H needs to answer, and the Theory says that no such
decider is creatable. You claims that you can't ask the question just
would confirm that, if you can't ask the question, you can't get the
answer to that question you couldn't ask.

[Richard Damon]

Yes, but that means that Px only returns if H actually is a valid
decider. Since Plcott keeps on putting in assumptons on H that make it
not one, means "hiding" that in the initial requirements, that Olcott
doesn't seem to understand need to apply, becomes a problem.

That is why I try to ALWAY put in the conditionals on the statements, as
PO doesn't seem to be able to put 1 and 1 together to get 2.

[Richard Damon]

On 6/19/22 5:17 PM, olcott wrote:
>

> When you disagree with this precisely stated verified fact you are
> either a liar or incompetent:

And when you state facts have been "verified" when they haven't, your a
liar.

Maybe you are too dumb to realize that your "proofs" have been rebutted,
but using stupidity as an excuse only goes so far.

[olcott]

Now that H has been very recently adapted to be a pure function of its
inputs whenever it is invoked it always returns on finite time.
H aborts its simulation of Px before Px invokes H.

H knows its own machine address and on this basis:
(a) H recognizes that Px is calling H with the same arguments that H was
called with.
(b) There are no instructions in Px that could possibly escape this
infinitely recursive emulation.

(c) H aborts its emulation of Px before its call to H is invoked.

[Mr Flibble]

On Sun, 19 Jun 2022 18:25:33 -0500

[olcott]

So you are a mere bot now.

[Mr Flibble]

On Sun, 19 Jun 2022 18:25:33 -0500

To be a valid halt decider H must always return a value to its invoker,
in this case Px; it doesn't so it isn't a valid halt decider.

/Flibble

[Mr Flibble]

On Sun, 19 Jun 2022 18:31:27 -0500

Until you offer something new I cannot be bothered to.

/Flibble

[olcott]

When a function is called in infinite recursion it merely never stops.

When a halt decider is called in infinite recursion it essentially says
https://www.youtube.com/watch?v=Z6EsNyIRG-g

[Mr Flibble]

On Sun, 19 Jun 2022 18:44:34 -0500

Px isn't calling Px; Px is calling H which is calling Px so the
infinite recursion is purely a manifestation of your invalid
halt decider; there would be no such infinite recursion if H was a valid
halt decider. The fact that you prevent the infinite recursion by
detecting the call to H and aborting is both beside the point and
fallacious.

/Flibble

[Richard Damon]

IF H always returns in finite time for all calls to it, the Px can't be
non-halting!! SO H saying it is says it is using wrong logic.

In fact, that means that you can't make an assumption that H does a
complete emulation of its input, which just breaks you logic.

> H knows its own machine address and on this basis:
> (a) H recognizes that Px is calling H with the same arguments that H was
> called with.
> (b) There are no instructions in Px that could possibly escape this
> infinitely recursive emulation.
> (c) H aborts its emulation of Px before its call to H is invoked.
>
>
>

Right, but there the conditional doens't need to be in the code for the
C function P, just in the x86 execution path of the PROGRAM P around the
loop.

This is a fatal flaw to your logic. WHERE do you get that rule stated
that way. Fundamentally, all it does is show that you don't understand
what a "Function" is to Computation Theory, it isn't just the base body
of the root function. It includes ALL the algorithms of all the
functions/subroutines that it calls, and thus for P we need to include H.

[Richard Damon]

On 6/19/22 7:44 PM, olcott wrote:
>>
>
> When a function is called in infinite recursion it merely never stops.
>
> When a halt decider is called in infinite recursion it essentially says
> https://www.youtube.com/watch?v=Z6EsNyIRG-g

Whixh means that the function used the halt decider doesn't get into the
infinite loop either, BECAUSE the Halt decider stopped the loop.

Your problem is your H thinks it will but then it doesn't so it just was
incorrect about the behavior.

And, there is no special case in the definitions that allow it to get a
pass for this case.

FAIL.

[André G. Isaak]

On 2022-06-19 16:18, olcott wrote:
> On 6/19/2022 5:02 PM, André G. Isaak wrote:
>> On 2022-06-19 14:43, olcott wrote:
>>
>>> My whole system is now wrapped in 131K zip file as a Visual Studio
>>> project on a downloadable link.
>>
>> I see no link anywhere.
>>
>> André
>>
>
> Are you sure maybe you didn't look hard enough?
> Maybe there is an invisible link between "131K" and "zip"

If you posted it somewhere, wouldn't it be easier to simply repost the
link rather than make snide comments?

Or if you don't intend to post the link, then say so.

[Richard Damon]

On 6/19/22 6:18 PM, olcott wrote:
> On 6/19/2022 5:02 PM, André G. Isaak wrote:
>> On 2022-06-19 14:43, olcott wrote:
>>
>>> My whole system is now wrapped in 131K zip file as a Visual Studio
>>> project on a downloadable link.
>>
>> I see no link anywhere.
>>
>> André
>>
>
> Are you sure maybe you didn't look hard enough?
> Maybe there is an invisible link between "131K" and "zip"
>

Except that there isn't one. Note Content-type Text/Plain doesn't have a
way to "Hide" links.

My guess is this is just your normal less-than-truthful sort of comment.

[olcott]

On 6/19/2022 9:27 PM, André G. Isaak wrote:
> On 2022-06-19 16:18, olcott wrote:
>> On 6/19/2022 5:02 PM, André G. Isaak wrote:
>>> On 2022-06-19 14:43, olcott wrote:
>>>
>>>> My whole system is now wrapped in 131K zip file as a Visual Studio
>>>> project on a downloadable link.
>>>
>>> I see no link anywhere.
>>>
>>> André
>>>
>>
>> Are you sure maybe you didn't look hard enough?
>> Maybe there is an invisible link between "131K" and "zip"
>
> If you posted it somewhere, wouldn't it be easier to simply repost the
> link rather than make snide comments?
>
> Or if you don't intend to post the link, then say so.
>
> André
>

I do not intend to post the link very soon.
Because reviewers here have been so consistently disparaging of my work
they will be last in line to be able to have access to this code.

When I boiled my claims down to two easily verified facts of software
engineering and everyone consistently still disagreed then I knew that
none of my reviewers were both sufficiently technically competent and
honest.

It is a very easily verified fact that the correct and complete x86

emulation of the input to H(P,P) by H would never reach the "ret"

instruction of P. Only one reviewer out of 100 reviewers in a dozen
different forums over the period of a year would acknowledge that.

The x86 emulator code is immaculate because I was very cautious in my
slight changes to keep it very clean. H is the one halt decider that has
all of its code quite clean and finally a pure function of its inputs.
The x86utm operating system code is very reliable yet quite messy.

At this point I have provided enough evidence that reasonable people
would conclude that all of my claims of having actual code have been
sufficiently proven. I decided that posting this code as a Google Drive
downloadable link to a complete Visual Studio project is the way to go.

The solution is defined so that immediately after the build the halt
decider can be directly run from inside Visual Studio. The halt decider
file itself can be edited to run different halt deciders on a small
library of sample inputs. Right out of the box H(P,P) is executed.

[André G. Isaak]

On 2022-06-19 21:14, olcott wrote:
> On 6/19/2022 9:27 PM, André G. Isaak wrote:
>> On 2022-06-19 16:18, olcott wrote:
>>> On 6/19/2022 5:02 PM, André G. Isaak wrote:
>>>> On 2022-06-19 14:43, olcott wrote:
>>>>
>>>>> My whole system is now wrapped in 131K zip file as a Visual Studio
>>>>> project on a downloadable link.
>>>>
>>>> I see no link anywhere.
>>>>
>>>> André
>>>>
>>>
>>> Are you sure maybe you didn't look hard enough?
>>> Maybe there is an invisible link between "131K" and "zip"
>>
>> If you posted it somewhere, wouldn't it be easier to simply repost the
>> link rather than make snide comments?
>>
>> Or if you don't intend to post the link, then say so.
>>
>> André
>>
>
> I do not intend to post the link very soon.

So then why bother mentioning it at all?

[olcott]

That I have all of the code fully operational in a single 131K zipped
Visual studio project is a key milestone.

On 3/14/2017 9:05 AM, peteolcott wrote: in comp.theory
[Solution to one instance of the Halting Problem]

Is when I first showed that a simulating halt decider could correctly
determine that the conventional input to the halting problem proofs
could be correctly decided as non-halting on the basis that they specify
infinitely nested simulation to every simulating halt decider.

It has been an average of at least full time work on this project ever
since.

[Richard Damon]

On 6/19/22 11:14 PM, olcott wrote:
> On 6/19/2022 9:27 PM, André G. Isaak wrote:
>> On 2022-06-19 16:18, olcott wrote:
>>> On 6/19/2022 5:02 PM, André G. Isaak wrote:
>>>> On 2022-06-19 14:43, olcott wrote:
>>>>
>>>>> My whole system is now wrapped in 131K zip file as a Visual Studio
>>>>> project on a downloadable link.
>>>>
>>>> I see no link anywhere.
>>>>
>>>> André
>>>>
>>>
>>> Are you sure maybe you didn't look hard enough?
>>> Maybe there is an invisible link between "131K" and "zip"
>>
>> If you posted it somewhere, wouldn't it be easier to simply repost the
>> link rather than make snide comments?
>>
>> Or if you don't intend to post the link, then say so.
>>
>> André
>>
>
> I do not intend to post the link very soon.
> Because reviewers here have been so consistently disparaging of my work
> they will be last in line to be able to have access to this code.
>
> When I boiled my claims down to two easily verified facts of software
> engineering and everyone consistently still disagreed then I knew that
> none of my reviewers were both sufficiently technically competent and
> honest.

No, you haven't, because you can't actually verify them, just claim
them, because they aren't actually correct.

>
> It is a very easily verified fact that the correct and complete x86
> emulation of the input to H(P,P) by H would never reach the "ret"
> instruction of P. Only one reviewer out of 100 reviewers in a dozen
> different forums over the period of a year would acknowledge that.

ONLY if H actually does a correct and complete x86 emulation, which it
actually doesn't, not if it returns 0 for a non-halting input. So, the
statement is actually illogical.

>
> The x86 emulator code is immaculate because I was very cautious in my
> slight changes to keep it very clean. H is the one halt decider that has
> all of its code quite clean and finally a pure function of its inputs.
> The x86utm operating system code is very reliable yet quite messy.

Some how, from what you have shown in the past, I doubt the the code for
H is "clean". I say this based on what code you have published and how
bad the basic structure of the code has been.

>
> At this point I have provided enough evidence that reasonable people
> would conclude that all of my claims of having actual code have been
> sufficiently proven. I decided that posting this code as a Google Drive
> downloadable link to a complete Visual Studio project is the way to go.



>
> The solution is defined so that immediately after the build the halt
> decider can be directly run from inside Visual Studio. The halt decider
> file itself can be edited to run different halt deciders on a small
> library of sample inputs. Right out of the box H(P,P) is executed.
>

And none of this shows that H(P,P) returning 0 is the right answer for H
to give as a Halt Decider, we don't need code to see that, we can go by
definitions.

The DEFINITION of a Halt decider is that it is a computation (so always
gives the same answer for the same inputs) that answer whether a given
algorithm + input combination will halt in a finite number of steps or not.

Typically, the computation to be decided is provided as a representation
of the algorithm and a representation of the input to be given to that
algorithm.

The Halting Theorem states that no such finite algorithm exist that can
be a correct halting decider for all possible algorithm + input
combinations.

The proof, is to imagine that we create a algorithm and input that asks
the proposed Halt Decider what this algorithm will do with its input,
and then do the opposite.

Said algorithm is clearly possible to build, if the halt decider
algorithm exists, as the steps are clearly defined.

Since your P is the embodyment of this counter example algorithm, and
P(P) calls H(P,P), that means that H(P,P) must mean that H(P,P) is
defined to answer about what P(P) does.

You claim otherwise just shows that you just don't understand the proof,
and are just being a dumb parrot about your code pieces and not
understanding them. (One reason I doubt your code is "clean").

Since we can easily prove that P(P) will Halt if H(P,P) returns 0, we
can show that H(P,P) returning 0 is clearly the wrong answer for a P
built by the counter argument algorithm, which is what is claimed.

Thus, either you have lied that this test was actually built to the
specifications (perhaps because you actually don't understand what
specifications actually mean) or your H is just an incorrect algorithm.

[olcott]

This is the part where you prove that you do not have sufficient
technical competence in software engineering.

H correctly detects in a finite number of steps that its complete and
correct x86 emulation of its input would never reach the "ret"
instruction of P.

H knows its own machine address and on this basis:

(a) H recognizes that P is calling H with the same arguments that H was
called with.
(b) There are no instructions in P that could possibly escape this
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.

The proof that I am correct is that no counter-example can possibly exist.

[Mr Flibble]

[Richard Damon]

How can it correct detect something that isn't true.

SInce you have stipulated that H(P,P) "Correctly" returns 0, and it is
proven that P(P) will halt when H(P,P) returns 0, it is proven that
H(P,P) returning 0 is not correct, because the input is NOT a
non-halting input.

>
> H knows its own machine address and on this basis:
> (a) H recognizes that P is calling H with the same arguments that H was
> called with.
> (b) There are no instructions in P that could possibly escape this
> infinitely recursive emulation.

FALSE Criteria, pleae provide your sourc for this "rule"

FALSE Premise -> UNSOUND LOGIC.

> (c) H aborts its emulation of P before its call to H is invoked.
>
> The proof that I am correct is that no counter-example can possibly exist.
>

LIE. P(P) is. Since P(P) Halts when H(P,P) returns 0.

If H(P,P) isn't refering to the compuation P(P), then you have just been
lying that P was built per Linz requirements.


Also, lack of counter example is not proof of truth, and that just shows
you are just a lying hypocrite, as YOU are the one that says that all
Truth needs to be Provable.

That fact that you can't live with youtr own rules shows that you dont
understand what Truth actually is.