01 typedef int (*ptr)(); // pointer to int function
02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 H(D,D);
15 }

When H is a simulating termination analyzer based on an x86 emulator
within the x86utm operating system this is the execution trace of the
above code:

Line 14: main() calls H(D,D) that simulates D(D)

keeps repeating:
Line 06: simulated D(D) calls simulated H(D,D) that simulates D(D) ...

Simulation invariant:
D correctly simulated by H never reaches its own Line 09.

This enables H to abort its simulation of D and correctly report that
(its input) D correctly simulated by H never halts. The above is fully
operational code within the x86utm operating system.
https://github.com/plolcott/x86utm

*Broadening the Practical Scope of Software Termination Analysis*

https://www.researchgate.net/publication/369971402_Broadening_the_Practical_Scope_of_Software_Termination_Analysis

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

On 6/10/2023 6:23 AM, olcott wrote:

Take a day off you retarded boring lunatic.

On 6/10/23 9:23 AM, olcott wrote:
> 01 typedef int (*ptr)(); // pointer to int function
> 02 int H(ptr x, ptr y)   // uses x86 emulator to simulate its input
> 03
> 04 int D(ptr x)
> 05 {
> 06  int Halt_Status = H(x, x);
> 07  if (Halt_Status)
> 08    HERE: goto HERE;
> 09  return Halt_Status;
> 10 }
> 11
> 12 void main()
> 13 {
> 14  H(D,D);
> 15 }
>
> When H is a simulating termination analyzer based on an x86 emulator
> within the x86utm operating system this is the execution trace of the
> above code:
>
> Line 14: main() calls H(D,D) that simulates D(D)
>
> keeps repeating:
> Line 06: simulated D(D) calls simulated H(D,D) that simulates D(D) ...

So, you are defining that the CORRECT SIMULATION of a call to H(D,D) is
that it keeps repeating its simulatin. We will call this stipulation A.

>
> Simulation invariant:
> D correctly simulated by H never reaches its own Line 09.

Ok, if you say so. Remember that means that for all calls to H(D,D) it
may not return a value. THAT is your invariant.

>
> This enables H to abort its simulation of D and correctly report that
> (its input) D correctly simulated by H never halts. The above is fully
> operational code within the x86utm operating system.
> https://github.com/plolcott/x86utm

NO, because that volates the stipulation A you made that H(D,D) just
keeps simulating its input, and your simulation invariant.

Thus, while it may be correct for H to abort its siulation of D at this
point, it can't actually do so without breaking its stipulations.

IF the code of H actually DOES stop its simulation at this point, then
the assumption made in Stipualation A is FALSE, and all following logic
is as UNSOUND as your own mind.

In fact, that ACTUAL behavior of D(D) calling H(D,D) is that H(D,D) will
simulate its input to the point that it sees this simulated D(D) calling
H(D,D), then it aborts its simuation and returns to the actual running
D(D) the value 0 to indicate non-halting, and that D(D) will Then Halt.

Thus, the CORRECT simulation of a the call to H(D,D) that H sees in its
simulation of D(D) needs to somehow determine that this call will return
a 0, since that is what it does, which means it does NOT do what you
claimed at the point of Stipulation A, which just shows you are an
ignorant pathological lying idiot.

>
> *Broadening the Practical Scope of Software Termination Analysis*
>
> https://www.researchgate.net/publication/369971402_Broadening_the_Practical_Scope_of_Software_Termination_Analysis
>

All based on the above lies.

The DEFINITION of a "Correct Simulation" is that it correctly predicts
the behavior of the actual program.

Since H(D,D) that you provide WILL return 0, it is clear and accepted
that D(D) when called by main will return, and thus the CORR#CT
SIMULATION of this input is Halting, so H is just incorrect, and the
logic presented in error. That you claim it to be correct, just shows
your utter ignorance of truth and how logic works.

You have just gaslit yourself with your own lies.

On 6/10/2023 8:54 AM, Richard Damon wrote:
> On 6/10/23 9:23 AM, olcott wrote:
>> 01 typedef int (*ptr)(); // pointer to int function
>> 02 int H(ptr x, ptr y)   // uses x86 emulator to simulate its input
>> 03
>> 04 int D(ptr x)
>> 05 {
>> 06  int Halt_Status = H(x, x);
>> 07  if (Halt_Status)
>> 08    HERE: goto HERE;
>> 09  return Halt_Status;
>> 10 }
>> 11
>> 12 void main()
>> 13 {
>> 14  H(D,D);
>> 15 }
>>
>> When H is a simulating termination analyzer based on an x86 emulator
>> within the x86utm operating system this is the execution trace of the
>> above code:
>>
>> Line 14: main() calls H(D,D) that simulates D(D)
>>
>> keeps repeating:
>> Line 06: simulated D(D) calls simulated H(D,D) that simulates D(D) ...
>
> So, you are defining that the CORRECT SIMULATION of a call to H(D,D) is
> that it keeps repeating its simulatin. We will call this stipulation A.
>
>>
>> Simulation invariant:
>> D correctly simulated by H never reaches its own Line 09.
>
> Ok, if you say so. Remember that means that for all calls to H(D,D) it
> may not return a value. THAT is your invariant.
>
>>
>> This enables H to abort its simulation of D and correctly report that
>> (its input) D correctly simulated by H never halts. The above is fully
>> operational code within the x86utm operating system.
>> https://github.com/plolcott/x86utm
>
> NO, because that volates the stipulation A you made that H(D,D) just
> keeps simulating its input, and your simulation invariant.
>
> Thus, while it may be correct for H to abort its siulation of D at this
> point, it can't actually do so without breaking its stipulations.
>
> IF the code of H actually DOES stop its simulation at this point, then
> the assumption made in Stipualation A is FALSE, and all following logic
> is as UNSOUND as your own mind.
>
> In fact, that ACTUAL behavior of D(D) calling H(D,D) is that H(D,D) will
> simulate its input to the point that it sees this simulated D(D) calling
> H(D,D), then it aborts its simuation and returns to the actual running
> D(D) the value 0 to indicate non-halting, and that D(D) will Then Halt.
>
> Thus, the CORRECT simulation of a the call to H(D,D) that H sees in its
> simulation of D(D) needs to somehow determine that this call will return
> a 0, since that is what it does, which means it does NOT do what you
> claimed at the point of Stipulation A, which just shows you are an
> ignorant pathological lying idiot.
>
>>
>> *Broadening the Practical Scope of Software Termination Analysis*
>>
>> https://www.researchgate.net/publication/369971402_Broadening_the_Practical_Scope_of_Software_Termination_Analysis
>>

> The DEFINITION of a "Correct Simulation" is that it correctly predicts
> the behavior of the actual program.
>

*That is not how termination analyzers works*
Termination analyzers compute the mapping from their inputs to an accept
or reject state on the basis of the actual behavior specified by this
input.

*It is incorrect for them to compute the halt status of non-inputs*

int sum(int x, int y)
{ return x + y;
}

You might be able to imagine that sum must be able to compute the sum of
non-inputs and say that sum(3,4) derives an incorrect result because it
does not compute the sum of 5 + 7.

In this same way that you would be wrong on this you are wrong that H
must compute the halt status of non-inputs.

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

On 6/10/23 10:12 AM, olcott wrote:
> On 6/10/2023 8:54 AM, Richard Damon wrote:
>> On 6/10/23 9:23 AM, olcott wrote:
>>> 01 typedef int (*ptr)(); // pointer to int function
>>> 02 int H(ptr x, ptr y)   // uses x86 emulator to simulate its input
>>> 03
>>> 04 int D(ptr x)
>>> 05 {
>>> 06  int Halt_Status = H(x, x);
>>> 07  if (Halt_Status)
>>> 08    HERE: goto HERE;
>>> 09  return Halt_Status;
>>> 10 }
>>> 11
>>> 12 void main()
>>> 13 {
>>> 14  H(D,D);
>>> 15 }
>>>
>>> When H is a simulating termination analyzer based on an x86 emulator
>>> within the x86utm operating system this is the execution trace of the
>>> above code:
>>>
>>> Line 14: main() calls H(D,D) that simulates D(D)
>>>
>>> keeps repeating:
>>> Line 06: simulated D(D) calls simulated H(D,D) that simulates D(D) ...
>>
>> So, you are defining that the CORRECT SIMULATION of a call to H(D,D)
>> is that it keeps repeating its simulatin. We will call this
>> stipulation A.
>>
>>>
>>> Simulation invariant:
>>> D correctly simulated by H never reaches its own Line 09.
>>
>> Ok, if you say so. Remember that means that for all calls to H(D,D) it
>> may not return a value. THAT is your invariant.
>>
>>>
>>> This enables H to abort its simulation of D and correctly report that
>>> (its input) D correctly simulated by H never halts. The above is fully
>>> operational code within the x86utm operating system.
>>> https://github.com/plolcott/x86utm
>>
>> NO, because that volates the stipulation A you made that H(D,D) just
>> keeps simulating its input, and your simulation invariant.
>>
>> Thus, while it may be correct for H to abort its siulation of D at
>> this point, it can't actually do so without breaking its stipulations.
>>
>> IF the code of H actually DOES stop its simulation at this point, then
>> the assumption made in Stipualation A is FALSE, and all following
>> logic is as UNSOUND as your own mind.
>>
>> In fact, that ACTUAL behavior of D(D) calling H(D,D) is that H(D,D)
>> will simulate its input to the point that it sees this simulated D(D)
>> calling H(D,D), then it aborts its simuation and returns to the actual
>> running D(D) the value 0 to indicate non-halting, and that D(D) will
>> Then Halt.
>>
>> Thus, the CORRECT simulation of a the call to H(D,D) that H sees in
>> its simulation of D(D) needs to somehow determine that this call will
>> return a 0, since that is what it does, which means it does NOT do
>> what you claimed at the point of Stipulation A, which just shows you
>> are an ignorant pathological lying idiot.
>>
>>>
>>> *Broadening the Practical Scope of Software Termination Analysis*
>>>
>>> https://www.researchgate.net/publication/369971402_Broadening_the_Practical_Scope_of_Software_Termination_Analysis
>>>
>
>> The DEFINITION of a "Correct Simulation" is that it correctly predicts
>> the behavior of the actual program.
>>
>
> *That is not how termination analyzers works*

Then it isn't applicaple to the Halting Problem, or, more likely, you
just don't understand what "Termination Analysis" actually is.

> Termination analyzers compute the mapping from their inputs to an accept
> or reject state on the basis of the actual behavior specified by this
> input.

Right, and the ACTUAL BEHAVIOR is defined by what the program does when
actually run.

> *It is incorrect for them to compute the halt status of non-inputs*
>
> int sum(int x, int y)
> {
>   return x + y;
> }

H(sum, x, y) would need to compute the halt status of that input.

Yes, H(D,D) doesn't give the answer to Sum(x,y), but need to give the
answer to D(D).

>
> You might be able to imagine that sum must be able to compute the sum of
> non-inputs and say that sum(3,4) derives an incorrect result because it
> does not compute the sum of 5 + 7.
>

So, you are just off serving Red Herring again.

H(D,D) MUST answer about the halting status of the program D(D).

> In this same way that you would be wrong on this you are wrong that H
> must compute the halt status of non-inputs.
>
>

So, you don;t seem to understand that H(D,D) has as its input, the
descrption of the program D, and is being asked to answer about that
actual program D.

By your logic, the ACTUAL problem of Termination Analysis must be
totally impossible because you don't understand how an actual program
can be given as an input to a function.

Once you accept that we can pass an actual program to the analyzer, then

H(D,D) must be seen to be asking about the behavior of D(D), and to say
that is a "non-input" is to just deny that the problem can be asked.

You are caught in your lies, and show to be the ignorant pathological
lying idiot.

Either H(D,D) is being asked about, as its input, the program D(D), or
the whole field of Termination Analysis, the field of asking if PROGRAMS
will terminate is invalid as you can't ask that question.

On 6/10/2023 9:32 AM, Richard Damon wrote:
> On 6/10/23 10:12 AM, olcott wrote:
>> On 6/10/2023 8:54 AM, Richard Damon wrote:
>>> On 6/10/23 9:23 AM, olcott wrote:
>>>> 01 typedef int (*ptr)(); // pointer to int function
>>>> 02 int H(ptr x, ptr y)   // uses x86 emulator to simulate its input
>>>> 03
>>>> 04 int D(ptr x)
>>>> 05 {
>>>> 06  int Halt_Status = H(x, x);
>>>> 07  if (Halt_Status)
>>>> 08    HERE: goto HERE;
>>>> 09  return Halt_Status;
>>>> 10 }
>>>> 11
>>>> 12 void main()
>>>> 13 {
>>>> 14  H(D,D);
>>>> 15 }
>>>>
>>>> When H is a simulating termination analyzer based on an x86 emulator
>>>> within the x86utm operating system this is the execution trace of the
>>>> above code:
>>>>
>>>> Line 14: main() calls H(D,D) that simulates D(D)
>>>>
>>>> keeps repeating:
>>>> Line 06: simulated D(D) calls simulated H(D,D) that simulates D(D) ...
>>>
>>> So, you are defining that the CORRECT SIMULATION of a call to H(D,D)
>>> is that it keeps repeating its simulatin. We will call this
>>> stipulation A.
>>>
>>>>
>>>> Simulation invariant:
>>>> D correctly simulated by H never reaches its own Line 09.
>>>
>>> Ok, if you say so. Remember that means that for all calls to H(D,D)
>>> it may not return a value. THAT is your invariant.
>>>
>>>>
>>>> This enables H to abort its simulation of D and correctly report that
>>>> (its input) D correctly simulated by H never halts. The above is fully
>>>> operational code within the x86utm operating system.
>>>> https://github.com/plolcott/x86utm
>>>
>>> NO, because that volates the stipulation A you made that H(D,D) just
>>> keeps simulating its input, and your simulation invariant.
>>>
>>> Thus, while it may be correct for H to abort its siulation of D at
>>> this point, it can't actually do so without breaking its stipulations.
>>>
>>> IF the code of H actually DOES stop its simulation at this point,
>>> then the assumption made in Stipualation A is FALSE, and all
>>> following logic is as UNSOUND as your own mind.
>>>
>>> In fact, that ACTUAL behavior of D(D) calling H(D,D) is that H(D,D)
>>> will simulate its input to the point that it sees this simulated D(D)
>>> calling H(D,D), then it aborts its simuation and returns to the
>>> actual running D(D) the value 0 to indicate non-halting, and that
>>> D(D) will Then Halt.
>>>
>>> Thus, the CORRECT simulation of a the call to H(D,D) that H sees in
>>> its simulation of D(D) needs to somehow determine that this call will
>>> return a 0, since that is what it does, which means it does NOT do
>>> what you claimed at the point of Stipulation A, which just shows you
>>> are an ignorant pathological lying idiot.
>>>
>>>>
>>>> *Broadening the Practical Scope of Software Termination Analysis*
>>>>
>>>> https://www.researchgate.net/publication/369971402_Broadening_the_Practical_Scope_of_Software_Termination_Analysis
>>>>
>>
>>> The DEFINITION of a "Correct Simulation" is that it correctly
>>> predicts the behavior of the actual program.
>>>
>>
>> *That is not how termination analyzers works*
>
> Then it isn't applicaple to the Halting Problem, or, more likely, you
> just don't understand what "Termination Analysis" actually is.
>
>> Termination analyzers compute the mapping from their inputs to an accept
>> or reject state on the basis of the actual behavior specified by this
>> input.
>
> Right, and the ACTUAL BEHAVIOR is defined by what the program does when
> actually run.
>
>> *It is incorrect for them to compute the halt status of non-inputs*
>>
>> int sum(int x, int y)
>> {
>>    return x + y;
>> }
>
> H(sum, x, y) would need to compute the halt status of that input.
>
> Yes, H(D,D) doesn't give the answer to Sum(x,y), but need to give the
> answer to D(D).
>
>>
>> You might be able to imagine that sum must be able to compute the sum of
>> non-inputs and say that sum(3,4) derives an incorrect result because it
>> does not compute the sum of 5 + 7.
>>
>
> So, you are just off serving Red Herring again.
>
> H(D,D) MUST answer about the halting status of the program D(D).
The behavior of D(D) is one recursive invocation away from the actual
behavior of the actual input.

H(D,D) is not allowed to report on what the behavior of its input would
be after it aborts the simulation of this input because it has not yet
aborted the simulation of this input.

You remain one recursive invocation away from reality.

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

On 6/10/23 10:55 AM, olcott wrote:
> On 6/10/2023 9:32 AM, Richard Damon wrote:
>> On 6/10/23 10:12 AM, olcott wrote:
>>> On 6/10/2023 8:54 AM, Richard Damon wrote:
>>>> On 6/10/23 9:23 AM, olcott wrote:
>>>>> 01 typedef int (*ptr)(); // pointer to int function
>>>>> 02 int H(ptr x, ptr y)   // uses x86 emulator to simulate its input
>>>>> 03
>>>>> 04 int D(ptr x)
>>>>> 05 {
>>>>> 06  int Halt_Status = H(x, x);
>>>>> 07  if (Halt_Status)
>>>>> 08    HERE: goto HERE;
>>>>> 09  return Halt_Status;
>>>>> 10 }
>>>>> 11
>>>>> 12 void main()
>>>>> 13 {
>>>>> 14  H(D,D);
>>>>> 15 }
>>>>>
>>>>> When H is a simulating termination analyzer based on an x86 emulator
>>>>> within the x86utm operating system this is the execution trace of the
>>>>> above code:
>>>>>
>>>>> Line 14: main() calls H(D,D) that simulates D(D)
>>>>>
>>>>> keeps repeating:
>>>>> Line 06: simulated D(D) calls simulated H(D,D) that simulates D(D) ...
>>>>
>>>> So, you are defining that the CORRECT SIMULATION of a call to H(D,D)
>>>> is that it keeps repeating its simulatin. We will call this
>>>> stipulation A.
>>>>
>>>>>
>>>>> Simulation invariant:
>>>>> D correctly simulated by H never reaches its own Line 09.
>>>>
>>>> Ok, if you say so. Remember that means that for all calls to H(D,D)
>>>> it may not return a value. THAT is your invariant.
>>>>
>>>>>
>>>>> This enables H to abort its simulation of D and correctly report that
>>>>> (its input) D correctly simulated by H never halts. The above is fully
>>>>> operational code within the x86utm operating system.
>>>>> https://github.com/plolcott/x86utm
>>>>
>>>> NO, because that volates the stipulation A you made that H(D,D) just
>>>> keeps simulating its input, and your simulation invariant.
>>>>
>>>> Thus, while it may be correct for H to abort its siulation of D at
>>>> this point, it can't actually do so without breaking its stipulations.
>>>>
>>>> IF the code of H actually DOES stop its simulation at this point,
>>>> then the assumption made in Stipualation A is FALSE, and all
>>>> following logic is as UNSOUND as your own mind.
>>>>
>>>> In fact, that ACTUAL behavior of D(D) calling H(D,D) is that H(D,D)
>>>> will simulate its input to the point that it sees this simulated
>>>> D(D) calling H(D,D), then it aborts its simuation and returns to the
>>>> actual running D(D) the value 0 to indicate non-halting, and that
>>>> D(D) will Then Halt.
>>>>
>>>> Thus, the CORRECT simulation of a the call to H(D,D) that H sees in
>>>> its simulation of D(D) needs to somehow determine that this call
>>>> will return a 0, since that is what it does, which means it does NOT
>>>> do what you claimed at the point of Stipulation A, which just shows
>>>> you are an ignorant pathological lying idiot.
>>>>
>>>>>
>>>>> *Broadening the Practical Scope of Software Termination Analysis*
>>>>>
>>>>> https://www.researchgate.net/publication/369971402_Broadening_the_Practical_Scope_of_Software_Termination_Analysis
>>>>>
>>>
>>>> The DEFINITION of a "Correct Simulation" is that it correctly
>>>> predicts the behavior of the actual program.
>>>>
>>>
>>> *That is not how termination analyzers works*
>>
>> Then it isn't applicaple to the Halting Problem, or, more likely, you
>> just don't understand what "Termination Analysis" actually is.
>>
>>> Termination analyzers compute the mapping from their inputs to an accept
>>> or reject state on the basis of the actual behavior specified by this
>>> input.
>>
>> Right, and the ACTUAL BEHAVIOR is defined by what the program does
>> when actually run.
>>
>>> *It is incorrect for them to compute the halt status of non-inputs*
>>>
>>> int sum(int x, int y)
>>> {
>>>    return x + y;
>>> }
>>
>> H(sum, x, y) would need to compute the halt status of that input.
>>
>> Yes, H(D,D) doesn't give the answer to Sum(x,y), but need to give the
>> answer to D(D).
>>
>>>
>>> You might be able to imagine that sum must be able to compute the sum of
>>> non-inputs and say that sum(3,4) derives an incorrect result because it
>>> does not compute the sum of 5 + 7.
>>>
>>
>> So, you are just off serving Red Herring again.
>>
>> H(D,D) MUST answer about the halting status of the program D(D).
> The behavior of D(D) is one recursive invocation away from the actual
> behavior of the actual input.

No, the INPUT is a description of the ACTUAL machine, and the actual
machine is what is being asked about.

