Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.ai.philosophy    |    Perhaps we should ask SkyNet about this    |    59,235 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 59,028 of 59,235    |
|    olcott to Richard Damon    |
|    Re: The Halting Problem asks for too muc    |
|    14 Jan 26 19:25:13    |
   
   XPost: comp.theory, sci.logic, sci.math   
   From: polcott333@gmail.com   
      
   On 1/12/2026 9:19 PM, Richard Damon wrote:   
   > On 1/12/26 9:29 AM, olcott wrote:   
   >> On 1/12/2026 4:44 AM, Mikko wrote:   
   >>> On 11/01/2026 16:18, olcott wrote:   
   >>>> On 1/11/2026 4:13 AM, Mikko wrote:   
   >>>>> On 10/01/2026 17:47, olcott wrote:   
   >>>>>> On 1/10/2026 2:23 AM, Mikko wrote:   
   >>>>>>> On 09/01/2026 17:52, olcott wrote:   
   >>>>>>>> On 1/9/2026 3:59 AM, Mikko wrote:   
   >>>>>>>>> On 08/01/2026 16:22, olcott wrote:   
   >>>>>>>>>> On 1/8/2026 4:22 AM, Mikko wrote:   
   >>>>>>>>>>> On 07/01/2026 13:54, olcott wrote:   
   >>>>>>>>>>>> On 1/7/2026 5:49 AM, Mikko wrote:   
   >>>>>>>>>>>>> On 07/01/2026 06:44, olcott wrote:   
   >>>>>>>>>>>>>> All deciders essentially: Transform finite string   
   >>>>>>>>>>>>>> inputs by finite string transformation rules into   
   >>>>>>>>>>>>>> {Accept, Reject} values.   
   >>>>>>>>>>>>>>   
   >>>>>>>>>>>>>> The counter-example input to requires more than   
   >>>>>>>>>>>>>> can be derived from finite string transformation   
   >>>>>>>>>>>>>> rules applied to this specific input thus the   
   >>>>>>>>>>>>>> Halting Problem requires too much.   
   >>>>>>>>>>>>   
   >>>>>>>>>>>>> In a sense the halting problem asks too much: the problem   
   >>>>>>>>>>>>> is proven to   
   >>>>>>>>>>>>> be unsolvable. In another sense it asks too little: usually   
   >>>>>>>>>>>>> we want to   
   >>>>>>>>>>>>> know whether a method halts on every input, not just one.   
   >>>>>>>>>>>>>   
   >>>>>>>>>>>>> Although the halting problem is unsolvable, there are   
   >>>>>>>>>>>>> partial solutions   
   >>>>>>>>>>>>> to the halting problem. In particular, every counter-   
   >>>>>>>>>>>>> example to the   
   >>>>>>>>>>>>> full solution is correctly solved by some partial deciders.   
   >>>>>>>>>>>>   
   >>>>>>>>>>>> *if undecidability is correct then truth itself is broken*   
   >>>>>>>>>>>   
   >>>>>>>>>>> Depends on whether the word "truth" is interpeted in the   
   >>>>>>>>>>> standard   
   >>>>>>>>>>> sense or in Olcott's sense.   
   >>>>>>>>>>   
   >>>>>>>>>> Undecidability is misconception. Self-contradictory   
   >>>>>>>>>> expressions are correctly rejected as semantically   
   >>>>>>>>>> incoherent thus form no undecidability or incompleteness.   
   >>>>>>>>>   
   >>>>>>>>> The misconception is yours. No expression in the language of   
   >>>>>>>>> the first   
   >>>>>>>>> order group theory is self-contradictory. But the first order   
   >>>>>>>>> goupr   
   >>>>>>>>> theory is incomplete: it is impossible to prove that AB = BA is   
   >>>>>>>>> true   
   >>>>>>>>> for every A and every B but it is also impossible to prove that   
   >>>>>>>>> AB = BA   
   >>>>>>>>> is false for some A and some B.   
   >>>>>>>>>   
   >>>>>>>>   
   >>>>>>>> All deciders essentially: Transform finite string   
   >>>>>>>> inputs by finite string transformation rules into   
   >>>>>>>> {Accept, Reject} values.   
   >>>>>>>>   
   >>>>>>>> When a required result cannot be derived by applying   
   >>>>>>>> finite string transformation rules to actual finite   
   >>>>>>>> string inputs, then the required result exceeds the   
   >>>>>>>> scope of computation and must be rejected as an   
   >>>>>>>> incorrect requirement.   
   >>>>>>>   
   >>>>>>> No, that does not follow. If a required result cannot be derived by   
   >>>>>>> appying a finite string transformation then the it it is   
   >>>>>>> uncomputable.   
   >>>>>>   
   >>>>>> Right. Outside the scope of computation. Requiring anything   
   >>>>>> outside the scope of computation is an incorrect requirement.   
   >>>>>   
   >>>>> You can't determine whether the required result is computable before   
   >>>>> you have the requirement.   
   >>>>   
   >>>> *Computation and Undecidability*   
   >>>> https://philpapers.org/go.pl?aid=OLCCAU   
   >>>>   
   >>>> We know that there does not exist any finite   
   >>>> string transformations that H can apply to its   
   >>>> input P to derive the halt status of any P   
   >>>> that does the opposite of whatever H returns.   
   >>>   
   >>> Which only nmakes sense when the requirement that H must determine   
   >>> whether the computation presented by its input halts has already   
   >>> been presented.   
   >>>   
   >>>> *ChatGPT explains how and why I am correct*   
   >>>>   
   >>>> *Reinterpretation of undecidability*   
   >>>> The example of P and H demonstrates that what is   
   >>>> often called “undecidable” is better understood as   
   >>>> ill-posed with respect to computable semantics.   
   >>>> When the specification is constrained to properties   
   >>>> detectable via finite simulation and finite pattern   
   >>>> recognition, computation proceeds normally and   
   >>>> correctly. Undecidability only appears when the   
   >>>> specification overreaches that boundary.   
   >>>   
   >>> It tries to explain but it does not prove.   
   >>>   
   >>   
   >> Its the same thing that I have been saying for years.   
   >> It is not that a universal halt decider cannot exist.   
   >>   
   >> It is that an input that does the opposite of whatever   
   >> value the halt decider returns is non-well-founded   
   >> within proof-theoretic semantics.   
   >>   
   >   
   > But the problem is that Computation is not a proof-theoretic semantic   
   > system, and thus those rules don't apply.   
   >   
      
   The dumbed down version is that the halting problem asks   
   a question outside of the scope of finite string transformations.   
      
   The halting problem proof does not fail because finite computation   
   is too weak. It fails because it asks finite computation to   
   decide a judgment that is not finitely grounded under operational   
   semantics.   
      
   By operational semantics I mean the standard proof‑theoretic   
   account of program meaning, where execution judgments are   
   given by inference rules and termination corresponds to the   
   existence of a finite derivation.   
      
   By proof‑theoretic semantics I mean the approach in which the   
   meaning of a statement is determined by its rules of proof   
   rather than by truth conditions in an external model.   
   Operational semantics fits this pattern: programs have meaning   
   through their execution rules, not through abstract denotations.   
      
   By denotational semantics I mean any semantics that assigns   
   mathematical objects—functions, truth values, domains-to programs   
   independently of how they are executed or proved. This contrasts   
   with operational or proof‑theoretic semantics, where meaning is   
   grounded in the structure of derivations rather than in an abstract   
   mathematical object.   
      
   I use “denotational semantics” simply to refer to any framework   
   that assigns meanings independently of operational behavior.   
      
   --   
   Copyright 2026 Olcott
|
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca