info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
It looks like I can exactly duplicate the Linz proof in x86 without static data
2 views
Skip to first unread message
olcott
Sep 21, 2021, 10:25:36 PM9/21/21
to
void P(u8* program)
{
u8* input;
CopyMemory(program, input);
u32 Input_Halts = halt_decider(program, input);
if (Input_Halts)
HERE: goto HERE;
}
int main()
{
u8* program = (u8*)Allocate(1024);
u8* input;
CopyMemory3((u8*)P, (u8*)program);
CopyMemory(program, input);
Output("Input_Halts = ", halt_decider(program, input));
}
As with my other proofs the halt status is correctly decided.
This paper will be completely rewritten with my new findings as soon as
they are fully operational. The key feasibility test elements are
already fully operational. The architectural design is complete.
To the best of my current knowledge the only steps required to make this
system fully operational are relatively minor ordinary C/x86 operating
system level programming.
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
{
u8* input;
CopyMemory(program, input);
u32 Input_Halts = halt_decider(program, input);
if (Input_Halts)
HERE: goto HERE;
}
int main()
{
u8* program = (u8*)Allocate(1024);
u8* input;
CopyMemory3((u8*)P, (u8*)program);
CopyMemory(program, input);
Output("Input_Halts = ", halt_decider(program, input));
}
As with my other proofs the halt status is correctly decided.
This paper will be completely rewritten with my new findings as soon as
they are fully operational. The key feasibility test elements are
already fully operational. The architectural design is complete.
To the best of my current knowledge the only steps required to make this
system fully operational are relatively minor ordinary C/x86 operating
system level programming.
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
olcott
Sep 21, 2021, 11:28:46 PM9/21/21
to
On 9/21/2021 9:25 PM, olcott wrote:
> void P(u8* program)
> {
> u8* input;
> CopyMemory(program, input);
> u32 Input_Halts = halt_decider(program, input);
> if (Input_Halts)
> HERE: goto HERE;
> }
>
>
int main()
{
u8* input = (u8*)Allocate(1024);
> void P(u8* program)
> {
> u8* input;
> CopyMemory(program, input);
> u32 Input_Halts = halt_decider(program, input);
> if (Input_Halts)
> HERE: goto HERE;
> }
>
>
int main()
{
CopyMemory3((u8*)P, (u8*)input);
Output("Input_Halts = ", halt_decider((u32)P, input));
}
This might be more consistent with Linz.
olcott
Sep 22, 2021, 2:47:02 PM9/22/21
to
On 9/21/2021 9:51 PM, Richard Damon wrote:
>
>
> Note, one SIGNIFICANT difference between your P and Linz-H^ is that your
> P doesn't include a copy of H, but H is somehow 'outside' the machine
> but used by it.
>
> This might make P not really a computaton, as its behavor is dependent
> on something outside of it that isn't a formal input.
>
This is about as close as I can get to H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
P has its own halt decider named H() yet P is decided by another
different instance named H1().
void P(u8* program)
{
u8* input;
CopyMemory(program, input);
u32 Input_Halts = H(program, input);
CopyMemory3((u8*)P, input);
Output("Input_Halts = ", H1((u32)P, input));
}
Soon to be completely rewritten to conform to the above newly defined
process:
> On 9/21/21 10:25 PM, olcott wrote:
>> void P(u8* program)
>> {
>> u8* input;
>> CopyMemory(program, input);
>> u32 Input_Halts = halt_decider(program, input);
>> if (Input_Halts)
>> HERE: goto HERE;
>> }
>>
>>
>> int main()
>> {
>> u8* program = (u8*)Allocate(1024);
>> u8* input;
>> CopyMemory3((u8*)P, (u8*)program);
>> CopyMemory(program, input);
>> Output("Input_Halts = ", halt_decider(program, input));
>> }
>>
>> As with my other proofs the halt status is correctly decided.
>>
>> This paper will be completely rewritten with my new findings as soon as
>> they are fully operational. The key feasibility test elements are
>> already fully operational. The architectural design is complete.
>>
>> To the best of my current knowledge the only steps required to make this
>> system fully operational are relatively minor ordinary C/x86 operating
>> system level programming.
>>
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>>
>
> You may want to add some allocations of input.
>> void P(u8* program)
>> {
>> u8* input;
>> CopyMemory(program, input);
>> u32 Input_Halts = halt_decider(program, input);
>> if (Input_Halts)
>> HERE: goto HERE;
>> }
>>
>>
>> int main()
>> {
>> u8* program = (u8*)Allocate(1024);
>> u8* input;
>> CopyMemory3((u8*)P, (u8*)program);
>> CopyMemory(program, input);
>> Output("Input_Halts = ", halt_decider(program, input));
>> }
>>
>> As with my other proofs the halt status is correctly decided.
>>
>> This paper will be completely rewritten with my new findings as soon as
>> they are fully operational. The key feasibility test elements are
>> already fully operational. The architectural design is complete.
>>
>> To the best of my current knowledge the only steps required to make this
>> system fully operational are relatively minor ordinary C/x86 operating
>> system level programming.
>>
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>>
>
>
>
> Note, one SIGNIFICANT difference between your P and Linz-H^ is that your
> P doesn't include a copy of H, but H is somehow 'outside' the machine
> but used by it.
>
> This might make P not really a computaton, as its behavor is dependent
> on something outside of it that isn't a formal input.
>
This is about as close as I can get to H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
P has its own halt decider named H() yet P is decided by another
different instance named H1().
void P(u8* program)
{
u8* input;
CopyMemory(program, input);
if (Input_Halts)
HERE: goto HERE;
}
int main()
{
u8* input;
HERE: goto HERE;
}
int main()
{
CopyMemory3((u8*)P, input);
Output("Input_Halts = ", H1((u32)P, input));
}
Soon to be completely rewritten to conform to the above newly defined
process:
olcott
Sep 22, 2021, 5:02:49 PM9/22/21
to
On 9/22/2021 5:46 AM, Richard Damon wrote:
> On 9/21/21 11:50 PM, André G. Isaak wrote:
>> separate *programs*, not just two functions called from within a single
>> main. The halting program, after all, is about a program which can
>> answer a question about another program; not a program which can answer
>> a question about part of itself.
>>
>> That means two separate, self-contained executables, each of which will
>> contain its own copy of halt_decider which cannot therefore occupy the
>> same machine address.
>>
>> André
>>
>
> No, they don't need to be separate programs, as in .exe, in actual
> construction. That is an unimportant detail.
>
> H and H^/P do need to be COMPLETE PROGRAMS in the sense that they are
> self contained. His current P calling halt_decider can be a violation of
> that he will probably utilize to cheat.
>
> His function P is not a computation by itself, as it uses code that
> isn't part of itself. thus we can't make a Turing Machine of 'just P'.
>
> THus the fact that he makes a copy of 'just P' to pass to itself says
> that his P isn't actually the equivalent of Linz H^.
>
This is about as self-contained as I can make it:
This is about as close as I can get to H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
P has its own halt decider named H() yet P is decided by another
different instance named H1().
> On 9/21/21 11:50 PM, André G. Isaak wrote:
>> On 2021-09-21 20:25, olcott wrote:
>>> void P(u8* program)
>>> {
>>> u8* input;
>>> CopyMemory(program, input);
>>> u32 Input_Halts = halt_decider(program, input);
>>> if (Input_Halts)
>>> HERE: goto HERE;
>>> }
>>>
>>>
>>> int main()
>>> {
>>> u8* program = (u8*)Allocate(1024);
>>> u8* input;
>>> CopyMemory3((u8*)P, (u8*)program);
>>> CopyMemory(program, input);
>>> Output("Input_Halts = ", halt_decider(program, input));
>>> }
>>>
>>> As with my other proofs the halt status is correctly decided.
>>>
>>> This paper will be completely rewritten with my new findings as soon
>>> as they are fully operational. The key feasibility test elements are
>>> already fully operational. The architectural design is complete.
>>>
>>> To the best of my current knowledge the only steps required to make
>>> this system fully operational are relatively minor ordinary C/x86
>>> operating system level programming.
>>
>> Well, no. The other thing you need to do is write it so your H and P are
>>> void P(u8* program)
>>> {
>>> u8* input;
>>> CopyMemory(program, input);
>>> u32 Input_Halts = halt_decider(program, input);
>>> if (Input_Halts)
>>> HERE: goto HERE;
>>> }
>>>
>>>
>>> int main()
>>> {
>>> u8* program = (u8*)Allocate(1024);
>>> u8* input;
>>> CopyMemory3((u8*)P, (u8*)program);
>>> CopyMemory(program, input);
>>> Output("Input_Halts = ", halt_decider(program, input));
>>> }
>>>
>>> As with my other proofs the halt status is correctly decided.
>>>
>>> This paper will be completely rewritten with my new findings as soon
>>> as they are fully operational. The key feasibility test elements are
>>> already fully operational. The architectural design is complete.
>>>
>>> To the best of my current knowledge the only steps required to make
>>> this system fully operational are relatively minor ordinary C/x86
>>> operating system level programming.
>>
>> separate *programs*, not just two functions called from within a single
>> main. The halting program, after all, is about a program which can
>> answer a question about another program; not a program which can answer
>> a question about part of itself.
>>
>> That means two separate, self-contained executables, each of which will
>> contain its own copy of halt_decider which cannot therefore occupy the
>> same machine address.
>>
>> André
>>
>
> No, they don't need to be separate programs, as in .exe, in actual
> construction. That is an unimportant detail.
>
> H and H^/P do need to be COMPLETE PROGRAMS in the sense that they are
> self contained. His current P calling halt_decider can be a violation of
> that he will probably utilize to cheat.
>
> His function P is not a computation by itself, as it uses code that
> isn't part of itself. thus we can't make a Turing Machine of 'just P'.
>
> THus the fact that he makes a copy of 'just P' to pass to itself says
> that his P isn't actually the equivalent of Linz H^.
>
This is about as self-contained as I can make it:
This is about as close as I can get to H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
P has its own halt decider named H() yet P is decided by another
different instance named H1().
void P(u8* program)
{
u8* input;
CopyMemory(program, input);
u32 Input_Halts = H(program, input);
{
u8* input;
CopyMemory(program, input);
if (Input_Halts)
HERE: goto HERE;
}
int main()
{
HERE: goto HERE;
}
int main()
{
u8* input;
CopyMemory3((u8*)P, input);
Output("Input_Halts = ", H1((u32)P, input));
}
Soon to be completely rewritten to conform to the above newly defined
process:
CopyMemory3((u8*)P, input);
Output("Input_Halts = ", H1((u32)P, input));
}
Soon to be completely rewritten to conform to the above newly defined
process:
olcott
Sep 22, 2021, 10:30:57 PM9/22/21
to
On 9/22/2021 9:13 PM, Richard Damon wrote:
> On 9/22/21 9:49 PM, olcott wrote:
>> On 9/22/2021 7:54 PM, Richard Damon wrote:
>
>>> You seem to have a reading comprehension issue. If you know about that
>>> you should admit it and tell us.
>>>
>>> Please re=read what I said.
>>>
>>> I said that I agreed that any case that is TRUELY infinitely recursive,
>>> no copy of any of the functions will return to their caller.
>>>
>> I know how I can clearly demarcate between you and I which one of us is
>> confused. You tell me how a function could determine that it has been
>> called in infinite recursion and abort its caller on this basis.
>>
>> According to everything that you have said your answer would have to be
>> that it simply can't do this.
>>
>
> To 100% accurately detect infinite recursion requires solving the
> halting problem FIRST, so yes, it can't be done, and you haven't.
>
> You got something right!!
>
> Note also, H isn't allowed to abort 'its caller', if it does that it
> fails at its job of being a decider.
>
> Since H is claimed to be a 'simulator', this whole thing is in fact
> irrelevant, as the simulator never gets stuck itself in recursion.
>
So that all merely proves that you remain utterly clueless about how a
simulating halt decider could detect that it is is being called in
the simplest possible case of infinite simulation and abort this
otherwise infinite simulation.
void P(u32 x)
{
H(x, x);
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
> On 9/22/21 9:49 PM, olcott wrote:
>> On 9/22/2021 7:54 PM, Richard Damon wrote:
>
>>> You seem to have a reading comprehension issue. If you know about that
>>> you should admit it and tell us.
>>>
>>> Please re=read what I said.
>>>
>>> I said that I agreed that any case that is TRUELY infinitely recursive,
>>> no copy of any of the functions will return to their caller.
>>>
>> I know how I can clearly demarcate between you and I which one of us is
>> confused. You tell me how a function could determine that it has been
>> called in infinite recursion and abort its caller on this basis.
>>
>> According to everything that you have said your answer would have to be
>> that it simply can't do this.
>>
>
> To 100% accurately detect infinite recursion requires solving the
> halting problem FIRST, so yes, it can't be done, and you haven't.
>
> You got something right!!
>
> Note also, H isn't allowed to abort 'its caller', if it does that it
> fails at its job of being a decider.
>
> Since H is claimed to be a 'simulator', this whole thing is in fact
> irrelevant, as the simulator never gets stuck itself in recursion.
>
So that all merely proves that you remain utterly clueless about how a
simulating halt decider could detect that it is is being called in
the simplest possible case of infinite simulation and abort this
otherwise infinite simulation.
void P(u32 x)
{
H(x, x);
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
olcott
Sep 23, 2021, 8:36:40 AM9/23/21
to
On 9/22/2021 10:37 PM, Richard Damon wrote:
>>
>
> i.e., like most of the time when you do this, your causght and have run
> out of tricks.
>
> The H -> H^ -> H invocation loop CAN'T be infinite if H can answer and H
> is a Computation.
>
> PERIOD.
>
> YOU are the one apperently over your head
>
It is easy to see who is confused when I ask you to provide the
architectural design of a system such that H simulates P with an x86
emulator until H detects that P is calling H in infinitely nested
simulation. Actual software engineers could do this.
void P(u32 x)
{
H(x, x);
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
That you cannot begin to imagine something as this sufficiently proves
that your software engineering skill is not in the same ballpark as mine.
>
> On 9/22/21 9:45 PM, olcott wrote:
>> On 9/22/2021 7:54 PM, Richard Damon wrote:
>
>>> You seem to have a reading comprehension issue. If you know about that
>>> you should admit it and tell us.
>>>
>>> Please re=read what I said.
>>>
>>> I said that I agreed that any case that is TRUELY infinitely recursive,
>>> no copy of any of the functions will return to their caller.
>>>
>> I am not going to go over this again it is clearly over your head.
> On 9/22/21 9:45 PM, olcott wrote:
>> On 9/22/2021 7:54 PM, Richard Damon wrote:
>
>>> You seem to have a reading comprehension issue. If you know about that
>>> you should admit it and tell us.
>>>
>>> Please re=read what I said.
>>>
>>> I said that I agreed that any case that is TRUELY infinitely recursive,
>>> no copy of any of the functions will return to their caller.
>>>
>>
>
> i.e., like most of the time when you do this, your causght and have run
> out of tricks.
>
> The H -> H^ -> H invocation loop CAN'T be infinite if H can answer and H
> is a Computation.
>
> PERIOD.
>
> YOU are the one apperently over your head
>
It is easy to see who is confused when I ask you to provide the
architectural design of a system such that H simulates P with an x86
emulator until H detects that P is calling H in infinitely nested
simulation. Actual software engineers could do this.
void P(u32 x)
{
H(x, x);
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
that your software engineering skill is not in the same ballpark as mine.
olcott
Sep 26, 2021, 2:29:06 PM9/26/21
to
On 9/21/2021 9:25 PM, olcott wrote:
> void P(u8* program)
> {
> u8* input;
> CopyMemory(program, input);
> u32 Input_Halts = halt_decider(program, input);
> if (Input_Halts)
> HERE: goto HERE;
> }
>
>
> int main()
> {
> u8* program = (u8*)Allocate(1024);
> u8* input;
> CopyMemory3((u8*)P, (u8*)program);
> CopyMemory(program, input);
> Output("Input_Halts = ", halt_decider(program, input));
> }
>
> As with my other proofs the halt status is correctly decided.
>
> This paper will be completely rewritten with my new findings as soon as
> they are fully operational. The key feasibility test elements are
> already fully operational. The architectural design is complete.
>
> To the best of my current knowledge the only steps required to make this
> system fully operational are relatively minor ordinary C/x86 operating
> system level programming.
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>
This was my key 2016 Breakthrough:
> {
> u8* input;
> CopyMemory(program, input);
> u32 Input_Halts = halt_decider(program, input);
> if (Input_Halts)
> HERE: goto HERE;
> }
>
>
> int main()
> {
> u8* program = (u8*)Allocate(1024);
> u8* input;
> CopyMemory3((u8*)P, (u8*)program);
> CopyMemory(program, input);
> Output("Input_Halts = ", halt_decider(program, input));
> }
>
> As with my other proofs the halt status is correctly decided.
>
> This paper will be completely rewritten with my new findings as soon as
> they are fully operational. The key feasibility test elements are
> already fully operational. The architectural design is complete.
>
> To the best of my current knowledge the only steps required to make this
> system fully operational are relatively minor ordinary C/x86 operating
> system level programming.
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>
The halting theorem counter-examples present infinitely nested
simulation (non-halting) behavior to every simulating halt decider.
It looks like I will be able to reproduce my original results where the
halt_decider is a pure function.
(1) The function return values are identical for identical arguments (no
variation with local static variables, non-local variables, mutable
reference arguments or input streams).
(2) The function application has no side effects (no mutation of local
static variables, non-local variables, mutable reference arguments or
input/output streams).
https://en.wikipedia.org/wiki/Pure_function
olcott
Sep 27, 2021, 1:42:05 PM9/27/21
to
On 9/27/2021 12:05 PM, Jeff Barnett wrote:
> On 9/27/2021 8:19 AM, olcott wrote:
>> On 9/27/2021 12:15 AM, Jeff Barnett wrote:
>>> On 9/26/2021 10:31 PM, olcott wrote:
>>>> On 9/26/2021 10:56 PM, André G. Isaak wrote:
> <CRAP DELETED>
>>>>
>>>> So then maybe you are stupid or ignorant, The actual code itself
>>>> cycles from 0xc36 though 0xc41 an infinite number of times unless
>>>> H(P,P) aborts the simulation of its input. In that case the
>>>> simulation is cut off at 0xc41. In no case does this code reach
>>>> final state 0xc50.
>>>
>>> <CRAP DELETED>
>>>
>>> So you now admit that your x86 simulator is flawed? Or maybe it
>>> isn't, but you set it up wrong or are using it incorrectly? You need
>>> to do something other than software; you're just not very good at it
>>> you know. Working in an area where you are inadequate causes you to
>>> act like a bad person out of frustration. Here you are calling Andre
>>> stupid and ignorant for trying to help you and make you better. You
>>> should say "thank you" instead of being such a crappy person. You
>>> should change your area of study to something simple like cooking
>>> rice. A few successes would improve your self image and stop the name
>>> calling and tantrums. You are no longer 3 years old. Time to mature a
>>> little.
>>
>> You are a clueless wonder that only has utterly baseless nay saying.
>
> More name calling; so out of control. a recapitulation of the "terrible
> threes". Concentrate; control yourself; be grateful for help offered to
> you. Time's short; strive for adulthood now. We are all rooting for you.
> Give life as an adult a chance while you have that opportunity. Good luck.
You are the only one with utterly baseless critique of my work. The only
critique of the {essence of my work} that has not been baseless has been
the key issue of what is required for a C function to meet the standard
of the theory of computation computable function.
There have been numerous times when I used a technical term of the art
in ways that slightly differ from their conventional meaning. Some of
these times may be accurately construed as errors. Some of these times
are cases where the term of the art was the closest approximation to the
meaning that I intended thus not exactly an actual error. Imprecise use
of terms of the art may reduce my credibility yet has no impact
what-so-ever on the validity of the essence of my work.
It is true that without the reviews of my work on comp.theory that my
work would have never been completed. This deserves gratitude to the
reviewers of my work on comp.theory. Even though what these reviewers
presented as an error was almost never any actual error at all these
reviews did help me increasingly clarify my position to best address
objections to this position.
The most exasperating critique of my work is when reviewers essentially
disagree that a {black cat} is either {black} or a {cat}.
_P()
[00000c36](01) 55 push ebp
[00000c37](02) 8bec mov ebp,esp
[00000c39](03) 8b4508 mov eax,[ebp+08] // 2nd Param
[00000c3c](01) 50 push eax
[00000c3d](03) 8b4d08 mov ecx,[ebp+08] // 1st Param
[00000c40](01) 51 push ecx
[00000c41](05) e820fdffff call 00000966 // call H
[00000c46](03) 83c408 add esp,+08
[00000c49](02) 85c0 test eax,eax
[00000c4b](02) 7402 jz 00000c4f
[00000c4d](02) ebfe jmp 00000c4d
[00000c4f](01) 5d pop ebp
[00000c50](01) c3 ret
Size in bytes:(0027) [00000c50]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
Begin Local Halt Decider Simulation at Machine Address:c36
[00000c36][002117ca][002117ce] 55 push ebp
[00000c37][002117ca][002117ce] 8bec mov ebp,esp
[00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
[00000c3c][002117c6][00000c36] 50 push eax // push P
[00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][002117c2][00000c36] 51 push ecx // push P
[00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)
Disagreeing that the input to H(P,P) never reaches its final state of
0xc50 whether or not simulating halt decider H stops simulating its
input is one of the cases where a {black cat} is denied being either
{black} or a {cat}.
> On 9/27/2021 8:19 AM, olcott wrote:
>> On 9/27/2021 12:15 AM, Jeff Barnett wrote:
>>> On 9/26/2021 10:31 PM, olcott wrote:
>>>> On 9/26/2021 10:56 PM, André G. Isaak wrote:
> <CRAP DELETED>
>>>>
>>>> So then maybe you are stupid or ignorant, The actual code itself
>>>> cycles from 0xc36 though 0xc41 an infinite number of times unless
>>>> H(P,P) aborts the simulation of its input. In that case the
>>>> simulation is cut off at 0xc41. In no case does this code reach
>>>> final state 0xc50.
>>>
>>> <CRAP DELETED>
>>>
>>> So you now admit that your x86 simulator is flawed? Or maybe it
>>> isn't, but you set it up wrong or are using it incorrectly? You need
>>> to do something other than software; you're just not very good at it
>>> you know. Working in an area where you are inadequate causes you to
>>> act like a bad person out of frustration. Here you are calling Andre
>>> stupid and ignorant for trying to help you and make you better. You
>>> should say "thank you" instead of being such a crappy person. You
>>> should change your area of study to something simple like cooking
>>> rice. A few successes would improve your self image and stop the name
>>> calling and tantrums. You are no longer 3 years old. Time to mature a
>>> little.
>>
>> You are a clueless wonder that only has utterly baseless nay saying.
>
> More name calling; so out of control. a recapitulation of the "terrible
> threes". Concentrate; control yourself; be grateful for help offered to
> you. Time's short; strive for adulthood now. We are all rooting for you.
> Give life as an adult a chance while you have that opportunity. Good luck.
You are the only one with utterly baseless critique of my work. The only
critique of the {essence of my work} that has not been baseless has been
the key issue of what is required for a C function to meet the standard
of the theory of computation computable function.
There have been numerous times when I used a technical term of the art
in ways that slightly differ from their conventional meaning. Some of
these times may be accurately construed as errors. Some of these times
are cases where the term of the art was the closest approximation to the
meaning that I intended thus not exactly an actual error. Imprecise use
of terms of the art may reduce my credibility yet has no impact
what-so-ever on the validity of the essence of my work.
It is true that without the reviews of my work on comp.theory that my
work would have never been completed. This deserves gratitude to the
reviewers of my work on comp.theory. Even though what these reviewers
presented as an error was almost never any actual error at all these
reviews did help me increasingly clarify my position to best address
objections to this position.
The most exasperating critique of my work is when reviewers essentially
disagree that a {black cat} is either {black} or a {cat}.
_P()
[00000c36](01) 55 push ebp
[00000c37](02) 8bec mov ebp,esp
[00000c39](03) 8b4508 mov eax,[ebp+08] // 2nd Param
[00000c3c](01) 50 push eax
[00000c3d](03) 8b4d08 mov ecx,[ebp+08] // 1st Param
[00000c40](01) 51 push ecx
[00000c41](05) e820fdffff call 00000966 // call H
[00000c46](03) 83c408 add esp,+08
[00000c49](02) 85c0 test eax,eax
[00000c4b](02) 7402 jz 00000c4f
[00000c4d](02) ebfe jmp 00000c4d
[00000c4f](01) 5d pop ebp
[00000c50](01) c3 ret
Size in bytes:(0027) [00000c50]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
Begin Local Halt Decider Simulation at Machine Address:c36
[00000c36][002117ca][002117ce] 55 push ebp
[00000c37][002117ca][002117ce] 8bec mov ebp,esp
[00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
[00000c3c][002117c6][00000c36] 50 push eax // push P
[00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][002117c2][00000c36] 51 push ecx // push P
[00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)
Disagreeing that the input to H(P,P) never reaches its final state of
0xc50 whether or not simulating halt decider H stops simulating its
input is one of the cases where a {black cat} is denied being either
{black} or a {cat}.
Jeff Barnett
Sep 27, 2021, 2:05:23 PM9/27/21
to
lies and contradictions no matter how much you try to change the
subject. I, on the other hand, will not let you off from your childish
(NB, I did not say child-like) behavior until we can see a maturation
process started. Given your off the mark, ignorant ideas and tantrums,
can you imagine how these howlers are perceived at the end of your messages:
"Copyright 2021 Pete Olcott
'Great spirits have always encountered violent opposition from
mediocre minds.' Einstein"
dribble. No not a soul. And as the king/queen of mediocrity, well can
you imagine the giggle when anyone reads it? Who do they think it's
about. Do you need a hint?
--
Jeff Barnett
olcott
Sep 27, 2021, 2:31:51 PM9/27/21
to
The halting theorem counter-examples present infinitely nested
simulation (non-halting) behavior to every simulating halt decider.
I presented this to Ben more than four years ago and he successfully
simulation (non-halting) behavior to every simulating halt decider.
changed the subject with various dishonest dodges so that it could not
be properly evaluated until now.
Infinitely Recursive input on HP Proofs
peteolcott
Mar 11, 2017, 3:13:03 PM
https://groups.google.com/g/comp.theory/c/NcFS02hKs1U
All of the "rebuttals" have taken the form of the strawman error:
The halting theorem does not specify a simulating halt decider.
This is no actual rebuttal to the original claim at all.
--
Jeff Barnett
Sep 27, 2021, 2:54:05 PM9/27/21
to
On 9/27/2021 12:31 PM, olcott wrote:
<CRAP SNAP>
> This is the key basis of my refutation of the halting theorem:
> The halting theorem counter-examples present infinitely nested
> simulation (non-halting) behavior to every simulating halt decider.
>
> I presented this to Ben more than four years ago and he successfully
> changed the subject with various dishonest dodges so that it could not
> be properly evaluated until now.
>
> Infinitely Recursive input on HP Proofs
> peteolcott
> Mar 11, 2017, 3:13:03 PM
> https://groups.google.com/g/comp.theory/c/NcFS02hKs1U
>
> All of the "rebuttals" have taken the form of the strawman error:
> The halting theorem does not specify a simulating halt decider.
> This is no actual rebuttal to the original claim at all.
No one but you has been dishonest. And that is a two decade truth. If
Martin Davis or Peter Lintz said they now had doubt of the halting
theorem, the world would be excited. We would expect to learn something
new about model theory or a new theory of computation. Also, most of us
would be a little sad: Since this was an extremely well pawed over area,
we would expect the insight to occur at such a deep level that we may or
may not be able to enjoy it either through lack of ability or of
knowledge at the state of the art. You, on the other hand are repeating
problems first discussed and analyzed by the pre Greeks. Today, the liar
paradox is for the amusement of school children, not logicians or
mathematicians. You are several thousand years late. The issues which
drive you are the stuff of Penny Problem Solver collections. There is a
book called "What is the name of this book?". Get a copy and read it
while there is time.
In any event, stop this childish repetition of non sense. Give adulthood
a chance. We are not all destined for fame and immortality for our brain
power. It's certain you are not. Even if your brain was adequate to do
world class work, your personality disorders disqualify you. You refuse
to listen, you refuse to learn, and you throw constant tantrums. The
technical world is much too sophisticated for a genius to walk in off
the streets and present a new earth shaking method to bake bread, let
alone do a new computation theory. You really do need to study more and
learn from the masters.
Your current plan has made you appear (and be) a classic case of
ignorance morphed into stupidity. You need to grow up.
Jeff Barnett
<CRAP SNAP>
> This is the key basis of my refutation of the halting theorem:
> The halting theorem counter-examples present infinitely nested
> simulation (non-halting) behavior to every simulating halt decider.
>
> I presented this to Ben more than four years ago and he successfully
> changed the subject with various dishonest dodges so that it could not
> be properly evaluated until now.
>
> Infinitely Recursive input on HP Proofs
> peteolcott
> Mar 11, 2017, 3:13:03 PM
> https://groups.google.com/g/comp.theory/c/NcFS02hKs1U
>
> All of the "rebuttals" have taken the form of the strawman error:
> The halting theorem does not specify a simulating halt decider.
> This is no actual rebuttal to the original claim at all.
Martin Davis or Peter Lintz said they now had doubt of the halting
theorem, the world would be excited. We would expect to learn something
new about model theory or a new theory of computation. Also, most of us
would be a little sad: Since this was an extremely well pawed over area,
we would expect the insight to occur at such a deep level that we may or
may not be able to enjoy it either through lack of ability or of
knowledge at the state of the art. You, on the other hand are repeating
problems first discussed and analyzed by the pre Greeks. Today, the liar
paradox is for the amusement of school children, not logicians or
mathematicians. You are several thousand years late. The issues which
drive you are the stuff of Penny Problem Solver collections. There is a
book called "What is the name of this book?". Get a copy and read it
while there is time.
In any event, stop this childish repetition of non sense. Give adulthood
a chance. We are not all destined for fame and immortality for our brain
power. It's certain you are not. Even if your brain was adequate to do
world class work, your personality disorders disqualify you. You refuse
to listen, you refuse to learn, and you throw constant tantrums. The
technical world is much too sophisticated for a genius to walk in off
the streets and present a new earth shaking method to bake bread, let
alone do a new computation theory. You really do need to study more and
learn from the masters.
Your current plan has made you appear (and be) a classic case of
ignorance morphed into stupidity. You need to grow up.
Jeff Barnett
olcott
Sep 27, 2021, 3:07:36 PM9/27/21
to
On 9/27/2021 1:53 PM, Jeff Barnett wrote:
> On 9/27/2021 12:31 PM, olcott wrote:
> <CRAP SNAP>
>
>> This is the key basis of my refutation of the halting theorem:
>> The halting theorem counter-examples present infinitely nested
>> simulation (non-halting) behavior to every simulating halt decider.
>>
>> I presented this to Ben more than four years ago and he successfully
>> changed the subject with various dishonest dodges so that it could not
>> be properly evaluated until now.
>>
>> Infinitely Recursive input on HP Proofs
>> peteolcott
>> Mar 11, 2017, 3:13:03 PM
>> https://groups.google.com/g/comp.theory/c/NcFS02hKs1U
>>
>> All of the "rebuttals" have taken the form of the strawman error:
>> The halting theorem does not specify a simulating halt decider.
>> This is no actual rebuttal to the original claim at all.
>
>
> No one but you has been dishonest.
I triple dog dare you to show how the above key basis of my refutation
> On 9/27/2021 12:31 PM, olcott wrote:
> <CRAP SNAP>
>
>> This is the key basis of my refutation of the halting theorem:
>> The halting theorem counter-examples present infinitely nested
>> simulation (non-halting) behavior to every simulating halt decider.
>>
>> I presented this to Ben more than four years ago and he successfully
>> changed the subject with various dishonest dodges so that it could not
>> be properly evaluated until now.
>>
>> Infinitely Recursive input on HP Proofs
>> peteolcott
>> Mar 11, 2017, 3:13:03 PM
>> https://groups.google.com/g/comp.theory/c/NcFS02hKs1U
>>
>> All of the "rebuttals" have taken the form of the strawman error:
>> The halting theorem does not specify a simulating halt decider.
>> This is no actual rebuttal to the original claim at all.
>
>
> No one but you has been dishonest.
is incorrect. https://www.youtube.com/watch?v=ZLZj3zOUZNs
olcott
Sep 27, 2021, 4:44:32 PM9/27/21
to
On 9/27/2021 2:52 PM, Ben Bacarisse wrote:
Of course you know that I am net talking about a simulator being used as
it it was a halt decider thus your reply is the same dishonest dodge
intentional (thus dishonest) strawman error as always.
> Of course you
> know this, which is why your putative decider is not a simulator but a
> partial simulator. It too fails to be a halt decider, as does every
> Turing machine. That's why you must declare false to be the correct
> answer for some halting computations.
> you have not even read the "proper" proof in Linz. The one that you can
> understand is only presented for historical reasons.
>
The logical flaw is that the halting theorem attempts to show that the
halting problem is undecidable by a counter-example that is clearly
decidable as non-halting.
> The fact that a simulator can't be a halt decider (and there are more
> reasons for that than the one you cite above) does not show a flaw in
> any proof.
>
Of course a simulator cannot by itself be a halt decider and it is
ridiculously dishonest of you to imply that this is what I mean.
>> All of the "rebuttals" have taken the form of the strawman error:
>> The halting theorem does not specify a simulating halt decider.
>> This is no actual rebuttal to the original claim at all.
>
> No, the rebuttals start with a simple fact: false is not the correct
> answer for a halting computation. The rest of the rebuttal comes from
> you (it has to since you are carefully hiding the code):
>
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
// because the simulation of ⟨Ĥ⟩ applied to ⟨Ĥ⟩ by Ĥ.qx DOES NOT HALT
The computation of Ĥ applied to ⟨Ĥ⟩ is a distinctly different
computation than the computation of the simulation of ⟨Ĥ⟩ applied to ⟨Ĥ⟩
by Ĥ.qx.
If we want to specify a computation that is equivalent to Ĥ applied to
⟨Ĥ⟩ we must specify H applied to ⟨Ĥ⟩ ⟨Ĥ⟩. H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
The difference is that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ invokes a copy of Ĥ.qx
whereas the input to H does not invoke a copy of H.
The pathological self-reference error that I first discovered in 2004 is
the key to finally resolved these otherwise undecidable decision problem
inputs.
comp.theory
Halting Problem Final Conclusion
Peter Olcott Sep 5, 2004,
The Liar Paradox can be shown to be nothing more than
a incorrectly formed statement because of its pathological
self-reference. The Halting Problem can only exist because
of this same sort of pathological self-reference.
https://groups.google.com/g/comp.theory/c/RO9Z9eCabeE/m/Ka8-xS2rdEEJ
> olcott <No...@NoWhere.com> writes:
>
>> This is the key basis of my refutation of the halting theorem:
>> The halting theorem counter-examples present infinitely nested
>> simulation (non-halting) behavior to every simulating halt decider.
>
> This is one reason a simulator can't be a halt decider.
>
>> This is the key basis of my refutation of the halting theorem:
>> The halting theorem counter-examples present infinitely nested
>> simulation (non-halting) behavior to every simulating halt decider.
>
Of course you know that I am net talking about a simulator being used as
it it was a halt decider thus your reply is the same dishonest dodge
intentional (thus dishonest) strawman error as always.
> Of course you
> know this, which is why your putative decider is not a simulator but a
> partial simulator. It too fails to be a halt decider, as does every
> Turing machine. That's why you must declare false to be the correct
> answer for some halting computations.
>
>> This is the key basis of my refutation of the halting theorem:
>
> You would have to find a logical flaw in the proofs. All of them. But
>> This is the key basis of my refutation of the halting theorem:
>
> you have not even read the "proper" proof in Linz. The one that you can
> understand is only presented for historical reasons.
>
The logical flaw is that the halting theorem attempts to show that the
halting problem is undecidable by a counter-example that is clearly
decidable as non-halting.
> The fact that a simulator can't be a halt decider (and there are more
> reasons for that than the one you cite above) does not show a flaw in
> any proof.
>
Of course a simulator cannot by itself be a halt decider and it is
ridiculously dishonest of you to imply that this is what I mean.
>> All of the "rebuttals" have taken the form of the strawman error:
>> The halting theorem does not specify a simulating halt decider.
>> This is no actual rebuttal to the original claim at all.
>
> answer for a halting computation. The rest of the rebuttal comes from
> you (it has to since you are carefully hiding the code):
>
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
// because the simulation of ⟨Ĥ⟩ applied to ⟨Ĥ⟩ by Ĥ.qx DOES NOT HALT
The computation of Ĥ applied to ⟨Ĥ⟩ is a distinctly different
computation than the computation of the simulation of ⟨Ĥ⟩ applied to ⟨Ĥ⟩
by Ĥ.qx.
If we want to specify a computation that is equivalent to Ĥ applied to
⟨Ĥ⟩ we must specify H applied to ⟨Ĥ⟩ ⟨Ĥ⟩. H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
The difference is that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ invokes a copy of Ĥ.qx
whereas the input to H does not invoke a copy of H.
The pathological self-reference error that I first discovered in 2004 is
the key to finally resolved these otherwise undecidable decision problem
inputs.
comp.theory
Halting Problem Final Conclusion
Peter Olcott Sep 5, 2004,
The Liar Paradox can be shown to be nothing more than
a incorrectly formed statement because of its pathological
self-reference. The Halting Problem can only exist because
of this same sort of pathological self-reference.
https://groups.google.com/g/comp.theory/c/RO9Z9eCabeE/m/Ka8-xS2rdEEJ
olcott
Sep 27, 2021, 11:28:19 PM9/27/21
to
On 9/27/2021 10:14 PM, André G. Isaak wrote:
> On 2021-09-27 20:52, olcott wrote:
>> On 9/27/2021 9:40 PM, André G. Isaak wrote:
>>> On 2021-09-27 20:05, olcott wrote:
>>>> 9/27/2021 8:45 PM, Ben Bacarisse wrote:
>>>
>>>> You know that the input to a halt decider is a TM description and
>>>> not a TM. This means that you know that it is not about whether or
>>>> not Ĥ halts.
>>>>
>>>> It it about whether or not the simulation of the first parameter ⟨Ĥ⟩
>>>> to Ĥ.qx halts on its input ⟨Ĥ⟩.
>>>
>>> The position you're taking here is, to put it bluntly, simply absurd.
>>>
>>> A halt decider takes a description of a computation as its input. It
>>> is supposed to determine whether the computation described by that
>>> description halts.
>> It is not about whether or not Ĥ halts on ⟨Ĥ⟩.
>> It is about whether or not the simulation of ⟨Ĥ⟩ on ⟨Ĥ⟩ at Ĥ.qx halts.
>
> I was not commenting on your (mis)use of notation and nothing in your
> response even remotely addressed what I was saying. I was commenting on
> the ridiculous statement that "You know that the input to a halt decider
> is a TM description and not a TM. This means that you know that it is
> not about whether or not Ĥ halts."
>
> This statement is simply wrong. Spectacularly wrong. If you don't
> understand what the halting problem is even about, you shouldn't be
> working on it at all.
>
> André
>
It may seem that way to you only because you have not bothered to think
it all the way through.
It may be that you fail to comprehend the following, yet a failure of
comprehension is less than no rebuttal at all:
H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ is computationally equivalent to Ĥ applied to ⟨Ĥ⟩.
Ĥ applied to ⟨Ĥ⟩ is NOT computationally equivalent to H applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
It turns out that when the input program P calls the same halt decider H
that is deciding its halting status this is computationally distinct
from another identically coded halt decider H1 that is not called by the
input program P.
> On 2021-09-27 20:52, olcott wrote:
>> On 9/27/2021 9:40 PM, André G. Isaak wrote:
>>> On 2021-09-27 20:05, olcott wrote:
>>>> 9/27/2021 8:45 PM, Ben Bacarisse wrote:
>>>
>>>> You know that the input to a halt decider is a TM description and
>>>> not a TM. This means that you know that it is not about whether or
>>>> not Ĥ halts.
>>>>
>>>> It it about whether or not the simulation of the first parameter ⟨Ĥ⟩
>>>> to Ĥ.qx halts on its input ⟨Ĥ⟩.
>>>
>>> The position you're taking here is, to put it bluntly, simply absurd.
>>>
>>> A halt decider takes a description of a computation as its input. It
>>> is supposed to determine whether the computation described by that
>>> description halts.
>>>
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ halts, and
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>> if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt
>>
>> I merely adapted the Linz annotations to be more clear.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ halts, and
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>> if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt
>>
>> It is not about whether or not Ĥ halts on ⟨Ĥ⟩.
>> It is about whether or not the simulation of ⟨Ĥ⟩ on ⟨Ĥ⟩ at Ĥ.qx halts.
>
> I was not commenting on your (mis)use of notation and nothing in your
> response even remotely addressed what I was saying. I was commenting on
> the ridiculous statement that "You know that the input to a halt decider
> is a TM description and not a TM. This means that you know that it is
> not about whether or not Ĥ halts."
>
> This statement is simply wrong. Spectacularly wrong. If you don't
> understand what the halting problem is even about, you shouldn't be
> working on it at all.
>
> André
>
It may seem that way to you only because you have not bothered to think
it all the way through.
It may be that you fail to comprehend the following, yet a failure of
comprehension is less than no rebuttal at all:
H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ is computationally equivalent to Ĥ applied to ⟨Ĥ⟩.
Ĥ applied to ⟨Ĥ⟩ is NOT computationally equivalent to H applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
It turns out that when the input program P calls the same halt decider H
that is deciding its halting status this is computationally distinct
from another identically coded halt decider H1 that is not called by the
input program P.
0 new messages