Halting Problem proof refutation is a tautology thus irrefutable

0 views
Skip to first unread message

olcott

unread,
Jun 19, 2022, 11:13:08 AMJun 19
to
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

unread,
Jun 19, 2022, 11:23:11 AMJun 19
to
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

unread,
Jun 19, 2022, 11:39:41 AMJun 19
to
_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

unread,
Jun 19, 2022, 12:00:02 PMJun 19
to
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

unread,
Jun 19, 2022, 12:01:14 PMJun 19
to

olcott

unread,
Jun 19, 2022, 12:23:31 PMJun 19
to

Richard Damon

unread,
Jun 19, 2022, 12:45:08 PMJun 19
to
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

unread,
Jun 19, 2022, 12:47:43 PMJun 19
to
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

unread,
Jun 19, 2022, 12:48:26 PMJun 19
to
On 6/19/22 12:23 PM, olcott wrote:

> *All technically competent software engineers*
>

Which means you are excluding yourself.

Richard Damon

unread,
Jun 19, 2022, 12:50:34 PMJun 19
to
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

unread,
Jun 19, 2022, 1:01:43 PMJun 19
to
On Sun, 19 Jun 2022 11:23:24 -0500

olcott

unread,
Jun 19, 2022, 1:16:13 PMJun 19
to
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

unread,
Jun 19, 2022, 1:34:54 PMJun 19
to
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

unread,
Jun 19, 2022, 1:40:09 PMJun 19
to
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

unread,
Jun 19, 2022, 2:08:10 PMJun 19
to
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

unread,
Jun 19, 2022, 2:09:51 PMJun 19
to
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

unread,
Jun 19, 2022, 2:20:22 PMJun 19
to
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

unread,
Jun 19, 2022, 2:22:33 PMJun 19
to
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

unread,
Jun 19, 2022, 2:30:29 PMJun 19
to
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

unread,
Jun 19, 2022, 2:43:46 PMJun 19
to
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

unread,
Jun 19, 2022, 3:17:49 PMJun 19
to
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

unread,
Jun 19, 2022, 3:23:11 PMJun 19
to
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

unread,
Jun 19, 2022, 3:59:54 PMJun 19
to
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

unread,
Jun 19, 2022, 4:05:18 PMJun 19
to
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

unread,
Jun 19, 2022, 4:08:16 PMJun 19
to
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

unread,
Jun 19, 2022, 4:16:12 PMJun 19
to
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

unread,
Jun 19, 2022, 4:19:10 PMJun 19
to
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

unread,
Jun 19, 2022, 4:23:20 PMJun 19
to
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

unread,
Jun 19, 2022, 4:26:03 PMJun 19
to
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

unread,
Jun 19, 2022, 4:31:41 PMJun 19
to
On Sun, 19 Jun 2022 15:16:05 -0500

olcott

unread,
Jun 19, 2022, 4:34:10 PMJun 19
to
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

unread,
Jun 19, 2022, 4:43:07 PMJun 19
to
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

unread,
Jun 19, 2022, 4:50:43 PMJun 19
to
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

unread,
Jun 19, 2022, 4:55:18 PMJun 19
to
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

unread,
Jun 19, 2022, 5:00:11 PMJun 19
to
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

unread,
Jun 19, 2022, 5:17:27 PMJun 19
to
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

unread,
Jun 19, 2022, 5:20:03 PMJun 19
to
On Sun, 19 Jun 2022 16:17:20 -0500

Richard Damon

unread,
Jun 19, 2022, 5:23:19 PMJun 19
to
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

unread,
Jun 19, 2022, 5:23:24 PMJun 19
to
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

unread,
Jun 19, 2022, 5:30:57 PMJun 19
to
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

unread,
Jun 19, 2022, 5:34:15 PMJun 19
to
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

unread,
Jun 19, 2022, 5:36:07 PMJun 19
to
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

unread,
Jun 19, 2022, 5:38:41 PMJun 19
to
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

unread,
Jun 19, 2022, 5:47:00 PMJun 19
to
On Sun, 19 Jun 2022 16:23:17 -0500
What I am saying is the following, no more, no less:

Richard Damon

unread,
Jun 19, 2022, 5:52:26 PMJun 19
to
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

unread,
Jun 19, 2022, 5:56:36 PMJun 19
to
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

unread,
Jun 19, 2022, 6:02:54 PMJun 19
to
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

unread,
Jun 19, 2022, 6:05:07 PMJun 19
to
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

unread,
Jun 19, 2022, 6:16:10 PMJun 19
to
You are not committing to a criterion measure of correctness thus your
claim is vague.

olcott

unread,
Jun 19, 2022, 6:18:45 PMJun 19
to
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

unread,
Jun 19, 2022, 6:22:05 PMJun 19
to
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

unread,
Jun 19, 2022, 6:25:07 PMJun 19
to
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

unread,
Jun 19, 2022, 6:31:50 PMJun 19
to
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

unread,
Jun 19, 2022, 6:34:18 PMJun 19
to
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

unread,
Jun 19, 2022, 6:53:39 PMJun 19
to
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

unread,
Jun 19, 2022, 6:58:27 PMJun 19
to
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

unread,
Jun 19, 2022, 7:02:44 PMJun 19
to
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

unread,
Jun 19, 2022, 7:05:34 PMJun 19
to
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

unread,
Jun 19, 2022, 7:25:09 PMJun 19
to
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

unread,
Jun 19, 2022, 7:25:40 PMJun 19