On 9/18/2025 10:37 AM, Kaz Kylheku wrote:
On 2025-09-18, olcott <[email protected]> wrote:
On 9/18/2025 12:42 AM, Kaz Kylheku wrote:
On 2025-09-18, olcott <[email protected]> wrote:
Maybe you should spend some time pondering this.
HHH(DD)==0 and HHH1(DD)==1 what are the details
that cause this?
I already explained it.
The details is that CALL HHH1, DD and CALL HHH, DD are treated as calls >>>> to different functions by the abort logic.
That different treatment then makes that true.
So you still just flat out don't understand
that the fact that DD calls HHH(DD) in recursive
simulation and that DD does not call HHH1 at at
makes a difference in their behavior?
I fully understand that is what /you think/ causes the difference in
behavior.
It is like you don't even know simple C.
void DDD()
{
HHH(DDD);
return;
}
HHH(DDD) simulates DDD, what comes next?
On 2025-09-18, olcott <[email protected]> wrote:
It is like you don't even know simple C.
void DDD()
{
HHH(DDD);
return;
}
This is not about the HHH1 vs HHH topic any more; you are
changing the subject.
On 9/18/2025 3:39 AM, Mikko wrote:
On 2025-09-17 07:48:56 +0000, vallor said:
On Mon, 15 Sep 2025 14:35:18 -0700, "Chris M. Thomasson"
<[email protected]> wrote in <10aa0qm$26msp$[email protected]>: >>>
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
I think not. Blowing the stack is not the same as halting...
As a matter of principle, it's part of the execution environment,
just like his partial decider simulating the code.
In his world, catching it calling itself twice without an intervening
decision is grounds to abort.
In our world, when the stack gets used up, it aborts.
True, but after the abort one cannot claim that the job is completed.
The job is not completed and the answer to the question is not known.
To say either "yes" or "no" without completing the job is a lie.
Meeting the abort criteria entails the answer of reject.
On 9/18/2025 11:21 AM, Kaz Kylheku wrote:
On 2025-09-18, olcott <[email protected]> wrote:I will get to that. We must take minimal
It is like you don't even know simple C.
void DDD()
{
HHH(DDD);
return;
}
This is not about the HHH1 vs HHH topic any more; you are
changing the subject.
steps or you will never understand.
void DDD()
{
HHH(DDD);
return;
}
HHH(DDD) simulates DDD, what comes next?
On 2025-09-18, olcott <[email protected]> wrote:
On 9/18/2025 11:21 AM, Kaz Kylheku wrote:
On 2025-09-18, olcott <[email protected]> wrote:I will get to that. We must take minimal
It is like you don't even know simple C.
void DDD()
{
HHH(DDD);
return;
}
This is not about the HHH1 vs HHH topic any more; you are
changing the subject.
steps or you will never understand.
void DDD()
{
HHH(DDD);
return;
}
HHH(DDD) simulates DDD, what comes next?
But I answered that in the same post; you just snipped it.
On 9/18/2025 12:56 PM, Kaz Kylheku wrote:
On 2025-09-18, olcott <[email protected]> wrote:
On 9/18/2025 11:21 AM, Kaz Kylheku wrote:
On 2025-09-18, olcott <[email protected]> wrote:I will get to that. We must take minimal
It is like you don't even know simple C.
void DDD()
{
HHH(DDD);
return;
}
This is not about the HHH1 vs HHH topic any more; you are
changing the subject.
steps or you will never understand.
void DDD()
{
HHH(DDD);
return;
}
HHH(DDD) simulates DDD, what comes next?
But I answered that in the same post; you just snipped it.
Yet again you did not immediately directly answer
with the next step in the execution trace of: what comes next?
Message-ID: <[email protected]>
On 9/18/2025 3:39 AM, Mikko wrote:
On 2025-09-17 07:48:56 +0000, vallor said:
On Mon, 15 Sep 2025 14:35:18 -0700, "Chris M. Thomasson"
<[email protected]> wrote in <10aa0qm$26msp$5@dont-
email.me>:
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
I think not. Blowing the stack is not the same as halting...
As a matter of principle, it's part of the execution environment,
just like his partial decider simulating the code.
In his world, catching it calling itself twice without an intervening
decision is grounds to abort.
In our world, when the stack gets used up, it aborts.
True, but after the abort one cannot claim that the job is completed.
The job is not completed and the answer to the question is not known.
To say either "yes" or "no" without completing the job is a lie.
Meeting the abort criteria entails the answer of reject.
On 9/17/2025 4:55 PM, Chris M. Thomasson wrote:
On 9/17/2025 8:44 AM, olcott wrote:
[..]
DD.HHH does not halt.
You keep trying to get away with the strawman deception.
Am I lying when I say I think you might be a bit unstable?
Ad Hominem the first resort of Pea brains.
On 9/18/2025 10:37 AM, Kaz Kylheku wrote:
On 2025-09-18, olcott <[email protected]> wrote:
On 9/18/2025 12:42 AM, Kaz Kylheku wrote:
On 2025-09-18, olcott <[email protected]> wrote:
Maybe you should spend some time pondering this.
HHH(DD)==0 and HHH1(DD)==1 what are the details
that cause this?
I already explained it.
The details is that CALL HHH1, DD and CALL HHH, DD are treated as calls >>>> to different functions by the abort logic.
That different treatment then makes that true.
So you still just flat out don't understand
that the fact that DD calls HHH(DD) in recursive
simulation and that DD does not call HHH1 at at
makes a difference in their behavior?
I fully understand that is what /you think/ causes the difference in
behavior.
It is like you don't even know simple C.
void DDD()
{
HHH(DDD);
return;
}
HHH(DDD) simulates DDD, what comes next?
On 9/17/2025 6:08 PM, olcott wrote:
On 9/17/2025 4:55 PM, Chris M. Thomasson wrote:
On 9/17/2025 8:44 AM, olcott wrote:
[..]
DD.HHH does not halt.
You keep trying to get away with the strawman deception.
Am I lying when I say I think you might be a bit unstable?
Ad Hominem the first resort of Pea brains.
Again, am I lying ?
On 9/18/2025 8:50 AM, olcott wrote:
On 9/18/2025 10:37 AM, Kaz Kylheku wrote:
On 2025-09-18, olcott <[email protected]> wrote:
On 9/18/2025 12:42 AM, Kaz Kylheku wrote:
On 2025-09-18, olcott <[email protected]> wrote:
Maybe you should spend some time pondering this.
HHH(DD)==0 and HHH1(DD)==1 what are the details
that cause this?
I already explained it.
The details is that CALL HHH1, DD and CALL HHH, DD are treated as
calls
to different functions by the abort logic.
That different treatment then makes that true.
So you still just flat out don't understand
that the fact that DD calls HHH(DD) in recursive
simulation and that DD does not call HHH1 at at
makes a difference in their behavior?
I fully understand that is what /you think/ causes the difference in
behavior.
It is like you don't even know simple C.
lol. Do you know simple BASIC?
void DDD()
{
HHH(DDD);
return;
}
HHH(DDD) simulates DDD, what comes next?
On 9/18/2025 2:43 PM, Chris M. Thomasson wrote:
On 9/17/2025 6:08 PM, olcott wrote:
On 9/17/2025 4:55 PM, Chris M. Thomasson wrote:
On 9/17/2025 8:44 AM, olcott wrote:
[..]
DD.HHH does not halt.
You keep trying to get away with the strawman deception.
Am I lying when I say I think you might be a bit unstable?
Ad Hominem the first resort of Pea brains.
Again, am I lying ?
I am much more stable than most people having fully
recovered from near death by cancer without ever
getting very perturbed.
By simply resorting to ad hominem instead of a
rebuttal on the basis of reasoning you have proved
to be a deceiver.
You have shown that you can do much better than
this on other forums.
On 2025-09-18, olcott <[email protected]> wrote:
On 9/18/2025 12:42 AM, Kaz Kylheku wrote:
On 2025-09-18, olcott <[email protected]> wrote:
Maybe you should spend some time pondering this.
HHH(DD)==0 and HHH1(DD)==1 what are the details
that cause this?
I already explained it.
The details is that CALL HHH1, DD and CALL HHH, DD are treated as calls
to different functions by the abort logic.
That different treatment then makes that true.
So you still just flat out don't understand
that the fact that DD calls HHH(DD) in recursive
simulation and that DD does not call HHH1 at at
makes a difference in their behavior?
I fully understand that is what /you think/ causes the difference in behavior.
On 9/18/2025 1:27 PM, olcott wrote:
On 9/18/2025 2:43 PM, Chris M. Thomasson wrote:
On 9/17/2025 6:08 PM, olcott wrote:
On 9/17/2025 4:55 PM, Chris M. Thomasson wrote:
On 9/17/2025 8:44 AM, olcott wrote:
[..]
DD.HHH does not halt.
You keep trying to get away with the strawman deception.
Am I lying when I say I think you might be a bit unstable?
Ad Hominem the first resort of Pea brains.
Again, am I lying ?
I am much more stable than most people having fully
recovered from near death by cancer without ever
getting very perturbed.
By simply resorting to ad hominem instead of a
rebuttal on the basis of reasoning you have proved
to be a deceiver.
You have shown that you can do much better than
this on other forums.
Again, am I lying?
On 9/18/2025 3:46 PM, Chris M. Thomasson wrote:
On 9/18/2025 1:27 PM, olcott wrote:
On 9/18/2025 2:43 PM, Chris M. Thomasson wrote:
On 9/17/2025 6:08 PM, olcott wrote:
On 9/17/2025 4:55 PM, Chris M. Thomasson wrote:
On 9/17/2025 8:44 AM, olcott wrote:
[..]
DD.HHH does not halt.
You keep trying to get away with the strawman deception.
Am I lying when I say I think you might be a bit unstable?
Ad Hominem the first resort of Pea brains.
Again, am I lying ?
I am much more stable than most people having fully
recovered from near death by cancer without ever
getting very perturbed.
By simply resorting to ad hominem instead of a
rebuttal on the basis of reasoning you have proved
to be a deceiver.
You have shown that you can do much better than
this on other forums.
Again, am I lying?
Yes.
On 9/18/2025 3:26 PM, Chris M. Thomasson wrote:
On 9/18/2025 8:50 AM, olcott wrote:
On 9/18/2025 10:37 AM, Kaz Kylheku wrote:
On 2025-09-18, olcott <[email protected]> wrote:
On 9/18/2025 12:42 AM, Kaz Kylheku wrote:
On 2025-09-18, olcott <[email protected]> wrote:
Maybe you should spend some time pondering this.
HHH(DD)==0 and HHH1(DD)==1 what are the details
that cause this?
I already explained it.
The details is that CALL HHH1, DD and CALL HHH, DD are treated as >>>>>> calls
to different functions by the abort logic.
That different treatment then makes that true.
So you still just flat out don't understand
that the fact that DD calls HHH(DD) in recursive
simulation and that DD does not call HHH1 at at
makes a difference in their behavior?
I fully understand that is what /you think/ causes the difference in
behavior.
It is like you don't even know simple C.
lol. Do you know simple BASIC?
I started programming with TI 99 4a basic
back in about 1979. It can't do recursion
so it lacks sufficient expressiveness for
making my point.
On 9/18/2025 10:37 AM, Kaz Kylheku wrote:
On 2025-09-18, olcott <[email protected]> wrote:
On 9/18/2025 12:42 AM, Kaz Kylheku wrote:
On 2025-09-18, olcott <[email protected]> wrote:
Maybe you should spend some time pondering this.
HHH(DD)==0 and HHH1(DD)==1 what are the details
that cause this?
I already explained it.
The details is that CALL HHH1, DD and CALL HHH, DD are treated as calls >>>> to different functions by the abort logic.
That different treatment then makes that true.
So you still just flat out don't understand
that the fact that DD calls HHH(DD) in recursive
simulation and that DD does not call HHH1 at at
makes a difference in their behavior?
I fully understand that is what /you think/ causes the difference in
behavior.
I have conclusively proven my point with an x86 execution
trace that you cannot understand.
In a dishonest dialogue when proof is provided that is
not understood then one uses pure bluster to maintain
one's position that has been totally refuted.
void DDD()
{
HHH(DDD);
return;
}
HHH(DDD) simulates DDD:
What is the next step in the execution trace?
simulated DDD calls HHH(DDD).
On 9/18/2025 1:37 PM, olcott wrote:
On 9/18/2025 3:26 PM, Chris M. Thomasson wrote:
On 9/18/2025 8:50 AM, olcott wrote:
On 9/18/2025 10:37 AM, Kaz Kylheku wrote:
On 2025-09-18, olcott <[email protected]> wrote:
On 9/18/2025 12:42 AM, Kaz Kylheku wrote:
On 2025-09-18, olcott <[email protected]> wrote:
Maybe you should spend some time pondering this.
HHH(DD)==0 and HHH1(DD)==1 what are the details
that cause this?
I already explained it.
The details is that CALL HHH1, DD and CALL HHH, DD are treated as >>>>>>> calls
to different functions by the abort logic.
That different treatment then makes that true.
So you still just flat out don't understand
that the fact that DD calls HHH(DD) in recursive
simulation and that DD does not call HHH1 at at
makes a difference in their behavior?
I fully understand that is what /you think/ causes the difference in >>>>> behavior.
It is like you don't even know simple C.
lol. Do you know simple BASIC?
I started programming with TI 99 4a basic
back in about 1979. It can't do recursion
so it lacks sufficient expressiveness for
making my point.
One can simulate recursion in BASIC, right?
On 2025-09-18, olcott <[email protected]> wrote:
On 9/18/2025 10:37 AM, Kaz Kylheku wrote:
On 2025-09-18, olcott <[email protected]> wrote:
So you still just flat out don't understand
that the fact that DD calls HHH(DD) in recursive
simulation and that DD does not call HHH1 at at
makes a difference in their behavior?
I fully understand that is what /you think/ causes the difference in
behavior.
I have conclusively proven my point with an x86 execution
trace that you cannot understand.
The trace confirms that there /is/ a difference. Everyone follows that
and agrees. You understand your own trace, but you don't understand the
root cause.
On 9/18/2025 4:29 PM, Kaz Kylheku wrote:
On 2025-09-18, olcott <[email protected]> wrote:
On 9/18/2025 10:37 AM, Kaz Kylheku wrote:
On 2025-09-18, olcott <[email protected]> wrote:
So you still just flat out don't understand
that the fact that DD calls HHH(DD) in recursive
simulation and that DD does not call HHH1 at at
makes a difference in their behavior?
I fully understand that is what /you think/ causes the difference in
behavior.
I have conclusively proven my point with an x86 execution
trace that you cannot understand.
The trace confirms that there /is/ a difference. Everyone follows that
and agrees. You understand your own trace, but you don't understand the
root cause.
The root cause has been common knowledge in every
computer science textbook.
That you disagree seems
to prove that you are clueless on this one point.
The root cause *HAS ALWAYS BEEN* that the
"do the opposite" code does effect HHH yet
does not effect HHH1.
The "do the opposite" code is "doing the opposite" of HHH
The "do the opposite" code is NOT "doing the opposite" of HHH1
On 2025-09-18, olcott <[email protected]> wrote:
The root cause has been common knowledge in every
computer science textbook.
The root cause *HAS ALWAYS BEEN* that the
"do the opposite" code does effect HHH yet
does not effect HHH1.
Make your abort test blind to the difference HHH and HHH1
and watch the "do the opposite" code affect HHH1.
On 9/18/2025 4:51 PM, Kaz Kylheku wrote:
On 2025-09-18, olcott <[email protected]> wrote:That is not the way that it works in textbooks.
The root cause has been common knowledge in every
computer science textbook.
The root cause *HAS ALWAYS BEEN* that the
"do the opposite" code does effect HHH yet
does not effect HHH1.
Make your abort test blind to the difference HHH and HHH1
and watch the "do the opposite" code affect HHH1.
The whole proof depends on some input D "doing the opposite"
of some halt decider H.
On 2025-09-18, olcott <[email protected]> wrote:
On 9/18/2025 4:51 PM, Kaz Kylheku wrote:
On 2025-09-18, olcott <[email protected]> wrote:That is not the way that it works in textbooks.
The root cause has been common knowledge in every
computer science textbook.
The root cause *HAS ALWAYS BEEN* that the
"do the opposite" code does effect HHH yet
does not effect HHH1.
Make your abort test blind to the difference HHH and HHH1
and watch the "do the opposite" code affect HHH1.
The whole proof depends on some input D "doing the opposite"
of some halt decider H.
Can you cite one CS textbook that uses two (2) decider functions (like
H1 and H2), which have the same definition and are argued to be
identical?
But such that a name comparison is presented which stupidly causes a different halting decision based on which one is used?
And if the textbook exists, does it argue for the correctness of this cockamamie situation, or incorrectness?
(I strongly suspect you pulled this out of your ass, not any CS text.)
On 9/18/2025 1:37 PM, olcott wrote:[...]
I started programming with TI 99 4a basic
back in about 1979. It can't do recursion
so it lacks sufficient expressiveness for
making my point.
One can simulate recursion in BASIC, right?
On 9/18/2025 2:16 PM, Chris M. Thomasson wrote:
On 9/18/2025 1:37 PM, olcott wrote:[...]
I started programming with TI 99 4a basic
back in about 1979. It can't do recursion
so it lacks sufficient expressiveness for
making my point.
One can simulate recursion in BASIC, right?
You never simulated recursion in BASIC before?
On 9/18/2025 7:07 PM, Kaz Kylheku wrote:
On 2025-09-18, olcott <[email protected]> wrote:
On 9/18/2025 4:51 PM, Kaz Kylheku wrote:
On 2025-09-18, olcott <[email protected]> wrote:That is not the way that it works in textbooks.
The root cause has been common knowledge in every
computer science textbook.
The root cause *HAS ALWAYS BEEN* that the
"do the opposite" code does effect HHH yet
does not effect HHH1.
Make your abort test blind to the difference HHH and HHH1
and watch the "do the opposite" code affect HHH1.
The whole proof depends on some input D "doing the opposite"
of some halt decider H.
Can you cite one CS textbook that uses two (2) decider functions (like
H1 and H2), which have the same definition and are argued to be
identical?
It is common knowledge that the input that one HP proof
decider cannot decide can be decided by another.
On 2025-09-19, olcott <[email protected]> wrote:
It is common knowledge that the input that one HP proof
decider cannot decide can be decided by another.
But if we have apparently two deciders, which turn out to be
the same function, then we do not actually have two deciders;
they are one decider referenced by two names.
It doesn't make a difference which name the diagonal case uses;
there is only one decider and one diagonal case.
Since there aren't two deciders there, it cannot be that one decides something that the other doesn't; there is one one and the other,
just the one.
If, in consideration of the situation of two identical deciders with different names, you write some program code to explore the situation,
and your two identical deciders are not behaving identically in your
program, alarm bells should go off! This is not something to celebrate.
Whether or not two values are equal in programming is determined by one thing: the equality comparison operator/function that we use. That
choice may or may not be aligned with the nature of the objects being compared.
In your abort detection logic, you compare functions, so you have
made a certain choice on what it means for functions to be the same.
On 9/18/2025 9:16 PM, Kaz Kylheku wrote:
On 2025-09-19, olcott <[email protected]> wrote:
It is common knowledge that the input that one HP proof
decider cannot decide can be decided by another.
But if we have apparently two deciders, which turn out to be
the same function, then we do not actually have two deciders;
they are one decider referenced by two names.
It doesn't make a difference which name the diagonal case uses;
there is only one decider and one diagonal case.
So when we use another otherwise identical decider
on the same input we no longer have the diagonal case.
DD is defined to "do the opposite of" whatever HHH reports.
DD is NOT defined to "do the opposite of" whatever HHH1 reports.
A brilliant guy that doesn't understand this is like Einstein
rejecting quantum theory: "God does not play dice with the universe"
Since there aren't two deciders there, it cannot be that one decides
something that the other doesn't; there is one one and the other,
just the one.
There are two deciders.
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
If, in consideration of the situation of two identical deciders with
different names, you write some program code to explore the situation,
and your two identical deciders are not behaving identically in your
program, alarm bells should go off! This is not something to celebrate.
Because DD is defined to "do the opposite" of what HHH reports.
and DD is NOT defined to "do the opposite" of what HHH1 reports.
HHH and HHH1 are at different machine addresses and the x86
code only uses the machine address to make it call.
On 2025-09-19, olcott <[email protected]> wrote:
On 9/18/2025 9:16 PM, Kaz Kylheku wrote:
On 2025-09-19, olcott <[email protected]> wrote:
It is common knowledge that the input that one HP proof
decider cannot decide can be decided by another.
But if we have apparently two deciders, which turn out to be
the same function, then we do not actually have two deciders;
they are one decider referenced by two names.
It doesn't make a difference which name the diagonal case uses;
there is only one decider and one diagonal case.
So when we use another otherwise identical decider
on the same input we no longer have the diagonal case.
"otherwise identical" means "identical in some properties, but
not identical ino thers", which means "not identical".
/Something/ has to be differenet about the other decider so
that it is off the diagonal with respect to that DD input.
It can't just be the name by which are referring to it.
A function name is the same as a variable name: name
for an entity.
If the variables x and y both hold 3, they are not different.
And f(a):a + x is not a different function from g(b):b + y.
In math we would be justified in writing f = g.
(And one interpretation that would have is that for
every single domain value d f(d) = g(d).)
But in C, f == g would be false for two different definitions
of exactly the same function. It is not the f = g
at all. Pointer equality is not function equality.
DD is defined to "do the opposite of" whatever HHH reports.
DD is NOT defined to "do the opposite of" whatever HHH1 reports.
If you ensure that HHH1 is regarded as equivalent to HHH, then in fact
DD is defined to do the opposite of HHH1, even though it's referencing
the HHH name. The underlying function is the same, through two
different names.
You've not done everything that is required for HHH and HHH1 to be the
same. You've given them the same argument list and body, but you've not ensured that you are using an equality operation which reports that they
are the same.
A brilliant guy that doesn't understand this is like Einstein
rejecting quantum theory: "God does not play dice with the universe"
Why don't you understand that comparing function pointers is not
a valid function equivalence?
It is correct when it reports true! Because F == F, right?
Same pointer on both sides must be the same function.
It is not always correct when it reports false.
This comparison being false is correct:
#include <math.h>
sin == cos
This one is a false negative:
HHH == HHH1
Since there aren't two deciders there, it cannot be that one decides
something that the other doesn't; there is one one and the other,
just the one.
There are two deciders.
If it is your /intent/ that HHH and HHH1 are not the same, why did you
give them the same body? Just define them so that they are different calculations.
And then, drop all rhetoric that insinuates that they are the same.
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
This is true and important. But by itself it doesn't help us.
Because inside a ocmputing machine, entities are often easily
discernible which we must not treat as discernible.
An easy example are strings. If you write some little database
program in C and ask it to look for the record whose name is
"Bob", it cannot use "name == record->name" for the matching,
right?
The "Bob" key that isnput and the "Bob" in record->name
/are/ discernible according to the ontological principle.
They each have a different address in the machine.
But we must treat them as indiscernible.
If, in consideration of the situation of two identical deciders with
different names, you write some program code to explore the situation,
and your two identical deciders are not behaving identically in your
program, alarm bells should go off! This is not something to celebrate.
Because DD is defined to "do the opposite" of what HHH reports.
and DD is NOT defined to "do the opposite" of what HHH1 reports.
HHH and HHH1 are at different machine addresses and the x86
code only uses the machine address to make it call.
The C language specification does not actually require HHH and HHH1
to be at different machine addresses. The implemntation can recognize
that the functions are the same and merge them into a single
implementation, such that HHH1 == HHH.
In the GNU world, I think to get this optimization to happen
you have to compile with -ffunction-sections to compartmentalize
functions in separate sections, and then use the --icf=all
option of the Gold Linker. (ICF means "identical code folding").
https://en.wikipedia.org/wiki/Gold_(linker)
On 9/18/2025 1:15 PM, Kaz Kylheku wrote:
Message-ID: <[email protected]>
*My superpower is an OCD level of persistence*
void DDD()
{
HHH(DDD);
return;
}
HHH(DDD) simulates DDD, what is the next step
in the execution trace?
THE NEXT STEP AND ONLY THE NEXT STEP IN THE EXECUTION TRACE
WHEN YOU GO MORE THAN ONE SINGLE STEP YO GET IT WRONG.
On 9/18/2025 3:39 AM, Mikko wrote:
On 2025-09-17 07:48:56 +0000, vallor said:
On Mon, 15 Sep 2025 14:35:18 -0700, "Chris M. Thomasson"
<[email protected]> wrote in <10aa0qm$26msp$[email protected]>: >>>
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
I think not. Blowing the stack is not the same as halting...
As a matter of principle, it's part of the execution environment,
just like his partial decider simulating the code.
In his world, catching it calling itself twice without an intervening
decision is grounds to abort.
In our world, when the stack gets used up, it aborts.
True, but after the abort one cannot claim that the job is completed.
The job is not completed and the answer to the question is not known.
To say either "yes" or "no" without completing the job is a lie.
Meeting the abort criteria entails the answer of reject.
On 9/18/2025 10:33 PM, Kaz Kylheku wrote:Ok, so HHH and HHH1 differ.
On 2025-09-19, olcott <[email protected]> wrote:
On 9/18/2025 9:16 PM, Kaz Kylheku wrote:
On 2025-09-19, olcott <[email protected]> wrote:
So when we use another otherwise identical decider on the same input
we no longer have the diagonal case.
What's your point if HHH and HHH1 are not identical?DD is defined to "do the opposite of" whatever HHH reports.
DD is NOT defined to "do the opposite of" whatever HHH1 reports.
lol no. Or stop claiming HHH and HHH1 are identical.Why don't you understand that comparing function pointers is not aBecause it is a matter of verifiable objective fact that it is.
valid function equivalence?
HHH and HHH1 don't have their address in common.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
Then you are depending on implementation details.That is not the case with my code. I turn off all optimizations.Because DD is defined to "do the opposite" of what HHH reports.The C language specification does not actually require HHH and HHH1 to
and DD is NOT defined to "do the opposite" of what HHH1 reports.
HHH and HHH1 are at different machine addresses and the x86 code only
uses the machine address to make it call.
be at different machine addresses. The implemntation can recognize that
the functions are the same and merge them into a single implementation,
such that HHH1 == HHH.
Am Thu, 18 Sep 2025 23:13:20 -0500 schrieb olcott:
On 9/18/2025 10:33 PM, Kaz Kylheku wrote:
On 2025-09-19, olcott <[email protected]> wrote:
On 9/18/2025 9:16 PM, Kaz Kylheku wrote:
On 2025-09-19, olcott <[email protected]> wrote:
Ok, so HHH and HHH1 differ.So when we use another otherwise identical decider on the same input
we no longer have the diagonal case.
On 9/19/2025 4:12 AM, joes wrote:
Am Thu, 18 Sep 2025 23:13:20 -0500 schrieb olcott:
On 9/18/2025 10:33 PM, Kaz Kylheku wrote:Ok, so HHH and HHH1 differ.
On 2025-09-19, olcott <[email protected]> wrote:
On 9/18/2025 9:16 PM, Kaz Kylheku wrote:
On 2025-09-19, olcott <[email protected]> wrote:
So when we use another otherwise identical decider on the
same input
we no longer have the diagonal case.
It almost like I am talking to people that are brain dead
DD calls HHH(DD) in recursive simulation
DD DOES NOT call HHH1() at all.
I have said this thousands of times now. WTF is wrong with you?
On 19/09/2025 16:06, olcott wrote:
On 9/19/2025 4:12 AM, joes wrote:
Am Thu, 18 Sep 2025 23:13:20 -0500 schrieb olcott:
On 9/18/2025 10:33 PM, Kaz Kylheku wrote:Ok, so HHH and HHH1 differ.
On 2025-09-19, olcott <[email protected]> wrote:
On 9/18/2025 9:16 PM, Kaz Kylheku wrote:
On 2025-09-19, olcott <[email protected]> wrote:
So when we use another otherwise identical decider on the same input >>>>>> we no longer have the diagonal case.
It almost like I am talking to people that are brain dead
For a genius such as yourself, that must surely just be part of the
daily round?
DD calls HHH(DD) in recursive simulation
Well, no. DD calls HHH, but at no point does HHH call DD.
DD DOES NOT call HHH1() at all.
Agreed.
I have said this thousands of times now. WTF is wrong with you?
Perhaps he's not in the top 97% like you?
On 9/19/2025 10:22 AM, Richard Heathfield wrote:
On 19/09/2025 16:06, olcott wrote:
On 9/19/2025 4:12 AM, joes wrote:
Am Thu, 18 Sep 2025 23:13:20 -0500 schrieb olcott:
On 9/18/2025 10:33 PM, Kaz Kylheku wrote:Ok, so HHH and HHH1 differ.
On 2025-09-19, olcott <[email protected]> wrote:
On 9/18/2025 9:16 PM, Kaz Kylheku wrote:
On 2025-09-19, olcott <[email protected]> wrote:
So when we use another otherwise identical decider on the
same input
we no longer have the diagonal case.
It almost like I am talking to people that are brain dead
For a genius such as yourself, that must surely just be part of
the daily round?
DD calls HHH(DD) in recursive simulation
Well, no. DD calls HHH, but at no point does HHH call DD.
void H()
{
D();
}
void D()
{
H();
}
In other words you are too stupid to understand
that when HHH simulates DD that this has the same
control flow effect as HHH calling DD() ???
DD DOES NOT call HHH1() at all.
Agreed.
I have said this thousands of times now. WTF is wrong with you?
Perhaps he's not in the top 97% like you?
Joes is female. I estimate that Joes is shorthand
for Josephine rather than plural for Joe.
On 9/19/2025 10:22 AM, Richard Heathfield wrote:
Well, no. DD calls HHH, but at no point does HHH call DD.void H()
{
D();
}
void D()
{
H();
}
In other words you are too stupid to understand that when HHH simulates
DD that this has the same control flow effect as HHH calling DD() ???
I have only requested not to be assumed male.Perhaps he's not in the top 97% like you?Joes is female. I estimate that Joes is shorthand for Josephine rather
than plural for Joe.
On 19/09/2025 17:20, olcott wrote:
On 9/19/2025 10:22 AM, Richard Heathfield wrote:
On 19/09/2025 16:06, olcott wrote:
On 9/19/2025 4:12 AM, joes wrote:
Am Thu, 18 Sep 2025 23:13:20 -0500 schrieb olcott:
On 9/18/2025 10:33 PM, Kaz Kylheku wrote:Ok, so HHH and HHH1 differ.
On 2025-09-19, olcott <[email protected]> wrote:
On 9/18/2025 9:16 PM, Kaz Kylheku wrote:
On 2025-09-19, olcott <[email protected]> wrote:
So when we use another otherwise identical decider on the same >>>>>>>> input
we no longer have the diagonal case.
It almost like I am talking to people that are brain dead
For a genius such as yourself, that must surely just be part of the
daily round?
DD calls HHH(DD) in recursive simulation
Well, no. DD calls HHH, but at no point does HHH call DD.
void H()
{
D();
}
void D()
{
H();
}
Yes, that's mutual recursion.
But HHH() doesn't call DD, so the recursion is not mutual.
In other words you are too stupid to understand
that when HHH simulates DD that this has the same
control flow effect as HHH calling DD() ???
No, it doesn't. Partly this is because HHH doesn't simulate DD
If joes would rather we used 'she' I have no doubt he, or she, is
capable of letting us know all by him- or possible herself. Until he (or she) does, I will continue to assume that joes stands for Joe S.
Am Fri, 19 Sep 2025 11:20:38 -0500 schrieb olcott:
On 9/19/2025 10:22 AM, Richard Heathfield wrote:
Well, no. DD calls HHH, but at no point does HHH call DD.void H()
{
D();
}
void D()
{
H();
}
In other words you are too stupid to understand that when HHH simulates
DD that this has the same control flow effect as HHH calling DD() ???
H can't abort.
I have only requested not to be assumed male.Perhaps he's not in the top 97% like you?Joes is female. I estimate that Joes is shorthand for Josephine rather
than plural for Joe.
On 9/19/2025 4:12 AM, joes wrote:
Am Thu, 18 Sep 2025 23:13:20 -0500 schrieb olcott:
On 9/18/2025 10:33 PM, Kaz Kylheku wrote:Ok, so HHH and HHH1 differ.
On 2025-09-19, olcott <[email protected]> wrote:
On 9/18/2025 9:16 PM, Kaz Kylheku wrote:
On 2025-09-19, olcott <[email protected]> wrote:
So when we use another otherwise identical decider on the same input >>>>> we no longer have the diagonal case.
It almost like I am talking to people that are brain dead
DD calls HHH(DD) in recursive simulation
DD DOES NOT call HHH1() at all.
I have said this thousands of times now. WTF is wrong with you?
I have only requested not to be assumed male.
On 9/19/2025 11:34 AM, Richard Heathfield wrote:
On 19/09/2025 17:20, olcott wrote:
On 9/19/2025 10:22 AM, Richard Heathfield wrote:
On 19/09/2025 16:06, olcott wrote:
On 9/19/2025 4:12 AM, joes wrote:
Am Thu, 18 Sep 2025 23:13:20 -0500 schrieb olcott:
On 9/18/2025 10:33 PM, Kaz Kylheku wrote:Ok, so HHH and HHH1 differ.
On 2025-09-19, olcott <[email protected]> wrote:
On 9/18/2025 9:16 PM, Kaz Kylheku wrote:
On 2025-09-19, olcott <[email protected]> wrote:
So when we use another otherwise identical decider on
the same input
we no longer have the diagonal case.
It almost like I am talking to people that are brain dead
For a genius such as yourself, that must surely just be part
of the daily round?
DD calls HHH(DD) in recursive simulation
Well, no. DD calls HHH, but at no point does HHH call DD.
void H()
{
D();
}
void D()
{
H();
}
Yes, that's mutual recursion.
But HHH() doesn't call DD, so the recursion is not mutual.
In other words you are too stupid to understand
that when HHH simulates DD that this has the same
control flow effect as HHH calling DD() ???
No, it doesn't. Partly this is because HHH doesn't simulate DD
Ah so you are too stupid
to know that mutual recursion
may be forced to stopping running yet this does not
count as halting?
DD() would never stop running unless HHH intervened
Perhaps you still don't know that halting is only
normal termination not requiring any intervention.
On 2025-09-19, olcott <[email protected]> wrote:
On 9/19/2025 4:12 AM, joes wrote:
Am Thu, 18 Sep 2025 23:13:20 -0500 schrieb olcott:
On 9/18/2025 10:33 PM, Kaz Kylheku wrote:Ok, so HHH and HHH1 differ.
On 2025-09-19, olcott <[email protected]> wrote:
On 9/18/2025 9:16 PM, Kaz Kylheku wrote:
On 2025-09-19, olcott <[email protected]> wrote:
So when we use another otherwise identical decider on the same input >>>>>> we no longer have the diagonal case.
It almost like I am talking to people that are brain dead
DD calls HHH(DD) in recursive simulation
HHH(DD) returns pretty soon, after simulating just two calls to the same address, without seeing a conditional jump.
Once returns, the recursive simulation depth stops growing.
DD DOES NOT call HHH1() at all.
That's simply because your system treats HHH1 and HHH
as different functions.
Your system treats two functions as unconditionally different if they
reside at different addresses. It doesn't matter that they have
identical code. (It's as if relocating a boot loader into high memory
makes it a different boot loader.)
On 9/19/2025 10:22 AM, Richard Heathfield wrote:
On 19/09/2025 16:06, olcott wrote:
On 9/19/2025 4:12 AM, joes wrote:
Am Thu, 18 Sep 2025 23:13:20 -0500 schrieb olcott:
On 9/18/2025 10:33 PM, Kaz Kylheku wrote:Ok, so HHH and HHH1 differ.
On 2025-09-19, olcott <[email protected]> wrote:
On 9/18/2025 9:16 PM, Kaz Kylheku wrote:
On 2025-09-19, olcott <[email protected]> wrote:
So when we use another otherwise identical decider on the same input >>>>>>> we no longer have the diagonal case.
It almost like I am talking to people that are brain dead
For a genius such as yourself, that must surely just be part of the
daily round?
DD calls HHH(DD) in recursive simulation
Well, no. DD calls HHH, but at no point does HHH call DD.
void H()
{
D();
}
void D()
{
H();
}
In other words you are too stupid to understand
that when HHH simulates DD that this has the same
control flow effect as HHH calling DD() ???
Joes is female. I estimate that Joes is shorthand
for Josephine rather than plural for Joe.
On 9/19/2025 11:34 AM, Richard Heathfield wrote:
On 19/09/2025 17:20, olcott wrote:
On 9/19/2025 10:22 AM, Richard Heathfield wrote:
On 19/09/2025 16:06, olcott wrote:
On 9/19/2025 4:12 AM, joes wrote:
Am Thu, 18 Sep 2025 23:13:20 -0500 schrieb olcott:
On 9/18/2025 10:33 PM, Kaz Kylheku wrote:Ok, so HHH and HHH1 differ.
On 2025-09-19, olcott <[email protected]> wrote:
On 9/18/2025 9:16 PM, Kaz Kylheku wrote:
On 2025-09-19, olcott <[email protected]> wrote:
So when we use another otherwise identical decider on the same >>>>>>>>> input
we no longer have the diagonal case.
It almost like I am talking to people that are brain dead
For a genius such as yourself, that must surely just be part of the
daily round?
DD calls HHH(DD) in recursive simulation
Well, no. DD calls HHH, but at no point does HHH call DD.
void H()
{
D();
}
void D()
{
H();
}
Yes, that's mutual recursion.
But HHH() doesn't call DD, so the recursion is not mutual.
In other words you are too stupid to understand
that when HHH simulates DD that this has the same
control flow effect as HHH calling DD() ???
No, it doesn't. Partly this is because HHH doesn't simulate DD
Ah so you are too stupid to know that mutual recursion
may be forced to stopping running yet this does not
count as halting?
DD() would never stop running unless HHH intervened
on its second recursive call.
On 9/19/2025 12:23 PM, Kaz Kylheku wrote:
That's simply because your system treats HHH1 and HHH
as different functions.
void H1()
{
D();
}
void H()
{
D();
}
void D()
{
H();
}
Your system treats two functions as unconditionally different if they
reside at different addresses. It doesn't matter that they have
identical code. (It's as if relocating a boot loader into high memory
makes it a different boot loader.)
That you still cannot understand that when HHH simulates
DD, this has the same control flow behavior as HHH calling
DD() seems to be intentional deception on your part.
On 9/18/2025 8:31 PM, Chris M. Thomasson wrote:
On 9/18/2025 2:16 PM, Chris M. Thomasson wrote:
On 9/18/2025 1:37 PM, olcott wrote:[...]
I started programming with TI 99 4a basic
back in about 1979. It can't do recursion
so it lacks sufficient expressiveness for
making my point.
One can simulate recursion in BASIC, right?
You never simulated recursion in BASIC before?
I only want to talk about my C function.
On 9/19/2025 11:34 AM, Richard Heathfield wrote:
On 19/09/2025 17:20, olcott wrote:
Ah so you are too stupid to know that mutual recursion may be forced to stopping running yet this does not count as halting?In other words you are too stupid to understand that when HHHNo, it doesn't. Partly this is because HHH doesn't simulate DD
simulates DD that this has the same control flow effect as HHH calling
DD() ???
Yes. That's not what it stands for, though.If joes would rather we used 'she' I have no doubt he, or she, is
capable of letting us know all by him- or possible herself. Until he
(or she) does, I will continue to assume that joes stands for Joe S.
I proved that DD is correctly simulated by HHH up to the point where DDExactly, up to the point, and then not anymore. Like you live forever
has met its non-halting criteria.
On 9/19/2025 11:34 AM, Richard Heathfield wrote:
Recursion cannot be stopped from the outside like simulation can.
Yes. That's not what it stands for, though.If joes would rather we used 'she' I have no doubt he, or she, is
capable of letting us know all by him- or possible herself. Until he
(or she) does, I will continue to assume that joes stands for Joe S.
On 2025-09-19, olcott <[email protected]> wrote:
Ah so you are too stupid to know that mutual recursion
may be forced to stopping running yet this does not
count as halting?
No, under recursion, a caller cannot force its callee to stop.
The caller's instruction pointer (or whatever is its equivalent)
has passed into the callee and will not be back until the callee
voluntarily returns.
Simulation is not a function call. The simulator retains
all control flow.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,070 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 252:41:29 |
| Calls: | 13,738 |
| Calls today: | 1 |
| Files: | 186,970 |
| D/L today: |
3,666 files (1,075M bytes) |
| Messages: | 2,419,465 |