On 5/14/25 11:42 PM, olcott wrote:
On 5/14/2025 10:14 PM, Richard Damon wrote:
On 5/14/25 11:02 PM, olcott wrote:
On 5/14/2025 9:54 PM, Richard Damon wrote:
On 5/14/25 9:30 PM, olcott wrote:
void DDD()
{
HHH(DDD);
return;
}
int main()
{
DDD();
}
If HHH cannot report on the behavior of its caller
because this is a ridiculous requirement then how
can HHH report on the direct execution of DDD()
(AKA its caller).
Because it is given the code of DDD, and thus doesn't need to know
about "It caller"
Unless it does know about its caller
The only directly executed DDD() that actually exists
no HHH can possibly know about any directly executed DDD().
So, how does it know that?
How does that knowledge affect the answer?
The HHH relative to any directly executed DDD is
only HHH called by this DDD. It has always been
stupid to require HHH to report on its caller.
The requirement for a halt decider to report on
the direct execution of its input is proven to
be stupidly wrong whenever this input calls
this decider because no C function can report
on its caller.
All you are doing is proving you don't understand what you are talking
about.
The "Directly Execution of DDD" is in one respect just a theoretical
concept, we don't need to have actually executed it in the past, or even
in the future. It is what that sequence of algorithmic steps, when/if we perform them, would do. Because those algorithmic steps are precisely
and definitively defined, that behavior is fully determined, and that
result is independent of if we actually run it or not.
It seems, this is just to abstract for your tiny mind. That something
can have a true value even if we don't know it.
Thus, HHH is not being asked about its caller, its being asked about its
input, which is a valid question, That input, if properly formed from
the program in question, will fully define the algorithm that the
program it represents will do, and thus fully specifies what that
program will do when it is run.
This is one reason the DDD can't just be a non-leaf function, as such a
thing isn't a program with all of its algorithm speccified, and thus
doesn't have halting behavior, and we can't form the input to describe
the algorithm if it isn't there in the program.
Yes, in the somewhat ill-defined system you are using, we could executed
DDD, and it will start to try to use instructions that were not part of
it, at which point we need to have defined what this means,
Either we say that DDD was strictly the code we said, and nothing else,
at which point the "execution" of DDD just fails to be defined, as we
violated or definitions of what DDD was.
Or we can say we allow it to access that memory, at which point to build
up the representation of the algorithm of DDD, we needed to include the contents of that memory, or have stipulated the exact behavior that code
will do (in effect, including that code in the axioms of your system).
Both of these mean that you can't change that code, as it has been
defined by your input or the axioms of the system.
Thus, since your HHH doesn't actually do a correct simulation of the
input (since you show that in the universe where that was defined to be
a non-aborting HHH, it will never answer, so can't be what you are now
defining as that answers) and thus HHH answering about the correct
simulation of its input by HHH is nonsense, refering to a condition that doesn't happen. It needs some memory locations to hold two different
contents at once to make the one program HHH have two different behaviors,
Sorry, you are just showing how broken you logic actually is.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)