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 Saturday, 10 June 2023 at 14:38:27 UTC+1, 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) ...
>
> 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

Oh god, this dipstick has simply changed languages.

Give it up, Olcott : you've already had your ravings falsified.

On 6/10/2023 1:39 PM, Tony Oliver wrote:
> On Saturday, 10 June 2023 at 14:38:27 UTC+1, 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) ...
>>
>> 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
>
> Oh god, this dipstick has simply changed languages.
>
> Give it up, Olcott : you've already had your ravings falsified.

The reason that I persist is that no one ever actually falsified my
work. It is the case that D correctly simulated by H cannot possibly
reach its own line 09. Someone on this forum agreed with that. It is
also the case that this does provide a correct basis for a termination
analyzer to reject its 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

In article <19d181b6-d2b7-40c1-aafa-39b3207a834en@googlegroups.com>,
Tony Oliver <guinness.tony@gmail.com> wrote:
>On Saturday, 10 June 2023 at 14:38:27 UTC+1, olcott wrote:
>> [snip]
>
>Oh god, this dipstick has simply changed languages.
>
>Give it up, Olcott : you've already had your ravings falsified.

This Olcott guy is a pure crank; please don't feed the troll.

- Dan C.

On 6/10/2023 1:39 PM, Tony Oliver wrote:
> On Saturday, 10 June 2023 at 14:38:27 UTC+1, 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) ...
>>
>> 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
>
> Oh god, this dipstick has simply changed languages.
>
> Give it up, Olcott : you've already had your ravings falsified.

*Please look at this again* (it has been rewritten)

(1) It is dead obvious to everyone here when examining the execution
trace of lines 14 and 06 above that D correctly simulated by H cannot
possibly terminate normally by reaching its own line 09.

(2) When evaluating termination analyzer H within the context of
software engineering it becomes dead obvious that H must provide the
halt status based on the actual behavior of its actual input.

All of the prior rebuttals were based on the assumption that a computer
science halt decider must report on the behavior of non-inputs.

Software engineers know that (from the software engineering perspective)
this is ridiculous. (I learned C when K&R was the standard)

(a) The behavior of D correctly simulated by H
(b) The behavior of the directly executed D(D)

(a) and (b) are different by one recursive invocation.

(a) must abort its simulation of D and
(b) has already aborted its simulation of D
This gives (a) and (b) different behavior.

--
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/11/2023 7:39 PM, olcott wrote:
> On 6/10/2023 1:39 PM, Tony Oliver wrote:
>> On Saturday, 10 June 2023 at 14:38:27 UTC+1, olcott wrote:
>>> 01 typedef int (*ptr)(); // pointer to int function
>>> 02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
[...]

Where can one take a look at this emulator you are using?

On 6/11/2023 10:49 PM, Chris M. Thomasson wrote:
> On 6/11/2023 7:39 PM, olcott wrote:
>> On 6/10/2023 1:39 PM, Tony Oliver wrote:
>>> On Saturday, 10 June 2023 at 14:38:27 UTC+1, olcott wrote:
>>>> 01 typedef int (*ptr)(); // pointer to int function
>>>> 02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
> [...]
>
> Where can one take a look at this emulator you are using?
>

The whole system is right here:
https://github.com/plolcott/x86utm

It compiles with the 2017 version of the Community Edition
https://visualstudio.microsoft.com/vs/older-downloads/

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

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

> Where can one take a look at this emulator you are using?

Take care. You could have replied to exactly the same nonsense in at
least two other groups that have already been lost to the cranks. The
groups the still work (like this one) need to be nurtured.

--
Ben.

On 6/12/2023 6:37 AM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>
>> Where can one take a look at this emulator you are using?
>
> Take care. You could have replied to exactly the same nonsense in at
> least two other groups that have already been lost to the cranks. The
> groups the still work (like this one) need to be nurtured.
>
In this case I proved that you are incorrect.

All of the prior rebuttals were based on the assumption that a computer
science halt decider must report on the behavior of non-inputs.

Software engineers know that (from the software engineering perspective)
this is ridiculous. (I learned C when K&R was the standard)

(a) The behavior of D correctly simulated by H
(b) The behavior of the directly executed D(D)

(a) and (b) are different by one recursive invocation.

(a) must abort its simulation of D and
(b) has already aborted its simulation of D
This gives (a) and (b) different behavior.

