Re: Hypothetical possibilities --- Complete Proof --- halt state

On 8/2/2024 11:32 PM, Jeff Barnett wrote:

On 8/2/2024 7:19 PM, Mike Terry wrote:

On 02/08/2024 23:42, Ben Bacarisse wrote:

Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>

Of course these traces don't support PO's overall case he is claiming,
because the (various) logs show that DDD halts, and that HHH(DDD) reports
DDD as non-halting, exactly as Linz/Sipser argue. Er, that's about it!

>
PO certainly used to claim that false (non-halting) is the correct
result "even though DDD halts" (I've edited the quote to reflect a name
change).  Unless he's changed this position, the traces do support his
claim that what everyone else calls the wrong answer is actually the
right one.
>

>
So, in your opinion, what do you believe is PO's criterion for "correct result", exactly?  It would be handy if you can give a proper mathematical definition so nobody will have any doubt what it is. Hey, I know you're more than capable of getting a definition right, so let's have that definition!
>
Definition:  A TM P given input I is said to "halt" iff ?????
              or whatever...

 I think this is a rather hopeless venture without formally defining the representation of a TM. For example: In some formulations, there are specific states defined as "halting states" and the machine only halts if either the start state is a halt state or there is a transition to a halt state within the execution trace;

*This turned out to be very helpful, thanks*
It may unify the honest people into Ben's agreement with the
first part of the Professor Sipser approved criteria.
<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>
void DDD()
{
   HHH(DDD);
   return;
}
*Anyone that knows C should agree that*
DDD correctly emulated by any HHH that can possibly exist
cannot possibly reach its own "return" instruction.
That only gets people to accept the first half of the Sipser
approved criteria and see what Ben sees.
When we add the this "return" instruction is your above
mentioned "halt state" things get much clearer. Then
we might begin to see:
HHH computes the mapping from its input finite string of x86
machine code... to the above behavior that does not halt.

In another formulation, machines halt if there is a transition to an undefined state. Note a few things: 1) the if's above are really iff's, 2) these and many other definitions all have equivalent computing prowess, 3) Some formulations define results by what is left on the tape (or other storage device) while others add the actual halting state to determine the results.
 In a conversation about such topics, gentlemen of good faith and reasonable knowledge can simple ignore these differences and not go off the rails. This is not true when the pied piper is ignorant, disillusional, and masturbating while simultaneously spinning a hula hoop around his neck.
 

It's easy enough to say "PO has his own criterion for halting, which is materially different from the HP condition, and so we all agree PO is correct by his own criterion, but that does not say anything about the HP theorem because it is different from the HP definition".
>
But is that /really/ something PO agrees with?  I don't think so somehow, because I'm pretty sure PO believes his claim "refutes" the HP result.  He wouldn't say that if he freely acknowleded that he had invented a completely different definition for halting.  Also, for what you're saying to be the right way of looking at things, PO would have to admit that the HP proof with its standard definition of halting is valid, and that there is nothing wrong with the Linz proof, other than it not applying to his own favourite PO-halting definition.
>
I.e. I think your way of looking at it is a bit "too easy" - but I'd be happy to be convinced! Personally I suspect PO has no such "new and different definition" and that anything along those lines PO is thinking of will be quite incoherent.  No doubt you could make some definition that is at least coherent but we have to ask ourselves - is that definition /really/ what PO is thinking???
>
Nowadays, I think PO's position is more that:
-  yes, DDD() halts when run directly
-  but DDD() when it runs inside HHH simulator /really/ does not halt, in some kind of
    sense that it /really/ has infinite recursion which would never end
    however far it was simulated (because it "exhibits" infinite recursion in some way)
-  and yes, DDD() /does/ halt when simulated within UTM(DDD),
-  but the behaviour of DDD depends on who is simulating it.  It terminates when
    UTM simulates it, but doesn't terminate when HHH simulates it, due to some
    kind of pathelogical relationship specifically with HHH.  This difference in
    simulation is /more/ than one simulator aborting earlier than the other...--

Jeff Barnett
 

--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer