Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.theory > #61678 > unrolled thread

Simulating halt deciders defeat the halting theorem

Back to article view | Back to comp.theory

Contents

  Simulating halt deciders defeat the halting theorem olcott <polcott2@gmail.com> - 2023-02-14 18:57 -0600
    Re: Simulating halt deciders defeat the halting theorem Richard Damon <Richard@Damon-Family.org> - 2023-02-14 21:03 -0500
    Re: Simulating halt deciders defeat the halting theorem olcott <polcott2@gmail.com> - 2023-02-14 21:39 -0600
      Re: Simulating halt deciders defeat the halting theorem Richard Damon <Richard@Damon-Family.org> - 2023-02-14 23:51 -0500
    Re: Simulating halt deciders defeat the halting theorem olcott <polcott2@gmail.com> - 2023-02-15 08:57 -0600
      Re: Simulating halt deciders defeat the halting theorem Richard Damon <Richard@Damon-Family.org> - 2023-02-15 18:57 -0500
    Re: Simulating halt deciders defeat the halting theorem olcott <polcott2@gmail.com> - 2023-02-15 13:25 -0600
      Re: Simulating halt deciders defeat the halting theorem olcott <polcott2@gmail.com> - 2023-02-15 15:12 -0600
        Re: Simulating halt deciders defeat the halting theorem olcott <polcott2@gmail.com> - 2023-02-15 16:12 -0600
          Re: Simulating halt deciders defeat the halting theorem Richard Damon <Richard@Damon-Family.org> - 2023-02-15 19:22 -0500
        Re: Simulating halt deciders defeat the halting theorem Richard Damon <Richard@Damon-Family.org> - 2023-02-15 19:20 -0500
      Re: Simulating halt deciders defeat the halting theorem olcott <polcott2@gmail.com> - 2023-02-15 16:13 -0600
      Re: Simulating halt deciders defeat the halting theorem olcott <polcott2@gmail.com> - 2023-02-15 20:22 -0600
        Re: Simulating halt deciders defeat the halting theorem Richard Damon <Richard@Damon-Family.org> - 2023-02-15 21:36 -0500
        Re: Simulating halt deciders defeat the halting theorem olcott <polcott2@gmail.com> - 2023-02-15 20:39 -0600
          Re: Simulating halt deciders defeat the halting theorem Richard Damon <Richard@Damon-Family.org> - 2023-02-15 21:55 -0500
          Re: Simulating halt deciders defeat the halting theorem olcott <polcott2@gmail.com> - 2023-02-15 21:15 -0600
            Re: Simulating halt deciders defeat the halting theorem Richard Damon <Richard@Damon-Family.org> - 2023-02-15 22:20 -0500
            Re: Simulating halt deciders defeat the halting theorem olcott <polcott2@gmail.com> - 2023-02-15 21:28 -0600
              Re: Simulating halt deciders defeat the halting theorem Richard Damon <Richard@Damon-Family.org> - 2023-02-15 22:42 -0500
                Re: Simulating halt deciders defeat the halting theorem olcott <polcott2@gmail.com> - 2023-02-16 10:59 -0600
                  Re: Simulating halt deciders defeat the halting theorem Richard Damon <Richard@Damon-Family.org> - 2023-02-16 18:43 -0500
      Re: Simulating halt deciders defeat the halting theorem olcott <polcott2@gmail.com> - 2023-02-16 13:16 -0600
        Re: Simulating halt deciders defeat the halting theorem Jeff Barnett <jbb@notatt.com> - 2023-02-16 12:26 -0700
          Re: Simulating halt deciders defeat the halting theorem [ irrefutable ] olcott <polcott2@gmail.com> - 2023-02-16 13:41 -0600
            Re: Simulating halt deciders defeat the halting theorem [ irrefutable ] Jeff Barnett <jbb@notatt.com> - 2023-02-16 15:24 -0700
              Re: Simulating halt deciders defeat the halting theorem [ irrefutable ] olcott <polcott2@gmail.com> - 2023-02-16 16:45 -0600
            Re: Simulating halt deciders defeat the halting theorem [ irrefutable ] Richard Damon <Richard@Damon-Family.org> - 2023-02-16 18:48 -0500
        Re: Simulating halt deciders defeat the halting theorem Richard Damon <Richard@Damon-Family.org> - 2023-02-16 18:45 -0500
      Re: Simulating halt deciders defeat the halting theorem [ Ben will not lie about this ] olcott <polcott2@gmail.com> - 2023-02-16 17:01 -0600
        Re: Simulating halt deciders defeat the halting theorem [ Ben will not lie about this ] Richard Damon <Richard@Damon-Family.org> - 2023-02-16 18:49 -0500
      Re: Simulating halt deciders defeat the halting theorem olcott <polcott2@gmail.com> - 2023-02-24 15:31 -0600
        Re: Simulating halt deciders defeat the halting theorem Richard Damon <Richard@Damon-Family.org> - 2023-02-24 20:11 -0500
      Re: Simulating halt deciders defeat the halting theorem olcott <polcott2@gmail.com> - 2023-02-24 15:31 -0600
        Re: Simulating halt deciders defeat the halting theorem Richard Damon <Richard@Damon-Family.org> - 2023-02-24 20:11 -0500
      Re: Simulating halt deciders defeat the halting theorem olcott <polcott2@gmail.com> - 2023-02-24 16:07 -0600
        Re: Simulating halt deciders defeat the halting theorem Richard Damon <Richard@Damon-Family.org> - 2023-02-24 20:11 -0500
      Re: Simulating halt deciders defeat the halting theorem olcott <polcott2@gmail.com> - 2023-02-24 16:08 -0600
        Re: Simulating halt deciders defeat the halting theorem Richard Damon <Richard@Damon-Family.org> - 2023-02-24 20:11 -0500
      Re: Simulating halt deciders defeat the halting theorem [-ONLY LIARS WILL DISAGREE-] olcott <polcott2@gmail.com> - 2023-02-26 14:01 -0600
        Re: Simulating halt deciders defeat the halting theorem [-ONLY LIARS WILL DISAGREE-] Richard Damon <Richard@Damon-Family.org> - 2023-02-26 15:15 -0500
          Re: Simulating halt deciders defeat the halting theorem [-ONLY LIARS WILL DISAGREE-] Mr Flibble <flibble@reddwarf.jmc.corp> - 2023-02-26 20:32 +0000

Page 1 of 3  [1] 2 3  Next page →

#61678 — Simulating halt deciders defeat the halting theorem

(a) If simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D could not possibly reach its
own "return" statement in a finite number of simulated steps then:

(b) H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.

When it is understood that (b) is a necessary consequence of (a) and we
can see that (a) has been met then we understand that H(D,D) has
correctly determined the halt state of its input.

001 int D(int (*x)())
002 {
003   int Halt_Status = H(x, x);
004   if (Halt_Status)
005     HERE: goto HERE;
006   return Halt_Status;
007 }
008
009 int main()
010 {
011   Output("Input_Halts = ", H(D,D));
012   Output("Input_Halts = ", D(D));
013 }

*Simulating halt deciders applied to the halting theorem*
The above is fully operational code in the x86utm operating system.

Because H correctly detects that D correctly simulated by H would
continue to call H(D,D) never reaching its own "return" statement H
aborts it simulation of D and returns 0 to main() on line 011.

Because H correctly detects that D correctly simulated by H would
continue to call H(D,D) never reaching its own "return" statement H
aborts it simulation of D and returns 0 to the executed D on line 003.

