On 09/05/2025 17:25, olcott wrote:

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

When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
(final halt state)

You beg the question.

You have not shown that HHH correctly simulates anything.

Mike Terry, on the other hand, has shown that it fails to
correctly simulate DDD.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

On 09/05/2025 17:30, Richard Heathfield wrote:

On 09/05/2025 17:25, olcott wrote:

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

When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own �return statement�.
(final halt state)

You beg the question.

You have not shown that HHH correctly simulates anything.

Mike Terry, on the other hand, has shown that it fails to correctly simulate DDD.

It may correctly /partially/ simulate DDD, in the sense of correctly simulating the sequence of
instructions of DDD until it decides to stop simulating. Well, in practice there is the
complication that PO's code has design bugs meaning that what PO calls a simulation is NOT actually
valid, due to misuse of global variables in his code! To be valid, the sequence of instructions
simulated must match the instructions of the computation being simulated (i.e. match the instruction
sequence of the independently executed computation.

Obviously a partial simulation (even a valid one) not reaching the halt state does not mean that the
computation being simulated never halts.


Mike.

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

On 5/9/25 12:25 PM, olcott wrote:

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

When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
(final halt state)

But that input can not be correctly emulated, as it doesn't contain the
code for HHH.

Sorru, you are just proving your stupidity.


Which FACT are you disagreeing with?

1) You stipuatle that the input is exact the code of the "C function"
DDD, and nothing else.

2) That you stipulate that the function HHH needs to be a pure function,
and thus only a function of its specific input, and not get information
from other sources.

3) That you stipulate that the emulation is to be according to the x86 language.


If you remove your stipu;ation 1, and the input contains the code of the
HHH that DDD calls, then every DDD / HHH pairing given as the input to something is a different input, and thus the DDD/HHH pair given to your
decider HHH that returns 0 is a different input than the DDD/HHH pair
given to your hypothetical HHH that does the corrert emulation.

If you remove your stipulation 2, then there exist an HHH that uses a
static variable to make the call to HHH(DD) from within DD when emulated
by HHH to just immediately return 0 (as the actual full behavior of HHH
is) and thus your claim is just refute by showing that it is possible.

And if you remove your stipulation 3, you need to explain what you
actualy mean by a "correct emulation" as something that is actually
compatible with what you are claiming.

Of course, if all these stipulation are in place, the NO HHH can correct emulate the input past the call HHH instruction, as the code that must
be emulated is not available to the emulator,

You failure to answer this question the many times it has been posted is
taken a proof that you KNOW you are just a stupid liar, and know you
can't justify your argument, but just keep on repeating it as you think
lying about things is just proper logic.

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

On 5/9/25 12:42 PM, olcott wrote:

On 5/9/2025 11:30 AM, Richard Heathfield wrote:

On 09/05/2025 17:25, olcott wrote:

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

When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
(final halt state)

You beg the question.

You have not shown that HHH correctly simulates anything.

Like I said any competent C programmer can see that
when DDD is correctly simulated by any HHH that DDD
cannot possibly reach its own "return statement".

No any copetent C program will see that your FUNCTION C doesn't have a
defined behavior until paired with a specific HHH, and if given just the
code of DDD as an input, no pure function emulator can do that emulation.

(And there exists a non-pure function emulator that can emulate the
input to the final state),

This remains true for every case where 1 or more
statements of DDD have been correctly simulated.

Nope. But then it seems you are too stupid to read what people say.

That you are not a competent C programmer is no rebuttal.

That you are so stupid is no excuse either.

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

On 5/9/25 2:17 PM, olcott wrote:

On 5/9/2025 11:49 AM, Mike Terry wrote:

On 09/05/2025 17:30, Richard Heathfield wrote:

On 09/05/2025 17:25, olcott wrote:

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

When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
(final halt state)

You beg the question.

You have not shown that HHH correctly simulates anything.

Mike Terry, on the other hand, has shown that it fails to correctly
simulate DDD.