So, either you accept that the behavior of the actual machine D(D) is
the problem that is being asked, or you admit that your definitions say
it is impossible to actually ASK the question of the problem.

Remember, the PROBLEM that you claim to be working on is DEFINED to be
aobut the actual machines.

>
> H(D,D) is not allowed to report on what the behavior of its input would
> be after it aborts the simulation of this input because it has not yet
> aborted the simulation of this input.

So, by your definition, H is not allowed to answer the actual question
of the problem.

>
> You remain one recursive invocation away from reality.
>

So, you actually think that the simulation of the thing is more real
than the thing itself.

THAT explains your lunacy, and is why you are just an ignorant
pathological lying idiot.

You seem to be living in a world at least one step from reality, but
unable to be able to discern that.

On 6/10/2023 11:24 AM, Richard Damon wrote:
> On 6/10/23 10:55 AM, olcott wrote:
>> On 6/10/2023 9:32 AM, Richard Damon wrote:
>>> On 6/10/23 10:12 AM, olcott wrote:
>>>> On 6/10/2023 8:54 AM, Richard Damon wrote:
>>>>> On 6/10/23 9:23 AM, olcott wrote:
>>>>>> 01 typedef int (*ptr)(); // pointer to int function
>>>>>> 02 int H(ptr x, ptr y)   // uses x86 emulator to simulate its input
>>>>>> 03
>>>>>> 04 int D(ptr x)
>>>>>> 05 {
>>>>>> 06  int Halt_Status = H(x, x);
>>>>>> 07  if (Halt_Status)
>>>>>> 08    HERE: goto HERE;
>>>>>> 09  return Halt_Status;
>>>>>> 10 }
>>>>>> 11
>>>>>> 12 void main()
>>>>>> 13 {
>>>>>> 14  H(D,D);
>>>>>> 15 }
>>>>>>
>>>>>> When H is a simulating termination analyzer based on an x86 emulator
>>>>>> within the x86utm operating system this is the execution trace of the
>>>>>> above code:
>>>>>>
>>>>>> Line 14: main() calls H(D,D) that simulates D(D)
>>>>>>
>>>>>> keeps repeating:
>>>>>> Line 06: simulated D(D) calls simulated H(D,D) that simulates D(D)
>>>>>> ...
>>>>>
>>>>> So, you are defining that the CORRECT SIMULATION of a call to
>>>>> H(D,D) is that it keeps repeating its simulatin. We will call this
>>>>> stipulation A.
>>>>>
>>>>>>
>>>>>> Simulation invariant:
>>>>>> D correctly simulated by H never reaches its own Line 09.
>>>>>
>>>>> Ok, if you say so. Remember that means that for all calls to H(D,D)
>>>>> it may not return a value. THAT is your invariant.
>>>>>
>>>>>>
>>>>>> This enables H to abort its simulation of D and correctly report that
>>>>>> (its input) D correctly simulated by H never halts. The above is
>>>>>> fully
>>>>>> operational code within the x86utm operating system.
>>>>>> https://github.com/plolcott/x86utm
>>>>>
>>>>> NO, because that volates the stipulation A you made that H(D,D)
>>>>> just keeps simulating its input, and your simulation invariant.
>>>>>
>>>>> Thus, while it may be correct for H to abort its siulation of D at
>>>>> this point, it can't actually do so without breaking its stipulations.
>>>>>
>>>>> IF the code of H actually DOES stop its simulation at this point,
>>>>> then the assumption made in Stipualation A is FALSE, and all
>>>>> following logic is as UNSOUND as your own mind.
>>>>>
>>>>> In fact, that ACTUAL behavior of D(D) calling H(D,D) is that H(D,D)
>>>>> will simulate its input to the point that it sees this simulated
>>>>> D(D) calling H(D,D), then it aborts its simuation and returns to
>>>>> the actual running D(D) the value 0 to indicate non-halting, and
>>>>> that D(D) will Then Halt.
>>>>>
>>>>> Thus, the CORRECT simulation of a the call to H(D,D) that H sees in
>>>>> its simulation of D(D) needs to somehow determine that this call
>>>>> will return a 0, since that is what it does, which means it does
>>>>> NOT do what you claimed at the point of Stipulation A, which just
>>>>> shows you are an ignorant pathological lying idiot.
>>>>>
>>>>>>
>>>>>> *Broadening the Practical Scope of Software Termination Analysis*
>>>>>>
>>>>>> https://www.researchgate.net/publication/369971402_Broadening_the_Practical_Scope_of_Software_Termination_Analysis
>>>>>>
>>>>
>>>>> The DEFINITION of a "Correct Simulation" is that it correctly
>>>>> predicts the behavior of the actual program.
>>>>>
>>>>
>>>> *That is not how termination analyzers works*
>>>
>>> Then it isn't applicaple to the Halting Problem, or, more likely, you
>>> just don't understand what "Termination Analysis" actually is.
>>>
>>>> Termination analyzers compute the mapping from their inputs to an
>>>> accept
>>>> or reject state on the basis of the actual behavior specified by this
>>>> input.
>>>
>>> Right, and the ACTUAL BEHAVIOR is defined by what the program does
>>> when actually run.
>>>
>>>> *It is incorrect for them to compute the halt status of non-inputs*
>>>>
>>>> int sum(int x, int y)
>>>> {
>>>>    return x + y;
>>>> }
>>>
>>> H(sum, x, y) would need to compute the halt status of that input.
>>>
>>> Yes, H(D,D) doesn't give the answer to Sum(x,y), but need to give the
>>> answer to D(D).
>>>
>>>>
>>>> You might be able to imagine that sum must be able to compute the
>>>> sum of
>>>> non-inputs and say that sum(3,4) derives an incorrect result because it
>>>> does not compute the sum of 5 + 7.
>>>>
>>>
>>> So, you are just off serving Red Herring again.
>>>
>>> H(D,D) MUST answer about the halting status of the program D(D).
>> The behavior of D(D) is one recursive invocation away from the actual
>> behavior of the actual input.
>
> No, the INPUT is a description of the ACTUAL machine, and the actual
> machine is what is being asked about.
>
> So, either you accept that the behavior of the actual machine D(D) is
> the problem that is being asked, or you admit that your definitions say
> it is impossible to actually ASK the question of the problem.
>
> Remember, the PROBLEM that you claim to be working on is DEFINED to be
> aobut the actual machines.
>
>
>>
>> H(D,D) is not allowed to report on what the behavior of its input would
>> be after it aborts the simulation of this input because it has not yet
>> aborted the simulation of this input.
>
> So, by your definition, H is not allowed to answer the actual question
> of the problem.
>
A termination analyzer is only asked about the behavior specified by its
input. Try and find anything in any paper about termination analyzers
that are required to report on the behavior of non-inputs.

That is simply not the way that software engineering works.

When we say it this way is becomes much more obvious that your
requirement is pure nonsense. It is the same kind of nonsense as
expecting sum(3,4) (defined above) to return the sum of 5 + 7.

By making the ideas of computer science concrete through software
engineering the incoherence of some of these ideas is made clear.

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

On 6/10/23 1:55 PM, olcott wrote:
> On 6/10/2023 11:24 AM, Richard Damon wrote:
>> On 6/10/23 10:55 AM, olcott wrote:
>>> On 6/10/2023 9:32 AM, Richard Damon wrote:
>>>> On 6/10/23 10:12 AM, olcott wrote:
>>>>> On 6/10/2023 8:54 AM, Richard Damon wrote:
>>>>>> On 6/10/23 9:23 AM, olcott wrote:
>>>>>>> 01 typedef int (*ptr)(); // pointer to int function
>>>>>>> 02 int H(ptr x, ptr y)   // uses x86 emulator to simulate its input
>>>>>>> 03
>>>>>>> 04 int D(ptr x)
>>>>>>> 05 {
>>>>>>> 06  int Halt_Status = H(x, x);
>>>>>>> 07  if (Halt_Status)
>>>>>>> 08    HERE: goto HERE;
>>>>>>> 09  return Halt_Status;
>>>>>>> 10 }
>>>>>>> 11
>>>>>>> 12 void main()
>>>>>>> 13 {
>>>>>>> 14  H(D,D);
>>>>>>> 15 }
>>>>>>>
>>>>>>> When H is a simulating termination analyzer based on an x86 emulator
>>>>>>> within the x86utm operating system this is the execution trace of
>>>>>>> the
>>>>>>> above code:
>>>>>>>
>>>>>>> Line 14: main() calls H(D,D) that simulates D(D)
>>>>>>>
>>>>>>> keeps repeating:
>>>>>>> Line 06: simulated D(D) calls simulated H(D,D) that simulates
>>>>>>> D(D) ...
>>>>>>
>>>>>> So, you are defining that the CORRECT SIMULATION of a call to
>>>>>> H(D,D) is that it keeps repeating its simulatin. We will call this
>>>>>> stipulation A.
>>>>>>
>>>>>>>
>>>>>>> Simulation invariant:
>>>>>>> D correctly simulated by H never reaches its own Line 09.
>>>>>>
>>>>>> Ok, if you say so. Remember that means that for all calls to
>>>>>> H(D,D) it may not return a value. THAT is your invariant.
>>>>>>
>>>>>>>
>>>>>>> This enables H to abort its simulation of D and correctly report
>>>>>>> that
>>>>>>> (its input) D correctly simulated by H never halts. The above is
>>>>>>> fully
>>>>>>> operational code within the x86utm operating system.
>>>>>>> https://github.com/plolcott/x86utm
>>>>>>
>>>>>> NO, because that volates the stipulation A you made that H(D,D)
>>>>>> just keeps simulating its input, and your simulation invariant.
>>>>>>
>>>>>> Thus, while it may be correct for H to abort its siulation of D at
>>>>>> this point, it can't actually do so without breaking its
>>>>>> stipulations.
>>>>>>
>>>>>> IF the code of H actually DOES stop its simulation at this point,
>>>>>> then the assumption made in Stipualation A is FALSE, and all
>>>>>> following logic is as UNSOUND as your own mind.
>>>>>>
>>>>>> In fact, that ACTUAL behavior of D(D) calling H(D,D) is that
>>>>>> H(D,D) will simulate its input to the point that it sees this
>>>>>> simulated D(D) calling H(D,D), then it aborts its simuation and
>>>>>> returns to the actual running D(D) the value 0 to indicate
>>>>>> non-halting, and that D(D) will Then Halt.
>>>>>>
>>>>>> Thus, the CORRECT simulation of a the call to H(D,D) that H sees
>>>>>> in its simulation of D(D) needs to somehow determine that this
>>>>>> call will return a 0, since that is what it does, which means it
>>>>>> does NOT do what you claimed at the point of Stipulation A, which
>>>>>> just shows you are an ignorant pathological lying idiot.
>>>>>>
>>>>>>>
>>>>>>> *Broadening the Practical Scope of Software Termination Analysis*
>>>>>>>
>>>>>>> https://www.researchgate.net/publication/369971402_Broadening_the_Practical_Scope_of_Software_Termination_Analysis
>>>>>>>
>>>>>
>>>>>> The DEFINITION of a "Correct Simulation" is that it correctly
>>>>>> predicts the behavior of the actual program.
>>>>>>
>>>>>
>>>>> *That is not how termination analyzers works*
>>>>
>>>> Then it isn't applicaple to the Halting Problem, or, more likely,
>>>> you just don't understand what "Termination Analysis" actually is.
>>>>
>>>>> Termination analyzers compute the mapping from their inputs to an
>>>>> accept
>>>>> or reject state on the basis of the actual behavior specified by this
>>>>> input.
>>>>
>>>> Right, and the ACTUAL BEHAVIOR is defined by what the program does
>>>> when actually run.
>>>>
>>>>> *It is incorrect for them to compute the halt status of non-inputs*
>>>>>
>>>>> int sum(int x, int y)
>>>>> {
>>>>>    return x + y;
>>>>> }
>>>>
>>>> H(sum, x, y) would need to compute the halt status of that input.
>>>>
>>>> Yes, H(D,D) doesn't give the answer to Sum(x,y), but need to give
>>>> the answer to D(D).
>>>>
>>>>>
>>>>> You might be able to imagine that sum must be able to compute the
>>>>> sum of
>>>>> non-inputs and say that sum(3,4) derives an incorrect result
>>>>> because it
>>>>> does not compute the sum of 5 + 7.
>>>>>
>>>>
>>>> So, you are just off serving Red Herring again.
>>>>
>>>> H(D,D) MUST answer about the halting status of the program D(D).
>>> The behavior of D(D) is one recursive invocation away from the actual
>>> behavior of the actual input.
>>
>> No, the INPUT is a description of the ACTUAL machine, and the actual
>> machine is what is being asked about.
>>
>> So, either you accept that the behavior of the actual machine D(D) is
>> the problem that is being asked, or you admit that your definitions
>> say it is impossible to actually ASK the question of the problem.
>>
>> Remember, the PROBLEM that you claim to be working on is DEFINED to be
>> aobut the actual machines.
>>
>>
>>>
>>> H(D,D) is not allowed to report on what the behavior of its input would
>>> be after it aborts the simulation of this input because it has not yet
>>> aborted the simulation of this input.
>>
>> So, by your definition, H is not allowed to answer the actual question
>> of the problem.
>>
> A termination analyzer is only asked about the behavior specified by its
> input. Try and find anything in any paper about termination analyzers
> that are required to report on the behavior of non-inputs.

But the input is the description of the program in question. H(D,D) is
being asked about D(D).

You have yet to answer that assertation, probably because you haven't
figured out a lie to cover it.

>
> That is simply not the way that software engineering works.

Right, they answer about their inputs, but you don't understand that the
address of D means the program D is the input.

In fact YOUR analysis is the one of a "non-input", as the input D is
clearly calling H, but your H assumes that this call is to "Simulate",
so it isn't seeing the input as it actually is.

>
> When we say it this way is becomes much more obvious that your
> requirement is pure nonsense. It is the same kind of nonsense as
> expecting sum(3,4) (defined above) to return the sum of 5 + 7.

Why do you say that, it is clear that 3 is not 5 and 4 is not 7.

Are you claiming that D is not D?

>
> By making the ideas of computer science concrete through software
> engineering the incoherence of some of these ideas is made clear.
>

But you seem to not understand either, or are just a pathological liar.

You whole arguement is built on lies because you have no understand of
what is actually truth.

On 6/10/2023 1:50 PM, Richard Damon wrote:
> On 6/10/23 1:55 PM, olcott wrote:
>> On 6/10/2023 11:24 AM, Richard Damon wrote:
>>> On 6/10/23 10:55 AM, olcott wrote:
>>>> On 6/10/2023 9:32 AM, Richard Damon wrote:
>>>>> On 6/10/23 10:12 AM, olcott wrote:
>>>>>> On 6/10/2023 8:54 AM, Richard Damon wrote:
>>>>>>> On 6/10/23 9:23 AM, olcott wrote:
>>>>>>>> 01 typedef int (*ptr)(); // pointer to int function
>>>>>>>> 02 int H(ptr x, ptr y)   // uses x86 emulator to simulate its input
>>>>>>>> 03
>>>>>>>> 04 int D(ptr x)
>>>>>>>> 05 {
>>>>>>>> 06  int Halt_Status = H(x, x);
>>>>>>>> 07  if (Halt_Status)
>>>>>>>> 08    HERE: goto HERE;
>>>>>>>> 09  return Halt_Status;
>>>>>>>> 10 }
>>>>>>>> 11
>>>>>>>> 12 void main()
>>>>>>>> 13 {
>>>>>>>> 14  H(D,D);
>>>>>>>> 15 }
>>>>>>>>
>>>>>>>> When H is a simulating termination analyzer based on an x86
>>>>>>>> emulator
>>>>>>>> within the x86utm operating system this is the execution trace
>>>>>>>> of the
>>>>>>>> above code:
>>>>>>>>
>>>>>>>> Line 14: main() calls H(D,D) that simulates D(D)
>>>>>>>>
>>>>>>>> keeps repeating:
>>>>>>>> Line 06: simulated D(D) calls simulated H(D,D) that simulates
>>>>>>>> D(D) ...
>>>>>>>
>>>>>>> So, you are defining that the CORRECT SIMULATION of a call to
>>>>>>> H(D,D) is that it keeps repeating its simulatin. We will call
>>>>>>> this stipulation A.
>>>>>>>
>>>>>>>>
>>>>>>>> Simulation invariant:
>>>>>>>> D correctly simulated by H never reaches its own Line 09.
>>>>>>>
>>>>>>> Ok, if you say so. Remember that means that for all calls to
>>>>>>> H(D,D) it may not return a value. THAT is your invariant.
>>>>>>>
>>>>>>>>
>>>>>>>> This enables H to abort its simulation of D and correctly report
>>>>>>>> that
>>>>>>>> (its input) D correctly simulated by H never halts. The above is
>>>>>>>> fully
>>>>>>>> operational code within the x86utm operating system.
>>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>
>>>>>>> NO, because that volates the stipulation A you made that H(D,D)
>>>>>>> just keeps simulating its input, and your simulation invariant.
>>>>>>>
>>>>>>> Thus, while it may be correct for H to abort its siulation of D
>>>>>>> at this point, it can't actually do so without breaking its
>>>>>>> stipulations.
>>>>>>>
>>>>>>> IF the code of H actually DOES stop its simulation at this point,
>>>>>>> then the assumption made in Stipualation A is FALSE, and all
>>>>>>> following logic is as UNSOUND as your own mind.
>>>>>>>
>>>>>>> In fact, that ACTUAL behavior of D(D) calling H(D,D) is that
>>>>>>> H(D,D) will simulate its input to the point that it sees this
>>>>>>> simulated D(D) calling H(D,D), then it aborts its simuation and
>>>>>>> returns to the actual running D(D) the value 0 to indicate
>>>>>>> non-halting, and that D(D) will Then Halt.
>>>>>>>
>>>>>>> Thus, the CORRECT simulation of a the call to H(D,D) that H sees
>>>>>>> in its simulation of D(D) needs to somehow determine that this
>>>>>>> call will return a 0, since that is what it does, which means it
>>>>>>> does NOT do what you claimed at the point of Stipulation A, which
>>>>>>> just shows you are an ignorant pathological lying idiot.
>>>>>>>
>>>>>>>>
>>>>>>>> *Broadening the Practical Scope of Software Termination Analysis*
>>>>>>>>
>>>>>>>> https://www.researchgate.net/publication/369971402_Broadening_the_Practical_Scope_of_Software_Termination_Analysis
>>>>>>>>
>>>>>>
>>>>>>> The DEFINITION of a "Correct Simulation" is that it correctly
>>>>>>> predicts the behavior of the actual program.
>>>>>>>
>>>>>>
>>>>>> *That is not how termination analyzers works*
>>>>>
>>>>> Then it isn't applicaple to the Halting Problem, or, more likely,
>>>>> you just don't understand what "Termination Analysis" actually is.
>>>>>
>>>>>> Termination analyzers compute the mapping from their inputs to an
>>>>>> accept
>>>>>> or reject state on the basis of the actual behavior specified by this
>>>>>> input.
>>>>>
>>>>> Right, and the ACTUAL BEHAVIOR is defined by what the program does
>>>>> when actually run.
>>>>>
>>>>>> *It is incorrect for them to compute the halt status of non-inputs*
>>>>>>
>>>>>> int sum(int x, int y)
>>>>>> {
>>>>>>    return x + y;
>>>>>> }
>>>>>
>>>>> H(sum, x, y) would need to compute the halt status of that input.
>>>>>
>>>>> Yes, H(D,D) doesn't give the answer to Sum(x,y), but need to give
>>>>> the answer to D(D).
>>>>>
>>>>>>
>>>>>> You might be able to imagine that sum must be able to compute the
>>>>>> sum of
>>>>>> non-inputs and say that sum(3,4) derives an incorrect result
>>>>>> because it
>>>>>> does not compute the sum of 5 + 7.
>>>>>>
>>>>>
>>>>> So, you are just off serving Red Herring again.
>>>>>
>>>>> H(D,D) MUST answer about the halting status of the program D(D).
>>>> The behavior of D(D) is one recursive invocation away from the actual
>>>> behavior of the actual input.
>>>
>>> No, the INPUT is a description of the ACTUAL machine, and the actual
>>> machine is what is being asked about.
>>>
>>> So, either you accept that the behavior of the actual machine D(D) is
>>> the problem that is being asked, or you admit that your definitions
>>> say it is impossible to actually ASK the question of the problem.
>>>
>>> Remember, the PROBLEM that you claim to be working on is DEFINED to
>>> be aobut the actual machines.
>>>
>>>
>>>>
>>>> H(D,D) is not allowed to report on what the behavior of its input would
>>>> be after it aborts the simulation of this input because it has not yet
>>>> aborted the simulation of this input.
>>>
>>> So, by your definition, H is not allowed to answer the actual
>>> question of the problem.
>>>
>> A termination analyzer is only asked about the behavior specified by its
>> input. Try and find anything in any paper about termination analyzers
>> that are required to report on the behavior of non-inputs.
>
>
> But the input is the description of the program in question. H(D,D) is
> being asked about D(D).
>

Not when there is a pathological relationship between H and D that
changes the behavior of the input D away from the behavior of D(D).

Because a termination analyzer always reports on the behavior of its
input H(D,D) must reject this input as non-halting.

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

On 6/10/23 3:57 PM, olcott wrote:
> On 6/10/2023 1:50 PM, Richard Damon wrote:
>> On 6/10/23 1:55 PM, olcott wrote:
>>> On 6/10/2023 11:24 AM, Richard Damon wrote:
>>>> On 6/10/23 10:55 AM, olcott wrote:
>>>>> On 6/10/2023 9:32 AM, Richard Damon wrote:
>>>>>> On 6/10/23 10:12 AM, olcott wrote:
>>>>>>> On 6/10/2023 8:54 AM, Richard Damon wrote:
>>>>>>>> On 6/10/23 9:23 AM, olcott wrote:
>>>>>>>>> 01 typedef int (*ptr)(); // pointer to int function
>>>>>>>>> 02 int H(ptr x, ptr y)   // uses x86 emulator to simulate its
>>>>>>>>> input
>>>>>>>>> 03
>>>>>>>>> 04 int D(ptr x)
>>>>>>>>> 05 {
>>>>>>>>> 06  int Halt_Status = H(x, x);
>>>>>>>>> 07  if (Halt_Status)
>>>>>>>>> 08    HERE: goto HERE;
>>>>>>>>> 09  return Halt_Status;
>>>>>>>>> 10 }
>>>>>>>>> 11
>>>>>>>>> 12 void main()
>>>>>>>>> 13 {
>>>>>>>>> 14  H(D,D);
>>>>>>>>> 15 }
>>>>>>>>>
>>>>>>>>> When H is a simulating termination analyzer based on an x86
>>>>>>>>> emulator
>>>>>>>>> within the x86utm operating system this is the execution trace
>>>>>>>>> of the
>>>>>>>>> above code:
>>>>>>>>>
>>>>>>>>> Line 14: main() calls H(D,D) that simulates D(D)
>>>>>>>>>
>>>>>>>>> keeps repeating:
>>>>>>>>> Line 06: simulated D(D) calls simulated H(D,D) that simulates
>>>>>>>>> D(D) ...
>>>>>>>>
>>>>>>>> So, you are defining that the CORRECT SIMULATION of a call to
>>>>>>>> H(D,D) is that it keeps repeating its simulatin. We will call
>>>>>>>> this stipulation A.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Simulation invariant:
>>>>>>>>> D correctly simulated by H never reaches its own Line 09.
>>>>>>>>
>>>>>>>> Ok, if you say so. Remember that means that for all calls to
>>>>>>>> H(D,D) it may not return a value. THAT is your invariant.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> This enables H to abort its simulation of D and correctly
>>>>>>>>> report that
>>>>>>>>> (its input) D correctly simulated by H never halts. The above
>>>>>>>>> is fully
>>>>>>>>> operational code within the x86utm operating system.
>>>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>>
>>>>>>>> NO, because that volates the stipulation A you made that H(D,D)
>>>>>>>> just keeps simulating its input, and your simulation invariant.
>>>>>>>>
>>>>>>>> Thus, while it may be correct for H to abort its siulation of D
>>>>>>>> at this point, it can't actually do so without breaking its
>>>>>>>> stipulations.
>>>>>>>>
>>>>>>>> IF the code of H actually DOES stop its simulation at this
>>>>>>>> point, then the assumption made in Stipualation A is FALSE, and
>>>>>>>> all following logic is as UNSOUND as your own mind.
>>>>>>>>
>>>>>>>> In fact, that ACTUAL behavior of D(D) calling H(D,D) is that
>>>>>>>> H(D,D) will simulate its input to the point that it sees this
>>>>>>>> simulated D(D) calling H(D,D), then it aborts its simuation and
>>>>>>>> returns to the actual running D(D) the value 0 to indicate
>>>>>>>> non-halting, and that D(D) will Then Halt.
>>>>>>>>
>>>>>>>> Thus, the CORRECT simulation of a the call to H(D,D) that H sees
>>>>>>>> in its simulation of D(D) needs to somehow determine that this
>>>>>>>> call will return a 0, since that is what it does, which means it
>>>>>>>> does NOT do what you claimed at the point of Stipulation A,
>>>>>>>> which just shows you are an ignorant pathological lying idiot.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Broadening the Practical Scope of Software Termination Analysis*
>>>>>>>>>
>>>>>>>>> https://www.researchgate.net/publication/369971402_Broadening_the_Practical_Scope_of_Software_Termination_Analysis
>>>>>>>>>
>>>>>>>
>>>>>>>> The DEFINITION of a "Correct Simulation" is that it correctly
>>>>>>>> predicts the behavior of the actual program.
>>>>>>>>
>>>>>>>
>>>>>>> *That is not how termination analyzers works*
>>>>>>
>>>>>> Then it isn't applicaple to the Halting Problem, or, more likely,
>>>>>> you just don't understand what "Termination Analysis" actually is.
>>>>>>
>>>>>>> Termination analyzers compute the mapping from their inputs to an
>>>>>>> accept
>>>>>>> or reject state on the basis of the actual behavior specified by
>>>>>>> this
>>>>>>> input.
>>>>>>
>>>>>> Right, and the ACTUAL BEHAVIOR is defined by what the program does
>>>>>> when actually run.
>>>>>>
>>>>>>> *It is incorrect for them to compute the halt status of non-inputs*
>>>>>>>
>>>>>>> int sum(int x, int y)
>>>>>>> {
>>>>>>>    return x + y;
>>>>>>> }
>>>>>>
>>>>>> H(sum, x, y) would need to compute the halt status of that input.
>>>>>>
>>>>>> Yes, H(D,D) doesn't give the answer to Sum(x,y), but need to give
>>>>>> the answer to D(D).
>>>>>>
>>>>>>>
>>>>>>> You might be able to imagine that sum must be able to compute the
>>>>>>> sum of
>>>>>>> non-inputs and say that sum(3,4) derives an incorrect result
>>>>>>> because it
>>>>>>> does not compute the sum of 5 + 7.
>>>>>>>
>>>>>>
>>>>>> So, you are just off serving Red Herring again.
>>>>>>
>>>>>> H(D,D) MUST answer about the halting status of the program D(D).
>>>>> The behavior of D(D) is one recursive invocation away from the actual
>>>>> behavior of the actual input.
>>>>
>>>> No, the INPUT is a description of the ACTUAL machine, and the actual
>>>> machine is what is being asked about.
>>>>
>>>> So, either you accept that the behavior of the actual machine D(D)
>>>> is the problem that is being asked, or you admit that your
>>>> definitions say it is impossible to actually ASK the question of the
>>>> problem.
>>>>
>>>> Remember, the PROBLEM that you claim to be working on is DEFINED to
>>>> be aobut the actual machines.
>>>>
>>>>
>>>>>
>>>>> H(D,D) is not allowed to report on what the behavior of its input
>>>>> would
>>>>> be after it aborts the simulation of this input because it has not yet
>>>>> aborted the simulation of this input.
>>>>
>>>> So, by your definition, H is not allowed to answer the actual
>>>> question of the problem.
>>>>
>>> A termination analyzer is only asked about the behavior specified by its
>>> input. Try and find anything in any paper about termination analyzers
>>> that are required to report on the behavior of non-inputs.
>>
>>
>> But the input is the description of the program in question. H(D,D) is
>> being asked about D(D).
>>
>
> Not when there is a pathological relationship between H and D that
> changes the behavior of the input D away from the behavior of D(D).
>
> Because a termination analyzer always reports on the behavior of its
> input H(D,D) must reject this input as non-halting.
>

On 6/10/2023 3:27 PM, Richard Damon wrote:
> On 6/10/23 3:57 PM, olcott wrote:
>> On 6/10/2023 1:50 PM, Richard Damon wrote:
>>> On 6/10/23 1:55 PM, olcott wrote:
>>>> On 6/10/2023 11:24 AM, Richard Damon wrote:
>>>>> On 6/10/23 10:55 AM, olcott wrote:
>>>>>> On 6/10/2023 9:32 AM, Richard Damon wrote:
>>>>>>> On 6/10/23 10:12 AM, olcott wrote:
>>>>>>>> On 6/10/2023 8:54 AM, Richard Damon wrote:
>>>>>>>>> On 6/10/23 9:23 AM, olcott wrote:
>>>>>>>>>> 01 typedef int (*ptr)(); // pointer to int function
>>>>>>>>>> 02 int H(ptr x, ptr y)   // uses x86 emulator to simulate its
>>>>>>>>>> input
>>>>>>>>>> 03
>>>>>>>>>> 04 int D(ptr x)
>>>>>>>>>> 05 {
>>>>>>>>>> 06  int Halt_Status = H(x, x);
>>>>>>>>>> 07  if (Halt_Status)
>>>>>>>>>> 08    HERE: goto HERE;
>>>>>>>>>> 09  return Halt_Status;
>>>>>>>>>> 10 }
>>>>>>>>>> 11
>>>>>>>>>> 12 void main()
>>>>>>>>>> 13 {
>>>>>>>>>> 14  H(D,D);
>>>>>>>>>> 15 }
>>>>>>>>>>
>>>>>>>>>> When H is a simulating termination analyzer based on an x86
>>>>>>>>>> emulator
>>>>>>>>>> within the x86utm operating system this is the execution trace
>>>>>>>>>> of the
>>>>>>>>>> above code:
>>>>>>>>>>
>>>>>>>>>> Line 14: main() calls H(D,D) that simulates D(D)
>>>>>>>>>>
>>>>>>>>>> keeps repeating:
>>>>>>>>>> Line 06: simulated D(D) calls simulated H(D,D) that simulates
>>>>>>>>>> D(D) ...
>>>>>>>>>
>>>>>>>>> So, you are defining that the CORRECT SIMULATION of a call to
>>>>>>>>> H(D,D) is that it keeps repeating its simulatin. We will call
>>>>>>>>> this stipulation A.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Simulation invariant:
>>>>>>>>>> D correctly simulated by H never reaches its own Line 09.
>>>>>>>>>
>>>>>>>>> Ok, if you say so. Remember that means that for all calls to
>>>>>>>>> H(D,D) it may not return a value. THAT is your invariant.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This enables H to abort its simulation of D and correctly
>>>>>>>>>> report that
>>>>>>>>>> (its input) D correctly simulated by H never halts. The above
>>>>>>>>>> is fully
>>>>>>>>>> operational code within the x86utm operating system.
>>>>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>>>
>>>>>>>>> NO, because that volates the stipulation A you made that H(D,D)
>>>>>>>>> just keeps simulating its input, and your simulation invariant.
>>>>>>>>>
>>>>>>>>> Thus, while it may be correct for H to abort its siulation of D
>>>>>>>>> at this point, it can't actually do so without breaking its
>>>>>>>>> stipulations.
>>>>>>>>>
>>>>>>>>> IF the code of H actually DOES stop its simulation at this
>>>>>>>>> point, then the assumption made in Stipualation A is FALSE, and
>>>>>>>>> all following logic is as UNSOUND as your own mind.
>>>>>>>>>
>>>>>>>>> In fact, that ACTUAL behavior of D(D) calling H(D,D) is that
>>>>>>>>> H(D,D) will simulate its input to the point that it sees this
>>>>>>>>> simulated D(D) calling H(D,D), then it aborts its simuation and
>>>>>>>>> returns to the actual running D(D) the value 0 to indicate
>>>>>>>>> non-halting, and that D(D) will Then Halt.
>>>>>>>>>
>>>>>>>>> Thus, the CORRECT simulation of a the call to H(D,D) that H
>>>>>>>>> sees in its simulation of D(D) needs to somehow determine that
>>>>>>>>> this call will return a 0, since that is what it does, which
>>>>>>>>> means it does NOT do what you claimed at the point of
>>>>>>>>> Stipulation A, which just shows you are an ignorant
>>>>>>>>> pathological lying idiot.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *Broadening the Practical Scope of Software Termination Analysis*
>>>>>>>>>>
>>>>>>>>>> https://www.researchgate.net/publication/369971402_Broadening_the_Practical_Scope_of_Software_Termination_Analysis
>>>>>>>>>>
>>>>>>>>
>>>>>>>>> The DEFINITION of a "Correct Simulation" is that it correctly
>>>>>>>>> predicts the behavior of the actual program.
>>>>>>>>>
>>>>>>>>
>>>>>>>> *That is not how termination analyzers works*
>>>>>>>
>>>>>>> Then it isn't applicaple to the Halting Problem, or, more likely,
>>>>>>> you just don't understand what "Termination Analysis" actually is.
>>>>>>>
>>>>>>>> Termination analyzers compute the mapping from their inputs to
>>>>>>>> an accept
>>>>>>>> or reject state on the basis of the actual behavior specified by
>>>>>>>> this
>>>>>>>> input.
>>>>>>>
>>>>>>> Right, and the ACTUAL BEHAVIOR is defined by what the program
>>>>>>> does when actually run.
>>>>>>>
>>>>>>>> *It is incorrect for them to compute the halt status of non-inputs*
>>>>>>>>
>>>>>>>> int sum(int x, int y)
>>>>>>>> {
>>>>>>>>    return x + y;
>>>>>>>> }
>>>>>>>
>>>>>>> H(sum, x, y) would need to compute the halt status of that input.
>>>>>>>
>>>>>>> Yes, H(D,D) doesn't give the answer to Sum(x,y), but need to give
>>>>>>> the answer to D(D).
>>>>>>>
>>>>>>>>
>>>>>>>> You might be able to imagine that sum must be able to compute
>>>>>>>> the sum of
>>>>>>>> non-inputs and say that sum(3,4) derives an incorrect result
>>>>>>>> because it
>>>>>>>> does not compute the sum of 5 + 7.
>>>>>>>>
>>>>>>>
>>>>>>> So, you are just off serving Red Herring again.
>>>>>>>
>>>>>>> H(D,D) MUST answer about the halting status of the program D(D).
>>>>>> The behavior of D(D) is one recursive invocation away from the actual
>>>>>> behavior of the actual input.
>>>>>
>>>>> No, the INPUT is a description of the ACTUAL machine, and the
>>>>> actual machine is what is being asked about.
>>>>>
>>>>> So, either you accept that the behavior of the actual machine D(D)
>>>>> is the problem that is being asked, or you admit that your
>>>>> definitions say it is impossible to actually ASK the question of
>>>>> the problem.
>>>>>
>>>>> Remember, the PROBLEM that you claim to be working on is DEFINED to
>>>>> be aobut the actual machines.
>>>>>
>>>>>
>>>>>>
>>>>>> H(D,D) is not allowed to report on what the behavior of its input
>>>>>> would
>>>>>> be after it aborts the simulation of this input because it has not
>>>>>> yet
>>>>>> aborted the simulation of this input.
>>>>>
>>>>> So, by your definition, H is not allowed to answer the actual
>>>>> question of the problem.
>>>>>
>>>> A termination analyzer is only asked about the behavior specified by
>>>> its
>>>> input. Try and find anything in any paper about termination analyzers
>>>> that are required to report on the behavior of non-inputs.
>>>
>>>
>>> But the input is the description of the program in question. H(D,D)
>>> is being asked about D(D).
>>>
>>
>> Not when there is a pathological relationship between H and D that
>> changes the behavior of the input D away from the behavior of D(D).
>>
>> Because a termination analyzer always reports on the behavior of its
>> input H(D,D) must reject this input as non-halting.
>>
>
> Where do you get that statement from?
>
Feel free to counter my claim by finding a published paper where a
termination analyzer operates on something besides its input.

On 6/10/23 5:06 PM, olcott wrote:
> On 6/10/2023 3:27 PM, Richard Damon wrote:
>> On 6/10/23 3:57 PM, olcott wrote:
>>> On 6/10/2023 1:50 PM, Richard Damon wrote:
>>>> On 6/10/23 1:55 PM, olcott wrote:
>>>>> On 6/10/2023 11:24 AM, Richard Damon wrote:
>>>>>> On 6/10/23 10:55 AM, olcott wrote:
>>>>>>> On 6/10/2023 9:32 AM, Richard Damon wrote:
>>>>>>>> On 6/10/23 10:12 AM, olcott wrote:
>>>>>>>>> On 6/10/2023 8:54 AM, Richard Damon wrote:
>>>>>>>>>> On 6/10/23 9:23 AM, olcott wrote:
>>>>>>>>>>> 01 typedef int (*ptr)(); // pointer to int function
>>>>>>>>>>> 02 int H(ptr x, ptr y)   // uses x86 emulator to simulate its
>>>>>>>>>>> input
>>>>>>>>>>> 03
>>>>>>>>>>> 04 int D(ptr x)
>>>>>>>>>>> 05 {
>>>>>>>>>>> 06  int Halt_Status = H(x, x);
>>>>>>>>>>> 07  if (Halt_Status)
>>>>>>>>>>> 08    HERE: goto HERE;
>>>>>>>>>>> 09  return Halt_Status;
>>>>>>>>>>> 10 }
>>>>>>>>>>> 11
>>>>>>>>>>> 12 void main()
>>>>>>>>>>> 13 {
>>>>>>>>>>> 14  H(D,D);
>>>>>>>>>>> 15 }
>>>>>>>>>>>
>>>>>>>>>>> When H is a simulating termination analyzer based on an x86
>>>>>>>>>>> emulator
>>>>>>>>>>> within the x86utm operating system this is the execution
>>>>>>>>>>> trace of the
>>>>>>>>>>> above code:
>>>>>>>>>>>
>>>>>>>>>>> Line 14: main() calls H(D,D) that simulates D(D)
>>>>>>>>>>>
>>>>>>>>>>> keeps repeating:
>>>>>>>>>>> Line 06: simulated D(D) calls simulated H(D,D) that simulates
>>>>>>>>>>> D(D) ...
>>>>>>>>>>
>>>>>>>>>> So, you are defining that the CORRECT SIMULATION of a call to
>>>>>>>>>> H(D,D) is that it keeps repeating its simulatin. We will call
>>>>>>>>>> this stipulation A.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Simulation invariant:
>>>>>>>>>>> D correctly simulated by H never reaches its own Line 09.
>>>>>>>>>>
>>>>>>>>>> Ok, if you say so. Remember that means that for all calls to
>>>>>>>>>> H(D,D) it may not return a value. THAT is your invariant.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This enables H to abort its simulation of D and correctly
>>>>>>>>>>> report that
>>>>>>>>>>> (its input) D correctly simulated by H never halts. The above
>>>>>>>>>>> is fully
>>>>>>>>>>> operational code within the x86utm operating system.
>>>>>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>>>>
>>>>>>>>>> NO, because that volates the stipulation A you made that
>>>>>>>>>> H(D,D) just keeps simulating its input, and your simulation
>>>>>>>>>> invariant.
>>>>>>>>>>
>>>>>>>>>> Thus, while it may be correct for H to abort its siulation of
>>>>>>>>>> D at this point, it can't actually do so without breaking its
>>>>>>>>>> stipulations.
>>>>>>>>>>
>>>>>>>>>> IF the code of H actually DOES stop its simulation at this
>>>>>>>>>> point, then the assumption made in Stipualation A is FALSE,
>>>>>>>>>> and all following logic is as UNSOUND as your own mind.
>>>>>>>>>>
>>>>>>>>>> In fact, that ACTUAL behavior of D(D) calling H(D,D) is that
>>>>>>>>>> H(D,D) will simulate its input to the point that it sees this
>>>>>>>>>> simulated D(D) calling H(D,D), then it aborts its simuation
>>>>>>>>>> and returns to the actual running D(D) the value 0 to indicate
>>>>>>>>>> non-halting, and that D(D) will Then Halt.
>>>>>>>>>>
>>>>>>>>>> Thus, the CORRECT simulation of a the call to H(D,D) that H
>>>>>>>>>> sees in its simulation of D(D) needs to somehow determine that
>>>>>>>>>> this call will return a 0, since that is what it does, which
>>>>>>>>>> means it does NOT do what you claimed at the point of
>>>>>>>>>> Stipulation A, which just shows you are an ignorant
>>>>>>>>>> pathological lying idiot.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *Broadening the Practical Scope of Software Termination
>>>>>>>>>>> Analysis*
>>>>>>>>>>>
>>>>>>>>>>> https://www.researchgate.net/publication/369971402_Broadening_the_Practical_Scope_of_Software_Termination_Analysis
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> The DEFINITION of a "Correct Simulation" is that it correctly
>>>>>>>>>> predicts the behavior of the actual program.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *That is not how termination analyzers works*
>>>>>>>>
>>>>>>>> Then it isn't applicaple to the Halting Problem, or, more
>>>>>>>> likely, you just don't understand what "Termination Analysis"
>>>>>>>> actually is.
>>>>>>>>
>>>>>>>>> Termination analyzers compute the mapping from their inputs to
>>>>>>>>> an accept
>>>>>>>>> or reject state on the basis of the actual behavior specified
>>>>>>>>> by this
>>>>>>>>> input.
>>>>>>>>
>>>>>>>> Right, and the ACTUAL BEHAVIOR is defined by what the program
>>>>>>>> does when actually run.
>>>>>>>>
>>>>>>>>> *It is incorrect for them to compute the halt status of
>>>>>>>>> non-inputs*
>>>>>>>>>
>>>>>>>>> int sum(int x, int y)
>>>>>>>>> {
>>>>>>>>>    return x + y;
>>>>>>>>> }
>>>>>>>>
>>>>>>>> H(sum, x, y) would need to compute the halt status of that input.
>>>>>>>>
>>>>>>>> Yes, H(D,D) doesn't give the answer to Sum(x,y), but need to
>>>>>>>> give the answer to D(D).
>>>>>>>>
>>>>>>>>>
>>>>>>>>> You might be able to imagine that sum must be able to compute
>>>>>>>>> the sum of
>>>>>>>>> non-inputs and say that sum(3,4) derives an incorrect result
>>>>>>>>> because it
>>>>>>>>> does not compute the sum of 5 + 7.
>>>>>>>>>
>>>>>>>>
>>>>>>>> So, you are just off serving Red Herring again.
>>>>>>>>
>>>>>>>> H(D,D) MUST answer about the halting status of the program D(D).
>>>>>>> The behavior of D(D) is one recursive invocation away from the
>>>>>>> actual
>>>>>>> behavior of the actual input.
>>>>>>
>>>>>> No, the INPUT is a description of the ACTUAL machine, and the
>>>>>> actual machine is what is being asked about.
>>>>>>
>>>>>> So, either you accept that the behavior of the actual machine D(D)
>>>>>> is the problem that is being asked, or you admit that your
>>>>>> definitions say it is impossible to actually ASK the question of
>>>>>> the problem.
>>>>>>
>>>>>> Remember, the PROBLEM that you claim to be working on is DEFINED
>>>>>> to be aobut the actual machines.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> H(D,D) is not allowed to report on what the behavior of its input
>>>>>>> would
>>>>>>> be after it aborts the simulation of this input because it has
>>>>>>> not yet
>>>>>>> aborted the simulation of this input.
>>>>>>
>>>>>> So, by your definition, H is not allowed to answer the actual
>>>>>> question of the problem.
>>>>>>
>>>>> A termination analyzer is only asked about the behavior specified
>>>>> by its
>>>>> input. Try and find anything in any paper about termination analyzers
>>>>> that are required to report on the behavior of non-inputs.
>>>>
>>>>
>>>> But the input is the description of the program in question. H(D,D)
>>>> is being asked about D(D).
>>>>
>>>
>>> Not when there is a pathological relationship between H and D that
>>> changes the behavior of the input D away from the behavior of D(D).
>>>
>>> Because a termination analyzer always reports on the behavior of its
>>> input H(D,D) must reject this input as non-halting.
>>>
>>
>> Where do you get that statement from?
>>
> Feel free to counter my claim by finding a published paper where a
> termination analyzer operates on something besides its input.
>

On 6/10/2023 4:15 PM, Richard Damon wrote:
> On 6/10/23 5:06 PM, olcott wrote:
>> On 6/10/2023 3:27 PM, Richard Damon wrote:
>>> On 6/10/23 3:57 PM, olcott wrote:
>>>> On 6/10/2023 1:50 PM, Richard Damon wrote:
>>>>> On 6/10/23 1:55 PM, olcott wrote:
>>>>>> On 6/10/2023 11:24 AM, Richard Damon wrote:
>>>>>>> On 6/10/23 10:55 AM, olcott wrote:
>>>>>>>> On 6/10/2023 9:32 AM, Richard Damon wrote:
>>>>>>>>> On 6/10/23 10:12 AM, olcott wrote:
>>>>>>>>>> On 6/10/2023 8:54 AM, Richard Damon wrote:
>>>>>>>>>>> On 6/10/23 9:23 AM, olcott wrote:
>>>>>>>>>>>> 01 typedef int (*ptr)(); // pointer to int function
>>>>>>>>>>>> 02 int H(ptr x, ptr y)   // uses x86 emulator to simulate
>>>>>>>>>>>> its input
>>>>>>>>>>>> 03
>>>>>>>>>>>> 04 int D(ptr x)
>>>>>>>>>>>> 05 {
>>>>>>>>>>>> 06  int Halt_Status = H(x, x);
>>>>>>>>>>>> 07  if (Halt_Status)
>>>>>>>>>>>> 08    HERE: goto HERE;
>>>>>>>>>>>> 09  return Halt_Status;
>>>>>>>>>>>> 10 }
>>>>>>>>>>>> 11
>>>>>>>>>>>> 12 void main()
>>>>>>>>>>>> 13 {
>>>>>>>>>>>> 14  H(D,D);
>>>>>>>>>>>> 15 }
>>>>>>>>>>>>
>>>>>>>>>>>> When H is a simulating termination analyzer based on an x86
>>>>>>>>>>>> emulator
>>>>>>>>>>>> within the x86utm operating system this is the execution
>>>>>>>>>>>> trace of the
>>>>>>>>>>>> above code:
>>>>>>>>>>>>
>>>>>>>>>>>> Line 14: main() calls H(D,D) that simulates D(D)
>>>>>>>>>>>>
>>>>>>>>>>>> keeps repeating:
>>>>>>>>>>>> Line 06: simulated D(D) calls simulated H(D,D) that
>>>>>>>>>>>> simulates D(D) ...
>>>>>>>>>>>
>>>>>>>>>>> So, you are defining that the CORRECT SIMULATION of a call to
>>>>>>>>>>> H(D,D) is that it keeps repeating its simulatin. We will call
>>>>>>>>>>> this stipulation A.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Simulation invariant:
>>>>>>>>>>>> D correctly simulated by H never reaches its own Line 09.
>>>>>>>>>>>
>>>>>>>>>>> Ok, if you say so. Remember that means that for all calls to
>>>>>>>>>>> H(D,D) it may not return a value. THAT is your invariant.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This enables H to abort its simulation of D and correctly
>>>>>>>>>>>> report that
>>>>>>>>>>>> (its input) D correctly simulated by H never halts. The
>>>>>>>>>>>> above is fully
>>>>>>>>>>>> operational code within the x86utm operating system.
>>>>>>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>>>>>
>>>>>>>>>>> NO, because that volates the stipulation A you made that
>>>>>>>>>>> H(D,D) just keeps simulating its input, and your simulation
>>>>>>>>>>> invariant.
>>>>>>>>>>>
>>>>>>>>>>> Thus, while it may be correct for H to abort its siulation of
>>>>>>>>>>> D at this point, it can't actually do so without breaking its
>>>>>>>>>>> stipulations.
>>>>>>>>>>>
>>>>>>>>>>> IF the code of H actually DOES stop its simulation at this
>>>>>>>>>>> point, then the assumption made in Stipualation A is FALSE,
>>>>>>>>>>> and all following logic is as UNSOUND as your own mind.
>>>>>>>>>>>
>>>>>>>>>>> In fact, that ACTUAL behavior of D(D) calling H(D,D) is that
>>>>>>>>>>> H(D,D) will simulate its input to the point that it sees this
>>>>>>>>>>> simulated D(D) calling H(D,D), then it aborts its simuation
>>>>>>>>>>> and returns to the actual running D(D) the value 0 to
>>>>>>>>>>> indicate non-halting, and that D(D) will Then Halt.
>>>>>>>>>>>
>>>>>>>>>>> Thus, the CORRECT simulation of a the call to H(D,D) that H
>>>>>>>>>>> sees in its simulation of D(D) needs to somehow determine
>>>>>>>>>>> that this call will return a 0, since that is what it does,
>>>>>>>>>>> which means it does NOT do what you claimed at the point of
>>>>>>>>>>> Stipulation A, which just shows you are an ignorant
>>>>>>>>>>> pathological lying idiot.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> *Broadening the Practical Scope of Software Termination
>>>>>>>>>>>> Analysis*
>>>>>>>>>>>>
>>>>>>>>>>>> https://www.researchgate.net/publication/369971402_Broadening_the_Practical_Scope_of_Software_Termination_Analysis
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> The DEFINITION of a "Correct Simulation" is that it correctly
>>>>>>>>>>> predicts the behavior of the actual program.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *That is not how termination analyzers works*
>>>>>>>>>
>>>>>>>>> Then it isn't applicaple to the Halting Problem, or, more
>>>>>>>>> likely, you just don't understand what "Termination Analysis"
>>>>>>>>> actually is.
>>>>>>>>>
>>>>>>>>>> Termination analyzers compute the mapping from their inputs to
>>>>>>>>>> an accept
>>>>>>>>>> or reject state on the basis of the actual behavior specified
>>>>>>>>>> by this
>>>>>>>>>> input.
>>>>>>>>>
>>>>>>>>> Right, and the ACTUAL BEHAVIOR is defined by what the program
>>>>>>>>> does when actually run.
>>>>>>>>>
>>>>>>>>>> *It is incorrect for them to compute the halt status of
>>>>>>>>>> non-inputs*
>>>>>>>>>>
>>>>>>>>>> int sum(int x, int y)
>>>>>>>>>> {
>>>>>>>>>>    return x + y;
>>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> H(sum, x, y) would need to compute the halt status of that input.
>>>>>>>>>
>>>>>>>>> Yes, H(D,D) doesn't give the answer to Sum(x,y), but need to
>>>>>>>>> give the answer to D(D).
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> You might be able to imagine that sum must be able to compute
>>>>>>>>>> the sum of
>>>>>>>>>> non-inputs and say that sum(3,4) derives an incorrect result
>>>>>>>>>> because it
>>>>>>>>>> does not compute the sum of 5 + 7.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So, you are just off serving Red Herring again.
>>>>>>>>>
>>>>>>>>> H(D,D) MUST answer about the halting status of the program D(D).
>>>>>>>> The behavior of D(D) is one recursive invocation away from the
>>>>>>>> actual
>>>>>>>> behavior of the actual input.
>>>>>>>
>>>>>>> No, the INPUT is a description of the ACTUAL machine, and the
>>>>>>> actual machine is what is being asked about.
>>>>>>>
>>>>>>> So, either you accept that the behavior of the actual machine
>>>>>>> D(D) is the problem that is being asked, or you admit that your
>>>>>>> definitions say it is impossible to actually ASK the question of
>>>>>>> the problem.
>>>>>>>
>>>>>>> Remember, the PROBLEM that you claim to be working on is DEFINED
>>>>>>> to be aobut the actual machines.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> H(D,D) is not allowed to report on what the behavior of its
>>>>>>>> input would
>>>>>>>> be after it aborts the simulation of this input because it has
>>>>>>>> not yet
>>>>>>>> aborted the simulation of this input.
>>>>>>>
>>>>>>> So, by your definition, H is not allowed to answer the actual
>>>>>>> question of the problem.
>>>>>>>
>>>>>> A termination analyzer is only asked about the behavior specified
>>>>>> by its
>>>>>> input. Try and find anything in any paper about termination analyzers
>>>>>> that are required to report on the behavior of non-inputs.
>>>>>
>>>>>
>>>>> But the input is the description of the program in question. H(D,D)
>>>>> is being asked about D(D).
>>>>>
>>>>
>>>> Not when there is a pathological relationship between H and D that
>>>> changes the behavior of the input D away from the behavior of D(D).
>>>>
>>>> Because a termination analyzer always reports on the behavior of its
>>>> input H(D,D) must reject this input as non-halting.
>>>>
>>>
>>> Where do you get that statement from?
>>>
>> Feel free to counter my claim by finding a published paper where a
>> termination analyzer operates on something besides its input.
>>
>
> Note, I was refering to:
>
> >>> Not when there is a pathological relationship between H and D that
> >>> changes the behavior of the input D away from the behavior of D(D).
>
> Since you haven't shown any reference, but just served up some red
> herring, it is clear you don't actually have a reference, and thus the
> claim IS just a lie from your own distorted imagination.
>

On 6/10/23 5:48 PM, olcott wrote:
> On 6/10/2023 4:15 PM, Richard Damon wrote:
>> On 6/10/23 5:06 PM, olcott wrote:
>>> On 6/10/2023 3:27 PM, Richard Damon wrote:
>>>> On 6/10/23 3:57 PM, olcott wrote:
>>>>> On 6/10/2023 1:50 PM, Richard Damon wrote:
>>>>>> On 6/10/23 1:55 PM, olcott wrote:
>>>>>>> On 6/10/2023 11:24 AM, Richard Damon wrote:
>>>>>>>> On 6/10/23 10:55 AM, olcott wrote:
>>>>>>>>> On 6/10/2023 9:32 AM, Richard Damon wrote:
>>>>>>>>>> On 6/10/23 10:12 AM, olcott wrote:
>>>>>>>>>>> On 6/10/2023 8:54 AM, Richard Damon wrote:
>>>>>>>>>>>> On 6/10/23 9:23 AM, olcott wrote:
>>>>>>>>>>>>> 01 typedef int (*ptr)(); // pointer to int function
>>>>>>>>>>>>> 02 int H(ptr x, ptr y)   // uses x86 emulator to simulate
>>>>>>>>>>>>> its input
>>>>>>>>>>>>> 03
>>>>>>>>>>>>> 04 int D(ptr x)
>>>>>>>>>>>>> 05 {
>>>>>>>>>>>>> 06  int Halt_Status = H(x, x);
>>>>>>>>>>>>> 07  if (Halt_Status)
>>>>>>>>>>>>> 08    HERE: goto HERE;
>>>>>>>>>>>>> 09  return Halt_Status;
>>>>>>>>>>>>> 10 }
>>>>>>>>>>>>> 11
>>>>>>>>>>>>> 12 void main()
>>>>>>>>>>>>> 13 {
>>>>>>>>>>>>> 14  H(D,D);
>>>>>>>>>>>>> 15 }
>>>>>>>>>>>>>
>>>>>>>>>>>>> When H is a simulating termination analyzer based on an x86
>>>>>>>>>>>>> emulator
>>>>>>>>>>>>> within the x86utm operating system this is the execution
>>>>>>>>>>>>> trace of the
>>>>>>>>>>>>> above code:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Line 14: main() calls H(D,D) that simulates D(D)
>>>>>>>>>>>>>
>>>>>>>>>>>>> keeps repeating:
>>>>>>>>>>>>> Line 06: simulated D(D) calls simulated H(D,D) that
>>>>>>>>>>>>> simulates D(D) ...
>>>>>>>>>>>>
>>>>>>>>>>>> So, you are defining that the CORRECT SIMULATION of a call
>>>>>>>>>>>> to H(D,D) is that it keeps repeating its simulatin. We will
>>>>>>>>>>>> call this stipulation A.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Simulation invariant:
>>>>>>>>>>>>> D correctly simulated by H never reaches its own Line 09.
>>>>>>>>>>>>
>>>>>>>>>>>> Ok, if you say so. Remember that means that for all calls to
>>>>>>>>>>>> H(D,D) it may not return a value. THAT is your invariant.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> This enables H to abort its simulation of D and correctly
>>>>>>>>>>>>> report that
>>>>>>>>>>>>> (its input) D correctly simulated by H never halts. The
>>>>>>>>>>>>> above is fully
>>>>>>>>>>>>> operational code within the x86utm operating system.
>>>>>>>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>>>>>>
>>>>>>>>>>>> NO, because that volates the stipulation A you made that
>>>>>>>>>>>> H(D,D) just keeps simulating its input, and your simulation
>>>>>>>>>>>> invariant.
>>>>>>>>>>>>
>>>>>>>>>>>> Thus, while it may be correct for H to abort its siulation
>>>>>>>>>>>> of D at this point, it can't actually do so without breaking
>>>>>>>>>>>> its stipulations.
>>>>>>>>>>>>
>>>>>>>>>>>> IF the code of H actually DOES stop its simulation at this
>>>>>>>>>>>> point, then the assumption made in Stipualation A is FALSE,
>>>>>>>>>>>> and all following logic is as UNSOUND as your own mind.
>>>>>>>>>>>>
>>>>>>>>>>>> In fact, that ACTUAL behavior of D(D) calling H(D,D) is that
>>>>>>>>>>>> H(D,D) will simulate its input to the point that it sees
>>>>>>>>>>>> this simulated D(D) calling H(D,D), then it aborts its
>>>>>>>>>>>> simuation and returns to the actual running D(D) the value 0
>>>>>>>>>>>> to indicate non-halting, and that D(D) will Then Halt.
>>>>>>>>>>>>
>>>>>>>>>>>> Thus, the CORRECT simulation of a the call to H(D,D) that H
>>>>>>>>>>>> sees in its simulation of D(D) needs to somehow determine
>>>>>>>>>>>> that this call will return a 0, since that is what it does,
>>>>>>>>>>>> which means it does NOT do what you claimed at the point of
>>>>>>>>>>>> Stipulation A, which just shows you are an ignorant
>>>>>>>>>>>> pathological lying idiot.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Broadening the Practical Scope of Software Termination
>>>>>>>>>>>>> Analysis*
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://www.researchgate.net/publication/369971402_Broadening_the_Practical_Scope_of_Software_Termination_Analysis
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> The DEFINITION of a "Correct Simulation" is that it
>>>>>>>>>>>> correctly predicts the behavior of the actual program.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *That is not how termination analyzers works*
>>>>>>>>>>
>>>>>>>>>> Then it isn't applicaple to the Halting Problem, or, more
>>>>>>>>>> likely, you just don't understand what "Termination Analysis"
>>>>>>>>>> actually is.
>>>>>>>>>>
>>>>>>>>>>> Termination analyzers compute the mapping from their inputs
>>>>>>>>>>> to an accept
>>>>>>>>>>> or reject state on the basis of the actual behavior specified
>>>>>>>>>>> by this
>>>>>>>>>>> input.
>>>>>>>>>>
>>>>>>>>>> Right, and the ACTUAL BEHAVIOR is defined by what the program
>>>>>>>>>> does when actually run.
>>>>>>>>>>
>>>>>>>>>>> *It is incorrect for them to compute the halt status of
>>>>>>>>>>> non-inputs*
>>>>>>>>>>>
>>>>>>>>>>> int sum(int x, int y)
>>>>>>>>>>> {
>>>>>>>>>>>    return x + y;
>>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> H(sum, x, y) would need to compute the halt status of that input.
>>>>>>>>>>
>>>>>>>>>> Yes, H(D,D) doesn't give the answer to Sum(x,y), but need to
>>>>>>>>>> give the answer to D(D).
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> You might be able to imagine that sum must be able to compute
>>>>>>>>>>> the sum of
>>>>>>>>>>> non-inputs and say that sum(3,4) derives an incorrect result
>>>>>>>>>>> because it
>>>>>>>>>>> does not compute the sum of 5 + 7.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So, you are just off serving Red Herring again.
>>>>>>>>>>
>>>>>>>>>> H(D,D) MUST answer about the halting status of the program D(D).
>>>>>>>>> The behavior of D(D) is one recursive invocation away from the
>>>>>>>>> actual
>>>>>>>>> behavior of the actual input.
>>>>>>>>
>>>>>>>> No, the INPUT is a description of the ACTUAL machine, and the
>>>>>>>> actual machine is what is being asked about.
>>>>>>>>
>>>>>>>> So, either you accept that the behavior of the actual machine
>>>>>>>> D(D) is the problem that is being asked, or you admit that your
>>>>>>>> definitions say it is impossible to actually ASK the question of
>>>>>>>> the problem.
>>>>>>>>
>>>>>>>> Remember, the PROBLEM that you claim to be working on is DEFINED
>>>>>>>> to be aobut the actual machines.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> H(D,D) is not allowed to report on what the behavior of its
>>>>>>>>> input would
>>>>>>>>> be after it aborts the simulation of this input because it has
>>>>>>>>> not yet
>>>>>>>>> aborted the simulation of this input.
>>>>>>>>
>>>>>>>> So, by your definition, H is not allowed to answer the actual
>>>>>>>> question of the problem.
>>>>>>>>
>>>>>>> A termination analyzer is only asked about the behavior specified
>>>>>>> by its
>>>>>>> input. Try and find anything in any paper about termination
>>>>>>> analyzers
>>>>>>> that are required to report on the behavior of non-inputs.
>>>>>>
>>>>>>
>>>>>> But the input is the description of the program in question.
>>>>>> H(D,D) is being asked about D(D).
>>>>>>
>>>>>
>>>>> Not when there is a pathological relationship between H and D that
>>>>> changes the behavior of the input D away from the behavior of D(D).
>>>>>
>>>>> Because a termination analyzer always reports on the behavior of
>>>>> its input H(D,D) must reject this input as non-halting.
>>>>>
>>>>
>>>> Where do you get that statement from?
>>>>
>>> Feel free to counter my claim by finding a published paper where a
>>> termination analyzer operates on something besides its input.
>>>
>>
>> Note, I was refering to:
>>
>>  >>> Not when there is a pathological relationship between H and D that
>>  >>> changes the behavior of the input D away from the behavior of D(D).
>>
>> Since you haven't shown any reference, but just served up some red
>> herring, it is clear you don't actually have a reference, and thus the
>> claim IS just a lie from your own distorted imagination.
>>
>
> The correct simulation of D by H is specified by the source-code of D
> within the assumption that H correctly simulates D with an x86 emulator.

On 6/10/2023 5:15 PM, Richard Damon wrote:
> On 6/10/23 5:48 PM, olcott wrote:
>> On 6/10/2023 4:15 PM, Richard Damon wrote:
>>> On 6/10/23 5:06 PM, olcott wrote:
>>>> On 6/10/2023 3:27 PM, Richard Damon wrote:
>>>>> On 6/10/23 3:57 PM, olcott wrote:
>>>>>> On 6/10/2023 1:50 PM, Richard Damon wrote:
>>>>>>> On 6/10/23 1:55 PM, olcott wrote:
>>>>>>>> On 6/10/2023 11:24 AM, Richard Damon wrote:
>>>>>>>>> On 6/10/23 10:55 AM, olcott wrote:
>>>>>>>>>> On 6/10/2023 9:32 AM, Richard Damon wrote:
>>>>>>>>>>> On 6/10/23 10:12 AM, olcott wrote:
>>>>>>>>>>>> On 6/10/2023 8:54 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 6/10/23 9:23 AM, olcott wrote:
>>>>>>>>>>>>>> 01 typedef int (*ptr)(); // pointer to int function
>>>>>>>>>>>>>> 02 int H(ptr x, ptr y)   // uses x86 emulator to simulate
>>>>>>>>>>>>>> its input
>>>>>>>>>>>>>> 03
>>>>>>>>>>>>>> 04 int D(ptr x)
>>>>>>>>>>>>>> 05 {
>>>>>>>>>>>>>> 06  int Halt_Status = H(x, x);
>>>>>>>>>>>>>> 07  if (Halt_Status)
>>>>>>>>>>>>>> 08    HERE: goto HERE;
>>>>>>>>>>>>>> 09  return Halt_Status;
>>>>>>>>>>>>>> 10 }
>>>>>>>>>>>>>> 11
>>>>>>>>>>>>>> 12 void main()
>>>>>>>>>>>>>> 13 {
>>>>>>>>>>>>>> 14  H(D,D);
>>>>>>>>>>>>>> 15 }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When H is a simulating termination analyzer based on an
>>>>>>>>>>>>>> x86 emulator
>>>>>>>>>>>>>> within the x86utm operating system this is the execution
>>>>>>>>>>>>>> trace of the
>>>>>>>>>>>>>> above code:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Line 14: main() calls H(D,D) that simulates D(D)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> keeps repeating:
>>>>>>>>>>>>>> Line 06: simulated D(D) calls simulated H(D,D) that
>>>>>>>>>>>>>> simulates D(D) ...
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, you are defining that the CORRECT SIMULATION of a call
>>>>>>>>>>>>> to H(D,D) is that it keeps repeating its simulatin. We will
>>>>>>>>>>>>> call this stipulation A.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Simulation invariant:
>>>>>>>>>>>>>> D correctly simulated by H never reaches its own Line 09.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ok, if you say so. Remember that means that for all calls
>>>>>>>>>>>>> to H(D,D) it may not return a value. THAT is your invariant.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This enables H to abort its simulation of D and correctly
>>>>>>>>>>>>>> report that
>>>>>>>>>>>>>> (its input) D correctly simulated by H never halts. The
>>>>>>>>>>>>>> above is fully
>>>>>>>>>>>>>> operational code within the x86utm operating system.
>>>>>>>>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>>>>>>>
>>>>>>>>>>>>> NO, because that volates the stipulation A you made that
>>>>>>>>>>>>> H(D,D) just keeps simulating its input, and your simulation
>>>>>>>>>>>>> invariant.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thus, while it may be correct for H to abort its siulation
>>>>>>>>>>>>> of D at this point, it can't actually do so without
>>>>>>>>>>>>> breaking its stipulations.
>>>>>>>>>>>>>
>>>>>>>>>>>>> IF the code of H actually DOES stop its simulation at this
>>>>>>>>>>>>> point, then the assumption made in Stipualation A is FALSE,
>>>>>>>>>>>>> and all following logic is as UNSOUND as your own mind.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In fact, that ACTUAL behavior of D(D) calling H(D,D) is
>>>>>>>>>>>>> that H(D,D) will simulate its input to the point that it
>>>>>>>>>>>>> sees this simulated D(D) calling H(D,D), then it aborts its
>>>>>>>>>>>>> simuation and returns to the actual running D(D) the value
>>>>>>>>>>>>> 0 to indicate non-halting, and that D(D) will Then Halt.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thus, the CORRECT simulation of a the call to H(D,D) that H
>>>>>>>>>>>>> sees in its simulation of D(D) needs to somehow determine
>>>>>>>>>>>>> that this call will return a 0, since that is what it does,
>>>>>>>>>>>>> which means it does NOT do what you claimed at the point of
>>>>>>>>>>>>> Stipulation A, which just shows you are an ignorant
>>>>>>>>>>>>> pathological lying idiot.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Broadening the Practical Scope of Software Termination
>>>>>>>>>>>>>> Analysis*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://www.researchgate.net/publication/369971402_Broadening_the_Practical_Scope_of_Software_Termination_Analysis
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> The DEFINITION of a "Correct Simulation" is that it
>>>>>>>>>>>>> correctly predicts the behavior of the actual program.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> *That is not how termination analyzers works*
>>>>>>>>>>>
>>>>>>>>>>> Then it isn't applicaple to the Halting Problem, or, more
>>>>>>>>>>> likely, you just don't understand what "Termination Analysis"
>>>>>>>>>>> actually is.
>>>>>>>>>>>
>>>>>>>>>>>> Termination analyzers compute the mapping from their inputs
>>>>>>>>>>>> to an accept
>>>>>>>>>>>> or reject state on the basis of the actual behavior
>>>>>>>>>>>> specified by this
>>>>>>>>>>>> input.
>>>>>>>>>>>
>>>>>>>>>>> Right, and the ACTUAL BEHAVIOR is defined by what the program
>>>>>>>>>>> does when actually run.
>>>>>>>>>>>
>>>>>>>>>>>> *It is incorrect for them to compute the halt status of
>>>>>>>>>>>> non-inputs*
>>>>>>>>>>>>
>>>>>>>>>>>> int sum(int x, int y)
>>>>>>>>>>>> {
>>>>>>>>>>>>    return x + y;
>>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> H(sum, x, y) would need to compute the halt status of that
>>>>>>>>>>> input.
>>>>>>>>>>>
>>>>>>>>>>> Yes, H(D,D) doesn't give the answer to Sum(x,y), but need to
>>>>>>>>>>> give the answer to D(D).
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> You might be able to imagine that sum must be able to
>>>>>>>>>>>> compute the sum of
>>>>>>>>>>>> non-inputs and say that sum(3,4) derives an incorrect result
>>>>>>>>>>>> because it
>>>>>>>>>>>> does not compute the sum of 5 + 7.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So, you are just off serving Red Herring again.
>>>>>>>>>>>
>>>>>>>>>>> H(D,D) MUST answer about the halting status of the program D(D).
>>>>>>>>>> The behavior of D(D) is one recursive invocation away from the
>>>>>>>>>> actual
>>>>>>>>>> behavior of the actual input.
>>>>>>>>>
>>>>>>>>> No, the INPUT is a description of the ACTUAL machine, and the
>>>>>>>>> actual machine is what is being asked about.
>>>>>>>>>
>>>>>>>>> So, either you accept that the behavior of the actual machine
>>>>>>>>> D(D) is the problem that is being asked, or you admit that your
>>>>>>>>> definitions say it is impossible to actually ASK the question
>>>>>>>>> of the problem.
>>>>>>>>>
>>>>>>>>> Remember, the PROBLEM that you claim to be working on is
>>>>>>>>> DEFINED to be aobut the actual machines.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> H(D,D) is not allowed to report on what the behavior of its
>>>>>>>>>> input would
>>>>>>>>>> be after it aborts the simulation of this input because it has
>>>>>>>>>> not yet
>>>>>>>>>> aborted the simulation of this input.
>>>>>>>>>
>>>>>>>>> So, by your definition, H is not allowed to answer the actual
>>>>>>>>> question of the problem.
>>>>>>>>>
>>>>>>>> A termination analyzer is only asked about the behavior
>>>>>>>> specified by its
>>>>>>>> input. Try and find anything in any paper about termination
>>>>>>>> analyzers
>>>>>>>> that are required to report on the behavior of non-inputs.
>>>>>>>
>>>>>>>
>>>>>>> But the input is the description of the program in question.
>>>>>>> H(D,D) is being asked about D(D).
>>>>>>>
>>>>>>
>>>>>> Not when there is a pathological relationship between H and D that
>>>>>> changes the behavior of the input D away from the behavior of D(D).
>>>>>>
>>>>>> Because a termination analyzer always reports on the behavior of
>>>>>> its input H(D,D) must reject this input as non-halting.
>>>>>>
>>>>>
>>>>> Where do you get that statement from?
>>>>>
>>>> Feel free to counter my claim by finding a published paper where a
>>>> termination analyzer operates on something besides its input.
>>>>
>>>
>>> Note, I was refering to:
>>>
>>>  >>> Not when there is a pathological relationship between H and D that
>>>  >>> changes the behavior of the input D away from the behavior of D(D).
>>>
>>> Since you haven't shown any reference, but just served up some red
>>> herring, it is clear you don't actually have a reference, and thus
>>> the claim IS just a lie from your own distorted imagination.
>>>
>>
>> The correct simulation of D by H is specified by the source-code of D
>> within the assumption that H correctly simulates D with an x86 emulator.
>
> No, it specified by the source-code of D and H.
The cannot possibly be any aspect of the source-code of H that enables D
to reach its own line 09 and remain a correct simulation of D by H.

On 6/10/23 6:26 PM, olcott wrote:
> On 6/10/2023 5:15 PM, Richard Damon wrote:
>> On 6/10/23 5:48 PM, olcott wrote:
>>> On 6/10/2023 4:15 PM, Richard Damon wrote:
>>>> On 6/10/23 5:06 PM, olcott wrote:
>>>>> On 6/10/2023 3:27 PM, Richard Damon wrote:
>>>>>> On 6/10/23 3:57 PM, olcott wrote:
>>>>>>> On 6/10/2023 1:50 PM, Richard Damon wrote:
>>>>>>>> On 6/10/23 1:55 PM, olcott wrote:
>>>>>>>>> On 6/10/2023 11:24 AM, Richard Damon wrote:
>>>>>>>>>> On 6/10/23 10:55 AM, olcott wrote:
>>>>>>>>>>> On 6/10/2023 9:32 AM, Richard Damon wrote:
>>>>>>>>>>>> On 6/10/23 10:12 AM, olcott wrote:
>>>>>>>>>>>>> On 6/10/2023 8:54 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 6/10/23 9:23 AM, olcott wrote:
>>>>>>>>>>>>>>> 01 typedef int (*ptr)(); // pointer to int function
>>>>>>>>>>>>>>> 02 int H(ptr x, ptr y)   // uses x86 emulator to simulate
>>>>>>>>>>>>>>> its input
>>>>>>>>>>>>>>> 03
>>>>>>>>>>>>>>> 04 int D(ptr x)
>>>>>>>>>>>>>>> 05 {
>>>>>>>>>>>>>>> 06  int Halt_Status = H(x, x);
>>>>>>>>>>>>>>> 07  if (Halt_Status)
>>>>>>>>>>>>>>> 08    HERE: goto HERE;
>>>>>>>>>>>>>>> 09  return Halt_Status;
>>>>>>>>>>>>>>> 10 }
>>>>>>>>>>>>>>> 11
>>>>>>>>>>>>>>> 12 void main()
>>>>>>>>>>>>>>> 13 {
>>>>>>>>>>>>>>> 14  H(D,D);
>>>>>>>>>>>>>>> 15 }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When H is a simulating termination analyzer based on an
>>>>>>>>>>>>>>> x86 emulator
>>>>>>>>>>>>>>> within the x86utm operating system this is the execution
>>>>>>>>>>>>>>> trace of the
>>>>>>>>>>>>>>> above code:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Line 14: main() calls H(D,D) that simulates D(D)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> keeps repeating:
>>>>>>>>>>>>>>> Line 06: simulated D(D) calls simulated H(D,D) that
>>>>>>>>>>>>>>> simulates D(D) ...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, you are defining that the CORRECT SIMULATION of a call
>>>>>>>>>>>>>> to H(D,D) is that it keeps repeating its simulatin. We
>>>>>>>>>>>>>> will call this stipulation A.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Simulation invariant:
>>>>>>>>>>>>>>> D correctly simulated by H never reaches its own Line 09.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ok, if you say so. Remember that means that for all calls
>>>>>>>>>>>>>> to H(D,D) it may not return a value. THAT is your invariant.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This enables H to abort its simulation of D and correctly
>>>>>>>>>>>>>>> report that
>>>>>>>>>>>>>>> (its input) D correctly simulated by H never halts. The
>>>>>>>>>>>>>>> above is fully
>>>>>>>>>>>>>>> operational code within the x86utm operating system.
>>>>>>>>>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> NO, because that volates the stipulation A you made that
>>>>>>>>>>>>>> H(D,D) just keeps simulating its input, and your
>>>>>>>>>>>>>> simulation invariant.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thus, while it may be correct for H to abort its siulation
>>>>>>>>>>>>>> of D at this point, it can't actually do so without
>>>>>>>>>>>>>> breaking its stipulations.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> IF the code of H actually DOES stop its simulation at this
>>>>>>>>>>>>>> point, then the assumption made in Stipualation A is
>>>>>>>>>>>>>> FALSE, and all following logic is as UNSOUND as your own
>>>>>>>>>>>>>> mind.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In fact, that ACTUAL behavior of D(D) calling H(D,D) is
>>>>>>>>>>>>>> that H(D,D) will simulate its input to the point that it
>>>>>>>>>>>>>> sees this simulated D(D) calling H(D,D), then it aborts
>>>>>>>>>>>>>> its simuation and returns to the actual running D(D) the
>>>>>>>>>>>>>> value 0 to indicate non-halting, and that D(D) will Then
>>>>>>>>>>>>>> Halt.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thus, the CORRECT simulation of a the call to H(D,D) that
>>>>>>>>>>>>>> H sees in its simulation of D(D) needs to somehow
>>>>>>>>>>>>>> determine that this call will return a 0, since that is
>>>>>>>>>>>>>> what it does, which means it does NOT do what you claimed
>>>>>>>>>>>>>> at the point of Stipulation A, which just shows you are an
>>>>>>>>>>>>>> ignorant pathological lying idiot.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Broadening the Practical Scope of Software Termination
>>>>>>>>>>>>>>> Analysis*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://www.researchgate.net/publication/369971402_Broadening_the_Practical_Scope_of_Software_Termination_Analysis
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> The DEFINITION of a "Correct Simulation" is that it
>>>>>>>>>>>>>> correctly predicts the behavior of the actual program.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> *That is not how termination analyzers works*
>>>>>>>>>>>>
>>>>>>>>>>>> Then it isn't applicaple to the Halting Problem, or, more
>>>>>>>>>>>> likely, you just don't understand what "Termination
>>>>>>>>>>>> Analysis" actually is.
>>>>>>>>>>>>
>>>>>>>>>>>>> Termination analyzers compute the mapping from their inputs
>>>>>>>>>>>>> to an accept
>>>>>>>>>>>>> or reject state on the basis of the actual behavior
>>>>>>>>>>>>> specified by this
>>>>>>>>>>>>> input.
>>>>>>>>>>>>
>>>>>>>>>>>> Right, and the ACTUAL BEHAVIOR is defined by what the
>>>>>>>>>>>> program does when actually run.
>>>>>>>>>>>>
>>>>>>>>>>>>> *It is incorrect for them to compute the halt status of
>>>>>>>>>>>>> non-inputs*
>>>>>>>>>>>>>
>>>>>>>>>>>>> int sum(int x, int y)
>>>>>>>>>>>>> {
>>>>>>>>>>>>>    return x + y;
>>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> H(sum, x, y) would need to compute the halt status of that
>>>>>>>>>>>> input.
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, H(D,D) doesn't give the answer to Sum(x,y), but need to
>>>>>>>>>>>> give the answer to D(D).
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> You might be able to imagine that sum must be able to
>>>>>>>>>>>>> compute the sum of
>>>>>>>>>>>>> non-inputs and say that sum(3,4) derives an incorrect
>>>>>>>>>>>>> result because it
>>>>>>>>>>>>> does not compute the sum of 5 + 7.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> So, you are just off serving Red Herring again.
>>>>>>>>>>>>
>>>>>>>>>>>> H(D,D) MUST answer about the halting status of the program
>>>>>>>>>>>> D(D).
>>>>>>>>>>> The behavior of D(D) is one recursive invocation away from
>>>>>>>>>>> the actual
>>>>>>>>>>> behavior of the actual input.
>>>>>>>>>>
>>>>>>>>>> No, the INPUT is a description of the ACTUAL machine, and the
>>>>>>>>>> actual machine is what is being asked about.
>>>>>>>>>>
>>>>>>>>>> So, either you accept that the behavior of the actual machine
>>>>>>>>>> D(D) is the problem that is being asked, or you admit that
>>>>>>>>>> your definitions say it is impossible to actually ASK the
>>>>>>>>>> question of the problem.
>>>>>>>>>>
>>>>>>>>>> Remember, the PROBLEM that you claim to be working on is
>>>>>>>>>> DEFINED to be aobut the actual machines.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> H(D,D) is not allowed to report on what the behavior of its
>>>>>>>>>>> input would
>>>>>>>>>>> be after it aborts the simulation of this input because it
>>>>>>>>>>> has not yet
>>>>>>>>>>> aborted the simulation of this input.
>>>>>>>>>>
>>>>>>>>>> So, by your definition, H is not allowed to answer the actual
>>>>>>>>>> question of the problem.
>>>>>>>>>>
>>>>>>>>> A termination analyzer is only asked about the behavior
>>>>>>>>> specified by its
>>>>>>>>> input. Try and find anything in any paper about termination
>>>>>>>>> analyzers
>>>>>>>>> that are required to report on the behavior of non-inputs.
>>>>>>>>
>>>>>>>>
>>>>>>>> But the input is the description of the program in question.
>>>>>>>> H(D,D) is being asked about D(D).
>>>>>>>>
>>>>>>>
>>>>>>> Not when there is a pathological relationship between H and D that
>>>>>>> changes the behavior of the input D away from the behavior of D(D).
>>>>>>>
>>>>>>> Because a termination analyzer always reports on the behavior of
>>>>>>> its input H(D,D) must reject this input as non-halting.
>>>>>>>
>>>>>>
>>>>>> Where do you get that statement from?
>>>>>>
>>>>> Feel free to counter my claim by finding a published paper where a
>>>>> termination analyzer operates on something besides its input.
>>>>>
>>>>
>>>> Note, I was refering to:
>>>>
>>>>  >>> Not when there is a pathological relationship between H and D that
>>>>  >>> changes the behavior of the input D away from the behavior of
>>>> D(D).
>>>>
>>>> Since you haven't shown any reference, but just served up some red
>>>> herring, it is clear you don't actually have a reference, and thus
>>>> the claim IS just a lie from your own distorted imagination.
>>>>
>>>
>>> The correct simulation of D by H is specified by the source-code of D
>>> within the assumption that H correctly simulates D with an x86 emulator.
>>
>> No, it specified by the source-code of D and H.
> The cannot possibly be any aspect of the source-code of H that enables D
> to reach its own line 09 and remain a correct simulation of D by H.
>

On 6/10/2023 5:52 PM, Richard Damon wrote:
> On 6/10/23 6:26 PM, olcott wrote:
>> On 6/10/2023 5:15 PM, Richard Damon wrote:
>>> On 6/10/23 5:48 PM, olcott wrote:
>>>> On 6/10/2023 4:15 PM, Richard Damon wrote:
>>>>> On 6/10/23 5:06 PM, olcott wrote:
>>>>>> On 6/10/2023 3:27 PM, Richard Damon wrote:
>>>>>>> On 6/10/23 3:57 PM, olcott wrote:
>>>>>>>> On 6/10/2023 1:50 PM, Richard Damon wrote:
>>>>>>>>> On 6/10/23 1:55 PM, olcott wrote:
>>>>>>>>>> On 6/10/2023 11:24 AM, Richard Damon wrote:
>>>>>>>>>>> On 6/10/23 10:55 AM, olcott wrote:
>>>>>>>>>>>> On 6/10/2023 9:32 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 6/10/23 10:12 AM, olcott wrote:
>>>>>>>>>>>>>> On 6/10/2023 8:54 AM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 6/10/23 9:23 AM, olcott wrote:
>>>>>>>>>>>>>>>> 01 typedef int (*ptr)(); // pointer to int function
>>>>>>>>>>>>>>>> 02 int H(ptr x, ptr y)   // uses x86 emulator to
>>>>>>>>>>>>>>>> simulate its input
>>>>>>>>>>>>>>>> 03
>>>>>>>>>>>>>>>> 04 int D(ptr x)
>>>>>>>>>>>>>>>> 05 {
>>>>>>>>>>>>>>>> 06  int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>> 07  if (Halt_Status)
>>>>>>>>>>>>>>>> 08    HERE: goto HERE;
>>>>>>>>>>>>>>>> 09  return Halt_Status;
>>>>>>>>>>>>>>>> 10 }
>>>>>>>>>>>>>>>> 11
>>>>>>>>>>>>>>>> 12 void main()
>>>>>>>>>>>>>>>> 13 {
>>>>>>>>>>>>>>>> 14  H(D,D);
>>>>>>>>>>>>>>>> 15 }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> When H is a simulating termination analyzer based on an
>>>>>>>>>>>>>>>> x86 emulator
>>>>>>>>>>>>>>>> within the x86utm operating system this is the execution
>>>>>>>>>>>>>>>> trace of the
>>>>>>>>>>>>>>>> above code:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Line 14: main() calls H(D,D) that simulates D(D)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> keeps repeating:
>>>>>>>>>>>>>>>> Line 06: simulated D(D) calls simulated H(D,D) that
>>>>>>>>>>>>>>>> simulates D(D) ...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So, you are defining that the CORRECT SIMULATION of a
>>>>>>>>>>>>>>> call to H(D,D) is that it keeps repeating its simulatin.
>>>>>>>>>>>>>>> We will call this stipulation A.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Simulation invariant:
>>>>>>>>>>>>>>>> D correctly simulated by H never reaches its own Line 09.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ok, if you say so. Remember that means that for all calls
>>>>>>>>>>>>>>> to H(D,D) it may not return a value. THAT is your invariant.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This enables H to abort its simulation of D and
>>>>>>>>>>>>>>>> correctly report that
>>>>>>>>>>>>>>>> (its input) D correctly simulated by H never halts. The
>>>>>>>>>>>>>>>> above is fully
>>>>>>>>>>>>>>>> operational code within the x86utm operating system.
>>>>>>>>>>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> NO, because that volates the stipulation A you made that
>>>>>>>>>>>>>>> H(D,D) just keeps simulating its input, and your
>>>>>>>>>>>>>>> simulation invariant.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thus, while it may be correct for H to abort its
>>>>>>>>>>>>>>> siulation of D at this point, it can't actually do so
>>>>>>>>>>>>>>> without breaking its stipulations.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> IF the code of H actually DOES stop its simulation at
>>>>>>>>>>>>>>> this point, then the assumption made in Stipualation A is
>>>>>>>>>>>>>>> FALSE, and all following logic is as UNSOUND as your own
>>>>>>>>>>>>>>> mind.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In fact, that ACTUAL behavior of D(D) calling H(D,D) is
>>>>>>>>>>>>>>> that H(D,D) will simulate its input to the point that it
>>>>>>>>>>>>>>> sees this simulated D(D) calling H(D,D), then it aborts
>>>>>>>>>>>>>>> its simuation and returns to the actual running D(D) the
>>>>>>>>>>>>>>> value 0 to indicate non-halting, and that D(D) will Then
>>>>>>>>>>>>>>> Halt.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thus, the CORRECT simulation of a the call to H(D,D) that
>>>>>>>>>>>>>>> H sees in its simulation of D(D) needs to somehow
>>>>>>>>>>>>>>> determine that this call will return a 0, since that is
>>>>>>>>>>>>>>> what it does, which means it does NOT do what you claimed
>>>>>>>>>>>>>>> at the point of Stipulation A, which just shows you are
>>>>>>>>>>>>>>> an ignorant pathological lying idiot.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *Broadening the Practical Scope of Software Termination
>>>>>>>>>>>>>>>> Analysis*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/369971402_Broadening_the_Practical_Scope_of_Software_Termination_Analysis
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The DEFINITION of a "Correct Simulation" is that it
>>>>>>>>>>>>>>> correctly predicts the behavior of the actual program.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *That is not how termination analyzers works*
>>>>>>>>>>>>>
>>>>>>>>>>>>> Then it isn't applicaple to the Halting Problem, or, more
>>>>>>>>>>>>> likely, you just don't understand what "Termination
>>>>>>>>>>>>> Analysis" actually is.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Termination analyzers compute the mapping from their
>>>>>>>>>>>>>> inputs to an accept
>>>>>>>>>>>>>> or reject state on the basis of the actual behavior
>>>>>>>>>>>>>> specified by this
>>>>>>>>>>>>>> input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Right, and the ACTUAL BEHAVIOR is defined by what the
>>>>>>>>>>>>> program does when actually run.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> *It is incorrect for them to compute the halt status of
>>>>>>>>>>>>>> non-inputs*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> int sum(int x, int y)
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>    return x + y;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> H(sum, x, y) would need to compute the halt status of that
>>>>>>>>>>>>> input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, H(D,D) doesn't give the answer to Sum(x,y), but need
>>>>>>>>>>>>> to give the answer to D(D).
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You might be able to imagine that sum must be able to
>>>>>>>>>>>>>> compute the sum of
>>>>>>>>>>>>>> non-inputs and say that sum(3,4) derives an incorrect
>>>>>>>>>>>>>> result because it
>>>>>>>>>>>>>> does not compute the sum of 5 + 7.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, you are just off serving Red Herring again.
>>>>>>>>>>>>>
>>>>>>>>>>>>> H(D,D) MUST answer about the halting status of the program
>>>>>>>>>>>>> D(D).
>>>>>>>>>>>> The behavior of D(D) is one recursive invocation away from
>>>>>>>>>>>> the actual
>>>>>>>>>>>> behavior of the actual input.
>>>>>>>>>>>
>>>>>>>>>>> No, the INPUT is a description of the ACTUAL machine, and the
>>>>>>>>>>> actual machine is what is being asked about.
>>>>>>>>>>>
>>>>>>>>>>> So, either you accept that the behavior of the actual machine
>>>>>>>>>>> D(D) is the problem that is being asked, or you admit that
>>>>>>>>>>> your definitions say it is impossible to actually ASK the
>>>>>>>>>>> question of the problem.
>>>>>>>>>>>
>>>>>>>>>>> Remember, the PROBLEM that you claim to be working on is
>>>>>>>>>>> DEFINED to be aobut the actual machines.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> H(D,D) is not allowed to report on what the behavior of its
>>>>>>>>>>>> input would
>>>>>>>>>>>> be after it aborts the simulation of this input because it
>>>>>>>>>>>> has not yet
>>>>>>>>>>>> aborted the simulation of this input.
>>>>>>>>>>>
>>>>>>>>>>> So, by your definition, H is not allowed to answer the actual
>>>>>>>>>>> question of the problem.
>>>>>>>>>>>
>>>>>>>>>> A termination analyzer is only asked about the behavior
>>>>>>>>>> specified by its
>>>>>>>>>> input. Try and find anything in any paper about termination
>>>>>>>>>> analyzers
>>>>>>>>>> that are required to report on the behavior of non-inputs.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> But the input is the description of the program in question.
>>>>>>>>> H(D,D) is being asked about D(D).
>>>>>>>>>
>>>>>>>>
>>>>>>>> Not when there is a pathological relationship between H and D that
>>>>>>>> changes the behavior of the input D away from the behavior of D(D).
>>>>>>>>
>>>>>>>> Because a termination analyzer always reports on the behavior of
>>>>>>>> its input H(D,D) must reject this input as non-halting.
>>>>>>>>
>>>>>>>
>>>>>>> Where do you get that statement from?
>>>>>>>
>>>>>> Feel free to counter my claim by finding a published paper where a
>>>>>> termination analyzer operates on something besides its input.
>>>>>>
>>>>>
>>>>> Note, I was refering to:
>>>>>
>>>>>  >>> Not when there is a pathological relationship between H and D
>>>>> that
>>>>>  >>> changes the behavior of the input D away from the behavior of
>>>>> D(D).
>>>>>
>>>>> Since you haven't shown any reference, but just served up some red
>>>>> herring, it is clear you don't actually have a reference, and thus
>>>>> the claim IS just a lie from your own distorted imagination.
>>>>>
>>>>
>>>> The correct simulation of D by H is specified by the source-code of D
>>>> within the assumption that H correctly simulates D with an x86
>>>> emulator.
>>>
>>> No, it specified by the source-code of D and H.
>> The cannot possibly be any aspect of the source-code of H that enables
>> D to reach its own line 09 and remain a correct simulation of D by H.
>>
>
> Right, because H can't do a correct simulation of D.
>

On 6/10/23 7:18 PM, olcott wrote:
> On 6/10/2023 5:52 PM, Richard Damon wrote:
>> On 6/10/23 6:26 PM, olcott wrote:
>>> On 6/10/2023 5:15 PM, Richard Damon wrote:
>>>> On 6/10/23 5:48 PM, olcott wrote:
>>>>> On 6/10/2023 4:15 PM, Richard Damon wrote:
>>>>>> On 6/10/23 5:06 PM, olcott wrote:
>>>>>>> On 6/10/2023 3:27 PM, Richard Damon wrote:
>>>>>>>> On 6/10/23 3:57 PM, olcott wrote:
>>>>>>>>> On 6/10/2023 1:50 PM, Richard Damon wrote:
>>>>>>>>>> On 6/10/23 1:55 PM, olcott wrote:
>>>>>>>>>>> On 6/10/2023 11:24 AM, Richard Damon wrote:
>>>>>>>>>>>> On 6/10/23 10:55 AM, olcott wrote:
>>>>>>>>>>>>> On 6/10/2023 9:32 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 6/10/23 10:12 AM, olcott wrote:
>>>>>>>>>>>>>>> On 6/10/2023 8:54 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 6/10/23 9:23 AM, olcott wrote:
>>>>>>>>>>>>>>>>> 01 typedef int (*ptr)(); // pointer to int function
>>>>>>>>>>>>>>>>> 02 int H(ptr x, ptr y)   // uses x86 emulator to
>>>>>>>>>>>>>>>>> simulate its input
>>>>>>>>>>>>>>>>> 03
>>>>>>>>>>>>>>>>> 04 int D(ptr x)
>>>>>>>>>>>>>>>>> 05 {
>>>>>>>>>>>>>>>>> 06  int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>> 07  if (Halt_Status)
>>>>>>>>>>>>>>>>> 08    HERE: goto HERE;
>>>>>>>>>>>>>>>>> 09  return Halt_Status;
>>>>>>>>>>>>>>>>> 10 }
>>>>>>>>>>>>>>>>> 11
>>>>>>>>>>>>>>>>> 12 void main()
>>>>>>>>>>>>>>>>> 13 {
>>>>>>>>>>>>>>>>> 14  H(D,D);
>>>>>>>>>>>>>>>>> 15 }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> When H is a simulating termination analyzer based on an
>>>>>>>>>>>>>>>>> x86 emulator
>>>>>>>>>>>>>>>>> within the x86utm operating system this is the
>>>>>>>>>>>>>>>>> execution trace of the
>>>>>>>>>>>>>>>>> above code:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Line 14: main() calls H(D,D) that simulates D(D)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> keeps repeating:
>>>>>>>>>>>>>>>>> Line 06: simulated D(D) calls simulated H(D,D) that
>>>>>>>>>>>>>>>>> simulates D(D) ...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So, you are defining that the CORRECT SIMULATION of a
>>>>>>>>>>>>>>>> call to H(D,D) is that it keeps repeating its simulatin.
>>>>>>>>>>>>>>>> We will call this stipulation A.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Simulation invariant:
>>>>>>>>>>>>>>>>> D correctly simulated by H never reaches its own Line 09.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ok, if you say so. Remember that means that for all
>>>>>>>>>>>>>>>> calls to H(D,D) it may not return a value. THAT is your
>>>>>>>>>>>>>>>> invariant.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This enables H to abort its simulation of D and
>>>>>>>>>>>>>>>>> correctly report that
>>>>>>>>>>>>>>>>> (its input) D correctly simulated by H never halts. The
>>>>>>>>>>>>>>>>> above is fully
>>>>>>>>>>>>>>>>> operational code within the x86utm operating system.
>>>>>>>>>>>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> NO, because that volates the stipulation A you made that
>>>>>>>>>>>>>>>> H(D,D) just keeps simulating its input, and your
>>>>>>>>>>>>>>>> simulation invariant.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thus, while it may be correct for H to abort its
>>>>>>>>>>>>>>>> siulation of D at this point, it can't actually do so
>>>>>>>>>>>>>>>> without breaking its stipulations.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> IF the code of H actually DOES stop its simulation at
>>>>>>>>>>>>>>>> this point, then the assumption made in Stipualation A
>>>>>>>>>>>>>>>> is FALSE, and all following logic is as UNSOUND as your
>>>>>>>>>>>>>>>> own mind.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In fact, that ACTUAL behavior of D(D) calling H(D,D) is
>>>>>>>>>>>>>>>> that H(D,D) will simulate its input to the point that it
>>>>>>>>>>>>>>>> sees this simulated D(D) calling H(D,D), then it aborts
>>>>>>>>>>>>>>>> its simuation and returns to the actual running D(D) the
>>>>>>>>>>>>>>>> value 0 to indicate non-halting, and that D(D) will Then
>>>>>>>>>>>>>>>> Halt.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thus, the CORRECT simulation of a the call to H(D,D)
>>>>>>>>>>>>>>>> that H sees in its simulation of D(D) needs to somehow
>>>>>>>>>>>>>>>> determine that this call will return a 0, since that is
>>>>>>>>>>>>>>>> what it does, which means it does NOT do what you
>>>>>>>>>>>>>>>> claimed at the point of Stipulation A, which just shows
>>>>>>>>>>>>>>>> you are an ignorant pathological lying idiot.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *Broadening the Practical Scope of Software Termination
>>>>>>>>>>>>>>>>> Analysis*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/369971402_Broadening_the_Practical_Scope_of_Software_Termination_Analysis
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The DEFINITION of a "Correct Simulation" is that it
>>>>>>>>>>>>>>>> correctly predicts the behavior of the actual program.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *That is not how termination analyzers works*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Then it isn't applicaple to the Halting Problem, or, more
>>>>>>>>>>>>>> likely, you just don't understand what "Termination
>>>>>>>>>>>>>> Analysis" actually is.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Termination analyzers compute the mapping from their
>>>>>>>>>>>>>>> inputs to an accept
>>>>>>>>>>>>>>> or reject state on the basis of the actual behavior
>>>>>>>>>>>>>>> specified by this
>>>>>>>>>>>>>>> input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Right, and the ACTUAL BEHAVIOR is defined by what the
>>>>>>>>>>>>>> program does when actually run.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *It is incorrect for them to compute the halt status of
>>>>>>>>>>>>>>> non-inputs*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> int sum(int x, int y)
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>    return x + y;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H(sum, x, y) would need to compute the halt status of that
>>>>>>>>>>>>>> input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes, H(D,D) doesn't give the answer to Sum(x,y), but need
>>>>>>>>>>>>>> to give the answer to D(D).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You might be able to imagine that sum must be able to
>>>>>>>>>>>>>>> compute the sum of
>>>>>>>>>>>>>>> non-inputs and say that sum(3,4) derives an incorrect
>>>>>>>>>>>>>>> result because it
>>>>>>>>>>>>>>> does not compute the sum of 5 + 7.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, you are just off serving Red Herring again.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H(D,D) MUST answer about the halting status of the program
>>>>>>>>>>>>>> D(D).
>>>>>>>>>>>>> The behavior of D(D) is one recursive invocation away from
>>>>>>>>>>>>> the actual
>>>>>>>>>>>>> behavior of the actual input.
>>>>>>>>>>>>
>>>>>>>>>>>> No, the INPUT is a description of the ACTUAL machine, and
>>>>>>>>>>>> the actual machine is what is being asked about.
>>>>>>>>>>>>
>>>>>>>>>>>> So, either you accept that the behavior of the actual
>>>>>>>>>>>> machine D(D) is the problem that is being asked, or you
>>>>>>>>>>>> admit that your definitions say it is impossible to actually
>>>>>>>>>>>> ASK the question of the problem.
>>>>>>>>>>>>
>>>>>>>>>>>> Remember, the PROBLEM that you claim to be working on is
>>>>>>>>>>>> DEFINED to be aobut the actual machines.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> H(D,D) is not allowed to report on what the behavior of its
>>>>>>>>>>>>> input would
>>>>>>>>>>>>> be after it aborts the simulation of this input because it
>>>>>>>>>>>>> has not yet
>>>>>>>>>>>>> aborted the simulation of this input.
>>>>>>>>>>>>
>>>>>>>>>>>> So, by your definition, H is not allowed to answer the
>>>>>>>>>>>> actual question of the problem.
>>>>>>>>>>>>
>>>>>>>>>>> A termination analyzer is only asked about the behavior
>>>>>>>>>>> specified by its
>>>>>>>>>>> input. Try and find anything in any paper about termination
>>>>>>>>>>> analyzers
>>>>>>>>>>> that are required to report on the behavior of non-inputs.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> But the input is the description of the program in question.
>>>>>>>>>> H(D,D) is being asked about D(D).
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Not when there is a pathological relationship between H and D that
>>>>>>>>> changes the behavior of the input D away from the behavior of
>>>>>>>>> D(D).
>>>>>>>>>
>>>>>>>>> Because a termination analyzer always reports on the behavior
>>>>>>>>> of its input H(D,D) must reject this input as non-halting.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Where do you get that statement from?
>>>>>>>>
>>>>>>> Feel free to counter my claim by finding a published paper where a
>>>>>>> termination analyzer operates on something besides its input.
>>>>>>>
>>>>>>
>>>>>> Note, I was refering to:
>>>>>>
>>>>>>  >>> Not when there is a pathological relationship between H and D
>>>>>> that
>>>>>>  >>> changes the behavior of the input D away from the behavior of
>>>>>> D(D).
>>>>>>
>>>>>> Since you haven't shown any reference, but just served up some red
>>>>>> herring, it is clear you don't actually have a reference, and thus
>>>>>> the claim IS just a lie from your own distorted imagination.
>>>>>>
>>>>>
>>>>> The correct simulation of D by H is specified by the source-code of D
>>>>> within the assumption that H correctly simulates D with an x86
>>>>> emulator.
>>>>
>>>> No, it specified by the source-code of D and H.
>>> The cannot possibly be any aspect of the source-code of H that
>>> enables D to reach its own line 09 and remain a correct simulation of
>>> D by H.
>>>
>>
>> Right, because H can't do a correct simulation of D.
>>
>
> Try and explain line-by-line and step-by-step how D correctly simulated
> by H would reach its own line 09.
>

On 6/10/2023 6:49 PM, Richard Damon wrote:
> On 6/10/23 7:18 PM, olcott wrote:
>> On 6/10/2023 5:52 PM, Richard Damon wrote:
>>> On 6/10/23 6:26 PM, olcott wrote:
>>>> On 6/10/2023 5:15 PM, Richard Damon wrote:
>>>>> On 6/10/23 5:48 PM, olcott wrote:
>>>>>> On 6/10/2023 4:15 PM, Richard Damon wrote:
>>>>>>> On 6/10/23 5:06 PM, olcott wrote:
>>>>>>>> On 6/10/2023 3:27 PM, Richard Damon wrote:
>>>>>>>>> On 6/10/23 3:57 PM, olcott wrote:
>>>>>>>>>> On 6/10/2023 1:50 PM, Richard Damon wrote:
>>>>>>>>>>> On 6/10/23 1:55 PM, olcott wrote:
>>>>>>>>>>>> On 6/10/2023 11:24 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 6/10/23 10:55 AM, olcott wrote:
>>>>>>>>>>>>>> On 6/10/2023 9:32 AM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 6/10/23 10:12 AM, olcott wrote:
>>>>>>>>>>>>>>>> On 6/10/2023 8:54 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 6/10/23 9:23 AM, olcott wrote:
>>>>>>>>>>>>>>>>>> 01 typedef int (*ptr)(); // pointer to int function
>>>>>>>>>>>>>>>>>> 02 int H(ptr x, ptr y)   // uses x86 emulator to
>>>>>>>>>>>>>>>>>> simulate its input
>>>>>>>>>>>>>>>>>> 03
>>>>>>>>>>>>>>>>>> 04 int D(ptr x)
>>>>>>>>>>>>>>>>>> 05 {
>>>>>>>>>>>>>>>>>> 06  int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>> 07  if (Halt_Status)
>>>>>>>>>>>>>>>>>> 08    HERE: goto HERE;
>>>>>>>>>>>>>>>>>> 09  return Halt_Status;
>>>>>>>>>>>>>>>>>> 10 }
>>>>>>>>>>>>>>>>>> 11
>>>>>>>>>>>>>>>>>> 12 void main()
>>>>>>>>>>>>>>>>>> 13 {
>>>>>>>>>>>>>>>>>> 14  H(D,D);
>>>>>>>>>>>>>>>>>> 15 }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> When H is a simulating termination analyzer based on
>>>>>>>>>>>>>>>>>> an x86 emulator
>>>>>>>>>>>>>>>>>> within the x86utm operating system this is the
>>>>>>>>>>>>>>>>>> execution trace of the
>>>>>>>>>>>>>>>>>> above code:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Line 14: main() calls H(D,D) that simulates D(D)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> keeps repeating:
>>>>>>>>>>>>>>>>>> Line 06: simulated D(D) calls simulated H(D,D) that
>>>>>>>>>>>>>>>>>> simulates D(D) ...
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So, you are defining that the CORRECT SIMULATION of a
>>>>>>>>>>>>>>>>> call to H(D,D) is that it keeps repeating its
>>>>>>>>>>>>>>>>> simulatin. We will call this stipulation A.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Simulation invariant:
>>>>>>>>>>>>>>>>>> D correctly simulated by H never reaches its own Line 09.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Ok, if you say so. Remember that means that for all
>>>>>>>>>>>>>>>>> calls to H(D,D) it may not return a value. THAT is your
>>>>>>>>>>>>>>>>> invariant.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This enables H to abort its simulation of D and
>>>>>>>>>>>>>>>>>> correctly report that
>>>>>>>>>>>>>>>>>> (its input) D correctly simulated by H never halts.
>>>>>>>>>>>>>>>>>> The above is fully
>>>>>>>>>>>>>>>>>> operational code within the x86utm operating system.
>>>>>>>>>>>>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> NO, because that volates the stipulation A you made
>>>>>>>>>>>>>>>>> that H(D,D) just keeps simulating its input, and your
>>>>>>>>>>>>>>>>> simulation invariant.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thus, while it may be correct for H to abort its
>>>>>>>>>>>>>>>>> siulation of D at this point, it can't actually do so
>>>>>>>>>>>>>>>>> without breaking its stipulations.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> IF the code of H actually DOES stop its simulation at
>>>>>>>>>>>>>>>>> this point, then the assumption made in Stipualation A
>>>>>>>>>>>>>>>>> is FALSE, and all following logic is as UNSOUND as your
>>>>>>>>>>>>>>>>> own mind.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> In fact, that ACTUAL behavior of D(D) calling H(D,D) is
>>>>>>>>>>>>>>>>> that H(D,D) will simulate its input to the point that
>>>>>>>>>>>>>>>>> it sees this simulated D(D) calling H(D,D), then it
>>>>>>>>>>>>>>>>> aborts its simuation and returns to the actual running
>>>>>>>>>>>>>>>>> D(D) the value 0 to indicate non-halting, and that D(D)
>>>>>>>>>>>>>>>>> will Then Halt.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thus, the CORRECT simulation of a the call to H(D,D)
>>>>>>>>>>>>>>>>> that H sees in its simulation of D(D) needs to somehow
>>>>>>>>>>>>>>>>> determine that this call will return a 0, since that is
>>>>>>>>>>>>>>>>> what it does, which means it does NOT do what you
>>>>>>>>>>>>>>>>> claimed at the point of Stipulation A, which just shows
>>>>>>>>>>>>>>>>> you are an ignorant pathological lying idiot.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *Broadening the Practical Scope of Software
>>>>>>>>>>>>>>>>>> Termination Analysis*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/369971402_Broadening_the_Practical_Scope_of_Software_Termination_Analysis
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The DEFINITION of a "Correct Simulation" is that it
>>>>>>>>>>>>>>>>> correctly predicts the behavior of the actual program.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *That is not how termination analyzers works*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Then it isn't applicaple to the Halting Problem, or, more
>>>>>>>>>>>>>>> likely, you just don't understand what "Termination
>>>>>>>>>>>>>>> Analysis" actually is.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Termination analyzers compute the mapping from their
>>>>>>>>>>>>>>>> inputs to an accept
>>>>>>>>>>>>>>>> or reject state on the basis of the actual behavior
>>>>>>>>>>>>>>>> specified by this
>>>>>>>>>>>>>>>> input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Right, and the ACTUAL BEHAVIOR is defined by what the
>>>>>>>>>>>>>>> program does when actually run.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *It is incorrect for them to compute the halt status of
>>>>>>>>>>>>>>>> non-inputs*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int sum(int x, int y)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>    return x + y;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> H(sum, x, y) would need to compute the halt status of
>>>>>>>>>>>>>>> that input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yes, H(D,D) doesn't give the answer to Sum(x,y), but need
>>>>>>>>>>>>>>> to give the answer to D(D).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You might be able to imagine that sum must be able to
>>>>>>>>>>>>>>>> compute the sum of
>>>>>>>>>>>>>>>> non-inputs and say that sum(3,4) derives an incorrect
>>>>>>>>>>>>>>>> result because it
>>>>>>>>>>>>>>>> does not compute the sum of 5 + 7.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So, you are just off serving Red Herring again.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> H(D,D) MUST answer about the halting status of the
>>>>>>>>>>>>>>> program D(D).
>>>>>>>>>>>>>> The behavior of D(D) is one recursive invocation away from
>>>>>>>>>>>>>> the actual
>>>>>>>>>>>>>> behavior of the actual input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, the INPUT is a description of the ACTUAL machine, and
>>>>>>>>>>>>> the actual machine is what is being asked about.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, either you accept that the behavior of the actual
>>>>>>>>>>>>> machine D(D) is the problem that is being asked, or you
>>>>>>>>>>>>> admit that your definitions say it is impossible to
>>>>>>>>>>>>> actually ASK the question of the problem.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Remember, the PROBLEM that you claim to be working on is
>>>>>>>>>>>>> DEFINED to be aobut the actual machines.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H(D,D) is not allowed to report on what the behavior of
>>>>>>>>>>>>>> its input would
>>>>>>>>>>>>>> be after it aborts the simulation of this input because it
>>>>>>>>>>>>>> has not yet
>>>>>>>>>>>>>> aborted the simulation of this input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, by your definition, H is not allowed to answer the
>>>>>>>>>>>>> actual question of the problem.
>>>>>>>>>>>>>
>>>>>>>>>>>> A termination analyzer is only asked about the behavior
>>>>>>>>>>>> specified by its
>>>>>>>>>>>> input. Try and find anything in any paper about termination
>>>>>>>>>>>> analyzers
>>>>>>>>>>>> that are required to report on the behavior of non-inputs.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> But the input is the description of the program in question.
>>>>>>>>>>> H(D,D) is being asked about D(D).
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Not when there is a pathological relationship between H and D
>>>>>>>>>> that
>>>>>>>>>> changes the behavior of the input D away from the behavior of
>>>>>>>>>> D(D).
>>>>>>>>>>
>>>>>>>>>> Because a termination analyzer always reports on the behavior
>>>>>>>>>> of its input H(D,D) must reject this input as non-halting.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Where do you get that statement from?
>>>>>>>>>
>>>>>>>> Feel free to counter my claim by finding a published paper where a
>>>>>>>> termination analyzer operates on something besides its input.
>>>>>>>>
>>>>>>>
>>>>>>> Note, I was refering to:
>>>>>>>
>>>>>>>  >>> Not when there is a pathological relationship between H and
>>>>>>> D that
>>>>>>>  >>> changes the behavior of the input D away from the behavior
>>>>>>> of D(D).
>>>>>>>
>>>>>>> Since you haven't shown any reference, but just served up some
>>>>>>> red herring, it is clear you don't actually have a reference, and
>>>>>>> thus the claim IS just a lie from your own distorted imagination.
>>>>>>>
>>>>>>
>>>>>> The correct simulation of D by H is specified by the source-code of D
>>>>>> within the assumption that H correctly simulates D with an x86
>>>>>> emulator.
>>>>>
>>>>> No, it specified by the source-code of D and H.
>>>> The cannot possibly be any aspect of the source-code of H that
>>>> enables D to reach its own line 09 and remain a correct simulation
>>>> of D by H.
>>>>
>>>
>>> Right, because H can't do a correct simulation of D.
>>>
>>
>> Try and explain line-by-line and step-by-step how D correctly simulated
>> by H would reach its own line 09.
>>
>
> You have a bad assumption in there, that H CAN "Correctly Simulate" this
> input. The H in your code doesn't do it (since "Correct" in this
> connotaion includes completely), an+d that is the only code that matters.
In other words you are claiming that D would terminate normally by
reaching its own line 09 if H would simply refrain from aborting its
simulation.

On 6/10/23 7:18 PM, olcott wrote:
>>
>
> Try and explain line-by-line and step-by-step how D correctly simulated
> by H would reach its own line 09.
>

If you really want an explaination of how this can happen,

The Magic Faerie Dust Powered Magic Unicorn Fairy Godmother taps the
code of H and magicaly makes the outer version of H into an actual
Correct Simulator without touching the behavior of the version of H
called by D.

This H then simulates D(D) and sees it call H(D,D), which has not been
changed by the magic.

THis H then starts its simulation of the D(D) passed to it, and it sees
that this D(D) call H(D,D), and since the code of H says (incorrectly)
that this means a correct simulation of this input will be non-halting,
it aborts its simulation and is simulated to return 0 to the original
D(D) being simulated by the enchanted H, which then comes to a Halt.

If you object to the use of magic, try to explain how you H produces a
"Correct Simulation" by means less extream and still return an answer.

You are just not seeing the faeries that you are invoking.

On 6/10/23 8:01 PM, olcott wrote:
> On 6/10/2023 6:49 PM, Richard Damon wrote:
>> On 6/10/23 7:18 PM, olcott wrote:
>>> On 6/10/2023 5:52 PM, Richard Damon wrote:
>>>> On 6/10/23 6:26 PM, olcott wrote:
>>>>> On 6/10/2023 5:15 PM, Richard Damon wrote:
>>>>>> On 6/10/23 5:48 PM, olcott wrote:
>>>>>>> On 6/10/2023 4:15 PM, Richard Damon wrote:
>>>>>>>> On 6/10/23 5:06 PM, olcott wrote:
>>>>>>>>> On 6/10/2023 3:27 PM, Richard Damon wrote:
>>>>>>>>>> On 6/10/23 3:57 PM, olcott wrote:
>>>>>>>>>>> On 6/10/2023 1:50 PM, Richard Damon wrote:
>>>>>>>>>>>> On 6/10/23 1:55 PM, olcott wrote:
>>>>>>>>>>>>> On 6/10/2023 11:24 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 6/10/23 10:55 AM, olcott wrote:
>>>>>>>>>>>>>>> On 6/10/2023 9:32 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 6/10/23 10:12 AM, olcott wrote:
>>>>>>>>>>>>>>>>> On 6/10/2023 8:54 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 6/10/23 9:23 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>> 01 typedef int (*ptr)(); // pointer to int function
>>>>>>>>>>>>>>>>>>> 02 int H(ptr x, ptr y)   // uses x86 emulator to
>>>>>>>>>>>>>>>>>>> simulate its input
>>>>>>>>>>>>>>>>>>> 03
>>>>>>>>>>>>>>>>>>> 04 int D(ptr x)
>>>>>>>>>>>>>>>>>>> 05 {
>>>>>>>>>>>>>>>>>>> 06  int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>> 07  if (Halt_Status)
>>>>>>>>>>>>>>>>>>> 08    HERE: goto HERE;
>>>>>>>>>>>>>>>>>>> 09  return Halt_Status;
>>>>>>>>>>>>>>>>>>> 10 }
>>>>>>>>>>>>>>>>>>> 11
>>>>>>>>>>>>>>>>>>> 12 void main()
>>>>>>>>>>>>>>>>>>> 13 {
>>>>>>>>>>>>>>>>>>> 14  H(D,D);
>>>>>>>>>>>>>>>>>>> 15 }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> When H is a simulating termination analyzer based on
>>>>>>>>>>>>>>>>>>> an x86 emulator
>>>>>>>>>>>>>>>>>>> within the x86utm operating system this is the
>>>>>>>>>>>>>>>>>>> execution trace of the
>>>>>>>>>>>>>>>>>>> above code:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Line 14: main() calls H(D,D) that simulates D(D)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> keeps repeating:
>>>>>>>>>>>>>>>>>>> Line 06: simulated D(D) calls simulated H(D,D) that
>>>>>>>>>>>>>>>>>>> simulates D(D) ...
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> So, you are defining that the CORRECT SIMULATION of a
>>>>>>>>>>>>>>>>>> call to H(D,D) is that it keeps repeating its
>>>>>>>>>>>>>>>>>> simulatin. We will call this stipulation A.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Simulation invariant:
>>>>>>>>>>>>>>>>>>> D correctly simulated by H never reaches its own Line
>>>>>>>>>>>>>>>>>>> 09.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Ok, if you say so. Remember that means that for all
>>>>>>>>>>>>>>>>>> calls to H(D,D) it may not return a value. THAT is
>>>>>>>>>>>>>>>>>> your invariant.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> This enables H to abort its simulation of D and
>>>>>>>>>>>>>>>>>>> correctly report that
>>>>>>>>>>>>>>>>>>> (its input) D correctly simulated by H never halts.
>>>>>>>>>>>>>>>>>>> The above is fully
>>>>>>>>>>>>>>>>>>> operational code within the x86utm operating system.
>>>>>>>>>>>>>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> NO, because that volates the stipulation A you made
>>>>>>>>>>>>>>>>>> that H(D,D) just keeps simulating its input, and your
>>>>>>>>>>>>>>>>>> simulation invariant.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thus, while it may be correct for H to abort its
>>>>>>>>>>>>>>>>>> siulation of D at this point, it can't actually do so
>>>>>>>>>>>>>>>>>> without breaking its stipulations.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> IF the code of H actually DOES stop its simulation at
>>>>>>>>>>>>>>>>>> this point, then the assumption made in Stipualation A
>>>>>>>>>>>>>>>>>> is FALSE, and all following logic is as UNSOUND as
>>>>>>>>>>>>>>>>>> your own mind.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> In fact, that ACTUAL behavior of D(D) calling H(D,D)
>>>>>>>>>>>>>>>>>> is that H(D,D) will simulate its input to the point
>>>>>>>>>>>>>>>>>> that it sees this simulated D(D) calling H(D,D), then
>>>>>>>>>>>>>>>>>> it aborts its simuation and returns to the actual
>>>>>>>>>>>>>>>>>> running D(D) the value 0 to indicate non-halting, and
>>>>>>>>>>>>>>>>>> that D(D) will Then Halt.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thus, the CORRECT simulation of a the call to H(D,D)
>>>>>>>>>>>>>>>>>> that H sees in its simulation of D(D) needs to somehow
>>>>>>>>>>>>>>>>>> determine that this call will return a 0, since that
>>>>>>>>>>>>>>>>>> is what it does, which means it does NOT do what you
>>>>>>>>>>>>>>>>>> claimed at the point of Stipulation A, which just
>>>>>>>>>>>>>>>>>> shows you are an ignorant pathological lying idiot.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *Broadening the Practical Scope of Software
>>>>>>>>>>>>>>>>>>> Termination Analysis*
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/369971402_Broadening_the_Practical_Scope_of_Software_Termination_Analysis
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The DEFINITION of a "Correct Simulation" is that it
>>>>>>>>>>>>>>>>>> correctly predicts the behavior of the actual program.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *That is not how termination analyzers works*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Then it isn't applicaple to the Halting Problem, or,
>>>>>>>>>>>>>>>> more likely, you just don't understand what "Termination
>>>>>>>>>>>>>>>> Analysis" actually is.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Termination analyzers compute the mapping from their
>>>>>>>>>>>>>>>>> inputs to an accept
>>>>>>>>>>>>>>>>> or reject state on the basis of the actual behavior
>>>>>>>>>>>>>>>>> specified by this
>>>>>>>>>>>>>>>>> input.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Right, and the ACTUAL BEHAVIOR is defined by what the
>>>>>>>>>>>>>>>> program does when actually run.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *It is incorrect for them to compute the halt status of
>>>>>>>>>>>>>>>>> non-inputs*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> int sum(int x, int y)
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>    return x + y;
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> H(sum, x, y) would need to compute the halt status of
>>>>>>>>>>>>>>>> that input.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yes, H(D,D) doesn't give the answer to Sum(x,y), but
>>>>>>>>>>>>>>>> need to give the answer to D(D).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You might be able to imagine that sum must be able to
>>>>>>>>>>>>>>>>> compute the sum of
>>>>>>>>>>>>>>>>> non-inputs and say that sum(3,4) derives an incorrect
>>>>>>>>>>>>>>>>> result because it
>>>>>>>>>>>>>>>>> does not compute the sum of 5 + 7.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So, you are just off serving Red Herring again.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> H(D,D) MUST answer about the halting status of the
>>>>>>>>>>>>>>>> program D(D).
>>>>>>>>>>>>>>> The behavior of D(D) is one recursive invocation away
>>>>>>>>>>>>>>> from the actual
>>>>>>>>>>>>>>> behavior of the actual input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No, the INPUT is a description of the ACTUAL machine, and
>>>>>>>>>>>>>> the actual machine is what is being asked about.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, either you accept that the behavior of the actual
>>>>>>>>>>>>>> machine D(D) is the problem that is being asked, or you
>>>>>>>>>>>>>> admit that your definitions say it is impossible to
>>>>>>>>>>>>>> actually ASK the question of the problem.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Remember, the PROBLEM that you claim to be working on is
>>>>>>>>>>>>>> DEFINED to be aobut the actual machines.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> H(D,D) is not allowed to report on what the behavior of
>>>>>>>>>>>>>>> its input would
>>>>>>>>>>>>>>> be after it aborts the simulation of this input because
>>>>>>>>>>>>>>> it has not yet
>>>>>>>>>>>>>>> aborted the simulation of this input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, by your definition, H is not allowed to answer the
>>>>>>>>>>>>>> actual question of the problem.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> A termination analyzer is only asked about the behavior
>>>>>>>>>>>>> specified by its
>>>>>>>>>>>>> input. Try and find anything in any paper about termination
>>>>>>>>>>>>> analyzers
>>>>>>>>>>>>> that are required to report on the behavior of non-inputs.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> But the input is the description of the program in question.
>>>>>>>>>>>> H(D,D) is being asked about D(D).
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Not when there is a pathological relationship between H and D
>>>>>>>>>>> that
>>>>>>>>>>> changes the behavior of the input D away from the behavior of
>>>>>>>>>>> D(D).
>>>>>>>>>>>
>>>>>>>>>>> Because a termination analyzer always reports on the behavior
>>>>>>>>>>> of its input H(D,D) must reject this input as non-halting.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Where do you get that statement from?
>>>>>>>>>>
>>>>>>>>> Feel free to counter my claim by finding a published paper where a
>>>>>>>>> termination analyzer operates on something besides its input.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Note, I was refering to:
>>>>>>>>
>>>>>>>>  >>> Not when there is a pathological relationship between H and
>>>>>>>> D that
>>>>>>>>  >>> changes the behavior of the input D away from the behavior
>>>>>>>> of D(D).
>>>>>>>>
>>>>>>>> Since you haven't shown any reference, but just served up some
>>>>>>>> red herring, it is clear you don't actually have a reference,
>>>>>>>> and thus the claim IS just a lie from your own distorted
>>>>>>>> imagination.
>>>>>>>>
>>>>>>>
>>>>>>> The correct simulation of D by H is specified by the source-code
>>>>>>> of D
>>>>>>> within the assumption that H correctly simulates D with an x86
>>>>>>> emulator.
>>>>>>
>>>>>> No, it specified by the source-code of D and H.
>>>>> The cannot possibly be any aspect of the source-code of H that
>>>>> enables D to reach its own line 09 and remain a correct simulation
>>>>> of D by H.
>>>>>
>>>>
>>>> Right, because H can't do a correct simulation of D.
>>>>
>>>
>>> Try and explain line-by-line and step-by-step how D correctly simulated
>>> by H would reach its own line 09.
>>>
>>
>> You have a bad assumption in there, that H CAN "Correctly Simulate"
>> this input. The H in your code doesn't do it (since "Correct" in this
>> connotaion includes completely), an+d that is the only code that matters.
> In other words you are claiming that D would terminate normally by
> reaching its own line 09 if H would simply refrain from aborting its
> simulation.
>

On 6/10/2023 7:01 PM, Richard Damon wrote:
> On 6/10/23 7:18 PM, olcott wrote:
>>>
>>
>> Try and explain line-by-line and step-by-step how D correctly simulated
>> by H would reach its own line 09.
>>
>
> If you really want an explaination of how this can happen,
>
> The Magic Faerie Dust Powered Magic Unicorn Fairy Godmother taps the
> code of H and magicaly makes the outer version of H into an actual
> Correct Simulator without touching the behavior of the version of H
> called by D.
I put you on the spot to prove that you are intentionally being
dishonest and you just confirmed this.

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

On 6/10/2023 7:08 PM, Richard Damon wrote:
> On 6/10/23 8:01 PM, olcott wrote:
>> On 6/10/2023 6:49 PM, Richard Damon wrote:
>>> On 6/10/23 7:18 PM, olcott wrote:
>>>> On 6/10/2023 5:52 PM, Richard Damon wrote:
>>>>> On 6/10/23 6:26 PM, olcott wrote:
>>>>>> On 6/10/2023 5:15 PM, Richard Damon wrote:
>>>>>>> On 6/10/23 5:48 PM, olcott wrote:
>>>>>>>> On 6/10/2023 4:15 PM, Richard Damon wrote:
>>>>>>>>> On 6/10/23 5:06 PM, olcott wrote:
>>>>>>>>>> On 6/10/2023 3:27 PM, Richard Damon wrote:
>>>>>>>>>>> On 6/10/23 3:57 PM, olcott wrote:
>>>>>>>>>>>> On 6/10/2023 1:50 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 6/10/23 1:55 PM, olcott wrote:
>>>>>>>>>>>>>> On 6/10/2023 11:24 AM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 6/10/23 10:55 AM, olcott wrote:
>>>>>>>>>>>>>>>> On 6/10/2023 9:32 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 6/10/23 10:12 AM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 6/10/2023 8:54 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 6/10/23 9:23 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> 01 typedef int (*ptr)(); // pointer to int function
>>>>>>>>>>>>>>>>>>>> 02 int H(ptr x, ptr y)   // uses x86 emulator to
>>>>>>>>>>>>>>>>>>>> simulate its input
>>>>>>>>>>>>>>>>>>>> 03
>>>>>>>>>>>>>>>>>>>> 04 int D(ptr x)
>>>>>>>>>>>>>>>>>>>> 05 {
>>>>>>>>>>>>>>>>>>>> 06  int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>> 07  if (Halt_Status)
>>>>>>>>>>>>>>>>>>>> 08    HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>> 09  return Halt_Status;
>>>>>>>>>>>>>>>>>>>> 10 }
>>>>>>>>>>>>>>>>>>>> 11
>>>>>>>>>>>>>>>>>>>> 12 void main()
>>>>>>>>>>>>>>>>>>>> 13 {
>>>>>>>>>>>>>>>>>>>> 14  H(D,D);
>>>>>>>>>>>>>>>>>>>> 15 }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> When H is a simulating termination analyzer based on
>>>>>>>>>>>>>>>>>>>> an x86 emulator
>>>>>>>>>>>>>>>>>>>> within the x86utm operating system this is the
>>>>>>>>>>>>>>>>>>>> execution trace of the
>>>>>>>>>>>>>>>>>>>> above code:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Line 14: main() calls H(D,D) that simulates D(D)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> keeps repeating:
>>>>>>>>>>>>>>>>>>>> Line 06: simulated D(D) calls simulated H(D,D) that
>>>>>>>>>>>>>>>>>>>> simulates D(D) ...
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> So, you are defining that the CORRECT SIMULATION of a
>>>>>>>>>>>>>>>>>>> call to H(D,D) is that it keeps repeating its
>>>>>>>>>>>>>>>>>>> simulatin. We will call this stipulation A.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Simulation invariant:
>>>>>>>>>>>>>>>>>>>> D correctly simulated by H never reaches its own
>>>>>>>>>>>>>>>>>>>> Line 09.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Ok, if you say so. Remember that means that for all
>>>>>>>>>>>>>>>>>>> calls to H(D,D) it may not return a value. THAT is
>>>>>>>>>>>>>>>>>>> your invariant.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> This enables H to abort its simulation of D and
>>>>>>>>>>>>>>>>>>>> correctly report that
>>>>>>>>>>>>>>>>>>>> (its input) D correctly simulated by H never halts.
>>>>>>>>>>>>>>>>>>>> The above is fully
>>>>>>>>>>>>>>>>>>>> operational code within the x86utm operating system.
>>>>>>>>>>>>>>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> NO, because that volates the stipulation A you made
>>>>>>>>>>>>>>>>>>> that H(D,D) just keeps simulating its input, and your
>>>>>>>>>>>>>>>>>>> simulation invariant.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thus, while it may be correct for H to abort its
>>>>>>>>>>>>>>>>>>> siulation of D at this point, it can't actually do so
>>>>>>>>>>>>>>>>>>> without breaking its stipulations.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> IF the code of H actually DOES stop its simulation at
>>>>>>>>>>>>>>>>>>> this point, then the assumption made in Stipualation
>>>>>>>>>>>>>>>>>>> A is FALSE, and all following logic is as UNSOUND as
>>>>>>>>>>>>>>>>>>> your own mind.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> In fact, that ACTUAL behavior of D(D) calling H(D,D)
>>>>>>>>>>>>>>>>>>> is that H(D,D) will simulate its input to the point
>>>>>>>>>>>>>>>>>>> that it sees this simulated D(D) calling H(D,D), then
>>>>>>>>>>>>>>>>>>> it aborts its simuation and returns to the actual
>>>>>>>>>>>>>>>>>>> running D(D) the value 0 to indicate non-halting, and
>>>>>>>>>>>>>>>>>>> that D(D) will Then Halt.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thus, the CORRECT simulation of a the call to H(D,D)
>>>>>>>>>>>>>>>>>>> that H sees in its simulation of D(D) needs to
>>>>>>>>>>>>>>>>>>> somehow determine that this call will return a 0,
>>>>>>>>>>>>>>>>>>> since that is what it does, which means it does NOT
>>>>>>>>>>>>>>>>>>> do what you claimed at the point of Stipulation A,
>>>>>>>>>>>>>>>>>>> which just shows you are an ignorant pathological
>>>>>>>>>>>>>>>>>>> lying idiot.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *Broadening the Practical Scope of Software
>>>>>>>>>>>>>>>>>>>> Termination Analysis*
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/369971402_Broadening_the_Practical_Scope_of_Software_Termination_Analysis
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The DEFINITION of a "Correct Simulation" is that it
>>>>>>>>>>>>>>>>>>> correctly predicts the behavior of the actual program.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *That is not how termination analyzers works*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Then it isn't applicaple to the Halting Problem, or,
>>>>>>>>>>>>>>>>> more likely, you just don't understand what
>>>>>>>>>>>>>>>>> "Termination Analysis" actually is.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Termination analyzers compute the mapping from their
>>>>>>>>>>>>>>>>>> inputs to an accept
>>>>>>>>>>>>>>>>>> or reject state on the basis of the actual behavior
>>>>>>>>>>>>>>>>>> specified by this
>>>>>>>>>>>>>>>>>> input.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Right, and the ACTUAL BEHAVIOR is defined by what the
>>>>>>>>>>>>>>>>> program does when actually run.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *It is incorrect for them to compute the halt status
>>>>>>>>>>>>>>>>>> of non-inputs*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> int sum(int x, int y)
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>    return x + y;
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> H(sum, x, y) would need to compute the halt status of
>>>>>>>>>>>>>>>>> that input.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yes, H(D,D) doesn't give the answer to Sum(x,y), but
>>>>>>>>>>>>>>>>> need to give the answer to D(D).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You might be able to imagine that sum must be able to
>>>>>>>>>>>>>>>>>> compute the sum of
>>>>>>>>>>>>>>>>>> non-inputs and say that sum(3,4) derives an incorrect
>>>>>>>>>>>>>>>>>> result because it
>>>>>>>>>>>>>>>>>> does not compute the sum of 5 + 7.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So, you are just off serving Red Herring again.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> H(D,D) MUST answer about the halting status of the
>>>>>>>>>>>>>>>>> program D(D).
>>>>>>>>>>>>>>>> The behavior of D(D) is one recursive invocation away
>>>>>>>>>>>>>>>> from the actual
>>>>>>>>>>>>>>>> behavior of the actual input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No, the INPUT is a description of the ACTUAL machine, and
>>>>>>>>>>>>>>> the actual machine is what is being asked about.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So, either you accept that the behavior of the actual
>>>>>>>>>>>>>>> machine D(D) is the problem that is being asked, or you
>>>>>>>>>>>>>>> admit that your definitions say it is impossible to
>>>>>>>>>>>>>>> actually ASK the question of the problem.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Remember, the PROBLEM that you claim to be working on is
>>>>>>>>>>>>>>> DEFINED to be aobut the actual machines.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> H(D,D) is not allowed to report on what the behavior of
>>>>>>>>>>>>>>>> its input would
>>>>>>>>>>>>>>>> be after it aborts the simulation of this input because
>>>>>>>>>>>>>>>> it has not yet
>>>>>>>>>>>>>>>> aborted the simulation of this input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So, by your definition, H is not allowed to answer the
>>>>>>>>>>>>>>> actual question of the problem.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A termination analyzer is only asked about the behavior
>>>>>>>>>>>>>> specified by its
>>>>>>>>>>>>>> input. Try and find anything in any paper about
>>>>>>>>>>>>>> termination analyzers
>>>>>>>>>>>>>> that are required to report on the behavior of non-inputs.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> But the input is the description of the program in
>>>>>>>>>>>>> question. H(D,D) is being asked about D(D).
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Not when there is a pathological relationship between H and
>>>>>>>>>>>> D that
>>>>>>>>>>>> changes the behavior of the input D away from the behavior
>>>>>>>>>>>> of D(D).
>>>>>>>>>>>>
>>>>>>>>>>>> Because a termination analyzer always reports on the
>>>>>>>>>>>> behavior of its input H(D,D) must reject this input as
>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Where do you get that statement from?
>>>>>>>>>>>
>>>>>>>>>> Feel free to counter my claim by finding a published paper
>>>>>>>>>> where a
>>>>>>>>>> termination analyzer operates on something besides its input.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Note, I was refering to:
>>>>>>>>>
>>>>>>>>>  >>> Not when there is a pathological relationship between H
>>>>>>>>> and D that
>>>>>>>>>  >>> changes the behavior of the input D away from the behavior
>>>>>>>>> of D(D).
>>>>>>>>>
>>>>>>>>> Since you haven't shown any reference, but just served up some
>>>>>>>>> red herring, it is clear you don't actually have a reference,
>>>>>>>>> and thus the claim IS just a lie from your own distorted
>>>>>>>>> imagination.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The correct simulation of D by H is specified by the source-code
>>>>>>>> of D
>>>>>>>> within the assumption that H correctly simulates D with an x86
>>>>>>>> emulator.
>>>>>>>
>>>>>>> No, it specified by the source-code of D and H.
>>>>>> The cannot possibly be any aspect of the source-code of H that
>>>>>> enables D to reach its own line 09 and remain a correct simulation
>>>>>> of D by H.
>>>>>>
>>>>>
>>>>> Right, because H can't do a correct simulation of D.
>>>>>
>>>>
>>>> Try and explain line-by-line and step-by-step how D correctly simulated
>>>> by H would reach its own line 09.
>>>>
>>>
>>> You have a bad assumption in there, that H CAN "Correctly Simulate"
>>> this input. The H in your code doesn't do it (since "Correct" in this
>>> connotaion includes completely), an+d that is the only code that
>>> matters.
>> In other words you are claiming that D would terminate normally by
>> reaching its own line 09 if H would simply refrain from aborting its
>> simulation.
>>
>
> No, I am saying that since H DOES abort its simulation and return a 0,
> that D(D) Halts.
So you are a complete moron about hypothetical possibilities?

On 6/10/23 8:11 PM, olcott wrote:
> On 6/10/2023 7:08 PM, Richard Damon wrote:
>> On 6/10/23 8:01 PM, olcott wrote:
>>> On 6/10/2023 6:49 PM, Richard Damon wrote:
>>>> On 6/10/23 7:18 PM, olcott wrote:
>>>>> On 6/10/2023 5:52 PM, Richard Damon wrote:
>>>>>> On 6/10/23 6:26 PM, olcott wrote:
>>>>>>> On 6/10/2023 5:15 PM, Richard Damon wrote:
>>>>>>>> On 6/10/23 5:48 PM, olcott wrote:
>>>>>>>>> On 6/10/2023 4:15 PM, Richard Damon wrote:
>>>>>>>>>> On 6/10/23 5:06 PM, olcott wrote:
>>>>>>>>>>> On 6/10/2023 3:27 PM, Richard Damon wrote:
>>>>>>>>>>>> On 6/10/23 3:57 PM, olcott wrote:
>>>>>>>>>>>>> On 6/10/2023 1:50 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 6/10/23 1:55 PM, olcott wrote:
>>>>>>>>>>>>>>> On 6/10/2023 11:24 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 6/10/23 10:55 AM, olcott wrote:
>>>>>>>>>>>>>>>>> On 6/10/2023 9:32 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 6/10/23 10:12 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 6/10/2023 8:54 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 6/10/23 9:23 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> 01 typedef int (*ptr)(); // pointer to int function
>>>>>>>>>>>>>>>>>>>>> 02 int H(ptr x, ptr y)   // uses x86 emulator to
>>>>>>>>>>>>>>>>>>>>> simulate its input
>>>>>>>>>>>>>>>>>>>>> 03
>>>>>>>>>>>>>>>>>>>>> 04 int D(ptr x)
>>>>>>>>>>>>>>>>>>>>> 05 {
>>>>>>>>>>>>>>>>>>>>> 06  int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>>> 07  if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>> 08    HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>> 09  return Halt_Status;
>>>>>>>>>>>>>>>>>>>>> 10 }
>>>>>>>>>>>>>>>>>>>>> 11
>>>>>>>>>>>>>>>>>>>>> 12 void main()
>>>>>>>>>>>>>>>>>>>>> 13 {
>>>>>>>>>>>>>>>>>>>>> 14  H(D,D);
>>>>>>>>>>>>>>>>>>>>> 15 }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> When H is a simulating termination analyzer based
>>>>>>>>>>>>>>>>>>>>> on an x86 emulator
>>>>>>>>>>>>>>>>>>>>> within the x86utm operating system this is the
>>>>>>>>>>>>>>>>>>>>> execution trace of the
>>>>>>>>>>>>>>>>>>>>> above code:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Line 14: main() calls H(D,D) that simulates D(D)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> keeps repeating:
>>>>>>>>>>>>>>>>>>>>> Line 06: simulated D(D) calls simulated H(D,D) that
>>>>>>>>>>>>>>>>>>>>> simulates D(D) ...
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> So, you are defining that the CORRECT SIMULATION of
>>>>>>>>>>>>>>>>>>>> a call to H(D,D) is that it keeps repeating its
>>>>>>>>>>>>>>>>>>>> simulatin. We will call this stipulation A.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Simulation invariant:
>>>>>>>>>>>>>>>>>>>>> D correctly simulated by H never reaches its own
>>>>>>>>>>>>>>>>>>>>> Line 09.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Ok, if you say so. Remember that means that for all
>>>>>>>>>>>>>>>>>>>> calls to H(D,D) it may not return a value. THAT is
>>>>>>>>>>>>>>>>>>>> your invariant.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> This enables H to abort its simulation of D and
>>>>>>>>>>>>>>>>>>>>> correctly report that
>>>>>>>>>>>>>>>>>>>>> (its input) D correctly simulated by H never halts.
>>>>>>>>>>>>>>>>>>>>> The above is fully
>>>>>>>>>>>>>>>>>>>>> operational code within the x86utm operating system.
>>>>>>>>>>>>>>>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> NO, because that volates the stipulation A you made
>>>>>>>>>>>>>>>>>>>> that H(D,D) just keeps simulating its input, and
>>>>>>>>>>>>>>>>>>>> your simulation invariant.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thus, while it may be correct for H to abort its
>>>>>>>>>>>>>>>>>>>> siulation of D at this point, it can't actually do
>>>>>>>>>>>>>>>>>>>> so without breaking its stipulations.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> IF the code of H actually DOES stop its simulation
>>>>>>>>>>>>>>>>>>>> at this point, then the assumption made in
>>>>>>>>>>>>>>>>>>>> Stipualation A is FALSE, and all following logic is
>>>>>>>>>>>>>>>>>>>> as UNSOUND as your own mind.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> In fact, that ACTUAL behavior of D(D) calling H(D,D)
>>>>>>>>>>>>>>>>>>>> is that H(D,D) will simulate its input to the point
>>>>>>>>>>>>>>>>>>>> that it sees this simulated D(D) calling H(D,D),
>>>>>>>>>>>>>>>>>>>> then it aborts its simuation and returns to the
>>>>>>>>>>>>>>>>>>>> actual running D(D) the value 0 to indicate
>>>>>>>>>>>>>>>>>>>> non-halting, and that D(D) will Then Halt.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thus, the CORRECT simulation of a the call to H(D,D)
>>>>>>>>>>>>>>>>>>>> that H sees in its simulation of D(D) needs to
>>>>>>>>>>>>>>>>>>>> somehow determine that this call will return a 0,
>>>>>>>>>>>>>>>>>>>> since that is what it does, which means it does NOT
>>>>>>>>>>>>>>>>>>>> do what you claimed at the point of Stipulation A,
>>>>>>>>>>>>>>>>>>>> which just shows you are an ignorant pathological
>>>>>>>>>>>>>>>>>>>> lying idiot.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> *Broadening the Practical Scope of Software
>>>>>>>>>>>>>>>>>>>>> Termination Analysis*
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/369971402_Broadening_the_Practical_Scope_of_Software_Termination_Analysis
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The DEFINITION of a "Correct Simulation" is that it
>>>>>>>>>>>>>>>>>>>> correctly predicts the behavior of the actual program.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *That is not how termination analyzers works*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Then it isn't applicaple to the Halting Problem, or,
>>>>>>>>>>>>>>>>>> more likely, you just don't understand what
>>>>>>>>>>>>>>>>>> "Termination Analysis" actually is.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Termination analyzers compute the mapping from their
>>>>>>>>>>>>>>>>>>> inputs to an accept
>>>>>>>>>>>>>>>>>>> or reject state on the basis of the actual behavior
>>>>>>>>>>>>>>>>>>> specified by this
>>>>>>>>>>>>>>>>>>> input.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Right, and the ACTUAL BEHAVIOR is defined by what the
>>>>>>>>>>>>>>>>>> program does when actually run.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *It is incorrect for them to compute the halt status
>>>>>>>>>>>>>>>>>>> of non-inputs*
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> int sum(int x, int y)
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>    return x + y;
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> H(sum, x, y) would need to compute the halt status of
>>>>>>>>>>>>>>>>>> that input.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Yes, H(D,D) doesn't give the answer to Sum(x,y), but
>>>>>>>>>>>>>>>>>> need to give the answer to D(D).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> You might be able to imagine that sum must be able to
>>>>>>>>>>>>>>>>>>> compute the sum of
>>>>>>>>>>>>>>>>>>> non-inputs and say that sum(3,4) derives an incorrect
>>>>>>>>>>>>>>>>>>> result because it
>>>>>>>>>>>>>>>>>>> does not compute the sum of 5 + 7.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> So, you are just off serving Red Herring again.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> H(D,D) MUST answer about the halting status of the
>>>>>>>>>>>>>>>>>> program D(D).
>>>>>>>>>>>>>>>>> The behavior of D(D) is one recursive invocation away
>>>>>>>>>>>>>>>>> from the actual
>>>>>>>>>>>>>>>>> behavior of the actual input.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No, the INPUT is a description of the ACTUAL machine,
>>>>>>>>>>>>>>>> and the actual machine is what is being asked about.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So, either you accept that the behavior of the actual
>>>>>>>>>>>>>>>> machine D(D) is the problem that is being asked, or you
>>>>>>>>>>>>>>>> admit that your definitions say it is impossible to
>>>>>>>>>>>>>>>> actually ASK the question of the problem.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Remember, the PROBLEM that you claim to be working on is
>>>>>>>>>>>>>>>> DEFINED to be aobut the actual machines.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> H(D,D) is not allowed to report on what the behavior of
>>>>>>>>>>>>>>>>> its input would
>>>>>>>>>>>>>>>>> be after it aborts the simulation of this input because
>>>>>>>>>>>>>>>>> it has not yet
>>>>>>>>>>>>>>>>> aborted the simulation of this input.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So, by your definition, H is not allowed to answer the
>>>>>>>>>>>>>>>> actual question of the problem.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A termination analyzer is only asked about the behavior
>>>>>>>>>>>>>>> specified by its
>>>>>>>>>>>>>>> input. Try and find anything in any paper about
>>>>>>>>>>>>>>> termination analyzers
>>>>>>>>>>>>>>> that are required to report on the behavior of non-inputs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But the input is the description of the program in
>>>>>>>>>>>>>> question. H(D,D) is being asked about D(D).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Not when there is a pathological relationship between H and
>>>>>>>>>>>>> D that
>>>>>>>>>>>>> changes the behavior of the input D away from the behavior
>>>>>>>>>>>>> of D(D).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Because a termination analyzer always reports on the
>>>>>>>>>>>>> behavior of its input H(D,D) must reject this input as
>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Where do you get that statement from?
>>>>>>>>>>>>
>>>>>>>>>>> Feel free to counter my claim by finding a published paper
>>>>>>>>>>> where a
>>>>>>>>>>> termination analyzer operates on something besides its input.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Note, I was refering to:
>>>>>>>>>>
>>>>>>>>>>  >>> Not when there is a pathological relationship between H
>>>>>>>>>> and D that
>>>>>>>>>>  >>> changes the behavior of the input D away from the
>>>>>>>>>> behavior of D(D).
>>>>>>>>>>
>>>>>>>>>> Since you haven't shown any reference, but just served up some
>>>>>>>>>> red herring, it is clear you don't actually have a reference,
>>>>>>>>>> and thus the claim IS just a lie from your own distorted
>>>>>>>>>> imagination.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The correct simulation of D by H is specified by the
>>>>>>>>> source-code of D
>>>>>>>>> within the assumption that H correctly simulates D with an x86
>>>>>>>>> emulator.
>>>>>>>>
>>>>>>>> No, it specified by the source-code of D and H.
>>>>>>> The cannot possibly be any aspect of the source-code of H that
>>>>>>> enables D to reach its own line 09 and remain a correct
>>>>>>> simulation of D by H.
>>>>>>>
>>>>>>
>>>>>> Right, because H can't do a correct simulation of D.
>>>>>>
>>>>>
>>>>> Try and explain line-by-line and step-by-step how D correctly
>>>>> simulated
>>>>> by H would reach its own line 09.
>>>>>
>>>>
>>>> You have a bad assumption in there, that H CAN "Correctly Simulate"
>>>> this input. The H in your code doesn't do it (since "Correct" in
>>>> this connotaion includes completely), an+d that is the only code
>>>> that matters.
>>> In other words you are claiming that D would terminate normally by
>>> reaching its own line 09 if H would simply refrain from aborting its
>>> simulation.
>>>
>>
>> No, I am saying that since H DOES abort its simulation and return a 0,
>> that D(D) Halts.
> So you are a complete moron about hypothetical possibilities?
>