Deutsch   English   Français   Italiano  
<b393150191c6d78fc3033efb7c2fb993914ab53e@i2pn2.org>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: joes <noreply@example.org>
Newsgroups: comp.theory
Subject: Re: Indirect Reference Changes the Behavior of DDD() relative to DDD
 emulated by HHH
Date: Wed, 4 Sep 2024 08:19:18 -0000 (UTC)
Organization: i2pn2 (i2pn.org)
Message-ID: <b393150191c6d78fc3033efb7c2fb993914ab53e@i2pn2.org>
References: <va104l$376ed$4@dont-email.me> <va3lai$3nd5c$2@dont-email.me>
	<va46sd$3pr24$1@dont-email.me> <va4mle$3s0hu$1@dont-email.me>
	<5591ff08ed8f7b4bdf33813681e156b775efe0ec@i2pn2.org>
	<va63uu$2fo9$1@dont-email.me>
	<b0a86b6a1343ebb5f9112ae757768a7cbbc770b2@i2pn2.org>
	<va65r8$6ht7$1@dont-email.me>
	<da75188ffa7677bd2b6979c8fc6ba82119404306@i2pn2.org>
	<878qwn0wyz.fsf@bsb.me.uk>
	<efacnfsQdv-ErlT7nZ2dnZfqnPadnZ2d@brightview.co.uk>
	<87le0jzc8f.fsf_-_@bsb.me.uk> <vaj1kd$2kvg9$1@dont-email.me>
	<eca21d905b57bb0b98172c573890b5c8cda91da8@i2pn2.org>
	<vakisq$302rl$3@dont-email.me> <vamjse$3d6eb$1@dont-email.me>
	<van2ni$3f6c0$1@dont-email.me> <vap9r5$3t411$1@dont-email.me>
	<vapv4l$3vumk$4@dont-email.me> <vashj9$grso$1@dont-email.me>
	<vav3iq$10jsm$4@dont-email.me> <vavc3b$11uqn$2@dont-email.me>
	<vavcf8$129qh$1@dont-email.me> <vavdv4$11uqn$6@dont-email.me>
	<vavfjq$12m8t$3@dont-email.me> <vb1gqf$1f566$1@dont-email.me>
	<vb4fd0$2s0uc$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 4 Sep 2024 08:19:18 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="801060"; 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: 8650
Lines: 120

