Forums before death by AOL, social media and spammers... "We can't have nice things"
|    sci.logic    |    Logic -- math, philosophy & computationa    |    262,912 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 261,928 of 262,912    |
|    Mikko to polcott    |
|    Re: on mathematical ghosts (2/3)    |
|    15 Dec 25 11:44:00    |
   
   [continued from previous message]   
      
   >>>>>>>   
   >>>>>>>>   
   >>>>>>>> if you believe the halting problem, then BB must have a limit L,   
   >>>>>>>> or else halting becomes generally solvable using the BB   
   >>>>>>>> function. see, if you can compute the BB number for any N-state   
   >>>>>>>> machines, then for any N-state machine u can just run the N-   
   >>>>>>>> state machine until BB number of steps. any machine that halts   
   >>>>>>>> on or before BB(N) steps halts, any that run past must be   
   >>>>>>>> nonhalting   
   >>>>>>>   
   >>>>>>> No, if we could establish an upper limit for BB(n) for all n,   
   >>>>>>> then we could solve the hatling problem, as we have an upper   
   >>>>>>> limit for the number of steps we need to simulate the machine.   
   >>>>>>>   
   >>>>>>> BB(n) has a value, but for sufficiently large values of n, we   
   >>>>>>> don't have an upper bound for BB(n).   
   >>>>>>>   
   >>>>>>>>   
   >>>>>>>> and the problem with allowing for partial decidability is that   
   >>>>>>>> BB can run continually run more and more deciders in parallel,   
   >>>>>>>> on every N- state machine, until one comes back with an halting   
   >>>>>>>> answer, for every N-state machine, which then it can the use to   
   >>>>>>>> decide what the BB number is for any N ...   
   >>>>>>>   
   >>>>>>> So, what BB are you running? Or are you misusing "running" to try   
   >>>>>>> to mean somehow trying to calculate?   
   >>>>>>>>   
   >>>>>>>> contradicting the concept it must have a limit L, where some L-   
   >>>>>>>> state machine cannot be decidable by *any* partial decider on   
   >>>>>>>> the matter,   
   >>>>>>>   
   >>>>>>> No, it can have a limit, just not a KNOWN limit.   
   >>>>>>   
   >>>>>> consensus is there can a known limit L to the BB function, and   
   >>>>>> proofs have been put out in regards to this   
   >>>>>>   
   >>>>>>>   
   >>>>>>>>   
   >>>>>>>> so no richard, partial decidability does not work if BB is to   
   >>>>>>>> have a limit   
   >>>>>>>>   
   >>>>>>>   
   >>>>>>> You only have the problem is BB has a KNOWN limit. Again, you   
   >>>>>>> trip up on assuming you can know any answer you want.   
   >>>>>>>   
   >>>>>>> That some things are not knowable breaks your logic.   
   >>>>>>   
   >>>>>   
   >>>>> I just glanced at your paper and skipped to the conclusion.   
   >>>>> Why do we care about the undecidability of the halting problem?   
   >>>>> Because undecidability in general (if it is correct) shows   
   >>>>> that truth itself is broken. Truth itself cannot be broken.   
   >>>>> This is the only reason why I have worked on these things   
   >>>>> for 28 years.   
   >>>>   
   >>>> because it makes us suck as developing and maintaining software, and   
   >>>> as a 35 year old burnt out SWE, i'm tired of living in a world   
   >>>> running off sucky software. it really is limiting our potential, and   
   >>>> i want my soon to be born son to have a far better experience with   
   >>>> this shit than i did.   
   >>>>   
   >>>> a consequence of accepting the halting problem is then necessarily   
   >>>> accepting proof against *all* semantic deciders, barring us from   
   >>>> agreeing on what such general deciders might be   
   >>>>   
   >>>   
   >>> Exactly: Tarski even "proved" that we can't even directly   
   >>> compute what is true. This lets dangerous liars get away   
   >>> with their dangerous lies.   
   >>>   
   >>>> this has lead to not only an unnecessary explosion in complexity of   
   >>>> software engineering, because we can't generally compute semantic   
   >>>> (turing) equivalence,   
   >>>>   
   >>>> but the general trend in deploying software that doesn't have   
   >>>> computed semantic proofs guaranteeing they actually do what we want   
   >>>> them to do.   
   >>>   
   >>> Yes without computing halting total proof of   
   >>> correctness is impossible.   
   >>>   
   >>>> "testing" is poor substitute for doing so, but that's the most we   
   >>>> can agree upon due to the current theory of computing.   
   >>>>   
   >>>> i think my ideas might contribute to dealing with incompleteness in   
   >>>> fundamental math more generally ... like producing more refined   
   >>>> limits to it's philosophical impact. tho idk if it can be gotten rid   
   >>>> of completely, anymore than we can get rid of the words "this   
   >>>> statement is false"   
   >>>>   
   >>>   
   >>> I don't think that there actually are any limits   
   >>> except for expressions requiring infinite proofs.   
   >>>   
   >>>> but i am currently focused on the theory of computing and not   
   >>>> anything more generally. the fundamental objects comprising the   
   >>>> theory of computing (machines) are far more constrained in their   
   >>>> definitions than what set theory needs to encompass, and within   
   >>>> those constraints i think i can twist the consensus into some   
   >>>> contradiction that are just entirely ignorant of atm   
   >>>>   
   >>>   
   >>> I have explored all of the key areas. None of them   
   >>> can be made as 100% perfectly concrete and unequivocal   
   >>> as computing.   
   >>>   
   >>>> that's the slam dunk left that i need. i have a means to rectify   
   >>>> whatever contradiction we find thru the use of RTMs, but i'm still   
   >>>> teasing out the contradiction that will *force* others to notice   
   >>>>   
   >>>   
   >>> I do have my refutation of the halting problem itself   
   >>> boiled down to a rough draft of two first principles.   
   >>>   
   >>> When the halting problem requires a halt decider   
   >>> to report on the behavior of a Turing machine this   
   >>> is always a category error because Turing machines   
   >>> only take finite string inputs.   
   >>>   
   >>> The corrected halting problem requires a Turing   
   >>> machine decider to report in the behavior that its   
   >>> actual finite string input actually specifies.   
   >>>   
   >>>   
   >>   
   >> polcott, i'm working on making the halting problem complete and   
   >> consistent in regards to a subset of the improved "reflective turing   
   >> machines" that encompasses all useful computations   
   >>   
   >> i'm sorry, but not about trying to reaffirm the halting function as   
   >> still uncomputable by calling it a category error   
   >   
   > I do compute the halting function correctly.   
   > I have been doing this for more than three years.   
   > We probably should not be spamming alt.buddha.short.fat.guy   
   >   
   > int sum(int x, int y){return x + y;}   
   > sum(3,2) should return 5 and it is incorrect   
   > to require sum(3,2) to return the sum of 5+6.   
      
   What   
    int sum(int x, int y){return x + y;}   
   should return either is specified somewhere or is not specified.   
   In the former case it should do as the document says, in the   
   latter case no return value is wrong.   
      
   However, C rules specify what that function must return. If the function   
   returns something other than 5 it violates C rules regardless what it   
   is required to return.   
      
   If the function is required to return 13 but it returns 5 then there   
   is a bug in the function.   
      
   --   
   Mikko   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca