| Deutsch English Français Italiano |
|
<4ce131a47cc0b59d10e1ef4f3a652cbf049b3e34@i2pn2.org> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.eternal-september.org!i2pn.org!i2pn2.org!.POSTED!not-for-mail From: joes <noreply@example.org> Newsgroups: comp.theory Subject: Re: HHH(DD) --- COMPUTE ACTUAL MAPPING FROM INPUT TO OUTPUT --- Using Finite String Transformations Date: Wed, 23 Apr 2025 11:22:02 -0000 (UTC) Organization: i2pn2 (i2pn.org) Message-ID: <4ce131a47cc0b59d10e1ef4f3a652cbf049b3e34@i2pn2.org> References: <vsnchj$23nrb$2@dont-email.me> <vto4vh$23i07$1@dont-email.me> <vto7qu$267in$1@dont-email.me> <k%RLP.1232047$Xb1.539402@fx05.ams4> <vtorpb$2uac$1@news.muc.de> <vtp32o$2vb5o$1@dont-email.me> <vtqpt5$17ns$1@news.muc.de> <vtrhbc$16pbv$2@dont-email.me> <vtrk7l$t44$1@news.muc.de> <vtrmfa$1be3n$1@dont-email.me> <vtvkgo$vjvi$1@dont-email.me> <vu2042$34l74$1@dont-email.me> <vu519u$1s5f9$1@dont-email.me> <vu6aha$2vn05$3@dont-email.me> <vu6dk4$2fq2$1@news.muc.de> <vu6knm$394oo$1@dont-email.me> <vu8cgm$2p5e$1@news.muc.de> <vu8gml$v0qa$2@dont-email.me> <vu8m2h$vn9b$2@dont-email.me> <vu8pr1$13jl5$8@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Wed, 23 Apr 2025 11:22:02 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="1531528"; mail-complaints-to="usenet@i2pn2.org"; posting-account="nS1KMHaUuWOnF/ukOJzx6Ssd8y16q9UPs1GZ+I3D0CM"; User-Agent: Pan/0.145 (Duplicitous mercenary valetism; d7e168a git.gnome.org/pan2) X-Spam-Checker-Version: SpamAssassin 4.0.0 Bytes: 3480 Lines: 41 Am Tue, 22 Apr 2025 14:14:41 -0500 schrieb olcott: > On 4/22/2025 1:10 PM, Fred. Zwarts wrote: >> Op 22.apr.2025 om 18:38 schreef olcott: >>> On Turing Machines inputs <are> finite strings, and finite string >>> transformation rules <are> applied to these finite strings to derive >>> corresponding outputs. >> And it has been proven that no finite string transformations are >> possible that report the halting behaviour for all inputs that specify >> a correct program. > The directly executed DD and DD emulated by HHH according to the > semantics of the x86 language have had provably different set of state > changes for several years now. Where do they diverge? The directly executed DD also calls a HHH that tries to simulate itself. > HHH is only accountable for the behavior that its input actually > specifies and strictly NOT ALLOWED to report on anything else. HHH IS > NOT ALLOWED TO REPORT ON THE BEHAVIOR OF THE DIRECTLY EXECUTED DD. This > breaks the computable function requirement that OUTPUTS MUST CORRESPOND > TO INPUTS. On the contrary, it is required to report on the behaviour of the input when directly executed, otherwise a halt decider is of no interest. I cannot produce a faulty simulator and claim that its result is what counts. > Outputs are forced to correspond to inputs when finite string > transformation rules are applied to inputs to derive outputs. There are many behaviours you could compute from the description of DD, such as when run backwards or in a loop, and even other things like the number of instructions. >> There is no 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. >> Agreed? Agreed. Agreed? -- Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math: It is not guaranteed that n+1 exists for every n.