On 2025-11-23, olcott <polcott333@gmail.com> wrote:
On 11/22/2025 10:00 PM, Kaz Kylheku wrote:
On 2025-11-22, olcott <polcott333@gmail.com> wrote:
On 11/22/2025 11:56 AM, Kaz Kylheku wrote:
On 2025-11-22, olcott <polcott333@gmail.com> wrote:
is exactly the same as HHH except that DD does not
call HHH1(DD) in recursive simulation.
I already pointed out the massive problem with this.
If HHH1 is identical to HHH, it means that HHH1 and HHH
are only different names for exactly the same function.
In the mathematical abstraction that simply pretends
the behavioral details don't exist the math itself is
also a damned liar.
The fact that two different names are used to refer to exactly the same
function does not constitute a "behavior detail" of that function.
That you are trying to get away with ignoring these
details from the stipulated perspective of the execution
trace in C according to the semantics of C makes you
a damned liar even when referring to the mathematical
abstraction.
If you want your C functions to correspond to recursive
functions in computation theory, you have to code them
according to certain rules.
One of those is that you may not conclude that if f1 != f2 (pointer
comparison) then they are different functions.
HHH1 is at line 589 - 665
HHH is at line 1081 - 1156
https://github.com/plolcott/x86utm/blob/master/Halt7.c
When DD calls HHH through of C interpreter
it does not call HHH1 because HHH1 has a
different name and is at a different location.
That's just the thing! If this were correctly implemented then in fact
DD /wold be/ calling HHH1, using the name HHH.
On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
That's just the thing! If this were correctly implemented then in fact
DD /wold be/ calling HHH1, using the name HHH.
You are trying to get away with this lie
about the semantics of C?
int main()
{
HHH(DD);
HHH1(DD);
return 0;
}
_main()
[000022c4] 55 push ebp
[000022c5] 8bec mov ebp,esp
[000022c7] 6834220000 push 00002234 ; push DD
[000022cc] e833f3ffff call 00001604 ; call HHH
[000022d1] 83c404 add esp,+04
[000022d4] 6834220000 push 00002234 ; push DD
[000022d9] e856f2ffff call 00001534 ; call HHH1
[000022de] 83c404 add esp,+04
[000022e1] 33c0 xor eax,eax
[000022e3] 5d pop ebp
[000022e4] c3 ret
Size in bytes:(0033) [000022e4]
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
That's just the thing! If this were correctly implemented then in fact
DD /wold be/ calling HHH1, using the name HHH.
You are trying to get away with this lie
about the semantics of C?
int main()
{
HHH(DD);
HHH1(DD);
return 0;
}
_main()
[000022c4] 55 push ebp
[000022c5] 8bec mov ebp,esp
[000022c7] 6834220000 push 00002234 ; push DD
[000022cc] e833f3ffff call 00001604 ; call HHH
[000022d1] 83c404 add esp,+04
[000022d4] 6834220000 push 00002234 ; push DD
[000022d9] e856f2ffff call 00001534 ; call HHH1
[000022de] 83c404 add esp,+04
[000022e1] 33c0 xor eax,eax
[000022e3] 5d pop ebp
[000022e4] c3 ret
Size in bytes:(0033) [000022e4]
That's right; even if HHH and HHH1 are separately realized and given different adddresses, not recognized as identical by the compiler and
not folded into one copy, in a correct implementation of your software, HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually interchangeable operations.
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/24/2025 10:32 AM, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
That's just the thing! If this were correctly implemented then in fact >>>>> DD /wold be/ calling HHH1, using the name HHH.
You are trying to get away with this lie
about the semantics of C?
int main()
{
HHH(DD);
HHH1(DD);
return 0;
}
_main()
[000022c4] 55 push ebp
[000022c5] 8bec mov ebp,esp
[000022c7] 6834220000 push 00002234 ; push DD
[000022cc] e833f3ffff call 00001604 ; call HHH
[000022d1] 83c404 add esp,+04
[000022d4] 6834220000 push 00002234 ; push DD
[000022d9] e856f2ffff call 00001534 ; call HHH1
[000022de] 83c404 add esp,+04
[000022e1] 33c0 xor eax,eax
[000022e3] 5d pop ebp
[000022e4] c3 ret
Size in bytes:(0033) [000022e4]
That's right; even if HHH and HHH1 are separately realized and given
different adddresses, not recognized as identical by the compiler and
not folded into one copy, in a correct implementation of your software,
HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually
interchangeable operations.
The problem is that you have logic which concludes that HHH1 != HHH (low >>> level pointer comparison), they are different functions.
Except when their input calls themself.
That makes no difference.
[000022e1] 33c0˙˙˙˙˙˙˙˙˙˙ xor eax,eax
[000022e3] 5d˙˙˙˙˙˙˙˙˙˙˙˙ pop ebp
[000022e4] c3˙˙˙˙˙˙˙˙˙˙˙˙ ret
Size in bytes:(0033) [000022e4]
That's right; even if HHH and HHH1 are separately realized and given
different adddresses, not recognized as identical by the compiler and
not folded into one copy, in a correct implementation of your software,
HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually
interchangeable operations.
Except when their input calls themself.
In this case they must simulate themselves
simulating their input, not just simulate
their input.
On 11/24/2025 11:55 AM, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/24/2025 10:32 AM, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
That's just the thing! If this were correctly implemented then in fact >>>>>> DD /wold be/ calling HHH1, using the name HHH.
You are trying to get away with this lie
about the semantics of C?
int main()
{
HHH(DD);
HHH1(DD);
return 0;
}
_main()
[000022c4] 55 push ebp
[000022c5] 8bec mov ebp,esp
[000022c7] 6834220000 push 00002234 ; push DD
[000022cc] e833f3ffff call 00001604 ; call HHH
[000022d1] 83c404 add esp,+04
[000022d4] 6834220000 push 00002234 ; push DD
[000022d9] e856f2ffff call 00001534 ; call HHH1
[000022de] 83c404 add esp,+04
[000022e1] 33c0 xor eax,eax
[000022e3] 5d pop ebp
[000022e4] c3 ret
Size in bytes:(0033) [000022e4]
That's right; even if HHH and HHH1 are separately realized and given
different adddresses, not recognized as identical by the compiler and
not folded into one copy, in a correct implementation of your software, >>>> HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually
interchangeable operations.
The problem is that you have logic which concludes that HHH1 != HHH (low >>>> level pointer comparison), they are different functions.
Except when their input calls themself.
That makes no difference.
typedef int (*ptr)();
int HHH(ptr P);
int HHH1(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
HHH1(DD);
}
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
HHH1 simulates DD that calls HHH(DD) that
returns to DD that returns to HHH1.
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/24/2025 12:12 PM, Mike Terry wrote:
Right - in terms of their results when called.
So stupidly incorrect that I can't believe
that Mike believes this.
Maybe the stupid one is you, and other people who are agree with each
other are right?
Naaaah, that could not possibly be ...
You must have deep connections in the US Department of Defense;
otherwise, how the hell did you get your hands on such a
high weapons-grade Dunning Kruger ...
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/24/2025 11:55 AM, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/24/2025 10:32 AM, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
That's just the thing! If this were correctly implemented then in fact >>>>>>> DD /wold be/ calling HHH1, using the name HHH.
You are trying to get away with this lie
about the semantics of C?
int main()
{
HHH(DD);
HHH1(DD);
return 0;
}
_main()
[000022c4] 55 push ebp
[000022c5] 8bec mov ebp,esp
[000022c7] 6834220000 push 00002234 ; push DD
[000022cc] e833f3ffff call 00001604 ; call HHH
[000022d1] 83c404 add esp,+04
[000022d4] 6834220000 push 00002234 ; push DD
[000022d9] e856f2ffff call 00001534 ; call HHH1
[000022de] 83c404 add esp,+04
[000022e1] 33c0 xor eax,eax
[000022e3] 5d pop ebp
[000022e4] c3 ret
Size in bytes:(0033) [000022e4]
That's right; even if HHH and HHH1 are separately realized and given >>>>> different adddresses, not recognized as identical by the compiler and >>>>> not folded into one copy, in a correct implementation of your software, >>>>> HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually
interchangeable operations.
The problem is that you have logic which concludes that HHH1 != HHH (low >>>>> level pointer comparison), they are different functions.
Except when their input calls themself.
That makes no difference.
typedef int (*ptr)();
int HHH(ptr P);
int HHH1(ptr P);
Please, don't post this repeated crap any more.
As long as you keep lying I will keep repeating it.
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/24/2025 1:27 PM, Kaz Kylheku wrote:
On 2025-11-24, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
On 24/11/2025 16:32, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
That's just the thing! If this were correctly implemented then in fact >>>>>>> DD /wold be/ calling HHH1, using the name HHH.
You are trying to get away with this lie
about the semantics of C?
int main()
{
HHH(DD);
HHH1(DD);
return 0;
}
_main()
[000022c4] 55 push ebp
[000022c5] 8bec mov ebp,esp
[000022c7] 6834220000 push 00002234 ; push DD
[000022cc] e833f3ffff call 00001604 ; call HHH
[000022d1] 83c404 add esp,+04
[000022d4] 6834220000 push 00002234 ; push DD
[000022d9] e856f2ffff call 00001534 ; call HHH1
[000022de] 83c404 add esp,+04
[000022e1] 33c0 xor eax,eax
[000022e3] 5d pop ebp
[000022e4] c3 ret
Size in bytes:(0033) [000022e4]
That's right; even if HHH and HHH1 are separately realized and given >>>>> different adddresses, not recognized as identical by the compiler and >>>>> not folded into one copy, in a correct implementation of your software, >>>>> HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually
interchangeable operations.
Right - in terms of their results when called.
But TM-descriptions can legitimately contain multiple distinct copies of "the same algorithm", and
there's no reason that an emulator emulating the TM is required to identify such copies as being
copies - an emulator just has to mimic what the TM would do and the TM doesn't know that it has
multiple copies of the same algorithm with different state labels... Your point that the /results/
of those copied algorithms must be the same is spot on though.
Olcott's simulator contains abort criteria which rely on comparing
addresses pulled from the trace buffer.
That logic concludes that when two addresses are not equal, they
represent two different functions. I.e. if CALL X and CALL Y occur in
the trace buffer, without any intervening conditionals in between but X
!= Y, then it is not concluded that it is a loop.
DD is calling HHH(DD) in recursive simulation
and DD is not calling HHH1(DD) in recursive
simulation.
Yes, clearly; yet HHH1 and HHH are the same. So how can that be?
I do not believe that you do not
understand this.
Indeed, I do, of course. I'm just saying that it's an incorrect
state of affairs.
The fact that you keep reiterating about how things /are/ in your
code, when I'm making effort to clarify that I'm talking about how
they are /supposed/ to be, shows me you are not comprehending
what you are reading.
Anyone that even knows what
ordinary recursion is should get this
The point is that there isn't /supposed/ to be a difference
between "DD is calls HHH" and "DD is calling HHH1".
We (you, me, anyone else who runs the code) do see a difference.
There is no denying that.
HHH and HHH1 both see if the same function is
called from the same machine address with the
same arguments. This is true for HHH(DD) and
not true for HHH1(DD).
You believe that HHH1 is a different function from HHH because
DDD calls HHH and does not call HHH1.
That, I'm saying, is not a valid concept.
The actual reason is that you are failing to identify HHH
and HHH1 as equivalent by using address comparisons.
The same function can be known under multiple addresses, just
like under different names. That's an implementation detail you
have to abstract away if you want to correctly model pure, recursive functions which behave like their mathematical counterparts in key ways.
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/24/2025 1:30 PM, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/24/2025 12:12 PM, Mike Terry wrote:
Right - in terms of their results when called.
So stupidly incorrect that I can't believe
that Mike believes this.
Maybe the stupid one is you, and other people who are agree with each
other are right?
Naaaah, that could not possibly be ...
You must have deep connections in the US Department of Defense;
otherwise, how the hell did you get your hands on such a
high weapons-grade Dunning Kruger ...
That you only have mere empty rhetoric that
has no basis seems to prove that you know
that you are not telling the truth.
Are you saying you are disappointed that your relevant and
substantial bit of rhetoric above, namely;
"So stupidly incorrect that I can't believe mike believes this"
did not elicit an equally deep followup?
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
As long as you keep lying I will keep repeating it.
To lie is to knowing post something that is false.
But if you do that about an objectively verifiable fact that has nothing
to do with yourself, but some scientific matter, nobody in their right
mind will see you as a liar.
Rather than see you as a liar, they will just assume you are ignorant
and incompetent.
What makes you think I, or Mike, or anyone here would write something I
know to be false, which would be interpreted as ignorant, rather than dishonest?
Maybe you don't understand that nobody would do that, since
you have no problem being casually wrong yourself.
On 2025-11-24, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
For HHH/HHH1 the issue is different - they are clearly different algorithms since they give
different results, but it's not pointer comparison that is the problem - it's the use of mutable
global data: HHH and HHH1 each use /their own/ global variable [viz their global trace tables]
within their algorithms.
Yes; this is an issue that I'm glossing over. HHH and HHH1 are not pure functions since they react to this mutating state.
Multiplie instances of HHH share an execution trace buffer, allocated
by the first call to HHH.
Multiple instances of HHH1 also share an execution trace buffer distinct
from that one allocated by the first call to HHH1.
Simulations conducted by any level of HHH only feed HHH's buffer,
and simulations conducted by any level of HHH1 only feed HHH1's buffer.
That is all gapingly incorrect; yet if these aspects were fixed, there
would still be a problem if we evaluate HHH1 != HHH as dincating that
they are different function.
It so happens that in this case, the global data is a static variable, and >> so it /appears/ at first glance as though they are the same - they have the same name in both
Olcott maintains that the only differenc ebetween HHH1 and HHH is
that DD calls HHH and not HHH1. Obviously that is false.
One way to fix this [akin to my H/H1 fix], would be to make HHH1 processing match HHH, e.g. change
both HHH/HHH1 to use a common global-scope variable rather than a static-cope ones. This leaves the
underlying problems of invalid global data use, but at least HHH/HHH1 are now equivalent. The
proper way of fixing the problem would be to get rid of the improper use of global data in both
HHH/HHH1. With either of these fixes HHH and HHH1 would produce the same result [neverhalts].
Olcott thinks that by moving the static data into the code space of the function, and using asssembly instructions and whatnot, such that the C keyword "static" does not appear, means that he has fixed the issue of relying on static data.
On 11/24/2025 4:22 PM, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/24/2025 1:27 PM, Kaz Kylheku wrote:
On 2025-11-24, Mike Terry
<news.dead.person.stones@darjeeling.plus.com> wrote:
On 24/11/2025 16:32, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
That's just the thing! If this were correctly implemented then >>>>>>>> in fact
DD /wold be/ calling HHH1, using the name HHH.
You are trying to get away with this lie
about the semantics of C?
int main()
{
˙˙˙˙˙ HHH(DD);
˙˙˙˙˙ HHH1(DD);
˙˙˙˙˙ return 0;
}
_main()
[000022c4] 55˙˙˙˙˙˙˙˙˙˙˙˙ push ebp
[000022c5] 8bec˙˙˙˙˙˙˙˙˙˙ mov ebp,esp
[000022c7] 6834220000˙˙˙˙ push 00002234 ; push DD
[000022cc] e833f3ffff˙˙˙˙ call 00001604 ; call HHH
[000022d1] 83c404˙˙˙˙˙˙˙˙ add esp,+04
[000022d4] 6834220000˙˙˙˙ push 00002234 ; push DD
[000022d9] e856f2ffff˙˙˙˙ call 00001534 ; call HHH1
[000022de] 83c404˙˙˙˙˙˙˙˙ add esp,+04
[000022e1] 33c0˙˙˙˙˙˙˙˙˙˙ xor eax,eax
[000022e3] 5d˙˙˙˙˙˙˙˙˙˙˙˙ pop ebp
[000022e4] c3˙˙˙˙˙˙˙˙˙˙˙˙ ret
Size in bytes:(0033) [000022e4]
That's right; even if HHH and HHH1 are separately realized and given >>>>>> different adddresses, not recognized as identical by the compiler and >>>>>> not folded into one copy, in a correct implementation of your
software,
HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually
interchangeable operations.
Right - in terms of their results when called.
But TM-descriptions can legitimately contain multiple distinct
copies of "the same algorithm", and
there's no reason that an emulator emulating the TM is required to
identify such copies as being
copies - an emulator just has to mimic what the TM would do and the >>>>> TM doesn't know that it has
multiple copies of the same algorithm with different state
labels...˙ Your point that the /results/
of those copied algorithms must be the same is spot on though.
Olcott's simulator contains abort criteria which rely on comparing
addresses pulled from the trace buffer.
That logic concludes that when two addresses are not equal, they
represent two different functions. I.e. if CALL X˙ and CALL Y occur in >>>> the trace buffer, without any intervening conditionals in between but X >>>> != Y, then it is not concluded that it is a loop.
DD is calling HHH(DD) in recursive simulation
and DD is not calling HHH1(DD) in recursive
simulation.
Yes, clearly; yet HHH1 and HHH are the same. So how can that be?
I do not believe that you do not
understand this.
Indeed, I do, of course. I'm just saying that it's an incorrect
state of affairs.
That wold be a lie.
It is like you are trying to get away with saying
that identical twins are one and the same person.
The identity of indiscernibles is an ontological principle
that states that there cannot be separate objects or entities
that have all their properties in common. https://en.wikipedia.org/wiki/Identity_of_indiscernibles
Even if identical twins had every single atom that
was identical they these atoms differ in their x,y,z
coordinates relative to the center of the Earth.
The fact that you keep reiterating about how things /are/ in your
code, when I'm making effort to clarify that I'm talking about how
they are /supposed/ to be, shows me you are not comprehending
what you are reading.
Anyone that even knows what
ordinary recursion is should get this
The point is that there isn't /supposed/ to be a difference
between "DD is calls HHH" and "DD is calling HHH1".
You keep thinking in mathematical terms that abstract
away (thus simply ignore) key differences.
We (you, me, anyone else who runs the code) do see a difference.
There is no denying that.
HHH and HHH1 both see if the same function is
called from the same machine address with the
same arguments. This is true for HHH(DD) and
not true for HHH1(DD).
You believe that HHH1 is a different function from HHH because
DDD calls HHH and does not call HHH1.
You really can't be stupid enough to not see the
different execution trace.
That, I'm saying, is not a valid concept.
The actual reason is that you are failing to identify HHH
and HHH1 as equivalent by using address comparisons.
That essentially prove that identical twins are not
one and the same person.
the comp.lang.c and comp.lang.c++ groups will
continue to be presented with your non-sense
until they call you out on it.
The same function can be known under multiple addresses, just
like under different names. That's an implementation detail you
have to abstract away if you want to correctly model pure, recursive
functions which behave like their mathematical counterparts in key ways.
On 24/11/2025 19:27, Kaz Kylheku wrote:
On 2025-11-24, Mike Terry
<news.dead.person.stones@darjeeling.plus.com> wrote:
On 24/11/2025 16:32, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
That's just the thing! If this were correctly implemented then in >>>>>> fact
DD /wold be/ calling HHH1, using the name HHH.
You are trying to get away with this lie
about the semantics of C?
int main()
{
˙˙˙˙ HHH(DD);
˙˙˙˙ HHH1(DD);
˙˙˙˙ return 0;
}
_main()
[000022c4] 55˙˙˙˙˙˙˙˙˙˙˙˙ push ebp
[000022c5] 8bec˙˙˙˙˙˙˙˙˙˙ mov ebp,esp
[000022c7] 6834220000˙˙˙˙ push 00002234 ; push DD
[000022cc] e833f3ffff˙˙˙˙ call 00001604 ; call HHH
[000022d1] 83c404˙˙˙˙˙˙˙˙ add esp,+04
[000022d4] 6834220000˙˙˙˙ push 00002234 ; push DD
[000022d9] e856f2ffff˙˙˙˙ call 00001534 ; call HHH1
[000022de] 83c404˙˙˙˙˙˙˙˙ add esp,+04
[000022e1] 33c0˙˙˙˙˙˙˙˙˙˙ xor eax,eax
[000022e3] 5d˙˙˙˙˙˙˙˙˙˙˙˙ pop ebp
[000022e4] c3˙˙˙˙˙˙˙˙˙˙˙˙ ret
Size in bytes:(0033) [000022e4]
That's right; even if HHH and HHH1 are separately realized and given
different adddresses, not recognized as identical by the compiler and
not folded into one copy, in a correct implementation of your software, >>>> HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually
interchangeable operations.
Right - in terms of their results when called.
But TM-descriptions can legitimately contain multiple distinct copies
of "the same algorithm", and
there's no reason that an emulator emulating the TM is required to
identify such copies as being
copies - an emulator just has to mimic what the TM would do and the
TM doesn't know that it has
multiple copies of the same algorithm with different state labels...
Your point that the /results/
of those copied algorithms must be the same is spot on though.
Olcott's simulator contains abort criteria which rely on comparing
addresses pulled from the trace buffer.
Yep.˙ There are two such comparisons:
-˙˙ the addresses of the CALL instructions are compared
-˙˙ the targets of the CALL instructions are compared
That logic concludes that when two addresses are not equal, they
represent two different functions. I.e. if CALL X˙ and CALL Y occur in
the trace buffer, without any intervening conditionals in between but X
!= Y, then it is not concluded that it is a loop.
Yep.˙ That's not actually a problem.˙ Possibly a genuine loop might be overlooked, but the point is that if the addresses /do/ match that could
be a loop (subject to the other conditions matching).
Hmm, maybe you're thinking that HHH/HHH1 are comparing trace addresses against /their own/ addresses?˙ They don't do that.˙ [H/H1 do that.]
All compared addresses (whether by HHH/HHH1) are trace addresses from
the DD() simulation, which is the same whether HHH or HHH1 is doing the emulation [up to the point HHH aborts and HHH1 carries on].˙ So if you
were right, the behaviour would in any case be the same for HHH/HHH1 and couldn't account for differing HHH/HHH1 results.
That is why HHH1 and HHH show different results, even though they are
identical.
That comparison is the root cause why it matters that DD calls HHH
and not HHH1.
Not so, but I'll perform the test...
A complication:˙ there are TWO occasions where trace address comparisons occur, as I listed above: the TARGETS of the two call instructions are compared, and the ADDRESSES of the call instructions are compared.
You want to equate "equivalent" addresses.˙ For the TARGET addresses
this is easy-peasy as I will just check if they are both HHH/HHH1.˙ For
the CALL instruction addresses, these will not be HHH/HHH1, but
logically the CALL addresses in different (equivalent) routines should
be considered equivalent???˙ What would you like done here?˙ [Perhaps if addresses are at the same offset within HHH/HHH1 they could be
considered equivalent.˙ That's a slight pain, but doable.]
You know what - I've just realised HHH/HHH1 are only called from DD, and there's only one DD so this issue doesn't matter in our scenario!˙ The
CALL instruction addresses will always be the same when HHH/HHH1 are
called.˙ I'll just ignore the issue for now.˙ (I'll trace the
comparisons and results so we can check this in the logs.)
Olcott wrongly believes that the fact of DD calling HHH and not HHH1 is
the root cause of the difference.
Well that's PO for you!˙ It's simply that HHH/HHH1 are different
algorithms (each working off their own static trace table).
If addressees are compared with a CompareFunctions(X, Y) function
whch ensures that HHH and HHH1 are considered equal, then that
difference will disappear.
But there will still be the problem I explained with the HHH/HHH1
having /their own/ static trace tables...
Mike.
On 11/24/2025 4:22 PM, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/24/2025 1:27 PM, Kaz Kylheku wrote:
On 2025-11-24, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
On 24/11/2025 16:32, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
That's just the thing! If this were correctly implemented then in fact >>>>>>>> DD /wold be/ calling HHH1, using the name HHH.
You are trying to get away with this lie
about the semantics of C?
int main()
{
HHH(DD);
HHH1(DD);
return 0;
}
_main()
[000022c4] 55 push ebp
[000022c5] 8bec mov ebp,esp
[000022c7] 6834220000 push 00002234 ; push DD
[000022cc] e833f3ffff call 00001604 ; call HHH
[000022d1] 83c404 add esp,+04
[000022d4] 6834220000 push 00002234 ; push DD
[000022d9] e856f2ffff call 00001534 ; call HHH1
[000022de] 83c404 add esp,+04
[000022e1] 33c0 xor eax,eax
[000022e3] 5d pop ebp
[000022e4] c3 ret
Size in bytes:(0033) [000022e4]
That's right; even if HHH and HHH1 are separately realized and given >>>>>> different adddresses, not recognized as identical by the compiler and >>>>>> not folded into one copy, in a correct implementation of your software, >>>>>> HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually
interchangeable operations.
Right - in terms of their results when called.
But TM-descriptions can legitimately contain multiple distinct copies of "the same algorithm", and
there's no reason that an emulator emulating the TM is required to identify such copies as being
copies - an emulator just has to mimic what the TM would do and the TM doesn't know that it has
multiple copies of the same algorithm with different state labels... Your point that the /results/
of those copied algorithms must be the same is spot on though.
Olcott's simulator contains abort criteria which rely on comparing
addresses pulled from the trace buffer.
That logic concludes that when two addresses are not equal, they
represent two different functions. I.e. if CALL X and CALL Y occur in >>>> the trace buffer, without any intervening conditionals in between but X >>>> != Y, then it is not concluded that it is a loop.
DD is calling HHH(DD) in recursive simulation
and DD is not calling HHH1(DD) in recursive
simulation.
Yes, clearly; yet HHH1 and HHH are the same. So how can that be?
I do not believe that you do not
understand this.
Indeed, I do, of course. I'm just saying that it's an incorrect
state of affairs.
That wold be a lie.
It is like you are trying to get away with saying
that identical twins are one and the same person.
The identity of indiscernibles is an ontological principle
that states that there cannot be separate objects or entities
that have all their properties in common.
https://en.wikipedia.org/wiki/Identity_of_indiscernibles
The point is that there isn't /supposed/ to be a difference
between "DD is calls HHH" and "DD is calling HHH1".
You keep thinking in mathematical terms that abstract
away (thus simply ignore) key differences.
We (you, me, anyone else who runs the code) do see a difference.
There is no denying that.
HHH and HHH1 both see if the same function is
called from the same machine address with the
same arguments. This is true for HHH(DD) and
not true for HHH1(DD).
You believe that HHH1 is a different function from HHH because
DDD calls HHH and does not call HHH1.
You really can't be stupid enough to not see the
different execution trace.
On 11/24/2025 4:45 PM, Kaz Kylheku wrote:
Olcott maintains that the only differenc ebetween HHH1 and HHH is
that DD calls HHH and not HHH1. Obviously that is false.
That is the key difference
That is the key difference
On 11/24/2025 4:45 PM, Kaz Kylheku wrote:
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
As long as you keep lying I will keep repeating it.
To lie is to knowing post something that is false.
But if you do that about an objectively verifiable fact
that has nothing to do with yourself, but some scientific
matter, nobody in their right mind will see you as a liar.
Rather than see you as a liar, they will just assume you
are ignorant and incompetent.
What makes you think I, or Mike, or anyone here would
write something I know to be false, which would be
interpreted as ignorant, rather than dishonest?
Maybe you don't understand that nobody would do that, since
you have no problem being casually wrong yourself.
The people on comp.lang.c or comp.lang.c++ can always speak
up.
typedef int (*ptr)(); int HHH(ptr P); int HHH1(ptr P);
int DD() { int Halt_Status = HHH(DD); if (Halt_Status) HERE:
goto HERE; return Halt_Status; }
int main() { HHH(DD); HHH1(DD); }
HHH simulates DD
On 24/11/2025 22:45, Kaz Kylheku wrote:
On 2025-11-24, Mike Terry
<news.dead.person.stones@darjeeling.plus.com> wrote:
For HHH/HHH1 the issue is different - they are clearly different
algorithms since they give
different results, but it's not pointer comparison that is the
problem - it's the use of mutable
global data:˙ HHH and HHH1 each use /their own/ global variable [viz
their global trace tables]
within their algorithms.
Yes; this is an issue that I'm glossing over. HHH and HHH1 are not pure
functions since they react to this mutating state.
Multiplie instances of HHH share an execution trace buffer, allocated
by the first call to HHH.
Multiple instances of HHH1 also share an execution trace buffer distinct
from that one allocated by the first call to HHH1.
Simulations conducted by any level of HHH only feed HHH's buffer,
and simulations conducted by any level of HHH1 only feed HHH1's buffer.a
Exactly.˙ That explains why HHH and HHH1 are not proper clones of each
other [whatever PO claims], and hence why they produce different results.
On 11/25/2025 1:19 PM, Mike Terry wrote:
On 24/11/2025 22:45, Kaz Kylheku wrote:
On 2025-11-24, Mike Terry
<news.dead.person.stones@darjeeling.plus.com> wrote:
For HHH/HHH1 the issue is different - they are clearly different
algorithms since they give
different results, but it's not pointer comparison that is the
problem - it's the use of mutable
global data:˙ HHH and HHH1 each use /their own/ global variable [viz
their global trace tables]
within their algorithms.
Yes; this is an issue that I'm glossing over. HHH and HHH1 are not pure
functions since they react to this mutating state.
Multiplie instances of HHH share an execution trace buffer, allocated
by the first call to HHH.
Multiple instances of HHH1 also share an execution trace buffer distinct >>> from that one allocated by the first call to HHH1.
Simulations conducted by any level of HHH only feed HHH's buffer,
and simulations conducted by any level of HHH1 only feed HHH1's buffer.a
Exactly.˙ That explains why HHH and HHH1 are not proper clones of each
other [whatever PO claims], and hence why they produce different results.
So you are really trying to get away with pretending
to be too stupid that you have no idea that recursive
simulation defines behavior that cannot terminate normally?
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Simulating termination analyzer HHH and input DD
have been a fully operational software system for
more than three years.
**Conclusion:**
HHH is Turing computable, just not a pure function.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 14 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 09:28:11 |
| Calls: | 184 |
| Files: | 21,502 |
| Messages: | 79,221 |