| Deutsch English Français Italiano |
|
<vs0hfi$1ckla$9@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: "Fred. Zwarts" <F.Zwarts@HetNet.nl> Newsgroups: comp.theory,comp.lang.c++ Subject: Re: Correcting the definition of the halting problem --- Computable functions Date: Wed, 26 Mar 2025 10:30:26 +0100 Organization: A noiseless patient Spider Lines: 78 Message-ID: <vs0hfi$1ckla$9@dont-email.me> References: <vr1shq$1qopn$1@dont-email.me> <vr9qu8$m4cu$2@dont-email.me> <vr9ttl$q57o$1@dont-email.me> <vr9u5m$q57o$2@dont-email.me> <vrbckn$23f4t$1@dont-email.me> <vrbtiq$2j07c$2@dont-email.me> <vrc3ud$2p461$1@dont-email.me> <vrc4nu$2m36k$5@dont-email.me> <vrkc2m$24ft6$1@dont-email.me> <vrkdij$25f9f$3@dont-email.me> <vrlt36$3haib$1@dont-email.me> <vrn237$im1e$1@dont-email.me> <vrn67b$md49$1@dont-email.me> <cb974817db8e02049daa5604d725300154e33ad1@i2pn2.org> <vrps14$35a4m$2@dont-email.me> <eab11e8806c669d296bff986870bdc6abdbb2fef@i2pn2.org> <vrqicu$3s258$1@dont-email.me> <30c2beae6c191f2502e93972a69c85ff227bfd03@i2pn2.org> <vrrs79$11a56$7@dont-email.me> <vrrsta$tdm5$1@dont-email.me> <vrs264$1a43i$1@dont-email.me> <vrs54q$1d1o2$1@dont-email.me> <vrse90$1jr8u$1@dont-email.me> <vrsk13$1q39o$1@dont-email.me> <vrsn62$1rblu$2@dont-email.me> <vrsnhu$1q39o$2@dont-email.me> <vrsodl$1rblu$3@dont-email.me> <vrtsee$2uea1$3@dont-email.me> <vru640$38ob9$2@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Wed, 26 Mar 2025 10:30:27 +0100 (CET) Injection-Info: dont-email.me; posting-host="f6a5cf00636726f8011e12af665f7e80"; logging-data="1462954"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX189e+3RGxL5kw2tyioLp3jY" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:yapClfVP3txKbEHNaMhN6L+fkMg= Content-Language: nl, en-GB In-Reply-To: <vru640$38ob9$2@dont-email.me> Bytes: 5102 Op 25.mrt.2025 om 13:04 schreef olcott: > On 3/25/2025 4:19 AM, Fred. Zwarts wrote: >> Op 25.mrt.2025 om 00:04 schreef olcott: >>> On 3/24/2025 5:49 PM, André G. Isaak wrote: >>>> On 2025-03-24 16:43, olcott wrote: >>>> >>>>>> Computable functions don't have inputs. They have domains. Turing >>>>>> machines have inputs.p >>>>>> >>>>> >>>>> Maybe when pure math objects. In every model of >>>>> computation they seem to always have inputs. >>>>> https://en.wikipedia.org/wiki/Computable_function >>>> >>>> Computable functions *are* pure math objects. You seem to want to >>>> conflate them with C functions, but that is not the case. >>>> >>>> The crucial point is that the domains of computable functions are >>>> *not* restricted to strings, even if the inputs to Turing Machines are. >>>> >>>>>> While the inputs to TMs are restricted to strings, there is no >>>>>> such such restriction on computable functions. >>>>> >>>>>> The vast majority of computable functions of interest do *not* >>>>>> have strings as their domains, yet they remain computable >>>>>> functions (a simple example would be the parity function which >>>>>> maps NATURAL NUMBERS (not strings) to yes/no values.) >>>>>> >>>>> >>>>> Since there is a bijection between natural numbers >>>>> and strings of decimal digits your qualification >>>>> seems vacuous. >>>> >>>> There is not a bijection between natural numbers and strings. There >>>> is a one-to-many mapping from natural numbers to strings, just as >>>> there is a one-to-many mapping from computations (i.e. turing >>>> machine/input string pairs, i.e. actual Turing machines directly >>>> running on their inputs) to strings. >>>> >>>> André >>>> >>>> >>> >>> _III() >>> [00002172] 55 push ebp ; housekeeping >>> [00002173] 8bec mov ebp,esp ; housekeeping >>> [00002175] 6872210000 push 00002172 ; push III >>> [0000217a] e853f4ffff call 000015d2 ; call EEE(III) >>> [0000217f] 83c404 add esp,+04 >>> [00002182] 5d pop ebp >>> [00002183] c3 ret >>> Size in bytes:(0018) [00002183] >>> >>> When III is emulated by pure emulator EEE for any finite >>> number of steps of emulation according to the semantics >>> of the x86 language it never reaches its own "ret" >>> instruction final halt state >> >> If fails to complete the simulation of a program that halts > > It is stupid to ignore the pathological relationship > that III defines with EEE. > That relation is irrelevant, it fails to reach the end of the simulation anyhow. It is not very interesting to know whether a simulator reports that it is unable to reach the end of the simulation of a program that halts in direct execution. It is interesting to know: 'Is there an algorithm that can determine for all possible inputs whether the input specifies a program that (according to the semantics of the machine language) halts when directly executed?' This question seems undecidable for Olcott.