void P(u8* program)
{
u8* input;
CopyMemory(program, input);
u32 Input_Halts = halt_decider(program, input);
if (Input_Halts)
HERE: goto HERE;
}
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
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.
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.
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
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^.
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 thatI know how I can clearly demarcate between you and I which one of us is
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.
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.
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 thatI am not going to go over this again it is clearly over your head.
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
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
On 9/27/2021 8:19 AM, olcott wrote:
On 9/27/2021 12:15 AM, Jeff Barnett wrote:<CRAP DELETED>
On 9/26/2021 10:31 PM, olcott wrote:
On 9/26/2021 10:56 PM, André G. Isaak wrote:
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.
On 9/27/2021 11:41 AM, olcott wrote:
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:<CRAP DELETED>
On 9/26/2021 10:31 PM, olcott wrote:
On 9/26/2021 10:56 PM, André G. Isaak wrote:
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}.
You are still out of control. Ben will not let you off from specific
lies and contradictions no matter how much you try to change the
subject.
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.
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.
olcott <NoOne@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.
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
you have not even read the "proper" proof in Linz. The one that you can understand is only presented for historical reasons.
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.
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):
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.
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é
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 56:16:43 |
| Calls: | 6,652 |
| Calls today: | 4 |
| Files: | 12,200 |
| Messages: | 5,330,867 |