XPost: comp.theory, sci.logic, sci.math
On 6/9/22 11:53 AM, olcott wrote:
On 6/9/2022 10:30 AM, wij wrote:
On Thursday, 9 June 2022 at 22:13:33 UTC+8, richar...@gmail.com wrote:
On 6/9/22 9:43 AM, wij wrote:
On Thursday, 9 June 2022 at 11:58:39 UTC+8, olcott wrote:
On 6/8/2022 12:00 PM, wij wrote:
On Wednesday, 8 June 2022 at 23:53:23 UTC+8, olcott wrote:
On 6/8/2022 10:37 AM, wij wrote:
On Wednesday, 8 June 2022 at 08:43:00 UTC+8, Mr Flibble wrote: >>>>>>>>> Hi,
From discussion with Olcott in comp.lang.c++ I have determined >>>>>>>>> that
his so called refutation of the HP proofs is based around the >>>>>>>>> behaviour of his simulation-based decider, H:
void Q(u32 x)
{
if (H(x, x))
FUBAR();
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Q, (u32)Q));
}
He asserts H(Q,Q)=0 based on a nested simulation being detected >>>>>>>>> (i.e. Q
invoking H) irregardless of whether FUBAR halts or not.
If FUBAR halts H gives the wrong answer.
He claims H(Q,Q)=0 as it gets stuck in a recursive (nested)
simulation
however that wouldn't be the case for non-simulating decider >>>>>>>>> for which
there would be no such recursion.
Can we finally put this to bed and change the fucking topic? >>>>>>>>>
/Flibble
+-----------------------------------------------------------------+ >>>>>>>> | The HP proof has nothing to do with how the 'H' is constructed. | >>>>>>>> +-----------------------------------------------------------------+ >>>>>>>> Many such liar's-paradox-like examples are for easy
comprehension (for educational purpose).
The real 'H' inside P is an algorithm computationally equivalent >>>>>>>> to 'H' (so, no
any 'call' is there, and the pattern matching tech. is very
difficult, by now to say.
And, this 'H' is also allowed given by some super intelligent
god.... whatever).
It is the pathological self reference(Olcott 2004) relationship
between
H and P that has previously been considered to make P undecidable >>>>>>> for H.
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
As you said the input P to H is pathological. Isn't POOH computing >>>>>> pathological inputs and producing pathological output?
+------------------------------------------------+
| olcott's brain is incapable of logic function. |
| (other kind of functions seem quite excellent) |
+------------------------------------------------+
It should be safe to say any concept involves logical operation, >>>>>>>> olcott cannot
make it formally correct (he relies on his "language's logic"). >>>>>>>> For example, I doubt he can handle several lines of
inter-connected codes.
...
All should be fine... except olcott now insists "H(P,P)==0" is >>>>>>>> correct while
there is no definition of H shown.
I am not claiming that H(P,P) correctly determines the halt
status of
its input. I am claiming that non-halting is the correct halt
status of
its input.
So, why POOH needs input? and to determine what?
And, why POOH halts and "H(P,P)==0"?
If you have to reread this 10,000 times to notice what the
difference is
then do that.
To determine the correct halt status for the input to H(P,P) we
don't
need to know anything about H besides that fact H uses an x86
emulator
to emulate its input.
Are you asking reviewers not to see the definition of H and must
agree "H(P,P)=0" is correct?
Everybody understands POOH is a manual thing. I doubt the 'x86
emulator' even exists at all?
https://github.com/wfeldt/libx86emu
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
Are you suggesting your 'x86 emulator' exists (built from a library)?
Your programming skill/knowledge is at shockingly idiotic level, as
have been
demonstrated publicly for years:
Does anybody believe a guy had problem understand "#define u32
uint32_t",...
can really build some real programs?
You seem always believe the P (10-lines program) a work of 'software
engineering'
from a competent software engineer (you). Can a 10-lines program, in
any sense
,relate to 'software engineering'? There are more:
x86 operation system --> 10-line-code + OS? (no such thing)
x86utm --> TM? (no such thing)
A recent one, string matching: show people functional codes doing
the string matching
(in H) and return 0.
Actually, I have no problem with your 'exhaustive scheme'.
My interpretaion of what has been done (going from what Olcott claims,
we can't be sure because he hides behind a cloak of secrecy because the
deception he does is apparently too fragile to let others see how it
actually works) is:
He started from the above linked Emulator for an basic x86 CPU.
He has spent the last decade+ modifying the code to generate the trace
he wants it to, in plainer words, to LIE about what the actual code does >>> to imply what he want.
He has written support code using the hooks provided by the linked
library to perform his halt deciding.
Note, this means that the subroutine H that P is calling, isn't actually >>> the code that is doing the Halt deciding, but that halt deciding has
been effectively embedded into the "CPU" via these hook functions,
perhaps with some "special" instructions to access the special
resources.
This points out why Peter can't allow P to have its own copy of H, H
isn't really a "program" in his system, but part of the system itself.
Yes, this means that perhaps he can "break" the pathological referal to
the decider, because the decider is no long in the same class of
computations as it is deciding on.
This means his system fails to meet at least some of the requirements in >>> the following ways, we can't tell which ones, because he hides the
details.:
1) His computation environment might not be Turing Complete, there being >>> some programs that can not be expressed by a computational equivalent in >>> his environment.
2) Related to 1, his H uses capabilities that can not be expressed in
his environment.
3) His H is using the fact that in Stored Program Machines, we can build >>> program fragments that aren't actually computations, and thus might not
be eligable to be deciders, or things that can be decided on. [Halting
is SPECIFICALY a property of actual Computation, and the Halting Mapping >>> is a fixed definite map, so a "decider" that can give different answers
for the same exact input CAN NOT be correct.]
4) His P isn't actually built by the specifications. H^ (what he calls
P) needs to use a copy of the FULL algorithm that is deciding on it.
That means that the H it calls must acually be the full algorithm that
will be used to decide on it, and thus, because it must be a
computation, it must give the same answer/behavior as that decider.
WHen I first saw what PO was proposing, it was clear that H and P are
not actually independent programs. H needs to be compiled and linked
with its "input", and P needs to be compiled and link with the decider
that is going to decide it.
There can be several interpretation of HP (or, liar's paradox in
broader sense).
olcott is incapable of logic reasoning.
From my point of view, the difficult part of the HP is to prove P
exists:
In other words when we look at the code that you have listed below there might not be any code there are all it might actually be a blank spot on
the screen and what appears to be code is merely a hallucination.
You don't understand. For P to exist as an ACTUAL program, then all the
code it calls must exist as an actual program.
The question is, does H exist as an actual program, or is H just a shim
that interface to the emulator, and thus is not actually an independent
program that can just be run.
If H can only exist inside the special universe of the x86UTM program,
then it fails to be an actual independent program, and thus, so does P.
void P(u32 x)
{
if (H(P,P)) // this P
HERE: goto HERE;
return;
}
Or, in case of "P(P)", I mean the argument P is more difficult to
express existent.
This should correspond to the coding of expressions to number like in
Gödel's
incompleteness theorems and other similar proofs I am not sure (I
don't really
understand this part but choose to believe).
Thanks to olcott, he brought this to my attention.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)