Re: Simulating termination analyzers by dummies --- criteria is met

On 6/22/24 10:42 AM, olcott wrote:

On 6/22/2024 9:20 AM, Richard Damon wrote:

On 6/22/24 10:11 AM, olcott wrote:

On 6/22/2024 8:27 AM, Richard Damon wrote:

On 6/22/24 9:04 AM, olcott wrote:

>
https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
>
<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>

>
And, as I remember, he also verified that he disagrees with your definition of correct simulation.
>

>
*Ben also verified that the criteria have been met*
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
 > I don't think that is the shell game. PO really /has/ an H
 > (it's trivial to do for this one case) that correctly determines
 > that P(P) *would* never stop running *unless* aborted.

>
Right, Ben was willing to do what I am not that you can prove that, by your definition, H can show that it "must" abort its simulation or the input will run forever.
>
But, just like me, he also agrees that this is NOT the defintion of Halting, so H is just shown to be a correct (partial) POOP decider but ot a Halt Decider, not even for that one input.
>

>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
 > I don't think that is the shell game. PO really /has/ an H
 > (it's trivial to do for this one case) that correctly determines
 > that P(P) *would* never stop running *unless* aborted.
 >
 > He knows and accepts that P(P) actually does stop. The
 > wrong answer is justified by what would happen if H
 > (and hence a different P) where not what they actually are.
 >
*Ben agrees that the criteria is met for the input*
>
Computable functions are the formalized analogue of the
intuitive notion of algorithms, in the sense that a function
is computable if there exists an algorithm that can do the
job of the function, i.e. *given an input of the function*
*domain it can return the corresponding output*
https://en.wikipedia.org/wiki/Computable_function
>
*Ben disagrees that the criteria is met for the non-input*
Yet no one here can stay focused on the fact that non-inputs
*DO NOT COUNT*

>
No, you don't understand the words he is using because you have distroted the meaning of too many words.
>
He is agreeing that H can correctly decide the POOP criteria, the it can

 The criteria that professor Sipser agreed is correct
and agreed that I can quote his agreement.
 

say that "no H can correctly simulate that input to a final state", but he does NOT agree that it means it doesn't HALT,

And the ONLY meaning that Professor Sipser has for "Correctly Simulate" is a simulation that EXACTLY reproduces the behavior of the input, and that means doesn't abort. Which H doesn't do.
Also, the input to a Halt Decider is the representation of a COMPLETE PROGRAM, so in your case, the D specifies an exact H that it uses.
So, when you use his statement to "change H", you change JUST the H doing the deciding, and NOT the H that is used by D, that is still the original H.
When we do this, your hypothetical H doing the simulating WILL SEE (if it runs long enough) the simulate original-H deciding it can use the criteria to abort, and then return 0 to the D that called it and D halting.
Thus, original-H is INCORRECT in thinking that it can correctly decide that "NO H" can never correctly simulate THIS INPUT to a final state, as some alternate Hs can.

 He also agreed that
 >>>>    H can abort its simulation of D and correctly report that D
 >>>>    specifies a non-halting sequence of configurations.

But only if it proved the first step.

 *So yet again you try to get away with denying verified facts*
and are busted.
 

Nope, your lies are exposed an YOU are busted.
You fundamentally don't understand the rules of the game you are trying to play, and keep on making illegal moves and complaing that the other player, who does know the rules, is cheating by not letting you make the illegal moves.

because that isn't the meaning of Halting, and your definition of Correct Simulation isn't what Professor Sipser was using, so you can't use that.
>
So, you are just stuck in your lies.
>

>
void DDD()
{
   HHH0(DDD);
}
>
int main()
{
   Output("Input_Halts = ", HHH0(DDD));
   Output("Input_Halts = ", HHH1(DDD));
}
>
It is a verified fact that the behavior that finite string DDD
presents to HH0 is that when DDD correctly simulated by HH0
calls HH0(DDD) that this call DOES NOT RETURN.
>
It is a verified fact that the behavior that finite string DDD
presents to HH1 is that when DDD correctly simulated by HH1
calls HH0(DDD) that this call DOES RETURN.
>
*I don't get why people here insist on lying about verified facts*
>
>

>
>
The problem is that the "behavior" that the finite string DDD presents to HH0, is DEFINED by the problem.

 *Not not at all, not in the least little bit*
 No textbook is allowed to override and supersede
the semantics of the x86 programming language.

So, what in the x86 programming language says ANYTHING about "Halt Deciding"? (citation please, or you admit to making that up)
And, as has been shown, the ACTUAL behavior of a correct simulation of the x86 code EXACTLY REPRODUCES the behavior of the input directly executed. The "difference" you see are when you don't actually simulate an instruction by try to argue (incorrectly) what it must be the equivalent of.,
for instance, a CALL H instruction, since H WILL return 0 when directly called, WILL eventally see a return with the value of 0.
The fact the simulator can't simulate to that point for any version of H you try to make doesn't change that behavior, it just means that no H can KNOW what the will do before it decides it needs to stop to give an answer.
it can't just assume it will not return, THAT is incorrect logic.

 Unlike you this does seem to be an honest mistake
on their part.

Nope, just shows you don't know what you are talking about.

 

 And if that problem is the Halting Problem, that behavior is the behavior of the machine the input represents.

 Some abstract idea that contradicts the semantics of the x86
programming language IS WRONG.
 I have had enough of your willful deception for one post.
 

If HH0 treats the input as having a different behavior, then HH0 just isn't a Halting Decider, but something else.
>
If HH0 is supposed to be a Halting decider, but uses a method that makes it see something other than that behavior, then it is just an incorrect Halting Decider, and its algorithm just creates an incorrect recreation of the property of the input it is supposed to be working on.
>
>
A bit of a side note, the actual "Input" to HH0, is a pointer to memory, and as such it passes a reference to ALL of memory considering the starting point to be that address, so your "Input" isn't actually the few bytes of DDD, but ALL of memory and a starting point. If you actually mean that the input is just those few bytes pointed to by the address, then the input is improperly formed and is NOT a proper representation of the input machine, becuase it is incomplete.
>
The fact you don't understand this, seems to imply you are lacking the basic knowledge to be talking about this sort of thing.
>