On 7/13/22 3:37 PM, olcott wrote:
> On 7/13/2022 1:03 PM, Paul N wrote:
>> On Wednesday, July 13, 2022 at 5:08:05 PM UTC+1, olcott wrote:
>>> On 7/13/2022 10:02 AM, Paul N wrote:
>>>> Firstly, this subject matter is not relevant in comp.lang.c or
>>>> comp.lang.c++, so please stop posting any of it there. If I see any
>>>> more posts of this sort in either of those newsgroups I shall assume
>>>> that, regardless of the merits of your argument, you are very rude.
>>>>
>>>> On Wednesday, July 13, 2022 at 4:16:04 AM UTC+1, olcott wrote:
>>>>> *CHANGING THE SUBJECT IS NEVER ANY REBUTTAL*
>>>>>
>>>>> I rewrote this question so that a software engineer of ordinary skill
>>>>> can easily verify that the simulated P does call H in what is
>>>>> essentially infinite recursion. **This simplification is the result of
>>>>> an extensive review (23 emails) by a leading computer scientist
>>>>> over the
>>>>> weekend.**
>>>>
>>>>> Does H(P,P) correctly determine the halt status of the halting
>>>>> problem's
>>>>> pathological input?
>>>>
>>>>> The following H and P have the above specified pathological
>>>>> relationship
>>>>> to each other.
>>>>>
>>>>> typedef void (*ptr)();
>>>>> int H(ptr p, ptr i);
>>>>>
>>>>> void P(ptr x)
>>>>> {
>>>>> if (H(x, x))
>>>>> HERE: goto HERE;
>>>>> return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> Output("Input_Halts = ", H(P, P));
>>>>> }
>>>>>
>>>>> Simulating halt decider H detects that its simulated input is
>>>>> essentially calling H in infinite recursion. H aborts its
>>>>> simulation on
>>>>> this basis and rejects this input as non-halting.
>>>>
>>>> Thus it is an incorrect assessment, as we'll see below.
>>>>
>>>>> *Once this halt deciding principle is accepted*
>>>>> A halt decider must compute the mapping from its inputs to an
>>>>> accept or
>>>>> reject state on the basis of the actual behavior that is actually
>>>>> specified by these inputs.
>>>>
>>>> Again, emphasis on "actual behaviour".
>>>>
>>>>> *Then (by logical necessity) this is understood to implement that*
>>>>> Every simulating halt decider that correctly simulates its input until
>>>>> it correctly predicts that this simulated input would never terminate
>>>>> normally, correctly rejects this input as non-halting.
>>>>
>>>> You have stated numerous times that a program that "correctly
>>>> simulates its input" can have different results. Thus it is not
>>>> clear what you mean by the phrase. There is no logical necessity to
>>>> accept anything about a correct simulation which does not simulate
>>>> correctly.
>>>>
>>>>> *The execution trace of function P() simulated by function H() shows*
>>>>> (1) Function H() is called from P().
>>>>> (2) With the same parameters to H().
>>>>> (3) With no instructions in P() that could possibly escape this
>>>>> infinitely recursive simulation.
>>>>
>>>> Ah, but there are instructions in H which escape from the infinite
>>>> recursion. You've said numerous times that there are. See only a few
>>>> lines up. If you pretend that they are somehow not there, you are
>>>> not correctly simulating H and hence not correctly simulating P
>>>> which calls it.
>>>>
>>>>> This proves that H(P,P) correctly predicts that its correctly
>>>>> simulated
>>>>> input would never terminate normally.
>>>>
>>>> As you've said above, in capitals and with asterisks, changing the
>>>> subject is not a rebuttal. You're trying to change the subject from
>>>> the actual behaviour of P(P) to some sort of "simulated" behaviour
>>>> of P(P) which you have said yourself is different.
>>> Welcome back.
>>>
>>> When H(P,P) correctly simulates its input this is the ultimate measure
>>> of the actual behavior specified by this input.
>>
>> No, the actual behaviour is the actual behaviour! If H correctlky
>> simulates this behaviour then it too will also be the same, but you
>> have siad numerous times that it does not correctly simulate the
>> behavoutr.
>>
>
> It is an easily verified fact that H(P,P) correctly simulates its input
> to everyone having sufficient knowledge of the x86 assembly language
> which currently seems to be hardy no one besides me. Back in the 1986
> when I began my career about 10% of all programmers had familiarity
> with the x86 language. This is the language that MSDOS and versions
> of MS Windows prior to Windows NT were written in. Windows NT switched
> to mostly C/C++.

