Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connections
Warning: mysqli::query(): Couldn't fetch mysqli in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\index.php on line 66
Article <vbri9h$3g2ju$1@dont-email.me>
Deutsch   English   Français   Italiano  
<vbri9h$3g2ju$1@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!.POSTED!not-for-mail
From: Mikko <mikko.levanto@iki.fi>
Newsgroups: comp.theory
Subject: Re: Indirect Reference Changes the Behavior of DDD() relative to DDD emulated by HHH --- Deception
Date: Wed, 11 Sep 2024 10:53:21 +0300
Organization: -
Lines: 142
Message-ID: <vbri9h$3g2ju$1@dont-email.me>
References: <va104l$376ed$4@dont-email.me> <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> <b393150191c6d78fc3033efb7c2fb993914ab53e@i2pn2.org> <vb9kao$3r9la$1@dont-email.me> <vbbvoc$9s9s$1@dont-email.me> <vbccr8$bdtb$5@dont-email.me> <vbeifo$om7b$5@dont-email.me> <vbep6r$punj$3@dont-email.me> <vbh9c8$1aru4$1@dont-email.me> <vbhm9k$1c7u5$13@dont-email.me> <vbjqhu$1sj3i$1@dont-email.me> <vbkai8$1u1js$6@dont-email.me> <vbkd8b$1v535$1@dont-email.me> <vbndvu$2g6vo$5@dont-email.me> <vbp23h$2skjj$1@dont-email.me> <vbpjlc$2vfau$7@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 11 Sep 2024 09:53:22 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="1b12f7c7333227c0655464d8aa448511";
	logging-data="3672702"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/0cEBplOIiZSz8KuLgZCnd"
User-Agent: Unison/2.2
Cancel-Lock: sha1:PWLZLISu8vAONMhHt59r1PLrp90=
Bytes: 7729

On 2024-09-10 14:04:28 +0000, olcott said:

> On 9/10/2024 4:04 AM, Mikko wrote:
>> On 2024-09-09 18:15:26 +0000, olcott said:
>> 
>>> On 9/8/2024 9:44 AM, Mikko wrote:
>>>> On 2024-09-08 13:58:32 +0000, olcott said:
>>>> 
>>>>> On 9/8/2024 4:25 AM, Mikko wrote:
>>>>>> On 2024-09-07 14:00:19 +0000, olcott said:
>>>>>> 
>>>>>>> On 9/7/2024 5:19 AM, Fred. Zwarts wrote:
>>>>>>>> Op 06.sep.2024 om 13:31 schreef olcott:
>>>>>>>>> On 9/6/2024 4:36 AM, Fred. Zwarts wrote:
>>>>>>>>>> Op 05.sep.2024 om 15:48 schreef olcott:
>>>>>>>>>>> 
>>>>>>>>>>> HHH MUST ABORT AFTER SOME FIXED NUMBER OF RECURSIVE EMULATIONS
>>>>>>>>>>> AND THE OUTERMOST HHH ALWAYS SEE ONE MORE THAN THE NEXT INNER ONE.
>>>>>>>>>> 
>>>>>>>>>> And the outer one, when aborting after two cycles , misses the 
>>>>>>>>>> behaviour of the inner one in the next cycle, where the inner one would 
>>>>>>>>>> see the 'special condition', abort, return to DDD, which would halt as 
>>>>>>>>>> well.
>>>>>>>>>> That HHH misses the last part of the behaviour of the program, does not 
>>>>>>>>>> change the fact that this is the behaviour that was coded in the program
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> If we have an infinite chain of people each waiting for
>>>>>>>>>>> the next one down the line to do something then that thing
>>>>>>>>>>> is never done.
>>>>>>>>>> 
>>>>>>>>>> The infinite chain exists only in your dream. In fact there are only 
>>>>>>>>>> two recursions, so never more that a chain of three HHH in the 
>>>>>>>>>> simulation.
>>>>>>>>>> HHH is incorrect in assuming the there is an infinite chain, but this 
>>>>>>>>>> incorrect assumption makes that it aborts and halts. This applies both 
>>>>>>>>>> to the simulating and the simulated HHH.
>>>>>>>>> 
>>>>>>>>> The way it is encoded now there are only two recursions.
>>>>>>>>> 
>>>>>>>>> If we encode it as you suggest the outermost directly
>>>>>>>>> executed HHH would wait for the first emulated HHH which
>>>>>>>>> would wait for the second which would wait for third
>>>>>>>>> on and on...
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> What is olcott's problem with English?
>>>>>>>> If one way is incorrect, he thinks that it suggests that another way 
>>>>>>>> must be correct.
>>>>>>>> I never suggested to change HHH, because there is *no* correct way to 
>>>>>>>> do it. Every HHH that simulates itself is incorrect. No matter what 
>>>>>>>> clever code it includes.
>>>>>>> 
>>>>>>> You must be a brain dead moron.
>>>>>>> As long as HHH emulates the sequence of instructions
>>>>>>> it was provided then HHH is correct even if it catches
>>>>>>> your computer on fire.
>>>>>> 
>>>>>> That is right. The error only occurs when HHH no longer emulates the
>>>>>> sequence of instructions it was provided.
>>>>>> 
>>>>> 
>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>>      If simulating halt decider H correctly simulates its input D
>>>>>      until H correctly determines that its simulated D would never
>>>>>      stop running unless aborted then
>>>>> 
>>>>>      H can abort its simulation of D and correctly report that D
>>>>>      specifies a non-halting sequence of configurations.
>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>> 
>>>>> The above refers to determining that *its input D*
>>>>> "specifies a non-halting sequence of configurations"
>>>>> When people change this to a *non-input D* they are
>>>>> trying to get away with deception.
>>>> 
>>>> We know except the only "people" that do so is you.
>>>> 
>>> 
>>> _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]
>>> 
>>> Try to show all of the details of how DDD emulated
>>> by HHH ever reaches machine address  00002183
>> 
>> It is your emulator so you need to show what needs be shown.
> 
> I am not making the false claim.
> My claim in that 00002172, 00002173, 00002175, 0000217a
> are emulated by the first executed emulator HHH then
> HHH emulates itself emulating DDD and we get
> 00002172, 00002173, 00002175, 0000217a...
> 
> I proved this claim by showing the execution trace
> https://www.liarparadox.org/HHH(DDD).pdf
> 
> Disagreeing with verified facts seems to be a psychotic
> break from reality to me. It is up to you to show otherwise.
> 
>> For others it is sufficient to determine what HHH returns and
>> whether DDD halts and compare the two.
> 
> That is the fallacy of equivocation error.

No, it is exactly the thing they consider sufficient.

> The emulated HHH cannot possibly return and you
> are trying to get away with lying about it by
> changing to subject to a different HHH instance.

Id you ara afaraid of a change of the subject then you should not
change the subject.

>>> Sequences of machine addressed when DDD is emulated by HHH
>>> 00002172, 00002173, 00002175, 0000217a
>>> which calls an emulated HHH(DDD).
>>> 
>>> What are the next instructions of DDD emulated by the emulated HHH ?
>> 
>> Here, too, it is your problem to show what needs be shown.
>> For the rest of us it is sufficient to note what you have not proven.
> 
> When DDD calls HHH(DDD) do I need to say that DDD does not
> make a milkshake? DDD does not dance the jig?

Only if someone asks.

> Wouldn't someone that is not a liar say that when DDD calls
> HHH(DDD) that HHH(DDD) would be invoked?

I think someone that is not a liar has already said so.

-- 
Mikko