straw man
An intentionally misrepresented proposition that is set up because it is
easier to defeat than an opponent's real argument. 
https://www.lexico.com/en/definition/straw_man

Every recent rebuttal uses the strawman deception to change the subject
away from: { D correctly simulated by H } or denies that (b) is a
necessary consequence of (a).



*Simulating Halt Decider Applied to the Halting Theorem*
https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem 



-- 
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

[toc] | [next] | [standalone]

#61679

On 2/14/23 7:57 PM, olcott wrote:
> (a) If simulating halt decider H correctly simulates its input D until H
> correctly determines that its simulated D could not possibly reach its
> own "return" statement in a finite number of simulated steps then:

Eccept that H can never correctly determine this of D, since if the H 
that is called by D does ever abort its simulation and returns 0, then D 
will halt, thus, since BY DEFINITION, the H we are talking about must be 
the same decider, unless you can show that a "Turing Equivalent Program" 
can act differently in two call sites, this can't happen.

You have been asked for this evidence, and failed to provide it, thus 
you have effectively admitted it is FALSE.

> 
> (b) H can abort its simulation of D and correctly report that D
> specifies a non-halting sequence of configurations.


> 
> When it is understood that (b) is a necessary consequence of (a) and we
> can see that (a) has been met then we understand that H(D,D) has
> correctly determined the halt state of its input.

but (a) is never true for D

> 
> 001 int D(int (*x)())
> 002 {
> 003   int Halt_Status = H(x, x);
> 004   if (Halt_Status)
> 005     HERE: goto HERE;
> 006   return Halt_Status;
> 007 }
> 008
> 009 int main()
> 010 {
> 011   Output("Input_Halts = ", H(D,D));
> 012   Output("Input_Halts = ", D(D));
> 013 }
> 
> *Simulating halt deciders applied to the halting theorem*
> The above is fully operational code in the x86utm operating system.
> 
> Because H correctly detects that D correctly simulated by H would
> continue to call H(D,D) never reaching its own "return" statement H
> aborts it simulation of D and returns 0 to main() on line 011.

Execpt it doesn't, because H will always abort its simulation too soon, 
and an actual correct simulation will reach the return statement, 
showing H is incorrect.

> 
> Because H correctly detects that D correctly simulated by H would
> continue to call H(D,D) never reaching its own "return" statement H
> aborts it simulation of D and returns 0 to the executed D on line 003.

Except it doesnt.

> 
> straw man
> An intentionally misrepresented proposition that is set up because it is
> easier to defeat than an opponent's real argument. 
> https://www.lexico.com/en/definition/straw_man

