Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD)

On 5/8/2025 11:22 PM, Keith Thompson wrote:

Richard Damon <news.x.richarddamon@xoxy.net> writes:

On 5/8/25 10:23 PM, Keith Thompson wrote:

Richard Damon <richard@damon-family.org> writes:

On 5/8/25 7:53 PM, olcott wrote:

[...]

void DDD()
{
     HHH(DDD);
     return;
}
We don't need to look at any of my code for me
to totally prove my point. For example when
the above DDD is correctly simulated by HHH
this simulated DDD cannot possibly reach its own
"return" instruction.

>
And thus not correctly simulatd.
>
Sorry, there is no "OS Exemption" to correct simulaiton;.

Perhaps I've missed something.  I don't see anything in the above
that
implies that HHH does not correctly simulate DDD.  Richard, you've read
far more of olcott's posts than I have, so perhaps you can clarify.
If we assume that HHH correctly simulates DDD, then the above code
is
equivalent to:
      void DDD()
      {
        DDD();
        return;
      }
which is a trivial case of infinite recursion.  As far as I can
tell,
assuming that DDD() is actually called at some point, neither the
outer execution of DDD nor the nested (simulated) execution of DDD
can reach the return statement.  Infinite recursion might either
cause a stack overflow and a probable program crash, or an unending
loop if the compiler implements tail call optimization.
I see no contradiction, just an uninteresting case of infinite
recursion, something that's well understood by anyone with a
reasonable level of programming experience.  (And it has nothing to
do with the halting problem as far as I can tell, though of course
olcott has discussed the halting problem elsewhere.)
Richard, what am I missing?
>

>
You are missing the equivocation he is using on what is "DDD()"
>
First, he tries to define it as just the code of the function, and not
including any of the code that it calls. He does this so all the
various HHH that he talks about are given the "same" input.
>
Then he tries to also say that when those functions look at DDD, they
can follow the memory chain to the functions that it calls, that
weren't actually part of the input.
>
This means the "behavior" of his input isn't actually defined by the input.

 I haven't seen any of that in the posts to which I've recently replied
(and I absolutely do not have the patience to read everything he's
posted here).
 What I've seen in the articles to which I've recently replied has been
just a strangely little C function and some claims about simulation.
Viewed in isolation, I don't think any of that (again, ignoring the vast
majority of what he's posted in this newsgroup) seems contradictory so far.
 

He has also, to get around other objections about what he is doing,
stipulated that his functions must be pure functions, and thus only
dependent on their direct input, other wise we can add the following
code to the beginning of HHH to make his statement false:

 I've seen no mention of pure functions in the posts to which I've
recently replied.
 [...]
 

You are seeing some of the same misdirection that I have been seeing.
Most people here change the subject when they come across difficult
and crucial material.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer