Path: ...!eternal-september.org!feeder2.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: joes <noreply@example.org>
Newsgroups: comp.theory
Subject: Re: The philosophy of computation reformulates existing ideas on a
 new basis
Date: Sat, 2 Nov 2024 12:47:12 -0000 (UTC)
Organization: i2pn2 (i2pn.org)
Message-ID: <3d8e4722ab9bce41bcd237e3e96530762dcaf597@i2pn2.org>
References: <vfli1h$fj8s$1@dont-email.me> <vflue8$3nvp8$2@i2pn2.org>
	<vfmd8m$k2m7$1@dont-email.me>
	<bcd82d9f8a987d3884220c0df7b8f7204cb9de3e@i2pn2.org>
	<vfmueh$mqn9$1@dont-email.me>
	<ff039b922cabbb6d44f90aa71a52d8c2f446b6ab@i2pn2.org>
	<vfo95k$11qs1$1@dont-email.me> <vfp8c0$3tobi$2@i2pn2.org>
	<vfpcko$1837o$3@dont-email.me> <vfpish$3u885$2@i2pn2.org>
	<vfpjk2$1976k$1@dont-email.me>
	<086fc32f14bcc004466d3128b0fe585b27377399@i2pn2.org>
	<vfqsui$1jg6i$2@dont-email.me> <vft4om$44tc$2@i2pn2.org>
	<vft944$25aio$6@dont-email.me>
	<11408789ed30027f4bc9a743f353dfa9b4712109@i2pn2.org>
	<QU2dnTAfup30Rr_6nZ2dnZfqn_WdnZ2d@brightview.co.uk>
	<vfvnml$2ll12$1@dont-email.me> <vfvujg$2mcse$6@dont-email.me>
	<vg2cqm$37cq6$1@dont-email.me> <vg2kfq$38m0h$1@dont-email.me>
	<vg4va2$3ok87$1@dont-email.me> <vg55lv$3pnvp$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 2 Nov 2024 12:47:12 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="590168"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="nS1KMHaUuWOnF/ukOJzx6Ssd8y16q9UPs1GZ+I3D0CM";
User-Agent: Pan/0.145 (Duplicitous mercenary valetism; d7e168a
 git.gnome.org/pan2)
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 9009
Lines: 147

Am Sat, 02 Nov 2024 07:24:29 -0500 schrieb olcott:
> On 11/2/2024 5:35 AM, Mikko wrote:
>> On 2024-11-01 13:18:48 +0000, olcott said:
>>> On 11/1/2024 6:08 AM, Mikko wrote:
>>>> On 2024-10-31 12:53:04 +0000, olcott said:
>>>>> On 10/31/2024 5:55 AM, Mikko wrote:
>>>>>> On 2024-10-31 01:20:40 +0000, Mike Terry said:
>>>>>>> On 30/10/2024 23:35, Richard Damon wrote:
>>>>>>>> On 10/30/24 8:34 AM, olcott wrote:
>>>>>>>>> On 10/30/2024 6:19 AM, Richard Damon wrote:
>>>>>>>>>> On 10/29/24 10:54 AM, olcott wrote:
>>>>>>>>>>> On 10/29/2024 5:50 AM, Richard Damon wrote:
>>>>>>>>>>>> On 10/28/24 11:08 PM, olcott wrote:

>>>>>>>>>>> I read, reread again and again to make sure that my
>>>>>>>>>>> understanding is correct. You seems to glance at a few words
>>>>>>>>>>> before spouting off a canned rebuttal that does not even apply
>>>>>>>>>>> to my words.
Comedy gold.

>>>>>>>>>> No, it knows its own code because it rule for "No conditional
>>>>>>>>>> branches" excludes that code.
>>>>>>>>> It does not know its own code. It merely knows that the machine
>>>>>>>>> address that it is looking at belongs to the operating system. I
>>>>>>>>> simply don't have the fifty labor years that AProVE:
>>>>>>>>> Non-Termination Witnesses for C Programs,
>>>>>>>>> could spend on handling conditional branches.
>>>>>>>>> The stupid aspect on your part is that even knowing that its own
>>>>>>>>> code halts THIS HAS NOTHING TO DO WITH DDD REACHING TS OWN
>>>>>>>>> RETURN INSTRUCTION.
>>>>>>>> No, HHH is NOT part of the "Operating System" so your claims are
>>>>>>>> just a lie,
>>>>>>> PO definitely has a deep-rooted problem with his thinking here.
>>>>>> What PO does does not look like any thingking but more like what
>>>>>> one could expect from ChatgPPT or a similar AI.
>>>>> I don't have the 50 years it would take for me to replicate the work
>>>>> of AProVE: Non-Termination Witnesses for C Programs.
>>>> Doesn't matter. Even if you had you could not use it to prove your
>>>> false claim that there be some defect in some proof.
>>> There has never ever been the least trace of error in this verified
>>> fact:
>>> DDD emulated by HHH according to the semantics of the x86 language
>>> cannot possibly reach its own "return" instruction whether or not any
>>> HHH ever aborts its emulation of DDD.
>> No, but its relevance to Linz' proof is very thin.
> When the main motive of people like Richard is to derail any chance of
> mutual agreement I cannot proceed with all of the steps achieving mutual
> agreement on each step one at a time in their mandatory prerequisite
> order.
Block him then?
You don't need to go in order.

