void DDD()
{
HHH(DDD);
return;
}

int main()
{
HHH(DDD);
}

Understanding that DDD correctly simulated by HHH cannot
possibly reach its own "return" instruction is a mandatory
prerequisite to further discussion.

I can't imagine that anyone having sufficient understanding
of C would not agree that DDD correctly simulated by HHH
cannot possibly reach its own "return" instruction. Several
C experts already agreed to this two of them having masters
in computer science: MSCS.

People are either disagreeing for trollish pleasure or have
woefully insufficient expertise in the C programming language.
*Either one of these is a deal killer*

Once they understand this we need to add one more point
that the "return" instruction of DDD is its halt state.

=== *Here is the last actual sticking point*
Computable functions are the formalized analogue of the intuitive
notion of algorithms, in the sense that a function is computable
if there exists an algorithm that can do the job of the function, i.e.
given an input of the function domain it can return the corresponding
output. https://en.wikipedia.org/wiki/Computable_function

A halt decider computes the mapping from an input finite string
to the behavior that this finite string specifies. No halt decider
ever reports on the actual behavior of the computation that itself
is contained within. This has been a very persistent false assumption.

For the three years that my work has been extensively reviewed
this has been the most difficult point for people to understand.

Everyone remains convinced that HHH must report on the behavior
of the computation that itself is contained within and not the
behavior that its finite string input specifies.



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


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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Tue, 06 Aug 2024 09:43:30 -0500 schrieb olcott:

Understanding that DDD correctly simulated by HHH cannot possibly reach
its own "return" instruction is a mandatory prerequisite to further discussion.

There is nothing to discuss after agreeing with your conclusion.

Everyone remains convinced that HHH must report on the behavior of the computation that itself is contained within and not the behavior that
its finite string input specifies.

The construction is not recursive if the description does not describe
the surrounding computation. And that behaviour cannot depend on the
decider, as they should all give the same answer.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/6/2024 12:02 PM, joes wrote:

Am Tue, 06 Aug 2024 09:43:30 -0500 schrieb olcott:

Understanding that DDD correctly simulated by HHH cannot possibly reach
its own "return" instruction is a mandatory prerequisite to further
discussion.

There is nothing to discuss after agreeing with your conclusion.

Everyone remains convinced that HHH must report on the behavior of the
computation that itself is contained within and not the behavior that
its finite string input specifies.

The construction is not recursive if the description does not describe
the surrounding computation. And that behaviour cannot depend on the
decider, as they should all give the same answer.

That is far too vague.

DDD correctly emulated by HHH according to the semantics
of the x86 programming language specifies a single exact
sequence of state changes. None of these state changes
ends up at the x86 machine language address of the "ret"
instruction of DDD.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/6/24 1:16 PM, olcott wrote:

On 8/6/2024 12:02 PM, joes wrote:

Am Tue, 06 Aug 2024 09:43:30 -0500 schrieb olcott:

Understanding that DDD correctly simulated by HHH cannot possibly reach
its own "return" instruction is a mandatory prerequisite to further
discussion.

There is nothing to discuss after agreeing with your conclusion.

Everyone remains convinced that HHH must report on the behavior of the
computation that itself is contained within and not the behavior that
its finite string input specifies.

The construction is not recursive if the description does not describe
the surrounding computation. And that behaviour cannot depend on the
decider, as they should all give the same answer.

That is far too vague.

DDD correctly emulated by HHH according to the semantics
of the x86 programming language specifies a single exact
sequence of state changes. None of these state changes
ends up at the x86 machine language address of the "ret"
instruction of DDD.

Which would be meaningful if HHH actual did a correct emulation of the
PROGRAM DDD that it is given. SInce it doesn't actual do that, despite
your attempts to lie about it, your claim doesn't matter.

Since HHH does actual emulate the instructions of HHH when DDD calls it
(or you haven't shown any evidence that it does, just that x86UTM does
when it runs HHH) and that it fails to be correct by aborting its
emulation of DDD, means your arguement is just BOGUS.

YOu are just proving you don't actually understand how the x86 processor
works, and thus how the language that describes it works.

The trace of the emulation of a call to HHH produce the METHOD that
generates the result of HHH, not the results of HHH.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/6/2024 8:38 PM, Richard Damon wrote:

On 8/6/24 1:16 PM, olcott wrote:

On 8/6/2024 12:02 PM, joes wrote:

Am Tue, 06 Aug 2024 09:43:30 -0500 schrieb olcott:

Understanding that DDD correctly simulated by HHH cannot possibly reach >>>> its own "return" instruction is a mandatory prerequisite to further
discussion.

There is nothing to discuss after agreeing with your conclusion.

Everyone remains convinced that HHH must report on the behavior of the >>>> computation that itself is contained within and not the behavior that
its finite string input specifies.

The construction is not recursive if the description does not describe
the surrounding computation. And that behaviour cannot depend on the
decider, as they should all give the same answer.

That is far too vague.

DDD correctly emulated by HHH according to the semantics
of the x86 programming language specifies a single exact
sequence of state changes. None of these state changes
ends up at the x86 machine language address of the "ret"
instruction of DDD.

Which would be meaningful if HHH actual did a correct emulation of the

HHH does emulate the exact sequence that the machine code
of DDD specifies. This has been conclusively proven by
the execution traces that the two instances of HHH provide.

Since everyone here besides me doesn't know Jack shit about
the x86 language they think that they can get away with a
fake rebuttal based on pure bluster. Even Mike is trying to
get away with this crap now. I thought that I could trust him.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/6/24 10:43 AM, olcott wrote:

void DDD()
{
  HHH(DDD);
  return;
}

int main()
{
  HHH(DDD);
}

Understanding that DDD correctly simulated by HHH cannot
possibly reach its own "return" instruction is a mandatory
prerequisite to further discussion.

BUt ONLY the DDD that calls the HHH that ACTUALLY correct simulates it
input, and thus never aborts.

I can't imagine that anyone having sufficient understanding
of C would not agree that DDD correctly simulated by HHH
cannot possibly reach its own "return" instruction. Several
C experts already agreed to this two of them having masters
in computer science: MSCS.

But ONLY for the HHH that ACTUALLY correctly simulates its input, and
thus does not abort it.

People are either disagreeing for trollish pleasure or have
woefully insufficient expertise in the C programming language.
*Either one of these is a deal killer*

No, just pointing out that you are then trying to CHANGE you HHH to
break your own definition of what HHH is.

Once they understand this we need to add one more point
that the "return" instruction of DDD is its halt state.

=== *Here is the last actual sticking point*
Computable functions are the formalized analogue of the intuitive
notion of algorithms, in the sense that a function is computable
if there exists an algorithm that can do the job of the function, i.e.
given an input of the function domain it can return the corresponding
output. https://en.wikipedia.org/wiki/Computable_function

A halt decider computes the mapping from an input finite string
to the behavior that this finite string specifies. No halt decider
ever reports on the actual behavior of the computation that itself
is contained within. This has been a very persistent false assumption.

Right, they compute the answer of what the input actually maps to.

For "Halting" that is does the behavior of the ACTUAL PROGRAM
represented by the input reach its final state.

For the three years that my work has been extensively reviewed
this has been the most difficult point for people to understand.

Because you insist that an INCORECT (because it is partial) simulation
of the input defines what the program does

Everyone remains convinced that HHH must report on the behavior
of the computation that itself is contained within and not the
behavior that its finite string input specifies.

Because that *IS* what its input ask it.

Why shouldn't it answer about what it is asked?

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

But the input DDD includes the HHH that it calls, or it isn't a full description of the program DDD. (As you say, you can't ask about "the
simulator deciding you" only about a specific decider, which might be
the one you are given to).

SInce that HHH DOES ABORT, as at the end you claim that is what it
"correctly" does, then the claim of the repeatitive loop is just
incorret, as there *IS* a condition in the loop, within the HHH that DDD
calls. HHH needs to take that into account, which it does not, and thus
does not CORRECTLY emulate the behavior of DDD>

Rmember, *ONE* mistake, no matter how small, make the anwer incorret,
and thus HHH isn't if fails to exactly reproduce the actual behavior of
the input, be it by not actually emulating the code of HHH when DDD
calls it, or by stopping its emulation, when the behavior of the
instruction says that execution continues, has made a mistake, and thus
has given an incorrect answer.

THe fact that the direct exection of DDD calling this HHH, or the actual complete emulation of this DDD calling THIS HHH by an emulator that
doesn't give ups shows that DDD calls HHH that will eventually give up
and return, shows that DDD *IS* a Halting Computation and thus HHH is
wrong, and you are nothing but a pathetic ignorant pathological lying
idiot with a reckless disregard for the truth because you just ignore
that fact.

Sorry, but you have just killed your reputation by your self imposed
stupidity.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/6/24 9:48 PM, olcott wrote:

On 8/6/2024 8:38 PM, Richard Damon wrote:

On 8/6/24 1:16 PM, olcott wrote:

On 8/6/2024 12:02 PM, joes wrote:

Am Tue, 06 Aug 2024 09:43:30 -0500 schrieb olcott:

Understanding that DDD correctly simulated by HHH cannot possibly
reach
its own "return" instruction is a mandatory prerequisite to further
discussion.

There is nothing to discuss after agreeing with your conclusion.

Everyone remains convinced that HHH must report on the behavior of the >>>>> computation that itself is contained within and not the behavior that >>>>> its finite string input specifies.

The construction is not recursive if the description does not describe >>>> the surrounding computation. And that behaviour cannot depend on the
decider, as they should all give the same answer.

That is far too vague.

DDD correctly emulated by HHH according to the semantics
of the x86 programming language specifies a single exact
sequence of state changes. None of these state changes
ends up at the x86 machine language address of the "ret"
instruction of DDD.

Which would be meaningful if HHH actual did a correct emulation of the

HHH does emulate the exact sequence that the machine code
of DDD specifies. This has been conclusively proven by
the execution traces that the two instances of HHH provide.

Nope, because it didn't emulate the call instruction properly.

YOu are just proving your ignorance of what you talk about.

You don't even seem to understand what the program DDD is.

Since everyone here besides me doesn't know Jack shit about
the x86 language they think that they can get away with a
fake rebuttal based on pure bluster. Even Mike is trying to
get away with this crap now. I thought that I could trust him.

Nope, YOU don't seem to know jack shit about it since you don't
understand that by that definition, the ONLY possible emulation of the
call HHH is to show, and ONLY SHOW, after the call HHH would be the instructions of HHH.

Since you don't, you are just demonstrating that you are nothing but a
stupid liar.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/6/2024 9:27 PM, Richard Damon wrote:

On 8/6/24 9:48 PM, olcott wrote:

On 8/6/2024 8:38 PM, Richard Damon wrote:

On 8/6/24 1:16 PM, olcott wrote:

On 8/6/2024 12:02 PM, joes wrote:

Am Tue, 06 Aug 2024 09:43:30 -0500 schrieb olcott:

Understanding that DDD correctly simulated by HHH cannot possibly
reach
its own "return" instruction is a mandatory prerequisite to further >>>>>> discussion.

There is nothing to discuss after agreeing with your conclusion.

Everyone remains convinced that HHH must report on the behavior of >>>>>> the
computation that itself is contained within and not the behavior that >>>>>> its finite string input specifies.

The construction is not recursive if the description does not describe >>>>> the surrounding computation. And that behaviour cannot depend on the >>>>> decider, as they should all give the same answer.

That is far too vague.

DDD correctly emulated by HHH according to the semantics
of the x86 programming language specifies a single exact
sequence of state changes. None of these state changes
ends up at the x86 machine language address of the "ret"
instruction of DDD.

Which would be meaningful if HHH actual did a correct emulation of the

HHH does emulate the exact sequence that the machine code
of DDD specifies. This has been conclusively proven by
the execution traces that the two instances of HHH provide.

Nope, because it didn't emulate the call instruction properly.

It is proved that it does emulate the call instruction
properly by the correct execution trace of the second
DDD derived by the second HHH.

*This has been proven this way for three freaking years*


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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/6/2024 9:27 PM, Richard Damon wrote:

On 8/6/24 9:48 PM, olcott wrote:

On 8/6/2024 8:38 PM, Richard Damon wrote:

On 8/6/24 1:16 PM, olcott wrote:

On 8/6/2024 12:02 PM, joes wrote:

Am Tue, 06 Aug 2024 09:43:30 -0500 schrieb olcott:

Understanding that DDD correctly simulated by HHH cannot possibly
reach
its own "return" instruction is a mandatory prerequisite to further >>>>>> discussion.

There is nothing to discuss after agreeing with your conclusion.

Everyone remains convinced that HHH must report on the behavior of >>>>>> the
computation that itself is contained within and not the behavior that >>>>>> its finite string input specifies.

The construction is not recursive if the description does not describe >>>>> the surrounding computation. And that behaviour cannot depend on the >>>>> decider, as they should all give the same answer.

That is far too vague.

DDD correctly emulated by HHH according to the semantics
of the x86 programming language specifies a single exact
sequence of state changes. None of these state changes
ends up at the x86 machine language address of the "ret"
instruction of DDD.

Which would be meaningful if HHH actual did a correct emulation of the

HHH does emulate the exact sequence that the machine code
of DDD specifies. This has been conclusively proven by
the execution traces that the two instances of HHH provide.

Nope, because it didn't emulate the call instruction properly.

YOu are just proving your ignorance of what you talk about.

You don't even seem to understand what the program DDD is.

Since everyone here besides me doesn't know Jack shit about
the x86 language they think that they can get away with a
fake rebuttal based on pure bluster. Even Mike is trying to
get away with this crap now. I thought that I could trust him.

Nope, YOU don't seem to know jack shit about it since you don't
understand that by that definition, the ONLY possible emulation of the
call HHH is to show, and ONLY SHOW, after the call HHH would be the instructions of HHH.

It is proved that it does emulate the call instruction
properly by the correct execution trace of the second
DDD derived by the second HHH.

*This has been proven this way for three freaking years*

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/6/24 10:41 PM, olcott wrote:

On 8/6/2024 9:27 PM, Richard Damon wrote:

On 8/6/24 9:48 PM, olcott wrote:

On 8/6/2024 8:38 PM, Richard Damon wrote:

On 8/6/24 1:16 PM, olcott wrote:

On 8/6/2024 12:02 PM, joes wrote:

Am Tue, 06 Aug 2024 09:43:30 -0500 schrieb olcott:

Understanding that DDD correctly simulated by HHH cannot possibly >>>>>>> reach
its own "return" instruction is a mandatory prerequisite to further >>>>>>> discussion.

There is nothing to discuss after agreeing with your conclusion.

Everyone remains convinced that HHH must report on the behavior
of the
computation that itself is contained within and not the behavior >>>>>>> that
its finite string input specifies.

The construction is not recursive if the description does not
describe
the surrounding computation. And that behaviour cannot depend on the >>>>>> decider, as they should all give the same answer.

That is far too vague.

DDD correctly emulated by HHH according to the semantics
of the x86 programming language specifies a single exact
sequence of state changes. None of these state changes
ends up at the x86 machine language address of the "ret"
instruction of DDD.

Which would be meaningful if HHH actual did a correct emulation of the

HHH does emulate the exact sequence that the machine code
of DDD specifies. This has been conclusively proven by
the execution traces that the two instances of HHH provide.

Nope, because it didn't emulate the call instruction properly.

It is proved that it does emulate the call instruction
properly by the correct execution trace of the second
DDD derived by the second HHH.

Nope, you just don't know what a correct emulation means.

Sorry Charlie, Truth only want ACTUAL truth, not made up statements.

*This has been proven this way for three freaking years*

Nope, you have LIED in your claim about it for three years.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-08-06 14:43:30 +0000, olcott said:

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

The date on that page says "April 2023". After that date many defects have
been identified.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 06.aug.2024 om 16:43 schreef olcott:

void DDD()
{
  HHH(DDD);
  return;
}

int main()
{
  HHH(DDD);
}

Understanding that DDD correctly simulated by HHH cannot
possibly reach its own "return" instruction is a mandatory
prerequisite to further discussion.

A correct understanding that HHH cannot possibly simulate itself
correctly is therefore enough to stop the discussion.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/7/2024 2:36 AM, Mikko wrote:

On 2024-08-06 14:43:30 +0000, olcott said:

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

The date on that page says "April 2023". After that date many defects have been identified.

That is the date that I first submitted it.
I completely rewrote the first half June 2024
and made major modifications yesterday.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/7/2024 3:21 AM, Fred. Zwarts wrote:

Op 06.aug.2024 om 16:43 schreef olcott:

void DDD()
{
   HHH(DDD);
   return;
}

int main()
{
   HHH(DDD);
}

Understanding that DDD correctly simulated by HHH cannot
possibly reach its own "return" instruction is a mandatory
prerequisite to further discussion.

A correct understanding that HHH cannot possibly simulate itself
correctly is therefore enough to stop the discussion.

That you insist and disagreeing with the semantics of the x86
language seems that you really want to avoid any honest dialogue
and only want to play head games.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-08-07 13:04:31 +0000, olcott said:

On 8/7/2024 2:36 AM, Mikko wrote:

On 2024-08-06 14:43:30 +0000, olcott said:

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

The date on that page says "April 2023". After that date many defects have >> been identified.

That is the date that I first submitted it.
I completely rewrote the first half June 2024
and made major modifications yesterday.

The revision dates are not shown. What was the last change?

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 07.aug.2024 om 15:21 schreef olcott:

On 8/7/2024 3:21 AM, Fred. Zwarts wrote:

Op 06.aug.2024 om 16:43 schreef olcott:

void DDD()
{
   HHH(DDD);
   return;
}

int main()
{
   HHH(DDD);
}

Understanding that DDD correctly simulated by HHH cannot
possibly reach its own "return" instruction is a mandatory
prerequisite to further discussion.

A correct understanding that HHH cannot possibly simulate itself
correctly is therefore enough to stop the discussion.

That you insist and disagreeing with the semantics of the x86
language seems that you really want to avoid any honest dialogue
and only want to play head games.

Again, only accusations, no evidence. Is that how you try to get away
with it?
We have clearly proven that HHH deviates from the semantics of the x86
language by skipping the last few instructions of a halting program.
HHH cannot simulate *itself* correctly.

No matter how much olcott wants it to be correct, or how many times
olcott repeats that it is correct, it does not change the fact that such
a simulation is incorrect, because it is unable to reach the end of a
halting program.
Olcott's own claim that the simulated HHH does not reach its end
confirms it. The trace he has shown also proves that HHH cannot reach
the end of its own simulation. So, his own claims prove that it is true
that HHH cannot possibly simulate itself up to the end, which makes the simulation incomplete and, therefore, incorrect.
Dreams are no substitute for logic proofs.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)