Groups | Search | Server Info | Login | Register

Groups > comp.theory > #65041

Re: Refutation of the Ben Bacarisse Rebuttal

Cross-posted to 3 groups.

Show all headers | View raw

On 6/20/23 6:19 PM, olcott wrote:
> On 6/20/2023 4:56 PM, Richard Damon wrote:
>> On 6/20/23 5:27 PM, olcott wrote:
>>> On 6/20/2023 3:46 PM, Richard Damon wrote:
>>>> On 6/20/23 4:38 PM, olcott wrote:
>>>>> 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?
>>>>>
>>>>
>>>> Where did I say that 1 is the wrong answer to THAT question.
>>>>
>>> What happens when H returns 1 to D?
>>>
>>
>> But it doesn't, so it doesn't matter.
> No H can possibly be defined that can be embedded within
> Linz Ĥ such that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to Ĥ.qy or Ĥ.qn
> consistently with the behavior of Ĥ applied to ⟨Ĥ⟩.

Right, which is why it is impossible to make a correct Halt Decider.

> 
> The reason for this is that Ĥ does the opposite of both
> Ĥ.qy and Ĥ.qn. This makes the input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H
> self-contradictory for embedded_H.

Not SELF contradicotory, but just contradictory.

> 
> You will not be able to explain why embedded_H cannot do
> this for any reason other than the fact that the input
> ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H is self-contradictory for embedded_H.

No, embedded H just doesn't have code to give the right answer.
> 
> (a) Because it just can't dodges the question.
> (b) Because the input is undecidable for H is equivalent to (a)
> 

"Just Can't" is a totally correct answer, when you look at an exhaustive 
list of options that it can do, and none of them work.

You just can't right an algorithm that always WINS at Tic-Tac-Toe

Note, "Undecidable" isn't defined for a particular machine, but for a 
PROBLEM.

That answer of D(D) is very decidable (as long as H gives an answer or 
is provable to not halt) so the answer for this machine is decidable.

It just is a fact that for ANY decider you chose, you can build a machie 
by the ^ template that it will fail on.

Back to comp.theory | 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