Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Fred. Zwarts" <F.Zwarts@HetNet.nl>
Newsgroups: comp.theory
Subject: Re: V5 --- Professor Sipser --- Does Ben Bacarisse believe that
 Professor Sipser is wrong?
Date: Sun, 25 Aug 2024 22:15:44 +0200
Organization: A noiseless patient Spider
Lines: 143
Message-ID: <vag3df$22hmk$1@dont-email.me>
References: <va104l$376ed$4@dont-email.me>
 <cd375f68f97a737988bab8c1332b7802509ff6ea@i2pn2.org>
 <va13po$376ed$7@dont-email.me>
 <d42e5d30ea5f1c067283cb04d8a7293e2117188e@i2pn2.org>
 <va24hl$3cvgv$1@dont-email.me>
 <431deaa157cdae1cae73a1b24268a61cf8ec2c1c@i2pn2.org>
 <va38qh$3ia79$1@dont-email.me>
 <7a1c569a699e79bfa146affbbae3eac7b91cd263@i2pn2.org>
 <va3f7o$3ipp3$1@dont-email.me>
 <729cc551062c13875686d266a5453a488058e81c@i2pn2.org>
 <va3kac$3nd5c$1@dont-email.me>
 <148bf4dd91f32379a6d81a621fb7ec3fc1e00db0@i2pn2.org>
 <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> <vafbb7$1t7ed$1@dont-email.me>
 <vafo8i$20jfl$1@dont-email.me> <vag0vn$22bh7$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 25 Aug 2024 22:15:44 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="7474af04504c504777169ac90a75b2d9";
	logging-data="2180820"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19yuQKqX/TIjxZoYNRAg314"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:kEpyD9xzzUXR9lPYrpqunPG5b6w=
In-Reply-To: <vag0vn$22bh7$1@dont-email.me>
Content-Language: en-GB
Bytes: 8454

Op 25.aug.2024 om 21:34 schreef olcott:
> On 8/25/2024 12:05 PM, Fred. Zwarts wrote:
>> Op 25.aug.2024 om 15:24 schreef olcott:
>>> On 8/23/2024 4:07 PM, Ben Bacarisse wrote:
>>>> joes <noreply@example.org> writes:
>>>>
>>>>> Am Wed, 21 Aug 2024 20:55:52 -0500 schrieb olcott:
>>>>
>>>>>> Professor Sipser clearly agreed that an H that does a finite 
>>>>>> simulation
>>>>>> of D is to predict the behavior of an unlimited simulation of D.
>>>>>
>>>>> If the simulator *itself* would not abort. The H called by D is,
>>>>> by construction, the same and *does* abort.
>>>>
>>>> We don't really know what context Sipser was given.  I got in touch at
>>>> the time so do I 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.
>>>>
>>>> I suspect he was tricked because PO used H and D as the names without
>>>> making it clear that D was constructed from H in the usual way (Sipser
>>>> uses H and D in at least one of his proofs).  Of course, he is clued in
>>>> enough know that, if D is indeed constructed from H like that, the
>>>> "minor remark" becomes true by being a hypothetical: if the moon is 
>>>> made
>>>> of cheese, the Martians can look forward to a fine fondue.  But,
>>>> personally, I think the professor is more straight talking than that,
>>>> and he simply took as a method that can work for some inputs. 
>>>
>>> <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>
>>>
>>> If professor Sipser agreed to this and it only works for
>>> some inputs then his agreement would have been incorrect.
>>> There was an 18 message exchange prior to this agreement.
>>>
>>> I do not believe that Professor Sipser made a mistake
>>> because it still seems to be a simple tautology to me.
>>>
>>>> That's
>>>> the only way is could be seen as a "minor remark" with being accused of
>>>> being disingenuous.
>>>>
>>>>>> Ben saw this right away and it seems that most everyone else 
>>>>>> simply lied
>>>>>> about it.
>>>>> I don’t think you understood him.
>>>>
>>>> I don't think PO even reads what people write.  He certainly works hard
>>>> to avoid addressing any points made to him.  I think it's true to say
>>>> that pretty much every paraphrase he attempts "X thinks ..." (usually
>>>> phrased as "so you are saying that black is white?") is garbage.
>>>> Understanding what other people say is low in his priorities since they
>>>> must be wrong anyway.
>>>>
>>>> (I refuse to have anything more to do with PO directly after he was
>>>> unconscionably rude, but I do keep an eye out for my name in case he
>>>> continues to smear it.)
>>>>
>>>
>>> That people still disagree that a correct emulation
>>> of N instructions of DDD according to the semantics
>>> of the x86 language defines what a correct simulation
>>> is still seems flat out dishonest to me.
>> That someone still refuses to see that skipping the last few 
>> instructions of a halting program is a violation of the semantics of 
>> the x86 language seems dishonest to me, in particular when several 
>> people pointed him to this error.
>>
>>> In the case of DDD correctly emulated by HHH this does
>>> require HHH to emulate itself emulating DDD exactly one
>>> time before HHH sees the repeating pattern.
>>
>> A repeating, but not an infinite repeating pattern,
> 
> *D would never stop running unless aborted*
> *D would never stop running unless aborted*
> *D would never stop running unless aborted*
> *D would never stop running unless aborted*
> 
> Are you just being dishonest?

Forget your dream of a non-aborting HHH. It does abort, so the 'unless' 
part makes it unnecessarily complicated. It stops running, because it 
aborts.
You can't have a HHH that is aborted, when it does not perform the abort 
itself.
Why don't you see that? Are you dishonest? It does abort and therefore 
is does not repeat infinitely. Then it halts. It stops running. Are you 
dishonest, or dreaming, or cheating?


> 
>>  because HHH is programmed to abort and halt after a few cycles, 
> 
> *It never has been AFTER A FEW CYCLES*
> *It has always been until a specific condition is met*

It is coded to abort when it sees this 'specific' condition (after a few 
cycles) and then it halts. It does not matter whether this condition is 
correct or incorrect, HHH sees this 'specific' condition (after a few 
cycles) and then it halts.
That is how it is programmed. Both the simulating and the simulated HHH 
will see this 'specific' condition (after a few cycles), when allowed to 
run that far.
So, thinking that it would repeat infinitely when it sees this 'special' 
condition, is either dishonest, or a dream, or cheating.

> 
> *until H correctly determines that its simulated*
> *D would never stop running unless aborted*

Even when it determines that it should halt, it halts. And then it 
halts. That means, it stops running. That holds for both the simulating 
and the simulated HHH (unless you are still cheating with the Root 
variable).
So, it does abort and therefore it stops running.
Are you dishonest about this, or dreaming again about the non-aborting HHH?

This has been proved by the direct execution and by the correct 
simulation by HHH1. Are you dishonest about these results, or just dreaming?

> 
> Are you just being dishonest?
> 
>> which the simulated HHH would do, too, if not aborted too soon (unless 
>> cheating with the Root variable).
>