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

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

Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: A state transition diagram proves ... GOOD PROGRESS
Date: Sat, 19 Oct 2024 17:46:05 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <e9116181bf0b583b25fb7bdf7e2f17fb06a810c8@i2pn2.org>
References: <ves6p1$2uoln$1@dont-email.me>
 <3232d8a0cc7b5d4bba46321bf682c94573bf1b7c@i2pn2.org>
 <vesemu$2v7sh$1@dont-email.me>
 <a9fb95eb0ed914d0d9775448c005111eb43f2c5b@i2pn2.org>
 <veslpf$34ogr$1@dont-email.me>
 <647fe917c6bc0cfc78083ccf927fe280acdf2f9d@i2pn2.org>
 <vetq7u$3b8r2$1@dont-email.me>
 <d8006439ae02f55ba148e6be1f8c4787905a999f@i2pn2.org>
 <veu30q$3cqfo$1@dont-email.me>
 <19353b51a56711156d467a25959b94b51976802e@i2pn2.org>
 <vev0ic$3hnjq$2@dont-email.me>
 <907fa87f8679d5085795db6186840a0e892b57bb@i2pn2.org>
 <vev986$3me0u$3@dont-email.me>
 <bbd63df65b0063e5db90e806c032b8aa694a45d2@i2pn2.org>
 <vf0592$3rr97$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 19 Oct 2024 21:46:05 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2793727"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <vf0592$3rr97$3@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 7932
Lines: 148

