Deutsch   English   Français   Italiano  
<vsdj0k$3o5fg$3@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
Subject: Re: DDD specifies recursive emulation to HHH and halting to HHH1
Date: Mon, 31 Mar 2025 10:16:20 +0200
Organization: A noiseless patient Spider
Lines: 176
Message-ID: <vsdj0k$3o5fg$3@dont-email.me>
References: <vrfuob$256og$1@dont-email.me> <vs6t10$2p360$6@dont-email.me>
 <vs70tc$39556$21@dont-email.me> <vs71bq$2p360$10@dont-email.me>
 <vs76m9$3m3q0$1@dont-email.me> <vs77th$2p360$11@dont-email.me>
 <vs78cu$3ms9k$1@dont-email.me>
 <c2b91231b9052e07b6705250938fb9095e711327@i2pn2.org>
 <vs7kvf$3eal$2@dont-email.me>
 <aeb75b411e9f77c974585181c671a47d03b22078@i2pn2.org>
 <vs7qdm$8dae$2@dont-email.me> <vs7r9b$8ajp$1@dont-email.me>
 <vs92l3$1fccq$5@dont-email.me> <vs93ae$1k9u2$1@dont-email.me>
 <vs9g5p$1v2n9$5@dont-email.me> <vs9gcg$20g2j$3@dont-email.me>
 <vs9h9o$23cav$2@dont-email.me> <vs9hh3$20g2j$6@dont-email.me>
 <vs9jie$23cav$4@dont-email.me> <vs9kb1$26cg5$2@dont-email.me>
 <vs9pni$27rl4$9@dont-email.me> <vs9r1b$28tqg$2@dont-email.me>
 <vs9t45$2f6n5$1@dont-email.me>
 <9f2ff3ab9b99a7bb6dfa0885f9757f810ce52e66@i2pn2.org>
 <vsaam4$2sfhq$1@dont-email.me> <vsbi7e$1hblk$1@dont-email.me>
 <vsc6qi$27lbo$2@dont-email.me>
 <8a3e7e93e6cad20b29d23405a0e6dbd497a492ac@i2pn2.org>
 <vscegq$2fv3s$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 31 Mar 2025 10:16:20 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b0973023f03c3251ee94fa08a88289ea";
	logging-data="3937776"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/8GvR4t8UcMqDTNy5Oxz1w"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:MjcSwxaF98F4hGTXeWlIIAlbnsk=
In-Reply-To: <vscegq$2fv3s$2@dont-email.me>
Content-Language: nl, en-GB
Bytes: 8989

