Software engineers can easily verify that D correctly simulated by H
cannot possibly reach its own line 09 and 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?

This means that when termination analyzer H aborts its simulation of D
and reports that its correctly simulated input cannot possibly terminate
normally it is merely reporting an easily verified fact.

*THE ABOVE IS AN EASILY VERIFIED FACT OF CORRECT SOFTWARE ENGINEERING*

I will provide the next steps of the analysis after the above has been
accepted.

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

Am 12.06.2023 um 18:34 schrieb olcott:
> Software engineers can easily verify that D correctly simulated by H
> cannot possibly reach its own line 09 and 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?
>
> This means that when termination analyzer H aborts its simulation of D
> and reports that its correctly simulated input cannot possibly terminate
> normally it is merely reporting an easily verified fact.
>
> *THE ABOVE IS AN EASILY VERIFIED FACT OF CORRECT SOFTWARE ENGINEERING*
>
> I will provide the next steps of the analysis after the above has been
> accepted.
>

Does it get you anywhere, obsessing over the same detail for years?

On 6/12/2023 12:04 PM, Bonita Montero wrote:
> Am 12.06.2023 um 18:34 schrieb olcott:
>> Software engineers can easily verify that D correctly simulated by H
>> cannot possibly reach its own line 09 and 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?
>>
>> This means that when termination analyzer H aborts its simulation of D
>> and reports that its correctly simulated input cannot possibly terminate
>> normally it is merely reporting an easily verified fact.
>>
>> *THE ABOVE IS AN EASILY VERIFIED FACT OF CORRECT SOFTWARE ENGINEERING*
>>
>> I will provide the next steps of the analysis after the above has been
>> accepted.
>>
>
> Does it get you anywhere, obsessing over the same detail for years?

I have improved the wording such that anyone with a modicum of software
engineering competence can easily verify that the above is necessarily
correct. H(D,D) does correctly report that D correctly simulated by H
cannot possibly terminate normally by reaching its own line 09.

Also I finally have an easily understood rebuttal to the one remaining
objection to my work that Ben Bacarisse has been so heavily pushing.

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

Am 12.06.2023 um 19:27 schrieb olcott:
> On 6/12/2023 12:04 PM, Bonita Montero wrote:
>> Am 12.06.2023 um 18:34 schrieb olcott:
>>> Software engineers can easily verify that D correctly simulated by H
>>> cannot possibly reach its own line 09 and 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?
>>>
>>> This means that when termination analyzer H aborts its simulation of D
>>> and reports that its correctly simulated input cannot possibly terminate
>>> normally it is merely reporting an easily verified fact.
>>>
>>> *THE ABOVE IS AN EASILY VERIFIED FACT OF CORRECT SOFTWARE ENGINEERING*
>>>
>>> I will provide the next steps of the analysis after the above has
>>> been accepted.
>>>
>>
>> Does it get you anywhere, obsessing over the same detail for years?
>
> I have improved the wording such that anyone with a modicum of software
> engineering competence can easily verify that the above is necessarily
> correct. H(D,D) does correctly report that D correctly simulated by H
> cannot possibly terminate normally by reaching its own line 09.
>
> Also I finally have an easily understood rebuttal to the one remaining
> objection to my work that Ben Bacarisse has been so heavily pushing.

How is that related to my question ?

On 6/12/2023 1:30 PM, Bonita Montero wrote:
> Am 12.06.2023 um 19:27 schrieb olcott:
>> On 6/12/2023 12:04 PM, Bonita Montero wrote:
>>> Am 12.06.2023 um 18:34 schrieb olcott:
>>>> Software engineers can easily verify that D correctly simulated by H
>>>> cannot possibly reach its own line 09 and 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?
>>>>
>>>> This means that when termination analyzer H aborts its simulation of D
>>>> and reports that its correctly simulated input cannot possibly
>>>> terminate
>>>> normally it is merely reporting an easily verified fact.
>>>>
>>>> *THE ABOVE IS AN EASILY VERIFIED FACT OF CORRECT SOFTWARE ENGINEERING*
>>>>
>>>> I will provide the next steps of the analysis after the above has
>>>> been accepted.
>>>>
>>>
>>> Does it get you anywhere, obsessing over the same detail for years?
>>
>> I have improved the wording such that anyone with a modicum of software
>> engineering competence can easily verify that the above is necessarily
>> correct. H(D,D) does correctly report that D correctly simulated by H
>> cannot possibly terminate normally by reaching its own line 09.
>>
>> Also I finally have an easily understood rebuttal to the one remaining
>> objection to my work that Ben Bacarisse has been so heavily pushing.
>
> How is that related to my question ?
>
>

