325 views

Skip to first unread message

Aug 17, 2022, 12:46:40 PMAug 17

to

Olcott, which of the following do you think is more likely?

1) Olcott is correct and everybody else is wrong.

2) Olcott is wrong and everybody else is correct.

Which one is more likely hasn't changed for all the years you've been

attempting to shill your simulating halting decider. I find it amusing

that I came up with, in less than 24 hours, a simulating halting

decider that doesn't have the flaws your SHD has.

/Flibble

1) Olcott is correct and everybody else is wrong.

2) Olcott is wrong and everybody else is correct.

Which one is more likely hasn't changed for all the years you've been

attempting to shill your simulating halting decider. I find it amusing

that I came up with, in less than 24 hours, a simulating halting

decider that doesn't have the flaws your SHD has.

/Flibble

Aug 17, 2022, 1:03:41 PMAug 17

to

flat.

It was around 500 B.C. that Pythagoras first proposed a spherical Earth,

mainly on aesthetic grounds rather than on any physical evidence. Like

many Greeks, he believed the sphere was the most perfect shape. Possibly

the first to propose a spherical Earth based on actual physical evidence

was Aristotle (384-322 B.C.), who listed several arguments for a

spherical Earth: ships disappear hull first when they sail over the

horizon, Earth casts a round shadow on the moon during a lunar eclipse,

and different constellations are visible at different latitudes.

https://www.aps.org/publications/apsnews/200606/history.cfm

--

Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;

Genius hits a target no one else can see."

Arthur Schopenhauer

Aug 17, 2022, 1:06:47 PMAug 17

to

On Wed, 17 Aug 2022 12:03:35 -0500

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

> On 8/17/2022 11:46 AM, Mr Flibble wrote:

> > Olcott, which of the following do you think is more likely?

> >

> > 1) Olcott is correct and everybody else is wrong.

> > 2) Olcott is wrong and everybody else is correct.

> >

> > Which one is more likely hasn't changed for all the years you've

> > been attempting to shill your simulating halting decider. I find

> > it amusing that I came up with, in less than 24 hours, a simulating

> > halting decider that doesn't have the flaws your SHD has.

> >

> > /Flibble

> >

>

> Prior to Pythagoras there was a universal consensus that the Earth

> was flat.

>

>

> It was around 500 B.C. that Pythagoras first proposed a spherical

> Earth, mainly on aesthetic grounds rather than on any physical

> evidence. Like many Greeks, he believed the sphere was the most

> perfect shape. Possibly the first to propose a spherical Earth based

> on actual physical evidence was Aristotle (384-322 B.C.), who listed

> several arguments for a spherical Earth: ships disappear hull first

> when they sail over the horizon, Earth casts a round shadow on the

> moon during a lunar eclipse, and different constellations are visible

> at different latitudes.

> https://www.aps.org/publications/apsnews/200606/history.cfm

So you are claiming to be a modern-day Pythagoras? I suggest you read
olcott <No...@NoWhere.com> wrote:

> On 8/17/2022 11:46 AM, Mr Flibble wrote:

> > Olcott, which of the following do you think is more likely?

> >

> > 1) Olcott is correct and everybody else is wrong.

> > 2) Olcott is wrong and everybody else is correct.

> >

> > Which one is more likely hasn't changed for all the years you've

> > been attempting to shill your simulating halting decider. I find

> > it amusing that I came up with, in less than 24 hours, a simulating

> > halting decider that doesn't have the flaws your SHD has.

> >

> > /Flibble

> >

>

> Prior to Pythagoras there was a universal consensus that the Earth

> was flat.

>

>

> It was around 500 B.C. that Pythagoras first proposed a spherical

> Earth, mainly on aesthetic grounds rather than on any physical

> evidence. Like many Greeks, he believed the sphere was the most

> perfect shape. Possibly the first to propose a spherical Earth based

> on actual physical evidence was Aristotle (384-322 B.C.), who listed

> several arguments for a spherical Earth: ships disappear hull first

> when they sail over the horizon, Earth casts a round shadow on the

> moon during a lunar eclipse, and different constellations are visible

> at different latitudes.

> https://www.aps.org/publications/apsnews/200606/history.cfm

the following:

https://en.wikipedia.org/wiki/Hubris

/Flibble

Aug 17, 2022, 5:47:27 PMAug 17

to

On 8/17/2022 11:03 AM, olcott wrote:

> On 8/17/2022 11:46 AM, Mr Flibble wrote:

>> Olcott, which of the following do you think is more likely?

>>

>> 1) Olcott is correct and everybody else is wrong.

>> 2) Olcott is wrong and everybody else is correct.

>>

>> Which one is more likely hasn't changed for all the years you've been

>> attempting to shill your simulating halting decider.Â I find it amusing

>> that I came up with, in less than 24 hours, a simulating halting

>> decider that doesn't have the flaws your SHD has.

>>

>> /Flibble

>>

>

> Prior to Pythagoras there was a universal consensus that the Earth was

> flat.

>

>

> It was around 500 B.C. that Pythagoras first proposed a spherical Earth,

> mainly on aesthetic grounds rather than on any physical evidence. Like

> many Greeks, he believed the sphere was the most perfect shape. Possibly

> the first to propose a spherical Earth based on actual physical evidence

> was Aristotle (384-322 B.C.), who listed several arguments for a

> spherical Earth: ships disappear hull first when they sail over the

> horizon, Earth casts a round shadow on the moon during a lunar eclipse,

> and different constellations are visible at different latitudes.

> https://www.aps.org/publications/apsnews/200606/history.cfm

So that is some of the many reasons that you are nothing like a
> On 8/17/2022 11:46 AM, Mr Flibble wrote:

>> Olcott, which of the following do you think is more likely?

>>

>> 1) Olcott is correct and everybody else is wrong.

>> 2) Olcott is wrong and everybody else is correct.

>>

>> Which one is more likely hasn't changed for all the years you've been

>> attempting to shill your simulating halting decider.Â I find it amusing

>> that I came up with, in less than 24 hours, a simulating halting

>> decider that doesn't have the flaws your SHD has.

>>

>> /Flibble

>>

>

> Prior to Pythagoras there was a universal consensus that the Earth was

> flat.

>

>

> It was around 500 B.C. that Pythagoras first proposed a spherical Earth,

> mainly on aesthetic grounds rather than on any physical evidence. Like

> many Greeks, he believed the sphere was the most perfect shape. Possibly

> the first to propose a spherical Earth based on actual physical evidence

> was Aristotle (384-322 B.C.), who listed several arguments for a

> spherical Earth: ships disappear hull first when they sail over the

> horizon, Earth casts a round shadow on the moon during a lunar eclipse,

> and different constellations are visible at different latitudes.

> https://www.aps.org/publications/apsnews/200606/history.cfm

modern-day Pythagoras - no results, now or ever, that anyone would care

about.

Another reason is that he would not eat beans and you do.

It seems that every one of your health infractions directly deadens your

brain. You really must do a better job of taking care of yourself. We

folks out here are hoping this trend stops before your head is solid Jello.

--

Jeff Barnett

Aug 20, 2022, 11:01:38 AMAug 20

to

Op 17.aug..2022 om 18:46 schreef Mr Flibble:

I have been following these discussions for many months now. I have a

strong impression that there is little progress. It seems that people

are running in circles. I am not an expert in this field. Maybe it helps

if a non-expert tries to summarize the discussion. Please, be patient

when correcting me if I make any mistake.

First the problem this is al about:

In computation theory we can denote a program with X and its input with

Y, which together is denoted as X(Y). X(Y) may end (halt) in a finite

number of steps, but another program X and/or input Y may not halt in a

finite number of steps. The question is, is it possible to create a

program H that when given any program X with its input Y can tell in a

finite number of steps whether X(Y) halts or not? In other words, will

H(X,Y) always halt after a finite number of steps with the correct

answer for any X and Y?

I hope that this is a correct formulation of the problem.

The classical proof that it is not possible is the idea that it is

always possible to create a program P that uses H, with itself as input,

but behaves opposite to what H returns. In a C-like language it would be

something like:

void P(ptr x)

{

int Halt_Status = H(x, x);

if (Halt_Status)

HERE: goto HERE;

return;

}

If there would be a hypothetical non-simulating non-aborting H, which

would always halts with the correct answer, then it is clear that there

would be a contradiction if we ask H about P with H(P,P). Because there

are only three possibilities:

1. If H would return true (halting) in a finite number of steps, then P

would start an endless loop, so H(P,P) does not halt in a finite number

of steps.

2. If H would return false (non-halting) in a finite number of steps,

then P returns immediately, so H returns a wrong result.

3. If H does not return, then it does not return in a finite number of

steps, so it is not the H where the problem asked for.

I think everybody agrees up to this point.

Now Olcott has created a simulating aborting H, which, when given P with

input P [so H(P,P)], creates a trace of the execution and at the point

where P calls H, it uses the following logic: If H were the hypothetical

non-aborting H, then an infinite recursion would happen at this point.

Therefore, Olcott's simulating H aborts the simulation and returns false

(0).

Does everybody still agree up to this point?

Now the opinions diverge.

Olcott thinks that his H gives the correct answer that P would not halt

when P would call the hypothetical non-aborting H, so, it must also be

the correct answer when P actually calls the actual aborting H.

Others have a different opinion and argue that P does not call the

hypothetical non-aborting H, but the actual aborting H, which does not

go in infinite recursion, but returns false in a finite number of steps.

Therefore, H's result is wrong.

Is this a correct summary of the disagreement? If not, please, tell me

where the summary failed. Maybe we can then find the point of divergence

of opinions easier.

strong impression that there is little progress. It seems that people

are running in circles. I am not an expert in this field. Maybe it helps

if a non-expert tries to summarize the discussion. Please, be patient

when correcting me if I make any mistake.

First the problem this is al about:

In computation theory we can denote a program with X and its input with

Y, which together is denoted as X(Y). X(Y) may end (halt) in a finite

number of steps, but another program X and/or input Y may not halt in a

finite number of steps. The question is, is it possible to create a

program H that when given any program X with its input Y can tell in a

finite number of steps whether X(Y) halts or not? In other words, will

H(X,Y) always halt after a finite number of steps with the correct

answer for any X and Y?

I hope that this is a correct formulation of the problem.

The classical proof that it is not possible is the idea that it is

always possible to create a program P that uses H, with itself as input,

but behaves opposite to what H returns. In a C-like language it would be

something like:

void P(ptr x)

{

int Halt_Status = H(x, x);

if (Halt_Status)

HERE: goto HERE;

return;

}

If there would be a hypothetical non-simulating non-aborting H, which

would always halts with the correct answer, then it is clear that there

would be a contradiction if we ask H about P with H(P,P). Because there

are only three possibilities:

1. If H would return true (halting) in a finite number of steps, then P

would start an endless loop, so H(P,P) does not halt in a finite number

of steps.

2. If H would return false (non-halting) in a finite number of steps,

then P returns immediately, so H returns a wrong result.

3. If H does not return, then it does not return in a finite number of

steps, so it is not the H where the problem asked for.

I think everybody agrees up to this point.

Now Olcott has created a simulating aborting H, which, when given P with

input P [so H(P,P)], creates a trace of the execution and at the point

where P calls H, it uses the following logic: If H were the hypothetical

non-aborting H, then an infinite recursion would happen at this point.

Therefore, Olcott's simulating H aborts the simulation and returns false

(0).

Does everybody still agree up to this point?

Now the opinions diverge.

Olcott thinks that his H gives the correct answer that P would not halt

when P would call the hypothetical non-aborting H, so, it must also be

the correct answer when P actually calls the actual aborting H.

Others have a different opinion and argue that P does not call the

hypothetical non-aborting H, but the actual aborting H, which does not

go in infinite recursion, but returns false in a finite number of steps.

Therefore, H's result is wrong.

Is this a correct summary of the disagreement? If not, please, tell me

where the summary failed. Maybe we can then find the point of divergence

of opinions easier.

Aug 20, 2022, 11:24:07 AMAug 20

to

The key nuance of divergence is that halting means that when H(P,P)

correctly simulates its input that this input would reach the "return"

instruction (final state) of P. H(P,P) correctly determines that its

correct simulation of its input would never reach the "return"

instruction of P.

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

When-so-ever the correct partial simulation of a machine description

correctly matches a correct infinite behavior pattern then it is certain

that this machine description specifies infinite behavior.

In other words the SHD decider correctly predicts that its correct and

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

this input.

*HERE IS THE SIMPLEST CASE OF THAT*

void Infinite_Loop()

{

HERE: goto HERE;

}

int main()

{

Output("Input_Halts = ", H0((u32)Infinite_Loop));

}

_Infinite_Loop()

[00001102](01) 55 push ebp

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

[00001105](02) ebfe jmp 00001105

[00001107](01) 5d pop ebp

[00001108](01) c3 ret

Size in bytes:(0007) [00001108]

> Others have a different opinion and argue that P does not call the

> hypothetical non-aborting H, but the actual aborting H, which does not

> go in infinite recursion, but returns false in a finite number of steps.

> Therefore, H's result is wrong.

>

> Is this a correct summary of the disagreement? If not, please, tell me

> where the summary failed. Maybe we can then find the point of divergence

> of opinions easier.

>

Aug 20, 2022, 2:32:14 PMAug 20

to

void Px(void (*x)())

{

(void) H(x, x);

return;

}

Px always halts if H returns to Px (and a valid halt decider must

always return a decision to its caller).

/Flibble

Aug 20, 2022, 2:32:59 PMAug 20

to

"Non-simulating" decider, but ANY decider, no matter how it determines

its answer.

The key error of Olcott, is the mistaken idea that just because H

happens to be a simulating Halt Decider, it gets to change the criteria

that it needs to decide on, and rather than being does the computation

the input represents [that is M(x) for a call to H(M,x) ], halt or never

halt, but can we decide instead of on a did "H need to abort its

simulation" criteria, and that this "need" affect EVERY COPY of H that

exists in the world. (He confuses that last point by mashing the code of

the decided program and the decider into a single program and having the

decided program share code with the decider instead of being an

independent copy, as it would need to be to actually implement as Turing

Machines.

Because of this, H is actually deciding on the wrong input, the H that

aborts is actually reporting the results of the input program P built on

the H that doesn't abort, which is a different input then the input

program P built on the H that does abort.

Aug 20, 2022, 2:50:22 PMAug 20

to

recursive simulation is easier to see.

void Px(void (*x)())

{

(void) HH(x, x);

return;

}

int main()

{

Output("Input_Halts = ", HH(Px, Px));

}

_Px()

[000010b2](01) 55 push ebp

[000010b3](02) 8bec mov ebp,esp

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

[000010b8](01) 50 push eax

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

[000010bc](01) 51 push ecx

[000010bd](05) e8e0fbffff call 00000ca2

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

[000010c5](01) 5d pop ebp

[000010c6](01) c3 ret

Size in bytes:(0021) [000010c6]

_main()

[000010d2](01) 55 push ebp

[000010d3](02) 8bec mov ebp,esp

[000010d5](05) 68b2100000 push 000010b2

[000010da](05) 68b2100000 push 000010b2

[000010df](05) e8befbffff call 00000ca2

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

[000010e7](01) 50 push eax

[000010e8](05) 6863040000 push 00000463

[000010ed](05) e890f3ffff call 00000482

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

[000010f5](02) 33c0 xor eax,eax

[000010f7](01) 5d pop ebp

[000010f8](01) c3 ret

Size in bytes:(0039) [000010f8]

machine stack stack machine assembly

address address data code language

======== ======== ======== ========= =============

[000010d2][00101b8d][00000000] 55 push ebp

[000010d3][00101b8d][00000000] 8bec mov ebp,esp

[000010d5][00101b89][000010b2] 68b2100000 push 000010b2

[000010da][00101b85][000010b2] 68b2100000 push 000010b2

[000010df][00101b81][000010e4] e8befbffff call 00000ca2

New slave_stack at:101c31

Begin Local Halt Decider Simulation Execution Trace Stored at:111c39

[000010b2][00111c25][00111c29] 55 push ebp

[000010b3][00111c25][00111c29] 8bec mov ebp,esp

[000010b5][00111c25][00111c29] 8b4508 mov eax,[ebp+08]

[000010b8][00111c21][000010b2] 50 push eax // push Px

[000010b9][00111c21][000010b2] 8b4d08 mov ecx,[ebp+08]

[000010bc][00111c1d][000010b2] 51 push ecx // push Px

[000010bd][00111c19][000010c2] e8e0fbffff call 00000ca2 // call HH

New slave_stack at:14c659

[000010b2][0015c64d][0015c651] 55 push ebp

[000010b3][0015c64d][0015c651] 8bec mov ebp,esp

[000010b5][0015c64d][0015c651] 8b4508 mov eax,[ebp+08]

[000010b8][0015c649][000010b2] 50 push eax // push Px

[000010b9][0015c649][000010b2] 8b4d08 mov ecx,[ebp+08]

[000010bc][0015c645][000010b2] 51 push ecx // push Px

[000010bd][0015c641][000010c2] e8e0fbffff call 00000ca2 // call HH

*Local Halt Decider: Infinite Recursion Detected Simulation Stopped*

*When HH(Px,Px) simulates its input it sees that*

(1) Function HH(Px,Px) is called twice in sequence from the same machine

address of Px().

(2) With the same arguments to HH(Px,Px).

(3) With no control flow instructions between the invocation of Px() and

its call to HH(Px,Px) that could possibly escape repeated simulations.

[000010e4][00101b8d][00000000] 83c408 add esp,+08

[000010e7][00101b89][00000000] 50 push eax

[000010e8][00101b85][00000463] 6863040000 push 00000463

[000010ed][00101b85][00000463] e890f3ffff call 00000482

Input_Halts = 0

[000010f2][00101b8d][00000000] 83c408 add esp,+08

[000010f5][00101b8d][00000000] 33c0 xor eax,eax

[000010f7][00101b91][00000018] 5d pop ebp

[000010f8][00101b95][00000000] c3 ret

Number of Instructions Executed(15322) == 229 Pages

Aug 20, 2022, 2:52:48 PMAug 20

to

On Sat, 20 Aug 2022 13:50:15 -0500

All your trace is doing is confirming that H gets the answer wrong, Px

halts. Until you resolve this false positive you do not have a valid

SHD.

/Flibble

halts. Until you resolve this false positive you do not have a valid

SHD.

/Flibble

Aug 20, 2022, 3:00:50 PMAug 20

to

machine description always provides the actual behavior specified by

this machine description.

That you and others reject this when it is applied to my simulating halt

decider implicitly rejects the notion of a UTM. Since you and others do

accept the notion of a UTM, I have just proven that your reasoning is

incoherent and/or inconsistent.

Whenever the simulating halt decider correctly predicts that its correct

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

of this input, then the SHD is correct to reject its input as non-halting.
*HERE IS THE SIMPLEST CASE OF THAT*

void Infinite_Loop()

{

HERE: goto HERE;

}

{

Output("Input_Halts = ", H0((u32)Infinite_Loop));

}

_Infinite_Loop()

[00001102](01) 55 push ebp

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

[00001105](02) ebfe jmp 00001105

[00001107](01) 5d pop ebp

[00001108](01) c3 ret
}

_Infinite_Loop()

[00001102](01) 55 push ebp

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

[00001105](02) ebfe jmp 00001105

[00001107](01) 5d pop ebp

Size in bytes:(0007) [00001108]

Aug 20, 2022, 3:06:39 PMAug 20

to

pure x86 emulation of its input until it correctly matches a non-halting

behavior pattern proving that the simulated input would never reach its

own final state.

(a) HH(Px,Px) simulates Px(Px) that calls a simulated HH(Px,Px)

(b) that simulates Px(Px) that calls a simulated HH(Px,Px)

(c) that simulates Px(Px) that calls a simulated HH(Px,Px)

(d) that simulates Px(Px) that calls a simulated HH(Px,Px)

*Until HH aborts its simulation*

All those having sufficient software engineering technical competence

can see this.

Aug 20, 2022, 3:09:11 PMAug 20

to

On Sat, 20 Aug 2022 14:06:32 -0500

Px always halts if H is a valid halt decider. Your H is not a valid

halt decider.

/Flibble

halt decider.

/Flibble

Aug 20, 2022, 3:18:36 PMAug 20

to

ignorance of software engineering yet are not fooling anyone that

actually has sufficient technical competence in software engineering.

** Utterly bereft of any supporting reasoning.

Aug 20, 2022, 3:27:52 PMAug 20

to

The H that answers non-halting does NOT do a COMPLETE simulation of its

input.

If that input is given to a UTM equivalent, the COMPLETE simulation of

that input (which still calls H) will Halt.

THUS, H was wrong.

>

> That you and others reject this when it is applied to my simulating halt

> decider implicitly rejects the notion of a UTM. Since you and others do

> accept the notion of a UTM, I have just proven that your reasoning is

> incoherent and/or inconsistent.

simulation of its input that will not halt even after an unbounded

number of steps.

>

> Whenever the simulating halt decider correctly predicts that its correct

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

> of this input, then the SHD is correct to reject its input as non-halting.

IF it doesn't actually DO a complete simulation, talking about what the

complete simulation it would do is MEANINGLESS.

You H is answering about a different input then the one given to it.

>

> *HERE IS THE SIMPLEST CASE OF THAT*

> void Infinite_Loop()

> {

> Â HERE: goto HERE;

> }

>

> int main()

> {

> Â Output("Input_Halts = ", H0((u32)Infinite_Loop));

> }

>

> _Infinite_Loop()

> [00001102](01)Â 55Â Â Â Â Â Â Â Â push ebp

> [00001103](02)Â 8becÂ Â Â Â Â Â mov ebp,esp

> [00001105](02)Â ebfeÂ Â Â Â Â Â jmp 00001105

> [00001107](01)Â 5dÂ Â Â Â Â Â Â Â pop ebp

> [00001108](01)Â c3Â Â Â Â Â Â Â Â ret

> Size in bytes:(0007) [00001108]

>

>

>

Fallacy of Proof by Exampe.

Aug 20, 2022, 3:29:39 PMAug 20

to

It is a figment of your imagination and VOIDS your "proof".

FAIL.

Aug 20, 2022, 3:30:48 PMAug 20

to

On Sat, 20 Aug 2022 14:18:28 -0500

Myself and others have provided supporting reasoning on many occasions

which you chose to simply ignore.

which you chose to simply ignore.

Aug 20, 2022, 3:32:56 PMAug 20

to

(a) Simulate Px(Px) that calls a sumulated HH(Px,Px)

(b) that simulates Px(Px) that calls a simulated HH(Px,Px)

(c) that simulates Px(Px) that calls a simulated HH(Px,Px)

(d) that simulates Px(Px) that calls a simulated HH(Px,Px)

(e) that simulates Px(Px) that calls a simulated HH(Px,Px)
(c) that simulates Px(Px) that calls a simulated HH(Px,Px)

(d) that simulates Px(Px) that calls a simulated HH(Px,Px)

*Until the SIMULATED HH from (a) abort ITS simulate.

(f) returns 0 to the simulated Px(Px) from (a)

(g) which returns, and thus Halts.

Thus, the COMPLETE simulation of the input to HH, which we agree shows

the actual behavior of the input to HH, comes to a Halt

The HH(Px,Px) returning 0 is INCORRECT.

Aug 20, 2022, 3:46:12 PMAug 20

to

simulation of the input to H(P,P):

void Px(void (*x)())

{

(void) Simulate(x, x);

return;

}

You provide the pure simulation at the wrong point in the execution

trace. In any case even in your incorrect execution trace the Px that HH

simulates never reaches its own final state, thus never halts.

Aug 20, 2022, 4:00:35 PMAug 20

to

Op 20.aug..2022 om 17:23 schreef olcott:

Thanks for the confirmation, because I was not completely sure about my

last sentence above. But I am glad that I understood you correctly that

your aborting H answers the question for P calling the hypothetical

non-aborting H.

You derive the final answer (for P calling the actual aborting H)

indirectly from the first answer, because it cannot be answered

directly, as it would not reach the return instruction.

last sentence above. But I am glad that I understood you correctly that

your aborting H answers the question for P calling the hypothetical

non-aborting H.

You derive the final answer (for P calling the actual aborting H)

indirectly from the first answer, because it cannot be answered

directly, as it would not reach the return instruction.

Aug 20, 2022, 4:04:49 PMAug 20

to

partial simulation of its input and the behavior of this partial

simulation correctly matches a non-halting behavior pattern then the

SHD halt decider can correctly report non-halting.

A non-halting behavior pattern is correct when-so-ever matching this

behavior pattern proves that the correct and complete simulation of the

input by SHD would never reach the final state of this simulated input.

Aug 20, 2022, 4:20:49 PMAug 20

to

When-so-ever a simulating halt decider (SHD) correctly performs a

partial simulation of its input and the behavior of this partial

simulation correctly matches a non-halting behavior pattern then the

SHD halt decider can correctly report non-halting.

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

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

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

A non-halting behavior pattern is correct when-so-ever matching this

behavior pattern proves that the correct and complete simulation of the
input by SHD would never reach the final state of this simulated input.

The above system equally applies to all non-halting inputs explicitly

including the pathological input defined below:

*In computability theory, the halting problem is the problem*

of determining, from a description of an arbitrary computer

program and an input, whether the program will finish running,

or continue to run forever. Alan Turing proved in 1936 that a

general algorithm to solve the halting problem for all possible

program-input pairs cannot exist.

For any program H that might determine if programs halt, a

"pathological" program P, called with some input, can pass its own

source and its input to H and then specifically do the opposite of

what H predicts P will do. *No H can exist that handles this case*

https://en.wikipedia.org/wiki/Halting_problem

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

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

*Two more inputs that are correctly decided using this same system*
void Infinite_Loop()

{

HERE: goto HERE;

}

{

Infinite_Recursion(N);

Aug 20, 2022, 4:35:37 PMAug 20

to

invalid.

/Flibble

Aug 20, 2022, 4:53:51 PMAug 20

to

so he is just pushing two silly arguments: (a) that H(X,Y) == false for

at least one X and Y where X(Y) halts is correct, despite it being

clearly wrong; and (b) that even specifying that H(X,Y) must answer

about X(Y), rather than something else that he's made up, is wrong.

Both objections are risible, yet that have managed to generate a lot of

posts!

The fuel for all the debate comes from the fact that PO has wisely

abandoned talking about Turing machines because there was not enough

room for confusion. After all, formal models of computation are

designed to facilitate clear and un-ambiguous proofs.

> The classical proof that it is not possible is the idea that it is

> always possible to create a program P that uses H, with itself as

> input, but behaves opposite to what H returns. In a C-like language it

> would be something like:

>

> void P(ptr x)

> {

> int Halt_Status = H(x, x);

> if (Halt_Status)

> HERE: goto HERE;

> return;

> }

>

> If there would be a hypothetical non-simulating non-aborting H, which

> would always halts with the correct answer, then it is clear that

> there would be a contradiction if we ask H about P with

> H(P,P). Because there are only three possibilities:

> 1. If H would return true (halting) in a finite number of steps, then

> P would start an endless loop, so H(P,P) does not halt in a finite

> number of steps.

> 2. If H would return false (non-halting) in a finite number of steps,

> then P returns immediately, so H returns a wrong result.

> 3. If H does not return, then it does not return in a finite number of

> steps, so it is not the H where the problem asked for.

>

> I think everybody agrees up to this point.

care about. There is absolutely no dispute about the facts that (1)

H(P,P) == false and (2) P(P) halts.

Every post in reply to PO should start and stop with that fact. There

is nothing else to talk about.

> Now Olcott has created a simulating aborting H, which, when given P

> with input P [so H(P,P)], creates a trace of the execution and at the

> point where P calls H, it uses the following logic: If H were the

> hypothetical non-aborting H, then an infinite recursion would happen

> at this point. Therefore, Olcott's simulating H aborts the simulation

> and returns false (0).

>

> Does everybody still agree up to this point?

what "would happen if" is in any way relevant to the halting problem.

He's been trying to sneak this trick past credulous readers for years in

many different disguises. P(P) halts, but it wouldn't if... is not

maths but junk. 33 would be prime if it weren't divisible by 3 and 11.

> Now the opinions diverge.

They diverged long before this! PO rejects the very idea that a halt

decider might tell up what we want to know: that H(X,Y) == false if, and

only if, X(Y) does not halt.

> Olcott thinks that his H gives the correct answer that P would not

> halt when P would call the hypothetical non-aborting H, so, it must

> also be the correct answer when P actually calls the actual aborting

> H.

coming up with ever more obscure what to justify the wrong answer, he

has toughly confused himself.

> Others have a different opinion and argue that P does not call the

> hypothetical non-aborting H, but the actual aborting H, which does not

> go in infinite recursion, but returns false in a finite number of

> steps. Therefore, H's result is wrong.

halting problem at the top of this post, H is wrong, not by virtue of

anything it does, but because it simply does not meet the definition of

a halt decider (even if it's only in this one instance).

> Is this a correct summary of the disagreement? If not, please, tell me

> where the summary failed. Maybe we can then find the point of

> divergence of opinions easier.

does not dispute the fact (and we not have the source code to see for

ourselves) that H(P,P) == false even though P(P) halts. These

undisputed facts should, in my opinion, be the start and end of every

reply to PO.

--

Ben.

Aug 20, 2022, 5:01:37 PMAug 20

to

It is common knowledge that the correct and complete simulation of a

machine description always provides the actual behavior specified by

this machine description.

machine description always provides the actual behavior specified by

this machine description.

That you and others reject this when it is applied to my simulating halt

decider implicitly rejects the notion of a UTM. Since you and others do

accept the notion of a UTM, I have just proven that your reasoning is

incoherent and/or inconsistent.

*NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS NO ERROR*
decider implicitly rejects the notion of a UTM. Since you and others do

accept the notion of a UTM, I have just proven that your reasoning is

incoherent and/or inconsistent.

When-so-ever a simulating halt decider (SHD) correctly performs a

partial simulation of its input and the behavior of this partial

simulation correctly matches a non-halting behavior pattern then the SHD

halt decider can correctly report non-halting.

A non-halting behavior pattern is correct when-so-ever matching this

behavior pattern proves that the correct and complete simulation of the

input by SHD would never reach the final state of this simulated input.

behavior pattern proves that the correct and complete simulation of the

input by SHD would never reach the final state of this simulated input.

Aug 20, 2022, 5:05:43 PMAug 20

to

P MUST be

void Px(void (*x)()) {

HH(x,x);

}

As that is the P that was defined.

Then have main be:

int main() {

// The original call to HH

Output("Input_Halts = ", HH(Px, Px));

// The test
Simulate(Px,Px);

Output("But Px(Px) Halts");

}

I.E just DO the correct and complete simulation of the input to HH.

That is the plain meaning of the words.

Youy keep on trying to change the P that is the input to H to "prove"

your answer.

THIS IS NOT ALLOWED, and shows that you are just a cheat.

Aug 20, 2022, 5:11:37 PMAug 20

to

>

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

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

>

> A non-halting behavior pattern is correct when-so-ever matching this

> behavior pattern proves that the correct and complete simulation of the

> input by SHD would never reach the final state of this simulated input.

The pattern is correct if when-so-ever matching this behavior pattern

proves that the correct and complete simulate of the input by a PURE

SIMULATOR would never reach the final state.

Note, your pattern even fails for your definition, as if the SHD has the

pattern in it, then it never actually does a correct and complete

simulation, so you can't "prove" what it does.

You don't get to look at P with a version of the SHD that doesn't have

the abort with a SHD that does have the abort and say that it passed the

test.

The P must use the SHD that decides it, which has the abort, which makes

the pattern incorrect.

FAIL.

Aug 20, 2022, 5:13:52 PMAug 20

to

*NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS NO ERROR*

When-so-ever a simulating halt decider (SHD) correctly performs a

partial simulation of its input and the behavior of this partial

simulation correctly matches a non-halting behavior pattern then the SHD

halt decider can correctly report non-halting.

partial simulation of its input and the behavior of this partial

simulation correctly matches a non-halting behavior pattern then the SHD

halt decider can correctly report non-halting.

A non-halting behavior pattern is correct when-so-ever matching this

behavior pattern proves that the correct and complete simulation of the
input by SHD would never reach the final state of this simulated input.

Aug 20, 2022, 5:14:58 PMAug 20

to

> A non-halting behavior pattern is correct when-so-ever matching this

> behavior pattern proves that the correct and complete simulation of the

> input by SHD would never reach the final state of this simulated input.

>

Not by the SHD, since BY DEFINITION, a SHD that had that pattern in it

would not do a complete simulation, so you have nothing to actually show

you were correcrt.

Please show the COMPLETE simulation of the input done by the SHD that

shows non-halting that it the exact same SHD that answers non-halting,

for an input that calls that SHD.

You need to test by a pure simulator, not the SHD.

FAIL.

Aug 20, 2022, 5:17:08 PMAug 20

to

On 8/20/22 5:01 PM, olcott wrote:

to be too dumb to understand it.

>

> When-so-ever a simulating halt decider (SHD) correctly performs a

> partial simulation of its input and the behavior of this partial

> simulation correctly matches a non-halting behavior pattern then the SHD

> halt decider can correctly report non-halting.

>

> A non-halting behavior pattern is correct when-so-ever matching this

> behavior pattern proves that the correct and complete simulation of the

> input by SHD would never reach the final state of this simulated input.

>

>

>

are just talking about POOP.

Halting is based on the ACTUAL EXECTUION of the machine, not by an

aborted simulation done by the SHD.

Sometimes it is right, but not in this case.

FAIL.

Aug 20, 2022, 5:18:52 PMAug 20

to

> When-so-ever a simulating halt decider (SHD) correctly performs a

> partial simulation of its input and the behavior of this partial

> simulation correctly matches a non-halting behavior pattern then the SHD

> halt decider can correctly report non-halting.

>

> A non-halting behavior pattern is correct when-so-ever matching this

> behavior pattern proves that the correct and complete simulation of the

> input by SHD would never reach the final state of this simulated input.

>

>

refute, which is just proof that you don't have a clue how to attempt

because you understand you are wrong.

You are just proving you are a pathological liar, or totally utterly

incompetent and stupid.

FAIL.

Aug 20, 2022, 5:27:24 PMAug 20

to

of the input would be if the SHD performed a correct and complete

simulation of this input.

The fact that the simulated input never reaches its own final state in

the above case conclusively proves that this input specifies a

non-halting sequence of instructions.

Aug 20, 2022, 5:29:42 PMAug 20

to

It is common knowledge that the correct and complete simulation of a

machine description always provides the actual behavior specified by

this machine description.

Therefore the actual behavior of the actual input is what the behavior

of the input would be if the SHD performed a correct and complete
machine description always provides the actual behavior specified by

this machine description.

Therefore the actual behavior of the actual input is what the behavior

simulation of this input.

The fact that the simulated input would never reach its own final state

in the above case conclusively proves that this input specifies a

non-halting sequence of instructions.

non-halting sequence of instructions.

Aug 20, 2022, 5:59:35 PMAug 20

to

>

> Therefore the actual behavior of the actual input is what the behavior

> of the input would be if the SHD performed a correct and complete

> simulation of this input.

>

abort it. The "SHD that does a complete simulation" is a different

function than the one deciding, so it isn't the one that P is calling,

so its behavior is irrelvent.

> The fact that the simulated input would never reach its own final state

> in the above case conclusively proves that this input specifies a

> non-halting sequence of instructions.

>

The fact that Simulate(Px,Px) does Halt for any HH that answers

HH(Px,Px) proves that it is wrong to say non-halting.

Simulate(Px,Px) is what you just references (if not by name) as the

correct and complete simulation of the machine description that was

given to HH.

You keep on having two different functions that you call H (or HH) that

you conflate in your logic.

It doesn't matter what H/HH would have done if different, it matters

what the P does that calls the H/HH that you do have.

Aug 20, 2022, 6:00:33 PMAug 20

to

>

> Therefore the actual behavior of the actual input is what the behavior

> of the input would be if the SHD performed a correct and complete

> simulation of this input.

>

> The fact that the simulated input never reaches its own final state in

> the above case conclusively proves that this input specifies a

> non-halting sequence of instructions.

>

>

Aug 20, 2022, 6:11:58 PMAug 20

to

On 8/20/2022 3:18 PM, Richard Damon wrote:

>

> On 8/20/22 5:13 PM, olcott wrote:

<SNIP> garbage
>

> On 8/20/22 5:13 PM, olcott wrote:

> I just showed you the error which you didn't bother even trying to

> refute, which is just proof that you don't have a clue how to attempt

> because you understand you are wrong.

>

> You are just proving you are a pathological liar, or totally utterly

> incompetent and stupid.

should be obvious after decades of this bullshit.

--

Jeff Barnett

Aug 20, 2022, 6:33:15 PMAug 20

to

machine description always provides the actual behavior specified by

this machine description.

(2) Therefore the actual behavior of the actual input is what the
this machine description.

behavior of the input would be if the SHD performed a correct and

complete simulation of this input.

(3) The fact that the simulated input would never reach its own final
complete simulation of this input.

state in the above case conclusively proves that this input specifies a

non-halting sequence of instructions.

Because (1) is known to be true and (2) logically follows from (1) it is
non-halting sequence of instructions.

impossible to correctly accept (1) and deny (2).

Aug 20, 2022, 6:59:24 PMAug 20

to

there is no "If it didn't" case to look at.

What is the results of program X doing operation Y if program X never

actually does operation Y.

It is an ill defined condition.

> (3) The fact that the simulated input would never reach its own final

> state in the above case conclusively proves that this input specifies a

> non-halting sequence of instructions.

>

> Because (1) is known to be true and (2) logically follows from (1) it is

> impossible to correctly accept (1) and deny (2).

>

could do the following.

H is defined to take THREE parameters:

P the program to decide on,

d the data for that program, and

s a flag that forces the decider to be a pure simulator and not a decider.

THen

H(P,d,0) is correct to return 1 if H(P,d,1) Halts, and

H(P,d,0) is correct to return 0 if H(P,d,1) will never halt but run forever.

P(x) is then defined to call H(x,x,0)

And the H to decide it by the call H(P,P,0)

You will find that by your logic:

H(P,P,0) will return 0, but H(P,P,1) will Halt, so it is wrong.

Or we will see that H(P,P,1) doesn't actually correctly simulate its

input, for instance if it thinks that the call H(P,P,0) in P behaves

differently then the call to H(P,P,0) done by main.

NOW you can ask about what the H would do if it doesn't abort, because

you can make that happen without changing the code for H.

Changing the code for H isn't allowed, as that affects the "input" to H,

since it is the x86 assembly code for the PROGRAM P (not just the

function) as that is what the definitions require.

Aug 20, 2022, 7:10:21 PMAug 20

to

execution trace.

x86utm Halt7.obj 1 // runs every instance of H as a pure simulator

x86utm Halt7.obj 0 // runs every instance of H as a halt decider

Aug 20, 2022, 7:28:10 PMAug 20

to

The simulating halt decider writes a 1 or a 0 to a specific tape

location that is initialized to blank. It does this as soon as it

correctly detects that its complete simulation would never stop running.

HERE IS THE KEY DIFFERENCE:

H continues to perform this complete simulation, thus never stops

running. Because it has reported this it is correct.

The assumption that H must stop to report its decision is refuted.

Aug 20, 2022, 7:40:30 PMAug 20

to

and x86utm Halts7.obj 0 will have H answer about the wrong P, it answers

about the P in the other case, which is wrong.

This can be shown by having main call P(P) and show that it returns.

You don't change the H that P calls, because that is changing the input

to H.

FAIL.

You are just

Aug 20, 2022, 7:42:13 PMAug 20

to

Your H you just defined never answers, so fails to be a decider.

FAIL.

You just don't know how Turing Machines work.

Can H "return" a value if it never returns?

NO.

>

Aug 20, 2022, 8:14:54 PMAug 20

to

IS A FALSE ASSUMPTION.

As soon as H knows the answer it writes a 1 or a 0 to a specific tape

location and then it keeps on running.

Aug 20, 2022, 8:16:05 PMAug 20

to

is correct.

> and x86utm Halts7.obj 0 will have H answer about the wrong P, it answers

> about the P in the other case, which is wrong.

> This can be shown by having main call P(P) and show that it returns.

>

>

> You don't change the H that P calls, because that is changing the input

> to H.

>

> FAIL.

>

> You are just

Aug 20, 2022, 9:06:40 PMAug 20

to

FAIL.

That parameter changed th e behavior of H, you are looking at the wrong

function P.

The CORRECT way to do that was as I described it above:

The behavior of H(P,P,1) verifies the correct answer for H(P,P,0)

Aug 20, 2022, 9:07:36 PMAug 20

to

Not how Turing Machine work.

Not how C functions work either.

FAIL.

You are just proving your ignorance.

Aug 20, 2022, 9:10:25 PMAug 20

to

and comments that this is without loss of generality.

That is because if you defined you H to write the answer on a given

location of the tape, you just need to add a "tail" to the Turing

Machine to go to that location on the tape and then go to the accept

state or reject state, becuase the tape is only looked at when the

machine halts.

DEFINITIONS you know.

Aug 20, 2022, 9:45:18 PMAug 20

to

at the first element of its tape?

> Not how C functions work either.

>

> FAIL.

>

> You are just proving your ignorance.

Aug 20, 2022, 9:48:57 PMAug 20

to

This is because the results are usable until it does (if, for instance,

you attach the algorithm for another Turing Machine after it.)

You are just showing your ignorance.

Aug 20, 2022, 9:50:07 PMAug 20

to

and keep on running. That the TM must halt to decide is simply not true.

This is another case where CS simply didn't bother to think things through.

> That is because if you defined you H to write the answer on a given

> location of the tape, you just need to add a "tail" to the Turing

> Machine to go to that location on the tape and then go to the accept

> state or reject state, becuase the tape is only looked at when the

> machine halts.

>

> DEFINITIONS you know.

running after reporting 0 it is wrong so it has to keep on running to

meet your objection.

Aug 20, 2022, 10:04:53 PMAug 20

to

reasoning. People that only learn things by rote never notice that some

rules have no actual basis in reasoning and are thus merely arbitrary

conventions.

> This is because the results are usable until it does (if, for instance,

> you attach the algorithm for another Turing Machine after it.)

>

report the results. This machine could light up a 40 foot billboard that

says H(P,P) has correctly determined that its input does not halt.

None of this convoluted nonsense is required if you simply accept the

fact that the simulating halt decider is already correct.

> You are just showing your ignorance.

>

>>

>>

>>> Not how C functions work either.

>>>

>>> FAIL.

>>>

>>> You are just proving your ignorance.

>>

>>

>>

>>

>

Aug 20, 2022, 10:08:03 PMAug 20

to

Does a C function "Return an answer" if it never reaches its return

instruction?

Remember, we are talking "Single Threaded" computations here.

Seams you are having problem with fundamental definition of basic

computer programming.

Remember the DEFINITION of a Decider, a Machine that HALTS for all inputs.

You H isn't a decider if it doesn't halt, so can't be a Halt Decder.

>

>> That is because if you defined you H to write the answer on a given

>> location of the tape, you just need to add a "tail" to the Turing

>> Machine to go to that location on the tape and then go to the accept

>> state or reject state, becuase the tape is only looked at when the

>> machine halts.

>>

>> DEFINITIONS you know.

>

> Another TM would have to do that because you insist that when H stops

> running after reporting 0 it is wrong so it has to keep on running to

> meet your objection.

>

Note, another TM can't access the tape of this TM except by cascading

there code, so they become part of a larger TM.

You ar just showing your ignorance.

Aug 20, 2022, 10:14:02 PMAug 20

to

Can you C function H return an answer to Main and still keep running?

Nope.

>

>> This is because the results are usable until it does (if, for

>> instance, you attach the algorithm for another Turing Machine after it.)

>>

>

> An other TM can be constantly polling that fixed memory location and

> report the results. This machine could light up a 40 foot billboard that

> says H(P,P) has correctly determined that its input does not halt.

FAIL.

PROOF of your Ignorance.

Note, if it could do that, then P could, and once H signals that the

answer is there, then P gets the signal and halts.

You can't have it both ways.

>

> None of this convoluted nonsense is required if you simply accept the

> fact that the simulating halt decider is already correct.

It ISN"t Correct, because if it gives an answer so that someone can use

it, P can use it and act contrary.

If it hasn't given an answer so P can use it, it hasn't given an answer

that anything else can use.

FAIL.

Aug 20, 2022, 10:18:50 PMAug 20

to

On Saturday, August 20, 2022 at 6:45:18 PM UTC-7, olcott wrote:

> So you are saying that it is impossible for a TM to write a binary digit

> at the first element of its tape?

>

The concept "first element of its tape" is ambigious and usually
> So you are saying that it is impossible for a TM to write a binary digit

> at the first element of its tape?

>

defined so as to be constantly changing. How something like

H returns anything needs to be carefully defined. Perhaps Linz

does define it elsewhere in his book.

Aug 20, 2022, 10:40:22 PMAug 20

to

so there is a first element. This does lead to other issues that need to

be handled.

PO just thinks of the tape as memory locations, so the concept of

element NOT having a address whould be too confusing for him.

Aug 20, 2022, 11:08:04 PMAug 20

to

tapes thus inherently have a first element.

page 10

https://basics.sjtu.edu.cn/~yuxi/teaching/computability2013/slides/4.%20Turing%20Machine.pdf

Aug 21, 2022, 2:10:10 AMAug 21

to

On Saturday, August 20, 2022 at 8:08:04 PM UTC-7, olcott wrote:

> On 8/20/2022 9:18 PM, dklei...@gmail.com wrote:

> > On Saturday, August 20, 2022 at 6:45:18 PM UTC-7, olcott wrote:

> >

> >> So you are saying that it is impossible for a TM to write a binary digit

> >> at the first element of its tape?

> >>

> > The concept "first element of its tape" is ambigious and usually

> > defined so as to be constantly changing. How something like

> > H returns anything needs to be carefully defined. Perhaps Linz

> > does define it elsewhere in his book.

> At least some of the definitions of TM's have only a unidirectional

> tapes thus inherently have a first element.

>

> page 10

> https://basics.sjtu.edu.cn/~yuxi/teaching/computability2013/slides/4.%20Turing%20Machine.pdf

That version of Turing Machines is somewhat eccentric. I wonder
> On 8/20/2022 9:18 PM, dklei...@gmail.com wrote:

> > On Saturday, August 20, 2022 at 6:45:18 PM UTC-7, olcott wrote:

> >

> >> So you are saying that it is impossible for a TM to write a binary digit

> >> at the first element of its tape?

> >>

> > The concept "first element of its tape" is ambigious and usually

> > defined so as to be constantly changing. How something like

> > H returns anything needs to be carefully defined. Perhaps Linz

> > does define it elsewhere in his book.

> At least some of the definitions of TM's have only a unidirectional

> tapes thus inherently have a first element.

>

> page 10

> https://basics.sjtu.edu.cn/~yuxi/teaching/computability2013/slides/4.%20Turing%20Machine.pdf

what the situation is among the research community. Is there any

kind of consensus today about what a standard Turing Machine

is. Is the machine described in Wikipedia the standard?

Aug 21, 2022, 5:00:13 AMAug 21

to

On 2022-08-20 15:01:34 +0000, Fred. Zwarts said:

> Op 17.aug..2022 om 18:46 schreef Mr Flibble:

>> Olcott, which of the following do you think is more likely?

>>

>> 1) Olcott is correct and everybody else is wrong.

>> 2) Olcott is wrong and everybody else is correct.

>>

>> Which one is more likely hasn't changed for all the years you've been

>> attempting to shill your simulating halting decider. I find it amusing

>> that I came up with, in less than 24 hours, a simulating halting

>> decider that doesn't have the flaws your SHD has.

>>

>> /Flibble

>>

>

> I have been following these discussions for many months now. I have a

> strong impression that there is little progress. It seems that people

> are running in circles. I am not an expert in this field. Maybe it

> helps if a non-expert tries to summarize the discussion. Please, be

> patient when correcting me if I make any mistake.

>

> First the problem this is al about:

> In computation theory we can denote a program with X and its input with

> Y, which together is denoted as X(Y). X(Y) may end (halt) in a finite

> number of steps, but another program X and/or input Y may not halt in a

> finite number of steps. The question is, is it possible to create a

> program H that when given any program X with its input Y can tell in a

> finite number of steps whether X(Y) halts or not? In other words, will

> H(X,Y) always halt after a finite number of steps with the correct

> answer f

> Op 17.aug..2022 om 18:46 schreef Mr Flibble:

>> Olcott, which of the following do you think is more likely?

>>

>> 1) Olcott is correct and everybody else is wrong.

>> 2) Olcott is wrong and everybody else is correct.

>>

>> Which one is more likely hasn't changed for all the years you've been

>> attempting to shill your simulating halting decider. I find it amusing

>> that I came up with, in less than 24 hours, a simulating halting

>> decider that doesn't have the flaws your SHD has.

>>

>> /Flibble

>>

>

> I have been following these discussions for many months now. I have a

> strong impression that there is little progress. It seems that people

> are running in circles. I am not an expert in this field. Maybe it

> helps if a non-expert tries to summarize the discussion. Please, be

> patient when correcting me if I make any mistake.

>

> First the problem this is al about:

> In computation theory we can denote a program with X and its input with

> Y, which together is denoted as X(Y). X(Y) may end (halt) in a finite

> number of steps, but another program X and/or input Y may not halt in a

> finite number of steps. The question is, is it possible to create a

> program H that when given any program X with its input Y can tell in a

> finite number of steps whether X(Y) halts or not? In other words, will

> H(X,Y) always halt after a finite number of steps with the correct

> answer f