No, it is easily verified tha H doesn't correctly simulate its input,
since BUY DEFINITION H(P,P) must be being asked about the behavior of
P(P) since that is the question that P is supposed to be asking H.

Since H's simulation of its input doesn't match the behavior of the
actual machine it is supposed to be simulating, it is incorrect.

THAT IS PURELY FROM THE DEFINTION OF CORRECT.

>
> The 23 emails that I had with a leading computer scientist made that
> very clear. Because of this I re-framed my explanation so that any
> expert C programmer that totally understands infinite recursion would be
> able to see that infinitely nested simulation is essentially the same
> thing.

You are very good at hiding the truth. If you said that H was DEFINED to
be a machine that did a pure simulation of its input until it actually
proved that its input doesn't halt, then yes, by that definition P(P)
will be non-halting, but also by that definiton H(P,P) can NEVER abort
its simulation of the input, becuase it can NEVER actually prove the
input to be non-halting, because if it ever thinks it has and returns 0,
then the input becomes halting.

If you made that claim while at the same time your H ACTUALLY did the
aborting, then you LIED, and his "support" is invalid.

>
> The next important point that requires one to have top software
> engineering skills that allowed me to transform H into a pure thus
> computable function: Infinitely nested simulation can be detected the
> first time that the simulated input calls the simulator with its same
> arguments. Infinite recursion requires seeing two such calls in a row.
> This change allowed me to discard the need for static local memory and
> do everything in local memory.
>

Nope, show the proof of that claim. Remember, the proof MUST include the
fact that the simulator is NOT "just" a pure simulator, but is
conditional on the behavior of the simulation, and WILL (per your claim)
abort this simulation and return 0.

>>> A security guard at the front door is only required to validate people
>>> coming in the front door the actual behavior of the actual input to
>>> H(P,P).
>>>
>>> This same security guard is not required to validate people coming in
>>> the back door the direct execution of P(P). Unless a computation is
>>> specified as an actual input to H it is not in the domain of the
>>> computable function that H implements.
>>
>> H takes two arguments. The first is a program to be considered and the
>> second is the input that could be supplied to that program. H is
>> required to decide, correctly, whether the program would halt given
>> that input, ie whether M(X) would halt.
>
> No this a very long standing misconception. H is required to determine
> whether or not its correct simulation of its input would ever reach the
> normal termination of this input.

Nope. If H is to be a Halt Decider, it must map the inputs, to the
behaivor of the program and input that its input represents. The Halting
Problem NEVER mentions simulation of its inputs.

You just are showing you don't understand the basics of the proof you
are talking about.

>
> Since no one ever bothered to think through the application of a
> simulating halt decider to the HP's impossible inputs they always stated
> the requirements incorrectly never realizing their mistake.

Nope, "Simulating Halt Deciders", if they are to be considered a Halt
Decider, must follow exactly the same definiton.

YOU FAIL.

>
> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior that is actually
> specified by these inputs.

A Decider CAN ONLY compute a mapping to an accept or reject state based
on the behavior it can determine, but MUST compute the mapping of the
DEFINED FUNCTION to be correct. Halting is DEFINED based on the
>
> In the H/P concrete example it is easily proven that the actual behavior
> of the actual input to H(P,P) is not the behavior of the directly
> executed P(P). The best proof of this is the x86 execution trace of each
> that precisely corresponds to what the x86 source code of P specifies.

Then H or P are not defined correctly.

P is DEFINED to ask H about itself with its input, if H(P,P) doesn't
represent that question, then YOU did something wrong in translating it
to your notation.

> From this is is obvious that the correctly simulated P cannot possibly
> terminate normally and the executed P(P) halts.

WRONG. it is obvious that a CORRECTLY simulated P will halt if H(P,P)
returns 0, and will not halt otherwise.

Yes, you can prove that H can never simulate its input to that point to
prove that P(P) is halting, but once H aborts its simulation, it has
ceased to be a source of truth for the behavior of the input, since the
actual behavior of the machine it represents continues, and the CORRECT
simulation will show that it halts.