>>> Does it get you anywhere, obsessing over the same detail for years?

*Yes it does here is how it does*
Because I have focused on the issue of H(D,D) determining the halt
status of its input for several years I have simplified my words so that
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 latest (very recent) change is to switch the frame-of-reference from
computer science halt deciders to software engineering termination
analyzers.

--
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 10:04 AM, Bonita Montero wrote:
> Am 12.06.2023 um 18:34 schrieb olcott:
>> Software engineers can easily verify that D correctly simulated by H
>> cannot possibly reach its own line 09 and 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?
>>
>> This means that when termination analyzer H aborts its simulation of D
>> and reports that its correctly simulated input cannot possibly terminate
>> normally it is merely reporting an easily verified fact.
>>
>> *THE ABOVE IS AN EASILY VERIFIED FACT OF CORRECT SOFTWARE ENGINEERING*
>>
>> I will provide the next steps of the analysis after the above has been
>> accepted.
>>
>
> Does it get you anywhere, obsessing over the same detail for years?

No shit Bonita! wow.

On 6/12/2023 2:53 PM, Chris M. Thomasson wrote:
> On 6/12/2023 10:04 AM, Bonita Montero wrote:
>> Am 12.06.2023 um 18:34 schrieb olcott:
>>> Software engineers can easily verify that D correctly simulated by H
>>> cannot possibly reach its own line 09 and 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?
>>>
>>> This means that when termination analyzer H aborts its simulation of D
>>> and reports that its correctly simulated input cannot possibly terminate
>>> normally it is merely reporting an easily verified fact.
>>>
>>> *THE ABOVE IS AN EASILY VERIFIED FACT OF CORRECT SOFTWARE ENGINEERING*
>>>
>>> I will provide the next steps of the analysis after the above has
>>> been accepted.
>>>
>>
>> Does it get you anywhere, obsessing over the same detail for years?
>
> No shit Bonita! wow.

>>> Does it get you anywhere, obsessing over the same detail for years?

*Yes it does here is how it does*
Because I have focused on the issue of H(D,D) determining the halt
status of its input for several years I have simplified my words so that
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 latest (very recent) change is to switch the frame-of-reference from
computer science halt deciders to software engineering termination
analyzers.

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 12/06/2023 18:04, Bonita Montero wrote:
>
>
> Does it get you anywhere, obsessing over the same detail for years?

He once said he gets a very hard erection to attend Bunga Bunga sex
party organised by late Silvio Berlusconi of Italy. He can show his
prowess in C programming at these parties.

On 6/12/23 12:34 PM, olcott wrote:
> Software engineers can easily verify that D correctly simulated by H
> cannot possibly reach its own line 09 and terminate normally.

I showed your flaws in comp.theory

Yes, No H can simulate D to its termination, but that does NOT mean that
D is non-halting

Only that no H can actually do a "correct" simulation and give an answer.

Since Halting is NOT about the simulation done by the decider, you are
just proving that you are totally ignorant of the problem you claim to
be solving.

On Monday, 12 June 2023 at 18:27:36 UTC+1, olcott wrote:
> On 6/12/2023 12:04 PM, Bonita Montero wrote:
> > Am 12.06.2023 um 18:34 schrieb olcott:
> >> Software engineers can easily verify that D correctly simulated by H
> >> cannot possibly reach its own line 09 and terminate normally.

<snip a load of old bollocks>

> >> *THE ABOVE IS AN EASILY VERIFIED FACT OF CORRECT SOFTWARE ENGINEERING*

<snip the remaining bollocks>

It is apparent that you do not have a clue what Software Engineering is.
A Software Engineer is a practitioner of the principles defined by the
Software Development Lifecycle (SDLC). There is no "verified fact
of correct Software Engineering" in your algorithm.

On 6/14/2023 9:35 AM, Tony Oliver wrote:
> On Monday, 12 June 2023 at 18:27:36 UTC+1, olcott wrote:
>> On 6/12/2023 12:04 PM, Bonita Montero wrote:
>>> Am 12.06.2023 um 18:34 schrieb olcott:
>>>> Software engineers can easily verify that D correctly simulated by H
>>>> cannot possibly reach its own line 09 and terminate normally.
>
> <snip a load of old bollocks>
>
>>>> *THE ABOVE IS AN EASILY VERIFIED FACT OF CORRECT SOFTWARE ENGINEERING*
>
> <snip the remaining bollocks>
>
> It is apparent that you do not have a clue what Software Engineering is.
> A Software Engineer is a practitioner of the principles defined by the
> Software Development Lifecycle (SDLC). There is no "verified fact
> of correct Software Engineering" in your algorithm.

