Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: A New Turing Machine Model
Date: Thu, 13 Feb 2025 07:17:15 -0500
Organization: i2pn2 (i2pn.org)
Message-ID: <e371ea488bdfe76be1417ab70030d7c10ec761a9@i2pn2.org>
References: <23c2f03654be07b579c1d15f4491bfc6ba0b9031.camel@gmail.com>
 <878qqaoi9h.fsf@bsb.me.uk> <vojs62$2oikq$5@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 13 Feb 2025 12:17:16 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="4036608"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <vojs62$2oikq$5@dont-email.me>
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 3164
Lines: 45

On 2/12/25 11:24 PM, olcott wrote:
> On 2/12/2025 5:28 PM, Ben Bacarisse wrote:
>> wij <wyniijj5@gmail.com> writes:
>>
>>> Many should have been annoyed by the low-level-ness of the 
>>> traditional Turing
>>> Machine. Spu comes to the rescue.
>>
>> The low-level is useful because it simplifies a lot of proofs, but when
>> something higher-level is needed Turing equivalence and other results
>> like the Curry-Howard correspondence mean that there is no shortage of
>> higher-level models to work with.
>>
> 
> https://en.wikipedia.org/wiki/Random-access_stored-program_machine
> Concise, precise and easily mapped to many higher level language.
> I have simply assumed that C maps to RASP and then used C.
> 

The problem is that while you can build a RASP machine from a Turing 
Machine (since it is Turing Compatible), a RASP machine ISN'T a Turing 
machine, and RASP code doesn't have all the nice properties of Turing 
COde, the big one being that *ALL* Turing Machine code fragments perform 
comupuations (a defined mapping of input to output) that can not be said 
of RASP program fragments.

The key point is that the fundamental structure of a Turing Machine puts 
a clear line between what is the "input" and what is the "internal 
program state", and what is the program, and a given program always 
starts at the same internal state.

Once you mix input and program state into a common bucket, you lose that 
nice property.

So, we get to your fundamental problem, that what you call the "program" 
D/DD/DDD isn't actually a program, but a program fragment, and when we 
run it, it ends up using "code" outside of itself, and thus violates the 
definition of a computation. In the same way, your decider, due to your 
"bug" that makes it not pure code, also uses data outside of its input, 
and thus is also not actually a "program" in the required meaning.

That you refuese to see this, just proves that you are totally ignorant 
of what you are talking about, and to stupid to understand your ignorance.

This is what comes by speaking rote phrases that you never learned their 
meaning.