Re: The philosophy of computation reformulates existing ideas on a new basis --- EQUIVOCATION

On 11/2/24 9:33 PM, olcott wrote:

On 11/2/2024 8:22 PM, Richard Damon wrote:

On 11/2/24 9:00 PM, olcott wrote:

On 11/2/2024 7:52 PM, Richard Damon wrote:

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

On 11/2/2024 7:21 PM, Richard Damon wrote:

On 11/2/24 5:13 PM, olcott wrote:

On 11/2/2024 3:24 PM, Richard Damon wrote:

On 11/2/24 12:56 PM, olcott wrote:

On 11/2/2024 10:44 AM, Richard Damon wrote:

On 11/2/24 8:24 AM, olcott wrote:

>
When the main motive of people like Richard is to derail
any chance of mutual agreement I cannot proceed with all
of the steps achieving mutual agreement on each step one
at a time in their mandatory prerequisite order.

>
No, my "motive" is to hold cranks to the truth, or at least get them to admit that they are off in some other system, that they can define.
>
You keep on wanting to be in the system (since it provides the proof of the things you don't like) but can't hold yourself to actually be in the system.
>

>
void DDD()
{
   HHH(DDD);
   return;
}
>
_DDD()
[000020a2] 55         push ebp      ; housekeeping
[000020a3] 8bec       mov ebp,esp   ; housekeeping
[000020a5] 68a2200000 push 000020a2 ; push DDD
[000020aa] e8f3f9ffff call 00001aa2 ; call H0
[000020af] 83c404     add esp,+04   ; housekeeping
[000020b2] 5d         pop ebp       ; housekeeping
[000020b3] c3         ret           ; never gets here
Size in bytes:(0018) [000020b3]
>
DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not any HHH ever aborts its emulation of DDD.

>
Equivocation between looking at the behavor of DDD being the actual program (which include a particular version of HHH) and the behavior of a PARTIAL emulation of DDD by HHH, which ends up not having the property you want to show.
>
Partial doesn't lead to showing never.
>

>
In other words you continue to perpetually insist on
the ridiculously stupid idea of requiring the complete
emulation of a non-terminating input.
>
I don't think this is: stupidity, ignorance, ADD.
I don't know what this leaves besides dishonesty with malice.
>

>
No, you just need to know the RESULTS of the emulation of the input even if you emulate it for an unlimited number of steps.

>
Yes

>
So, you agree that the results of only the partial emulation done by HHH doesn't define the answer, only that of the infinte emulation OF THIS EXACT INPUT, defines the behavior, as shown by HHH1(DDD) which shows it halts.
>

You don't need to actually do it if you can prove what it would be.
>

>
*Yes and ChatGPT agrees*
>
<ChatGPT>
   Think of HHH as a "watchdog" that steps in during real
   execution to stop DDD() from running forever. But when
   HHH simulates DDD(), it's analyzing an "idealized" version
   of DDD() where nothing stops the recursion. In the simulation,
   DDD() is seen as endlessly recursive, so HHH concludes that
   it would not halt without external intervention.
</ChatGPT>
>
https://chatgpt.com/share/67158ec6-3398-8011-98d1-41198baa29f2

>
Just admitmits that HHH gets the wrong answer, because you lied, because the HHH that DDD calls will also abort and return to DDD, so DDD would halt.
>
Remember, you AGREED above that it is the behavior of the INFINITE emulation, not the finite emulation of HHH defines the answer.
>

>
A termination analyzer / halt decider must PREDICT
non terminating behavior not measure it.
>
If a termination analyzer / halt decider MEASURES
non-terminating behavior IT CANNOT REPORT THIS.
>

>

Of course, that is for this exact input, which uses the copy of H that does abort and return.
>

>
No it is not.
<ChatGPT>
   when HHH simulates DDD(), it's analyzing an
   "idealized" version of DDD() where nothing
   stops the recursion.
</ChatGPT>

>
In other words you are admitting that it isn't actually looking at the input it was given.
>

>
ChatGPT (using its own words) and I both agree that HHH
is supposed to predict the behavior of the infinite
emulation on the basis of its finite emulation.
>

>
Yes, but that behavior is DEFINED by the actual behavior of the actual machine.
>

>
No it is not. It is never based on the actual behavior
of the actual machine for any non-terminating inputs.

>
Then you don't undetstand the requirement for something to be a semantic property.
>

 The actual behavior specified by the finite string input
to HHH does include HHH emulating itself emulating DDD
such that this DD *not some other DDD somewhere else*
cannot possibly reach its own "return" instruction
whether HHH emulates DDD forever or some finite number
of times.

But, since the HHH that DDD calls DOES abort its emulation, that logic is INVALID.
We know it does, since you claim it it correct to do so.
So, either you are lying that it does it to be correct, or you are lying that DDD doesn't call THAT HHH, or you are lying that the input DDD even HAS the property of halting, as that only applies to PROGRAMS, which require it to have ALL the code used, and thus the input DDD includes the code of HHH, so you can't change it.

 

>
It has only ever been based on what this input would do
if its simulation was never aborted.

>
Right, which will be exactly what the input will do when run.
>
It also means not by changing the copy of the decider the input calls, as then it its the input it was given.
>
If you want to change these properties, you need to first fully define what you mean by the terms, and show they still meet the basic requirement needed for this things.
>

>

Only a knucklehead would think that HHH is supposed
to actually measure infinite behavior.

>
But it needs to actually prove that it would occur before it can claim it.
>

>
In other words that fact that DDD emulated by HHH would never
stop running unless aborted is over your head?

>
But since the HHH that DDD calls DOES aborr, that is a vacous statement.
>
The unaborted emulation of the input given to HHH will reach a final state it HHH aborts its emulation, and thus gives up its claim to be defining the semantic property.
>

>
I can see this, Ben can see this and ChatGPT understands it
so well that it can use entirely different words to explain
exactly how it sees this.
>

>
Nope, If you look carefully at what Ben agreed to was if you define the NON-SEMANTIC property that you have been trying to define, your decider can be a correct POOP decider. (of course, you can't look that closely as you don't undetstand what you have been talking about).
>

 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, he is pointing out that your NON-PROGRAM P, (since the input doesn't include the code for H) forms a template with H that creates a result that P will not halt unless H aborts.
Since the Halting problem is about Programs, and not Non-Programs, it doesn't say anything about the real halting problem.

 The semantic property of this finite string does specify
that HHH must emulate itself emulating DDD.

And, since HHH fails to do that, it can't use its own simulation as a measure of the real halting property, so either HHH just isn't a halt decider.
If your requriement is that HHH is defined to emulate DDD to determine its behavior, it just isn't allowed to abort its emulation until that behavior has been correctly determined. And, if HHH aborts its emulation, that behavior depends on what DDD does after HHH returns to it, so it can't know by your algorithm, and thus to meet your stated requirement, your HHH just isn't allowed to abort its emulation.
Since HHH doesn't meet the stated requirements for your HHH, your logic is just a LIE.
Remember, a semantic property is based on the determination of the actual final behavior of that input (not the results of an aborted emulation), thus if HHH does abort it emulation, the semantic property is what happens with that exact same input (and thus the exact same code of HHH that did that aborting) given to a complete emulator, (like HHH1), which shows that the input WILL halt, therefore HHH was wrong to abort, and thus failed to meet its requirements.

 The direct execution of DDD DOES NOT SPECIFY THAT.

Sure it does. HHH must do what HHH does. That is the requirement in both cases. It requires that the HHH that it calls do EXACTLY the same thing as the HHH that looked at it, and conversly, the HHH that is analysing this input needs to treat the call to itself as behaving like it will, even if it doesn't realize it is actually itself.
Thus, your "rule" that tries to detect infinite recursion is incorrect, as it has a false positive when HHH thinks that the HHH that it is emulating will not return, when the correct (and thus complete) emulation of that code shows that it will.

 

He NEVER agree that your decider was a correct Halt Decider.
>

 *He did agree that H does meet the first half of this criteria*

Nope, because here D is a program, and thus includes the code for H, so the H that aborts can't claim that its D is non-halting.

 <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>