Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory,sci.logic
Subject: Re: Why do people here insist on denying these verified facts?
Date: Sat, 22 Jun 2024 13:08:21 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v570e5$onl4$10@i2pn2.org>
References: <v56n8h$3pr25$1@dont-email.me> <v56ntj$onl3$7@i2pn2.org>
 <v56ps2$3q4ea$1@dont-email.me> <v56ql2$onl3$9@i2pn2.org>
 <v56t5a$3ql1v$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 22 Jun 2024 17:08:21 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="810660"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
In-Reply-To: <v56t5a$3ql1v$1@dont-email.me>
Bytes: 14797
Lines: 365

On 6/22/24 12:12 PM, olcott wrote:
> On 6/22/2024 10:29 AM, Richard Damon wrote:
>> On 6/22/24 11:16 AM, olcott wrote:
>>> On 6/22/2024 9:42 AM, Richard Damon wrote:
>>>> On 6/22/24 10:31 AM, olcott wrote:
>>>>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
>>>>>
>>>>> To understand this analysis requires a sufficient knowledge of
>>>>> the C programming language and what an x86 emulator does. HHH0
>>>>> and HHH1 have this criteria as their algorithm:
>>>>
>>>> Which you just showed you don't have, since on comp.lang.c++ you 
>>>> thought that
>>>>
>>>> x *= ++f * ++f;
>>>>
>>>> had defined behavior for primative types for f.
>>>>
>>>>>
>>>>> <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>
>>>>
>>>> Which used the definition of "Correct Simulation" to mean a 
>>>> simulation that produces the EXACT results of the direct execution 
>>>> of the machine being simulated, which requires a simulation that 
>>>> will not "abort" its simulation, EVER (except by reaching a final 
>>>> state).
>>>>
>>>
>>> I have had enough of your deception trying to get away
>>> with denying the semantics of the x86 programming language.
>>> I really hope that you don't get condemned to Hell over this.
>>
>> And what in the actual detail of the x86 programming language says 
>> something diffferent than what I say?
>>
>> I think YOU are the one in danger, as you LIE about what the x86 
>> assembly code says,
>>
>>>
>>>> You Deciders do not do this, nor do they do this about an actual 
>>>> Correct Simulation per that definition of the input, so they can not 
>>>> use the second clause.
>>>>
>>>>>
>>>>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
>>>>>  > I don't think that is the shell game. PO really /has/ an H
>>>>>  > (it's trivial to do for this one case) that correctly determines
>>>>>  > that P(P) *would* never stop running *unless* aborted.
>>>>>  >
>>>>>
>>>>> Ben only agrees that the criteria is met for the input. He
>>>>> does not agree that the criteria has been meet for non-inputs.
>>>>
>>>> Ben only agrees that H correctly decides the exact criteria that you 
>>>> state, that no H can "correctly simuate" (per YOUR definition) the 
>>>> input to a final state. 
>>>
>>> And you happily deny the verified facts at the possible cost
>>> of damnation in Hell.
>>>
>>>> Thus, he is agreeing that you H is a POOP decider, for this input, 
>>>> but not that it is a HALTING decider for this input, since its 
>>>> criteria is not the Halting Criteria.
>>>>
>>>>>
>>>>> Computable functions are the formalized analogue of the intuitive
>>>>> notion of algorithms, in the sense that a function is computable if 
>>>>> there exists an algorithm that can do the job of the function, i.e. 
>>>>> *given an input of the function domain*
>>>>> *it can return the corresponding output*
>>>>> https://en.wikipedia.org/wiki/Computable_function
>>>>>
>>>>> *That seems to say that non-inputs do not count*
>>>>
>>>> But we aren't talking about "Non-Inputs", 
>>>
>>> The D(D) that calls H(D,D) such that this call returns has
>>> provably different behavior than D correctly simulated by H
>>> is measured by the actual semantics of the x86 programming
>>> language.
>>>
>>> How the Hell does anyone feel that they can get away with
>>> flatly contradicting the semantics of the x86 programming
>>> language?
>>>
>>> We are a herd and our first duty it to follow the herd
>>> even if the herd leaps off a cliff.
>>>
>>>> and in fact, YOUR arguement needs to look at the non-inputs, as it 
>>>> allows the input to change when you argue about other deciders.
>>>>
>>> int sum(int x, int y){ return x + y; }
>>> In other words sum(3,4) must consider the sum of 5 + 6?
>>>
>>>> The input is the finite string.
>>>>
>>>> The MEANING of that finite string is defined by the PROBLEM.
>>>
>>> LIAR. You know that the meaning of the finite string
>>> is defined by the semantics of the x86 language.
>>
>> Right, by what the DIRECT EXECUTION of that set of instruction will do.
>>
>> Which means, for your input, in needs the instuctions of the decider 
>> it calls.
>>
>>>
>>> I might start wishing that you get a tiny taste of Hell
>>> to set you on the correct path.
>>>
>>> As Christ said as ye judge ye shall be judged so I do
>>> wish the same thing upon myself. If I am on the wrong
>>> path then I sincerely wish for the minimum adversity
>>> required to definitely set me on the right path.
>>>
>>>>  The decider gets to define the encoding, but not the 
>>>> meaning/behavior of the encoded items.
>>>>
>>>
>>> When the x86 language is specified then the decider
>>> has zero leeway in this.
>>
>> So, what in the x86 language shows what you claim?
>>
>>>
>>>> Halting DEFINES the meaning/behavior to be that of the directly run 
>>>> program represented by the input.
>>>
>>> That makes it contradict one of its own axioms, thus
>>> conclusively proving that it is incorrect:
>>>
>>> Computable functions are the formalized analogue of the
>>> intuitive notion of algorithms, in the sense that a
>>> function is computable if there exists an algorithm
>>> that can do the job of the function, i.e.
>>> *given an input of the function domain it*
>>> *can return the corresponding output*
>>> https://en.wikipedia.org/wiki/Computable_function
>>
>> Who says Halting is a Computable Function?
>>
> 
> That is the wrong question.

No, it is exactly the right question.

You can't claim the Definition of Halting is in contradiction to the 
definition of a Computable Function unless you say that Halting needs to 
be Computable.

Since it isn't defined to be that, it doesn't need to be compatable with it.

> Halting is only computed from inputs to HHH0 that include
> the call from DDD correctly emulated by HHH0 to HHH0(DDD)
> such that this call DOES NOT RETURN.

HALTING, as properly defined is NOT comptable.

You are stuck in a circular argument where you are trying to define it 
to be computable by redefining what it is, which means you aren't 
actually talking about Halting.

> 
>> THAT is part of your problem.
>>
>> The question actually is, "IS Halting Computable?"
>>
>>>
>>>>>
========== REMAINDER OF ARTICLE TRUNCATED ==========