On 3/22/25 1:31 PM, olcott wrote:

On 3/22/2025 11:37 AM, joes wrote:

Am Sat, 22 Mar 2025 08:43:03 -0500 schrieb olcott:

typedef void (*ptr)();
int HHH(ptr P);
int main()
{
    HHH(Infinite_Recursion);
}
There is no program DDD in the above code.

There is also no Infinite_Recursion.

Since no Turing machine M can ever compute the mapping from the behavior >>> of any directly executed TM2 referring to the behavior of the directly
executed DDD has always been incorrect. Halt Deciders always report on
the behavior that their input finite string specifies.

Please explain what behaviour the description of a TM "specifies",
and which TM the input describes.

"Bill sang a song" describes what Bill did.
A tape recording of Bill singing that same
song completely specifies what Bill did.

And what a UTM does with this input completely specifies its behavior,

In every case that does not involve pathological self-reference the
behavior that the finite string specifies is coincidentally the same
behavior as the direct execution of the corresponding machine. The
actual measure, however, has always been the behavior that the finite
string input specifies.

...which is the direct execution. Not much of a coincidence.

_III()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push III
[0000217a] e853f4ffff call 000015d2 ; call EEE(III)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

When-so-ever any correct emulator EEE correctly emulates
a finite number of steps of an input III that calls this
same emulator to emulate itself the behavior of the direct
execution of III will not be the same as the behavior of
the emulated III.

Becuase a finite emulation that stop before the end is not a correct
emulation of the thing, but just the first part of that emulation.

THus, we see that just because a partial emulation doesn't reach the
final state, we can not say that the COMPLETE and correct emulation of
that exact same input doesn't halt.

Note. the input III must include the exact version of EEE that it is
calling, and the complete emulation will be of III calling THAT EEE,
since that is what the input was.

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

On 3/22/25 2:08 PM, olcott wrote:

On 3/22/2025 12:38 PM, Richard Damon wrote:

On 3/22/25 1:31 PM, olcott wrote:

On 3/22/2025 11:37 AM, joes wrote:

Am Sat, 22 Mar 2025 08:43:03 -0500 schrieb olcott:

typedef void (*ptr)();
int HHH(ptr P);
int main()
{
    HHH(Infinite_Recursion);
}
There is no program DDD in the above code.

There is also no Infinite_Recursion.

Since no Turing machine M can ever compute the mapping from the
behavior
of any directly executed TM2 referring to the behavior of the directly >>>>> executed DDD has always been incorrect. Halt Deciders always report on >>>>> the behavior that their input finite string specifies.

Please explain what behaviour the description of a TM "specifies",
and which TM the input describes.

"Bill sang a song" describes what Bill did.
A tape recording of Bill singing that same
song completely specifies what Bill did.

And what a UTM does with this input completely specifies its behavior,

In every case that does not involve pathological self-reference the
behavior that the finite string specifies is coincidentally the same >>>>> behavior as the direct execution of the corresponding machine. The
actual measure, however, has always been the behavior that the finite >>>>> string input specifies.

...which is the direct execution. Not much of a coincidence.

_III()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push III
[0000217a] e853f4ffff call 000015d2 ; call EEE(III)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

When-so-ever any correct emulator EEE correctly emulates
a finite number of steps of an input III that calls this
same emulator to emulate itself the behavior of the direct
execution of III will not be the same as the behavior of
the emulated III.

Becuase a finite emulation that stop before the end is not a correct
emulation

In other words you keep dishonestly trying to get away with
disagreeing with the law of identity.

When N steps are III are correctly emulated by EEE
then N steps are III are correctly emulated by EEE.

Which isn't the same as the CORRECT emulation that shows if the program
being emulated will halt/.

There exists no Natural Number N number of steps of III
correctly emulated by EEE where III reaches its
own "ret" instruction and terminates normally.

Because each emulation is of a DIFFERENT PROGRAM, and thus the results
of one can't be apppled to the other.

Sorry, you are just proving you don't know what the words actually mean.

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

On 2025-03-22 17:31:48 +0000, olcott said:

On 3/22/2025 11:37 AM, joes wrote:

Am Sat, 22 Mar 2025 08:43:03 -0500 schrieb olcott:

typedef void (*ptr)();
int HHH(ptr P);
int main()
{
HHH(Infinite_Recursion);
}
There is no program DDD in the above code.

There is also no Infinite_Recursion.

Since no Turing machine M can ever compute the mapping from the behavior >>> of any directly executed TM2 referring to the behavior of the directly
executed DDD has always been incorrect. Halt Deciders always report on
the behavior that their input finite string specifies.

Please explain what behaviour the description of a TM "specifies",
and which TM the input describes.

"Bill sang a song" describes what Bill did.
A tape recording of Bill singing that same
song completely specifies what Bill did.

In every case that does not involve pathological self-reference the
behavior that the finite string specifies is coincidentally the same
behavior as the direct execution of the corresponding machine. The
actual measure, however, has always been the behavior that the finite
string input specifies.

...which is the direct execution. Not much of a coincidence.

_III()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push III
[0000217a] e853f4ffff call 000015d2 ; call EEE(III)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]

When-so-ever any correct emulator EEE correctly emulates
a finite number of steps of an input III that calls this
same emulator to emulate itself the behavior of the direct
execution of III will not be the same as the behavior of
the emulated III.

I would implement EEE so that it skips some (hopefully unimportant) details
of the behaviour of III (or whatever input is given) and emulates the rest
of the behaviour.

--
Mikko

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

On 2025-03-22 18:08:07 +0000, olcott said:

On 3/22/2025 12:38 PM, Richard Damon wrote:

On 3/22/25 1:31 PM, olcott wrote:

On 3/22/2025 11:37 AM, joes wrote:

Am Sat, 22 Mar 2025 08:43:03 -0500 schrieb olcott:

typedef void (*ptr)();
int HHH(ptr P);
int main()
{
    HHH(Infinite_Recursion);
}
There is no program DDD in the above code.

There is also no Infinite_Recursion.

Since no Turing machine M can ever compute the mapping from the behavior >>>>> of any directly executed TM2 referring to the behavior of the directly >>>>> executed DDD has always been incorrect. Halt Deciders always report on >>>>> the behavior that their input finite string specifies.

Please explain what behaviour the description of a TM "specifies",
and which TM the input describes.

"Bill sang a song" describes what Bill did.
A tape recording of Bill singing that same
song completely specifies what Bill did.

And what a UTM does with this input completely specifies its behavior,

In every case that does not involve pathological self-reference the
behavior that the finite string specifies is coincidentally the same >>>>> behavior as the direct execution of the corresponding machine. The
actual measure, however, has always been the behavior that the finite >>>>> string input specifies.

...which is the direct execution. Not much of a coincidence.

_III()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push III
[0000217a] e853f4ffff call 000015d2 ; call EEE(III)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

When-so-ever any correct emulator EEE correctly emulates
a finite number of steps of an input III that calls this
same emulator to emulate itself the behavior of the direct
execution of III will not be the same as the behavior of
the emulated III.

Becuase a finite emulation that stop before the end is not a correct emulation

In other words you keep dishonestly trying to get away with
disagreeing with the law of identity.

It is not a good idea to lie about another person, especially when
the truth can be seen.

--
Mikko

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

On 3/22/25 11:52 PM, olcott wrote:

On 3/22/2025 9:53 PM, Richard Damon wrote:

On 3/22/25 2:08 PM, olcott wrote:

On 3/22/2025 12:38 PM, Richard Damon wrote:

On 3/22/25 1:31 PM, olcott wrote:

On 3/22/2025 11:37 AM, joes wrote:

Am Sat, 22 Mar 2025 08:43:03 -0500 schrieb olcott:

typedef void (*ptr)();
int HHH(ptr P);
int main()
{
    HHH(Infinite_Recursion);
}
There is no program DDD in the above code.

There is also no Infinite_Recursion.

Since no Turing machine M can ever compute the mapping from the
behavior
of any directly executed TM2 referring to the behavior of the
directly
executed DDD has always been incorrect. Halt Deciders always
report on
the behavior that their input finite string specifies.

Please explain what behaviour the description of a TM "specifies", >>>>>> and which TM the input describes.

"Bill sang a song" describes what Bill did.
A tape recording of Bill singing that same
song completely specifies what Bill did.

And what a UTM does with this input completely specifies its behavior, >>>>

In every case that does not involve pathological self-reference the >>>>>>> behavior that the finite string specifies is coincidentally the same >>>>>>> behavior as the direct execution of the corresponding machine. The >>>>>>> actual measure, however, has always been the behavior that the
finite
string input specifies.

...which is the direct execution. Not much of a coincidence.

_III()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push III
[0000217a] e853f4ffff call 000015d2 ; call EEE(III)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

When-so-ever any correct emulator EEE correctly emulates
a finite number of steps of an input III that calls this
same emulator to emulate itself the behavior of the direct
execution of III will not be the same as the behavior of
the emulated III.

Becuase a finite emulation that stop before the end is not a correct
emulation

In other words you keep dishonestly trying to get away with
disagreeing with the law of identity.

When N steps are III are correctly emulated by EEE
then N steps are III are correctly emulated by EEE.

Which isn't the same as the CORRECT emulation that shows if the
program being emulated will halt/.

There exists no Natural Number N number of steps of III
correctly emulated by EEE where III reaches its
own "ret" instruction and terminates normally.

Because

In other words you agree that the recursive emulation
of a single finite string of x86 machine code single
machine address [00002172] cannot possibly reach its
own machine address [00002183]when emulated by emulator
EEE according to the semantics of the x86 language.

But it isn't a single finite string of x86 machince code, as to emulate
it we need to include the machine code of EEE, which you just said froms
an infinite set of partial emulators.

That is your fundamental problem, that you need to redefine the meaning
of core terms to try to "establish" your facts, and thus you don't
establish them in the logic system you claim to be talking about (the
one that Turing made his claim in)

Sorry, your statements are just self-contradictory, and you are proven
to be ignoran.

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

On 3/23/25 1:21 PM, olcott wrote:

On 3/23/2025 6:07 AM, Richard Damon wrote:

On 3/22/25 11:52 PM, olcott wrote:

On 3/22/2025 9:53 PM, Richard Damon wrote:

On 3/22/25 2:08 PM, olcott wrote:

On 3/22/2025 12:38 PM, Richard Damon wrote:

On 3/22/25 1:31 PM, olcott wrote:

On 3/22/2025 11:37 AM, joes wrote:

Am Sat, 22 Mar 2025 08:43:03 -0500 schrieb olcott:

typedef void (*ptr)();
int HHH(ptr P);
int main()
{
    HHH(Infinite_Recursion);
}
There is no program DDD in the above code.

There is also no Infinite_Recursion.

Since no Turing machine M can ever compute the mapping from the >>>>>>>>> behavior
of any directly executed TM2 referring to the behavior of the >>>>>>>>> directly
executed DDD has always been incorrect. Halt Deciders always >>>>>>>>> report on
the behavior that their input finite string specifies.

Please explain what behaviour the description of a TM "specifies", >>>>>>>> and which TM the input describes.

"Bill sang a song" describes what Bill did.
A tape recording of Bill singing that same
song completely specifies what Bill did.

And what a UTM does with this input completely specifies its
behavior,

In every case that does not involve pathological self-reference >>>>>>>>> the
behavior that the finite string specifies is coincidentally the >>>>>>>>> same
behavior as the direct execution of the corresponding machine. The >>>>>>>>> actual measure, however, has always been the behavior that the >>>>>>>>> finite
string input specifies.

...which is the direct execution. Not much of a coincidence.

_III()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push III
[0000217a] e853f4ffff call 000015d2 ; call EEE(III)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

When-so-ever any correct emulator EEE correctly emulates
a finite number of steps of an input III that calls this
same emulator to emulate itself the behavior of the direct
execution of III will not be the same as the behavior of
the emulated III.

Becuase a finite emulation that stop before the end is not a
correct emulation

In other words you keep dishonestly trying to get away with
disagreeing with the law of identity.

When N steps are III are correctly emulated by EEE
then N steps are III are correctly emulated by EEE.

Which isn't the same as the CORRECT emulation that shows if the
program being emulated will halt/.

There exists no Natural Number N number of steps of III
correctly emulated by EEE where III reaches its
own "ret" instruction and terminates normally.

Because

In other words you agree that the recursive emulation
of a single finite string of x86 machine code single
machine address [00002172] cannot possibly reach its
own machine address [00002183]when emulated by emulator
EEE according to the semantics of the x86 language.

But it isn't a single finite string of x86 machince code,

As a matter of verified fact it is a single finite
string of machine code at a fixed offset in the
Halt7.obj file.

Nope, because DEFINTIONALLY, to correctly emulate it, you need ALL of it
(at least all seen by the emulator) and thus you can't change the parts
seen and still be talking about the same input.

Your claim just shows you are a patholgical liar.

You can not "correctly emulate" the code of just the function, you need
the rest of the code, which mean you can't do the variations you talk about.

That is basic to the definitions of the items in the problem.

Of course, in your FRAUD, you just ignore those definitions, but then
you can say you results apply to the Halting Problem, as that wasn't
defined in your system, but the classical one.

as to emulate it we need to include the machine code of EEE,

Which would also be a single finite string of machine code
at a fixed offset in the Halt7.obj file if it was not an
infinite set of hypothetical pure x86 emulators.

But the single finite string that didn't change, when you create that
set of DIFFERENT EEEs, isn't a complete program, and you couldn't
emulate your string by the rules of the x86 language past the call EEE instruction.

Your problem is either the code of EEE is in the input, and thus can't
be changed or you need to admit that every emulation is of a different
input, or you need to exclude the code of EEE, and then you can't
emulate the input without looking at things not defined by it.

which you just said froms an infinite set of partial emulators.

That is your fundamental problem, that you need to redefine the
meaning of core terms

A freaking set of pure x86 emulators EEE[0] to EEE[N] that
emulates 0 to N instructions of III IS NOT REDEFINING ANY
TERMS.

How do they emulate the input for any N > 4, and be a proper program
that only uses its input, when the input doesn't contain the instruction
that it needs to emulate?

You are just proving you don't understand what a PROGRAM is, and that
your argument is based on the FRAUD of using an incorrect definition for it.

All you have done is proved that you life has been spent just putting
out many lies about things, lies that apparently you have believed
yourself, since you brainwashed yourself to avoid learning the proper
rules as you brainwashed yourself that the truth would brainwash you.

Sorry, you wasted your life by killing your reputation by giving in the
the power of the lie.

to try to "establish" your facts, and thus you don't establish them in
the logic system you claim to be talking about (the one that Turing
made his claim in)

Sorry, your statements are just self-contradictory, and you are proven
to be ignoran.

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

On 3/23/25 6:47 PM, olcott wrote:

On 3/23/2025 4:46 PM, Richard Damon wrote:

On 3/23/25 1:21 PM, olcott wrote:

On 3/23/2025 6:07 AM, Richard Damon wrote:

On 3/22/25 11:52 PM, olcott wrote:

On 3/22/2025 9:53 PM, Richard Damon wrote:

On 3/22/25 2:08 PM, olcott wrote:

On 3/22/2025 12:38 PM, Richard Damon wrote:

On 3/22/25 1:31 PM, olcott wrote:

On 3/22/2025 11:37 AM, joes wrote:

Am Sat, 22 Mar 2025 08:43:03 -0500 schrieb olcott:

typedef void (*ptr)();
int HHH(ptr P);
int main()
{
    HHH(Infinite_Recursion);
}
There is no program DDD in the above code.

There is also no Infinite_Recursion.

Since no Turing machine M can ever compute the mapping from >>>>>>>>>>> the behavior
of any directly executed TM2 referring to the behavior of the >>>>>>>>>>> directly
executed DDD has always been incorrect. Halt Deciders always >>>>>>>>>>> report on
the behavior that their input finite string specifies.

Please explain what behaviour the description of a TM
"specifies",
and which TM the input describes.

"Bill sang a song" describes what Bill did.
A tape recording of Bill singing that same
song completely specifies what Bill did.

And what a UTM does with this input completely specifies its
behavior,

In every case that does not involve pathological self-
reference the
behavior that the finite string specifies is coincidentally >>>>>>>>>>> the same
behavior as the direct execution of the corresponding
machine. The
actual measure, however, has always been the behavior that >>>>>>>>>>> the finite
string input specifies.

...which is the direct execution. Not much of a coincidence. >>>>>>>>>>