*Thanks for replying I really need software engineering feedback*

Software engineering is much more than merely the system development
lifecycle it also includes extremely much more rigor in the development
of software than computer programming.

Software engineers operate within something like axioms of computer
programming, design patterns are an example of this.
https://en.wikipedia.org/wiki/Design_Patterns

The kind of rigorous analysis performed by software engineers
conclusively proves that D correctly simulated by H cannot possibly
terminate normally.

I wrote the x86utm operating system. The most difficult part was
providing the infrastructure to support the context switch so that
termination analyzer H could simulate itself simulating itself to an
arbitrary level of recursive depth.

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 H(D,D);
15 }

Execution Trace
Line 14: main() invokes H(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.

H correctly determines that D correctly simulated by H cannot possibly
terminate normally on the basis that H recognizes a dynamic behavior
pattern equivalent to infinite recursion.

The x86utm operating system (includes several termination analyzers)
https://github.com/plolcott/x86utm

It compiles with the 2017 version of the Community Edition
https://visualstudio.microsoft.com/thank-you-downloading-visual-studio/?sku=Community&rel=15

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

Pete, do you have an occupation as a software engineer ?

On 6/14/2023 10:09 AM, Bonita Montero wrote:
> Pete, do you have an occupation as a software engineer ?

I have been a professional C++ software engineer since 2001. Learned C
when K&R was the standard. I met Bjarne Stroustrup in person when he was
promoting his brand new C++ programming language.

On several projects for the air force we had daily scrum meetings.
I worked for Northrop Grumman at the air force base on their NPOESS
satellite system. https://en.wikipedia.org/wiki/NPOESS

I have two software engineering patents that are deterministic finite
automaton optical character recognizers.

Software engineering is much more than the development life cycle it
applies much more rigor in many different ways using a variety of tools
and methods. Refactoring, automated regression testing and UML are a
part of software engineering.

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

Am 14.06.2023 um 17:45 schrieb olcott:
> On 6/14/2023 10:09 AM, Bonita Montero wrote:
>> Pete, do you have an occupation as a software engineer ?
>
> I have been a professional C++ software engineer since 2001. Learned C
> when K&R was the standard. I met Bjarne Stroustrup in person when he was
> promoting his brand new C++ programming language.
>
> On several projects for the air force we had daily scrum meetings.
> I worked for Northrop Grumman at the air force base on their NPOESS
> satellite system. https://en.wikipedia.org/wiki/NPOESS
>
> I have two software engineering patents that are deterministic finite
> automaton optical character recognizers.
>
> Software engineering is much more than the development life cycle it
> applies much more rigor in many different ways using a variety of tools
> and methods. Refactoring, automated regression testing and UML are a
> part of software engineering.

I gues you're currently doing nothing with sw-development because
you're stuck in a nonsense-loop.

On 6/14/2023 10:48 AM, Bonita Montero wrote:
> Am 14.06.2023 um 17:45 schrieb olcott:
>> On 6/14/2023 10:09 AM, Bonita Montero wrote:
>>> Pete, do you have an occupation as a software engineer ?
>>
>> I have been a professional C++ software engineer since 2001. Learned C
>> when K&R was the standard. I met Bjarne Stroustrup in person when he was
>> promoting his brand new C++ programming language.
>>
>> On several projects for the air force we had daily scrum meetings.
>> I worked for Northrop Grumman at the air force base on their NPOESS
>> satellite system. https://en.wikipedia.org/wiki/NPOESS
>>
>> I have two software engineering patents that are deterministic finite
>> automaton optical character recognizers.
>>
>> Software engineering is much more than the development life cycle it
>> applies much more rigor in many different ways using a variety of tools
>> and methods. Refactoring, automated regression testing and UML are a
>> part of software engineering.
>
> I gues you're currently doing nothing with sw-development because
> you're stuck in a nonsense-loop.
>
>

If you would bother to pay attention and actually examine my work you
would comprehend that termination analyzer H does correctly prevent the
denial of service attack that would otherwise succeed when H is provided
a halting problem styled pathological input D.

*You only have to carefully examine the first page to see this*
(The last two pages apply the same principle to computer science)

*Termination Analyzer H prevents Denial of Service attacks*
https://www.researchgate.net/publication/369971402_Termination_Analyzer_H_prevents_Denial_of_Service_attacks

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

Am 14.06.2023 um 17:58 schrieb olcott:
> On 6/14/2023 10:48 AM, Bonita Montero wrote:
>> Am 14.06.2023 um 17:45 schrieb olcott:
>>> On 6/14/2023 10:09 AM, Bonita Montero wrote:
>>>> Pete, do you have an occupation as a software engineer ?
>>>
>>> I have been a professional C++ software engineer since 2001. Learned C
>>> when K&R was the standard. I met Bjarne Stroustrup in person when he was
>>> promoting his brand new C++ programming language.
>>>
>>> On several projects for the air force we had daily scrum meetings.
>>> I worked for Northrop Grumman at the air force base on their NPOESS
>>> satellite system. https://en.wikipedia.org/wiki/NPOESS
>>>
>>> I have two software engineering patents that are deterministic finite
>>> automaton optical character recognizers.
>>>
>>> Software engineering is much more than the development life cycle it
>>> applies much more rigor in many different ways using a variety of tools
>>> and methods. Refactoring, automated regression testing and UML are a
>>> part of software engineering.
>>
>> I gues you're currently doing nothing with sw-development because
>> you're stuck in a nonsense-loop.
>>
>>
>
> If you would bother to pay attention and actually examine my work you
> would comprehend that termination analyzer H does correctly prevent the
> denial of service attack that would otherwise succeed when H is provided
> a halting problem styled pathological input D.
>
> *You only have to carefully examine the first page to see this*
> (The last two pages apply the same principle to computer science)
>
> *Termination Analyzer H prevents Denial of Service attacks*
> https://www.researchgate.net/publication/369971402_Termination_Analyzer_H_prevents_Denial_of_Service_attacks
>
>

I guess that you have a psychosis and your IT topic
is a delusion from which you can no longer get out.

On 6/14/2023 11:04 AM, Bonita Montero wrote:
> Am 14.06.2023 um 17:58 schrieb olcott:
>> On 6/14/2023 10:48 AM, Bonita Montero wrote:
>>> Am 14.06.2023 um 17:45 schrieb olcott:
>>>> On 6/14/2023 10:09 AM, Bonita Montero wrote:
>>>>> Pete, do you have an occupation as a software engineer ?
>>>>
>>>> I have been a professional C++ software engineer since 2001. Learned C
>>>> when K&R was the standard. I met Bjarne Stroustrup in person when he
>>>> was
>>>> promoting his brand new C++ programming language.
>>>>
>>>> On several projects for the air force we had daily scrum meetings.
>>>> I worked for Northrop Grumman at the air force base on their NPOESS
>>>> satellite system. https://en.wikipedia.org/wiki/NPOESS
>>>>
>>>> I have two software engineering patents that are deterministic
>>>> finite automaton optical character recognizers.
>>>>
>>>> Software engineering is much more than the development life cycle it
>>>> applies much more rigor in many different ways using a variety of tools
>>>> and methods. Refactoring, automated regression testing and UML are a
>>>> part of software engineering.
>>>
>>> I gues you're currently doing nothing with sw-development because
>>> you're stuck in a nonsense-loop.
>>>
>>>
>>
>> If you would bother to pay attention and actually examine my work you
>> would comprehend that termination analyzer H does correctly prevent the
>> denial of service attack that would otherwise succeed when H is provided
>> a halting problem styled pathological input D.
>>
>> *You only have to carefully examine the first page to see this*
>> (The last two pages apply the same principle to computer science)
>>
>> *Termination Analyzer H prevents Denial of Service attacks*
>> https://www.researchgate.net/publication/369971402_Termination_Analyzer_H_prevents_Denial_of_Service_attacks
>>
>>
>
> I guess that you have a psychosis and your IT topic
> is a delusion from which you can no longer get out.

If you actually look at what I said and try to find an actual mistake
you will see that this is not true.

*It is an easily verified fact that*
Termination analyzer H does correctly thwart a denial of service attack
that would have otherwise succeeded when H is presented with the halting
problem's otherwise "impossible" input: D.

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

Am 14.06.2023 um 18:24 schrieb olcott:

> If you actually look at what I said and try to find an actual mistake
> you will see that this is not true.
>
> *It is an easily verified fact that*
> Termination analyzer H does correctly thwart a denial of service attack
> that would have otherwise succeeded when H is presented with the halting
> problem's otherwise "impossible" input: D.

Now I'm 100% confident that you have got a psychosis.

On 6/14/2023 11:26 AM, Bonita Montero wrote:
> Am 14.06.2023 um 18:24 schrieb olcott:
>
>> If you actually look at what I said and try to find an actual mistake
>> you will see that this is not true.
>>
>> *It is an easily verified fact that*
>> Termination analyzer H does correctly thwart a denial of service attack
>> that would have otherwise succeeded when H is presented with the halting
>> problem's otherwise "impossible" input: D.
>
> Now I'm 100% confident that you have got a psychosis.
>

That is merely an example of the ad hominem error of reasoning.

(Attacking the person): This fallacy occurs when, instead of addressing
someone's argument or position, you irrelevantly attack the person or
some aspect of the person who is making the argument.
https://www.txst.edu/philosophy/resources/fallacy-definitions/Ad-Hominem.html

It is not even in the ballpark of showing any error in my claim.

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

Am 14.06.2023 um 18:43 schrieb olcott:

> That is merely an example of the ad hominem error of reasoning.

That's not ad homimem. I just wanted to say that you've
sth. completely different than a comuter science problem.

On 6/14/2023 12:03 PM, Bonita Montero wrote:
> Am 14.06.2023 um 18:43 schrieb olcott:
>
>> That is merely an example of the ad hominem error of reasoning.
>
> That's not ad homimem. I just wanted to say that you've
> sth. completely different than a comuter science problem.
>

I reframed the problem from a computer science halt decider to a
termination analyzer that correctly prevents denial of service attacks
from inputs matching the halting problem's input template.

Because H does correctly thwart denial of service attacks based on this
input then H is necessarily correct from this frame-of-reference.

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

Am 14.06.2023 um 19:16 schrieb olcott:
> On 6/14/2023 12:03 PM, Bonita Montero wrote:
>> Am 14.06.2023 um 18:43 schrieb olcott:
>>
>>> That is merely an example of the ad hominem error of reasoning.
>>
>> That's not ad homimem. I just wanted to say that you've
>> sth. completely different than a comuter science problem.
>>
>
> I reframed the problem from a computer science halt decider to a
> termination analyzer that correctly prevents denial of service attacks
> from inputs matching the halting problem's input template.
>
> Because H does correctly thwart denial of service attacks based on
> this input then H is necessarily correct from this frame-of-reference.

I think that others around here understand what I said.
But not you.

On 6/14/2023 1:37 PM, Bonita Montero wrote:
> Am 14.06.2023 um 19:16 schrieb olcott:
>> On 6/14/2023 12:03 PM, Bonita Montero wrote:
>>> Am 14.06.2023 um 18:43 schrieb olcott:
>>>
>>>> That is merely an example of the ad hominem error of reasoning.
>>>
>>> That's not ad homimem. I just wanted to say that you've
>>> sth. completely different than a comuter science problem.
>>>
>>
>> I reframed the problem from a computer science halt decider to a
>> termination analyzer that correctly prevents denial of service attacks
>> from inputs matching the halting problem's input template.
>>
>> Because H does correctly thwart denial of service attacks based on
>> this input then H is necessarily correct from this frame-of-reference.
>
>
> I think that others around here understand what I said.
> But not you.
>

So you do not understand that that termination analyzer H does correctly
thwart what would be an otherwise successful denial of service attack by
by pathological input D?

Are you new to the C++ programming language? A few years ago I beat Herb
Sutter's std::string by about 23-fold faster performance.

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

Am 14.06.2023 um 20:58 schrieb olcott:

> So you do not understand that that termination analyzer H does correctly
> thwart what would be an otherwise successful denial of service attack by
> by pathological input D?

*facepalm*
The therapist who is a match for you has yet to be born.

On 6/14/2023 2:49 PM, Bonita Montero wrote:
> Am 14.06.2023 um 20:58 schrieb olcott:
>
>> So you do not understand that that termination analyzer H does correctly
>> thwart what would be an otherwise successful denial of service attack by
>> by pathological input D?
>
> *facepalm*
> The therapist who is a match for you has yet to be born.

People that insist on staying in rebuttal mode even against the
easily verified facts can be spotted when their entire rebuttal
is an ad hominem attack.

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