0 views

Skip to first unread message

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

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

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

{

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

Jun 19, 2022, 11:39:41 AMJun 19

to

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

Jun 19, 2022, 12:00:02 PMJun 19

to

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

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

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

>> computation that halts â€¦ the Turing machine will halt whenever it

>> enters a final state. (Linz:1990:234)

>

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

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

to

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

to

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

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.

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*

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.

Jun 19, 2022, 12:47:43 PMJun 19

to

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.

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.
> *All technically competent software engineers*

>

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

>

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.

Jun 19, 2022, 1:01:43 PMJun 19

to

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

Jun 19, 2022, 1:16:13 PMJun 19

to

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.

Jun 19, 2022, 1:34:54 PMJun 19

to

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.

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.

analysing what its input actually does and instead assuming that an

input that calls H is always pathological.

Jun 19, 2022, 2:08:10 PMJun 19

to

H(Px,Px) does correctly determine that the complete and correct x86

emulation of its input would never reach the "ret" instruction of Px.

Jun 19, 2022, 2:09:51 PMJun 19

to

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

>

> Mikko

>

The code <is> the proof.

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

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

>

>

> Mikko

>

The code <is> the proof.

Jun 19, 2022, 2:20:22 PMJun 19

to

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.

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

>

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.

Jun 19, 2022, 2:30:29 PMJun 19

to

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.

Jun 19, 2022, 2:43:46 PMJun 19

to

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.

Jun 19, 2022, 3:17:49 PMJun 19

to

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

Jun 19, 2022, 3:23:11 PMJun 19

to

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:

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

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

be to allow Px to halt, which is what Px is defined to do:

void Px(u32 x)

{

H(x, x);

}

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

Jun 19, 2022, 4:05:18 PMJun 19

to

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

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.

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

doesn't halt. QED.

/Flibble

Jun 19, 2022, 4:16:12 PMJun 19

to

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.

Jun 19, 2022, 4:19:10 PMJun 19

to

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.

>

> 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

>

there to be a "future tense", the answer existed as soon as the machine

in question was defined, if not before.

Jun 19, 2022, 4:23:20 PMJun 19

to

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.

Jun 19, 2022, 4:26:03 PMJun 19

to

>

> 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

>

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.

Jun 19, 2022, 4:31:41 PMJun 19

to

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

Jun 19, 2022, 4:34:10 PMJun 19

to

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.

Jun 19, 2022, 4:43:07 PMJun 19

to

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.

Jun 19, 2022, 4:50:43 PMJun 19

to

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)

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

Jun 19, 2022, 4:55:18 PMJun 19

to

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.

Jun 19, 2022, 5:00:11 PMJun 19

to

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.

Jun 19, 2022, 5:17:27 PMJun 19

to

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

changing its words and showing that the changed words are not true then

between liar and incompetent you prove to be a liar.

Jun 19, 2022, 5:20:03 PMJun 19

to

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

Jun 19, 2022, 5:23:19 PMJun 19

to

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.

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.

>

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.

Jun 19, 2022, 5:23:24 PMJun 19

to

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

would never reach the "ret" instruction

would never reach the "ret" instruction

Jun 19, 2022, 5:30:57 PMJun 19

to

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.

>

>

you don't use the facts correctly and thus fill your rhetorica;

"arguments" with unsound logic.

Jun 19, 2022, 5:34:15 PMJun 19

to

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

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

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

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.

Jun 19, 2022, 5:36:07 PMJun 19

to

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.

Jun 19, 2022, 5:38:41 PMJun 19

to

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

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:

Jun 19, 2022, 5:52:26 PMJun 19

to

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.

>

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.

Jun 19, 2022, 5:56:36 PMJun 19

to

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.

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.
> My whole system is now wrapped in 131K zip file as a Visual Studio

> project on a downloadable link.

AndrÃ©

--

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

service.

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

it cannot handle the following case correctly:

Jun 19, 2022, 6:16:10 PMJun 19

to

claim is vague.

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?
> 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Ã©

>

Maybe there is an invisible link between "131K" and "zip"

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

decides that it is non-halting.

/Flibble

Jun 19, 2022, 6:25:07 PMJun 19

to

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?

Jun 19, 2022, 6:31:50 PMJun 19

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

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.

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:

the following out every time you start a "new" topic repeating the same

old shit:

Jun 19, 2022, 6:53:39 PMJun 19

to

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.

Jun 19, 2022, 6:58:27 PMJun 19

to

finite time) then Px *will* always halt: it doesn't because Olcott's H

is not a valid halt decider.

/Flibble

Jun 19, 2022, 7:02:44 PMJun 19

to

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.

Jun 19, 2022, 7:05:34 PMJun 19

to

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.

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
> either a liar or incompetent:

liar.

Maybe you are too dumb to realize that your "proofs" have been rebutted,

but using stupidity as an excuse only goes so far.

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