Groups | Search | Server Info | Login | Register

Groups > comp.ai.philosophy > #29790

Re: Refutation of the Ben Bacarisse Rebuttal

Cross-posted to 3 groups.

Show all headers | View raw

On 6/20/2023 3:32 PM, Richard Damon wrote:
> On 6/20/23 2:33 PM, olcott wrote:
>> On 6/20/2023 1:20 PM, Richard Damon wrote:
>>> On 6/20/23 1:46 PM, olcott wrote:
>>>> On 6/20/2023 10:48 AM, Richard Damon wrote:
>>>>> On 6/20/23 11:02 AM, olcott wrote:
>>>>>> On 6/20/2023 6:19 AM, Richard Damon wrote:
>>>>>>> On 6/19/23 11:46 PM, olcott wrote:
>>>>>>>> On 6/19/2023 8:13 PM, Richard Damon wrote:
>>>>>>>>> On 6/19/23 9:02 PM, olcott wrote:
>>>>>>>>>> On 6/19/2023 7:45 PM, Richard Damon wrote:
>>>>>>>>>>> On 6/19/23 4:43 PM, olcott wrote:
>>>>>>>>>>>> The behavior of the directly executed P(P) is different than 
>>>>>>>>>>>> the
>>>>>>>>>>>> behavior of P(P) correctly simulated by H because in the 
>>>>>>>>>>>> first case H
>>>>>>>>>>>> has already aborted its simulation of its input and in the 
>>>>>>>>>>>> second case
>>>>>>>>>>>> this has not yet occurred.
>>>>>>>>>>>
>>>>>>>>>>> By what definition of "Correctly Simulated"?
>>>>>>>>>>>
>>>>>>>>>>> The fact that H aborts its simulation has NO affect on the 
>>>>>>>>>>> direct execution of the machine, so all you are saying that H 
>>>>>>>>>>> has shut its eyes and said "I don't see it, so it didn't 
>>>>>>>>>>> happen".
>>>>>>>>>>>
>>>>>>>>>>> That is just FALSEHOOD.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I now refer to P(P) as D(D).
>>>>>>>>>>>>
>>>>>>>>>>>> Can D correctly simulated by H terminate normally?
>>>>>>>>>>>> No it cannot see the details below.
>>>>>>>>>>>
>>>>>>>>>>> Which is not the question being asked. The fact that it is 
>>>>>>>>>>> impossible to design an H that can correctly simulate its 
>>>>>>>>>>> input to a halting state just proves that H can not correctly 
>>>>>>>>>>> decider that its input is Halting.
>>>>>>>>>>>
>>>>>>>>>>> This does NOT mean that the input can't be Halting, just that 
>>>>>>>>>>> H can never prove it.
>>>>>>>>>>>
>>>>>>>>>>> IF H doesn't ever abort its simulation, then yes, the D built 
>>>>>>>>>>> on that H is non-halting, but that H never gives that answer, 
>>>>>>>>>>> so it is still wrong.
>>>>>>>>>>>
>>>>>>>>>>> Each H gets a DIFFERENT D, since they include the H that the 
>>>>>>>>>>> "pathological test" is to be performed on, so the behavior of 
>>>>>>>>>>> one D built on a different H doesn't apply, and for correct 
>>>>>>>>>>> reasoning, you really need to give each one a different name. 
>>>>>>>>>>> Reusing the same name for different machine, and then trying 
>>>>>>>>>>> to confuse which one is which is just a sign of being 
>>>>>>>>>>> intentionally deceptive to try to tell a LIE.
>>>>>>>>>>>>
>>>>>>>>>>>> The x86utm operating system based on an open source x86 
>>>>>>>>>>>> emulator. This
>>>>>>>>>>>> system enables one C function to execute another C function 
>>>>>>>>>>>> in debug
>>>>>>>>>>>> step mode. When H simulates D it creates a separate process 
>>>>>>>>>>>> context for
>>>>>>>>>>>> D with its own memory, stack and virtual registers. H is 
>>>>>>>>>>>> able to
>>>>>>>>>>>> simulate D simulating itself, thus the only limit to recursive
>>>>>>>>>>>> simulations is RAM.
>>>>>>>>>>>
>>>>>>>>>>> But D is not SPECIFIED in a seperate context, but share code 
>>>>>>>>>>> space with H, which means it fails to be truely distinctly, 
>>>>>>>>>>> like a Turing Machine would be.
>>>>>>>>>>>
>>>>>>>>>>> It is NOT a full "separate process context" as all the 
>>>>>>>>>>> contexts share code space.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> // The following is written in C
>>>>>>>>>>>> //
>>>>>>>>>>>> 01 typedef int (*ptr)(); // pointer to int function
>>>>>>>>>>>> 02 int H(ptr x, ptr y)   // uses x86 emulator to simulate 
>>>>>>>>>>>> its input
>>>>>>>>>>>> 03
>>>>>>>>>>>> 04 int D(ptr x)
>>>>>>>>>>>> 05 {
>>>>>>>>>>>> 06   int Halt_Status = H(x, x);
>>>>>>>>>>>> 07   if (Halt_Status)
>>>>>>>>>>>> 08     HERE: goto HERE;
>>>>>>>>>>>> 09   return Halt_Status;
>>>>>>>>>>>> 10 }
>>>>>>>>>>>> 11
>>>>>>>>>>>> 12 void main()
>>>>>>>>>>>> 13 {
>>>>>>>>>>>> 14   D(D);
>>>>>>>>>>>> 15 }
>>>>>>>>>>>>
>>>>>>>>>>>> D correctly simulated by H cannot possibly terminate 
>>>>>>>>>>>> normally by reaching its own final state at line 09.
>>>>>>>>>>>
>>>>>>>>>>> But D correctly simulated by a correct simulator would, at 
>>>>>>>>>>> least as long as you are using an H that answer H(D,D) as 0, 
>>>>>>>>>>> as you claim.
>>>>>>>>>> H correctly simulates N steps of D until H correctly predicts 
>>>>>>>>>> through
>>>>>>>>>> the type of mathematical induction used by termination 
>>>>>>>>>> analyzers that D
>>>>>>>>>> correctly simulated by H cannot possibly terminate normally.
>>>>>>>>>
>>>>>>>>> But that is the wrong prediction. It needs to predict if the 
>>>>>>>>> input when run will halt, as THAT is the Halting Question.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That is just like Jack's question posed to Jack, 
>>>>>>>> self-contradictory.
>>>>>>>> ChatGPT could understand that I am correct.
>>>>>>>
>>>>>>> Nope, and you just seem too stupid to understand.
>>>>>>>
>>>>>>>>
>>>>>>>>> Thus, you are just admitting to working on POOP instead of 
>>>>>>>>> Halting, and ALL your statements are just LIES.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> int factorial(int n)
>>>>>>>>>> {
>>>>>>>>>>    if(n==0)
>>>>>>>>>>      return(1);
>>>>>>>>>>    return(n*factorial(n-1));
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> AProVE correctly determines that factorial(5) halts by
>>>>>>>>>> boiling the key behavior of entire function to this:
>>>>>>>>>> f(x) → f(x-1) :|: x > 0 && x <= 5
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>  > Wrong Question leads to incorrect answer, and all your work 
>>>>>>>>> goes down
>>>>>>>>> the drain.
>>>>>>>>>
>>>>>>>>
>>>>>>>> AProVE is the largest termination analysis project in the world.
>>>>>>>
>>>>>>> Yes, and it probably uses the RIGHT question, will the program 
>>>>>>> halt when actually run.
>>>>>>>
>>>>>>> It will probably also tell you that D(D) will Halt since H(D,D) 
>>>>>>> returns 0.
>>>>>>>
>>>>>>> Thus, it likely shows you are wrong about everything.
>>>>>>
>>>>>> When we use the criteria:
>>>>>> Can D correctly simulated by H ever terminate normally?
>>>>>
>>>>> So you are ADMITTING to working on a different problem, and lying 
>>>>> about what you are doing. Thank you for being honest about that.
>>>>>
>>>>> Ben is just pointing out the ERRORS in your logic
>>>>>
>>>>
>>>> When Ben pointed out that H(P,P) reports that P(P) does not halt when
>>>> P(P) does halt this seems to be a contradiction to people that lack a
>>>> complete understanding.
>>>
>>> NO, it is a TRUE statement. H is NOT a correct HALT DECIDER.
>>>
>>> It might be a valid POOP decider with your altered criteria, but it 
>>> isn't correct as a Halt Decider.
>>>
>>> You don't get to change the meaning of words, attempting to just 
>>> shows you are a liar.
>>>
>>> Halting is a property of the original machine, not of the partial 
>>> simulation that H does.
>>>>
>>>> Because of this I changed the semantic meaning of a return value of 0
>>>> from H to mean either that P(P) does not halt or P(P) specifically
>>>> targets H to do the opposite of whatever Boolean value that H returns.
>>>
>>> Which means you H need to return BOTH a 0 and 1 at the same time, 
>> Not at all. Not the least little bit.
>> A return value of 0 also indicates that input D intentionally targets
>> H by doing the opposite of whatever Boolean value that H returns.
> 
> But a return of 1 signals that it halts, which it does.
> 
> You don't seem to understand English.
> 
> The Halting Problem asks if the Machine Described by the input Halts.
> 
> It Does (for the H that you are cliaming to be correct)
> 
> Therefore, the correct answer is YES / Halting, and you are PROVED to be 
> a LIAR.
If I am the one that is a Liar then why did you already say that 1 is
the wrong answer and are now saying that it is the right answer?

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

Back to comp.ai.philosophy | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Refutation of the Ben Bacarisse Rebuttal olcott <polcott2@gmail.com> - 2023-06-19 15:43 -0500
  Re: Refutation of the Ben Bacarisse Rebuttal Richard Damon <Richard@Damon-Family.org> - 2023-06-19 20:45 -0400
    Re: Refutation of the Ben Bacarisse Rebuttal olcott <polcott2@gmail.com> - 2023-06-19 20:02 -0500
      Re: Refutation of the Ben Bacarisse Rebuttal Richard Damon <news.x.richarddamon@xoxy.net> - 2023-06-19 21:13 -0400
        Re: Refutation of the Ben Bacarisse Rebuttal olcott <polcott2@gmail.com> - 2023-06-19 22:46 -0500
          Re: Refutation of the Ben Bacarisse Rebuttal Richard Damon <Richard@Damon-Family.org> - 2023-06-20 07:19 -0400
            Re: Refutation of the Ben Bacarisse Rebuttal olcott <polcott2@gmail.com> - 2023-06-20 10:02 -0500
              Re: Refutation of the Ben Bacarisse Rebuttal Richard Damon <Richard@Damon-Family.org> - 2023-06-20 11:48 -0400
                Re: Refutation of the Ben Bacarisse Rebuttal olcott <polcott2@gmail.com> - 2023-06-20 12:46 -0500
                Re: Refutation of the Ben Bacarisse Rebuttal Richard Damon <Richard@Damon-Family.org> - 2023-06-20 14:20 -0400
                Re: Refutation of the Ben Bacarisse Rebuttal olcott <polcott2@gmail.com> - 2023-06-20 13:33 -0500
                Re: Refutation of the Ben Bacarisse Rebuttal Richard Damon <Richard@Damon-Family.org> - 2023-06-20 16:32 -0400
                Re: Refutation of the Ben Bacarisse Rebuttal olcott <polcott2@gmail.com> - 2023-06-20 15:38 -0500
                Re: Refutation of the Ben Bacarisse Rebuttal Richard Damon <Richard@Damon-Family.org> - 2023-06-20 16:46 -0400
                Re: Refutation of the Ben Bacarisse Rebuttal olcott <polcott2@gmail.com> - 2023-06-20 16:27 -0500
                Re: Refutation of the Ben Bacarisse Rebuttal Richard Damon <Richard@Damon-Family.org> - 2023-06-20 17:56 -0400
                Re: Refutation of the Ben Bacarisse Rebuttal olcott <polcott2@gmail.com> - 2023-06-20 17:19 -0500
                Re: Refutation of the Ben Bacarisse Rebuttal Richard Damon <Richard@Damon-Family.org> - 2023-06-20 18:52 -0400
                Re: Refutation of the Ben Bacarisse Rebuttal olcott <polcott2@gmail.com> - 2023-06-20 17:59 -0500
                Re: Refutation of the Ben Bacarisse Rebuttal Richard Damon <Richard@Damon-Family.org> - 2023-06-20 20:41 -0400
                Re: Refutation of the Ben Bacarisse Rebuttal olcott <polcott2@gmail.com> - 2023-06-20 20:36 -0500
                Re: Refutation of the Ben Bacarisse Rebuttal Richard Damon <Richard@Damon-Family.org> - 2023-06-20 22:32 -0400
                Re: Refutation of the Ben Bacarisse Rebuttal olcott <polcott2@gmail.com> - 2023-06-20 21:59 -0500
                Re: Refutation of the Ben Bacarisse Rebuttal Richard Damon <Richard@Damon-Family.org> - 2023-06-21 07:38 -0400
                Re: Refutation of the Ben Bacarisse Rebuttal olcott <polcott2@gmail.com> - 2023-06-21 12:32 -0500
                Re: Refutation of the Ben Bacarisse Rebuttal Richard Damon <Richard@Damon-Family.org> - 2023-06-21 19:01 -0400
        Re: Refutation of [nothing] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-06-20 12:48 +0100
          Ben Bacarisse specifically targets my posts to discourage honest dialogue ... olcott <polcott2@gmail.com> - 2023-06-20 10:03 -0500
          Re: Refutation of [nothing] (Ben Bacarisse lies about this see below) olcott <polcott2@gmail.com> - 2023-06-22 13:00 -0500
            Re: Refutation of [nothing] (Peter Olcott lies about this see below) Richard Damon <Richard@Damon-Family.org> - 2023-06-22 21:06 -0400

csiph-web