--
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/12/2023 4:37 AM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>
>> Where can one take a look at this emulator you are using?
>
> Take care. You could have replied to exactly the same nonsense in at
> least two other groups that have already been lost to the cranks. The
> groups the still work (like this one) need to be nurtured.
>

42 14

y :De mx7< NPa m&$\Jf u9-@\RYA m=\Mh? M3]v 52q

On 6/12/2023 2:57 PM, Chris M. Thomasson wrote:
> On 6/12/2023 4:37 AM, Ben Bacarisse wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>
>>> Where can one take a look at this emulator you are using?
>>
>> Take care.  You could have replied to exactly the same nonsense in at
>> least two other groups that have already been lost to the cranks.  The
>> groups the still work (like this one) need to be nurtured.
>>
>
> 42 14
>
> y :De mx7< NPa m&$\Jf u9-@\RYA m=\Mh? M3]v 52q

*NO ONE CAN CORRECTLY REFUTE THIS EASILY VERIFIED FACT*
Anyone with a modicum of software engineering knowledge can easily
verify that H(D,D) does correctly determine that D correctly simulated
by H cannot possibly terminate normally.

The whole system is right here:
https://github.com/plolcott/x86utm

It compiles with the 2017 version of the Community Edition
https://visualstudio.microsoft.com/vs/older-downloads/

--
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/12/2023 1:28 PM, olcott wrote:
> On 6/12/2023 2:57 PM, Chris M. Thomasson wrote:
>> On 6/12/2023 4:37 AM, Ben Bacarisse wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>
>>>> Where can one take a look at this emulator you are using?
>>>
>>> Take care.  You could have replied to exactly the same nonsense in at
>>> least two other groups that have already been lost to the cranks.  The
>>> groups the still work (like this one) need to be nurtured.
>>>
>>
>> 42 14
>>
>> y :De mx7< NPa m&$\Jf u9-@\RYA m=\Mh? M3]v 52q
>

> *NO ONE CAN CORRECTLY REFUTE THIS EASILY VERIFIED FACT*
> Anyone with a modicum of software engineering knowledge can easily
> verify that H(D,D) does correctly determine that D correctly simulated
> by H cannot possibly terminate normally.
>
> The whole system is right here:
> https://github.com/plolcott/x86utm
>
> It compiles with the 2017 version of the Community Edition
> https://visualstudio.microsoft.com/vs/older-downloads/
>

Humm... Are you a bot?

On 6/12/2023 4:07 PM, Chris M. Thomasson wrote:
> On 6/12/2023 1:28 PM, olcott wrote:
>> On 6/12/2023 2:57 PM, Chris M. Thomasson wrote:
>>> On 6/12/2023 4:37 AM, Ben Bacarisse wrote:
>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>
>>>>> Where can one take a look at this emulator you are using?
>>>>
>>>> Take care.  You could have replied to exactly the same nonsense in at
>>>> least two other groups that have already been lost to the cranks.  The
>>>> groups the still work (like this one) need to be nurtured.
>>>>
>>>
>>> 42 14
>>>
>>> y :De mx7< NPa m&$\Jf u9-@\RYA m=\Mh? M3]v 52q
>>
>
>
>> *NO ONE CAN CORRECTLY REFUTE THIS EASILY VERIFIED FACT*
>> Anyone with a modicum of software engineering knowledge can easily
>> verify that H(D,D) does correctly determine that D correctly simulated
>> by H cannot possibly terminate normally.
>>
>> The whole system is right here:
>> https://github.com/plolcott/x86utm
>>
>> It compiles with the 2017 version of the Community Edition
>> https://visualstudio.microsoft.com/vs/older-downloads/
>>
>
> Humm... Are you a bot?

I am not a bot.

--
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/12/2023 4:07 PM, Chris M. Thomasson wrote:
> On 6/12/2023 1:28 PM, olcott wrote:
>> On 6/12/2023 2:57 PM, Chris M. Thomasson wrote:
>>> On 6/12/2023 4:37 AM, Ben Bacarisse wrote:
>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>
>>>>> Where can one take a look at this emulator you are using?
>>>>
>>>> Take care.  You could have replied to exactly the same nonsense in at
>>>> least two other groups that have already been lost to the cranks.  The
>>>> groups the still work (like this one) need to be nurtured.
>>>>
>>>
>>> 42 14
>>>
>>> y :De mx7< NPa m&$\Jf u9-@\RYA m=\Mh? M3]v 52q
>>
>
>
>> *NO ONE CAN CORRECTLY REFUTE THIS EASILY VERIFIED FACT*
>> Anyone with a modicum of software engineering knowledge can easily
>> verify that H(D,D) does correctly determine that D correctly simulated
>> by H cannot possibly terminate normally.
>>
>> The whole system is right here:
>> https://github.com/plolcott/x86utm
>>
>> It compiles with the 2017 version of the Community Edition
>> https://visualstudio.microsoft.com/vs/older-downloads/
>>
>
> Humm... Are you a bot?

Do you understand that D correctly simulated by H cannot possibly
terminate normally?

The x86utm operating system based on an open source x86 emulator.
This system enables one C function to execute another C function in
debug step mode. When H simulates D it creates a separate process
context for D with its own memory, stack and virtual registers. H is
able to simulate D simulating itself, thus the only limit to recursive
simulations is RAM.

// The following is written in C
//
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 D(D);
15 }

*Execution Trace*
Line 14: main() invokes D(D)

*keeps repeating* (unless aborted)
Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)

*Simulation invariant*
D correctly simulated by H cannot possibly reach its own line 09.

Is it dead obvious to everyone here when examining the execution
trace of lines 14 and 06 above that D correctly simulated by H cannot
possibly terminate normally by reaching its own line 09?

--
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/12/23 10:41 AM, olcott wrote:

> All of the prior rebuttals were based on the assumption that a computer
> science halt decider must report on the behavior of non-inputs.
>
Which proves that you are not talking about the Halting Problem. PERIOD.

Remember, the Halting Problem says that the decider is to answer about
the Machine Describe by it input.

If H(D,D) is NOT refering to D(D), then why did you call it that way.

Obviously, because H isn't actually a Halt Decider, but just a POOP decider.

Eitehr your comment is a stupid statement that it is IMPOSSIBLE to
actually make a desciption of a machine to give the a decider (but it
has been proven that you can), or that you are INTENTIONALLY lying about
the rules of your H and giving it the wrong input to ask about D(D), or
you are just lying about your H being a Halt Decider.

Your choice, which way are you lying?

Richard Damon <Richard@Damon-Family.org> writes:
> On 6/12/23 10:41 AM, olcott wrote:
>> All of the prior rebuttals [SNIP]
> Which proves that [SNIP]
[...]

Richard, please confine this to comp.theory. I already filter out
everything olcott posts to comp.lang.c and comp.lang.c++; don't help him
bypass my filters (and presumably those of a lot of other readers).

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

In article <87a5x4i4ov.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>Richard Damon <Richard@Damon-Family.org> writes:
>> On 6/12/23 10:41 AM, olcott wrote:
>>> All of the prior rebuttals [SNIP]
>> Which proves that [SNIP]
>[...]
>
>Richard, please confine this to comp.theory. I already filter out
>everything olcott posts to comp.lang.c and comp.lang.c++; don't help him
>bypass my filters (and presumably those of a lot of other readers).

Indeed. Please keep this elsewhere. Or better yet,
don't respond to the OP at all.

- Dan C.

On 6/13/2023 6:12 AM, Dan Cross wrote:
> In article <87a5x4i4ov.fsf@nosuchdomain.example.com>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>> On 6/12/23 10:41 AM, olcott wrote:
>>>> All of the prior rebuttals [SNIP]
>>> Which proves that [SNIP]
>> [...]
>>
>> Richard, please confine this to comp.theory. I already filter out
>> everything olcott posts to comp.lang.c and comp.lang.c++; don't help him
>> bypass my filters (and presumably those of a lot of other readers).
>
> Indeed. Please keep this elsewhere. Or better yet,
> don't respond to the OP at all.
>
> - Dan C.
>

The purpose of solving the halting problem is to determine non-halting
bugs and non-halting malevolent software. My system achieves that
purpose.

It is only when the halting problem is construed as providing a correct
yes/no answer to a self-contradictory question that the halting problem
cannot be solved.

When termination analyzer H is intended to prevent denial of service
attacks is presented with an input D that has been defined to have a
pathological relationship to this termination analyzer, it correctly
aborts the simulation of this input that would have otherwise caused H
to never terminate until system resources have been exhausted, crashing
the system.

*The halting problem is an issue with denial of service attacks*
https://medium.com/coinmonks/ethereum-what-is-gas-and-why-do-we-need-it-88bcd7fc191d

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