>>> When we do not construe the current received view as inherently
>>> infallible then we can begin to consider alternative view.
>> You can call a strawman deception (or an attempt of one) an altenative
>> view but it is still a strawman deception.
> THE FREAKING SUBJECT OF THE FREAKING THREAD IS THE PHILOSOPHY OF
> COMPUTATION.
No, the subject is that halting is undecidable.

>>> If naive set theory was construed as inherently infallible then ZFC
>>> could have never resolved Russell's Paradox.
>> There is no point in construing an inconsistent theory as inherently
>> infallible.
> None-the-less everyone here continues to do that. Everyone here takes
> the current received view on the theory of computation is if it came
> directly from God himself. They cannot begin to imagine the tiniest
> little trace of any error what-so-ever in the current received view.
Projecting much?

>>> It really is not even any change to the view of deciders to know that
>>> they compute the mapping from their finite string input to their own
>>> accept or reject state on the basis of a semantic or syntactic
>>> property of this string.
>> 
>>> It does seems to be a change to how this semantic property is string
>>> understood when applied to the halting problem proof.
>> The point is that a Turing machine can only compute syntactic
>> properties.
> No that is not the actual point. That is only the current received view
> not an infallible ruling. Rice's theorem is accepted as true. That is
> not the same as it actually being true.

>> From what I recall Rice can always be reduced to the HP.
> This means refuting the HP proofs can be construed as refuting Rice.
Getting into heady heights here.

>>> Everyone here seems to think that the semantic property of this finite
>>> string is not the actual behavior that this finite string actually
>>> specifies.
>> In order to get a specification of anything the string must be
>> interpreted.
> Thus when HHH is a C interpreter both HHH and DDD eventually crash due
> to out-of-memory error.
Finite memory means it is not Turing-complete.

>> A behaviour is not a finite string so a Turing machine cannot see it.
> [...] this UTM can see the behavior specified by
> the string as a subset of its own state transitions.
A UTM does not abort.

>>> Instead of the actual behavior they construe it as the idealized
>>> behavior that would occur if DDD was not calling its own termination
>>> analyzer.
>> No, most participant of these discussions understand that the halting
>> problem asks about the actual behaviour of the actual Turing machine
>> with the actual input.
> We are still miles away from beginning to talk about the halting
> problem. We must first establish mutual agreement on this.
I'd rather hear about the halting problem. I'm reluctant to agree to
your unknown reasoning up front, because you will represent it as
proof you must be right. I can agree to this first step later and
then I will have agreed to everything else.

>>>>> In other case what I am doing is called isolating the independent
>>>>> variable.
>>>> You may call it that way. It does not look like that.
>>>>
>>>>> The program under test is DDD.
>>>>> HHH is NOT the program under test it is the tester.
>>>> So far is good. But the halting problem demands that every Turng
>>>> machine can be put to the test.

>>> It is not 100% impossible to construe this as the reject criteria. It
>>> is merely unconventional.
>> More importan is whther it is correct. If a terminating computation is
>> rejected as non-terminating then at least one of the criteria is
>> incorrect.
> HHH does compute the mapping from its input DDD to the actual behavior
> that DDD specifies and this DOES INCLUDE HHH emulating itself emulating
> DDD.
The actual behaviour that the code of DDD specifies differs from what
your "decider" returns.

> HHH1 does compute the mapping from its input DDD to the actual behavior
> that DDD specifies and this DOES NOT INCLUDE HHH1 emulating itself
> emulating DDD.
Then DDD is a different program being given the same name, but not the
same code - that of the program which simulates it.
DDD(){HHH(DDD);} is different from EEE(){HHH1(EEE);}.

> It seems ridiculously stupid for everyone here to simply ignore how
> pathological self-reference DOES IN FACT change the behavior of DDD.
One program = one behaviour.

-- 
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.