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 10:42:59 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v56ntj$onl3$7@i2pn2.org>
References: <v56n8h$3pr25$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 14:42:59 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="810659"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <v56n8h$3pr25$1@dont-email.me>
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 5903
Lines: 121

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).

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. 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", 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.

The input is the finite string.

The MEANING of that finite string is defined by the PROBLEM. The decider 
gets to define the encoding, but not the meaning/behavior of the encoded 
items.

Halting DEFINES the meaning/behavior to be that of the directly run 
program represented by the input.
> 
> *Here is the verified facts that everyone denies*
> *Here is the verified facts that everyone denies*
> *Here is the verified facts that everyone denies*
> *Here is the verified facts that everyone denies*
> 
> void DDD()
> {
>    HHH0(DDD);
> }
> 
> int main()
> {
>    Output("Input_Halts = ", HHH0(DDD));
>    Output("Input_Halts = ", HHH1(DDD));
> }
> 
> It is a verified fact that the behavior that finite string DDD
> presents to HH0 is that when DDD correctly emulated by HH0
> calls HH0(DDD) that *THIS CALL DOES NOT RETURN*
> 
> It is a verified fact that the behavior that finite string DDD
> presents to HH1 is that when DDD correctly emulated by HH1
> calls HH0(DDD) that *THIS CALL DOES RETURN*
> 
> 


The problem is that the "behavior" that the finite string DDD presents 
to HH0, is DEFINED by the problem. And if that problem is the Halting 
Problem, that behavior is the behavior of the machine the input 
represents. If HH0 treats the input as having a different behavior, then 
HH0 just isn't a Halting Decider, but something else.

If HH0 is supposed to be a Halting decider, but uses a method that makes 
it see something other than that behavior, then it is just an incorrect 
Halting Decider, and its algorithm just creates an incorrect recreation 
of the property of the input it is supposed to be working on.


A bit of a side note, the actual "Input" to HH0, is a pointer to memory, 
and as such it passes a reference to ALL of memory considering the 
starting point to be that address, so your "Input" isn't actually the 
few bytes of DDD, but ALL of memory and a starting point. If you 
actually mean that the input is just those few bytes pointed to by the 
address, then the input is improperly formed and is NOT a proper 
representation of the input machine, becuase it is incomplete.

The fact you don't understand this, seems to imply you are lacking the 
basic knowledge to be talking about this sort of thing.