>
> Those lacking knowledge of the x86 language can understand that this
> first halt deciding principle is necessarily correct:
>
> *When this halt deciding principle understood to be correct*
> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior that is actually
> specified by these inputs.

Right, and the ACTUAL BEHAVIOR of the input to H(P,P) is the behavior of
P(P) and P(P) Halts if H(P,P) returns 0, so H(P,P) returning 0 is not
correct.

The ONLY way for your H(P,P) to not represent P(P) would be for H to say
that because you have defined your "input P" to only be the byte of
assembly of P itsef, that H rejects the input as invalid as not being a
complete program, which just shows that P was defined incorrectly.

>
> And this second halt deciding principle follows from the first one by
> logical necessity.
>
> *Then (by logical necessity) this implements that principle*
> Every simulating halt decider that correctly simulates its input until
> it correctly predicts that this simulated input would never terminate
> normally, correctly rejects this input as non-halting.
>

Yes, if it DOES simulate correctly until it can correctly predict that
this simulate input would never terminate, then H(P,P) will never
return, as such an H will never actually reach (in finite time) a state
that it can prove in non-halting, because ANY such state in the
simulation that it might think would be non-halting, if programmed into
H as a non-halting pattern, makes P(P) halting, and thus isn't a correct
pattern.

>>
>> If a program M would halt given input X, then H(M, X) is required to
>> be non-zero.
>> If a program M would not halt given input X, then H(M, X) is required
>> to be zero.
>>
>
> This is a misconception that can only be true if the halt decider is
> required to report on something besides the actual behavior of its
> actual input.

And again H(P,P) MUST represent P(P) or your P is defined incorrectly.

>
> The ultimate measure of the actual behavior of the actual input is the
> provable correct simulation of this input by the simulating halt decider.

ONLY if the simulator never stops its simulation until it can actually
CORRECTLY prove that the input never halts, which means that the same
input when given to a different simulator that actually never does
abort, will never halt.

>
> To assume that this behavior must be the same as the directly executed
> P(P) after it has been conclusively proven to not be that same as an
> established fact is at least a little nutty.

Nope, you haven't actually established this fact. You "proof" is based
on false premises so is unsound.

>
> That people unequivocally state that I must be wrong entirely on the
> basis that they lack sufficient understanding of the x86 language to
> understand my proof is a worst case example of the ad ignorantiam logic
> error.

Nope, YOU ARE WRONG on the basis that H give the wrong answer to the
ACTUAL Halting problem, which ONLY references the behavior of the actual
machine.

All you are doing is proving you don't understand the first thing about
requirments.

>
>> If for some combination M, X the function H(M, X) gives the wrong
>> answer, then it is not a halt decider. If particular, if H(M, X) = 0
>> but M(X) does halt, then the answer is wrong. You can't get out of it
>> by arguing that M(X) is "direct" and H(M, X) is a "correct
>> simulation", whatever that might mean. The answer needs to relate to
>> the actual behaviour, as you yourself have said numerous times.
>>
>> Thus if P(P) halts, H(P, P) is required to be non-zero. If P(P) does
>> not halt, H(P, P) is required to be zero. Anything else is the wrong
>> answer.
>>
>> When we calculate H(P, P), we are supplying P as the first argument
>> and so P is specified as an actual input to H. And we are interested
>> in the actual behaviour of P, the actual input. There is no "back
>> door" by which you can say that P(P) is not the function and input we
>> are talking about.
>>
>>>> To summarise, if H(P, P) terminates (which you have never denied),
>>>> then there are at most four possibilities:
>>>>
>>>> A) H(P, P) returns 0 and P(P) terminates.
>>>> B) H(P, P) returns non-zero and P(P) terminates.
>>>> C) H(P, P) returns 0 and P(P) does not terminate.
>>>> D) H(P, P) returns non-zero and P(P) does not terminate.
>>>>
>>>> B and C are clearly not possible from the definition of P. In A and
>>>> D, H produces the wrong answer.
>>
>>> A1) H(P, P) returns 0 because it correctly determines that the input
>>> that it correctly simulates would never terminate normally.
>>
>> No, that is not a correct answer. You have said numerous times that
>> P(P) terminates.
>>
>>> A2) Directly executed P(P) halts because of (A)
>
>