olcott <NoOne@NoWhere.com> writes:
The only other possibility is that H is a halt
decider that aborts its simulation of P at the
machine address 0xc41 of P. In this case P also
never reaches is final state at machine address
0xc50. Thus in every possibility P never reaches
its final state and thus never halts.
So having lost the argument in relation to Turing machines, you have
returned to your hidden code that gets the wrong answer?
Or do you now
accept that H(P,P) == false is wrong if P(P) halts? To get any traction
you really do have to admit that defining the wrong answer to be the
right one simply did not cut it!
By playing tricks (which will remain as hidden as your code) you can
arrange for H(P,P) == true when P(P) halts which would be a welcome
change of heart.
On Sunday, 31 October 2021 at 22:14:07 UTC+8, olcott wrote:
On 10/30/2021 11:01 PM, wij wrote:
On Sunday, 31 October 2021 at 10:45:03 UTC+8, olcott wrote:I show all of the details of how we can know that when H(P,P) does not
When we examine pages 4 and 5 and hypothesize
that H is merely a pure simulator we can see
that when P calls H at its machine address 0xc41
that this **is** infinitely nested simulation
such that P never reaches its final state.
The only other possibility is that H is a halt
decider that aborts its simulation of P at the
machine address 0xc41 of P. In this case P also
never reaches is final state at machine address
0xc50. Thus in every possibility P never reaches
its final state and thus never halts.
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
P exists only after the existence of H. No H, no P.
Your H is specific for some 'P' already existent before H.
Your understanding and implement are not what you think.
GUR dictates that:
...
No function f can decide the property of another function g that g can defy.
GUR(v4) https://groups.google.com/g/comp.theory/c/_tbCYyMox9M
...
abort its simulation of its input then its input never reaches its final
state. We can also see that its input never reaches its final state even
if H(P,P) aborts its input therefore we can know that under all possible
conditions the input to H(P,P) does not halt.
You have to exactly look at pages 4 and 5 to see this:
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
On page 4:
The word 'partial' in the title "Simulating partial halt decider H correctly decides that P(P) never halts (V1)" bugged me.
On page 5:
1. Your H does not actually take any 'given input'.
2. What language (or model) C, x86 assembly, or TM are you using?
None of these three languages are easy to take 'machine description' as input.
You chose a hard(impossible, by GUR) way to tackle the problem.
If I understand correctly, you seem to emphasize the fact that H can correctly
decide whether its P will halt or not. I have no doubt of your case.
But, for the conventional HP, P does not exist before H is created. Hard coding
P into H is simply wrong. It is not a decider of any given real program.
olcott <NoOne@NoWhere.com> writes:
I show all of the details of how we can know that when H(P,P) does not
abort its simulation of its input then its input never reaches its
final state.
That's a teeny, tiny fib, isn't it, because you don't show /all/ the
details. The most important details -- in the code for H -- are going
to remain hidden forever.
On 10/31/21 11:51 AM, olcott wrote:
On 10/31/2021 10:11 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
The only other possibility is that H is a halt
decider that aborts its simulation of P at the
machine address 0xc41 of P. In this case P also
never reaches is final state at machine address
0xc50. Thus in every possibility P never reaches
its final state and thus never halts.
So having lost the argument in relation to Turing machines, you have
returned to your hidden code that gets the wrong answer?
(1) I haven't lost the argument on Turing Machines.
Only because you haven't actually made a real arguemnt on Turing Machines.
(2) I conclusively prove that the input to H(P,P) never halts in
Message-ID: <hIednR1p-IK1NuP8nZ2dnUU7-ePNnZ2d@giganews.com>
Giganews posted this message to other groups and skipped itself.
Except that is a meaningless statement.
'Inputs' don't halt. Machines Halt.
When the input <H^><H^> is given to a UTM, that computation Halts, which
is one of the ways to look at the definition of the Halting Problem.
Yes, H's aborted simulation of <H^><H^> never reached a final halting
state, but aborted simulation NEVER, in themselves, prove non-halting
(or Halting). So you are arguing about meaningless behavior trying to
claim that it actually means something by using bad terminology.
Or do you now
accept that H(P,P) == false is wrong if P(P) halts? To get any traction >>> you really do have to admit that defining the wrong answer to be the
right one simply did not cut it!
By playing tricks (which will remain as hidden as your code) you can
arrange for H(P,P) == true when P(P) halts which would be a welcome
change of heart.
// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
_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]
_main()
[00000c56](01) 55 push ebp
[00000c57](02) 8bec mov ebp,esp
[00000c59](05) 68360c0000 push 00000c36 // push P
[00000c5e](05) 68360c0000 push 00000c36 // push P
[00000c63](05) e8fefcffff call 00000966 // call H(P,P)
[00000c68](03) 83c408 add esp,+08
[00000c6b](01) 50 push eax
[00000c6c](05) 6857030000 push 00000357
[00000c71](05) e810f7ffff call 00000386
[00000c76](03) 83c408 add esp,+08
[00000c79](02) 33c0 xor eax,eax
[00000c7b](01) 5d pop ebp
[00000c7c](01) c3 ret
Size in bytes:(0039) [00000c7c]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00000c56][0010172a][00000000] 55 push ebp
[00000c57][0010172a][00000000] 8bec mov ebp,esp
[00000c59][00101726][00000c36] 68360c0000 push 00000c36 // push P
[00000c5e][00101722][00000c36] 68360c0000 push 00000c36 // push P
[00000c63][0010171e][00000c68] e8fefcffff call 00000966 // call H(P,P)
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) >>
[00000c36][0025c1f2][0025c1f6] 55 push ebp
[00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp
[00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08]
[00000c3c][0025c1ee][00000c36] 50 push eax // push P
[00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][0025c1ea][00000c36] 51 push ecx // push P
[00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P) >> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
The above is from pages 4 and 5 of this paper:
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
There are no tricks. There are only two possible cases:
(1) H(P,P) aborts its simulation and P never reaches its final state
at 0xc50
(2) H(P,P) does not abort its simulation and P never reaches its final
state at 0xc50
Therefore when H(P,P) decides that its input never halts H is
necessarily correct.
You are just arguing POOP.
The fact that H doesn't reach the halting state is irrelevent to the
halting problem.
olcott <NoOne@NoWhere.com> writes:
On 10/31/2021 10:11 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
The only other possibility is that H is a haltSo having lost the argument in relation to Turing machines, you have
decider that aborts its simulation of P at the
machine address 0xc41 of P. In this case P also
never reaches is final state at machine address
0xc50. Thus in every possibility P never reaches
its final state and thus never halts.
returned to your hidden code that gets the wrong answer?
(1) I haven't lost the argument on Turing Machines.
(2) I conclusively prove that the input to H(P,P) never halts in
Message-ID: <hIednR1p-IK1NuP8nZ2dnUU7-ePNnZ2d@giganews.com>
Giganews posted this message to other groups and skipped itself.
The input to H represents the computation P(P). At least up until
recently you asserted that P(P) halts and you spent a lot of time trying
to hand-wave away the wrong answer from H.
Or do you now
accept that H(P,P) == false is wrong if P(P) halts? To get any traction >>> you really do have to admit that defining the wrong answer to be the
right one simply did not cut it!
By playing tricks (which will remain as hidden as your code) you can
arrange for H(P,P) == true when P(P) halts which would be a welcome
change of heart.
There are no tricks.
Good. That means you can't have H(P,P) == true iff P(P) halts.
There are only two possible cases:
(1) H(P,P) aborts its simulation and P never reaches its final state
at 0xc50
(2) H(P,P) does not abort its simulation and P never reaches its final
state at 0xc50
Therefore when H(P,P) decides that its input never halts H is
necessarily correct.
I can see you don't want to answer.
I was asking if you have changed
your mind,
and I know that's very hard for someone in your position to
admit. Here's the key question: do you still assert that H(P,P) ==
false is the "correct" answer even though P(P) halts?
If you won't say,
nothing you do say about what is "correct" (necessarily or otherwise) is pointless.
Of course, it's likely you have no changed you mind and you are still searching for words to make the wrong answer seems less obviously
wrong. Not answering my question is a key part of that strategy so I
don't expect an answer.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 366 |
Nodes: | 16 (2 / 14) |
Uptime: | 03:54:12 |
Calls: | 7,812 |
Files: | 12,924 |
Messages: | 5,749,465 |