Right, and since the DEFINITION of Halting is about the ACTUAL BEHAVIOR 
of the machine, or equivalently the simulation of it by a ACTUAL UTM, 
you arguements about simution by the decider (which isn't a UTM) is just 
shwon to be a STRAWMAN, and your entire arguement a big fat LIE.

> 
> Every recent rebuttal uses the strawman deception to change the subject
> away from: { D correctly simulated by H } or denies that (b) is a
> necessary consequence of (a).
> 
> 

Nope, all YOUR arguement are strawman because you don't use the ACTUAL 
definiton of Halting.

> 
> *Simulating Halt Decider Applied to the Halting Theorem*
> https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem
> 
> 

Just a load of garbage, as proven.

[toc] | [prev] | [next] | [standalone]

#61680

On 2/14/2023 6:57 PM, olcott wrote:
> (a) If simulating halt decider H correctly simulates its input D until H
> correctly determines that its simulated D could not possibly reach its
> own "return" statement in a finite number of simulated steps then:
> 
> (b) H can abort its simulation of D and correctly report that D
> specifies a non-halting sequence of configurations.
> 
> When it is understood that (b) is a necessary consequence of (a) and we
> can see that (a) has been met then we understand that H(D,D) has
> correctly determined the halt state of its input.
> 
> 001 int D(int (*x)())
> 002 {
> 003   int Halt_Status = H(x, x);
> 004   if (Halt_Status)
> 005     HERE: goto HERE;
> 006   return Halt_Status;
> 007 }
> 008
> 009 int main()
> 010 {
> 011   Output("Input_Halts = ", H(D,D));
> 012   Output("Input_Halts = ", D(D));
> 013 }
> 
> *Simulating halt deciders applied to the halting theorem*
> The above is fully operational code in the x86utm operating system.
> 
> Because H correctly detects that D correctly simulated by H would
> continue to call H(D,D) never reaching its own "return" statement H
> aborts it simulation of D and returns 0 to main() on line 011.
> 
> Because H correctly detects that D correctly simulated by H would
> continue to call H(D,D) never reaching its own "return" statement H
> aborts it simulation of D and returns 0 to the executed D on line 003.
> 
> straw man
> An intentionally misrepresented proposition that is set up because it is
> easier to defeat than an opponent's real argument. 
> https://www.lexico.com/en/definition/straw_man
> 
> Every recent rebuttal uses the strawman deception to change the subject
> away from: { D correctly simulated by H } or denies that (b) is a
> necessary consequence of (a).
> 
> *Simulating Halt Decider Applied to the Halting Theorem*
> https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem

People that are much dumber than a box of rocks will not be able to
understand that detecting recursive simulation is exactly the same as
detecting infinite recursion.

These incredibly stupid people don't even have the slightest clue how
infinite recursion would be detected so they are way too dumb to see
that detecting recursive simulation is almost exactly the same thing.

void Infinite_Recursion(u32 N)
{
   Infinite_Recursion(N);
}




-- 
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#61681

On 2/14/23 10:39 PM, olcott wrote:
> On 2/14/2023 6:57 PM, olcott wrote:
>> (a) If simulating halt decider H correctly simulates its input D until H
>> correctly determines that its simulated D could not possibly reach its
>> own "return" statement in a finite number of simulated steps then:
>>
>> (b) H can abort its simulation of D and correctly report that D
>> specifies a non-halting sequence of configurations.
>>
>> When it is understood that (b) is a necessary consequence of (a) and we
>> can see that (a) has been met then we understand that H(D,D) has
>> correctly determined the halt state of its input.
>>
>> 001 int D(int (*x)())
>> 002 {
>> 003   int Halt_Status = H(x, x);
>> 004   if (Halt_Status)
>> 005     HERE: goto HERE;
>> 006   return Halt_Status;
>> 007 }
>> 008
>> 009 int main()
>> 010 {
>> 011   Output("Input_Halts = ", H(D,D));
>> 012   Output("Input_Halts = ", D(D));
>> 013 }
>>
>> *Simulating halt deciders applied to the halting theorem*
>> The above is fully operational code in the x86utm operating system.
>>
>> Because H correctly detects that D correctly simulated by H would
>> continue to call H(D,D) never reaching its own "return" statement H
>> aborts it simulation of D and returns 0 to main() on line 011.
>>
>> Because H correctly detects that D correctly simulated by H would
>> continue to call H(D,D) never reaching its own "return" statement H
>> aborts it simulation of D and returns 0 to the executed D on line 003.
>>
>> straw man
>> An intentionally misrepresented proposition that is set up because it is
>> easier to defeat than an opponent's real argument. 
>> https://www.lexico.com/en/definition/straw_man
>>
>> Every recent rebuttal uses the strawman deception to change the subject
>> away from: { D correctly simulated by H } or denies that (b) is a
>> necessary consequence of (a).
>>
>> *Simulating Halt Decider Applied to the Halting Theorem*
>> https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem
> 
> People that are much dumber than a box of rocks will not be able to
> understand that detecting recursive simulation is exactly the same as
> detecting infinite recursion.

Only if it is UNCONDITIOHAL simulation, at which point your "decider" 
can't answer.

If it is CONDITIONAL simulation, it is just like recusion with a test in 
it, which lets it be finite.

> 
> These incredibly stupid people don't even have the slightest clue how
> infinite recursion would be detected so they are way too dumb to see
> that detecting recursive simulation is almost exactly the same thing.


No, you don't seem to understand the difference between conditional 
simulation or unconditional.

You also seem blinded to the actual truth that since D(D) does halt, its 
"correct simulaiton" can't be non-halting.

That just shows how little you understand about truth.

> 
> void Infinite_Recursion(u32 N)
> {
>    Infinite_Recursion(N);
> }
> 

Which is a strawman, as that isn't the machine we are talking about.

This shows how STUPID you are.


Fundamentally, you need to justify why, when the actual question for a 
halt decidder is about the behavior of the original machine, which you 
admit is halting, you can get to an "equivalent" stateent which says 
that non-halting is correct.

The only answer is you don't understand what Truth actually is.

[toc] | [prev] | [next] | [standalone]

#61682

On 2/14/2023 6:57 PM, olcott wrote:
> (a) If simulating halt decider H correctly simulates its input D until H
> correctly determines that its simulated D could not possibly reach its
> own "return" statement in a finite number of simulated steps then:
> 
> (b) H can abort its simulation of D and correctly report that D
> specifies a non-halting sequence of configurations.
> 
> When it is understood that (b) is a necessary consequence of (a) and we
> can see that (a) has been met then we understand that H(D,D) has
> correctly determined the halt state of its input.
> 
> 001 int D(int (*x)())
> 002 {
> 003   int Halt_Status = H(x, x);
> 004   if (Halt_Status)
> 005     HERE: goto HERE;
> 006   return Halt_Status;
> 007 }
> 008
> 009 int main()
> 010 {
> 011   Output("Input_Halts = ", H(D,D));
> 012   Output("Input_Halts = ", D(D));
> 013 }
> 
> *Simulating halt deciders applied to the halting theorem*
> The above is fully operational code in the x86utm operating system.
> 
> Because H correctly detects that D correctly simulated by H would
> continue to call H(D,D) never reaching its own "return" statement H
> aborts it simulation of D and returns 0 to main() on line 011.
> 
> Because H correctly detects that D correctly simulated by H would
> continue to call H(D,D) never reaching its own "return" statement H
> aborts it simulation of D and returns 0 to the executed D on line 003.
> 
> straw man
> An intentionally misrepresented proposition that is set up because it is
> easier to defeat than an opponent's real argument. 
> https://www.lexico.com/en/definition/straw_man
> 
> Every recent rebuttal uses the strawman deception to change the subject
> away from: { D correctly simulated by H } or denies that (b) is a
> necessary consequence of (a).
> 

Simulating Halt decider H(D,D) computes the mapping from its inputs to
an accept or reject state based on the behavior of D correctly simulated
by H. H simulates D until H determines that D would never reach its own
"return" statement in any finite number of simulated steps.

All halt deciders are intended to correctly predict the behavior of non-
terminating inputs. No halt decider ever continues to simulate its
input after it has correctly detected a repeating state.

Halfwit morons can't seem to understand this. These incredibly stupid
people seem to believe that the only way to detect infinite behavior is
to continue to simulate the non-halting input forever.

People with a modicum of technical competence will understand that when
D calls H(D,D) to simulate itself again that this simulated D cannot
possibly reach its own "return" statement in any finite number of steps.

I have shown this in x86 assembly language so that it is perfectly
unambiguously clear yet even highly skilled people seemed to have
totally forgotten this lost art.

H: Begin Simulation   Execution Trace Stored at:113109
Address_of_H:1562
[00001d12][001130f5][001130f9] 55         push ebp       ; begin D
[00001d13][001130f5][001130f9] 8bec       mov ebp,esp
[00001d15][001130f1][001030c5] 51         push ecx
[00001d16][001130f1][001030c5] 8b4508     mov eax,[ebp+08]
[00001d19][001130ed][00001d12] 50         push eax       ; push address of D
[00001d1a][001130ed][00001d12] 8b4d08     mov ecx,[ebp+08]
[00001d1d][001130e9][00001d12] 51         push ecx       ; push address of D
[00001d1e][001130e5][00001d23] e83ff8ffff call 00001562  ; call H
H: Infinitely Recursive Simulation Detected Simulation Stopped

We can see that the first seven instructions of D simulated by H 
precisely match the first seven instructions of the x86 source-code of 
D. This conclusively proves that these instructions were simulated 
correctly.

Anyone sufficiently technically competent in the x86 programming 
language will agree that the above execution trace of D simulated by H 
shows that D will never reach its own "return" statement.

H detects that D is calling itself with the exact same arguments that H 
was called with and there are no conditional branch instructions from 
the beginning of D to its call to H that can possibly escape the 
repetition of this recursive simulation.


> 
> *Simulating Halt Decider Applied to the Halting Theorem*
> https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem
> 
> 

-- 
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#61691

On 2/15/23 9:57 AM, olcott wrote:
> On 2/14/2023 6:57 PM, olcott wrote:
>> (a) If simulating halt decider H correctly simulates its input D until H
>> correctly determines that its simulated D could not possibly reach its
>> own "return" statement in a finite number of simulated steps then:
>>
>> (b) H can abort its simulation of D and correctly report that D
>> specifies a non-halting sequence of configurations.
>>
>> When it is understood that (b) is a necessary consequence of (a) and we
>> can see that (a) has been met then we understand that H(D,D) has
>> correctly determined the halt state of its input.
>>
>> 001 int D(int (*x)())
>> 002 {
>> 003   int Halt_Status = H(x, x);
>> 004   if (Halt_Status)
>> 005     HERE: goto HERE;
>> 006   return Halt_Status;
>> 007 }
>> 008
>> 009 int main()
>> 010 {
>> 011   Output("Input_Halts = ", H(D,D));
>> 012   Output("Input_Halts = ", D(D));
>> 013 }
>>
>> *Simulating halt deciders applied to the halting theorem*
>> The above is fully operational code in the x86utm operating system.
>>
>> Because H correctly detects that D correctly simulated by H would
>> continue to call H(D,D) never reaching its own "return" statement H
>> aborts it simulation of D and returns 0 to main() on line 011.
>>
>> Because H correctly detects that D correctly simulated by H would
>> continue to call H(D,D) never reaching its own "return" statement H
>> aborts it simulation of D and returns 0 to the executed D on line 003.
>>
>> straw man
>> An intentionally misrepresented proposition that is set up because it is
>> easier to defeat than an opponent's real argument. 
>> https://www.lexico.com/en/definition/straw_man
>>
>> Every recent rebuttal uses the strawman deception to change the subject
>> away from: { D correctly simulated by H } or denies that (b) is a
>> necessary consequence of (a).
>>
> 
> Simulating Halt decider H(D,D) computes the mapping from its inputs to
> an accept or reject state based on the behavior of D correctly simulated
> by H. H simulates D until H determines that D would never reach its own
> "return" statement in any finite number of simulated steps.

And if that doesn't match the Halting Behavior of the actual function 
then it isn't computing that Halting Function so it isn't a "Halt Decider.

D(D) Halts since H(D,D) returns 0, thus Halting(D,D) is True, thus the 
CORRECT answer from H if it is an actual Halt Decider is 1, so H is 
INCORRECT in its decision of H(D,D).

> 
> All halt deciders are intended to correctly predict the behavior of non-
> terminating inputs. No halt decider ever continues to simulate its
> input after it has correctly detected a repeating state.
> 

Right, but it needs to CORRECTLY determine the answer, which if H(D,D) 
returns 0, and thus D(D) will halt, means H(D,D) SHOULD have returned 1.


> Halfwit morons can't seem to understand this. These incredibly stupid
> people seem to believe that the only way to detect infinite behavior is
> to continue to simulate the non-halting input forever.
> 

And NO-WIT OLCOTTS don't understand that the decider needs to answer 
Halting if the input would Halt when run or correctly simulated by an 
actual UTM.

D(D) Halts since H(D,D) Returns 0, thus the CORRECT answer for H(D,D) is 
1, and H was incorrect.

To claim 0 is the correct answer is to show that the claimant is a liar.

> People with a modicum of technical competence will understand that when
> D calls H(D,D) to simulate itself again that this simulated D cannot
> possibly reach its own "return" statement in any finite number of steps.
> 

Right, because H aborrs its simulation before the CORRECT simulation 
reaches that final state, which is what actually matters.

It is only your strawman that tries to refer to the PARTIAL simulation 
done by H as the bases that even comes close to your claims

> I have shown this in x86 assembly language so that it is perfectly
> unambiguously clear yet even highly skilled people seemed to have
> totally forgotten this lost art.



> 
> H: Begin Simulation   Execution Trace Stored at:113109
> Address_of_H:1562
> [00001d12][001130f5][001130f9] 55         push ebp       ; begin D
> [00001d13][001130f5][001130f9] 8bec       mov ebp,esp
> [00001d15][001130f1][001030c5] 51         push ecx
> [00001d16][001130f1][001030c5] 8b4508     mov eax,[ebp+08]
> [00001d19][001130ed][00001d12] 50         push eax       ; push address 
> of D
> [00001d1a][001130ed][00001d12] 8b4d08     mov ecx,[ebp+08]
> [00001d1d][001130e9][00001d12] 51         push ecx       ; push address 
> of D
> [00001d1e][001130e5][00001d23] e83ff8ffff call 00001562  ; call H
> H: Infinitely Recursive Simulation Detected Simulation Stopped

And if H is correct about that, then H can never abort its simulation, 
so H lies.

If H does abort its simulation, it is incorrect about its conclusion 
that this is an infinitely recursive simulation.

H just doesn't understand the behavior of the H that it is simulating.

> 
> We can see that the first seven instructions of D simulated by H 
> precisely match the first seven instructions of the x86 source-code of 
> D. This conclusively proves that these instructions were simulated 
> correctly.
> 

So, we see that D will call an H that will simulate D again, and since 
we now know that H WILL abort its simulation when it gets to the call to 
H, we know that there is no infinite simulation loop, but that it will 
be aborted by H.

Until you can show that the two identical H's will actually behave 
differently, you are just claiming a lie.

This has been asked before, and you have failed to answer, thus showing 
that you admit you can't prove your claim, and it is just a fabricaiton 
and a lie

> Anyone sufficiently technically competent in the x86 programming 
> language will agree that the above execution trace of D simulated by H 
> shows that D will never reach its own "return" statement.

Which just proves that it is impossible for H to correct simulate this 
input to prove that it is Halting.

Your proof is just that the whole category of such deciders can never be 
correct.

> 
> H detects that D is calling itself with the exact same arguments that H 
> was called with and there are no conditional branch instructions from 
> the beginning of D to its call to H that can possibly escape the 
> repetition of this recursive simulation.

No, we KNOW that a CORRECT AND COMPLETE simulation of the input. not 
able to be done by H, will see the excape if H gives the answer 0, thus 
H is incorrect for the ACTUAL requriement.

It is only "correct" for your "strawman" requirement, which proves that 
that your claimed equivalent requirement is not actually equivalent by 
is just a strawman.

You are just proving your stupidity.
> 
> 
>>
>> *Simulating Halt Decider Applied to the Halting Theorem*
>> https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem
>>
>>
> 

[toc] | [prev] | [next] | [standalone]

#61683

On 2/15/2023 11:05 AM, Fritz Feldhase wrote:
> On Wednesday, February 15, 2023 at 1:57:50 AM UTC+1, olcott wrote:
> 
>> (a) If simulating halt decider H <bla bla>
> 
> The internal workings of a (claimed) "halt decider" is completely irrelevant in this context.
> 
> It can be shown that a (correct) _halt decider_ can't exist.
> 
> What's the matter with you, idiot? Can't you follow a simple argument?

All of my rebuttals in the last few months are specifically 
counter-factual.

void E(int (*x)())
{
   HH(x, x);
   return;
}

int main()
{
   HH(E,E);
}

When HH is a simulating halt decider anyone with a modicum of technical
competence can see that E correctly simulated by HH cannot possibly
reach its "return" statement and terminate normally, thus never halts.


-- 
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#61685

On 2/15/2023 2:46 PM, Fritz Feldhase wrote:
> On Wednesday, February 15, 2023 at 8:25:56 PM UTC+1, olcott wrote:
> 
> void E(int (*x)())
> {
>   HH(x, x);
>   return;
> }
> 
> int main()
> {
>   HH(E,E);
> }
> 
>> anyone [...] can see that E correctly simulated by HH cannot possibly
>> reach its "return" statement and terminate normally, thus never halts.
> 
> *lol* But then HH is _not_ a (correct) "halt decider". After all a (correct) "halt decider" H(P, X) has to decide if the program P with input X halts or doesn't halt. (In other words, H(P, X) has to terminate for any inputs P, X where P is a syntactically correct program.)
> 

That is not quite correct. HH must correctly predict whether or not E
correctly simulated by HH would ever reach its own "return" statement
(final state) and terminate normally.

> So if E (with input E) does not halt _as you say_ THEN a (correct) "halt decider" would have to "decide" (and return that decision) that E(E) does not halt. But since E (with input E) does not halt _as you say_ this means that HH(E, E) does not return anything (i.e. does not terminate) and hence is no a (correct) "halt decider".
> 

*This is a very common mistake on your part* HH need not infinitely
simulate E to determine that E would never halt. HH only needs to
simulate enough steps of E to see that E would continue to call HH in
recursive simulation thus never reaching the final state of E in any
finite number of simulated steps.

> Man, you are dense.
> 

-- 
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#61686

On 2/15/2023 3:26 PM, Fritz Feldhase wrote:
> On Wednesday, February 15, 2023 at 10:13:00 PM UTC+1, olcott wrote:
>> On 2/15/2023 2:46 PM, Fritz Feldhase wrote:
>>> On Wednesday, February 15, 2023 at 8:25:56 PM UTC+1, olcott wrote:
>>>
>>> void E(int (*x)())
>>> {
>>> HH(x, x);
>>> return;
>>> }
>>>
>>> int main()
>>> {
>>> HH(E,E);
>>> }
>>>
>>>> anyone [...] can see that E correctly simulated by HH cannot possibly
>>>> reach its "return" statement and terminate normally, thus never halts.
>>>
>>> *lol* But then HH is _not_ a (correct) "halt decider". After all a (correct) "halt decider" H(P, X) has to decide if the program P with input X halts or doesn't halt. (In other words, H(P, X) has to terminate for any inputs P, X where P is a syntactically correct program.)
>>>
>> That is not quite correct.
> 
> That is completely correct.
> 
> And now fuck off, you silly crank!
> 
> EOD
> 
> P.S. So if E (with input E) does not halt _as you say_  

HH correctly predicts that E correctly simulated by HH would not halt
HH correctly predicts that E correctly simulated by HH would not halt
HH correctly predicts that E correctly simulated by HH would not halt
HH correctly predicts that E correctly simulated by HH would not halt

> THEN a (correct) "halt decider" would have to "decide" (and return that decision) that E(E) does not halt. But since E (with input E) does not halt _as you say_ this means that HH(E, E) does not return anything (i.e. does not terminate) and hence is no a (correct) "halt decider".

-- 
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#61693

On 2/15/23 5:12 PM, olcott wrote:
> On 2/15/2023 3:26 PM, Fritz Feldhase wrote:
>> On Wednesday, February 15, 2023 at 10:13:00 PM UTC+1, olcott wrote:
>>> On 2/15/2023 2:46 PM, Fritz Feldhase wrote:
>>>> On Wednesday, February 15, 2023 at 8:25:56 PM UTC+1, olcott wrote:
>>>>
>>>> void E(int (*x)())
>>>> {
>>>> HH(x, x);
>>>> return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> HH(E,E);
>>>> }
>>>>
>>>>> anyone [...] can see that E correctly simulated by HH cannot possibly
>>>>> reach its "return" statement and terminate normally, thus never halts.
>>>>
>>>> *lol* But then HH is _not_ a (correct) "halt decider". After all a 
>>>> (correct) "halt decider" H(P, X) has to decide if the program P with 
>>>> input X halts or doesn't halt. (In other words, H(P, X) has to 
>>>> terminate for any inputs P, X where P is a syntactically correct 
>>>> program.)
>>>>
>>> That is not quite correct.
>>
>> That is completely correct.
>>
>> And now fuck off, you silly crank!
>>
>> EOD
>>
>> P.S. So if E (with input E) does not halt _as you say_ 
> 
> HH correctly predicts that E correctly simulated by HH would not halt
> HH correctly predicts that E correctly simulated by HH would not halt
> HH correctly predicts that E correctly simulated by HH would not halt
> HH correctly predicts that E correctly simulated by HH would not halt

