Deutsch   English   Français   Italiano  
<v0loq2$2g493$1@i2pn2.org>

View for Bookmarking (what is this?)
Look up another Usenet article

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: Can D simulated by H terminate normally?
Date: Sun, 28 Apr 2024 11:08:50 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v0loq2$2g493$1@i2pn2.org>
References: <v0k4jc$laej$1@dont-email.me> <v0l11u$ussl$1@dont-email.me>
 <v0lh24$123q3$1@dont-email.me> <v0lic7$2g492$3@i2pn2.org>
 <v0lkas$12q0o$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 28 Apr 2024 15:08:50 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2625827"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <v0lkas$12q0o$3@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
Bytes: 7006
Lines: 147

On 4/28/24 9:52 AM, olcott wrote:
> On 4/28/2024 8:19 AM, Richard Damon wrote:
>> On 4/28/24 8:56 AM, olcott wrote:
>>> On 4/28/2024 3:23 AM, Mikko wrote:
>>>> On 2024-04-28 00:17:48 +0000, olcott said:
>>>>
>>>>> Can D simulated by H terminate normally?
>>>>
>>>> One should not that "D simulated by H" is not the same as
>>>> "simulation of D by H". The message below seems to be more
>>>> about the latter than the former. In any case, it is more
>>>> about the properties of H than about the properties of D.
>>>>
>>>
>>> D specifies what is essentially infinite recursion to H.
>>> Several people agreed that D simulated by H cannot possibly
>>> reach past its own line 03 no matter what H does.
>>
>> Nope, it is only that if H fails to be a decider.
>>
> 
> *We don't make this leap of logic. I never used the term decider*
> *We don't make this leap of logic. I never used the term decider*
> *We don't make this leap of logic. I never used the term decider*
> *We don't make this leap of logic. I never used the term decider*


You admit that people see that as being a claim about the Halting 
Problem, and thus the implied definitons of the terms apply.

This is obvious from your twenty year context of the arguement.


If you want to disconnect your recent statements from your past context, 
you need to make an EXPLICIT repudiation that this is where you are 
going to try to go, and that you accept that you can't just blindly 
connect things back there just because of similar words.

Then, you are going to need to FORMALLY define the meaning of your words 
that you are using. What are the restrictions on the "C Function" that 
is trying to make the decision, and what defines "behavior"?

What are the restrictions on the "C Function" to be processed? This is 
particularrly important as it appears that you allow that function to 
have "unbound" references to things that are not part of it (like H).

What exactly do you men by "Simulation"? In particular, what does it 
mean to correctly simulate a part of the input that isn't actually part
of the input (like the call to H)?

Then lastly, why should we care? If you can't put it into the framework 
of an established problem, why should people even care about what you 
are doing?

It is clear that you long term goal is to get back to the Halting 
Problem and what it implies about the non-provability of some truths and 
the inability to alway know if a statement is true.

You are just setting yourself up for failure, as every time you try to 
move this "problem" closer to that, you are going to invalidate some of 
the assumption built into your proof, and it then needs to be redone. Of 
course, your idea is probably that you can get people to forget the 
definitions the earlier parts were built under, after you re-stipulate 
meanings over and over, and thus shouldn't be able to reach past the 
definition change, but you will.

> 
> We are only concerned with the behavior of a pair of C functions.
> Unless I require that reviewers proceed through every slight nuance
> of details of my reasoning they simply ignore my words and leap to
> the conclusion that I must be wrong.

Because, we know that you are, because you WILL try to link it back to 
your previous claims.

You have shown that you just don't understand the meaning of the words 
that you use.

> 
> *It will be increasingly more clear that your rebuttals are baseless*
> *It will be increasingly more clear that your rebuttals are baseless*
> *It will be increasingly more clear that your rebuttals are baseless*

No, it is increasingly clear that you are totally ignorant of the topic 
that you claimed to be working on.

It is increasingly clear that you just have no ground to base your 
claims on.

If they had a base, you could start from the side next to what is 
actually known and proven, and work from that side. The fact that you 
can't, just means that your logic is most likely invalid.

> 
>> Since you claim H to be a decider, D can not have infinite recursion, 
>> because H must return in finite time.
>>
>> Yes, we get two different, and contradictory, sets of results 
>> depending on which facts we look at. The cause of this is the 
>> principle of explosion, that somewhere in our setup we have a false 
>> premise, and that turns out to be that there can exist an H that can 
>> correctly determine the halting status of its input, or in particular, 
>> the input built by this formula.
>>
>>>
>>>>> The x86utm operating system based on an open source x86 emulator.
>>>>> This system enables one C function to execute another C function
>>>>> in debug step mode. When H simulates D it creates a separate process
>>>>> context for D with its own memory, stack and virtual registers. H
>>>>> is able to simulate D simulating itself, thus the only limit to
>>>>> recursive simulations is RAM.
>>>>>
>>>>> // The following is written in C
>>>>> //
>>>>> 01 typedef int (*ptr)(); // pointer to int function
>>>>> 02 int H(ptr x, ptr y)    // uses x86 emulator to simulate its input
>>>>> 03
>>>>> 04 int D(ptr x)
>>>>> 05 {
>>>>> 06   int Halt_Status = H(x, x);
>>>>> 07   if (Halt_Status)
>>>>> 08     HERE: goto HERE;
>>>>> 09   return Halt_Status;
>>>>> 10 }
>>>>> 11
>>>>> 12 void main()
>>>>> 13 {
>>>>> 14   D(D);
>>>>> 15 }
>>>>>
>>>>> Execution Trace
>>>>> Line 14: main() invokes D(D)
>>>>>
>>>>> keeps repeating (unless aborted)
>>>>> Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>>>>
>>>>> Simulation invariant
>>>>> D correctly simulated by H cannot possibly reach its own line 09.
>>>>>
>>>>> Is it dead obvious to everyone here when examining the execution
>>>>> trace of lines 14 and 06 above that D correctly simulated by H cannot
>>>>> possibly terminate normally by reaching its own line 09?
>>>>
>>>>
>>>
>>
>