XPost: comp.theory   
   From: polcott333@gmail.com   
      
   On 10/29/2025 12:21 PM, Kaz Kylheku wrote:   
   > On 2025-10-29, olcott  wrote:   
   >> On 10/29/2025 12:36 AM, Kaz Kylheku wrote:   
   >>> On 2025-10-29, olcott  wrote:   
   >>>> On 10/28/2025 9:19 PM, Kaz Kylheku wrote:   
   >>>>> On 2025-10-29, olcott  wrote:   
   >>>>>> On 10/28/2025 7:25 PM, Kaz Kylheku wrote:   
   >>>>>>> Under your system, I don't know whether Y is correct.   
   >>>>>>>   
   >>>>>>> Y could be a broken decider that is wrongly deciding D (and /that/   
   >>>>>>> is why its execution trace differs from X).   
   >>>>>>>   
   >>>>>>> Or it could be the case that D is a non-input to Y, in which case Y is   
   >>>>>>> deemed to be correct because D being a non-input to Y means that D   
   >>>>>>> denotes non-halting semantics to Y (and /that/ is why its execution   
   >>>>>>> trace differs from X).   
   >>>>>>>   
   >>>>>>> The fact that the execution trace differs doesn't inform.   
   >>>>>>>   
   >>>>>>> We need to know the value of is_input(Y, D): we need to /decide/   
   whether   
   >>>>>>> D is non-input or input to Y in order to /decide/ whether its rejection   
   >>>>>>> is correct.   
   >>>>>>>   
   >>>>>>   
   >>>>>> Whatever is a correct simulation of an input by   
   >>>>>> a decider is the behavior that must be reported on.   
   >>>>>   
   >>>>> But under your system, if I am a user of deciders, and have been   
   >>>>> given a decider H which is certified to be correct, I cannot   
   >>>>> rely on it to decide halting.   
   >>>>>   
   >>>>   
   >>>> When halting is defined correctly:   
   >>>> Does this input specify a sequence of moves that   
   >>>> reach a final halt state?   
   >>>>   
   >>>> and not defined incorrectly: to require something   
   >>>> that is not specified in the input then this does   
   >>>> overcome the halting problem proof and shows that   
   >>>> the halting problem itself has always been a category   
   >>>> error. (Flibble's brilliant term).   
   >>>>   
   >>>>> I want to know whether D halts, that's all.   
   >>>>>   
   >>>>> H says no. It is certified correct under your paradigm, so   
   >>>>> so I don't have to suspect that if it is given an /input/   
   >>>>> it will be wrong.   
   >>>>>   
   >>>>> But: I have no idea whether D is an input to H or a non-input!   
   >>>>>   
   >>>>   
   >>>> That is ridiculous. If it is an argument   
   >>>> to the decider function then it is an input.   
   >>>   
   >>> So how it's supposed to work that an otherwise halting D   
   >>> is a non-halting input to H.   
   >>>   
   >>   
   >> int D()   
   >> {   
   >>     int Halt_Status = H(D);   
   >>     if (Halt_Status)   
   >>       HERE: goto HERE;   
   >>     return Halt_Status;   
   >> }   
   >>   
   >> H simulates D   
   >> that calls H(D) to simulate D   
   >> that calls H(D) to simulate D   
   >> that calls H(D) to simulate D   
   >> that calls H(D) to simulate D   
   >> that calls H(D) to simulate D   
   >> until H sees this repeating pattern.   
   >>   
   >>> When the non-halting D is an input to H (which it undeniably as you have   
   >>> now decided) D is non-halting.   
   >>>   
   >>   
   >> D.input_to_H is non-halting is confirmed in that   
   >> D simulated by cannot possibly reach its own   
   >> "return" statement final halt state. This divides   
   >> non-halting from stopping running.   
   >>   
   >>> With respect to H, it's as if the halting D exists in another dimension;   
   >>> /that/ D is not the input.   
   >>>   
   >>> Okay, but anyway ...   
   >>>   
   >>> - The decider user has some program P..   
   >>>   
   >>> - P terminates, but it takes three years on the user's hardware.   
   >>>   
   >>> - The user does not know this; they tried running P for weeks,   
   >>>     months, but it never terminated.   
   >>>   
   >>> - The user has H which they have been assured is correct under   
   >>>     the Olcott Halting Paradigm.   
   >>>   
   >>> - The applies H to P, and H rejects it.   
   >>>   
   >>   
   >> The would mean that P has specifically targeted   
   >> H in an attempt to thwart a correct assessment.   
   >>   
   >>> - The program P is actually D, but the user doesn't know this.   
   >>>   
   >>   
   >> The system works on source-code.   
   >   
   > Whatever results you have, they have to be valid   
   > for any representation of Turing machines whatsoever.   
   >   
   > Source code can be obfuscated, as well as extremely large and   
   > obfuscated.   
   >   
      
   We are not taking about complexity we are talking about   
   computability.   
      
   > That the user can have source code (not required at all by the Turing   
   > model) doesn't change that the user has no idea that P is actually a D   
   > program with respect to their halting decider.   
   >   
      
   The source code is always required all the time because   
   Turing machines only operate on finite string machine   
   descriptions that are essentially source-code.   
      
   > Also, the question "is this input P a diagonal input targetin this   
   > decider H" is an undecidable problem!!!   
   >   
      
   That is circumvented by simulating halt deciders that   
   do what all deciders do and that is compute an accept   
   or reject value entirely on the basis of what its finite   
   string actually specifies.   
      
   >>> What should the user believe? Does D halt or not?   
   >>>   
   >>   
   >> When the input P targets the decider H or does not target   
   >> the decider H input P simulated by decider H always reports   
   >> on the basis of whether P can reach its own final halt state.   
   >   
   > But that's not the output we want; we want to know whether P()   
   > halts.   
   >   
      
   People can choose to break from reality.   
      
   >>> How is the user /not/ deceived if they believe that P doesn't halt?   
   >>>   
   >>>>> When H says 0, I have no idea whether it's being judged non-halting   
   >>>>> as an input, or whether it's being judged as a non-input (whereby   
   >>>>> either value is the correct answer as far as H is concerned).   
   >>>>>   
   >>>>   
   >>>> Judging by anything besides and input has always   
   >>>> been incorrect. H(D) maps its input to a reject   
   >>>> value on the basis of the behavior that this   
   >>>> argument to H specifies.   
   >>>   
   >>> But that behavior is only real /as/ an argument to H; it is not the   
   >>> behavior that the halter-decider customer wants reported on.   
   >>>   
   >>   
   >> When what the customer wants and what is in the scope of   
   >> Turing machines differ the user must face reality.   
   >   
   > So under your paradigm, the user is told they must face reality: some   
   > machines cannot be decided,   
      
   I never said that. You are not paying close enough   
   attention.   
      
   If the user wants the square root of a dead rabbit   
   they must be corrected that square roots only apply   
   to numbers.   
      
   If the user wants the halt status of a program they   
   must be corrected in that halt deciders only provide   
   the halt status of their finite string inputs.   
      
   > so you cannot get an answer for whether P()   
   > halts. Sometimes you get answer for whether P is considered to be   
   > halting when simulated by H, which doesn't match whether P() halts. Suck   
   > it up!   
   >   
      
   If it wasn't for the damned cheat of an input calling   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)