It may correctly /partially/ simulate DDD, in the sense of correctly
simulating the sequence of instructions of DDD until it decides to
stop simulating.  Well, in practice there is the complication that
PO's code has design bugs meaning that what PO calls a simulation is
NOT actually valid, due to misuse of global variables in his code!  To
be valid, the sequence of instructions simulated must match the
instructions of the computation being simulated (i.e. match the
instruction sequence of the independently executed computation.

Obviously a partial simulation (even a valid one) not reaching the
halt state does not mean that the computation being simulated never
halts.


Mike.

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

When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.

That a correctly simulated input cannot possibly
reach its own simulated final halt state proves
that this simulated input cannot possibly halt.

But pure function HHH can not emulate the instructions of HHH that it
hasn't been given as part of the input.

Thus you have stipulated that your statement is false.

Sorry, but you are just showing you don't understand the requirement to
use consistant, and correct, definitions of terms.

All you are doing is proving that you are just a stupid liar.

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

On 09/05/2025 17:42, olcott wrote:

On 5/9/2025 11:30 AM, Richard Heathfield wrote:

On 09/05/2025 17:25, olcott wrote:

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

When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
(final halt state)

You beg the question.

You have not shown that HHH correctly simulates anything.

Like I said any competent C programmer

We have already established that you are in no position to judge
who is and who is not a competent C programmer.

That you are not a competent C programmer is no rebuttal.

<grin>

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

Op 09.mei.2025 om 18:25 schreef olcott:

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

When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
(final halt state)

A competent programmer understands that when HHH returns after the
'correct' simulation, DDD will reach its final halt state. A 'correct' simulation must take that into account.

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

On 2025-05-09 16:25:12 +0000, olcott said:

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

When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
(final halt state)

That one or more statements of DDD are correctly simulated does not
mean that DDD is correctly simulated.

That one or more cents of a debt is correctly paid does not mean
that the debt is correctly paid.

--
Mikko

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

Op 10.mei.2025 om 17:25 schreef olcott:

On 5/10/2025 2:33 AM, Mikko wrote:

On 2025-05-09 16:25:12 +0000, olcott said:

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

When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
(final halt state)

That one or more statements of DDD are correctly simulated does not
mean that DDD is correctly simulated.

It is stipulated that when one or more statements
of DDD are correctly simulated that one or more
statements of DDD are correctly simulated.

It is ridiculously stupid to require a simulating
termination analyzer to continue to simulate a non
terminating input.

1) In other words: When the computation of a value diverges, we can not
require that it continues, so a wild guess must be correct.
2) If the analyser would continue, it would see that it is a terminating
input. The input specifies a buggy halting program, but the buggy
simulator does not see the behaviour specified in the input.

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

On 5/10/25 11:25 AM, olcott wrote:

On 5/10/2025 2:33 AM, Mikko wrote:

On 2025-05-09 16:25:12 +0000, olcott said:

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

When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
(final halt state)

That one or more statements of DDD are correctly simulated does not
mean that DDD is correctly simulated.

It is stipulated that when one or more statements
of DDD are correctly simulated that one or more
statements of DDD are correctly simulated.

And it is

It is ridiculously stupid to require a simulating
termination analyzer to continue to simulate a non
terminating input.

Maybe to you, but that *IS* the definition, After all, the definition of
a correcxt emulation is to EXACTLY reproduce the behavior of the input,
and if that would never stop, the emulation must never stop.

That one or more cents of a debt is correctly paid does not mean
that the debt is correctly paid.

My point is that there are no conditions where
DDD could be correctly simulated by HHH such that
DDD reaches its own "return" statement.

But only because no HHH can exist that can do the correct emulation of
your stipulated input.

And when you add in the code of HHH, so it can be emulated, the only HHH
that does the correct eumulation, is given the version DDD that uses it,
and that will be non-hating, but every other HHH was given a DIFFERENT
DDD, paired with itself, which is different that the one that never
aborts, and thus can have different behavior.

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
    If simulating halt decider H correctly simulates its
    input D until H correctly determines that its simulated D
    *would never stop running unless aborted* then

Simulating termination analyzers continue to simulate
until D simulated by hypothetical H (that does not abort)
*would never stop running unless aborted*

Until ORIGINAL D simulate by hypothetical H, would have the hypothetical
H see D use the ORIGINAL H emulating the ORIGINAL D for a bit, then
abort its emulation (since that is what it does) and then return to D
and then D will halt.

Your problem is you LIE and change the code of D.

Of course, you forced yourself to lie, becuase you system just can't
create the test case because it stipulates what H is so it can't be changed.

That is like stipulating x to be 1, and then asking what happens if x is
0, and using properties based on the stipulation.

You are just proving you are just a pathological liar that just doens't understand how truth works.

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

On 2025-05-10 15:25:16 +0000, olcott said:

On 5/10/2025 2:33 AM, Mikko wrote:

On 2025-05-09 16:25:12 +0000, olcott said:

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

When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
(final halt state)

That one or more statements of DDD are correctly simulated does not
mean that DDD is correctly simulated.

It is stipulated that when one or more statements
of DDD are correctly simulated that one or more
statements of DDD are correctly simulated.

Thera are only two statements in DDD. HHH does not correctly emulate
the first one, which is a call to HHH, and not at all the second one,
which is the final return.

--
Mikko

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

On 5/11/25 12:26 PM, olcott wrote:

On 5/11/2025 4:25 AM, Mikko wrote:

On 2025-05-10 15:25:16 +0000, olcott said:

On 5/10/2025 2:33 AM, Mikko wrote:

On 2025-05-09 16:25:12 +0000, olcott said:

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

When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
(final halt state)

That one or more statements of DDD are correctly simulated does not
mean that DDD is correctly simulated.

It is stipulated that when one or more statements
of DDD are correctly simulated that one or more
statements of DDD are correctly simulated.

Thera are only two statements in DDD. HHH does not correctly emulate
the first one, which is a call to HHH, and not at all the second one,
which is the final return.

_DDD()
[0000219e] 55             push ebp
[0000219f] 8bec           mov ebp,esp
[000021a1] 689e210000     push 0000219e // push DDD
[000021a6] e843f4ffff     call 000015ee // call HHH
[000021ab] 83c404         add esp,+04
[000021ae] 5d             pop ebp
[000021af] c3             ret
Size in bytes:(0018) [000021af]

There are seven instructions in DDD.
When DDD calls HHH(DDD) then HHH emulates
itself emulating DDD.

Then either HHH is just wrong, violating the definition of the input, or
isn't a pure function, and thus can use my static hack to correct
emulate the input to the final state.

Sorry, you are just showing that you are lying by equivocation.

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

On 5/11/25 5:42 PM, olcott wrote:

On 5/11/2025 3:15 PM, Richard Damon wrote:

On 5/11/25 12:26 PM, olcott wrote:

On 5/11/2025 4:25 AM, Mikko wrote:

On 2025-05-10 15:25:16 +0000, olcott said:

On 5/10/2025 2:33 AM, Mikko wrote:

On 2025-05-09 16:25:12 +0000, olcott said:

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

When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
(final halt state)

That one or more statements of DDD are correctly simulated does not >>>>>> mean that DDD is correctly simulated.

It is stipulated that when one or more statements
of DDD are correctly simulated that one or more
statements of DDD are correctly simulated.

Thera are only two statements in DDD. HHH does not correctly emulate
the first one, which is a call to HHH, and not at all the second one,
which is the final return.

_DDD()
[0000219e] 55             push ebp
[0000219f] 8bec           mov ebp,esp
[000021a1] 689e210000     push 0000219e // push DDD
[000021a6] e843f4ffff     call 000015ee // call HHH
[000021ab] 83c404         add esp,+04
[000021ae] 5d             pop ebp
[000021af] c3             ret
Size in bytes:(0018) [000021af]

There are seven instructions in DDD.
When DDD calls HHH(DDD) then HHH emulates
itself emulating DDD.

Then either HHH is just wrong,

DDD is emulated by HHH according to the only correct
measure the rules of the x86 language.

No it isn't, as your HHH aborts its simulation, and that isn't allowed
by the x86 lannguage.

And it can only do even that if you include HHH in the input, or allow
HHH to be a non-pure function.

violating the definition of the input, or

I told you far too many times that HHH and DDD
are in the same memory space. This means that
HHH must emulate itself emulating DDD or it
did not emulate the first 7 instructions of DDD
correctly.

Which is IRRELVENT if HHH is a pure function, I guess you just don't
understand the meaning of the term you yourself used in your stipulation.

So which lie are you admitting to? (Failure to answer will be presumed
to mean ALL of them)?

That the input actually contains the code for HHH, and thus each DDD/HHH pairing is a distinct input, as the code for each HHH is different.

That your HHH isn't a pure funciton, as it looks at data memory that
wasn't part of its input (or generated from it) and thus my local static variable hack is also allowed, and thus you are just shown to be a
stupid liar about no HHH can do it, when I show how to build an HHH that
can do it. (Your comments about needing a better criteria doesn't help
until you DO come up with something)

That you are just lying about HHH being a correct emulator, and it sees
a call to HHH, and INCORRECTLY assumes that HHH is a correct emulator as claimed when it actually is not (since it does abort), thus showing that
you lie in your stipulations.

isn't a pure function, and thus can use my static hack to correct
emulate the input to the final state.

Refusing to emulate DDD after one emulation
cannot possibly derive a simulating termination
analyzer, thus this break requirements.

Where?

The requirement to correctly emulate was the requirement on the outer
HHH, which it doesn't acutally do.

The queation is can we make a HHH that emulates in input, HHH does that.

This is no different than your false assertion that the outer HHH can
abort while the inner one will not abort.

Sorry, you are just showing that you are lying by equivocation.

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

On 5/12/25 11:07 AM, olcott wrote:

On 5/12/2025 3:04 AM, Mikko wrote:

On 2025-05-11 16:26:44 +0000, olcott said:

On 5/11/2025 4:25 AM, Mikko wrote:

On 2025-05-10 15:25:16 +0000, olcott said:

On 5/10/2025 2:33 AM, Mikko wrote:

On 2025-05-09 16:25:12 +0000, olcott said:

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

When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.
(final halt state)

That one or more statements of DDD are correctly simulated does not >>>>>> mean that DDD is correctly simulated.

It is stipulated that when one or more statements
of DDD are correctly simulated that one or more
statements of DDD are correctly simulated.

Thera are only two statements in DDD. HHH does not correctly emulate
the first one, which is a call to HHH, and not at all the second one,
which is the final return.

_DDD()
[0000219e] 55             push ebp
[0000219f] 8bec           mov ebp,esp
[000021a1] 689e210000     push 0000219e // push DDD
[000021a6] e843f4ffff     call 000015ee // call HHH
[000021ab] 83c404         add esp,+04
[000021ae] 5d             pop ebp
[000021af] c3             ret
Size in bytes:(0018) [000021af]

There are seven instructions in DDD.
When DDD calls HHH(DDD) then HHH emulates
itself emulating DDD.

No, there are seven instructions in a particular translation of DDD.

Not at all. The above sequence of machine code bytes
is named DDD. Every other string of bytes is off topic.
The x86 machine code is the final form.

And the above string of bytes are NOT a program, and can NOT be
correctly emulated by a pure emulator past the call instruction.

Sorry, but you just are showing that you don't care about truth, but
just want to repeat your lies.

But that is irrelevant. My comment was to a message that did not use
the word "instruction" at all.

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