Groups | Search | Server Info | Login | Register
Groups > comp.software-eng > #3815
| From | dart200 <user7160@newsgrouper.org.invalid> |
|---|---|
| Newsgroups | comp.theory, comp.ai.philosophy, comp.software-eng |
| Subject | Re: is the ct-thesis cooked? |
| Date | 2026-01-12 20:21 -0800 |
| Organization | A noiseless patient Spider |
| Message-ID | <10k4h87$2s63u$1@dont-email.me> (permalink) |
| References | (5 earlier) <10jkcoo$9u4l$1@dont-email.me> <10jkiea$b3m5$4@dont-email.me> <yt59R.1403595$u2q8.729303@fx11.iad> <10k3re3$2krfs$1@dont-email.me> <AOi9R.203777$Zqk9.36159@fx08.iad> |
Cross-posted to 3 groups.
On 1/12/26 7:16 PM, Richard Damon wrote: > On 1/12/26 5:09 PM, dart200 wrote: >> On 1/12/26 4:06 AM, Richard Damon wrote: >>> On 1/6/26 10:03 PM, dart200 wrote: >>>> On 1/6/26 5:26 PM, olcott wrote: >>>>> On 1/6/2026 1:47 AM, dart200 wrote: >>>>>> On 1/5/26 4:24 PM, Oleksiy Gapotchenko wrote: >>>>>>> Just an external observation: >>>>>>> >>>>>>> A lot of tech innovations in software optimization area get >>>>>>> discarded from the very beginning because people who work on them >>>>>>> perceive the halting problem as a dogma. As result, certain >>>>>>> practical things (in code analysis) are not even tried because >>>>>>> it's assumed that they are bound by the halting problem. >>>>>>> >>>>>>> In practice, however, the halting problem is rarely a limitation. >>>>>>> And even when one hits it, they can safely discard a particular >>>>>>> analysis branch by marking it as inconclusive. >>>>>>> >>>>>>> Halting problem for sure can be better framed to not sound as a >>>>>>> dogma, at least. In practice, algorithmic inconclusiveness has >>>>>>> 0.001 probability, not a 100% guarantee as many engineers >>>>>>> perceive it. >>>>>> >>>>>> god it's been such a mind-fuck to unpack the halting problem, >>>>>> >>>>>> but the halting problem does not mean that no algorithm exists for >>>>>> any given machine, just that a "general" decider does not exist >>>>>> for all machiens ... >>>>>> >>>>>> heck it must be certain that for any given machine there must >>>>>> exist a partial decider that can decide on it ... because >>>>>> otherwise a paradox would have to address all possible partial >>>>>> deciders in a computable fashion and that runs up against it's own >>>>>> limit to classical computing. therefore some true decider must >>>>>> exist for any given machine that exists ... we just can't funnel >>>>>> the knowledge thru a general interface. >>>>>> >>>>> >>>>> For every H there is a D such that D does the opposite >>>>> of whatever H reports. In this case use H1 on this D. >>>> >>>> yes, the inability to correctly resolve halting thru a singular >>>> interface is a flaw of TM computing, not an inherent algorithmic limit >>>> >>> >>> Nope, because the proof doesn't actually need to talk about HOW the >>> decider actually made its decision, and thus not limited to Turing >>> Machines. >>> >>> All it needs is that the decider be limited by the rules of a >>> computation. >>> >>> All the arguements against the proof seem to begin with the error >>> that the decider can be changed after the fact and such change >>> changes the input to match, but that breaks the fundamental property >>> of computations, that they are fixed algorithms >>> >>> The proof shows that the SPECIFIC decider that the input was made >>> from will get the wrong answer, and we can make such an input for ANY >>> specific decider, and thus no decider can get all answers correct. >>> >>> That the input HAS a correct answer (just the opposite of what that >>> specific decider gives) shows that there IS a correct answer, so >>> there is nothing wrong about the question of its halting, and thus a >>> non- answer like "its behavior is contrary" is valid. >>> >>> Everyone trying to make the arguements just shows they don't >>> understand the basics of what a computation is. >> >> missed ya dick! >> >> given that deciders are inherently part of the execution path they are >> deciding on ... ofc deciders can modify their behavior based on an >> input which they are included within, like they can modify their >> behavior based on the properties of the input. > > No, that behavior had to always have been in them, and thus seen by the > "pathological" input. > >> >> this is how partial deciders can intelligently block on responding to >> input that cannot be answered thru their particular interface. >> >> i'm not aware of any method that can prove a partial decider can't be >> more efficient that brute force, because again, they can block when >> encountering a paradox specific to their interface. > > How does "brute force" determine non-halting? well it does for the halting computations (bounded time, bounded space), and proper infinite loops (unbounded time, bounded space), just not runaway infinite computation (unbounded time, unbounded space) > > And nothing in the theory disagrees with partial halt deciders existing, > they just can NEVER give an answer to the pathological program based on > them, as if they give an answer, it will be wrong. which means: for any given machine, there is a decider out there that must decide correctly on it. so, for any given machine there is a method that does correctly decide on it without ever given any wrong answers to any other machine (tho it may not give answers at times). as a man, i'm not subject to having my output read and contradicted like turing machine deciders are. i'm not subject to having to block indefinitely because some input is pathological to me. and because some method must exist that can correct decide on any given input... i can know that method for any given input, and therefor i can decide on any given input. this is why i'm really starting to think the ct-thesis is cooked. you say i can't do that because turing machines can't do that ... but where's the proof that turing machine encompass all of computing? why am i limited by the absolute nonsense that is turing machines producing pathological input to themselves? because turing machines *are* the fundamentals of computation??? but again: that's just an assumption. we never proved it, yet here you are treating it like unquestionable law. that's the flaw bro, one we've been sitting on for almost a century. i don't even have a proof to deconstruct, it's literally just an assumption, so all i need to do is construct the scenarios where something is obviously generally computable, but that computation cannot be generally expressed thru a turing machine computation input/ouput specification. > >> >> furthermore this doesn't disprove a general algorithm backing the >> partial deciders, all the general algorithm needs is a "self" input >> which identifies the particular interface it's computing for. this >> general algo for partial deciders will have three outputs: HALTS, >> LOOPS, and PARADOX. when partial deciders receive PARADOX back from >> their algo run they will then just loop forever to never respond. > > Sure it does. > > The problem is it doesn't get a "self" input, and by its nature. it i'm defining the algo, so i say it does > can't determine if the input is just using a computational equivalent of > itself that doesn't match its idea of what it looks like. > > This FACT just breaks you concept, as you just assume you can detect > what is proven to be undetectable in full generality. using the very paradox i'm trying to solve, so that's begging the question. it's really kinda sad how much begging the question is going on in the fundamental theory of computing > > And, even if it CAN detect that the input is using a copy of itself, > that doesn't help it as it still can't get the right answer, and the it's general algo to the partial deciders - all it needs to do is either it returns PARADOX in which case the partial decider decides to loop(), or maybe we can just extract that functionality into the general partial algo itself... > pathological input based on your general algorithm effectively uses > copies of all the algorithms it enumerates, so NONE of them can give the > right answer. > >> >> yes i'm aware "interfaces" are complete descriptions of a partial >> decider, and that's what i mean by passing in a self. the partial >> decider must have a quine that allows it to recognize itself, and it >> passes this into the general algo. > > Nope, an "Interface" is NOT a complete description of ANY machine, so > you are just showing you are fundamentally incorrect in your basis. > > You can't "run" and "interface", only an actual program that implements it. sure, but all the partial decider do is construct a self-reference using a quine and pass that along with the input to a common backing algorithm. all valid partial deciders will need accurate quines in order to ascertain where their output feedbacks into affect the prediction they are making. and yes the partial deciders do contain full descriptions of the common backing algo, but they still really do just act as an interface to that common algo they act like an exposed API/interface into the common algo > >> >> "but i can loop over all partial deciders to produce a paradox" ... >> uhh no you can't? traditional computing cannot iterate over all >> functionally equivalent machines, so it certainly can't iterate over >> all almost functionally equivalent machines, so you cannot claim to >> produce a general paradox for the general algo as such a computation >> is outside the scope of classical computing limits. > > So, you just admitting you can't use an emumerated list of partial > deciders to get the answer. which is fine, it's just not necessary > > The pathological program doesn't need to enumerate the deciders, it just > needs to user what you make your final decider, which can only partially > enumerate the partial deciders. it would in order to break the general algo across all self's. the self acts as the fixed point of reference to which the decision is made ... and while no fixed point can decide on all input, for any given input there is a fixed point of self that can decide on that input. and this can be encapsulated into a general algorithm that encapsulated a general procedure even if any given fixed point of self is not general. therefore a general algo exists, even if any particular fixed point of decision making is contradicted. dear god, why is computing theory is such a shit show? cause we've been almost blindly following what the forefathers of computing said? > >> >> i await to see how you purposefully misunderstand this >> > > It seems you are the one that doesn't understand. > > Programs can't CHANGE there behavior, they HAVE specific behavior that > depends on the input, and ALWAYS have that behavior for that input. > > The definition of a computation means it can't squirrel away the fact > that it was once used on this particular input, and needs to do > something different, which is what is needed to CHANGE their behavior. i'm aware, i'm not really sure why ur reapting that and i await ur further purposeful misunderstanding -- arising us out of the computing dark ages, please excuse my pseudo-pyscript, ~ nick
Back to comp.software-eng | Previous | Next — Previous in thread | Next in thread | Find similar
Re: Proof that the halting problem itself is a category error polcott <polcott333@gmail.com> - 2025-12-10 17:03 -0600
Re: Proof that the halting problem itself is a category error wij <wyniijj5@gmail.com> - 2025-12-11 07:10 +0800
Re: Proof that the halting problem itself is a category error --- typo polcott <polcott333@gmail.com> - 2025-12-10 17:53 -0600
Re: Proof that the halting problem itself is a category error Oleksiy Gapotchenko <alex.s.gap@gmail.com> - 2026-01-06 01:24 +0100
Re: Proof that the halting problem itself is a category error olcott <polcott333@gmail.com> - 2026-01-05 18:39 -0600
is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-05 23:47 -0800
Re: is the ct-thesis cooked? olcott <polcott333@gmail.com> - 2026-01-06 19:26 -0600
Re: is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-06 19:03 -0800
Re: is the ct-thesis cooked? olcott <polcott333@gmail.com> - 2026-01-06 22:33 -0600
Re: is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-07 00:56 -0800
yes/no questions lacking a correct yes/no answer are incorrect questions olcott <polcott333@gmail.com> - 2026-01-07 05:50 -0600
Re: is the ct-thesis cooked? Richard Damon <Richard@Damon-Family.org> - 2026-01-12 07:12 -0500
Re: is the ct-thesis cooked? Richard Damon <Richard@Damon-Family.org> - 2026-01-12 07:06 -0500
Re: is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-12 14:09 -0800
Re: is the ct-thesis cooked? Richard Damon <Richard@Damon-Family.org> - 2026-01-12 22:16 -0500
Re: is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-12 20:21 -0800
Re: is the ct-thesis cooked? Richard Damon <Richard@Damon-Family.org> - 2026-01-13 07:09 -0500
Re: is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-13 12:33 -0800
Re: is the ct-thesis cooked? Richard Damon <Richard@Damon-Family.org> - 2026-01-14 22:43 -0500
Re: is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-15 04:23 -0800
Re: is the ct-thesis cooked? Richard Damon <Richard@Damon-Family.org> - 2026-01-15 22:28 -0500
Re: is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-16 01:08 -0800
Re: is the ct-thesis cooked? Richard Damon <Richard@Damon-Family.org> - 2026-01-16 11:46 -0500
Re: is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-16 14:21 -0800
The essence of all Computation generically defined olcott <polcott333@gmail.com> - 2026-01-16 16:58 -0600
Re: The essence of all Computation generically defined Richard Damon <Richard@Damon-Family.org> - 2026-01-16 18:21 -0500
Re: is the ct-thesis cooked? Richard Damon <Richard@Damon-Family.org> - 2026-01-16 18:21 -0500
Re: is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-16 16:43 -0800
Re: is the ct-thesis cooked? Richard Damon <Richard@Damon-Family.org> - 2026-01-16 22:24 -0500
Re: is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-16 23:23 -0800
Re: is the ct-thesis cooked? Richard Damon <Richard@Damon-Family.org> - 2026-01-17 07:33 -0500
Re: is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-17 19:14 -0800
Re: is the ct-thesis cooked? Richard Damon <Richard@Damon-Family.org> - 2026-01-17 22:28 -0500
Re: is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-17 22:05 -0800
Re: is the ct-thesis cooked? Richard Damon <Richard@Damon-Family.org> - 2026-01-18 07:05 -0500
Re: is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-18 10:15 -0800
Re: is the ct-thesis cooked? Richard Damon <Richard@Damon-Family.org> - 2026-01-18 15:56 -0500
Re: is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-18 13:50 -0800
Re: is the ct-thesis cooked? Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-01-18 22:27 +0000
Re: is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-18 15:01 -0800
Re: is the ct-thesis cooked? Richard Damon <Richard@Damon-Family.org> - 2026-01-18 19:28 -0500
Re: is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-18 20:30 -0800
Re: is the ct-thesis cooked? Richard Damon <Richard@Damon-Family.org> - 2026-01-20 00:29 -0500
Re: is the ct-thesis cooked? Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-01-18 22:28 +0000
Re: is the ct-thesis cooked? Richard Damon <Richard@Damon-Family.org> - 2026-01-18 19:28 -0500
Re: is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-18 20:51 -0800
Re: is the ct-thesis cooked? Richard Damon <Richard@Damon-Family.org> - 2026-01-20 00:29 -0500
Re: is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-19 22:18 -0800
Re: is the ct-thesis cooked? Richard Damon <Richard@Damon-Family.org> - 2026-01-20 07:59 -0500
Re: is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-20 17:55 -0800
Re: is the ct-thesis cooked? Richard Damon <Richard@Damon-Family.org> - 2026-01-24 09:44 -0500
Re: is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-24 14:36 -0800
Re: is the ct-thesis cooked? Richard Damon <Richard@Damon-Family.org> - 2026-01-24 19:52 -0500
Re: is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-24 18:24 -0800
Re: is the ct-thesis cooked? Richard Damon <Richard@Damon-Family.org> - 2026-01-25 13:21 -0500
Re: is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-25 13:05 -0800
Re: is the ct-thesis cooked? Richard Damon <Richard@Damon-Family.org> - 2026-01-25 17:36 -0500
Re: is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-25 21:56 -0800
Re: is the ct-thesis cooked? Richard Damon <Richard@Damon-Family.org> - 2026-01-26 11:39 -0500
Re: is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-26 11:43 -0800
Re: is the ct-thesis cooked? Richard Damon <Richard@Damon-Family.org> - 2026-01-26 17:17 -0500
Re: is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-26 14:29 -0800
Re: is the ct-thesis cooked? Dude <punditster@gmail.com> - 2026-01-27 13:31 -0800
Re: is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-28 01:12 -0800
Re: is the ct-thesis cooked? Dude <punditster@gmail.com> - 2026-01-28 13:29 -0800
Re: is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-28 13:37 -0800
Re: is the ct-thesis cooked? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-01-27 14:07 -0800
Re: is the ct-thesis cooked? Richard Damon <news.x.richarddamon@xoxy.net> - 2026-01-28 07:23 -0500
Re: is the ct-thesis cooked? Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-01-17 12:17 +0000
Re: is the ct-thesis cooked? Richard Damon <Richard@Damon-Family.org> - 2026-01-17 08:15 -0500
Re: is the ct-thesis cooked? dart200 <user7160@newsgrouper.org.invalid> - 2026-01-17 09:47 -0800
Re: is the ct-thesis cooked? Richard Damon <Richard@Damon-Family.org> - 2026-01-17 15:31 -0500
The essence of all Computation generically defined olcott <polcott333@gmail.com> - 2026-01-16 18:35 -0600
Re: is the ct-thesis cooked? Mikko <mikko.levanto@iki.fi> - 2026-01-07 14:05 +0200
Exactly what are deciders in the theory of computation? olcott <polcott333@gmail.com> - 2026-01-07 15:29 -0600
Re: is the ct-thesis cooked? PLO olcott <polcott333@gmail.com> - 2026-01-24 17:06 -0600
Re: is the ct-thesis cooked? PLO Richard Damon <Richard@Damon-Family.org> - 2026-01-24 19:52 -0500
Re: is the ct-thesis cooked? PLO dart200 <user7160@newsgrouper.org.invalid> - 2026-01-24 18:05 -0800
Re: is the ct-thesis cooked? PLO Richard Damon <Richard@Damon-Family.org> - 2026-01-25 13:23 -0500
Re: is the ct-thesis cooked? PLO dart200 <user7160@newsgrouper.org.invalid> - 2026-01-25 13:04 -0800
Re: is the ct-thesis cooked? PLO Richard Damon <Richard@Damon-Family.org> - 2026-01-25 17:40 -0500
Re: is the ct-thesis cooked? PLO dart200 <user7160@newsgrouper.org.invalid> - 2026-01-25 22:50 -0800
Re: is the ct-thesis cooked? PLO dart200 <user7160@newsgrouper.org.invalid> - 2026-01-26 01:35 -0800
Re: is the ct-thesis cooked? PLO Richard Damon <Richard@Damon-Family.org> - 2026-01-26 11:43 -0500
Re: is the ct-thesis cooked? PLO dart200 <user7160@newsgrouper.org.invalid> - 2026-01-26 11:45 -0800
Re: is the ct-thesis cooked? PLO Richard Damon <Richard@Damon-Family.org> - 2026-01-26 17:28 -0500
Re: is the ct-thesis cooked? PLO dart200 <user7160@newsgrouper.org.invalid> - 2026-01-27 00:00 -0800
Re: is the ct-thesis cooked? PLO olcott <polcott333@gmail.com> - 2026-01-24 20:35 -0600
Re: is the ct-thesis cooked? PLO dart200 <user7160@newsgrouper.org.invalid> - 2026-01-24 18:38 -0800
Re: is the ct-thesis cooked? PLO olcott <polcott333@gmail.com> - 2026-01-24 20:53 -0600
Re: is the ct-thesis cooked? PLO dart200 <user7160@newsgrouper.org.invalid> - 2026-01-24 19:12 -0800
Re: is the ct-thesis cooked? PLO olcott <polcott333@gmail.com> - 2026-01-24 21:42 -0600
Re: is the ct-thesis cooked? PLO dart200 <user7160@newsgrouper.org.invalid> - 2026-01-24 20:03 -0800
Re: is the ct-thesis cooked? PLO olcott <polcott333@gmail.com> - 2026-01-24 22:06 -0600
Re: is the ct-thesis cooked? PLO dart200 <user7160@newsgrouper.org.invalid> - 2026-01-24 21:45 -0800
Re: Proof that the halting problem itself is a category error Mikko <mikko.levanto@iki.fi> - 2026-01-06 15:23 +0200
Boiling Gödel's 1931 Incompleteness proof down to its barest essence olcott <polcott333@gmail.com> - 2026-01-06 08:02 -0600
Re: Boiling Gödel's 1931 Incompleteness proof down to its barest essence Mikko <mikko.levanto@iki.fi> - 2026-01-07 14:10 +0200
Re: Boiling Gödel's 1931 Incompleteness proof down to its barest essence olcott <polcott333@gmail.com> - 2026-01-07 07:06 -0600
Re: Boiling Gödel's 1931 Incompleteness proof down to its barest essence Mikko <mikko.levanto@iki.fi> - 2026-01-08 12:21 +0200
Re: Boiling Gödel's 1931 Incompleteness proof down to its barest essence olcott <polcott333@gmail.com> - 2026-01-08 08:18 -0600
Re: Boiling Gödel's 1931 Incompleteness proof down to its barest essence Mikko <mikko.levanto@iki.fi> - 2026-01-10 11:25 +0200
Re: Boiling Gödel's 1931 Incompleteness proof down to its barest essence olcott <polcott333@gmail.com> - 2026-01-11 08:32 -0600
Re: Boiling Gödel's 1931 Incompleteness proof down to its barest essence Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-01-11 16:16 +0000
Re: Boiling Gödel's 1931 Incompleteness proof down to its barest essence olcott <NoOne@NoWhere.com> - 2026-01-11 21:00 -0600
Re: Boiling Gödel's 1931 Incompleteness proof down to its barest essence Mikko <mikko.levanto@iki.fi> - 2026-01-12 13:05 +0200
csiph-web