XPost: comp.theory, sci.logic   
   From: polcott333@gmail.com   
      
   On 7/1/2025 4:17 AM, Fred. Zwarts wrote:   
   > Op 30.jun.2025 om 19:08 schreef olcott:   
   >> On 6/30/2025 2:40 AM, Fred. Zwarts wrote:   
   >>> Op 29.jun.2025 om 15:46 schreef olcott:   
   >>>> On 6/29/2025 5:38 AM, Fred. Zwarts wrote:   
   >>>>> Op 28.jun.2025 om 15:02 schreef olcott:   
   >>>>>> On 6/28/2025 3:50 AM, Fred. Zwarts wrote:   
   >>>>>>> Op 28.jun.2025 om 01:30 schreef olcott:   
   >>>>>>>> On 6/26/2025 4:16 AM, Fred. Zwarts wrote:   
   >>>>>>>>> Op 25.jun.2025 om 16:09 schreef olcott:   
   >>>>>>>>>> On 6/25/2025 2:59 AM, Fred. Zwarts wrote:   
   >>>>>>>>>>> Op 24.jun.2025 om 16:06 schreef olcott:   
   >>>>>>>>>>   
   >>>>>>>>>> None of the code in HHH can possibly cause DDD correctly   
   >>>>>>>>>> simulated by HHH to reach its own simulated "return" statement.   
   >>>>>>>>>   
   >>>>>>>>> Yes, exactly, that is the bug.   
   >>>>>>>>>   
   >>>>>>>>   
   >>>>>>>> Recursive emulation is only a tiny bit more complicated   
   >>>>>>>> than recursion yet no one here seems to have a clue.   
   >>>>>>>> Do you know what recursion is?   
   >>>>>>>> (If you don't that would explain a lot)   
   >>>>>>> As usual irrelevant claims without evidence. No rebuttal.   
   >>>>>>   
   >>>>>> Ah so you don't know what recursion is.   
   >>>>>   
   >>>>> As usual a false claim without evidence.   
   >>>>>   
   >>>>>>   
   >>>>>>> HHH has a bug that makes that it does not recognise the halting   
   >>>>>>> behaviour of the program specified in the input.   
   >>>>>>   
   >>>>>> If you don't even know what recursion is then   
   >>>>>> you are totally unqualified to review these things.   
   >>>>>   
   >>>>> And since the condition in the 'if' fails, the conclusion is not true.   
   >>>>>   
   >>>>>>   
   >>>>>>> Even a beginner can see that the input is a pointer to code,   
   >>>>>>> including the code to abort and halt. But HHH is programmed to   
   >>>>>>> ignore the conditional branch instructions, when simulating   
   >>>>>>> itself, so it thinks that there is an infinite loop when there   
   >>>>>>> are only a finite number of recursions.   
   >>>>>>> But Olcott does not understand that not all recursions are infinite.   
   >>>>>>   
   >>>>>> When the measure is whether or not DDD correctly   
   >>>>>> simulated by HHH can possibly reach its own "return"   
   >>>>>> instruction final halt state nothing inside HHH can   
   >>>>>> possibly have any effect on this.   
   >>>>>>   
   >>>>>> That you don't know this proves that you are unqualified   
   >>>>>> to review my work.   
   >>>>> The failure of HHH is an incorrect measure for the halting   
   >>>>> behaviour specified in the input.   
   >>>>> That you do not understand this explains your invalid claims.   
   >>>>> The halting behaviour of the input can be analysed by several other   
   >>>>> methods and they show that HHH is incorrect in its analysis.   
   >>>>>   
   >>>>>   
   >>>>   
   >>>> No Turing machine can ever report on the behavior of   
   >>>> any directly executing Turing Machine because no TM   
   >>>> can ever take another directly executing Turing Machine   
   >>>> as its input.   
   >>> There is no need to report about another Turing Machine.   
   >>   
   >> The conventional halting problem proof incorrectly requires this.   
   >>   
   >   
   >   
   > As usual repeated claims without evidence.   
   >   
   >> void DDD()   
   >> {   
   >>    HHH(DDD);   
   >>    return;   
   >> }   
   >>   
   >> int main()   
   >> {   
   >>    HHH(DDD);   
   >>    DDD();   
   >> }   
   >>   
   >> When the input to HHH(DDD) is correctly simulated   
   >> by HHH then HHH correctly rejects this input as   
   >> specifying non-halting behavior.   
   >   
   > No, it *incorrectly* does that. The input is DDD calling an aborting   
   > HHH, so the input specifies a halting program.   
   >   
      
   DDD correctly simulated by HHH cannot possibly   
   reach its own "return" instruction final halt state   
   that DOES NOT HALT TO MATTER WHAT THE F YOU CALL IT.   
      
   >>   
   >> The directly executed DDD() halts yet is not and cannot   
   >> be an input to HHH, thus it outside of the domain of HHH.   
   >   
   > Irrelevant. It is only relevant that the input specifies a halting program.   
   >   
   >>   
   >>>  It only needs to report about its input. In this case the input   
   >>> includes the abort code and in this way specifies a halting program.   
   >>   
   >> You keep getting confused about the program under test here.   
   >> If HHH was the program under test the the internals of HHH   
   >> would be relevant.   
   >   
   > You keep confused by combining the program under test with the input.   
   > Not the program under test is under test, but the code of the program   
   > under test is part of the input. The whole input is under test. This   
   > code cannot be replaced by other hypothetical code with different   
   > behaviour.   
   >   
   >>   
   >> Since DDD is the program under test and HHH remains a pure   
   >> simulator of DDD until HHH correctly determines that DDD   
   >> correctly simulated by HHH cannot possibly reach its own   
   >> simulated "return" statement final halt state, the internals   
   >> of HHH cease to be relevant.   
   >>   
   > And this behaviour to abort and halt, is part of the code given as input   
   > to the simulator.   
   > That HHH has bugs to ignore that part of the code, does not change the   
   > fact that that part of the code is also under test, because it is used   
   > by DDD.   
      
      
   --   
   Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius   
   hits a target no one else can see." Arthur Schopenhauer   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)