wij <wyniijj2@gmail.com> writes:
Students of average level understand Halting decider cannot exist, as olcott >> has demonstrated for years (no 'correct' H exists).
If H does not exist, what dose "H(P,P)==0" mean?
H as specified in, say, Linz does not exist. But PO's H does and so P
(which should really be called something like H_Hat) also exists.
That's why H is wrong about the "halting" of P(P).
Another way to write the proof is to show that every Turing machine gets
at least one instance wrong -- i.e. that no TM computes the halting
function. PO's H is just an example of that, and he even tells us that
it gets the instance representing P(P) wrong.
H(P,P) must return 0 because the actual behavior specified by the actual
input never halts.
The true answer is derived from the real H, not you.
A proof that "H(P,P)==0 is correct" without showing what the H is is a garbage proof, unconditionally.
reviewers need to see exactly the 'jack shit' how H is defined.Reviewers may need to see exactly how H is defined to determine that
H(P,P) does correctly determine the halt status of its input.
Reviewers absolutely need to see exactly how H is defined to determine that
H(P,P) does correctly determine the halt status of its input.
Reviewers DO NOT NEED TO SEE EXACTLY HOW H IS DEFINED TO KNOW THAT
H(P,P)==0 IS THE CORRECT HALT STATUS VALUE FOR THE "IMPOSSIBLE" INPUT.
What do you expect reviewers to say about H while H is not shown (empty)? Reviewers cannot deduce any answer from empty declaration (no contents).
Declaration/stipulation and implement/proof are two different things.You are "GUR" growling at me?
You boasted long ago that you have implemented H. Where is it?
Are you suggesting/admitting GUR is correct (no correct Halting decider can exist)?
I have conclusively proved that H(P,P)==0 is correct.
The real H cannot exist (by GUR, and proved by the absence of POOH).
On 6/6/2022 1:36 PM, Ben wrote:
wij <wyniijj2@gmail.com> writes:
Students of average level understand Halting decider cannot exist, as
olcott
has demonstrated for years (no 'correct' H exists).
If H does not exist, what dose "H(P,P)==0" mean?
H as specified in, say, Linz does not exist. But PO's H does and so P
(which should really be called something like H_Hat) also exists.
That's why H is wrong about the "halting" of P(P).
Another way to write the proof is to show that every Turing machine gets
at least one instance wrong -- i.e. that no TM computes the halting
function. PO's H is just an example of that, and he even tells us that
it gets the instance representing P(P) wrong.
int sum(int x, int y)
{
return x + y;
}
H(P,P) must return 0 because the actual behavior specified by the actual input never halts.
To say that H(P,P) must return a value based on an entirely different sequence of instructions than are specified by its input is as
ridiculously stupid as requiring sum(3,4) to return any integer besides 7.
Since Ben is not ridiculously stupid it makes no sense that he forms ridiculously stupid conclusions.
On 6/6/2022 5:36 PM, wij wrote:
reviewers need to see exactly the 'jack shit' how H is defined.Reviewers may need to see exactly how H is defined to determine that
H(P,P) does correctly determine the halt status of its input.
Reviewers absolutely need to see exactly how H is defined to determine
that
H(P,P) does correctly determine the halt status of its input.
Reviewers DO NOT NEED TO SEE EXACTLY HOW H IS DEFINED TO KNOW THAT
H(P,P)==0 IS THE CORRECT HALT STATUS VALUE FOR THE "IMPOSSIBLE" INPUT.
What do you expect reviewers to say about H while H is not shown (empty)?
Reviewers cannot deduce any answer from empty declaration (no contents).
It may be that reviewers on this forum are far too stupid to have any
idea that an x86 emulator emulates x86 machine code.
This is not typically the case. Every competent reviewer can easily
determine that within the hypothesis that:
H(P,P) correctly emulates its input with an x86 emulator
that the correctly emulated input to H(P,P) would never reach its "ret" instruction.
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P [00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P [0000135d](05) e840feffff call 000011a2 // call H [00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
Declaration/stipulation and implement/proof are two different things.You are "GUR" growling at me?
You boasted long ago that you have implemented H. Where is it?
Are you suggesting/admitting GUR is correct (no correct Halting
decider can exist)?
I have conclusively proved that H(P,P)==0 is correct.
The real H cannot exist (by GUR, and proved by the absence of POOH).
wij <wyniijj2@gmail.com> writes:
Students of average level understand Halting decider cannot exist, as olcott >> has demonstrated for years (no 'correct' H exists).
If H does not exist, what dose "H(P,P)==0" mean?
H as specified in, say, Linz does not exist. But PO's H does and so P
(which should really be called something like H_Hat) also exists.
That's why H is wrong about the "halting" of P(P).
Another way to write the proof is to show that every Turing machine gets
at least one instance wrong -- i.e. that no TM computes the halting
function. PO's H is just an example of that, and he even tells us that
it gets the instance representing P(P) wrong.
On 6/6/2022 1:36 PM, Ben wrote:
wij <wyniijj2@gmail.com> writes:
Students of average level understand Halting decider cannot exist, as
olcott
has demonstrated for years (no 'correct' H exists).
If H does not exist, what dose "H(P,P)==0" mean?
H as specified in, say, Linz does not exist. But PO's H does and so P
(which should really be called something like H_Hat) also exists.
That's why H is wrong about the "halting" of P(P).
Another way to write the proof is to show that every Turing machine gets
at least one instance wrong -- i.e. that no TM computes the halting
function. PO's H is just an example of that, and he even tells us that
it gets the instance representing P(P) wrong.
Since you know that
(1) Deciders in computer science compute the mapping from their inputs
to an accept or reject state.
(2) P(P) is not an input to H
Why do you persist in the deception that H must compute the halt status
of P(P) ?
On Tuesday, 7 June 2022 at 07:32:26 UTC+8, olcott wrote:
On 6/6/2022 5:36 PM, wij wrote:
It may be that reviewers on this forum are far too stupid to have anyreviewers need to see exactly the 'jack shit' how H is defined.Reviewers may need to see exactly how H is defined to determine that
H(P,P) does correctly determine the halt status of its input.
Reviewers absolutely need to see exactly how H is defined to determine that >>> H(P,P) does correctly determine the halt status of its input.
Reviewers DO NOT NEED TO SEE EXACTLY HOW H IS DEFINED TO KNOW THAT
H(P,P)==0 IS THE CORRECT HALT STATUS VALUE FOR THE "IMPOSSIBLE" INPUT.
What do you expect reviewers to say about H while H is not shown (empty)? >>> Reviewers cannot deduce any answer from empty declaration (no contents). >>>
idea that an x86 emulator emulates x86 machine code.
This is not typically the case. Every competent reviewer can easily
determine that within the hypothesis that:
H(P,P) correctly emulates its input with an x86 emulator
that the correctly emulated input to H(P,P) would never reach its "ret"
instruction.
Everybody (including you) understands "the correctly emulated input to H(P,P) would never reach its "ret" instruction."
Therefore, the HONEST answer is "H(P,P) is undecidable."
On Tuesday, 7 June 2022 at 12:17:05 UTC+1, richar...@gmail.com wrote:
On 6/6/22 11:49 PM, olcott wrote:x86 is von Neumann architecture. So stored programs can be manipulated
On 6/6/2022 1:36 PM, Ben wrote:But P(P) IS an input to H via its representation being given to H.
wij <wyni...@gmail.com> writes:
Students of average level understand Halting decider cannot exist, as >>>>> olcott
has demonstrated for years (no 'correct' H exists).
If H does not exist, what dose "H(P,P)==0" mean?
H as specified in, say, Linz does not exist. But PO's H does and so P >>>> (which should really be called something like H_Hat) also exists.
That's why H is wrong about the "halting" of P(P).
Another way to write the proof is to show that every Turing machine gets >>>> at least one instance wrong -- i.e. that no TM computes the halting
function. PO's H is just an example of that, and he even tells us that >>>> it gets the instance representing P(P) wrong.
Since you know that
(1) Deciders in computer science compute the mapping from their inputs
to an accept or reject state.
(2) P(P) is not an input to H
Why do you persist in the deception that H must compute the halt status
of P(P) ?
If you want to say that you can't actually give a computation to a
Turing Machine then the Halting Theorem is trivially proven true.
as data. In PO's system, H is passed a pointer to the actual machine code of P. PO is trying to draw a distinction between P when it is called, and P when it is passed to H. I think Ben might have been a bit over-pedantic
with him and he might have misunderstood what Ben was saying.
WIth Turing machines, you can't pass an actual machine. You can only
provide a description of a machine, on the tape. A Turing machine has
no access to its own states, and it cannot examine another Turing machine. This isn't true of x86 programs.
The distinction shouldn't be important, but there seems to be some confusion somewhere.
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Tuesday, 7 June 2022 at 00:32:26 UTC+1, olcott wrote:
This is not typically the case. Every competent reviewer can easilyYou can't tell from that that "ret" is never reached. It depends what is in H.
determine that within the hypothesis that:
H(P,P) correctly emulates its input with an x86 emulator
that the correctly emulated input to H(P,P) would never reach its "ret"
instruction.
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
You say that H emulates P(P).
He is very studiously avoiding saying that! Obviously that's what
/should/ be simulated, because H(X,Y) should tell us about X(Y), but
then H(P,P) == 0 would be even more obviously wrong.
That's what the new unexplained mantra is all about. "The correct
simulation of the input to H(P,P)" can mean whatever PO wants it to
mean.
For that reason I can't see why anyone thinks he's wrong about
it. It's not the halting problem, but it could only be wrong if he told
us it should do something it isn't doing.
In fact, according to you, H returns 0 (non-halting) because it detects that >> otherwise the nested simulations will go on forever. That's correct. However,
in aborting the simulation, it makes it not true that the nested simulations >> will go on forever. That's the part you've failed to understand.
He understands that very well. I can provide all sorts of quotes to
attest to that. His plan is just to find some words that will keep the conversation going.
On Tuesday, 7 June 2022 at 22:28:35 UTC+8, olcott wrote:
On 6/7/2022 8:38 AM, wij wrote:
On Tuesday, 7 June 2022 at 07:32:26 UTC+8, olcott wrote:Never reaching its "ret" instruction means that it never halts.
On 6/6/2022 5:36 PM, wij wrote:
It may be that reviewers on this forum are far too stupid to have anyreviewers need to see exactly the 'jack shit' how H is defined.Reviewers may need to see exactly how H is defined to determine that >>>>>> H(P,P) does correctly determine the halt status of its input.
Reviewers absolutely need to see exactly how H is defined to determine that
H(P,P) does correctly determine the halt status of its input.
Reviewers DO NOT NEED TO SEE EXACTLY HOW H IS DEFINED TO KNOW THAT >>>>>> H(P,P)==0 IS THE CORRECT HALT STATUS VALUE FOR THE "IMPOSSIBLE" INPUT. >>>>>What do you expect reviewers to say about H while H is not shown (empty)? >>>>> Reviewers cannot deduce any answer from empty declaration (no contents). >>>>>
idea that an x86 emulator emulates x86 machine code.
This is not typically the case. Every competent reviewer can easily
determine that within the hypothesis that:
H(P,P) correctly emulates its input with an x86 emulator
that the correctly emulated input to H(P,P) would never reach its "ret" >>>> instruction.
Everybody (including you) understands "the correctly emulated input to H(P,P)
would never reach its "ret" instruction."
Therefore, the HONEST answer is "H(P,P) is undecidable."How the Hell can you possibly construe correctly decided as undecidable?
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
Simply because that is what it is -- As you mentioned, "the correctly emulated input to H(P,P)
would never reach its "ret" instruction." -- I.e. H(P,P) is undecidable (never halts).
What the Hell can you possibly be honest to say H(P,P)==0 while observed and testified that
the "H(P,P) would never reach its "ret" instruction"?
In the circumstance of no evidence (no definition of H),
What the Hell can you possibly conclude "H(P,P)==0" is correct?
On Wednesday, 8 June 2022 at 00:53:32 UTC+8, olcott wrote:
On 6/7/2022 11:32 AM, wij wrote:
On Tuesday, 7 June 2022 at 22:28:35 UTC+8, olcott wrote:That is the kind of confusion that you get when you only glance at a
On 6/7/2022 8:38 AM, wij wrote:
On Tuesday, 7 June 2022 at 07:32:26 UTC+8, olcott wrote:Never reaching its "ret" instruction means that it never halts.
On 6/6/2022 5:36 PM, wij wrote:
It may be that reviewers on this forum are far too stupid to have any >>>>>> idea that an x86 emulator emulates x86 machine code.reviewers need to see exactly the 'jack shit' how H is defined. >>>>>>>> Reviewers may need to see exactly how H is defined to determine that >>>>>>>> H(P,P) does correctly determine the halt status of its input.
Reviewers absolutely need to see exactly how H is defined to determine that
H(P,P) does correctly determine the halt status of its input.
Reviewers DO NOT NEED TO SEE EXACTLY HOW H IS DEFINED TO KNOW THAT >>>>>>>> H(P,P)==0 IS THE CORRECT HALT STATUS VALUE FOR THE "IMPOSSIBLE" INPUT. >>>>>>>What do you expect reviewers to say about H while H is not shown (empty)?
Reviewers cannot deduce any answer from empty declaration (no contents).
This is not typically the case. Every competent reviewer can easily >>>>>> determine that within the hypothesis that:
H(P,P) correctly emulates its input with an x86 emulator
that the correctly emulated input to H(P,P) would never reach its "ret" >>>>>> instruction.
Everybody (including you) understands "the correctly emulated input to H(P,P)
would never reach its "ret" instruction."
Therefore, the HONEST answer is "H(P,P) is undecidable."How the Hell can you possibly construe correctly decided as undecidable? >>>> --
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
Simply because that is what it is -- As you mentioned, "the correctly emulated input to H(P,P)
would never reach its "ret" instruction." -- I.e. H(P,P) is undecidable (never halts).
What the Hell can you possibly be honest to say H(P,P)==0 while observed and testified that
the "H(P,P) would never reach its "ret" instruction"?
couple of my words before spouting off a rebuttal.
the correctly emulated input to H(P,P)
correctly emulated input to H(P,P)
correctly emulated input to H(P,P)
correctly emulated input to H(P,P)
correctly emulated input to H(P,P)
would never reach its "ret" instruction
thus conclusively proving that H(P,P)==0 is correct.
That you "interpreted"
correctly emulated input to H(P,P) never halts
as meaning that H never halts is ridiculously stupid.
In the circumstance of no evidence (no definition of H),--
What the Hell can you possibly conclude "H(P,P)==0" is correct?
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
Just curious, why you are so desperate to disprove the HP? Anything good to you?
On 6/7/2022 8:53 AM, Ben wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Tuesday, 7 June 2022 at 00:32:26 UTC+1, olcott wrote:
This is not typically the case. Every competent reviewer can easilyYou can't tell from that that "ret" is never reached. It depends what
determine that within the hypothesis that:
H(P,P) correctly emulates its input with an x86 emulator
that the correctly emulated input to H(P,P) would never reach its "ret" >>>> instruction.
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
is in H.
You say that H emulates P(P).
He is very studiously avoiding saying that! Obviously that's what
/should/ be simulated, because H(X,Y) should tell us about X(Y), but
then H(P,P) == 0 would be even more obviously wrong.
That's what the new unexplained mantra is all about. "The correct
simulation of the input to H(P,P)" can mean whatever PO wants it to
mean. For that reason I can't see why anyone thinks he's wrong about
it. It's not the halting problem, but it could only be wrong if he told
us it should do something it isn't doing.
It may be the case that I have misjudged the Sire of POOP all this time.
A feature of engineering software products today is not implementing or testing to a specification. In fact there usually isn't a spec anywhere
in sight. That's how M$ as well as other software vendors avoid fixing obvious mistakes. Since the spec doesn't exist, how can you know if it's
an error. I'm guessing that this style of development contributed to PO
not being able to hold a job (and all the projects we know about were failures). It's the modern way and PO was there first. Let's all raise
our cups and shout hooray for Pete!
Jeff BarnettIn fact, according to you, H returns 0 (non-halting) because it
detects that
otherwise the nested simulations will go on forever. That's correct.
However,
in aborting the simulation, it makes it not true that the nested
simulations
will go on forever. That's the part you've failed to understand.
He understands that very well. I can provide all sorts of quotes to
attest to that. His plan is just to find some words that will keep the
conversation going.--
On 6/7/2022 9:53 AM, Ben wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Tuesday, 7 June 2022 at 00:32:26 UTC+1, olcott wrote:
This is not typically the case. Every competent reviewer can easilyYou can't tell from that that "ret" is never reached. It depends what
determine that within the hypothesis that:
H(P,P) correctly emulates its input with an x86 emulator
that the correctly emulated input to H(P,P) would never reach its "ret" >>>> instruction.
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
is in H.
You say that H emulates P(P).
He is very studiously avoiding saying that! Obviously that's what
/should/ be simulated, because H(X,Y) should tell us about X(Y), but
then H(P,P) == 0 would be even more obviously wrong.
That's what the new unexplained mantra is all about. "The correct
simulation of the input to H(P,P)" can mean whatever PO wants it to
mean.
LIAR LIAR PANTS ON FIRE !!!
As I have said many hundreds of times H perform and x86 emulation of its input. This only has a single 100% precise meaning. That you say that I
am vague about this can only be a God damned lie and not any sort of
honest mistake.
It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction of P repeats this process we can know with complete certainty that the emulated P never reaches its final “ret” instruction, thus never halts.
For that reason I can't see why anyone thinks he's wrong about
it. It's not the halting problem, but it could only be wrong if he told
us it should do something it isn't doing.
H computes the mapping from its input finite strings to its accept or
reject state on the basis of the actual behavior specified by the actual input as measured by the correct x86 emulation or UTM simulation of this input by H.
In fact, according to you, H returns 0 (non-halting) because it
detects that
otherwise the nested simulations will go on forever. That's correct.
However,
in aborting the simulation, it makes it not true that the nested
simulations
will go on forever. That's the part you've failed to understand.
computation that halts … the Turing machine will halt whenever it enters
a final state. (Linz:1990:234)
That the correct and complete x86 emulation of the input to H(P,P) or Infinite_Loop wold never stop running conclusively proves that these
inputs specify a non-halting sequence of x86 instructions.
void Infinite_Loop()
{
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}
_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]
He understands that very well. I can provide all sorts of quotes to
attest to that. His plan is just to find some words that will keep the
conversation going.
Since you know that
(1) Deciders in computer science compute the mapping from their inputs
to an accept or reject state.
(2) P(P) is not an input to H
Why do you persist in the deception that H must compute the halt status
of P(P) ? (Can only parrot textbook authors with no actual
understanding of the underlying relationships involved).
On 6/7/2022 6:30 AM, Malcolm McLean wrote:
On Tuesday, 7 June 2022 at 12:17:05 UTC+1, richar...@gmail.com wrote:
On 6/6/22 11:49 PM, olcott wrote:x86 is von Neumann architecture. So stored programs can be manipulated
On 6/6/2022 1:36 PM, Ben wrote:But P(P) IS an input to H via its representation being given to H.
wij <wyni...@gmail.com> writes:
Students of average level understand Halting decider cannot exist, as >>>>>> olcott
has demonstrated for years (no 'correct' H exists).
If H does not exist, what dose "H(P,P)==0" mean?
H as specified in, say, Linz does not exist. But PO's H does and so P >>>>> (which should really be called something like H_Hat) also exists.
That's why H is wrong about the "halting" of P(P).
Another way to write the proof is to show that every Turing machine
gets
at least one instance wrong -- i.e. that no TM computes the halting
function. PO's H is just an example of that, and he even tells us
that
it gets the instance representing P(P) wrong.
Since you know that
(1) Deciders in computer science compute the mapping from their inputs >>>> to an accept or reject state.
(2) P(P) is not an input to H
Why do you persist in the deception that H must compute the halt status >>>> of P(P) ?
If you want to say that you can't actually give a computation to a
Turing Machine then the Halting Theorem is trivially proven true.
as data. In PO's system, H is passed a pointer to the actual machine
code of
P. PO is trying to draw a distinction between P when it is called, and P >> when it is passed to H. I think Ben might have been a bit over-pedantic
with him and he might have misunderstood what Ben was saying.
WIth Turing machines, you can't pass an actual machine. You can only
provide a description of a machine, on the tape. A Turing machine has
no access to its own states, and it cannot examine another Turing
machine.
This isn't true of x86 programs.
The distinction shouldn't be important, but there seems to be some
confusion
somewhere.
A simulating halt decider based on an x86 emulator or a UTM is the same
idea and fundamentally works the same way.
It is the case that P(P) is not and cannot be an input to H(P,P) because
the input to H(P,P) has a pathological self-reference relationship to H
and P(P) has no such relationship.
The correct and complete simulation of the input to HP(P,P) is stuck in infinitely nested simulation and P(P) halts.
On 6/7/2022 12:05 PM, Jeff Barnett wrote:
On 6/7/2022 8:53 AM, Ben wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Tuesday, 7 June 2022 at 00:32:26 UTC+1, olcott wrote:
This is not typically the case. Every competent reviewer can easilyYou can't tell from that that "ret" is never reached. It depends
determine that within the hypothesis that:
H(P,P) correctly emulates its input with an x86 emulator
that the correctly emulated input to H(P,P) would never reach its
"ret"
instruction.
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
what is in H.
You say that H emulates P(P).
He is very studiously avoiding saying that! Obviously that's what
/should/ be simulated, because H(X,Y) should tell us about X(Y), but
then H(P,P) == 0 would be even more obviously wrong.
That's what the new unexplained mantra is all about. "The correct
simulation of the input to H(P,P)" can mean whatever PO wants it to
mean. For that reason I can't see why anyone thinks he's wrong about
it. It's not the halting problem, but it could only be wrong if he told >>> us it should do something it isn't doing.
It may be the case that I have misjudged the Sire of POOP all this
time. A feature of engineering software products today is not
implementing or testing to a specification. In fact there usually
isn't a spec anywhere
This is a 100% complete specification required to correctly determine
that the correctly emulated input to H(P,P) never reaches its "ret" instruction, thus never halts.
That you imply that it is not a complete specification proves that you
are incompetent or dishonest or both.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P [00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P [0000135d](05) e840feffff call 000011a2 // call H [00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction of P repeats this process we can know with complete certainty that the emulated P never reaches its final “ret” instruction, thus never halts.
in sight. That's how M$ as well as other software vendors avoid fixing
obvious mistakes. Since the spec doesn't exist, how can you know if
it's an error. I'm guessing that this style of development contributed
to PO not being able to hold a job (and all the projects we know about
were failures). It's the modern way and PO was there first. Let's all
raise our cups and shout hooray for Pete!
Jeff BarnettIn fact, according to you, H returns 0 (non-halting) because it
detects that
otherwise the nested simulations will go on forever. That's correct.
However,
in aborting the simulation, it makes it not true that the nested
simulations
will go on forever. That's the part you've failed to understand.
He understands that very well. I can provide all sorts of quotes to
attest to that. His plan is just to find some words that will keep the >>> conversation going.--
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 128:03:48 |
| Calls: | 6,663 |
| Calls today: | 1 |
| Files: | 12,212 |
| Messages: | 5,335,189 |