So HH isn't a Halt Decider as a Halt Decider needs to correctly predict 
if E itself would Halt, of if E correcgtly simulatied by a REAL UTM 
would halt.

There is no reference to "By the decider", and there can't be, and be a 
decider of a property of just the input.



> 
>> THEN a (correct) "halt decider" would have to "decide" (and return 
>> that decision) that E(E) does not halt. But since E (with input E) 
>> does not halt _as you say_ this means that HH(E, E) does not return 
>> anything (i.e. does not terminate) and hence is no a (correct) "halt 
>> decider".
> 

[toc] | [prev] | [next] | [standalone]

#61692

On 2/15/23 4:12 PM, olcott wrote:
> On 2/15/2023 2:46 PM, Fritz Feldhase wrote:
>> On Wednesday, February 15, 2023 at 8:25:56 PM UTC+1, olcott wrote:
>>
>> void E(int (*x)())
>> {
>>   HH(x, x);
>>   return;
>> }
>>
>> int main()
>> {
>>   HH(E,E);
>> }
>>
>>> anyone [...] can see that E correctly simulated by HH cannot possibly
>>> reach its "return" statement and terminate normally, thus never halts.
>>
>> *lol* But then HH is _not_ a (correct) "halt decider". After all a 
>> (correct) "halt decider" H(P, X) has to decide if the program P with 
>> input X halts or doesn't halt. (In other words, H(P, X) has to 
>> terminate for any inputs P, X where P is a syntactically correct 
>> program.)
>>
> 
> That is not quite correct. HH must correctly predict whether or not E
> correctly simulated by HH would ever reach its own "return" statement
> (final state) and terminate normally.

