Re: HHH maps its input to the behavior specified by it ---

On 8/10/24 2:11 PM, olcott wrote:

On 8/10/2024 12:51 PM, Richard Damon wrote:

On 8/10/24 1:37 PM, olcott wrote:

>
<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>
>
That is true in every case except when an input calls its
own simulating halt decider.

>
>
Nope. No exeptions. That is just another of your "I made it up but can't prove it but it must be true" lies.
>
>

>
void DDD()
{
   HHH(DDD);
   return;
}
>
*The set of HHH x86 emulators are defined such that*
Each element of this set corresponds to one element of the set
of positive integers indicating the number of  x86 instructions
of DDD that it emulates.

>
But every one that emulates for a finite number of steps, and then returns create a halting DDD, so you claim is just disproven.
>

 Changing the title indicates a reply that I can ignore.
I am only replying to a single thread of communication
with you.

I just sometimes correct your title, because it is wrong.
For instance, if HHH is defined to be a Halt Decider, it MUST map the input to the behavior of the direct execution of the machine represented by the input, which if HHH(DDD) returns to main, in returns to DDD, so the mapping it is REQUIRED to compute (to be correct) is Halting.
If HHH computes a mapping based on its aborted simulation of its input, then it is NOT a "Halt Decider", but something else. Since the mapping it is computing differs based on the decider, it isn't even a fixed property of the input, so isn't even a valid "property" for a decider unless you define the property for THAT PARTICUAL HHHs simulaiton, and thus you infinite set of "deciders" is looking at an infinite set of "properties", which isn't something that is normally considered valid.
Sorry, you are just showing you don't know what you are talking about.

 *Maybe your ADD has always been much worse than I ever expected*
We have been over all of these same points hundreds of times.

Right, you have made the same LIES  over and over, and I keep on correcting you, but you seem too stupid to be able to learn. I pity the angel that has been assigned to keep your behavior books in heaven and has to keep track of all your lies.

 When each element of the outer-most directly executed SHH
corresponds to one element of the set of positive integers
indicating the number of x86 instructions of DDD that it
emulates none of the emulated instances of HHH ever returns.

And EVERY ONE Of them doesn't get the right answer.
The ones that do a finite number of instructions, and then return create a HALTING DDD, because the DDD they are looking at calls THEM, so if they return to their caller of main, they return to their caller of DDD, and thus DDD is halting.
The fact that their simulation didn't get to that point, just shows that it was just a PARTIAL simulation which doesn't actually show the full behavior fo the input, and then the programmer (YOU) gave them faulty logic to try to compute the behavior.
Your problem is you conflate the behavior of the program emulated, with the partial emulation of that program. Once you talk about "halting", partial emulations are no longer determinative of that property, only direct exectution or complete emulations.

 THAT IS WHAT THE C SOURCE CODE MEANS
THAT IS WHAT THE X86 CODE MEANS
 

Well, the x86 instruction of DDD says that it will do exactly what its direct execution does, and says that the code of HHH is PARRT of the code of DDD, as that comes out of the semantics of the x86 langugage.
It also comes out of the C programming language, which says that a program consists of ALL the translation units that define the program, and DDD isn't a valid program if we don't have the translation unit with HHH.
This also means that changing the translation unit with HHH, changes the program DDD, whether you want to consdier that or not, and thus the correct interpreation of the program DDD if dependent on the behavior of HHH, and thus you can't look at the behavior of one DDD while assuming a different HHH then the one that DDD actually was calling.