Deutsch English Français Italiano |
<vg7pab$bqa3$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Mikko <mikko.levanto@iki.fi> Newsgroups: comp.theory Subject: Re: The philosophy of computation reformulates existing ideas on a new basis --- Date: Sun, 3 Nov 2024 14:11:55 +0200 Organization: - Lines: 133 Message-ID: <vg7pab$bqa3$1@dont-email.me> References: <vfli1h$fj8s$1@dont-email.me> <vflue8$3nvp8$2@i2pn2.org> <vfmd8m$k2m7$1@dont-email.me> <bcd82d9f8a987d3884220c0df7b8f7204cb9de3e@i2pn2.org> <vfmueh$mqn9$1@dont-email.me> <ff039b922cabbb6d44f90aa71a52d8c2f446b6ab@i2pn2.org> <vfo95k$11qs1$1@dont-email.me> <vfp8c0$3tobi$2@i2pn2.org> <vfpbtq$1837o$2@dont-email.me> <vfq4h9$1fo1n$1@dont-email.me> <vfqrro$1jg6i$1@dont-email.me> <vfvnbk$2lj5i$1@dont-email.me> <vfvudo$2mcse$5@dont-email.me> <vg2c7p$379h1$1@dont-email.me> <vg2hei$37lpn$8@dont-email.me> <vg5030$3oo1p$1@dont-email.me> <vg56vn$3pnvp$2@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sun, 03 Nov 2024 13:11:56 +0100 (CET) Injection-Info: dont-email.me; posting-host="f2506e5f9c3d8310dc0ce37006e161f6"; logging-data="387395"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18hDJW5SYY1IMeeTTJxVlCZ" User-Agent: Unison/2.2 Cancel-Lock: sha1:AngEqlGZ5XsVt+A7nJ4Sw1qzPk8= Bytes: 7166 On 2024-11-02 12:46:47 +0000, olcott said: > On 11/2/2024 5:49 AM, Mikko wrote: >> On 2024-11-01 12:26:58 +0000, olcott said: >> >>> On 11/1/2024 5:58 AM, Mikko wrote: >>>> On 2024-10-31 12:50:00 +0000, olcott said: >>>> >>>>> On 10/31/2024 5:49 AM, Mikko wrote: >>>>>> On 2024-10-29 14:35:34 +0000, olcott said: >>>>>> >>>>>>> On 10/29/2024 2:57 AM, Mikko wrote: >>>>>>>> On 2024-10-29 00:57:30 +0000, olcott said: >>>>>>>> >>>>>>>>> On 10/28/2024 6:56 PM, Richard Damon wrote: >>>>>>>>>> On 10/28/24 11:04 AM, olcott wrote: >>>>>>>>>>> On 10/28/2024 6:16 AM, Richard Damon wrote: >>>>>>>>>>>> The machine being used to compute the Halting Function has taken a >>>>>>>>>>>> finite string description, the Halting Function itself always took a >>>>>>>>>>>> Turing Machine, >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> That is incorrect. It has always been the finite string Turing Machine >>>>>>>>>>> description of a Turing machine is the input to the halt decider. >>>>>>>>>>> There are always been a distinction between the abstraction and the >>>>>>>>>>> encoding. >>>>>>>>>> >>>>>>>>>> Nope, read the problem you have quoted in the past. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Ultimately I trust Linz the most on this: >>>>>>>>> >>>>>>>>> the problem is: given the description of a Turing machine >>>>>>>>> M and an input w, does M, when started in the initial >>>>>>>>> configuration qow, perform a computation that eventually halts? >>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf >>>>>>>>> >>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>> >>>>>>>>> Linz also makes sure to ignore that the behavior of ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>>>>>> correctly simulated by embedded_H cannot possibly reach >>>>>>>>> either ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩ because like everyone else he rejects >>>>>>>>> simulation out of hand: >>>>>>>>> >>>>>>>>> We cannot find the answer by simulating the action of M on w, >>>>>>>>> say by performing it on a universal Turing machine, because >>>>>>>>> there is no limit on the length of the computation. >>>>>>>> >>>>>>>> That statement does not fully reject simulation but is correct in >>>>>>>> the observation that non-halting cannot be determied in finite time >>>>>>>> by a complete simulation so someting else is needed instead of or >>>>>>>> in addition to a partial simulation. Linz does include simulationg >>>>>>>> Turing machines in his proof that no Turing machine is a halt decider. >>>>>>> >>>>>>> *That people fail to agree with this and also fail to* >>>>>>> *correctly point out any error seems to indicate dishonestly* >>>>>>> *or lack of technical competence* >>>>>>> >>>>>>> DDD emulated by HHH according to the semantics of the x86 >>>>>>> language cannot possibly reach its own "return" instruction >>>>>>> whether or not any HHH ever aborts its emulation of DDD. >>>>>> >>>>>> - irrelevant >>>>> >>>>> 100% perfectly relevant within the philosophy of computation >>>> >>>> Probably but not to anything quoted above. >>>> >>>>> *THE TITLE OF THIS THREAD* >>>>> [The philosophy of computation reformulates existing ideas on a new basis ---] >>>>> >>>>>> - couterfactual >>>> >>>>> You can baselessly claim that verified facts are counter-factual >>>>> you cannot show this. >>>> >>>> Your statement was about a situation where "people fail to agree with >>>> this and also fail to correctly point out any error". But that situation >>>> has not happened as people have identified your errors (perhaps not all >>>> but at least sufficiently many). >>>> >>> >>> Inconsistent with the currently received view is >>> certainly not the slightest trace of any error when >>> examined within the philosophy of computation. >> >>> It has always seemed quite ridiculous to me that everyone >>> here consistently construes the currently received view >>> as inherently infallible. >> >> The currently received view that if you are asked "What is 5 + 6?" >> then only an answer that tells what 5 + 6 is is correct is infallible. > > This is simple enough that people cannot be confused. > That 5 + 6 == 11 does seem infallibly true. So even you can make the ridiculous mistake to regard the currently received view as infallible? >>> They call me stupid and ignorant for not accepting the currently >>> received view as inherently infallible. >> >> You are stupid if you regard your own view as infallible. If you >> regard something that has been tested and found good as infallible >> then the risk of error can be small enough. > > I have known that equating believable with true is an error > a great consequence ever since I was 14. > > It seems clear that halt deciders must compute the mapping > from their input finite strings to the actual behavior > specified by these finite strings. It is not clear at all unless you specify how those finite strings specify the actual behaviour. It is not pspecified in the usual formulation of the problem. Also note that the behaviour exists before those strings so "describe" should be and usually is used instead of "specify". The use of latter may give the false impression that the behaviour is determined by those strings. > It is true that when we construe the halting criteria as > requiring taking into account how a pathological relationship > changes the behavior of the input instead of simply ignoring > this behavior change that pathological inputs become decidable > as non-halting. It is true that doing that means leaving the halting proble unsolved. -- Mikko