No, by THE DEFINITION of a Halting Decider, HH must try to "correctly 
predict" whether or not E would reach its return statment when run, or, 
from the definition of a UTM, if the UTM simulaition of the input to HH 
would reach its final state (the "return").

There is NOTHING in the definition of a "Halt Decider" that refers to 
any behavior of a simulation of the input by the decider, AND THERE CAN 
NOT BE, as Halting is a property of the machine/input given to the 
decider and not at all a property of the decider being asked.

> 
>> So if E (with input E) does not halt _as you say_ THEN a (correct) 
>> "halt decider" would have to "decide" (and return that decision) that 
>> E(E) does not halt. But since E (with input E) does not halt _as you 
>> say_ this means that HH(E, E) does not return anything (i.e. does not 
>> terminate) and hence is no a (correct) "halt decider".
>>
> 
> *This is a very common mistake on your part* HH need not infinitely
> simulate E to determine that E would never halt. HH only needs to
> simulate enough steps of E to see that E would continue to call HH in
> recursive simulation thus never reaching the final state of E in any
> finite number of simulated steps.

Rigth, but it needs to predict what the behavior of a simulation that is 
never aborted would do, IF HH does abort its simulation, then it is NOT 
the "simulation done by the decider" that matters, only what that 
correct and unaborted simuation would do.

> 
>> Man, you are dense.
>>
> 

[toc] | [prev] | [next] | [standalone]

#61687

On 2/15/2023 3:32 PM, Ben Bacarisse wrote:
> Fritz Feldhase <franz.fritschee.ff@gmail.com> writes:
> 
>> On Wednesday, February 15, 2023 at 8:25:56 PM UTC+1, olcott wrote:
>>
>> void E(int (*x)())
>> {
>> HH(x, x);
>> return;
>> }
>>
>> int main()
>> {
>> HH(E,E);
>> }
>>
>>> anyone [...] can see that E correctly simulated by HH cannot possibly
>>> reach its "return" statement and terminate normally, thus never halts.
>>
>> *lol* But then HH is _not_ a (correct) "halt decider". After all a
>> (correct) "halt decider" H(P, X) has to decide if the program P with
>> input X halts or doesn't halt. (In other words, H(P, X) has to
>> terminate for any inputs P, X where P is a syntactically correct
>> program.)
> 
> There is a lot of history here.  PO has redefined what "halting" means
> and has been waffling for a few years trying to find a way to say it
> that makes the ruse less obvious.  There is, however, absolutely no
> doubt that that is what he's up to:
> 
>    "A non-halting computation is every computation that never halts
>    unless its simulation is aborted.  This maps to every element of
>    the conventional halting problem set of non-halting computations
>    *and a few more*."  (emphasis mine)
> 

HH correctly predicts that E correctly simulated by HH would not halt
HH correctly predicts that E correctly simulated by HH would not halt
HH correctly predicts that E correctly simulated by HH would not halt
HH correctly predicts that E correctly simulated by HH would not halt




-- 
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#61696

