0 views

Skip to first unread message

Jun 16, 2022, 1:40:28 PMJun 16

to

On 6/16/2022 12:17 PM, Mr Flibble wrote:

> Given olcott's code,

>

> #include <stdint.h>

> typedef void (*ptr)();

>

> void P(ptr x)

> {

> if (H(x, x))

> HERE: goto HERE;

> return;

> }

>

> int main()

> {

> Output("Input_Halts = ", H(P, P));

> }

>

> and olcott's assertion that H is a pure function and H(P,P) == 0,

> then, P should halt as H should also return 0 to P (pure functions

> ALWAYS return the same result for the same arguments with no side

> effects). P doesn't halt so H is erroneous; olcott, it's really that

> simple.

>

> /Flibble

>

_P()

[00001352](01) 55 push ebp

[00001353](02) 8bec mov ebp,esp

[00001355](03) 8b4508 mov eax,[ebp+08]

[00001358](01) 50 push eax // push P

[00001359](03) 8b4d08 mov ecx,[ebp+08]

[0000135c](01) 51 push ecx // push P

[0000135d](05) e840feffff call 000011a2 // call H

[00001362](03) 83c408 add esp,+08

[00001365](02) 85c0 test eax,eax

[00001367](02) 7402 jz 0000136b

[00001369](02) ebfe jmp 00001369

[0000136b](01) 5d pop ebp

[0000136c](01) c3 ret

Size in bytes:(0027) [0000136c]

Any competent software engineer will see that the correct and complete

x86 emulation of the input to H(P,P) will never reach its "ret"

instruction (the final state of P).

When H(P,P) aborts the x86 emulation of its input on this basis and

returns 0 to main competent software engineers will know that this does

not cause P to reach its "ret" instruction.

computation that halts … the Turing machine will halt whenever it enters

a final state. (Linz:1990:234)

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

> Given olcott's code,

>

> #include <stdint.h>

> typedef void (*ptr)();

>

> void P(ptr x)

> {

> if (H(x, x))

> HERE: goto HERE;

> return;

> }

>

> int main()

> {

> Output("Input_Halts = ", H(P, P));

> }

>

> and olcott's assertion that H is a pure function and H(P,P) == 0,

> then, P should halt as H should also return 0 to P (pure functions

> ALWAYS return the same result for the same arguments with no side

> effects). P doesn't halt so H is erroneous; olcott, it's really that

> simple.

>

> /Flibble

>

_P()

[00001352](01) 55 push ebp

[00001353](02) 8bec mov ebp,esp

[00001355](03) 8b4508 mov eax,[ebp+08]

[00001358](01) 50 push eax // push P

[00001359](03) 8b4d08 mov ecx,[ebp+08]

[0000135c](01) 51 push ecx // push P

[0000135d](05) e840feffff call 000011a2 // call H

[00001362](03) 83c408 add esp,+08

[00001365](02) 85c0 test eax,eax

[00001367](02) 7402 jz 0000136b

[00001369](02) ebfe jmp 00001369

[0000136b](01) 5d pop ebp

[0000136c](01) c3 ret

Size in bytes:(0027) [0000136c]

Any competent software engineer will see that the correct and complete

x86 emulation of the input to H(P,P) will never reach its "ret"

instruction (the final state of P).

When H(P,P) aborts the x86 emulation of its input on this basis and

returns 0 to main competent software engineers will know that this does

not cause P to reach its "ret" instruction.

computation that halts … the Turing machine will halt whenever it enters

a final state. (Linz:1990:234)

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 16, 2022, 2:02:15 PMJun 16

to

posts. Your H is erroneous.

/Flibble

Jun 16, 2022, 2:07:37 PMJun 16

to

the following proves that H(P,P)==0 is correct.

#include <stdint.h>

typedef void (*ptr)();

void P(ptr x)

{

if (H(x, x))

HERE: goto HERE;

return;

}

int main()

{

Output("Input_Halts = ", H(P, P));

}

_P()

[00001352](01) 55 push ebp

[00001353](02) 8bec mov ebp,esp

[00001355](03) 8b4508 mov eax,[ebp+08]

[00001358](01) 50 push eax // push P

[00001359](03) 8b4d08 mov ecx,[ebp+08]

[0000135c](01) 51 push ecx // push P

[0000135d](05) e840feffff call 000011a2 // call H

[00001362](03) 83c408 add esp,+08

[00001365](02) 85c0 test eax,eax

[00001367](02) 7402 jz 0000136b

[00001369](02) ebfe jmp 00001369

[0000136b](01) 5d pop ebp

[0000136c](01) c3 ret

Size in bytes:(0027) [0000136c]

(1) It is an easily verified fact that when we assume that H is only an
[00001352](01) 55 push ebp

[00001353](02) 8bec mov ebp,esp

