Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.theory > #104615 > unrolled thread

Re: Linz's proofs and other undecidable decision problems [LP as basis] [Mike Terry]

Back to article view | Back to comp.theory

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Linz's proofs and other undecidable decision problems [LP as basis] [Mike Terry] olcott <polcott333@gmail.com> - 2024-05-10 13:16 -0500
    Re: Linz's proofs and other undecidable decision problems [LP as basis] [Mike Terry] Mikko <mikko.levanto@iki.fi> - 2024-05-11 11:00 +0300
      Re: Linz's proofs and other undecidable decision problems [LP as basis] [Mike Terry] olcott <polcott333@gmail.com> - 2024-05-11 11:06 -0500
        Re: Linz's proofs and other undecidable decision problems [LP as basis] [Mike Terry] Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2024-05-11 17:32 +0100
          Re: Linz's proofs and other undecidable decision problems [LP as basis] [Mike Terry](apology) olcott <polcott333@gmail.com> - 2024-05-11 12:04 -0500
        Re: Linz's proofs and other undecidable decision problems [LP as basis] [Mike Terry] Richard Damon <richard@damon-family.org> - 2024-05-11 12:46 -0400
          Re: Linz's proofs and other undecidable decision problems [LP as basis] [Mike Terry] olcott <polcott333@gmail.com> - 2024-05-11 12:19 -0500
            Re: Linz's proofs and other undecidable decision problems [LP as basis] [Mike Terry] olcott <polcott333@gmail.com> - 2024-05-11 15:16 -0500
              Re: Linz's proofs and other undecidable decision problems [LP as basis] [Mike Terry] Richard Damon <richard@damon-family.org> - 2024-05-11 19:24 -0400
            Re: Linz's proofs and other undecidable decision problems [LP as basis] [Mike Terry] Richard Damon <richard@damon-family.org> - 2024-05-11 19:25 -0400
        Re: Linz's proofs and other undecidable decision problems [LP as basis] [Mike Terry] olcott <polcott333@gmail.com> - 2024-05-12 09:18 -0500
          Re: Linz's proofs and other undecidable decision problems [LP as basis] [Mike Terry] Mikko <mikko.levanto@iki.fi> - 2024-05-12 18:14 +0300
            Re: Linz's proofs and other undecidable decision problems [LP as basis] [Mike Terry] olcott <polcott333@gmail.com> - 2024-05-12 11:53 -0500
              Re: Linz's proofs and other undecidable decision problems [LP as basis] [Mike Terry] Richard Damon <richard@damon-family.org> - 2024-05-12 13:07 -0400
              Re: Linz's proofs and other undecidable decision problems [LP as basis] [Mike Terry] Mikko <mikko.levanto@iki.fi> - 2024-05-13 11:09 +0300
          Re: Linz's proofs and other undecidable decision problems [LP as basis] [Mike Terry] Richard Damon <richard@damon-family.org> - 2024-05-12 12:57 -0400

#104615 — Re: Linz's proofs and other undecidable decision problems [LP as basis] [Mike Terry]

On 3/1/2024 12:41 PM, Mike Terry wrote:
> On 01/03/2024 17:55, olcott wrote:
>> On 3/1/2024 11:42 AM, Mike Terry wrote:
>>> On 01/03/2024 06:14, olcott wrote:
>>>> On 2/29/2024 10:18 PM, Richard Damon wrote:
>>>>> On 2/29/24 10:42 PM, olcott wrote:
>>>>>> On 2/29/2024 8:28 PM, Richard Damon wrote:
>>>>>>> On 2/29/24 5:29 PM, olcott wrote:
>>>>>>>> On 2/29/2024 4:24 PM, wij wrote:
>>>>>>>>> On Thu, 2024-02-29 at 16:13 -0600, olcott wrote:
>>>>>>>>>> On 2/29/2024 4:06 PM, wij wrote:
>>>>>>>>>>> On Thu, 2024-02-29 at 15:59 -0600, olcott wrote:
>>>>>>>>>>>> On 2/29/2024 3:50 PM, wij wrote:
>>>>>>>>>>>>> On Thu, 2024-02-29 at 15:27 -0600, olcott wrote:
>>>>>>>>>>>>>> On 2/29/2024 3:15 PM, wij wrote:
>>>>>>>>>>>>>>> On Thu, 2024-02-29 at 15:07 -0600, olcott wrote:
>>>>>>>>>>>>>>>> On 2/29/2024 3:00 PM, wij wrote:
>>>>>>>>>>>>>>>>> On Thu, 2024-02-29 at 14:51 -0600, olcott wrote:
>>>>>>>>>>>>>>>>>> On 2/29/2024 2:48 PM, wij wrote:
>>>>>>>>>>>>>>>>>>> On Thu, 2024-02-29 at 13:46 -0600, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 2/29/2024 1:37 PM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>> On 2024-02-29 15:51:56 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ (in a separate memory space) merely 
>>>>>>>>>>>>>>>>>>>>>> needs to report on
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> A Turing machine is not in any memory space.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> That no memory space is specified because Turing 
>>>>>>>>>>>>>>>>>>>> machines
>>>>>>>>>>>>>>>>>>>> are imaginary fictions does not entail that they 
>>>>>>>>>>>>>>>>>>>> have no
>>>>>>>>>>>>>>>>>>>> memory space. The actual memory space of actual Turing
>>>>>>>>>>>>>>>>>>>> machines is the human memory where these ideas are 
>>>>>>>>>>>>>>>>>>>> located.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The entire notion of undecidability when it depends on
>>>>>>>>>>>>>>>>>>>> epistemological antinomies is incoherent.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> People that learn these things by rote never notice 
>>>>>>>>>>>>>>>>>>>> this.
>>>>>>>>>>>>>>>>>>>> Philosophers that examine these things looking for
>>>>>>>>>>>>>>>>>>>> incoherence find it.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ...14 Every epistemological antinomy can likewise be 
>>>>>>>>>>>>>>>>>>>> used
>>>>>>>>>>>>>>>>>>>> for a similar undecidability proof...(Gödel 1931:43)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> So, do you agree what GUR says?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> People believes GUR. Why struggle so painfully, 
>>>>>>>>>>>>>>>>>>> playing idiot everyday ?
>>>>>>>>>>>>>>>>>>> Give in, my friend.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Graphical User Robots?
>>>>>>>>>>>>>>>>>> The survival of the species depends on a correct 
>>>>>>>>>>>>>>>>>> understanding of truth.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> People believes GUR are going to survive.
>>>>>>>>>>>>>>>>> People does not believe GUR are going to vanish.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> What the Hell is GUR ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Selective memory?
>>>>>>>>>>>>>>> https://groups.google.com/g/comp.theory/c/_tbCYyMox9M/m/XgvkLGOQAwAJ
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Basically, GUR says that no one even your god can defy 
>>>>>>>>>>>>>>> that HP is undecidable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I simplify that down to this.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ...14 Every epistemological antinomy can likewise be used for
>>>>>>>>>>>>>> a similar undecidability proof...(Gödel 1931:43)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The general notion of decision problem undecidability is 
>>>>>>>>>>>>>> fundamentally
>>>>>>>>>>>>>> flawed in all of those cases where a decider is required 
>>>>>>>>>>>>>> to correctly
>>>>>>>>>>>>>> answer a self-contradictory (thus incorrect) question.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When we account for this then epistemological antinomies 
>>>>>>>>>>>>>> are always
>>>>>>>>>>>>>> excluded from the domain of every decision problem making 
>>>>>>>>>>>>>> all of
>>>>>>>>>>>>>> these decision problems decidable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> It seems you try to change what the halting problem again.
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>>> In computability theory, the halting problem is the problem 
>>>>>>>>>>>>> of determining, from a description
>>>>>>>>>>>>> of
>>>>>>>>>>>>> an
>>>>>>>>>>>>> arbitrary computer program and an input, whether the 
>>>>>>>>>>>>> program will finish running, or continue
>>>>>>>>>>>>> to
>>>>>>>>>>>>> run
>>>>>>>>>>>>> forever....
>>>>>>>>>>>>>
>>>>>>>>>>>>> This wiki definition had been shown many times. But, since 
>>>>>>>>>>>>> your English is
>>>>>>>>>>>>> terrible, you often read it as something else (actually, 
>>>>>>>>>>>>> deliberately
>>>>>>>>>>>>> interpreted it differently, so called 'lie')
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you want to refute Halting Problem, you must first 
>>>>>>>>>>>>> understand what the
>>>>>>>>>>>>> problem is about, right? You never hit the target that 
>>>>>>>>>>>>> every one can see, but POOP.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Note: My email was delivered strangely. It swapped to 
>>>>>>>>>>> sci.logic !!!
>>>>>>>>>>>
>>>>>>>>>>>> If we have the decision problem that no one can answer this 
>>>>>>>>>>>> question:
>>>>>>>>>>>> Is this sentence true or false: "What time is it?"
>>>>>>>>>>>
>>>>>>>>>>> This is not the halting problem.
>>>>>>>>>>>
>>>>>>>>>>>> Someone has to point out that there is something wrong with it.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This is another problem (not the HP neither)
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The halting problem is one of many problems that is
>>>>>>>>>> only "undecidable" because the notion of decidability
>>>>>>>>>> incorrectly requires a correct answer to a self-contradictory
>>>>>>>>>> (thus incorrect) question.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> What is the 'correct answer' to all HP like problems ?
>>>>>>>>>
>>>>>>>>
>>>>>>>> The correct answer to all undecidable decision problems
>>>>>>>> that rely on self-contradictory input to determine
>>>>>>>> undecidability is to reject this input as outside of the
>>>>>>>> domain of any and all decision problems. This applies
>>>>>>>> to the Halting Problem and many others.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> In other words, just define that some Turing Machines aren't 
>>>>>>> actually Turing Machines, or aren't Turing Machines if they are 
>>>>>>> given certain inputs.
>>>>>>>
>>>>>>
>>>>>> No not at all simply make a Turing Machine that does this:
>>>>>>
>>>>>> LP = "This sentence is not true."
>>>>>> Boolean True(English, LP)  is false
>>>>>> Boolean True(English, ~LP) is false
>>>>>
>>>>> In other words, you are admitting that you havve absolutly NO idea 
>>>>> what a Turing Machine is, and what it can do.
>>>>>
>>>>
>>>> Not at all this is the high level architectural design of
>>>> a system that could be implemented as a Turing machine.
>>>>
>>>>> You don't even seem to understand what you need to do to program 
>>>>> something.
>>>>
>>>> That is proven to be ridiculous by my fully operational code.
>>>> that created the x86utm operating system entirely out of an
>>>> excellent x86 emulator. It was very tricky to get HH to simulate
>>>> itself to an arbitrary recursive depth.
>>>
>>> BUT....  Your HH code is completely broken!
>>>
>>> It uses static variables like execution_trace shared across 
>>> simulations.  The effect of this is that nested simulations see (and 
>>> actively examine as part of their decision logic) trace entries from 
>>> parent simulators.  A valid simulation cannot do that - your program 
>>> logic is Wrong.
>>
>> (1) This is moot.
>> (2) A UTM can share a portion of its own tape with the machine that it
>> is simulating so that it can see this machines own internal data.
>>
>>> I thought you had claimed to have fixed that problem, and you 
>>> certainly never corrected me when I mentioned that I thought you had 
>>> fixed it in an earlier post.  It seems you never fixed it, SO IT'S 
>>> STILL BROKEN.
>>>
>>
>> H is able to correctly determine that D is calling itself thus
>> no need for the UTM to share a portion of its own tape with
>> the machine that it is simulating.
>>
>>> What you did instead, it seems, was change from using HH to using H, 
>>> the latter not requiring nested simulation to work as intended.  And 
>>> yet you still throw out references to your "HH using nested 
>>> simulation" and "arbitrary recursive depth" as though you had 
>>> actually fixed it - very dishonest of you.
>>>
>>
>> Not the slightest little bit. The original H was renamed to HH.
>> Because a UTM actually can share a portion of its own tape with
>> the machine it is simulating HH may actually be the preferred version.
> 
> Obviously a simulator has access to the internal state (tape contents 
> etc.) of the simulated machine.  No problem there.
> 
> What isn't allowed is the simulated machine altering its own behaviour 
> by accessing data outside of its own state.  (I.e. accessing data from 
> its parent simulators state.)
> 
> While an "active-simulator" [my own term] is at liberty to combine 
> straight simulation with add-on "enhancements" that extend the 
> functionality of the simulated machine, 

> in doing so it would no longer 
> be a simulator in the sense you need it to be.  So you mustn't do this!
> 

*You did not provide complete reasoning justifying this proclamation*
*You did not provide complete reasoning justifying this proclamation*
*You did not provide complete reasoning justifying this proclamation*

Because the simulator must perform every detail of the simulation of
the underlying machine it can watch every single state change of this
underlying machine and this does not change the behavior of the
simulated input AT ALL (relative to not watching the state changes).

> You need the simulator to prove claims you are making about the logic of 
> Linz's proof being faulty. More directly, you want to say that
> a)  your H/H^ "follow the pattern of Linz's proof",
> b)  so that the logic in Linz's proof informs us that H should decide 
> input (H^,H^) incorrectly
> c)  yet YOUR H actually decides input (H^,H^) CORRECTLY.
> d)  [so Linz's logic is wrong, somewhere]
> But the Linz proof relies on the copy of H within H^ [let's call that 
> Hcopy] faithfully mirroring the computation and result produced by H, 
> for any given input.  That's obvious (although apparently not to you!) 
> when applied to TMs, which is all Linz is concerned with.
> 
> IF you make your "simulation" into an "active-simulation" where the 
> simulator changes the computation dynamically in AMY way [e.g. by 
> leaking external data into the simulation], then the "faithful 
> mirroring" Linz assumption will be broken, so the Linz conclusion need 
> not apply in your environments.  But you NEED the Li^nz logic to apply 
> otherwise you can't conclude that logic is wrong in (d) above.  If the 
> Linz logic /doesn't apply/ then your H/H^ is not a counter-example 
> because it is not "counter" to Linz.
> 
> It is not a question of whether a TM "actively" simulating something can 
> dynamically amend the "simulation" behaviour - the point is that Hcopy 
> within H^ is NOT SUCH AN "ENHANCED" SIMULATION - it is an "exact copy" 
> of H logic, up to the two final H states.
> 
> I appreciate all the above is rather "abstract" for you.  But anyhow, 
> rather than trying to argue the problem away, why not just code it 
> correctly in the first place?  And meanwhile stop claiming anything 
> about your HH handling "arbitrary recursive depth" and the like.
> 
>>
>>> The "examination of traces from nested simulations" was one of the 
>>> trickier coding problems you faced in creating x86utm, and you FAILED 
>>> at that challenge. 
>>
>> Not at all. I found out the the reason these x86 emulations
>> were crashing is the each instance required its own stack.
>>
>>> The funny thing is, the problem was actually not that hard at all 
>>> [i.e. hours work rather than days/weeks], and I would expect 
>>> practically everyone on this group woud have come up with a correct 
>>> working approach where you messed it up.
>>>
>>>
>>> Mike.
>>>
>>
>> I think that I correctly rebutted your rebuttal yet here
>> is why your rebuttal is moot.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn     // Ĥ applied to ⟨Ĥ⟩ does not halt
>>
>> Ĥ contradicts Ĥ.H and does not contradict H, thus H
>> is able to correctly decide ⟨Ĥ⟩ ⟨Ĥ⟩.
>>
>> As long as some computable criteria exists for Ĥ.H to transition
>> to Ĥ.Hqy or Ĥ.Hqn, then H has its basis to correctly decide ⟨Ĥ⟩ ⟨Ĥ⟩.
>>
>> H simply looks for whatever wrong answer that Ĥ.H returns and
>> reports on the halting or not halting behavior of that.
> 
> Dude!  :(
> 
> Can you really not see what's wrong with your suggestion???
> 
> Well, if really not, then I guess you can quickly amend your x86utm 
> project to implement a new version of H that works exactly as your 
> suggesting.  Please post the usual traces showing such an H in action!  
> [..and you will quickly see why your idea doesn't work.]
> 
> Mike.
> 

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

[toc] | [next] | [standalone]

#104665

On 2024-05-10 18:16:37 +0000, olcott said:

> On 3/1/2024 12:41 PM, Mike Terry wrote:

>> Obviously a simulator has access to the internal state (tape contents 
>> etc.) of the simulated machine.  No problem there.
>> 
>> What isn't allowed is the simulated machine altering its own behaviour 
>> by accessing data outside of its own state.  (I.e. accessing data from 
>> its parent simulators state.)
>> 
>> While an "active-simulator" [my own term] is at liberty to combine
>> straight simulation with add-on "enhancements" that extend the
>> functionality of the simulated machine, in doing so it would no
>> longer be a simulator in the sense you need it to be.  So you
>> mustn't do this!

In principle an incorrect simulation is permissible. However, to prove
that the result inferred from an incorrect simulation is correct may
be impossible.

> *You did not provide complete reasoning justifying this proclamation*
> *You did not provide complete reasoning justifying this proclamation*
> *You did not provide complete reasoning justifying this proclamation*

The provided reasoning is sufficient. You can continue reasoning from
that if you want more.

> Because the simulator must perform every detail of the simulation of
> the underlying machine it can watch every single state change of this
> underlying machine and this does not change the behavior of the
> simulated input AT ALL (relative to not watching the state changes).

Yes, that is a correct interpretation.

-- 
Mikko

[toc] | [prev] | [next] | [standalone]

#104678

On 5/11/2024 3:00 AM, Mikko wrote:
> On 2024-05-10 18:16:37 +0000, olcott said:
> 
>> On 3/1/2024 12:41 PM, Mike Terry wrote:
> 
>>> Obviously a simulator has access to the internal state (tape contents 
>>> etc.) of the simulated machine.  No problem there.
>>>
>>> What isn't allowed is the simulated machine altering its own 
>>> behaviour by accessing data outside of its own state.  (I.e. 
>>> accessing data from its parent simulators state.)
>>>
>>> While an "active-simulator" [my own term] is at liberty to combine
>>> straight simulation with add-on "enhancements" that extend the
>>> functionality of the simulated machine, in doing so it would no
>>> longer be a simulator in the sense you need it to be.  So you
>>> mustn't do this!
> 
> In principle an incorrect simulation is permissible. However, to prove
> that the result inferred from an incorrect simulation is correct may
> be impossible.
> 

Within the conventional terms-of-the-art of {termination analyzer}
and {simulator} an incorrect simulation is forbidden.

>> *You did not provide complete reasoning justifying this proclamation*
>> *You did not provide complete reasoning justifying this proclamation*
>> *You did not provide complete reasoning justifying this proclamation*
> 
> The provided reasoning is sufficient. You can continue reasoning from
> that if you want more.
> 

*He is SIMPLY WRONG and when he tries*
*to justify what he said he will fail*

Any pure x86 emulator or UTM can have the added functionality
of watching every state change of its simulated input without
changing the simulated steps of this input relative to an
unmodified x86 emulator or UTM.

*SO MIKE TERRY IS SIMPLY WRONG ABOUT THIS*

>> Because the simulator must perform every detail of the simulation of
>> the underlying machine it can watch every single state change of this
>> underlying machine and this does not change the behavior of the
>> simulated input AT ALL (relative to not watching the state changes).
> 
> Yes, that is a correct interpretation.
> 

OK Great!
So a simulating termination analyzer could watch the behavior of its
input and analyze this watched behavior and transition to a non-final
state that indicates non-halting and then go back and continue
simulating the non-halting input and it remains a simulator all along.

*This would not be a halt decider because all deciders must halt*
*It would be an unconventional termination analyzer*

*It does correctly report that its pathological input never halts*

*This method does work correctly on the H/D template*
*and the Ĥ applied to ⟨Ĥ⟩ template shown below*

00 int H(ptr x, ptr x)  // ptr is pointer to int function
01 int D(ptr x)
02 {
03   int Halt_Status = H(x, x);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }
08
09 int main()
10 {
11   H(D,D);
12 }

When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

*Termination Analyzer H is Not Fooled by Pathological Input D*
https://www.researchgate.net/publication/369971402_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D 


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

[toc] | [prev] | [next] | [standalone]

#104681

On 11/05/2024 17:06, olcott wrote:
> On 5/11/2024 3:00 AM, Mikko wrote:
>> On 2024-05-10 18:16:37 +0000, olcott said:
>>
>>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>>
>>>> Obviously a simulator has access to the internal state (tape contents etc.) of the simulated 
>>>> machine.  No problem there.
>>>>
>>>> What isn't allowed is the simulated machine altering its own behaviour by accessing data outside 
>>>> of its own state.  (I.e. accessing data from its parent simulators state.)
>>>>
>>>> While an "active-simulator" [my own term] is at liberty to combine
>>>> straight simulation with add-on "enhancements" that extend the
>>>> functionality of the simulated machine, in doing so it would no
>>>> longer be a simulator in the sense you need it to be.  So you
>>>> mustn't do this!
>>
>> In principle an incorrect simulation is permissible. However, to prove
>> that the result inferred from an incorrect simulation is correct may
>> be impossible.
>>
> 
> Within the conventional terms-of-the-art of {termination analyzer}
> and {simulator} an incorrect simulation is forbidden.
> 
>>> *You did not provide complete reasoning justifying this proclamation*
>>> *You did not provide complete reasoning justifying this proclamation*
>>> *You did not provide complete reasoning justifying this proclamation*
>>
>> The provided reasoning is sufficient. You can continue reasoning from
>> that if you want more.
>>
> 
> *He is SIMPLY WRONG and when he tries*
> *to justify what he said he will fail*
> 
> Any pure x86 emulator or UTM can have the added functionality
> of watching every state change of its simulated input without
> changing the simulated steps of this input relative to an
> unmodified x86 emulator or UTM.
> 
> *SO MIKE TERRY IS SIMPLY WRONG ABOUT THIS*

Idiot.


> 
>>> Because the simulator must perform every detail of the simulation of
>>> the underlying machine it can watch every single state change of this
>>> underlying machine and this does not change the behavior of the
>>> simulated input AT ALL (relative to not watching the state changes).
>>
>> Yes, that is a correct interpretation.
>>
> 
> OK Great!
> So a simulating termination analyzer could watch the behavior of its
> input and analyze this watched behavior and transition to a non-final
> state that indicates non-halting and then go back and continue
> simulating the non-halting input and it remains a simulator all along.
> 
> *This would not be a halt decider because all deciders must halt*
> *It would be an unconventional termination analyzer*
> 
> *It does correctly report that its pathological input never halts*
> 
> *This method does work correctly on the H/D template*
> *and the Ĥ applied to ⟨Ĥ⟩ template shown below*
> 
> 00 int H(ptr x, ptr x)  // ptr is pointer to int function
> 01 int D(ptr x)
> 02 {
> 03   int Halt_Status = H(x, x);
> 04   if (Halt_Status)
> 05     HERE: goto HERE;
> 06   return Halt_Status;
> 07 }
> 08
> 09 int main()
> 10 {
> 11   H(D,D);
> 12 }
> 
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> 
> *Termination Analyzer H is Not Fooled by Pathological Input D*
> https://www.researchgate.net/publication/369971402_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D 
> 
> 

[toc] | [prev] | [next] | [standalone]

#104687 — Re: Linz's proofs and other undecidable decision problems [LP as basis] [Mike Terry](apology)

On 5/11/2024 11:32 AM, Mike Terry wrote:
> On 11/05/2024 17:06, olcott wrote:
>> On 5/11/2024 3:00 AM, Mikko wrote:
>>> On 2024-05-10 18:16:37 +0000, olcott said:
>>>
>>>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>>>
>>>>> Obviously a simulator has access to the internal state (tape 
>>>>> contents etc.) of the simulated machine.  No problem there.
>>>>>
>>>>> What isn't allowed is the simulated machine altering its own 
>>>>> behaviour by accessing data outside of its own state.  (I.e. 
>>>>> accessing data from its parent simulators state.)
>>>>>
>>>>> While an "active-simulator" [my own term] is at liberty to combine
>>>>> straight simulation with add-on "enhancements" that extend the
>>>>> functionality of the simulated machine, in doing so it would no
>>>>> longer be a simulator in the sense you need it to be.  So you
>>>>> mustn't do this!
>>>
>>> In principle an incorrect simulation is permissible. However, to prove
>>> that the result inferred from an incorrect simulation is correct may
>>> be impossible.
>>>
>>
>> Within the conventional terms-of-the-art of {termination analyzer}
>> and {simulator} an incorrect simulation is forbidden.
>>
>>>> *You did not provide complete reasoning justifying this proclamation*
>>>> *You did not provide complete reasoning justifying this proclamation*
>>>> *You did not provide complete reasoning justifying this proclamation*
>>>
>>> The provided reasoning is sufficient. You can continue reasoning from
>>> that if you want more.
>>>
>>
>> *He is SIMPLY WRONG and when he tries*
>> *to justify what he said he will fail*
>>
>> Any pure x86 emulator or UTM can have the added functionality
>> of watching every state change of its simulated input without
>> changing the simulated steps of this input relative to an
>> unmodified x86 emulator or UTM.
>>
>> *SO MIKE TERRY IS SIMPLY WRONG ABOUT THIS*
> 
> Idiot.
> 

Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk>
On 3/1/2024 12:41 PM, Mike Terry wrote:
 > While an "active-simulator" [my own term] is at liberty
 > to combine straight simulation with add-on "enhancements"
 > that extend the functionality of the simulated machine,
 > in doing so it would no longer be a simulator in the sense
 > you need it to be.  So you mustn't do this!

When none of these add-on enhancements change behavior of the
simulated machine relative to a pure simulation of these same
inputs then the resulting machine remains a simulator even with
add-on enhancements.

Now that I have re-read what you said many times I noticed
nuances that I did not notice before.

*extend the functionality of the simulated machine*
does not refer to the simulator as I previously thought.

So it is my mistake. I apologize for mischaracterizing
what you said. This was unintentional.

>>
>>>> Because the simulator must perform every detail of the simulation of
>>>> the underlying machine it can watch every single state change of this
>>>> underlying machine and this does not change the behavior of the
>>>> simulated input AT ALL (relative to not watching the state changes).
>>>
>>> Yes, that is a correct interpretation.
>>>
>>
>> OK Great!
>> So a simulating termination analyzer could watch the behavior of its
>> input and analyze this watched behavior and transition to a non-final
>> state that indicates non-halting and then go back and continue
>> simulating the non-halting input and it remains a simulator all along.
>>
>> *This would not be a halt decider because all deciders must halt*
>> *It would be an unconventional termination analyzer*
>>
>> *It does correctly report that its pathological input never halts*
>>
>> *This method does work correctly on the H/D template*
>> *and the Ĥ applied to ⟨Ĥ⟩ template shown below*
>>
>> 00 int H(ptr x, ptr x)  // ptr is pointer to int function
>> 01 int D(ptr x)
>> 02 {
>> 03   int Halt_Status = H(x, x);
>> 04   if (Halt_Status)
>> 05     HERE: goto HERE;
>> 06   return Halt_Status;
>> 07 }
>> 08
>> 09 int main()
>> 10 {
>> 11   H(D,D);
>> 12 }
>>
>> When Ĥ is applied to ⟨Ĥ⟩
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> *Termination Analyzer H is Not Fooled by Pathological Input D*
>> https://www.researchgate.net/publication/369971402_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
>>

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

[toc] | [prev] | [next] | [standalone]

#104683

On 5/11/24 12:06 PM, olcott wrote:
> On 5/11/2024 3:00 AM, Mikko wrote:
>> On 2024-05-10 18:16:37 +0000, olcott said:
>>
>>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>>
>>>> Obviously a simulator has access to the internal state (tape 
>>>> contents etc.) of the simulated machine.  No problem there.
>>>>
>>>> What isn't allowed is the simulated machine altering its own 
>>>> behaviour by accessing data outside of its own state.  (I.e. 
>>>> accessing data from its parent simulators state.)
>>>>
>>>> While an "active-simulator" [my own term] is at liberty to combine
>>>> straight simulation with add-on "enhancements" that extend the
>>>> functionality of the simulated machine, in doing so it would no
>>>> longer be a simulator in the sense you need it to be.  So you
>>>> mustn't do this!
>>
>> In principle an incorrect simulation is permissible. However, to prove
>> that the result inferred from an incorrect simulation is correct may
>> be impossible.
>>
> 
> Within the conventional terms-of-the-art of {termination analyzer}
> and {simulator} an incorrect simulation is forbidden.


 From what definitions.

I would say that based on the definition of simulation that you imply 
you are using (by the using of it to bridge from the behavior of the 
program to the simlulation of the program) ALL your H that answer about 
D have used an "incorrect" simulation.

> 
>>> *You did not provide complete reasoning justifying this proclamation*
>>> *You did not provide complete reasoning justifying this proclamation*
>>> *You did not provide complete reasoning justifying this proclamation*
>>
>> The provided reasoning is sufficient. You can continue reasoning from
>> that if you want more.
>>
> 
> *He is SIMPLY WRONG and when he tries*
> *to justify what he said he will fail*
> 
> Any pure x86 emulator or UTM can have the added functionality
> of watching every state change of its simulated input without
> changing the simulated steps of this input relative to an
> unmodified x86 emulator or UTM.
> 
> *SO MIKE TERRY IS SIMPLY WRONG ABOUT THIS*
> 
>>> Because the simulator must perform every detail of the simulation of
>>> the underlying machine it can watch every single state change of this
>>> underlying machine and this does not change the behavior of the
>>> simulated input AT ALL (relative to not watching the state changes).
>>
>> Yes, that is a correct interpretation.
>>
> 
> OK Great!
> So a simulating termination analyzer could watch the behavior of its
> input and analyze this watched behavior and transition to a non-final
> state that indicates non-halting and then go back and continue
> simulating the non-halting input and it remains a simulator all along.

HOw can you "return" the non-halting indication and then continue to run?

> 
> *This would not be a halt decider because all deciders must halt*
> *It would be an unconventional termination analyzer*

It wouldn't be a program by the normal definitions of a program.

> 
> *It does correctly report that its pathological input never halts*

Nope.

> 
> *This method does work correctly on the H/D template*
> *and the Ĥ applied to ⟨Ĥ⟩ template shown below*
> 
> 00 int H(ptr x, ptr x)  // ptr is pointer to int function
> 01 int D(ptr x)
> 02 {
> 03   int Halt_Status = H(x, x);
> 04   if (Halt_Status)
> 05     HERE: goto HERE;
> 06   return Halt_Status;
> 07 }
> 08
> 09 int main()
> 10 {
> 11   H(D,D);
> 12 }
> 
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> 
> *Termination Analyzer H is Not Fooled by Pathological Input D*
> https://www.researchgate.net/publication/369971402_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
> 

Nope, because the H you just described is not equivalent to a Turing 
Machine.

[toc] | [prev] | [next] | [standalone]

#104689

On 5/11/2024 11:46 AM, Richard Damon wrote:
> On 5/11/24 12:06 PM, olcott wrote:
>> On 5/11/2024 3:00 AM, Mikko wrote:
>>> On 2024-05-10 18:16:37 +0000, olcott said:
>>>
>>>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>>>
>>>>> Obviously a simulator has access to the internal state (tape 
>>>>> contents etc.) of the simulated machine.  No problem there.
>>>>>
>>>>> What isn't allowed is the simulated machine altering its own 
>>>>> behaviour by accessing data outside of its own state.  (I.e. 
>>>>> accessing data from its parent simulators state.)
>>>>>
>>>>> While an "active-simulator" [my own term] is at liberty to combine
>>>>> straight simulation with add-on "enhancements" that extend the
>>>>> functionality of the simulated machine, in doing so it would no
>>>>> longer be a simulator in the sense you need it to be.  So you
>>>>> mustn't do this!
>>>
>>> In principle an incorrect simulation is permissible. However, to prove
>>> that the result inferred from an incorrect simulation is correct may
>>> be impossible.
>>>
>>
>> Within the conventional terms-of-the-art of {termination analyzer}
>> and {simulator} an incorrect simulation is forbidden.
> 
> 
>  From what definitions.
> 
> I would say that based on the definition of simulation that you imply 
> you are using (by the using of it to bridge from the behavior of the 
> program to the simlulation of the program) ALL your H that answer about 
> D have used an "incorrect" simulation.
> 
>>
>>>> *You did not provide complete reasoning justifying this proclamation*
>>>> *You did not provide complete reasoning justifying this proclamation*
>>>> *You did not provide complete reasoning justifying this proclamation*
>>>
>>> The provided reasoning is sufficient. You can continue reasoning from
>>> that if you want more.
>>>
>>
>> *He is SIMPLY WRONG and when he tries*
>> *to justify what he said he will fail*
>>
>> Any pure x86 emulator or UTM can have the added functionality
>> of watching every state change of its simulated input without
>> changing the simulated steps of this input relative to an
>> unmodified x86 emulator or UTM.
>>
>> *SO MIKE TERRY IS SIMPLY WRONG ABOUT THIS*
>>
>>>> Because the simulator must perform every detail of the simulation of
>>>> the underlying machine it can watch every single state change of this
>>>> underlying machine and this does not change the behavior of the
>>>> simulated input AT ALL (relative to not watching the state changes).
>>>
>>> Yes, that is a correct interpretation.
>>>
>>
>> OK Great!
>> So a simulating termination analyzer could watch the behavior of its
>> input and analyze this watched behavior and transition to a non-final
>> state that indicates non-halting and then go back and continue
>> simulating the non-halting input and it remains a simulator all along.
> 
> HOw can you "return" the non-halting indication and then continue to run?
> 

D simulated by H could
(a) Watch all of the state changes of its input.
(b) Analyze these state changes.
(c) Correctly determine that its input would never halt.
(d) Continue to report that its input would never halt by
     transitioning to a special non-final state indicating this.

All the while remaining a pure simulator with extra features.

>>
>> *This would not be a halt decider because all deciders must halt*
>> *It would be an unconventional termination analyzer*
> 
> It wouldn't be a program by the normal definitions of a program.
> 
>>
>> *It does correctly report that its pathological input never halts*
> 
> Nope.
> 
>>
>> *This method does work correctly on the H/D template*
>> *and the Ĥ applied to ⟨Ĥ⟩ template shown below*
>>
>> 00 int H(ptr x, ptr x)  // ptr is pointer to int function
>> 01 int D(ptr x)
>> 02 {
>> 03   int Halt_Status = H(x, x);
>> 04   if (Halt_Status)
>> 05     HERE: goto HERE;
>> 06   return Halt_Status;
>> 07 }
>> 08
>> 09 int main()
>> 10 {
>> 11   H(D,D);
>> 12 }
>>
>> When Ĥ is applied to ⟨Ĥ⟩
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> *Termination Analyzer H is Not Fooled by Pathological Input D*
>> https://www.researchgate.net/publication/369971402_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
>>
> 
> Nope, because the H you just described is not equivalent to a Turing 
> Machine.

The exact same (a)(b)(c)(d) sequence of steps applies equally
to the Linz template:

When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

embedded_H is not a halt decider or even a conventional
{termination analyzer}, it is an unconventional {termination analyzer}
that does correctly report the halt status of its pathological input.


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

[toc] | [prev] | [next] | [standalone]

#104694

On 5/11/2024 12:19 PM, olcott wrote:
> On 5/11/2024 11:46 AM, Richard Damon wrote:
>> On 5/11/24 12:06 PM, olcott wrote:
>>> On 5/11/2024 3:00 AM, Mikko wrote:
>>>> On 2024-05-10 18:16:37 +0000, olcott said:
>>>>
>>>>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>>>>
>>>>>> Obviously a simulator has access to the internal state (tape 
>>>>>> contents etc.) of the simulated machine.  No problem there.
>>>>>>
>>>>>> What isn't allowed is the simulated machine altering its own 
>>>>>> behaviour by accessing data outside of its own state.  (I.e. 
>>>>>> accessing data from its parent simulators state.)
>>>>>>
>>>>>> While an "active-simulator" [my own term] is at liberty to combine
>>>>>> straight simulation with add-on "enhancements" that extend the
>>>>>> functionality of the simulated machine, in doing so it would no
>>>>>> longer be a simulator in the sense you need it to be.  So you
>>>>>> mustn't do this!
>>>>
>>>> In principle an incorrect simulation is permissible. However, to prove
>>>> that the result inferred from an incorrect simulation is correct may
>>>> be impossible.
>>>>
>>>
>>> Within the conventional terms-of-the-art of {termination analyzer}
>>> and {simulator} an incorrect simulation is forbidden.
>>
>>
>>  From what definitions.
>>
>> I would say that based on the definition of simulation that you imply 
>> you are using (by the using of it to bridge from the behavior of the 
>> program to the simlulation of the program) ALL your H that answer 
>> about D have used an "incorrect" simulation.
>>
>>>
>>>>> *You did not provide complete reasoning justifying this proclamation*
>>>>> *You did not provide complete reasoning justifying this proclamation*
>>>>> *You did not provide complete reasoning justifying this proclamation*
>>>>
>>>> The provided reasoning is sufficient. You can continue reasoning from
>>>> that if you want more.
>>>>
>>>
>>> *He is SIMPLY WRONG and when he tries*
>>> *to justify what he said he will fail*
>>>
>>> Any pure x86 emulator or UTM can have the added functionality
>>> of watching every state change of its simulated input without
>>> changing the simulated steps of this input relative to an
>>> unmodified x86 emulator or UTM.
>>>
>>> *SO MIKE TERRY IS SIMPLY WRONG ABOUT THIS*
>>>
>>>>> Because the simulator must perform every detail of the simulation of
>>>>> the underlying machine it can watch every single state change of this
>>>>> underlying machine and this does not change the behavior of the
>>>>> simulated input AT ALL (relative to not watching the state changes).
>>>>
>>>> Yes, that is a correct interpretation.
>>>>
>>>
>>> OK Great!
>>> So a simulating termination analyzer could watch the behavior of its
>>> input and analyze this watched behavior and transition to a non-final
>>> state that indicates non-halting and then go back and continue
>>> simulating the non-halting input and it remains a simulator all along.
>>
>> HOw can you "return" the non-halting indication and then continue to run?
>>
> 
> D simulated by H could
> (a) Watch all of the state changes of its input.
> (b) Analyze these state changes.
> (c) Correctly determine that its input would never halt.
> (d) Continue to report that its input would never halt by
>      transitioning to a special non-final state indicating this.
> 
> All the while remaining a pure simulator with extra features.
> 
>>>
>>> *This would not be a halt decider because all deciders must halt*
>>> *It would be an unconventional termination analyzer*
>>
>> It wouldn't be a program by the normal definitions of a program.
>>
>>>
>>> *It does correctly report that its pathological input never halts*
>>
>> Nope.
>>
>>>
>>> *This method does work correctly on the H/D template*
>>> *and the Ĥ applied to ⟨Ĥ⟩ template shown below*
>>>
>>> 00 int H(ptr x, ptr x)  // ptr is pointer to int function
>>> 01 int D(ptr x)
>>> 02 {
>>> 03   int Halt_Status = H(x, x);
>>> 04   if (Halt_Status)
>>> 05     HERE: goto HERE;
>>> 06   return Halt_Status;
>>> 07 }
>>> 08
>>> 09 int main()
>>> 10 {
>>> 11   H(D,D);
>>> 12 }
>>>
>>> When Ĥ is applied to ⟨Ĥ⟩
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> *Termination Analyzer H is Not Fooled by Pathological Input D*
>>> https://www.researchgate.net/publication/369971402_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
>>>
>>
>> Nope, because the H you just described is not equivalent to a Turing 
>> Machine.
> 
> The exact same (a)(b)(c)(d) sequence of steps applies equally
> to the Linz template:
> 
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> 
> embedded_H is not a halt decider or even a conventional
> {termination analyzer}, it is an unconventional {termination analyzer}
> that does correctly report the halt status of its pathological input.
> 
> 

It is also true that the behavior that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
is reporting on is the same behavior as Ĥ ⟨Ĥ⟩.

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

[toc] | [prev] | [next] | [standalone]

#104695

On 5/11/24 4:16 PM, olcott wrote:
> On 5/11/2024 12:19 PM, olcott wrote:
>> On 5/11/2024 11:46 AM, Richard Damon wrote:
>>> On 5/11/24 12:06 PM, olcott wrote:
>>>> On 5/11/2024 3:00 AM, Mikko wrote:
>>>>> On 2024-05-10 18:16:37 +0000, olcott said:
>>>>>
>>>>>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>>>>>
>>>>>>> Obviously a simulator has access to the internal state (tape 
>>>>>>> contents etc.) of the simulated machine.  No problem there.
>>>>>>>
>>>>>>> What isn't allowed is the simulated machine altering its own 
>>>>>>> behaviour by accessing data outside of its own state.  (I.e. 
>>>>>>> accessing data from its parent simulators state.)
>>>>>>>
>>>>>>> While an "active-simulator" [my own term] is at liberty to combine
>>>>>>> straight simulation with add-on "enhancements" that extend the
>>>>>>> functionality of the simulated machine, in doing so it would no
>>>>>>> longer be a simulator in the sense you need it to be.  So you
>>>>>>> mustn't do this!
>>>>>
>>>>> In principle an incorrect simulation is permissible. However, to prove
>>>>> that the result inferred from an incorrect simulation is correct may
>>>>> be impossible.
>>>>>
>>>>
>>>> Within the conventional terms-of-the-art of {termination analyzer}
>>>> and {simulator} an incorrect simulation is forbidden.
>>>
>>>
>>>  From what definitions.
>>>
>>> I would say that based on the definition of simulation that you imply 
>>> you are using (by the using of it to bridge from the behavior of the 
>>> program to the simlulation of the program) ALL your H that answer 
>>> about D have used an "incorrect" simulation.
>>>
>>>>
>>>>>> *You did not provide complete reasoning justifying this proclamation*
>>>>>> *You did not provide complete reasoning justifying this proclamation*
>>>>>> *You did not provide complete reasoning justifying this proclamation*
>>>>>
>>>>> The provided reasoning is sufficient. You can continue reasoning from
>>>>> that if you want more.
>>>>>
>>>>
>>>> *He is SIMPLY WRONG and when he tries*
>>>> *to justify what he said he will fail*
>>>>
>>>> Any pure x86 emulator or UTM can have the added functionality
>>>> of watching every state change of its simulated input without
>>>> changing the simulated steps of this input relative to an
>>>> unmodified x86 emulator or UTM.
>>>>
>>>> *SO MIKE TERRY IS SIMPLY WRONG ABOUT THIS*
>>>>
>>>>>> Because the simulator must perform every detail of the simulation of
>>>>>> the underlying machine it can watch every single state change of this
>>>>>> underlying machine and this does not change the behavior of the
>>>>>> simulated input AT ALL (relative to not watching the state changes).
>>>>>
>>>>> Yes, that is a correct interpretation.
>>>>>
>>>>
>>>> OK Great!
>>>> So a simulating termination analyzer could watch the behavior of its
>>>> input and analyze this watched behavior and transition to a non-final
>>>> state that indicates non-halting and then go back and continue
>>>> simulating the non-halting input and it remains a simulator all along.
>>>
>>> HOw can you "return" the non-halting indication and then continue to 
>>> run?
>>>
>>
>> D simulated by H could
>> (a) Watch all of the state changes of its input.
>> (b) Analyze these state changes.
>> (c) Correctly determine that its input would never halt.
>> (d) Continue to report that its input would never halt by
>>      transitioning to a special non-final state indicating this.
>>
>> All the while remaining a pure simulator with extra features.
>>
>>>>
>>>> *This would not be a halt decider because all deciders must halt*
>>>> *It would be an unconventional termination analyzer*
>>>
>>> It wouldn't be a program by the normal definitions of a program.
>>>
>>>>
>>>> *It does correctly report that its pathological input never halts*
>>>
>>> Nope.
>>>
>>>>
>>>> *This method does work correctly on the H/D template*
>>>> *and the Ĥ applied to ⟨Ĥ⟩ template shown below*
>>>>
>>>> 00 int H(ptr x, ptr x)  // ptr is pointer to int function
>>>> 01 int D(ptr x)
>>>> 02 {
>>>> 03   int Halt_Status = H(x, x);
>>>> 04   if (Halt_Status)
>>>> 05     HERE: goto HERE;
>>>> 06   return Halt_Status;
>>>> 07 }
>>>> 08
>>>> 09 int main()
>>>> 10 {
>>>> 11   H(D,D);
>>>> 12 }
>>>>
>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> *Termination Analyzer H is Not Fooled by Pathological Input D*
>>>> https://www.researchgate.net/publication/369971402_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
>>>>
>>>
>>> Nope, because the H you just described is not equivalent to a Turing 
>>> Machine.
>>
>> The exact same (a)(b)(c)(d) sequence of steps applies equally
>> to the Linz template:
>>
>> When Ĥ is applied to ⟨Ĥ⟩
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> embedded_H is not a halt decider or even a conventional
>> {termination analyzer}, it is an unconventional {termination analyzer}
>> that does correctly report the halt status of its pathological input.
>>
>>
> 
> It is also true that the behavior that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
> is reporting on is the same behavior as Ĥ ⟨Ĥ⟩.
> 

But it gets that wrong answer.

Since H^ (H^) Halts, but embedded_H(H^,H^) says it doesn't

Thus, you admit your logic is broken.

Note, embedded_H can't use your answer but not halt, as Turing Machines 
can't do that, so if you need that, your whole model is just 
incompatible with the theory, and you need to explain how it works.

[toc] | [prev] | [next] | [standalone]

#104698

On 5/11/24 1:19 PM, olcott wrote:
> On 5/11/2024 11:46 AM, Richard Damon wrote:
>> On 5/11/24 12:06 PM, olcott wrote:
>>> On 5/11/2024 3:00 AM, Mikko wrote:
>>>> On 2024-05-10 18:16:37 +0000, olcott said:
>>>>
>>>>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>>>>
>>>>>> Obviously a simulator has access to the internal state (tape 
>>>>>> contents etc.) of the simulated machine.  No problem there.
>>>>>>
>>>>>> What isn't allowed is the simulated machine altering its own 
>>>>>> behaviour by accessing data outside of its own state.  (I.e. 
>>>>>> accessing data from its parent simulators state.)
>>>>>>
>>>>>> While an "active-simulator" [my own term] is at liberty to combine
>>>>>> straight simulation with add-on "enhancements" that extend the
>>>>>> functionality of the simulated machine, in doing so it would no
>>>>>> longer be a simulator in the sense you need it to be.  So you
>>>>>> mustn't do this!
>>>>
>>>> In principle an incorrect simulation is permissible. However, to prove
>>>> that the result inferred from an incorrect simulation is correct may
>>>> be impossible.
>>>>
>>>
>>> Within the conventional terms-of-the-art of {termination analyzer}
>>> and {simulator} an incorrect simulation is forbidden.
>>
>>
>>  From what definitions.
>>
>> I would say that based on the definition of simulation that you imply 
>> you are using (by the using of it to bridge from the behavior of the 
>> program to the simlulation of the program) ALL your H that answer 
>> about D have used an "incorrect" simulation.
>>
>>>
>>>>> *You did not provide complete reasoning justifying this proclamation*
>>>>> *You did not provide complete reasoning justifying this proclamation*
>>>>> *You did not provide complete reasoning justifying this proclamation*
>>>>
>>>> The provided reasoning is sufficient. You can continue reasoning from
>>>> that if you want more.
>>>>
>>>
>>> *He is SIMPLY WRONG and when he tries*
>>> *to justify what he said he will fail*
>>>
>>> Any pure x86 emulator or UTM can have the added functionality
>>> of watching every state change of its simulated input without
>>> changing the simulated steps of this input relative to an
>>> unmodified x86 emulator or UTM.
>>>
>>> *SO MIKE TERRY IS SIMPLY WRONG ABOUT THIS*
>>>
>>>>> Because the simulator must perform every detail of the simulation of
>>>>> the underlying machine it can watch every single state change of this
>>>>> underlying machine and this does not change the behavior of the
>>>>> simulated input AT ALL (relative to not watching the state changes).
>>>>
>>>> Yes, that is a correct interpretation.
>>>>
>>>
>>> OK Great!
>>> So a simulating termination analyzer could watch the behavior of its
>>> input and analyze this watched behavior and transition to a non-final
>>> state that indicates non-halting and then go back and continue
>>> simulating the non-halting input and it remains a simulator all along.
>>
>> HOw can you "return" the non-halting indication and then continue to run?
>>
> 
> D simulated by H could
> (a) Watch all of the state changes of its input.
> (b) Analyze these state changes.
> (c) Correctly determine that its input would never halt.
> (d) Continue to report that its input would never halt by
>      transitioning to a special non-final state indicating this.
> 
> All the while remaining a pure simulator with extra features.

How does a program, per the definition in Computation Theory, report an 
answer to its caller, and continue to do something.

Remember, you have DEFINED that this D must call H, which means that H 
must return its answer to D. Going through a non-final state to answer 
is inconsistant with your definition of H as RETURNING the answer.

Your definition is just self-inconstant, as is your logic.

You are trying to define a dog, that is also a 10 story office building.

> 
>>>
>>> *This would not be a halt decider because all deciders must halt*
>>> *It would be an unconventional termination analyzer*
>>
>> It wouldn't be a program by the normal definitions of a program.
>>
>>>
>>> *It does correctly report that its pathological input never halts*
>>
>> Nope.
>>
>>>
>>> *This method does work correctly on the H/D template*
>>> *and the Ĥ applied to ⟨Ĥ⟩ template shown below*
>>>
>>> 00 int H(ptr x, ptr x)  // ptr is pointer to int function
>>> 01 int D(ptr x)
>>> 02 {
>>> 03   int Halt_Status = H(x, x);
>>> 04   if (Halt_Status)
>>> 05     HERE: goto HERE;
>>> 06   return Halt_Status;
>>> 07 }
>>> 08
>>> 09 int main()
>>> 10 {
>>> 11   H(D,D);
>>> 12 }
>>>
>>> When Ĥ is applied to ⟨Ĥ⟩
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> *Termination Analyzer H is Not Fooled by Pathological Input D*
>>> https://www.researchgate.net/publication/369971402_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
>>>
>>
>> Nope, because the H you just described is not equivalent to a Turing 
>> Machine.
> 
> The exact same (a)(b)(c)(d) sequence of steps applies equally
> to the Linz template:

Nope. ANSWERING is BY DEFINITION a final state for that sub-machine.

So, you are just proving you don't understand what you are talking about.

*H* answers by going to *ITS* final states, qy or qn. Once we build H^, 
THAT isn't defined to give an answer, only have behavior.


> 
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> 
> embedded_H is not a halt decider or even a conventional
> {termination analyzer}, it is an unconventional {termination analyzer}
> that does correctly report the halt status of its pathological input.
> 
> 

Then H isn't a Halt Decider or Terminataion Analyzer and you are just 
admitting to being a LIAR.

Remember, you claim that embeded_H is from the Linz style proof and thus 
is an exact copy of your H so is the same sort of thing as it.

[toc] | [prev] | [next] | [standalone]

#104706

On 5/12/2024 2:47 AM, Mikko wrote:
> On 2024-05-11 16:06:29 +0000, olcott said:
> 
>> On 5/11/2024 3:00 AM, Mikko wrote:
>>> On 2024-05-10 18:16:37 +0000, olcott said:
>>>
>>>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>>>
>>>>> Obviously a simulator has access to the internal state (tape 
>>>>> contents etc.) of the simulated machine.  No problem there.
>>>>>
>>>>> What isn't allowed is the simulated machine altering its own 
>>>>> behaviour by accessing data outside of its own state.  (I.e. 
>>>>> accessing data from its parent simulators state.)
>>>>>
>>>>> While an "active-simulator" [my own term] is at liberty to combine
>>>>> straight simulation with add-on "enhancements" that extend the
>>>>> functionality of the simulated machine, in doing so it would no
>>>>> longer be a simulator in the sense you need it to be.  So you
>>>>> mustn't do this!
>>>
>>> In principle an incorrect simulation is permissible. However, to prove
>>> that the result inferred from an incorrect simulation is correct may
>>> be impossible.
>>>
>>
>> Within the conventional terms-of-the-art of {termination analyzer}
>> and {simulator} an incorrect simulation is forbidden.
> 
> The conventional meaning of "termination analyzer" does not prohibit
> incorrect simulation.

If it does not correctly determine termination then it is not
a termination analyzer.

>  Whether an incorrect simulation can be called
> "simulation" is a matter of opinion. 

One can call a {dead cat} a fifteen story office building. One
cannot correctly call a {dead cat} a fifteen story office building.

Ignoring the input and simulating zero steps cannot be correctly
called a simulation. Correctly simulating the first step of an
input is a correct simulation by definition. It is not a correct
and complete simulation when the input has more than one step.

> In any case, when a methind that
> uses an incorrect simulation is described the incorrectness of the
> simulation, whther calles "simulation" or otherwise, must be mentioned
> and its role be explained.
> 

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

[toc] | [prev] | [next] | [standalone]

#104709

On 2024-05-12 14:18:05 +0000, olcott said:

> On 5/12/2024 2:47 AM, Mikko wrote:
>> On 2024-05-11 16:06:29 +0000, olcott said:
>> 
>>> On 5/11/2024 3:00 AM, Mikko wrote:
>>>> On 2024-05-10 18:16:37 +0000, olcott said:
>>>> 
>>>>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>>>> 
>>>>>> Obviously a simulator has access to the internal state (tape contents 
>>>>>> etc.) of the simulated machine.  No problem there.
>>>>>> 
>>>>>> What isn't allowed is the simulated machine altering its own behaviour 
>>>>>> by accessing data outside of its own state.  (I.e. accessing data from 
>>>>>> its parent simulators state.)
>>>>>> 
>>>>>> While an "active-simulator" [my own term] is at liberty to combine
>>>>>> straight simulation with add-on "enhancements" that extend the
>>>>>> functionality of the simulated machine, in doing so it would no
>>>>>> longer be a simulator in the sense you need it to be.  So you
>>>>>> mustn't do this!
>>>> 
>>>> In principle an incorrect simulation is permissible. However, to prove
>>>> that the result inferred from an incorrect simulation is correct may
>>>> be impossible.
>>>> 
>>> 
>>> Within the conventional terms-of-the-art of {termination analyzer}
>>> and {simulator} an incorrect simulation is forbidden.
>> 
>> The conventional meaning of "termination analyzer" does not prohibit
>> incorrect simulation.
> 
> If it does not correctly determine termination then it is not
> a termination analyzer.

That is not always required. IT is often considered sufficent that
the analyzer does not determine incorrectly. To not determine at
all is often considered acceptable.

An incorrect simulation as a part of the algorithm is acceptable
as long as the result about termination is correct.

-- 
Mikko

[toc] | [prev] | [next] | [standalone]

#104713

On 5/12/2024 10:14 AM, Mikko wrote:
> On 2024-05-12 14:18:05 +0000, olcott said:
> 
>> On 5/12/2024 2:47 AM, Mikko wrote:
>>> On 2024-05-11 16:06:29 +0000, olcott said:
>>>
>>>> On 5/11/2024 3:00 AM, Mikko wrote:
>>>>> On 2024-05-10 18:16:37 +0000, olcott said:
>>>>>
>>>>>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>>>>>
>>>>>>> Obviously a simulator has access to the internal state (tape 
>>>>>>> contents etc.) of the simulated machine.  No problem there.
>>>>>>>
>>>>>>> What isn't allowed is the simulated machine altering its own 
>>>>>>> behaviour by accessing data outside of its own state.  (I.e. 
>>>>>>> accessing data from its parent simulators state.)
>>>>>>>
>>>>>>> While an "active-simulator" [my own term] is at liberty to combine
>>>>>>> straight simulation with add-on "enhancements" that extend the
>>>>>>> functionality of the simulated machine, in doing so it would no
>>>>>>> longer be a simulator in the sense you need it to be.  So you
>>>>>>> mustn't do this!
>>>>>
>>>>> In principle an incorrect simulation is permissible. However, to prove
>>>>> that the result inferred from an incorrect simulation is correct may
>>>>> be impossible.
>>>>>
>>>>
>>>> Within the conventional terms-of-the-art of {termination analyzer}
>>>> and {simulator} an incorrect simulation is forbidden.
>>>
>>> The conventional meaning of "termination analyzer" does not prohibit
>>> incorrect simulation.
>>
>> If it does not correctly determine termination then it is not
>> a termination analyzer.
> 
> That is not always required. IT is often considered sufficent that
> the analyzer does not determine incorrectly. To not determine at
> all is often considered acceptable.
> 
> An incorrect simulation as a part of the algorithm is acceptable
> as long as the result about termination is correct.
> 

A program that performs zero termination analysis is NOT
a termination analyzer. Richard was trying to get away
with sating that it is.

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

[toc] | [prev] | [next] | [standalone]

#104718

On 5/12/24 12:53 PM, olcott wrote:
> On 5/12/2024 10:14 AM, Mikko wrote:
>> On 2024-05-12 14:18:05 +0000, olcott said:
>>
>>> On 5/12/2024 2:47 AM, Mikko wrote:
>>>> On 2024-05-11 16:06:29 +0000, olcott said:
>>>>
>>>>> On 5/11/2024 3:00 AM, Mikko wrote:
>>>>>> On 2024-05-10 18:16:37 +0000, olcott said:
>>>>>>
>>>>>>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>>>>>>
>>>>>>>> Obviously a simulator has access to the internal state (tape 
>>>>>>>> contents etc.) of the simulated machine.  No problem there.
>>>>>>>>
>>>>>>>> What isn't allowed is the simulated machine altering its own 
>>>>>>>> behaviour by accessing data outside of its own state.  (I.e. 
>>>>>>>> accessing data from its parent simulators state.)
>>>>>>>>
>>>>>>>> While an "active-simulator" [my own term] is at liberty to combine
>>>>>>>> straight simulation with add-on "enhancements" that extend the
>>>>>>>> functionality of the simulated machine, in doing so it would no
>>>>>>>> longer be a simulator in the sense you need it to be.  So you
>>>>>>>> mustn't do this!
>>>>>>
>>>>>> In principle an incorrect simulation is permissible. However, to 
>>>>>> prove
>>>>>> that the result inferred from an incorrect simulation is correct may
>>>>>> be impossible.
>>>>>>
>>>>>
>>>>> Within the conventional terms-of-the-art of {termination analyzer}
>>>>> and {simulator} an incorrect simulation is forbidden.
>>>>
>>>> The conventional meaning of "termination analyzer" does not prohibit
>>>> incorrect simulation.
>>>
>>> If it does not correctly determine termination then it is not
>>> a termination analyzer.
>>
>> That is not always required. IT is often considered sufficent that
>> the analyzer does not determine incorrectly. To not determine at
>> all is often considered acceptable.
>>
>> An incorrect simulation as a part of the algorithm is acceptable
>> as long as the result about termination is correct.
>>
> 
> A program that performs zero termination analysis is NOT
> a termination analyzer. Richard was trying to get away
> with sating that it is.
> 

Termination analysis doesn't define the METHOD that is to be used, only 
the results.

In fact, a fundamental aspect of Computabilty Theory is that it doesn't 
really care HOW an answer is given, but that it is given (and being 
correct).

Other parts of computer science (like complexity theory) look at the 
details of how the answer is given, but they are not part of 
Computability theory.

[toc] | [prev] | [next] | [standalone]

#104759

On 2024-05-12 16:53:33 +0000, olcott said:

> On 5/12/2024 10:14 AM, Mikko wrote:
>> On 2024-05-12 14:18:05 +0000, olcott said:
>> 
>>> On 5/12/2024 2:47 AM, Mikko wrote:
>>>> On 2024-05-11 16:06:29 +0000, olcott said:
>>>> 
>>>>> On 5/11/2024 3:00 AM, Mikko wrote:
>>>>>> On 2024-05-10 18:16:37 +0000, olcott said:
>>>>>> 
>>>>>>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>>>>>> 
>>>>>>>> Obviously a simulator has access to the internal state (tape contents 
>>>>>>>> etc.) of the simulated machine.  No problem there.
>>>>>>>> 
>>>>>>>> What isn't allowed is the simulated machine altering its own behaviour 
>>>>>>>> by accessing data outside of its own state.  (I.e. accessing data from 
>>>>>>>> its parent simulators state.)
>>>>>>>> 
>>>>>>>> While an "active-simulator" [my own term] is at liberty to combine
>>>>>>>> straight simulation with add-on "enhancements" that extend the
>>>>>>>> functionality of the simulated machine, in doing so it would no
>>>>>>>> longer be a simulator in the sense you need it to be.  So you
>>>>>>>> mustn't do this!
>>>>>> 
>>>>>> In principle an incorrect simulation is permissible. However, to prove
>>>>>> that the result inferred from an incorrect simulation is correct may
>>>>>> be impossible.
>>>>>> 
>>>>> 
>>>>> Within the conventional terms-of-the-art of {termination analyzer}
>>>>> and {simulator} an incorrect simulation is forbidden.
>>>> 
>>>> The conventional meaning of "termination analyzer" does not prohibit
>>>> incorrect simulation.
>>> 
>>> If it does not correctly determine termination then it is not
>>> a termination analyzer.
>> 
>> That is not always required. IT is often considered sufficent that
>> the analyzer does not determine incorrectly. To not determine at
>> all is often considered acceptable.
>> 
>> An incorrect simulation as a part of the algorithm is acceptable
>> as long as the result about termination is correct.
>> 
> 
> A program that performs zero termination analysis is NOT
> a termination analyzer. Richard was trying to get away
> with sating that it is.

Irrelevan to everything mentioned in the subject line.

-- 
Mikko

[toc] | [prev] | [next] | [standalone]

#104716

On 5/12/24 10:18 AM, olcott wrote:
> On 5/12/2024 2:47 AM, Mikko wrote:
>> On 2024-05-11 16:06:29 +0000, olcott said:
>>
>>> On 5/11/2024 3:00 AM, Mikko wrote:
>>>> On 2024-05-10 18:16:37 +0000, olcott said:
>>>>
>>>>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>>>>
>>>>>> Obviously a simulator has access to the internal state (tape 
>>>>>> contents etc.) of the simulated machine.  No problem there.
>>>>>>
>>>>>> What isn't allowed is the simulated machine altering its own 
>>>>>> behaviour by accessing data outside of its own state.  (I.e. 
>>>>>> accessing data from its parent simulators state.)
>>>>>>
>>>>>> While an "active-simulator" [my own term] is at liberty to combine
>>>>>> straight simulation with add-on "enhancements" that extend the
>>>>>> functionality of the simulated machine, in doing so it would no
>>>>>> longer be a simulator in the sense you need it to be.  So you
>>>>>> mustn't do this!
>>>>
>>>> In principle an incorrect simulation is permissible. However, to prove
>>>> that the result inferred from an incorrect simulation is correct may
>>>> be impossible.
>>>>
>>>
>>> Within the conventional terms-of-the-art of {termination analyzer}
>>> and {simulator} an incorrect simulation is forbidden.
>>
>> The conventional meaning of "termination analyzer" does not prohibit
>> incorrect simulation.
> 
> If it does not correctly determine termination then it is not
> a termination analyzer.

And thus, since D(D) does terminate, your H is wrong.

> 
>>  Whether an incorrect simulation can be called
>> "simulation" is a matter of opinion. 
> 
> One can call a {dead cat} a fifteen story office building. One
> cannot correctly call a {dead cat} a fifteen story office building.

And you can not correctly call a halting program as non-halting.

Since D(D) Halts, H(D,D) saying it doesn't is just wrong.

ALL your logic eventually goes back to assuming an incorrect statement, 
Like that H does correctly simulate its input, or that H is both a 
single machine and also an infinite set of machines, or that H can 
analyze a D that calls some other H then the one that the one it is 
looking at works on.


Also, you have effectively admitted to just being a liar, as the 
conventional definition as a term-of-art for either a Halt Decider, or a 
Terminataion Analyzer, is that their input is a description of a 
PROGRAM, a SPECIFIC program, but your H doesn't take in a specific 
program, but a "template" that changes the input as we apply different 
deciders to it.

> 
> Ignoring the input and simulating zero steps cannot be correctly
> called a simulation. Correctly simulating the first step of an
> input is a correct simulation by definition. It is not a correct
> and complete simulation when the input has more than one step.
> 

You miss that it is just as valid as simulating N steps, and then use 
invalid logic t get the wrong answer. You keep on trying to change you 
definitions to hide your various errors.

If YOUR H is allowed to ignore the actual behavior of the input given to 
it (which calls itself, and thus assume that the H that this D calls 
doesn't return, when it is defined as THIS H, which does return, then it 
is just as valid to totally ignore the input.

>> In any case, when a methind that
>> uses an incorrect simulation is described the incorrectness of the
>> simulation, whther calles "simulation" or otherwise, must be mentioned
>> and its role be explained.
>>
> 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.theory

csiph-web