_III()
[00002172] 55         push ebp      ; housekeeping >>>>>>>>> [00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push III
[0000217a] e853f4ffff call 000015d2 ; call EEE(III)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

When-so-ever any correct emulator EEE correctly emulates
a finite number of steps of an input III that calls this
same emulator to emulate itself the behavior of the direct
execution of III will not be the same as the behavior of
the emulated III.

Becuase a finite emulation that stop before the end is not a
correct emulation

In other words you keep dishonestly trying to get away with
disagreeing with the law of identity.

When N steps are III are correctly emulated by EEE
then N steps are III are correctly emulated by EEE.

Which isn't the same as the CORRECT emulation that shows if the
program being emulated will halt/.

There exists no Natural Number N number of steps of III
correctly emulated by EEE where III reaches its
own "ret" instruction and terminates normally.

Because

In other words you agree that the recursive emulation
of a single finite string of x86 machine code single
machine address [00002172] cannot possibly reach its
own machine address [00002183]when emulated by emulator
EEE according to the semantics of the x86 language.

But it isn't a single finite string of x86 machince code,

As a matter of verified fact it is a single finite
string of machine code at a fixed offset in the
Halt7.obj file.

Nope, because DEFINTIONALLY, to correctly emulate it, you need ALL of
it (at least all seen by the emulator) and thus you can't change the
parts seen and still be talking about the same input.

Your claim just shows you are a patholgical liar.

You can not "correctly emulate" the code of just the function, you
need the rest of the code, which mean you can't do the variations you
talk about.

x86utm operates on a compiled object file that
is stored in a single location of global memory.

Right, and thus you must consider *ALL* of that memory as the input, so
if you change it, it is a different input.

That means you are just lying when you say the below is the finite
string input given to EEE, as you just admitted that it uses more.

(It also shows your stupidity to say it stored the entire file in "a
single location of global memory", as a signle location can hold only
one value, even more evidence of you not knowing what you are talking about.

And the use of "global memory" as you have admitted, breaks the
definition of your decider, which you have admitted needs to be a pure function, and thus can't use "global memory".

_III()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push III
[0000217a] e853f4ffff call 000015d2 ; call EEE(III)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

There are no freaking variations merely III repeating
its first four instructions a finite number of times.

Nope. The ONLY correct emulation shows goig from 0000217A with a call to
EEE at 000015d2, and after that the Program Counter for this emulation
will NEVER get back to any of the addresses between 00002172 to 0000217a.

IT is only the variable within EEE that represents the address it is
emulation that goes back there, so your statement is just a lie.

And, since EEE did look at those locations in memory, every EEE got a
DIFFERENT input, as the actual input is much larger than you deceptively
claim, as it DOES contain all the memory locations looked at, which
include the code for EEE, and thus every time you changed EEE, you
canged the ACTUAL finite string that represents the input, and thus you
just LIE when you say they all are the "same" III

Sorry, you are just proving that you are nothing but a pathological liar
that is commiting deliberate FRAUD by trying to redefine the core terms
of the system you are working in.

Try to disprove ANY of these statement, with a quoted reliable source to
back your reasoning.

You are just stuck in your world of make-beleive and you are totally
ignorant of what you are actually talking about in the actual world of
logic.

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

On 3/23/25 9:06 PM, olcott wrote:

On 3/23/2025 6:56 PM, Richard Damon wrote:

On 3/23/25 6:47 PM, olcott wrote:

On 3/23/2025 4:46 PM, Richard Damon wrote:

On 3/23/25 1:21 PM, olcott wrote:

On 3/23/2025 6:07 AM, Richard Damon wrote:

On 3/22/25 11:52 PM, olcott wrote:

On 3/22/2025 9:53 PM, Richard Damon wrote:

On 3/22/25 2:08 PM, olcott wrote:

On 3/22/2025 12:38 PM, Richard Damon wrote:

On 3/22/25 1:31 PM, olcott wrote:

On 3/22/2025 11:37 AM, joes wrote:

Am Sat, 22 Mar 2025 08:43:03 -0500 schrieb olcott:

typedef void (*ptr)();
int HHH(ptr P);
int main()
{
    HHH(Infinite_Recursion);
}
There is no program DDD in the above code.

There is also no Infinite_Recursion.

Since no Turing machine M can ever compute the mapping from >>>>>>>>>>>>> the behavior
of any directly executed TM2 referring to the behavior of >>>>>>>>>>>>> the directly
executed DDD has always been incorrect. Halt Deciders >>>>>>>>>>>>> always report on
the behavior that their input finite string specifies. >>>>>>>>>>>

Please explain what behaviour the description of a TM
"specifies",
and which TM the input describes.

"Bill sang a song" describes what Bill did.
A tape recording of Bill singing that same
song completely specifies what Bill did.

And what a UTM does with this input completely specifies its >>>>>>>>>> behavior,

In every case that does not involve pathological self- >>>>>>>>>>>>> reference the
behavior that the finite string specifies is coincidentally >>>>>>>>>>>>> the same
behavior as the direct execution of the corresponding >>>>>>>>>>>>> machine. The
actual measure, however, has always been the behavior that >>>>>>>>>>>>> the finite
string input specifies.

...which is the direct execution. Not much of a coincidence. >>>>>>>>>>>>

_III()
[00002172] 55         push ebp      ; housekeeping >>>>>>>>>>> [00002173] 8bec       mov  ebp,esp  ; housekeeping >>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push III
[0000217a] e853f4ffff call 000015d2 ; call EEE(III)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

When-so-ever any correct emulator EEE correctly emulates >>>>>>>>>>> a finite number of steps of an input III that calls this >>>>>>>>>>> same emulator to emulate itself the behavior of the direct >>>>>>>>>>> execution of III will not be the same as the behavior of >>>>>>>>>>> the emulated III.

Becuase a finite emulation that stop before the end is not a >>>>>>>>>> correct emulation

In other words you keep dishonestly trying to get away with
disagreeing with the law of identity.

When N steps are III are correctly emulated by EEE
then N steps are III are correctly emulated by EEE.

Which isn't the same as the CORRECT emulation that shows if the >>>>>>>> program being emulated will halt/.

There exists no Natural Number N number of steps of III
correctly emulated by EEE where III reaches its
own "ret" instruction and terminates normally.

Because

In other words you agree that the recursive emulation
of a single finite string of x86 machine code single
machine address [00002172] cannot possibly reach its
own machine address [00002183]when emulated by emulator
EEE according to the semantics of the x86 language.

But it isn't a single finite string of x86 machince code,

As a matter of verified fact it is a single finite
string of machine code at a fixed offset in the
Halt7.obj file.

Nope, because DEFINTIONALLY, to correctly emulate it, you need ALL
of it (at least all seen by the emulator) and thus you can't change
the parts seen and still be talking about the same input.

Your claim just shows you are a patholgical liar.

You can not "correctly emulate" the code of just the function, you
need the rest of the code, which mean you can't do the variations
you talk about.

x86utm operates on a compiled object file that
is stored in a single location of global memory.

Right, and thus you must consider *ALL* of that memory as the input,
so if you change it, it is a different input.

You haven't yet noticed that all posts with this title
[III correctly emulated by EEE] are talking about a pure
emulator that emulates a finite number of instructions of III.

Which is just a strawman, and a contradiction, as the definition of
"correct emulation" (to be able to use it in the halting problem as a
surrogate for the programs behavior) must be complete.

If you want to define a new definition for "Correct Emulation", then all
you do is knownly make it impossible for the Halt Decider to have any
idea of what the input does, as that was DEFINED by the direct
execution, and if correct emulation is no longer defined to be the same,
then it can't be used for the problem.

Thus, you are just proving that you were never working on what you said
you were, but were always lying by the use of a strawman.

You have shown that you don't understand the fundamentals of how logic
works, as you think you get to redefined the basic terms, which you
don't. (You can create a new, and independent logic system that way, but
it says nothing about the original system).

This seems to be because you have just no understanding on core concepts
like Truth.

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

On 3/24/25 10:14 AM, olcott wrote:

On 3/24/2025 6:23 AM, Richard Damon wrote:

On 3/23/25 9:06 PM, olcott wrote:

On 3/23/2025 6:56 PM, Richard Damon wrote:

On 3/23/25 6:47 PM, olcott wrote:

On 3/23/2025 4:46 PM, Richard Damon wrote:

On 3/23/25 1:21 PM, olcott wrote:

On 3/23/2025 6:07 AM, Richard Damon wrote:

On 3/22/25 11:52 PM, olcott wrote:

On 3/22/2025 9:53 PM, Richard Damon wrote:

On 3/22/25 2:08 PM, olcott wrote:

On 3/22/2025 12:38 PM, Richard Damon wrote:

On 3/22/25 1:31 PM, olcott wrote:

On 3/22/2025 11:37 AM, joes wrote:

Am Sat, 22 Mar 2025 08:43:03 -0500 schrieb olcott: >>>>>>>>>>>>>>

typedef void (*ptr)();
int HHH(ptr P);
int main()
{
    HHH(Infinite_Recursion);
}
There is no program DDD in the above code.

There is also no Infinite_Recursion.

Since no Turing machine M can ever compute the mapping >>>>>>>>>>>>>>> from the behavior
of any directly executed TM2 referring to the behavior of >>>>>>>>>>>>>>> the directly
executed DDD has always been incorrect. Halt Deciders >>>>>>>>>>>>>>> always report on
the behavior that their input finite string specifies. >>>>>>>>>>>>>

Please explain what behaviour the description of a TM >>>>>>>>>>>>>> "specifies",
and which TM the input describes.

"Bill sang a song" describes what Bill did.
A tape recording of Bill singing that same
song completely specifies what Bill did.

And what a UTM does with this input completely specifies its >>>>>>>>>>>> behavior,

In every case that does not involve pathological self- >>>>>>>>>>>>>>> reference the
behavior that the finite string specifies is
coincidentally the same
behavior as the direct execution of the corresponding >>>>>>>>>>>>>>> machine. The
actual measure, however, has always been the behavior >>>>>>>>>>>>>>> that the finite
string input specifies.

...which is the direct execution. Not much of a coincidence. >>>>>>>>>>>>>>

_III()
[00002172] 55         push ebp      ; housekeeping >>>>>>>>>>>>> [00002173] 8bec       mov  ebp,esp  ; housekeeping >>>>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push III
[0000217a] e853f4ffff call 000015d2 ; call EEE(III)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

When-so-ever any correct emulator EEE correctly emulates >>>>>>>>>>>>> a finite number of steps of an input III that calls this >>>>>>>>>>>>> same emulator to emulate itself the behavior of the direct >>>>>>>>>>>>> execution of III will not be the same as the behavior of >>>>>>>>>>>>> the emulated III.

Becuase a finite emulation that stop before the end is not a >>>>>>>>>>>> correct emulation

In other words you keep dishonestly trying to get away with >>>>>>>>>>> disagreeing with the law of identity.

When N steps are III are correctly emulated by EEE
then N steps are III are correctly emulated by EEE.

Which isn't the same as the CORRECT emulation that shows if >>>>>>>>>> the program being emulated will halt/.

There exists no Natural Number N number of steps of III
correctly emulated by EEE where III reaches its
own "ret" instruction and terminates normally.

Because

In other words you agree that the recursive emulation
of a single finite string of x86 machine code single
machine address [00002172] cannot possibly reach its
own machine address [00002183]when emulated by emulator
EEE according to the semantics of the x86 language.

But it isn't a single finite string of x86 machince code,

As a matter of verified fact it is a single finite
string of machine code at a fixed offset in the
Halt7.obj file.

Nope, because DEFINTIONALLY, to correctly emulate it, you need ALL >>>>>> of it (at least all seen by the emulator) and thus you can't
change the parts seen and still be talking about the same input.

Your claim just shows you are a patholgical liar.

You can not "correctly emulate" the code of just the function, you >>>>>> need the rest of the code, which mean you can't do the variations
you talk about.

x86utm operates on a compiled object file that
is stored in a single location of global memory.

Right, and thus you must consider *ALL* of that memory as the input,
so if you change it, it is a different input.

You haven't yet noticed that all posts with this title
[III correctly emulated by EEE] are talking about a pure
emulator that emulates a finite number of instructions of III.

Which is just a strawman, and a contradiction, as the definition of
"correct emulation" (to be able to use it in the halting problem as a
surrogate for the programs behavior) must be complete.

_III()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push III
[0000217a] e853f4ffff call 000015d2 ; call EEE(III)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

You continue to look increasingly foolish when you
try to keep getting away with denying that III
calls EEE(III) in recursive emulation.

But I don't deny it, just point out that it is irrelevent, since none of
your variations of HHH get that same input, as the input *MUST* include
the code of the function that DDD/III calls, and thus they will be
different.

Remember, a pure function, which is what a program is, can't access any
memory not part of its input. It can only access its own code to execute it.


So sorry that all you are doing is proving the fraud you have been
trying to pull over everyone by your lying about what you words actually
mean and showing how stupid and ignorant you are.

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

Am Mon, 24 Mar 2025 21:13:51 -0500 schrieb olcott:

On 3/24/2025 8:28 PM, Richard Damon wrote:

On 3/24/25 10:14 AM, olcott wrote:

On 3/24/2025 6:23 AM, Richard Damon wrote:

On 3/23/25 9:06 PM, olcott wrote:

On 3/23/2025 6:56 PM, Richard Damon wrote:

On 3/23/25 6:47 PM, olcott wrote:

On 3/23/2025 4:46 PM, Richard Damon wrote:

On 3/23/25 1:21 PM, olcott wrote:

On 3/23/2025 6:07 AM, Richard Damon wrote:

On 3/22/25 11:52 PM, olcott wrote:

On 3/22/2025 9:53 PM, Richard Damon wrote:

On 3/22/25 2:08 PM, olcott wrote:

On 3/22/2025 12:38 PM, Richard Damon wrote:

On 3/22/25 1:31 PM, olcott wrote:

On 3/22/2025 11:37 AM, joes wrote:

Am Sat, 22 Mar 2025 08:43:03 -0500 schrieb olcott: >>>>>>>>>>>>>>>>

typedef void (*ptr)();
int HHH(ptr P);
int main()
{
    HHH(Infinite_Recursion);
}
There is no program DDD in the above code.

There is also no Infinite_Recursion.

Since no Turing machine M can ever compute the mapping >>>>>>>>>>>>>>>>> from the behavior of any directly executed TM2 referring >>>>>>>>>>>>>>>>> to the behavior of the directly executed DDD has always >>>>>>>>>>>>>>>>> been incorrect. Halt Deciders always report on the >>>>>>>>>>>>>>>>> behavior that their input finite string specifies. >>>>>>>>>>>>>>>>

Please explain what behaviour the description of a TM >>>>>>>>>>>>>>>> "specifies", and which TM the input describes. >>>>>>>>>>>>>>>>

"Bill sang a song" describes what Bill did.
A tape recording of Bill singing that same song completely >>>>>>>>>>>>>>> specifies what Bill did.

And what a UTM does with this input completely specifies >>>>>>>>>>>>>> its behavior,

In every case that does not involve pathological self- >>>>>>>>>>>>>>>>> reference the behavior that the finite string specifies >>>>>>>>>>>>>>>>> is coincidentally the same behavior as the direct >>>>>>>>>>>>>>>>> execution of the corresponding machine. The actual >>>>>>>>>>>>>>>>> measure, however, has always been the behavior that the >>>>>>>>>>>>>>>>> finite string input specifies.

...which is the direct execution. Not much of a >>>>>>>>>>>>>>>> coincidence.

When-so-ever any correct emulator EEE correctly emulates a >>>>>>>>>>>>>>> finite number of steps of an input III that calls this >>>>>>>>>>>>>>> same emulator to emulate itself the behavior of the direct >>>>>>>>>>>>>>> execution of III will not be the same as the behavior of >>>>>>>>>>>>>>> the emulated III.

Becuase a finite emulation that stop before the end is not >>>>>>>>>>>>>> a correct emulation

In other words you keep dishonestly trying to get away with >>>>>>>>>>>>> disagreeing with the law of identity.
When N steps are III are correctly emulated by EEE then N >>>>>>>>>>>>> steps are III are correctly emulated by EEE.

Which isn't the same as the CORRECT emulation that shows if >>>>>>>>>>>> the program being emulated will halt/.

There exists no Natural Number N number of steps of III >>>>>>>>>>>>> correctly emulated by EEE where III reaches its own "ret" >>>>>>>>>>>>> instruction and terminates normally.

But there is an N after which III returns.

In other words you agree that the recursive emulation of a >>>>>>>>>>> single finite string of x86 machine code single machine
address [00002172] cannot possibly reach its own machine >>>>>>>>>>> address [00002183]when emulated by emulator EEE according to >>>>>>>>>>> the semantics of the x86 language.

But it isn't a single finite string of x86 machince code,

As a matter of verified fact it is a single finite string of >>>>>>>>> machine code at a fixed offset in the Halt7.obj file.

Nope, because DEFINTIONALLY, to correctly emulate it, you need >>>>>>>> ALL of it (at least all seen by the emulator) and thus you can't >>>>>>>> change the parts seen and still be talking about the same input. >>>>>>>> Your claim just shows you are a patholgical liar.
You can not "correctly emulate" the code of just the function, >>>>>>>> you need the rest of the code, which mean you can't do the
variations you talk about.

x86utm operates on a compiled object file that is stored in a
single location of global memory.

Right, and thus you must consider *ALL* of that memory as the
input, so if you change it, it is a different input.

You haven't yet noticed that all posts with this title [III
correctly emulated by EEE] are talking about a pure emulator that
emulates a finite number of instructions of III.