[00001355](03) 8b4508 mov eax,[ebp+08]

[00001358](01) 50 push eax // push P

[00001359](03) 8b4d08 mov ecx,[ebp+08]

[0000135c](01) 51 push ecx // push P

[0000135d](05) e840feffff call 000011a2 // call H

[00001362](03) 83c408 add esp,+08

[00001365](02) 85c0 test eax,eax

[00001367](02) 7402 jz 0000136b

[00001369](02) ebfe jmp 00001369

[0000136b](01) 5d pop ebp

[0000136c](01) c3 ret

Size in bytes:(0027) [0000136c]

x86 emulator that the correctly emulated P never reaches its "ret"

instruction it remains stuck in repeated cycles of emulation.

(2) It is an easily verified fact that if H has been adapted to

correctly detect (in a finite number of steps) that the correct and

complete x86 emulation of its input would never each its "ret"

instruction that H could abort its emulation and return 0 to report this.

(3) When the halt status criteria is defined as correctly determining

whether or not an x86 emulated input would ever reach its "ret"

instruction then it becomes an easily verified fact H(P,P) could

correctly reject its input as non-halting.

Correct deductive inference proves that all of these things are true

without any need what-so-ever to see either the source-code or the

execution trace of H.

The one thing that is not proved is whether or not an actual encoded

H(P,P) does indeed correctly determine that its input would never reach

its "ret" instruction as a pure function of its inputs.

Jun 16, 2022, 2:11:42 PMJun 16

to

/Flibble

Jun 16, 2022, 2:21:53 PMJun 16

to

and be unable to find any software engineering mistakes.

It is an easily verified fact that the correct and complete x86

emulation of the input to H(P,P) by H cannot possibly reach its "ret"

instruction.

Since this is the criterion measure for returning 0 then H(P,P)==0 has

been proven to be correct on the basis of software engineering.

Jun 16, 2022, 2:22:41 PMJun 16

to

On Thu, 16 Jun 2022 13:21:45 -0500

Jun 16, 2022, 2:26:33 PMJun 16

to

rebuttal to truth will avoid addressing the above irrefutably correct

reasoning.

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

to

On Thu, 16 Jun 2022 13:26:25 -0500

Your reasoning is incorrect. If H(P,P) == 0 then P should halt.

/Flibble

/Flibble

Jun 16, 2022, 2:32:05 PMJun 16

to

People that are not competent software engineers and people that

prefer rebuttal to truth will avoid addressing the above irrefutably

correct reasoning.

Jun 16, 2022, 2:33:04 PMJun 16

to

On Thu, 16 Jun 2022 13:31:57 -0500

Jun 16, 2022, 2:45:15 PMJun 16

to

It is an easily verified fact that the correct and complete x86

emulation of the input to H(P,P) by H cannot possibly reach its

"ret" instruction.

would never reach the "ret" instruction of this input.

Every possible rebuttal is simultaneously proven to be incorrect.

Jun 16, 2022, 2:49:39 PMJun 16

to

On Thu, 16 Jun 2022 13:45:07 -0500

Jun 16, 2022, 3:04:20 PMJun 16

to

emulation of the input to H(P,P) by H cannot possibly reach its "ret"

instruction.

(Y) H returns 0 whenever the correct and complete x86 emulation of its
instruction.

input would never reach the "ret" instruction of this input.

(Z) H(P,P)==0 is correct
When (X & Y) proves Z and we know X & Y then Z is proved.

Even you can understand that there is no escape from this last line.

Failing to acknowledge the correctness of this last line is sufficient

evidence of dishonesty.

Jun 16, 2022, 3:27:29 PMJun 16

to

On 6/16/2022 2:15 PM, Ben Bacarisse wrote:

> Mr Flibble <fli...@reddwarf.jmc> writes:

>

>> Given olcott's code,

> Not only has he posted a trace of P(P) halting, he has clearly stated

> that H(P,P) == 0 "is the correct answer even though P(P) halts".[1]

> something else (the "correct simulation of the input to H(P,P)") and the

> mistakes in that irrelevant statement are keeping him supplied with the

> attention he craves. You might consider not giving him what he wants.

>

> [1] Message-ID: <c8idnbFAF6C8QuP8...@giganews.com>

>

When a simulating halt decider rejects all inputs as non-halting

whenever it correctly detects that its correct and complete simulation

of its input would never reach the final state of this input that all

inputs (including pathological inputs) are decided correctly.

*computation that halts* … the Turing machine will halt whenever it

> Mr Flibble <fli...@reddwarf.jmc> writes:

>

>> Given olcott's code,

>>

>> #include <stdint.h>

>> typedef void (*ptr)();

>>

>> void P(ptr x)

>> {

>> if (H(x, x))

>> HERE: goto HERE;

>> return;

>> }

>>

>> int main()