On 2/15/2023 7:47 PM, Ben Bacarisse wrote:
> Fritz Feldhase <franz.fritschee.ff@gmail.com> writes:
> 
>> On Wednesday, February 15, 2023 at 10:32:19 PM UTC+1, Ben Bacarisse wrote:
>>
>>> Me: do you still assert that H(P,P) == false is the "correct" answer
>>> even though P(P) halts?
>>>
>>> PO: Yes that is the correct answer even though P(P) halts.
>>
>> Wow!
>>
>> So for PO H is a "correct halt decider" even if it states that a
>> program P with input P _doesn't halt_, though it _halts_.
>>
>> Well, what can I say?
> 
> What indeed.  I think this is pretty much the only reply that should be
> made to PO.  He may, one day, admit that that was wrong and start to
> build a new waffle mountain, but until then, its game over.
> 
>> Seems that all cranks are more or less "the same" (in a certain
>> sense): WM, PO, JG, AP, etc.
> 
> In some way yes, but they all disagree with each other when the surface
> is scratched because they all want to be the unique individual who as
> seen clearly where everyone else was blind.  I would not be surprised if
> they all had NPD.
> 
>> See:
>> https://context.reverso.net/%C3%BCbersetzung/spanisch-englisch/loco%2C+loco
> 
> Possibly literally!
> 