Then it is not pure.

Which is just a strawman, and a contradiction, as the definition of
"correct emulation" (to be able to use it in the halting problem as a
surrogate for the programs behavior) must be complete.

You continue to look increasingly foolish when you try to keep getting
away with denying that III calls EEE(III) in recursive emulation.

But I don't deny it, just point out that it is irrelevent,

It proves that the input DDD to HHH DOES NOT HALT.
How the f-ck is that irrelevant?

DDD, the input, halts.

--
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 3/24/25 10:13 PM, olcott wrote:

On 3/24/2025 8:28 PM, Richard Damon wrote:

On 3/24/25 10:14 AM, olcott wrote:

On 3/24/2025 6:23 AM, Richard Damon wrote:

On 3/23/25 9:06 PM, olcott wrote:

On 3/23/2025 6:56 PM, Richard Damon wrote:

On 3/23/25 6:47 PM, olcott wrote:

On 3/23/2025 4:46 PM, Richard Damon wrote:

On 3/23/25 1:21 PM, olcott wrote:

On 3/23/2025 6:07 AM, Richard Damon wrote:

On 3/22/25 11:52 PM, olcott wrote:

On 3/22/2025 9:53 PM, Richard Damon wrote:

On 3/22/25 2:08 PM, olcott wrote:

On 3/22/2025 12:38 PM, Richard Damon wrote:

On 3/22/25 1:31 PM, olcott wrote:

On 3/22/2025 11:37 AM, joes wrote:

Am Sat, 22 Mar 2025 08:43:03 -0500 schrieb olcott: >>>>>>>>>>>>>>>>

typedef void (*ptr)();
int HHH(ptr P);
int main()
{
    HHH(Infinite_Recursion);
}
There is no program DDD in the above code.

There is also no Infinite_Recursion.

Since no Turing machine M can ever compute the mapping >>>>>>>>>>>>>>>>> from the behavior
of any directly executed TM2 referring to the behavior >>>>>>>>>>>>>>>>> of the directly
executed DDD has always been incorrect. Halt Deciders >>>>>>>>>>>>>>>>> always report on
the behavior that their input finite string specifies. >>>>>>>>>>>>>>>

Please explain what behaviour the description of a TM >>>>>>>>>>>>>>>> "specifies",
and which TM the input describes.

"Bill sang a song" describes what Bill did.
A tape recording of Bill singing that same
song completely specifies what Bill did.

And what a UTM does with this input completely specifies >>>>>>>>>>>>>> its behavior,

In every case that does not involve pathological self- >>>>>>>>>>>>>>>>> reference the
behavior that the finite string specifies is >>>>>>>>>>>>>>>>> coincidentally the same
behavior as the direct execution of the corresponding >>>>>>>>>>>>>>>>> machine. The
actual measure, however, has always been the behavior >>>>>>>>>>>>>>>>> that the finite
string input specifies.

...which is the direct execution. Not much of a >>>>>>>>>>>>>>>> coincidence.

_III()
[00002172] 55         push ebp      ; housekeeping >>>>>>>>>>>>>>> [00002173] 8bec       mov  ebp,esp  ; housekeeping >>>>>>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push III
[0000217a] e853f4ffff call 000015d2 ; call EEE(III) >>>>>>>>>>>>>>> [0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

When-so-ever any correct emulator EEE correctly emulates >>>>>>>>>>>>>>> a finite number of steps of an input III that calls this >>>>>>>>>>>>>>> same emulator to emulate itself the behavior of the direct >>>>>>>>>>>>>>> execution of III will not be the same as the behavior of >>>>>>>>>>>>>>> the emulated III.

Becuase a finite emulation that stop before the end is not >>>>>>>>>>>>>> a correct emulation

In other words you keep dishonestly trying to get away with >>>>>>>>>>>>> disagreeing with the law of identity.

When N steps are III are correctly emulated by EEE
then N steps are III are correctly emulated by EEE.

Which isn't the same as the CORRECT emulation that shows if >>>>>>>>>>>> the program being emulated will halt/.

There exists no Natural Number N number of steps of III >>>>>>>>>>>>> correctly emulated by EEE where III reaches its
own "ret" instruction and terminates normally.

Because

In other words you agree that the recursive emulation
of a single finite string of x86 machine code single
machine address [00002172] cannot possibly reach its
own machine address [00002183]when emulated by emulator
EEE according to the semantics of the x86 language.

But it isn't a single finite string of x86 machince code,

As a matter of verified fact it is a single finite
string of machine code at a fixed offset in the
Halt7.obj file.

Nope, because DEFINTIONALLY, to correctly emulate it, you need >>>>>>>> ALL of it (at least all seen by the emulator) and thus you can't >>>>>>>> change the parts seen and still be talking about the same input. >>>>>>>>
Your claim just shows you are a patholgical liar.

You can not "correctly emulate" the code of just the function, >>>>>>>> you need the rest of the code, which mean you can't do the
variations you talk about.

x86utm operates on a compiled object file that
is stored in a single location of global memory.

Right, and thus you must consider *ALL* of that memory as the
input, so if you change it, it is a different input.

You haven't yet noticed that all posts with this title
[III correctly emulated by EEE] are talking about a pure
emulator that emulates a finite number of instructions of III.

Which is just a strawman, and a contradiction, as the definition of
"correct emulation" (to be able to use it in the halting problem as
a surrogate for the programs behavior) must be complete.

_III()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push III
[0000217a] e853f4ffff call 000015d2 ; call EEE(III)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

You continue to look increasingly foolish when you
try to keep getting away with denying that III
calls EEE(III) in recursive emulation.

But I don't deny it, just point out that it is irrelevent,

It proves that the input DDD to HHH DOES NOT HALT.
How the f-ck is that irrelevant?

NO it doesn't, as that isn't the same input as DDD, as DDD calls HHH not
EEE, and they are different functions.

Sorry, you are just proving you don't know what you are talking about.

Remember, the decider needs to decide on the input, and thus it needs
ALL of the program given to it.

And, it is impossible to build a physical (or even theoretical one that
matches reality) that can have two different program (HHH and EEE)
stored at the same memory address.

Where did you learn about what programs are?

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

Am Tue, 25 Mar 2025 07:00:57 -0500 schrieb olcott:

On 3/25/2025 3:37 AM, joes wrote:

Am Mon, 24 Mar 2025 21:13:51 -0500 schrieb olcott:

On 3/24/2025 8:28 PM, Richard Damon wrote:

On 3/24/25 10:14 AM, olcott wrote:

On 3/24/2025 6:23 AM, Richard Damon wrote:

On 3/23/25 9:06 PM, olcott wrote:

On 3/23/2025 6:56 PM, Richard Damon wrote:

On 3/23/25 6:47 PM, olcott wrote:

On 3/23/2025 4:46 PM, Richard Damon wrote:

On 3/23/25 1:21 PM, olcott wrote:

On 3/23/2025 6:07 AM, Richard Damon wrote:

On 3/22/25 11:52 PM, olcott wrote:

On 3/22/2025 9:53 PM, Richard Damon wrote:

On 3/22/25 2:08 PM, olcott wrote:

There exists no Natural Number N number of steps of III >>>>>>>>>>>>>>> correctly emulated by EEE where III reaches its own "ret" >>>>>>>>>>>>>>> instruction and terminates normally.

But there is an N after which III returns.

Right, and thus you must consider *ALL* of that memory as the
input, so if you change it, it is a different input.

You haven't yet noticed that all posts with this title [III
correctly emulated by EEE] are talking about a pure emulator that >>>>>>> emulates a finite number of instructions of III.

Then it is not pure.

DDD, the input, halts.

The DDD that halts IS NOT AN ACTUAL INPUT TO HHH.

Then what is? Another program with the same name that doesn't?

--
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 3/25/25 8:12 AM, olcott wrote:

On 3/24/2025 8:28 PM, Richard Damon wrote:

On 3/24/25 10:14 AM, olcott wrote:

On 3/24/2025 6:23 AM, Richard Damon wrote:

On 3/23/25 9:06 PM, olcott wrote:

On 3/23/2025 6:56 PM, Richard Damon wrote:

On 3/23/25 6:47 PM, olcott wrote:

On 3/23/2025 4:46 PM, Richard Damon wrote:

On 3/23/25 1:21 PM, olcott wrote:

On 3/23/2025 6:07 AM, Richard Damon wrote:

On 3/22/25 11:52 PM, olcott wrote:

On 3/22/2025 9:53 PM, Richard Damon wrote:

On 3/22/25 2:08 PM, olcott wrote:

On 3/22/2025 12:38 PM, Richard Damon wrote:

On 3/22/25 1:31 PM, olcott wrote:

On 3/22/2025 11:37 AM, joes wrote:

Am Sat, 22 Mar 2025 08:43:03 -0500 schrieb olcott: >>>>>>>>>>>>>>>>

typedef void (*ptr)();
int HHH(ptr P);
int main()
{
    HHH(Infinite_Recursion);
}
There is no program DDD in the above code.

There is also no Infinite_Recursion.

Since no Turing machine M can ever compute the mapping >>>>>>>>>>>>>>>>> from the behavior
of any directly executed TM2 referring to the behavior >>>>>>>>>>>>>>>>> of the directly
executed DDD has always been incorrect. Halt Deciders >>>>>>>>>>>>>>>>> always report on
the behavior that their input finite string specifies. >>>>>>>>>>>>>>>

Please explain what behaviour the description of a TM >>>>>>>>>>>>>>>> "specifies",
and which TM the input describes.

"Bill sang a song" describes what Bill did.
A tape recording of Bill singing that same
song completely specifies what Bill did.

And what a UTM does with this input completely specifies >>>>>>>>>>>>>> its behavior,

In every case that does not involve pathological self- >>>>>>>>>>>>>>>>> reference the
behavior that the finite string specifies is >>>>>>>>>>>>>>>>> coincidentally the same
behavior as the direct execution of the corresponding >>>>>>>>>>>>>>>>> machine. The
actual measure, however, has always been the behavior >>>>>>>>>>>>>>>>> that the finite
string input specifies.

...which is the direct execution. Not much of a >>>>>>>>>>>>>>>> coincidence.

_III()
[00002172] 55         push ebp      ; housekeeping >>>>>>>>>>>>>>> [00002173] 8bec       mov  ebp,esp  ; housekeeping >>>>>>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push III
[0000217a] e853f4ffff call 000015d2 ; call EEE(III) >>>>>>>>>>>>>>> [0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

When-so-ever any correct emulator EEE correctly emulates >>>>>>>>>>>>>>> a finite number of steps of an input III that calls this >>>>>>>>>>>>>>> same emulator to emulate itself the behavior of the direct >>>>>>>>>>>>>>> execution of III will not be the same as the behavior of >>>>>>>>>>>>>>> the emulated III.

Becuase a finite emulation that stop before the end is not >>>>>>>>>>>>>> a correct emulation

In other words you keep dishonestly trying to get away with >>>>>>>>>>>>> disagreeing with the law of identity.

When N steps are III are correctly emulated by EEE
then N steps are III are correctly emulated by EEE.

Which isn't the same as the CORRECT emulation that shows if >>>>>>>>>>>> the program being emulated will halt/.

There exists no Natural Number N number of steps of III >>>>>>>>>>>>> correctly emulated by EEE where III reaches its
own "ret" instruction and terminates normally.

Because

In other words you agree that the recursive emulation
of a single finite string of x86 machine code single
machine address [00002172] cannot possibly reach its
own machine address [00002183]when emulated by emulator
EEE according to the semantics of the x86 language.

But it isn't a single finite string of x86 machince code,

As a matter of verified fact it is a single finite
string of machine code at a fixed offset in the
Halt7.obj file.

Nope, because DEFINTIONALLY, to correctly emulate it, you need >>>>>>>> ALL of it (at least all seen by the emulator) and thus you can't >>>>>>>> change the parts seen and still be talking about the same input. >>>>>>>>
Your claim just shows you are a patholgical liar.

You can not "correctly emulate" the code of just the function, >>>>>>>> you need the rest of the code, which mean you can't do the
variations you talk about.

x86utm operates on a compiled object file that
is stored in a single location of global memory.

Right, and thus you must consider *ALL* of that memory as the
input, so if you change it, it is a different input.

You haven't yet noticed that all posts with this title
[III correctly emulated by EEE] are talking about a pure
emulator that emulates a finite number of instructions of III.

Which is just a strawman, and a contradiction, as the definition of
"correct emulation" (to be able to use it in the halting problem as
a surrogate for the programs behavior) must be complete.

_III()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push III
[0000217a] e853f4ffff call 000015d2 ; call EEE(III)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

You continue to look increasingly foolish when you
try to keep getting away with denying that III
calls EEE(III) in recursive emulation.

But I don't deny it, just point out that it is irrelevent,

If you don't deny it then you know that III emulated
by EEE cannot possibly halt. DDD emulated by HHH has
this same pattern that proves that HHH is correct to
reject DDD as not halting.

It proves that the input DDD to HHH DOES NOT HALT.
How the f-ck is that irrelevant?

Nope, because HHH isn't EEE, and thus the inputs are either differnt or category errors (if you don't include the called function as part of the input).

Sorry, but you are just proving that you whole argument is based on lies
and FRAUD.

It seems you just don't understand what it means for something to be TRUE.

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

On 3/25/25 6:57 PM, olcott wrote:

On 3/25/2025 4:32 PM, joes wrote:

Am Tue, 25 Mar 2025 07:00:57 -0500 schrieb olcott:

On 3/25/2025 3:37 AM, joes wrote:

Am Mon, 24 Mar 2025 21:13:51 -0500 schrieb olcott:

On 3/24/2025 8:28 PM, Richard Damon wrote:

On 3/24/25 10:14 AM, olcott wrote:

On 3/24/2025 6:23 AM, Richard Damon wrote:

On 3/23/25 9:06 PM, olcott wrote:

On 3/23/2025 6:56 PM, Richard Damon wrote:

On 3/23/25 6:47 PM, olcott wrote:

On 3/23/2025 4:46 PM, Richard Damon wrote:

On 3/23/25 1:21 PM, olcott wrote:

On 3/23/2025 6:07 AM, Richard Damon wrote:

On 3/22/25 11:52 PM, olcott wrote:

On 3/22/2025 9:53 PM, Richard Damon wrote:

On 3/22/25 2:08 PM, olcott wrote:

There exists no Natural Number N number of steps of III >>>>>>>>>>>>>>>>> correctly emulated by EEE where III reaches its own "ret" >>>>>>>>>>>>>>>>> instruction and terminates normally.

But there is an N after which III returns.

Right, and thus you must consider *ALL* of that memory as the >>>>>>>>>> input, so if you change it, it is a different input.

You haven't yet noticed that all posts with this title [III
correctly emulated by EEE] are talking about a pure emulator that >>>>>>>>> emulates a finite number of instructions of III.

Then it is not pure.

DDD, the input, halts.

The DDD that halts IS NOT AN ACTUAL INPUT TO HHH.

Then what is? Another program with the same name that doesn't?

An entirely different instance that has different behavior.

YOu mean it has a different set of instructions?

It is easier to see this as DDD emulated by HHH where DDD
defines a pathological relationship with HHH versus DDD
emulated by HHH1 where there is no such pathological relationship.

DDD/HHH  Cannot possibly reach its final halt state.

So HHH just gives up before reaching the end, but doesn't show that a
FULL emulation of that input won't reach there.

DDD/HHH1 Reaches its final halt state.

Because HHH1 didn't give up.

HHH giving up doesn't prove that the correct emulation of its input
doesn't reach a halting state, just that HHH didn't emulate long enough.


HHH can't emulate longer, as it would no longer BE that HHH, but some
other program, and would have to be at some other address, or you have
changed the program DDD as it is already using that memory and fixed its values.

Of course, if you say those locations aren't part of the input
representing DDD becuase they are a part of DDD, then DDD CAN'T be
correctly emulated, as it is no longer actually a program with behavior,
as a program can't use code that isn't part of itself.

Sorry, you are just proving that your logic is based on lies and fraud.

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

Am Tue, 25 Mar 2025 17:57:29 -0500 schrieb olcott:

On 3/25/2025 4:32 PM, joes wrote:

Am Tue, 25 Mar 2025 07:00:57 -0500 schrieb olcott:

On 3/25/2025 3:37 AM, joes wrote:

Am Mon, 24 Mar 2025 21:13:51 -0500 schrieb olcott:

On 3/24/2025 8:28 PM, Richard Damon wrote:

On 3/24/25 10:14 AM, olcott wrote:

On 3/24/2025 6:23 AM, Richard Damon wrote:

On 3/23/25 9:06 PM, olcott wrote:

On 3/23/2025 6:56 PM, Richard Damon wrote:

On 3/23/25 6:47 PM, olcott wrote:

On 3/23/2025 4:46 PM, Richard Damon wrote:

On 3/23/25 1:21 PM, olcott wrote:

On 3/23/2025 6:07 AM, Richard Damon wrote:

On 3/22/25 11:52 PM, olcott wrote:

On 3/22/2025 9:53 PM, Richard Damon wrote:

On 3/22/25 2:08 PM, olcott wrote:

There exists no Natural Number N number of steps of III >>>>>>>>>>>>>>>>> correctly emulated by EEE where III reaches its own >>>>>>>>>>>>>>>>> "ret" instruction and terminates normally.

But there is an N after which III returns.

^

Right, and thus you must consider *ALL* of that memory as the >>>>>>>>>> input, so if you change it, it is a different input.

You haven't yet noticed that all posts with this title [III
correctly emulated by EEE] are talking about a pure emulator >>>>>>>>> that emulates a finite number of instructions of III.

Then it is not pure.

^

DDD, the input, halts.

The DDD that halts IS NOT AN ACTUAL INPUT TO HHH.

Then what is? Another program with the same name that doesn't?

An entirely different instance that has different behavior.

Not with deterministic code. So what is the input, if not DDD?

It is easier to see this as DDD emulated by HHH where DDD defines a pathological relationship with HHH versus DDD emulated by HHH1 where
there is no such pathological relationship.
DDD/HHH Cannot possibly reach its final halt state.
DDD/HHH1 Reaches its final halt state.

HHH1 is right.

--
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 3/25/25 11:32 PM, olcott wrote:

On 3/25/2025 8:14 PM, Richard Damon wrote:

On 3/25/25 6:57 PM, olcott wrote:

On 3/25/2025 4:32 PM, joes wrote:

Am Tue, 25 Mar 2025 07:00:57 -0500 schrieb olcott:

On 3/25/2025 3:37 AM, joes wrote:

Am Mon, 24 Mar 2025 21:13:51 -0500 schrieb olcott:

On 3/24/2025 8:28 PM, Richard Damon wrote:

On 3/24/25 10:14 AM, olcott wrote:

On 3/24/2025 6:23 AM, Richard Damon wrote:

On 3/23/25 9:06 PM, olcott wrote:

On 3/23/2025 6:56 PM, Richard Damon wrote:

On 3/23/25 6:47 PM, olcott wrote:

On 3/23/2025 4:46 PM, Richard Damon wrote:

On 3/23/25 1:21 PM, olcott wrote:

On 3/23/2025 6:07 AM, Richard Damon wrote:

On 3/22/25 11:52 PM, olcott wrote:

On 3/22/2025 9:53 PM, Richard Damon wrote:

On 3/22/25 2:08 PM, olcott wrote:

There exists no Natural Number N number of steps of III >>>>>>>>>>>>>>>>>>> correctly emulated by EEE where III reaches its own >>>>>>>>>>>>>>>>>>> "ret"
instruction and terminates normally.

But there is an N after which III returns.

Right, and thus you must consider *ALL* of that memory as the >>>>>>>>>>>> input, so if you change it, it is a different input.

You haven't yet noticed that all posts with this title [III >>>>>>>>>>> correctly emulated by EEE] are talking about a pure emulator >>>>>>>>>>> that
emulates a finite number of instructions of III.

Then it is not pure.

DDD, the input, halts.

The DDD that halts IS NOT AN ACTUAL INPUT TO HHH.

Then what is? Another program with the same name that doesn't?

An entirely different instance that has different behavior.

YOu mean it has a different set of instructions?

It is easier to see this as DDD emulated by HHH where DDD
defines a pathological relationship with HHH versus DDD
emulated by HHH1 where there is no such pathological relationship.

DDD/HHH  Cannot possibly reach its final halt state.

So HHH just gives up before reaching the end,

Since you know that I know you are lying I
dare you to prove your point with actual correct
reasoning so that you can make a fool of yourself.

No, I know that you are so stupid you think i am lying when you are.

My point is proven by just running HHH, and seeing that it gives up.

We can then run the version where main calls DDD, and we see that by the DEFINITIONS of the problem, the input halts, and thus HHH was wrong.

Sorry, you are just proving to the world that you are so stupid you
can't see your stupidity. A perfect example of Dunning-Kruger.

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

On 3/25/25 11:28 PM, olcott wrote:

On 3/25/2025 7:33 PM, Richard Damon wrote:

On 3/25/25 8:12 AM, olcott wrote:

On 3/24/2025 8:28 PM, Richard Damon wrote:

On 3/24/25 10:14 AM, olcott wrote:

On 3/24/2025 6:23 AM, Richard Damon wrote:

On 3/23/25 9:06 PM, olcott wrote:

On 3/23/2025 6:56 PM, Richard Damon wrote:

On 3/23/25 6:47 PM, olcott wrote:

On 3/23/2025 4:46 PM, Richard Damon wrote:

On 3/23/25 1:21 PM, olcott wrote:

On 3/23/2025 6:07 AM, Richard Damon wrote:

On 3/22/25 11:52 PM, olcott wrote:

On 3/22/2025 9:53 PM, Richard Damon wrote:

On 3/22/25 2:08 PM, olcott wrote:

On 3/22/2025 12:38 PM, Richard Damon wrote:

On 3/22/25 1:31 PM, olcott wrote:

On 3/22/2025 11:37 AM, joes wrote:

Am Sat, 22 Mar 2025 08:43:03 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>

typedef void (*ptr)();
int HHH(ptr P);
int main()
{
    HHH(Infinite_Recursion);
}
There is no program DDD in the above code. >>>>>>>>>>>>>>>>>> There is also no Infinite_Recursion.

Since no Turing machine M can ever compute the >>>>>>>>>>>>>>>>>>> mapping from the behavior
of any directly executed TM2 referring to the >>>>>>>>>>>>>>>>>>> behavior of the directly
executed DDD has always been incorrect. Halt Deciders >>>>>>>>>>>>>>>>>>> always report on
the behavior that their input finite string specifies. >>>>>>>>>>>>>>>>>

Please explain what behaviour the description of a TM >>>>>>>>>>>>>>>>>> "specifies",
and which TM the input describes.

"Bill sang a song" describes what Bill did.
A tape recording of Bill singing that same
song completely specifies what Bill did.

And what a UTM does with this input completely specifies >>>>>>>>>>>>>>>> its behavior,

In every case that does not involve pathological >>>>>>>>>>>>>>>>>>> self- reference the
behavior that the finite string specifies is >>>>>>>>>>>>>>>>>>> coincidentally the same
behavior as the direct execution of the corresponding >>>>>>>>>>>>>>>>>>> machine. The
actual measure, however, has always been the behavior >>>>>>>>>>>>>>>>>>> that the finite
string input specifies.

...which is the direct execution. Not much of a >>>>>>>>>>>>>>>>>> coincidence.

_III()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping >>>>>>>>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push III >>>>>>>>>>>>>>>>> [0000217a] e853f4ffff call 000015d2 ; call EEE(III) >>>>>>>>>>>>>>>>> [0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

When-so-ever any correct emulator EEE correctly emulates >>>>>>>>>>>>>>>>> a finite number of steps of an input III that calls this >>>>>>>>>>>>>>>>> same emulator to emulate itself the behavior of the direct >>>>>>>>>>>>>>>>> execution of III will not be the same as the behavior of >>>>>>>>>>>>>>>>> the emulated III.

Becuase a finite emulation that stop before the end is >>>>>>>>>>>>>>>> not a correct emulation

In other words you keep dishonestly trying to get away with >>>>>>>>>>>>>>> disagreeing with the law of identity.

When N steps are III are correctly emulated by EEE >>>>>>>>>>>>>>> then N steps are III are correctly emulated by EEE. >>>>>>>>>>>>>>

Which isn't the same as the CORRECT emulation that shows >>>>>>>>>>>>>> if the program being emulated will halt/.

There exists no Natural Number N number of steps of III >>>>>>>>>>>>>>> correctly emulated by EEE where III reaches its
own "ret" instruction and terminates normally.

Because

In other words you agree that the recursive emulation >>>>>>>>>>>>> of a single finite string of x86 machine code single >>>>>>>>>>>>> machine address [00002172] cannot possibly reach its >>>>>>>>>>>>> own machine address [00002183]when emulated by emulator >>>>>>>>>>>>> EEE according to the semantics of the x86 language.

But it isn't a single finite string of x86 machince code, >>>>>>>>>>>

As a matter of verified fact it is a single finite
string of machine code at a fixed offset in the
Halt7.obj file.

Nope, because DEFINTIONALLY, to correctly emulate it, you need >>>>>>>>>> ALL of it (at least all seen by the emulator) and thus you >>>>>>>>>> can't change the parts seen and still be talking about the >>>>>>>>>> same input.

Your claim just shows you are a patholgical liar.

You can not "correctly emulate" the code of just the function, >>>>>>>>>> you need the rest of the code, which mean you can't do the >>>>>>>>>> variations you talk about.

x86utm operates on a compiled object file that
is stored in a single location of global memory.

Right, and thus you must consider *ALL* of that memory as the
input, so if you change it, it is a different input.

You haven't yet noticed that all posts with this title
[III correctly emulated by EEE] are talking about a pure
emulator that emulates a finite number of instructions of III.

Which is just a strawman, and a contradiction, as the definition
of "correct emulation" (to be able to use it in the halting
problem as a surrogate for the programs behavior) must be complete. >>>>>>

_III()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push III
[0000217a] e853f4ffff call 000015d2 ; call EEE(III)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

You continue to look increasingly foolish when you
try to keep getting away with denying that III
calls EEE(III) in recursive emulation.

But I don't deny it, just point out that it is irrelevent,

If you don't deny it then you know that III emulated
by EEE cannot possibly halt. DDD emulated by HHH has
this same pattern that proves that HHH is correct to
reject DDD as not halting.

It proves that the input DDD to HHH DOES NOT HALT.
How the f-ck is that irrelevant?

Nope, because HHH isn't EEE, and thus the inputs are either differnt
or category errors (if you don't include the called function as part
of the input).

EEE is merely a dumbed down HHH because people got confused.

No, you have been confused and dumbed yourself down to try to make
things better, but just made it worse.

Since none of your EEE shows the actual behavior of the input, and we
can show that since EEE will ALWAYS return after a finite number of
steps (since it always only does a finite number of steps) that III must
be a halting program.

Yes, we can extend that to DDD and HHH, that since all your HHH that
answer will abort their emulation (and thus not establish the defined
behavior of the input) and return to DDD, we can show that all DDD will
halt.

Your problem is just that you are too stupid to understand this, and are
trying to create a self-contradictory definition based on your faulty logic.

The fact that HHH just can not do a correct emulation, and at the same
time return an answer has made your whole argument a giant FRAUD that
has sunk you reputation by the lies you put out to try to support it.

Sorry, but you are just proving that you whole argument is based on
lies and FRAUD.

It seems you just don't understand what it means for something to be
TRUE.

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

On 3/26/25 6:43 PM, olcott wrote:

On 3/26/2025 6:20 AM, Richard Damon wrote:

On 3/25/25 11:32 PM, olcott wrote:

On 3/25/2025 8:14 PM, Richard Damon wrote:

On 3/25/25 6:57 PM, olcott wrote:

On 3/25/2025 4:32 PM, joes wrote:

Am Tue, 25 Mar 2025 07:00:57 -0500 schrieb olcott:

On 3/25/2025 3:37 AM, joes wrote:

Am Mon, 24 Mar 2025 21:13:51 -0500 schrieb olcott:

On 3/24/2025 8:28 PM, Richard Damon wrote:

On 3/24/25 10:14 AM, olcott wrote:

On 3/24/2025 6:23 AM, Richard Damon wrote:

On 3/23/25 9:06 PM, olcott wrote:

On 3/23/2025 6:56 PM, Richard Damon wrote:

On 3/23/25 6:47 PM, olcott wrote:

On 3/23/2025 4:46 PM, Richard Damon wrote:

On 3/23/25 1:21 PM, olcott wrote:

On 3/23/2025 6:07 AM, Richard Damon wrote:

On 3/22/25 11:52 PM, olcott wrote:

On 3/22/2025 9:53 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 3/22/25 2:08 PM, olcott wrote:

There exists no Natural Number N number of steps of >>>>>>>>>>>>>>>>>>>>> III
correctly emulated by EEE where III reaches its own >>>>>>>>>>>>>>>>>>>>> "ret"
instruction and terminates normally.

But there is an N after which III returns.

Right, and thus you must consider *ALL* of that memory as the >>>>>>>>>>>>>> input, so if you change it, it is a different input. >>>>>>>>>>>>> You haven't yet noticed that all posts with this title [III >>>>>>>>>>>>> correctly emulated by EEE] are talking about a pure

emulator that
emulates a finite number of instructions of III.

Then it is not pure.

DDD, the input, halts.

The DDD that halts IS NOT AN ACTUAL INPUT TO HHH.

Then what is? Another program with the same name that doesn't?

An entirely different instance that has different behavior.

YOu mean it has a different set of instructions?

It is easier to see this as DDD emulated by HHH where DDD
defines a pathological relationship with HHH versus DDD
emulated by HHH1 where there is no such pathological relationship.

DDD/HHH  Cannot possibly reach its final halt state.

So HHH just gives up before reaching the end,

Since you know that I know you are lying I
dare you to prove your point with actual correct
reasoning so that you can make a fool of yourself.

No, I know that you are so stupid you think i am lying when you are.

My point is proven by just running HHH, and seeing that it gives up.

You already admitted that DDD emulated by HHH never reaches
its final state an halts. Do you not understand that this
behavior can be detected in a finite number of steps.

But it isn't non-halting.

Non-Halting is that the machine won't reach its final staste even if an unbounded number of steps are emulated. Since HHH doesn't do that, it
isn't showing non-halting.

UTM(DDD) shows that the DDD that calls the HHH that THINKS (incorrectly)
that it has detected non-halting behavior will, in fact, reach a final
state, and thus be halting, and thus HHH is wrong if though of as an
actual Halting Decider.

Maybe you have solved the POOP problem, if you can ever properly define
it, which I am not so sure about.

We can then run the version where main calls DDD, and we see that by
the DEFINITIONS of the problem, the input halts, and thus HHH was wrong.

Sorry, you are just proving to the world that you are so stupid you
can't see your stupidity. A perfect example of Dunning-Kruger.

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

On 3/26/25 9:34 PM, olcott wrote:

On 3/26/2025 8:22 PM, Richard Damon wrote:

On 3/26/25 6:57 PM, olcott wrote:

On 3/26/2025 6:24 AM, Richard Damon wrote:

Since none of your EEE shows the actual behavior of the input, and
we can show that since EEE will ALWAYS return after a finite number
of steps

III emulated by EEE never reaches its final halt state.

Only because EEE doesn't do a complete emulation.

How is an infinite number of steps not a complete emulation?

You EEE never did an infinite numbdr of steps.

You said "When-so-ever any correct emulator EEE correctly emulates
a finite number of steps ..."

Thus, NEVER did an infinite number of steps.

The problem with lying is you need to keep your lies straight.

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

On 3/26/25 10:37 PM, olcott wrote:

On 3/26/2025 9:28 PM, Richard Damon wrote:

On 3/26/25 9:34 PM, olcott wrote:

On 3/26/2025 8:22 PM, Richard Damon wrote:

On 3/26/25 6:57 PM, olcott wrote:

On 3/26/2025 6:24 AM, Richard Damon wrote:

Since none of your EEE shows the actual behavior of the input, and >>>>>> we can show that since EEE will ALWAYS return after a finite
number of steps

III emulated by EEE never reaches its final halt state.

Only because EEE doesn't do a complete emulation.

How is an infinite number of steps not a complete emulation?

You EEE never did an infinite numbdr of steps.

Because you continue to dishonestly dodge the point I
have to revise the point to shut down your dishonest dodge.

How is an infinite number of steps not a complete emulation?

Because you defined EEE to do a finite number of steps?

How is a finite number of steps ever infinite?

You just are proving you don't understand the meaning of the words you use.

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

Op 26.mrt.2025 om 23:57 schreef olcott:

On 3/26/2025 6:24 AM, Richard Damon wrote:

On 3/25/25 11:28 PM, olcott wrote:

On 3/25/2025 7:33 PM, Richard Damon wrote:

On 3/25/25 8:12 AM, olcott wrote:

On 3/24/2025 8:28 PM, Richard Damon wrote:

On 3/24/25 10:14 AM, olcott wrote:

On 3/24/2025 6:23 AM, Richard Damon wrote:

On 3/23/25 9:06 PM, olcott wrote:

On 3/23/2025 6:56 PM, Richard Damon wrote:

On 3/23/25 6:47 PM, olcott wrote:

On 3/23/2025 4:46 PM, Richard Damon wrote:

On 3/23/25 1:21 PM, olcott wrote:

On 3/23/2025 6:07 AM, Richard Damon wrote:

On 3/22/25 11:52 PM, olcott wrote:

On 3/22/2025 9:53 PM, Richard Damon wrote:

On 3/22/25 2:08 PM, olcott wrote:

On 3/22/2025 12:38 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>> On 3/22/25 1:31 PM, olcott wrote:

On 3/22/2025 11:37 AM, joes wrote:

Am Sat, 22 Mar 2025 08:43:03 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>>>

typedef void (*ptr)();
int HHH(ptr P);
int main()
{
    HHH(Infinite_Recursion);
}
There is no program DDD in the above code. >>>>>>>>>>>>>>>>>>>> There is also no Infinite_Recursion.

Since no Turing machine M can ever compute the >>>>>>>>>>>>>>>>>>>>> mapping from the behavior
of any directly executed TM2 referring to the >>>>>>>>>>>>>>>>>>>>> behavior of the directly
executed DDD has always been incorrect. Halt >>>>>>>>>>>>>>>>>>>>> Deciders always report on
the behavior that their input finite string specifies. >>>>>>>>>>>>>>>>>>>

Please explain what behaviour the description of a >>>>>>>>>>>>>>>>>>>> TM "specifies",
and which TM the input describes.

"Bill sang a song" describes what Bill did. >>>>>>>>>>>>>>>>>>> A tape recording of Bill singing that same >>>>>>>>>>>>>>>>>>> song completely specifies what Bill did.

And what a UTM does with this input completely >>>>>>>>>>>>>>>>>> specifies its behavior,

In every case that does not involve pathological >>>>>>>>>>>>>>>>>>>>> self- reference the
behavior that the finite string specifies is >>>>>>>>>>>>>>>>>>>>> coincidentally the same
behavior as the direct execution of the >>>>>>>>>>>>>>>>>>>>> corresponding machine. The
actual measure, however, has always been the >>>>>>>>>>>>>>>>>>>>> behavior that the finite
string input specifies.

...which is the direct execution. Not much of a >>>>>>>>>>>>>>>>>>>> coincidence.

_III()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping >>>>>>>>>>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push III >>>>>>>>>>>>>>>>>>> [0000217a] e853f4ffff call 000015d2 ; call EEE(III) >>>>>>>>>>>>>>>>>>> [0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

When-so-ever any correct emulator EEE correctly emulates >>>>>>>>>>>>>>>>>>> a finite number of steps of an input III that calls this >>>>>>>>>>>>>>>>>>> same emulator to emulate itself the behavior of the >>>>>>>>>>>>>>>>>>> direct
execution of III will not be the same as the behavior of >>>>>>>>>>>>>>>>>>> the emulated III.

Becuase a finite emulation that stop before the end is >>>>>>>>>>>>>>>>>> not a correct emulation

In other words you keep dishonestly trying to get away >>>>>>>>>>>>>>>>> with
disagreeing with the law of identity.

When N steps are III are correctly emulated by EEE >>>>>>>>>>>>>>>>> then N steps are III are correctly emulated by EEE. >>>>>>>>>>>>>>>>

Which isn't the same as the CORRECT emulation that shows >>>>>>>>>>>>>>>> if the program being emulated will halt/.

There exists no Natural Number N number of steps of III >>>>>>>>>>>>>>>>> correctly emulated by EEE where III reaches its >>>>>>>>>>>>>>>>> own "ret" instruction and terminates normally. >>>>>>>>>>>>>>>>>

Because

In other words you agree that the recursive emulation >>>>>>>>>>>>>>> of a single finite string of x86 machine code single >>>>>>>>>>>>>>> machine address [00002172] cannot possibly reach its >>>>>>>>>>>>>>> own machine address [00002183]when emulated by emulator >>>>>>>>>>>>>>> EEE according to the semantics of the x86 language. >>>>>>>>>>>>>>>

But it isn't a single finite string of x86 machince code, >>>>>>>>>>>>>

As a matter of verified fact it is a single finite
string of machine code at a fixed offset in the
Halt7.obj file.

Nope, because DEFINTIONALLY, to correctly emulate it, you >>>>>>>>>>>> need ALL of it (at least all seen by the emulator) and thus >>>>>>>>>>>> you can't change the parts seen and still be talking about >>>>>>>>>>>> the same input.

Your claim just shows you are a patholgical liar.

You can not "correctly emulate" the code of just the
function, you need the rest of the code, which mean you >>>>>>>>>>>> can't do the variations you talk about.

x86utm operates on a compiled object file that
is stored in a single location of global memory.

Right, and thus you must consider *ALL* of that memory as the >>>>>>>>>> input, so if you change it, it is a different input.

You haven't yet noticed that all posts with this title
[III correctly emulated by EEE] are talking about a pure
emulator that emulates a finite number of instructions of III. >>>>>>>>>

Which is just a strawman, and a contradiction, as the definition >>>>>>>> of "correct emulation" (to be able to use it in the halting
problem as a surrogate for the programs behavior) must be complete. >>>>>>>>

_III()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push III
[0000217a] e853f4ffff call 000015d2 ; call EEE(III)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

You continue to look increasingly foolish when you
try to keep getting away with denying that III
calls EEE(III) in recursive emulation.

But I don't deny it, just point out that it is irrelevent,

If you don't deny it then you know that III emulated
by EEE cannot possibly halt. DDD emulated by HHH has
this same pattern that proves that HHH is correct to
reject DDD as not halting.

It proves that the input DDD to HHH DOES NOT HALT.
How the f-ck is that irrelevant?

Nope, because HHH isn't EEE, and thus the inputs are either differnt
or category errors (if you don't include the called function as part
of the input).

EEE is merely a dumbed down HHH because people got confused.

No, you have been confused and dumbed yourself down to try to make
things better, but just made it worse.

Since none of your EEE shows the actual behavior of the input, and we
can show that since EEE will ALWAYS return after a finite number of steps

III emulated by EEE never reaches its final halt state.

It is not very interesting to know whether a simulator reports that it
is unable to reach the end of the simulation of a program that halts in
direct execution.
It is interesting to know:
'Is there an algorithm that can determine for all possible inputs
whether the input specifies a program that (according to the semantics
of the machine language) halts when directly executed?'
This question seems undecidable for Olcott.

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

On 3/27/25 12:05 AM, olcott wrote:

On 3/26/2025 10:30 PM, Richard Damon wrote:

On 3/26/25 10:37 PM, olcott wrote:

On 3/26/2025 9:28 PM, Richard Damon wrote:

On 3/26/25 9:34 PM, olcott wrote:

On 3/26/2025 8:22 PM, Richard Damon wrote:

On 3/26/25 6:57 PM, olcott wrote:

On 3/26/2025 6:24 AM, Richard Damon wrote:

Since none of your EEE shows the actual behavior of the input, >>>>>>>> and we can show that since EEE will ALWAYS return after a finite >>>>>>>> number of steps

III emulated by EEE never reaches its final halt state.

Only because EEE doesn't do a complete emulation.

How is an infinite number of steps not a complete emulation?

You EEE never did an infinite numbdr of steps.

Because you continue to dishonestly dodge the point I
have to revise the point to shut down your dishonest dodge.

How is an infinite number of steps not a complete emulation?

Because you defined EEE to do a finite number of steps?

I just redefined it to be infinite dipshit.

Glad you are admitting that you "logic" is just "infinite dipshit".

That is how all your logic works, you can't hold yourself to a single definition, because you logic just can't work.

Sorry, you are proving that you are nothing but a pathological liar, and
that all your work is just a FRAUD.

How is a finite number of steps ever infinite?

You just are proving you don't understand the meaning of the words you
use.

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