Am Mon, 02 Sep 2024 08:42:56 -0500 schrieb olcott:
> On 9/1/2024 5:48 AM, Fred. Zwarts wrote:
>> Op 31.aug.2024 om 18:15 schreef olcott:
>>> On 8/31/2024 10:47 AM, Fred. Zwarts wrote:
>>>> Op 31.aug.2024 om 17:22 schreef olcott:
>>>>> On 8/31/2024 10:15 AM, Fred. Zwarts wrote:
>>>>>> Op 31.aug.2024 om 14:50 schreef olcott:
>>>>>>> On 8/30/2024 8:31 AM, Mikko wrote:
>>>>>>>> On 2024-08-29 14:04:05 +0000, olcott said:
>>>>>>>>> On 8/29/2024 3:00 AM, Mikko wrote:
>>>>>>>>>> On 2024-08-28 11:46:58 +0000, olcott said:
>>>>>>>>>>> On 8/28/2024 2:33 AM, Mikko wrote:
>>>>>>>>>>>> On 2024-08-27 13:04:26 +0000, olcott said:
>>>>>>>>>>>>> On 8/27/2024 12:45 AM, joes wrote:
>>>>>>>>>>>>>> Am Mon, 26 Aug 2024 18:03:41 -0500 schrieb olcott:
>>>>>>>>>>>>>>> On 8/26/2024 7:42 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com>
>>>>>>>>>>>>>>>> writes:
>>>>>>>>>>>>>>>>> On 23/08/2024 22:07, Ben Bacarisse wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> We don't really know what context Sipser was given.  I
>>>>>>>>>>>>>>>>>> got in touch at the time so I do know he had enough
>>>>>>>>>>>>>>>>>> context to know that PO's ideas were "wacky" and that
>>>>>>>>>>>>>>>>>> had agreed to what he considered a "minor remark".
>>>>>>>>>>>>>>>>>> Since PO considers his words finely crafted and key to
>>>>>>>>>>>>>>>>>> his so-called work I think it's clear that Sipser did
>>>>>>>>>>>>>>>>>> not take the "minor remark" he agreed to to mean what
>>>>>>>>>>>>>>>>>> PO takes it to mean! My own take if that he (Sipser)
>>>>>>>>>>>>>>>>>> read it as a general remark about how to determine some
>>>>>>>>>>>>>>>>>> cases, i.e. that D names an input that H can partially
>>>>>>>>>>>>>>>>>> simulate to determine it's halting or otherwise.  We
>>>>>>>>>>>>>>>>>> all know or could construct some such cases.
>>>>>>>>>>>>>>>>> Exactly my reading.  It makes Sipser's agreement
>>>>>>>>>>>>>>>>> natural, because it is both correct [with sensible
>>>>>>>>>>>>>>>>> interpretation of terms], and moreover describes an
>>>>>>>>>>>>>>>>> obvious strategy that a partial decider might use that
>>>>>>>>>>>>>>>>> can decide halting for some specific cases.  No need for
>>>>>>>>>>>>>>>>> Sipser to be deceptive or misleading here, when the
>>>>>>>>>>>>>>>>> truth suffices. (In particular no need to employ
>>>>>>>>>>>>>>>>> "tricksy" vacuous truth get out clauses just to get PO
>>>>>>>>>>>>>>>>> off his back as some have suggested.)
>>>>>>>>>>>>>>>> Yes, and it fits with his thinking it a "trivial remark".
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That aside, it's such an odd way to present an argument:
>>>>>>>>>>>>>>>> "I managed to trick X into saying 'yes' to something
>>>>>>>>>>>>>>>> vague".  In any reasonable collegiate exchange you'd go
>>>>>>>>>>>>>>>> back and check: "So even when D is constructed from H, H
>>>>>>>>>>>>>>>> can return based on what /would/ happen if H did not stop
>>>>>>>>>>>>>>>> simulating so that H(D,D) == false is correct even though
>>>>>>>>>>>>>>>> D(D)
>>>>>>>>>>>>>>>> halts?".  Just imagine what Sipser would say to that!
>>>>>>>>>>>>>> Is this an accurate phrasing, pete?
>>>>>>>>>>>>> Deciders never compute the mapping of the computation that
>>>>>>>>>>>>> they themselves are contained within.
>>>>>>>>>>>> Why not? A decider always either accepts or rejects its
>>>>>>>>>>>> input.
>>>>>>>>>>> The computation that they themselves are contained within
>>>>>>>>>>> cannot possibly be an input.
>>>>>>>>>> What would prevent that if the input language permits
>>>>>>>>>> computations?
>>>>>>>>> When a TM takes its own machine description as input this is not
>>>>>>>>> always that same behavior as the direct execution of the
>>>>>>>>> machine. It is not the same because it is one level of indirect
>>>>>>>>> reference away.
>>>>>>>> Now you contradict what you said above. You said that deciders
>>>>>>>> never conpute the mapping of the computation they themselves are
>>>>>>>> contained within.
>>>>>>> Although deciders cannot possibly see their own behavior other
>>>>>>> people can see this behavior.
>>>>>>>
>>>>>>>> Now you are saying that they do in a way that might not be as
>>>>>>>> expected.
>>>>>>> If is a verified fact that DDD has different behavior before it is
>>>>>>> aborted in the same way that people are hungry before they eat.
>>>>>> No, the behaviour specified by the finite string does not change
>>>>>> when a simulator decides to do the simulation only halfway. It is
>>>>>> just an incorrect simulation.
>>>>>>
>>>>>>> than the behavior of DDD after it has been aborted, people are not
>>>>>>> hungry after they eat.
>>>>>> If two people are hungry and one of them eats, the other one is
>>>>>> still hungry and needs to eat. It is stupid to say that they are no
>>>>>> longer hungry because they have eaten.
>>>>>> Similarly the simulating HHH is not longer hungry, but the
>>>>>> simulated HHH still is hungry and has not yet eaten.

>>>>>>> The direct execution of DDD includes the behavior of the emulated
>>>>>>> DDD after it has been aborted.
>>>>>> And the simulator should also simulate until it sees the behaviour
>>>>>> of after the simulated HHH has aborted its simulator.
>>> People that are not as stupid can see that HHH cannot wait for itself
>>> to abort its own simulation.
>> And people (except the stupid ones) can see that, because HHH cannot
>> wait for itself,
> Because this would require it to wait forever,
> thus HHH knows that to meet its own requirement to halt it must abort
> its simulation.
And because HHH is simulating itself, the simulated HHH also aborts.

>> this means that HHH failed to simulate itself correctly
> As long as HHH emulates its input according to the semantics of the x86
> language HHH is correctly emulating this input even if this correct
> emulation causes the computer to catch on fire.
> AS I HAVE TOLD YOU FAR TOO MANY TIMES CORRECT EMULATION IS ENTIRELY
> DETERMINED BY THE SEMANTICS OF THE X86 LANGUAGE.
> When DDD calls HHH(DDD) then HHH must emulate itself emulating DDD. If
> this causes the emulated HHH to never return THEN THIS EMULATION IS
> STIPULATED TO BE CORRECT BY THE ONLY MEASURE OF CORRECT EMULATION, the
> semantics of the x86 language.
Useless stipulation.

>> up to the end. HHH cannot possibly simulate itself correctly up to the
>> end.
> HHH cannot possibly correctly simulate itself to the end because the x86
> code of DDD and HHH specify that HHH cannot simulate itself to the end.
> If HHH did simulate itself to the end then HHH WOULD BE WRONG.
No simulator can simulate itself.

-- 
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.