int D(int (*x)())
{
   int Halt_Status = H(x, x);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

int main()
{
   Output("Input_Halts = ", H(D,D));
   Output("Input_Halts = ", D(D));
}

None-the-less Ben will not lie about:
*H correctly predicts that D correctly simulated by H would never halt*
*H correctly predicts that D correctly simulated by H would never halt*
*H correctly predicts that D correctly simulated by H would never halt*

-- 
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#61697

On 2/15/23 9:22 PM, olcott wrote:
> On 2/15/2023 7:47 PM, Ben Bacarisse wrote:
>> Fritz Feldhase <franz.fritschee.ff@gmail.com> writes:
>>
>>> On Wednesday, February 15, 2023 at 10:32:19 PM UTC+1, Ben Bacarisse 
>>> wrote:
>>>
>>>> Me: do you still assert that H(P,P) == false is the "correct" answer
>>>> even though P(P) halts?
>>>>
>>>> PO: Yes that is the correct answer even though P(P) halts.
>>>
>>> Wow!
>>>
>>> So for PO H is a "correct halt decider" even if it states that a
>>> program P with input P _doesn't halt_, though it _halts_.
>>>
>>> Well, what can I say?
>>
>> What indeed.  I think this is pretty much the only reply that should be
>> made to PO.  He may, one day, admit that that was wrong and start to
>> build a new waffle mountain, but until then, its game over.
>>
>>> Seems that all cranks are more or less "the same" (in a certain
>>> sense): WM, PO, JG, AP, etc.
>>
>> In some way yes, but they all disagree with each other when the surface
>> is scratched because they all want to be the unique individual who as
>> seen clearly where everyone else was blind.  I would not be surprised if
>> they all had NPD.
>>
>>> See:
>>> https://context.reverso.net/%C3%BCbersetzung/spanisch-englisch/loco%2C+loco
>>
>> Possibly literally!
>>
> 
> int D(int (*x)())
> {
>    int Halt_Status = H(x, x);
>    if (Halt_Status)
>      HERE: goto HERE;
>    return Halt_Status;
> }
> 
> int main()
> {
>    Output("Input_Halts = ", H(D,D));
>    Output("Input_Halts = ", D(D));
> }
> 
> None-the-less Ben will not lie about:
> *H correctly predicts that D correctly simulated by H would never halt*
> *H correctly predicts that D correctly simulated by H would never halt*
> *H correctly predicts that D correctly simulated by H would never halt*
> 

So, you aren't working on the Halting Problem so your HH isn't actually 
a Halting Decider.

Remember:

In computability theory, the halting problem is the problem of 
determining, from a description of an arbitrary computer program and an 
input, whether the program will finish running, or continue to run forever.


**WHETHER THE PROGRAM WILL FINISH RUNNING**

Note if some sort of somulation by H would never halt, which can't be 
"correct" since a "correct simulation" show the actual behavior of the 
thing simulated, and it has been shown that D(D) will Halt since H(D,D) 
returns 0.

You are just proving you are ignorant of what you are talking about and 
are just a patholgocial liar not caring if your words are accurate.

[toc] | [prev] | [next] | [standalone]

#61698

On 2/15/2023 8:22 PM, olcott wrote:
> On 2/15/2023 7:47 PM, Ben Bacarisse wrote:
>> Fritz Feldhase <franz.fritschee.ff@gmail.com> writes:
>>
>>> On Wednesday, February 15, 2023 at 10:32:19 PM UTC+1, Ben Bacarisse 
>>> wrote:
>>>
>>>> Me: do you still assert that H(P,P) == false is the "correct" answer
>>>> even though P(P) halts?
>>>>
>>>> PO: Yes that is the correct answer even though P(P) halts.
>>>
>>> Wow!
>>>
>>> So for PO H is a "correct halt decider" even if it states that a
>>> program P with input P _doesn't halt_, though it _halts_.
>>>
>>> Well, what can I say?
>>
>> What indeed.  I think this is pretty much the only reply that should be
>> made to PO.  He may, one day, admit that that was wrong and start to
>> build a new waffle mountain, but until then, its game over.
>>
>>> Seems that all cranks are more or less "the same" (in a certain
>>> sense): WM, PO, JG, AP, etc.
>>
>> In some way yes, but they all disagree with each other when the surface
>> is scratched because they all want to be the unique individual who as
>> seen clearly where everyone else was blind.  I would not be surprised if
>> they all had NPD.
>>
>>> See:
>>> https://context.reverso.net/%C3%BCbersetzung/spanisch-englisch/loco%2C+loco
>>
>> Possibly literally!
>>
> 
> int D(int (*x)())
> {
>    int Halt_Status = H(x, x);
>    if (Halt_Status)
>      HERE: goto HERE;
>    return Halt_Status;
> }
> 
> int main()
> {
>    Output("Input_Halts = ", H(D,D));
>    Output("Input_Halts = ", D(D));
> }
> 
> None-the-less Ben will not lie about:
> *H correctly predicts that D correctly simulated by H would never halt*
> *H correctly predicts that D correctly simulated by H would never halt*
> *H correctly predicts that D correctly simulated by H would never halt*

In other words because Ben is not a liar he implicitly affirms that
H(D,D) does correctly compute the mapping from its input to its reject
state on the above basis.

-- 
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#61699

On 2/15/23 9:39 PM, olcott wrote:
> On 2/15/2023 8:22 PM, olcott wrote:
>> On 2/15/2023 7:47 PM, Ben Bacarisse wrote:
>>> Fritz Feldhase <franz.fritschee.ff@gmail.com> writes:
>>>
>>>> On Wednesday, February 15, 2023 at 10:32:19 PM UTC+1, Ben Bacarisse 
>>>> wrote:
>>>>
>>>>> Me: do you still assert that H(P,P) == false is the "correct" answer
>>>>> even though P(P) halts?
>>>>>
>>>>> PO: Yes that is the correct answer even though P(P) halts.
>>>>
>>>> Wow!
>>>>
>>>> So for PO H is a "correct halt decider" even if it states that a
>>>> program P with input P _doesn't halt_, though it _halts_.
>>>>
>>>> Well, what can I say?
>>>
>>> What indeed.  I think this is pretty much the only reply that should be
>>> made to PO.  He may, one day, admit that that was wrong and start to
>>> build a new waffle mountain, but until then, its game over.
>>>
>>>> Seems that all cranks are more or less "the same" (in a certain
>>>> sense): WM, PO, JG, AP, etc.
>>>
>>> In some way yes, but they all disagree with each other when the surface
>>> is scratched because they all want to be the unique individual who as
>>> seen clearly where everyone else was blind.  I would not be surprised if
>>> they all had NPD.
>>>
>>>> See:
>>>> https://context.reverso.net/%C3%BCbersetzung/spanisch-englisch/loco%2C+loco
>>>
>>> Possibly literally!
>>>
>>
>> int D(int (*x)())
>> {
>>    int Halt_Status = H(x, x);
>>    if (Halt_Status)
>>      HERE: goto HERE;
>>    return Halt_Status;
>> }
>>
>> int main()
>> {
>>    Output("Input_Halts = ", H(D,D));
>>    Output("Input_Halts = ", D(D));
>> }
>>
>> None-the-less Ben will not lie about:
>> *H correctly predicts that D correctly simulated by H would never halt*
>> *H correctly predicts that D correctly simulated by H would never halt*
>> *H correctly predicts that D correctly simulated by H would never halt*
> 
> In other words because Ben is not a liar he implicitly affirms that
> H(D,D) does correctly compute the mapping from its input to its reject
> state on the above basis.
> 

No, he says you THINK "A Correct Halt Decider" can say what you say it 
does, even if that isn't the actual definition of a corect halt decider.


Read what he asy again

He says that for YOU, H is correct, ... even if it states that a program 
doesn't halt when it halts.

You are just showing you don't understand English.

[toc] | [prev] | [next] | [standalone]

#61700

On 2/15/2023 8:39 PM, olcott wrote:
> On 2/15/2023 8:22 PM, olcott wrote:
>> On 2/15/2023 7:47 PM, Ben Bacarisse wrote:
>>> Fritz Feldhase <franz.fritschee.ff@gmail.com> writes:
>>>
>>>> On Wednesday, February 15, 2023 at 10:32:19 PM UTC+1, Ben Bacarisse 
>>>> wrote:
>>>>
>>>>> Me: do you still assert that H(P,P) == false is the "correct" answer
>>>>> even though P(P) halts?
>>>>>
>>>>> PO: Yes that is the correct answer even though P(P) halts.
>>>>
>>>> Wow!
>>>>
>>>> So for PO H is a "correct halt decider" even if it states that a
>>>> program P with input P _doesn't halt_, though it _halts_.
>>>>
>>>> Well, what can I say?
>>>
>>> What indeed.  I think this is pretty much the only reply that should be
>>> made to PO.  He may, one day, admit that that was wrong and start to
>>> build a new waffle mountain, but until then, its game over.
>>>
>>>> Seems that all cranks are more or less "the same" (in a certain
>>>> sense): WM, PO, JG, AP, etc.
>>>
>>> In some way yes, but they all disagree with each other when the surface
>>> is scratched because they all want to be the unique individual who as
>>> seen clearly where everyone else was blind.  I would not be surprised if
>>> they all had NPD.
>>>
>>>> See:
>>>> https://context.reverso.net/%C3%BCbersetzung/spanisch-englisch/loco%2C+loco
>>>
>>> Possibly literally!
>>>
>>
>> int D(int (*x)())
>> {
>>    int Halt_Status = H(x, x);
>>    if (Halt_Status)
>>      HERE: goto HERE;
>>    return Halt_Status;
>> }
>>
>> int main()
>> {
>>    Output("Input_Halts = ", H(D,D));
>>    Output("Input_Halts = ", D(D));
>> }
>>
>> None-the-less Ben will not lie about:
>> *H correctly predicts that D correctly simulated by H would never halt*
>> *H correctly predicts that D correctly simulated by H would never halt*
>> *H correctly predicts that D correctly simulated by H would never halt*
> 
> In other words because Ben is not a liar he implicitly affirms that
> H(D,D) does correctly compute the mapping from its input to its reject
> state on the above basis.
> 

There are all kinds of way to weasel word around the above two verified
facts that will fool the gullible.

*None-the-less this verified fact remains irrefutable*

H(D,D) does correctly compute the mapping from its input to its reject
state on the basis that H correctly predicts that D correctly simulated
by H would never halt.


-- 
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#61701

On 2/15/23 10:15 PM, olcott wrote:
> On 2/15/2023 8:39 PM, olcott wrote:
>> On 2/15/2023 8:22 PM, olcott wrote:
>>> On 2/15/2023 7:47 PM, Ben Bacarisse wrote:
>>>> Fritz Feldhase <franz.fritschee.ff@gmail.com> writes:
>>>>
>>>>> On Wednesday, February 15, 2023 at 10:32:19 PM UTC+1, Ben Bacarisse 
>>>>> wrote:
>>>>>
>>>>>> Me: do you still assert that H(P,P) == false is the "correct" answer
>>>>>> even though P(P) halts?
>>>>>>
>>>>>> PO: Yes that is the correct answer even though P(P) halts.
>>>>>
>>>>> Wow!
>>>>>
>>>>> So for PO H is a "correct halt decider" even if it states that a
>>>>> program P with input P _doesn't halt_, though it _halts_.
>>>>>
>>>>> Well, what can I say?
>>>>
>>>> What indeed.  I think this is pretty much the only reply that should be
>>>> made to PO.  He may, one day, admit that that was wrong and start to
>>>> build a new waffle mountain, but until then, its game over.
>>>>
>>>>> Seems that all cranks are more or less "the same" (in a certain
>>>>> sense): WM, PO, JG, AP, etc.
>>>>
>>>> In some way yes, but they all disagree with each other when the surface
>>>> is scratched because they all want to be the unique individual who as
>>>> seen clearly where everyone else was blind.  I would not be 
>>>> surprised if
>>>> they all had NPD.
>>>>
>>>>> See:
>>>>> https://context.reverso.net/%C3%BCbersetzung/spanisch-englisch/loco%2C+loco
>>>>
>>>> Possibly literally!
>>>>
>>>
>>> int D(int (*x)())
>>> {
>>>    int Halt_Status = H(x, x);
>>>    if (Halt_Status)
>>>      HERE: goto HERE;
>>>    return Halt_Status;
>>> }
>>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ", H(D,D));
>>>    Output("Input_Halts = ", D(D));
>>> }
>>>
>>> None-the-less Ben will not lie about:
>>> *H correctly predicts that D correctly simulated by H would never halt*
>>> *H correctly predicts that D correctly simulated by H would never halt*
>>> *H correctly predicts that D correctly simulated by H would never halt*
>>
>> In other words because Ben is not a liar he implicitly affirms that
>> H(D,D) does correctly compute the mapping from its input to its reject
>> state on the above basis.
>>
> 
> There are all kinds of way to weasel word around the above two verified
> facts that will fool the gullible.
> 
> *None-the-less this verified fact remains irrefutable*
> 
> H(D,D) does correctly compute the mapping from its input to its reject
> state on the basis that H correctly predicts that D correctly simulated
> by H would never halt.
> 
> 

Which isn't Halt Deciding but just Peter Olcott's Other Problem (POOP) 
deciding.

In computability theory, the halting problem is the problem of 
determining, from a description of an arbitrary computer program and an 
input, whether the program will finish running, or continue to run forever.

Thus a HALT DECIDER must report on the behavior of whether the ACTUAL 
PROGRAM (described by the input) would Halt or not.

D(D) Halts, since H(D,D) returns 0.

THus, for an actual Halt Decider, the correct answer is Halting.

Since you say the "Correct Answer" in Not Halting, the question CAN'T be 
the Halting Problem, or you are just proving you are a LIAR.

You H may in fact be a correct POOP decider, which you THINK is a Halt 
Decider, but it isn't one.

PERIOD.

