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

On 5/10/25 12:21 AM, olcott wrote:

On 5/9/2025 10:31 PM, Richard Damon wrote:

On 5/9/25 11:13 PM, wij wrote:

On Fri, 2025-05-09 at 19:40 -0700, Keith Thompson wrote:

olcott <polcott333@gmail.com> writes:

On 5/9/2025 4:40 PM, Richard Heathfield wrote:

On 09/05/2025 21:15, olcott wrote:

On 5/9/2025 3:07 PM, Richard Heathfield wrote:

On 09/05/2025 20:46, olcott wrote:

We have not begun to get into any of those points.
We are only asking can DDD correctly simulated
by any HHH that can exist ever reach its own
"return" instruction.

>
DDD can't be correctly simulated by itself (which is effectively
what you're trying to do when you fire up the simulation from
inside DDD).

>
How the Hell did you twist my words to say that?

I haven't touched your words. What I have done is to observe that
DDD's /only/ action is to call a simulator. Since DDD isn't itself a
simulator, there is nothing to simulate except a call to a
simulator.
It's recursion without a base case - a rookie error.
HHH cannot successfully complete its task, because it never regains
control after the first recursion. To return, it must abort the
simulation, which means the simulation fails.
>

void DDD()
{
    HHH(DDD);
    return;
}
>
When 1 or more statements of DDD are correctly
simulated by HHH then this correctly simulated
DDD cannot possibly reach its own “return statement”.

On what grounds can you persuade an extraordinarily sceptical
readership that HHH 'correctly simulated' DDD?

>
Any competent C programmer can see that
the call from DDD to HHH(DDD) (its own simulator)
is equivalent to infinite recursion.
>
On 5/8/2025 8:30 PM, Keith Thompson wrote:

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;
      }
>
Then the return statement (which is unnecessary anyway) will never be
reached.  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.

>
I had not intended to post again, but I feel the need to make
a clarification.
>
I acknowledged that the return statement would never be reached
*given the assumption* that HHH correctly simulates DDD.  Given
that assumption, a call to DDD() should be equivalent to a call
to HHH(DDD).
>
I did not address whether the assumption is valid.  I merely
temporarily accepted it for the sake of discussion, just as I would
accept that if I were ten feet tall I would bump my head against
the ceiling in my house.
>
The discussion I had with olcott did not reach the point of
discussing *how* HHH could correctly simulate DDD, or whether it
would even be logically possible for it to do so.  I also did not
address any issues of partial simulation, where olcott claims that
HHH can "accurately simulate" only a few x86 instructions rather
than simulating its entire execution.  I did not participate in
any discussion that would require knowledge of x86 machine or
assembly code.  (I have no doubt that I could learn x86 machine
and assembly code reasonably well if motivated to do so, but I am
not so motivated.)
>
What I acknowledged was barely more than "if HHH correctly simulates
DDD, then HHH correctly simulates DDD".  (My understanding from
posts by others, whom I presume to be sufficiently knowledgeable,
is that HHH logically cannot accurately simulate DDD.)  I would
prefer that olcott refrain from using my words to support any of
his arguments beyond the scope of what he and I directly discussed.

>
Don't know why you people stick on the 'simulation' stuff so long.
The HP simply asks for such an H (in function form. POOH does not
resemble TM):
  H(D)=1 if D() halt.
  H(D)=0 if D() not halt.
>
>

>
The issue is Peter thinks that by making H a "simulating Halt Decider" or a "Simulating Termination Analyzer" it can change the definition, by trying to put out a lying definition of Halting by lying about the definition of correct simulation and what is the input.

 It is a stupid idea that halt deciders must be either
infallible or wrong so I switched to termination analyzers.

Which also must be infallible or wrong as a total program. Just like halt deciders, PARTIAL deciders are possible, and effort goes into how good we can do. It is perhaps more useful to know termination analysis, as we rarely run a program on just a single input as the Halting Problem answers so better to spend the effort to attempt termination analysis where we hope to get a range of inputs that the program can be shown that it will give an answer.

 A termination analyzer is correct if it can process a
single input that itself has no inputs.
 

Nope. Show your definition.
The one I am using is experessed at:
https://en.wikipedia.org/wiki/Termination_analysis
In computer science, termination analysis is program analysis which attempts to determine whether the evaluation of a given program halts for each input. This means to determine whether the input program computes a total function.
It is closely related to the halting problem, which is to determine whether a given program halts for a given input and which is undecidable. The termination analysis is even more difficult than the halting problem: the termination analysis in the model of Turing machines as the model of programs implementing computable functions would have the goal of deciding whether a given Turing machine is a total Turing machine,
Note, just like A Halt Decider, it needs to decide CORRECTLY (to be correct) for whatever program is given. Not just for "a" input.
Perhaps you get confused because a lot of work goes on looking at partial termination analyzers, where the goal is to see for what inputs can the analyzer PROVE halting for all (or at least a defined set) of inputs. The field admits it isn't solving the total problem, but accepts partial answers so the common discussion doesn't talk about a analyzer being a "correct decider" but being correct for certain inputs, or not incorrect for others, as it allows the deciders to give an "i can't tell" answer.