>> {

>> Output("Input_Halts = ", H(P, P));

>> }

>>

>> #include <stdint.h>

>> typedef void (*ptr)();

>>

>> void P(ptr x)

>> {

>> if (H(x, x))

>> HERE: goto HERE;

>> return;

>> }

>>

>> int main()

>> {

>> Output("Input_Halts = ", H(P, P));

>> }

>>

>> and olcott's assertion that H is a pure function and H(P,P) == 0,

>> then, P should halt as H should also return 0 to P

>

> You mean P(P) should halt, and it does. PO does not dispute this fact.
>> then, P should halt as H should also return 0 to P

>

> Not only has he posted a trace of P(P) halting, he has clearly stated

> that H(P,P) == 0 "is the correct answer even though P(P) halts".[1]

>

>> (pure functions

>> ALWAYS return the same result for the same arguments with no side

>> effects). P doesn't halt so H is erroneous; olcott, it's really that

>> simple.

>

> Except that he is now just asserting that H(P,P) == 0 is correct about
>> (pure functions

>> ALWAYS return the same result for the same arguments with no side

>> effects). P doesn't halt so H is erroneous; olcott, it's really that

>> simple.

>

> something else (the "correct simulation of the input to H(P,P)") and the

> mistakes in that irrelevant statement are keeping him supplied with the

> attention he craves. You might consider not giving him what he wants.

>

> [1] Message-ID: <c8idnbFAF6C8QuP8...@giganews.com>

>

When a simulating halt decider rejects all inputs as non-halting

whenever it correctly detects that its correct and complete simulation

of its input would never reach the final state of this input that all

inputs (including pathological inputs) are decided correctly.

*computation that halts* … the Turing machine will halt whenever it

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

Linz, Peter 1990. An Introduction to Formal Languages and Automata.

Lexington/Toronto: D. C. Heath and Company. (317-320)

Linz, Peter 1990. An Introduction to Formal Languages and Automata.

Lexington/Toronto: D. C. Heath and Company. (317-320)

Jun 16, 2022, 9:58:21 PMJun 16

to

simulation to give an answer?

The fact that you seem to claim that when H is called by main, it aborts

and returns an answer, but when H is called by the simulated P it

doesn't, just proves that H isn't the pure function you claim, or H's

emulaiton isn't correct.

>

> When H(P,P) aborts the x86 emulation of its input on this basis and

> returns 0 to main competent software engineers will know that this does

> not cause P to reach its "ret" instruction.

the pure function you claim.

>

> computation that halts … the Turing machine will halt whenever it enters

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

H;s emulation of it) and that seems to Halt becahse H should return the

value 0 to it.

>

> Linz, Peter 1990. An Introduction to Formal Languages and Automata.

> Lexington/Toronto: D. C. Heath and Company. (317-320)

>

Is H not actually a pure function, or

Does H not accurately emulate its input, or

Is P not actualy built as required?

One of these has to be wrong.

Jun 16, 2022, 10:03:16 PMJun 16

to

>

> (2) It is an easily verified fact that if H has been adapted to

> correctly detect (in a finite number of steps) that the correct and

> complete x86 emulation of its input would never each its "ret"

> instruction that H could abort its emulation and return 0 to report this.

>

> (3) When the halt status criteria is defined as correctly determining

> whether or not an x86 emulated input would ever reach its "ret"

> instruction then it becomes an easily verified fact H(P,P) could

> correctly reject its input as non-halting.

>

emulation, thus if H acts as in (3), then it can't use the logic of (1)

or (2), since those both were based on the stipulation that H did a

complete and correct emulation and NEVER aborted.

FALSE PREMISE, UNSOUND logic.

> Correct deductive inference proves that all of these things are true

> without any need what-so-ever to see either the source-code or the

> execution trace of H.

it just shows either ignorance or just being a pathological liar.

>

> The one thing that is not proved is whether or not an actual encoded

> H(P,P) does indeed correctly determine that its input would never reach

> its "ret" instruction as a pure function of its inputs.

>

Jun 16, 2022, 10:08:28 PMJun 16

to

and complete simulation of its input would never reach the final state

unless it actually DOES that.
If H DOES a complete emulation of its input P, then it never answers and

fails.

If H DOES abort its emulation, it doesn't actually do a complete and

correct emulation, so your definition isn't applicable, and when we look

at the ACTUAL complete and correct emulation, we see it halts, so H was

wrong.

Note, you quoteing Linz on a computation that Halts actually shows that

your criterion is incorrect, as it never references a "simultion" or

"emulation" of the machine, but the machine it self, thus, since even

you agree that P(P) will halt if H(P,P) returns 0, Linz definition says

P(P) is a Halting computaiton in that case, so H(P,P) returning 0 is

incorrect for something actually claiming to be a Halting Decider.

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu