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

On 5/8/25 11:34 PM, olcott wrote:

On 5/8/2025 10:14 PM, Mike Terry wrote:

On 09/05/2025 03:13, olcott wrote:

On 5/8/2025 8:30 PM, Keith Thompson wrote:

olcott <polcott333@gmail.com> writes:

On 5/8/2025 6:49 PM, Keith Thompson wrote:

olcott <polcott333@gmail.com> writes:
[...]

void DDD()
{
    HHH(DDD);
    return;
}
>
If you are a competent C programmer then you
know that DDD correctly simulated by HHH cannot
possibly each its own "return" instruction.

"cannot possibly each"?
I am a competent C programmer (and I don't believe you can make
the same claim).  I don't know what HHH is.  The name "HHH" tells
me nothing about what it's supposed to do.  Without knowing what
HHH is, I can't say much about your code (or is it pseudo-code?).
>

>
For the purpose of this discussion HHH is exactly
what I said it is. It correctly simulates DDD.

>
Does HHH correctly simulate DDD *and do nothing else*?
>
Does HHH correctly simulate *every* function whose address is passed
to it?  Must the passed function be one that takes no arguments
and does not return a value?
>
Can HHH just *call* the function whose address is passed to it?
If it's a correct simulation, there should be no difference between
calling the function and "correctly simulating" it.
>
My knowledge of C tells me nothing about *how* HHH might simulate
DDD.
>

>
HHH can only simulate a function that take no arguments
and has no return value. HHH also simulates the entire
chain of functions that this function calls. These can
take arguments or not and have return values or not.
>
Thus HHH ends up simulating itself (and everything
that HHH calls) simulating DDD in an infinite
sequence of recursive emulation until OOM error.
>

We need not know anything else about HHH to
know that DDD correctly simulated by HHH cannot
possibly REACH its own "return" instruction.

>
Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
does nothing else, your code would be equivalent to this:
>
     void DDD(void) {
         DDD();
         return;
     }
>

>
Exactly. None of these people on comp.theory could
get that even after three years.
>

>
PO is being quite deceptive here.
>

 I am only referring to the above hypothetical HHH/DDD pair.
Everyone here has consistently denied that when DDD is
correctly simulated by HHH that this DDD cannot possibly
reach its "return" instruction (final halt state).

But that HHH isn't the required pure function that correctly emulate the input, as the input has been clearly defined to be JUST the code of the function DDD, and thus the call instruction can't be emulated as the instruction it references isn't in the input.
When you include the input, then DDD become a DDD/HHH pair, and thus the input for this hypotherical HHH is processing a different input than the input you are going to give to your actual HHH, and thus says nothing about it.
If you fix your statements so that it is clear that "the input" includes all of that memroy, we might be able to deal with THIS statement, but then you can't get to your next one.
And, if you remove the pure requirement, my version of HHH that uses the static flag proves your claim is just incorrect in the relaxed case.

 

His simulation is in fact a single-stepped x86 instruction simulation, where the stepping of each x86 instruction is under the HHH's control. HHH can continue stepping the simulation until its target returns, in which case the situation is logically just like direct call, as you have described.  Or HHH could step just 3 x86 instructions (say) and then decide to return (aka "abort" its simulation).  Let's call that / partial/ simulation in contrast with /full/ simulation which you've been supposing.
>

 A full simulation of infinite recursion?
I am only doing one tiny idea at a time here.

Sure, if that is what is there.
The fact that you HHH can't get by the call instruction and still meet the defintions, since you have been excluding that code as "part of the input" and just "in the system".

 

Oh, did he forget to mention that?  Anyhow, in the general case with / partial/ simulation there is more to think about as it is obvioudly / not/ logically equivalent to direct execution.
>

 That is changing the subject away from
DDD correctly simulated by HHH.

Which doesn't happen within your definitions.

 

>
Oh, and obviously everybody in comp.theory gets all this.  The problem is with PO and his inability to communicate his ideas properly and his inability to understand what other people understand or disagree with. He goes on for months/years claiming people don't understand things they agree with, but it's down to his duffer wording...
>

Then the return statement (which is unnecessary anyway) will never be
reached.

>
It is only there to mark a final halt state.
>

In practice, the program will likely crash due to a stack
overflow, unless the compiler implements tail-call optimization, in
which case the program might just run forever -- which also means the
unnecessary return statement will never be reached.
>

>
Yes you totally have this correctly.
None of the dozens of comp.theory people could
ever achieve that level of understanding even
after three years. That is why I needed to post
on comp.lang.c.

>
Everybody on comp.theory understands this much.

 No one here ever agreed that when 1 or more
instructions of DDD are correctly simulated
by HHH that DDD cannot possibly reach its
own "return" instruction.

Because that is just a false phrase. Your HHH can not correctly emulate past the call HHH instruction (and still be the requried pure function) as the code there isn't part of what you have defined as the input.

 Everyone has found one excuse or another to
deny this.

Only by pointing out your errors.

 

PO's plan is that when he goes elsewhere he can start with noobies and trick them into agreeing with certain "wordings" by not explaining relevent context for his questions.  Then he goes back to comp.theory and triumphantly claims support from elsewhere, proving to himself that comp.theory posters are all idiots.  :)
>
So beware!
>

>

This conclusion relies on my understanding of what you've said about
your code, which I consider to be unreliable.

>
Hmm, did PO make it clear that when he says
>
    "..DDD correctly simulated by HHH cannot
     possibly REACH its own "return" instruction."
>

 Unless we go one tiny step at a time everyone
permanently leaps to a false conclusion and stays
there.

The problem is you are trying to hide your errors in the ambiquity of equivocation,

 

he is not talking about whether "DDD halts"?  [I.e. halts when run directly from main() outside of a simulator.]  No, what he is talking about is whether the /step-by-step partial simuation/ of DDD performed by HHH proceeds as far as DDD returning.

 When 1 or more steps of DDD are correctly simulated
by HHH the simulated DDD cannot possibly reach its
"return" instruction (final halt state).

And HHH can't correctly emulate its input past the call instruction, as the code past there isn't part of the input.
Are you really that dense?

 No one here has agreed to that. Not in several
years of coaxing and elaboration.

Because it isn't true under your stipulations.

 

 Don't forget - HHH is allowed to simply stop simulating and return whenever it likes!  Maybe it only wants to simulate 48 x86 instructions, or just 1, or maybe it's in for the long haul and simulates until DDD returns [if it ever does].
>

 When 1 or more steps of DDD are correctly simulated
by HHH the simulated DDD cannot possibly reach its
"return" instruction (final halt state).
remains a verified fact.

No, it remains a verified LIE by category error.

 

So you need to re-analyse everything you've said with this new information that PO forgot to make clear.
>
>
Regards,
Mike.
>