Re: Anyone that disagrees with this is not telling the truth --- V5 --- Professor Sipser

On 8/20/24 11:01 PM, olcott wrote:

On 8/20/2024 9:53 PM, Richard Damon wrote:

On 8/20/24 10:44 PM, olcott wrote:

On 8/20/2024 8:56 PM, Richard Damon wrote:

On 8/20/24 9:17 PM, olcott wrote:

On 8/20/2024 7:50 PM, Richard Damon wrote:

On 8/20/24 7:28 PM, olcott wrote:

On 8/20/2024 6:18 PM, Richard Damon wrote:

On 8/20/24 9:09 AM, olcott wrote:

On 8/19/2024 11:02 PM, Richard Damon wrote:

On 8/19/24 11:50 PM, olcott wrote:

On 8/19/2024 10:32 PM, Richard Damon wrote:

On 8/19/24 10:47 PM, olcott wrote:

*Everything that is not expressly stated below is*
*specified as unspecified*

>
Looks like you still have this same condition.
>
I thought you said you removed it.
>

>
void DDD()
{
   HHH(DDD);
   return;
}
>
_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]
>
*It is a basic fact that DDD emulated by HHH according to*
*the semantics of the x86 language cannot possibly stop*
*running unless aborted* (out of memory error excluded)

>
But it can't emulate DDD correctly past 4 instructions, since the 5th instruciton to emulate doesn't exist.
>
And, you can't include the memory that holds HHH, as you mention HHHn below, so that changes, but DDD, so the input doesn't and thus is CAN'T be part of the input.
>
>

>
X = DDD emulated by HHH∞ according to the semantics of the x86 language
Y = HHH∞ never aborts its emulation of DDD
Z = DDD never stops running
>
The above claim boils down to this: (X ∧ Y) ↔ Z

>
And neither X or Y are possible.
>

>
x86utm takes the compiled Halt7.obj file of this c program
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Thus making all of the code of HHH directly available to
DDD and itself. HHH emulates itself emulating DDD.

>
Which is irrelevent and a LIE as if HHHn is part of the input, that input needs to be DDDn
>
And, in fact,
>
Since, you have just explicitly introduced that all of HHHn is available to HHHn when it emulates its input, that DDD must actually be DDDn as it changes.
>
Thus, your ACTUAL claim needs to be more like:
>
X = DDD∞ emulated by HHH∞ according to the semantics of the x86 language
Y = HHH∞ never aborts its emulation of DDD∞
Z = DDD∞ never stops running
>
The above claim boils down to this: (X ∧ Y) ↔ Z
>

>
Yes that is correct.

>
So, you only prove that the DDD∞ that calls the HHH∞ is non- halting.
>
>
Not any of the other DDDn
>

>

Your problem is that for any other DDDn / HHHn, you don't have Y so you don't have Z.
>

>
void EEE()
{
   HERE: goto HERE;
}
>
HHHn correctly predicts the behavior of DDD the same
way that HHHn correctly predicts the behavior of EEE.
>

>
Nope, HHHn can form a valid inductive proof of the input.
>

>

It can't for DDDn, since when we move to HHHn+1 we no longer have DDDn but DDDn+1, which is a different input.
>

>
You already agreed that (X ∧ Y) ↔ Z is correct.
Did you do an infinite trace in your mind?

>
But only for DDD∞, not any of the other ones.
>

>
If you can do it and I can do it then HHH can
do this same sort of thing. Computations are
not inherently dumber than human minds.
>

>
But HHHn isn't given DDD∞ as its input, so that doesn't matter.
>
HHHn is given DDDn as its input,
>
Remeber, since you said that the input to HHH includes all the memory, if that differs, it is a DIFFERENT input, and needs to be so marked.
>
You are just admittig that you are just stupid and think two things that are different are the same.
>
>

>
*attempts to use misdirection to weasel word around this are dismissed*
*attempts to use misdirection to weasel word around this are dismissed*
*attempts to use misdirection to weasel word around this are dismissed*
>
<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
>
>

>
Right, so the decider needs top be able to show that its exact input will not halt.

>
No it cannot possibly mean that or professor Sipser
would not agreed to the second half:
>
     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>
>
>

>
Of course it means that, because Professoer Sipser would have presumed that you built the machines PROPERLY, so that you COULD think of changing THIS H to be non-aborting, while the input still used the final version that it always uses,
>

>
A machine cannot both abort and fail to abort an input
unless it modifies its own code dynamically.

>
>
Right, so HHH must do just one of them, and the DDD that calls it will act differently based on which one it is.
>

>
Professor Sipser would not have construed that I am referring
to self-modifying code.

>
Nope, just giving the exact same input to two different version of the decider, the one that doesn't abort as the hypothetical, and the one that does as the actual (if the hypothical one doesn't halt).
>
The key is that both get the EXACT SAME input, the DDD that calls the HHH that does abort.
>
The point is that your "reasoning" can't actually be done just by experimentation, (as to experimentally show that the input when correctly simulated will not halt take infinite time), but needs to be solved by correct LOGIC, thus the "hypothetical" machine never actaully needs to exist, but the actual machine needs to be able to prove what it would do with the EXACT input that was given, and not just the matching imput from the "template".
>

>
This means that he must have understood that HHHn(DDD)
is predicting the behavior of HHH∞.

>
Nope. That is just your stupidity.
>
In his case, there really IS just one DDD, and that DDD calls HHH.
>
The test case is giving HHH∞ the input DDD that calls the HHH that you want to call correct, which is the aborting one.
>
ANd then HHH∞ shows that HHH isn't actually authorixed to abort its simulation, so was programmed incorrectly.
>

>
(1) That is mostly incoherent.

>
Nope. It is factual. That you can't understand it shows your stupidity.
>

(2) When you pay complete attention (if you can even do that)
>
You will see the Professor Sipser could have only been
referring to HHHn(DDD) predicting the behavior of HHH∞(DDD)

>
Nope. That is just illogical, and your claims make you just a liar.
>

>
Your weasel words around this may simply be your ADD.
>

>
You are just IGNORANT of what the words mean, which you prove by saying they can;t mean what they do means just because you dont want them to mean it.
>
First, your HHH/DDD setup is INVALID in computatio theory, The *PROGRAM*

 *We are only talking about one single point*
Professor Sipser must have understood that an HHH(DDD)
that does abort is supposed predict what would happen
if it never aborted.
 That you can't even stick to that point may be an ADD issue.
 

Of course he did. But for D that calls H that means what a simulation of THAT EXACT input would do if not aborted, including the behavior of the H that will possibly eventually abort (since that IS what the input would do).
Professor Sipser would ONLY think of inputs as COMPLETE programs, and thus D includes all the code of the H it calls, and that code doesn't change when we hypothesize that H doesn't abort its simulation, and thus the H deciding is a DIFFERENT copy then the H that D calls.
Your "system" just breaks that rule, and thus makes the idea of "changing H" not possible.
Sorry, you are just so brainwashed by yourself into believing your lies, that you have just killed your ability to actually see reality.