All your weasle words to claim otherwise are just revealed to be what 
they are, and you are proved to be an idiot as you can't tell the 
difference between POOP and Halting.

[toc] | [prev] | [next] | [standalone]

#61702

On 2/15/2023 9:15 PM, olcott wrote:
> On 2/15/2023 8:39 PM, olcott wrote:
>> On 2/15/2023 8:22 PM, olcott wrote:
>>> On 2/15/2023 7:47 PM, Ben Bacarisse wrote:
>>>> Fritz Feldhase <franz.fritschee.ff@gmail.com> writes:
>>>>
>>>>> On Wednesday, February 15, 2023 at 10:32:19 PM UTC+1, Ben Bacarisse 
>>>>> wrote:
>>>>>
>>>>>> Me: do you still assert that H(P,P) == false is the "correct" answer
>>>>>> even though P(P) halts?
>>>>>>
>>>>>> PO: Yes that is the correct answer even though P(P) halts.
>>>>>
>>>>> Wow!
>>>>>
>>>>> So for PO H is a "correct halt decider" even if it states that a
>>>>> program P with input P _doesn't halt_, though it _halts_.
>>>>>
>>>>> Well, what can I say?
>>>>
>>>> What indeed.  I think this is pretty much the only reply that should be
>>>> made to PO.  He may, one day, admit that that was wrong and start to
>>>> build a new waffle mountain, but until then, its game over.
>>>>
>>>>> Seems that all cranks are more or less "the same" (in a certain
>>>>> sense): WM, PO, JG, AP, etc.
>>>>
>>>> In some way yes, but they all disagree with each other when the surface
>>>> is scratched because they all want to be the unique individual who as
>>>> seen clearly where everyone else was blind.  I would not be 
>>>> surprised if
>>>> they all had NPD.
>>>>
>>>>> See:
>>>>> https://context.reverso.net/%C3%BCbersetzung/spanisch-englisch/loco%2C+loco
>>>>
>>>> Possibly literally!
>>>>
>>>
>>> int D(int (*x)())
>>> {
>>>    int Halt_Status = H(x, x);
>>>    if (Halt_Status)
>>>      HERE: goto HERE;
>>>    return Halt_Status;
>>> }
>>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ", H(D,D));
>>>    Output("Input_Halts = ", D(D));
>>> }
>>>
>>> None-the-less Ben will not lie about:
>>> *H correctly predicts that D correctly simulated by H would never halt*
>>> *H correctly predicts that D correctly simulated by H would never halt*
>>> *H correctly predicts that D correctly simulated by H would never halt*
>>
>> In other words because Ben is not a liar he implicitly affirms that
>> H(D,D) does correctly compute the mapping from its input to its reject
>> state on the above basis.
>>
> 
> There are all kinds of way to weasel word around the above two verified
> facts that will fool the gullible.
> 
> *None-the-less this verified fact remains irrefutable*
> 
> H(D,D) does correctly compute the mapping from its input to its reject
> state on the basis that H correctly predicts that D correctly simulated
> by H would never halt.

*Finally a most important key point of agreement*

Now we are at the point where I said that I painted my house white and
people disagree on the basis that the can of paint said that the color
was eggshell.

-- 
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#61703

On 2/15/23 10:28 PM, olcott wrote:
> On 2/15/2023 9:15 PM, olcott wrote:
>> On 2/15/2023 8:39 PM, olcott wrote:
>>> On 2/15/2023 8:22 PM, olcott wrote:
>>>> On 2/15/2023 7:47 PM, Ben Bacarisse wrote:
>>>>> Fritz Feldhase <franz.fritschee.ff@gmail.com> writes:
>>>>>
>>>>>> On Wednesday, February 15, 2023 at 10:32:19 PM UTC+1, Ben 
>>>>>> Bacarisse wrote:
>>>>>>
>>>>>>> Me: do you still assert that H(P,P) == false is the "correct" answer
>>>>>>> even though P(P) halts?
>>>>>>>
>>>>>>> PO: Yes that is the correct answer even though P(P) halts.
>>>>>>
>>>>>> Wow!
>>>>>>
>>>>>> So for PO H is a "correct halt decider" even if it states that a
>>>>>> program P with input P _doesn't halt_, though it _halts_.
>>>>>>
>>>>>> Well, what can I say?
>>>>>
>>>>> What indeed.  I think this is pretty much the only reply that 
>>>>> should be
>>>>> made to PO.  He may, one day, admit that that was wrong and start to
>>>>> build a new waffle mountain, but until then, its game over.
>>>>>
>>>>>> Seems that all cranks are more or less "the same" (in a certain
>>>>>> sense): WM, PO, JG, AP, etc.
>>>>>
>>>>> In some way yes, but they all disagree with each other when the 
>>>>> surface
>>>>> is scratched because they all want to be the unique individual who as
>>>>> seen clearly where everyone else was blind.  I would not be 
>>>>> surprised if
>>>>> they all had NPD.
>>>>>
>>>>>> See:
>>>>>> https://context.reverso.net/%C3%BCbersetzung/spanisch-englisch/loco%2C+loco
>>>>>
>>>>> Possibly literally!
>>>>>
>>>>
>>>> int D(int (*x)())
>>>> {
>>>>    int Halt_Status = H(x, x);
>>>>    if (Halt_Status)
>>>>      HERE: goto HERE;
>>>>    return Halt_Status;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    Output("Input_Halts = ", H(D,D));
>>>>    Output("Input_Halts = ", D(D));
>>>> }
>>>>
>>>> None-the-less Ben will not lie about:
>>>> *H correctly predicts that D correctly simulated by H would never halt*
>>>> *H correctly predicts that D correctly simulated by H would never halt*
>>>> *H correctly predicts that D correctly simulated by H would never halt*
>>>
>>> In other words because Ben is not a liar he implicitly affirms that
>>> H(D,D) does correctly compute the mapping from its input to its reject
>>> state on the above basis.
>>>
>>
>> There are all kinds of way to weasel word around the above two verified
>> facts that will fool the gullible.
>>
>> *None-the-less this verified fact remains irrefutable*
>>
>> H(D,D) does correctly compute the mapping from its input to its reject
>> state on the basis that H correctly predicts that D correctly simulated
>> by H would never halt.
> 
> *Finally a most important key point of agreement*
> 
> Now we are at the point where I said that I painted my house white and
> people disagree on the basis that the can of paint said that the color
> was eggshell.
> 

So, you still think that your POOP is halting, because you don't know 
the difference.

In computability theory, the halting problem is the problem of 
determining, from a description of an arbitrary computer program and an 
input, whether the program will finish running, or continue to run forever.

This says NOTHING about the decider being able to argue about it being 
unable to simulate to a final state.

The ONLY thing that matters is the behavior of the actual machine. PERIOD.

Anything else either must be actually equivalent, so the answer is the 
same, or it isn't a correct interpreation.

This is like you saying you painted the house white, but the color is 
actually purple.

Your idea of what "Halting" means isn't compatible with the actual 
definition in all cases, and H^/P/D is one of the cases it differs. You 
are just too blind to be able to tell the difference.

You may THINK its just like White vs Eggshell, but that just shows you 
don't actually understand what you are talking about.

Ultimately, you have made the explicit claim that even though D(D) 
Halts, that Non-Halting is the correct answer for H to give as a Halt 
Decider.

THAT IS WRONG. PERIOD.

Your claim just proves you are either totally ignorant, or a 
pathological liar, or most likely BOTH.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.theory

csiph-web