On 10/19/24 7:30 AM, olcott wrote:
> On 10/19/2024 6:21 AM, Richard Damon wrote:
>> On 10/18/24 11:32 PM, olcott wrote:
>>> On 10/18/2024 9:49 PM, Richard Damon wrote:
>>>> On 10/18/24 9:04 PM, olcott wrote:
>>>>> On 10/18/2024 6:19 PM, Richard Damon wrote:
>>>>>> On 10/18/24 12:39 PM, olcott wrote:
>>>>>>> On 10/18/2024 9:41 AM, joes wrote:
>>>>>>>> Am Fri, 18 Oct 2024 09:10:04 -0500 schrieb olcott:
>>>>>>>>> On 10/18/2024 6:17 AM, Richard Damon wrote:
>>>>>>>>>> On 10/17/24 11:47 PM, olcott wrote:
>>>>>>>>>>> On 10/17/2024 10:27 PM, Richard Damon wrote:
>>>>>>>>>>>> On 10/17/24 9:47 PM, olcott wrote:
>>>>>>>>>>>>> On 10/17/2024 8:13 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 10/17/24 7:31 PM, olcott wrote:
>>>>>>>>
>>>>>>>>>>>>>>> When DDD is correctly emulated by HHH according to the 
>>>>>>>>>>>>>>> semantics
>>>>>>>>>>>>>>> of the x86 language DDD cannot possibly reach its own 
>>>>>>>>>>>>>>> machine
>>>>>>>>>>>>>>> address [00002183] no matter what HHH does.
>>>>>>>>>>>>>>> +-->[00002172]-->[00002173]-->[00002175]-->[0000217a]--+
>>>>>>>>
>>>>>>>>>>>>>> Except that 0000217a doesn't go to 00002172, but to 000015d2
>>>>>>>>
>>>>>>>>>> The Emulating HHH sees those addresses at its begining and 
>>>>>>>>>> then never
>>>>>>>>>> again.
>>>>>>>>>> Then the HHH that it is emulating will see those addresses, 
>>>>>>>>>> but not the
>>>>>>>>>> outer one that is doing that emulation of HHH.
>>>>>>>>>> And so on.
>>>>>>>>>> Which HHH do you think EVER gets back to 00002172?
>>>>>>>>>> What instruction do you think that it emulates that would tell 
>>>>>>>>>> it to do
>>>>>>>>>> so?
>>>>>>>>
>>>>>>>>>> At best the trace is:
>>>>>>>>>> 00002172 00002173 00002175 0000217a conditional emulation of 
>>>>>>>>>> 00002172
>>>>>>>>>> conditional emulation of 00002173 conditional emulation of 
>>>>>>>>>> 00002175
>>>>>>>>>> conditional emulation of 0000217a CE of CE of 00002172 ...
>>>>>>>>> OK great this is finally good progress.
>>>>>>>> The more interesting part is HHH simulating itself, specifically 
>>>>>>>> the
>>>>>>>> if(Root) check on line 502.
>>>>>>>>
>>>>>>>
>>>>>>> That has nothing to do with any aspect of the emulation
>>>>>>> until HHH has correctly emulated itself emulating DDD.
>>>>>>>
>>>>>>>>>> and if HHH decides to abort its emulation, it also should know 
>>>>>>>>>> that
>>>>>>>>>> every level of condition emulation it say will also do the 
>>>>>>>>>> same thing,
>>>>>>>>> If I understand his words correctly Mike has already disagreed 
>>>>>>>>> with
>>>>>>>>> this.
>>>>>>>> He hasn't.
>>>>>>>>
>>>>>>>>> Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk>
>>>>>>>>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>>>>>>>>>   > Obviously a simulator has access to the internal state 
>>>>>>>>> (tape contents
>>>>>>>>>   > etc.) of the simulated machine. No problem there.
>>>>>>>>> This seems to indicate that the Turing machine UTM version of 
>>>>>>>>> HHH can
>>>>>>>>> somehow see each of the state transitions of the DDD resulting 
>>>>>>>>> from
>>>>>>>>> emulating its own Turing machine description emulating DDD.
>>>>>>>
>>>>>>>> Of course. It needs to, in order to simulate it. Strictly speaking
>>>>>>>> it has no idea of its simulation of a simulation two levels down,
>>>>>>>> only of the immediate simulation; the rest is just part of whatever
>>>>>>>> program the simulated simulator is simulating, which happens to be
>>>>>>>> itself.
>>>>>>>>
>>>>>>>
>>>>>>>  From the concrete execution trace of DDD emulated by HHH
>>>>>>> according to the semantics of the x86 language people with
>>>>>>> sufficient technical competence can see that the halt status
>>>>>>> criteria that professor Sipser agreed to has been met.
>>>>>>
>>>>>> Nope.
>>>>>>
>>>>>> Proven previously and you accepted by default by not pointing out 
>>>>>> an error.
>>>>>>
>>>>>> Your HHH neither "correctly simulated" per his definitions or 
>>>>>> correctly predicts the behavior of such a simulation, and thus 
>>>>>> never acheived the required criteria.
>>>>>>
>>>>>
>>>>> So you are still trying to stupidly get away with saying
>>>>> that when a finite string of x86 code is emulated according
>>>>> to the semantics of the x86 language
>>>>>
>>>>> (including HHH emulating itself emulating DDD)
>>>>> THAT THE EMULATION CAN BE WRONG ???
>>>>>
>>>>
>>>> It is WRONG for the determination of the final behavior of DDD it is 
>>>> aborted.
>>>>
>>>> Remember, the "semantics of the x86 processor" includes the fact 
>>>> that the x86 processor WON'T STOP until it reaches a terminal 
>>>> instruction, and thus stopping before that isn't actually correct.
>>>>
>>>> If you are willing to admit partial behavior, it can be correct, but 
>>>> saying it will "never" do something, is unsupported.
>>>
>>> https://chatgpt.com/share/6709e046-4794-8011-98b7-27066fb49f3e
>>> Fully understands that HHH does correctly predict the behavior
>>> of DDD emulated by HHH according to the semantics of the x86 language.
>>>
>>> Try and post its response to your argument against this.
>>> It will be just like the reason why Trump doesn't want
>>> any more debates or interviews.
>>>
>>> ChatGPT will make a fool of any rebuttal that you make of my work.
>>>
>>>
>>
>> Because you have LIED to it, and AI is too stupid to catch that, 
>> because it has been programmed to try to agree with what it has been 
>> told.
> 
> If anything that I said to it was untrue then
> you could find a way to convince ChatGPT that
> it is untrue. You don't try because you know
> that I am correct.
> 

And I posted where ChatGPT ADMITTS that the input represents a HALTING 
program, but that it was justified given a wrong answer.

Since a wrong answer is never the right answer, all you have done is 
convinced an AI to lie.

IF your criteria is can you convince a AI to accept you statement, then 
you must accept that DOnald Trump won the 2020 election because of the 
massive election fraud and that Global Warming isn't a thing to b4 
worried about, as both of those positions can likely be successulf 
argued to it.

Sorry, you are just proving that you have just lost all contact with the 
actual meaning of Truth and Knowledge and have turned yourself into a 
brainwashed patholo0gical lying idiot.