Op 30.mrt.2025 om 23:53 schreef olcott:
> On 3/30/2025 4:01 PM, Richard Damon wrote:
>> On 3/30/25 3:42 PM, olcott wrote:
>>> On 3/30/2025 8:50 AM, Fred. Zwarts wrote:
>>>> Op 30.mrt.2025 om 04:35 schreef olcott:
>>>>> On 3/29/2025 8:12 PM, Richard Damon wrote:
>>>>>> On 3/29/25 6:44 PM, olcott wrote:
>>>>>>> On 3/29/2025 5:08 PM, dbush wrote:
>>>>>>>> On 3/29/2025 5:46 PM, olcott wrote:
>>>>>>>>> On 3/29/2025 3:14 PM, dbush wrote:
>>>>>>>>>> On 3/29/2025 4:01 PM, olcott wrote:
>>>>>>>>>>> On 3/29/2025 2:26 PM, dbush wrote:
>>>>>>>>>>>> On 3/29/2025 3:22 PM, olcott wrote:
>>>>>>>>>>>>> On 3/29/2025 2:06 PM, dbush wrote:
>>>>>>>>>>>>>> On 3/29/2025 3:03 PM, olcott wrote:
>>>>>>>>>>>>>>> On 3/29/2025 10:23 AM, dbush wrote:
>>>>>>>>>>>>>>>> On 3/29/2025 11:12 AM, olcott wrote:
>>>>>>>>>>>>>>>>> On 3/28/2025 11:00 PM, dbush wrote:
>>>>>>>>>>>>>>>>>> On 3/28/2025 11:45 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It defines that it must compute the mapping from
>>>>>>>>>>>>>>>>>>> the direct execution of a Turing Machine
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Which does not require tracing an actual running TM, 
>>>>>>>>>>>>>>>>>> only mapping properties of the TM described. 
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The key fact that you continue to dishonestly ignore
>>>>>>>>>>>>>>>>> is the concrete counter-example that I provided that
>>>>>>>>>>>>>>>>> conclusively proves that the finite string of machine
>>>>>>>>>>>>>>>>> code input is not always a valid proxy for the behavior
>>>>>>>>>>>>>>>>> of the underlying virtual machine.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In other words, you deny the concept of a UTM, which can 
>>>>>>>>>>>>>>>> take a description of any Turing machine and exactly 
>>>>>>>>>>>>>>>> reproduce the behavior of the direct execution.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I deny that a pathological relationship between a UTM and
>>>>>>>>>>>>>>> its input can be correctly ignored.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In such a case, the UTM will not halt, and neither will 
>>>>>>>>>>>>>> the input when executed directly.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is not impossible to adapt a UTM such that it
>>>>>>>>>>>>> correctly simulates a finite number of steps of an
>>>>>>>>>>>>> input.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 1) then you no longer have a UTM, so statements about a UTM 
>>>>>>>>>>>> don't apply
>>>>>>>>>>>
>>>>>>>>>>> We can know that when this adapted UTM simulates a
>>>>>>>>>>> finite number of steps of its input that this finite
>>>>>>>>>>> number of steps were simulated correctly.
>>>>>>>>>>
>>>>>>>>>> And therefore does not do a correct UTM simulation that 
>>>>>>>>>> matches the behavior of the direct execution as it is incomplete.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It is dishonest to expect non-terminating inputs to complete.
>>>>>>>>
>>>>>>>> An input that halts when executed directly is not non-terminating
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> 2) changing the input is not allowed
>>>>>>>>>>>
>>>>>>>>>>> The input is unchanged. There never was any
>>>>>>>>>>> indication that the input was in any way changed.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> False, if the starting function calls UTM and UTM changes, 
>>>>>>>>>> you're changing the input.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> When UTM1 is a UTM that has been adapted to only simulate
>>>>>>>>> a finite number of steps 
>>>>>>>>
>>>>>>>> And is therefore no longer a UTM that does a correct and 
>>>>>>>> complete simulation
>>>>>>>>
>>>>>>>>> and input D calls UTM1 then the
>>>>>>>>> behavior of D simulated by UTM1 
>>>>>>>>
>>>>>>>>
>>>>>>>> Is not what I asked about.  I asked about the behavior of D when 
>>>>>>>> executed directly.
>>>>>>>>
>>>>>>>
>>>>>>> Off topic for this thread.
>>>>>>> UTM1 D DOES NOT HALT
>>>>>>> UTM2 D HALTS
>>>>>>> D is the same finite string in both cases.
>>>>>>>
>>>>>>
>>>>>> No it isn't, not if it is the definition of a PROGRAM.
>>>>>>
>>>>>
>>>>> _DDD()
>>>>> [00002172] 55         push ebp      ; housekeeping
>>>>> [00002173] 8bec       mov  ebp,esp  ; housekeeping
>>>>> [00002175] 6872210000 push 00002172 ; push DDD
>>>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
>>>>> [0000217f] 83c404     add  esp,+04
>>>>> [00002182] 5d         pop  ebp
>>>>> [00002183] c3         ret
>>>>> Size in bytes:(0018) [00002183]
>>>>>
>>>>> The behavior that these machine code bytes specify:
>>>>> 558bec6872210000e853f4ffff83c4045dc3
>>>>> as an input to HHH is different than these
>>>>> same bytes as input to HHH1 as a verified fact.
>>>>>
>>>>>> Or, are you admitting you don't understand the meaning of a program?
>>>>>>
>>>>>
>>>>> It seems that you "just don't believe in" verified facts.
>>>>>
>>>> That completely depends on who has verified it.
>>>
>>> No it does not. That is a stupid thing to say.
>>> Every verified fact IS TRUE BY DEFINITION.
>>
>> No, if the verifiers lies, then his "verification" isn't valid.
>>
> 
> That is not the way semantic tautology works.
> If the father of lies says that cats are animals
> then cats are still animals.
> 
>> Or, do you accept the verification by the election deniers that show 
>> that there was the possibility of the fraud,
>>
> 
> There is a possibility that five minutes ago never existed.
> Claiming that there was fraud when you know there was no
> evidence of fraud might get you eternally incinerated.
> 
>> A guess you have to or you are admitting yourself to be a hypocrite.
>>
>>>
>>>> If everyone can see that the way in which Olcott verifies his 
>>>> 'facts' is only a baseless claim, I do not believe in the 
>>>> verification. In particular when he does not fix the errors in the 
>>>> verification that were pointed out to him.
>>>
>>> My claims are verified as true entirely on the basis
>>> of the  meaning of their words.
>>>
>>
>> Nope, it is proved incorrect by the ACTUAL meaning of the words you 
>> use, but then you LIE to yourself about what those words mean.
> 
>  >
> 
> _DDD()
> [00002172] 55         push ebp      ; housekeeping
> [00002173] 8bec       mov  ebp,esp  ; housekeeping
> [00002175] 6872210000 push 00002172 ; push DDD
> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
> [0000217f] 83c404     add  esp,+04
========== REMAINDER OF ARTICLE TRUNCATED ==========