On 8/17/2022 10:35 AM, Dennis Bush wrote:
> On Wednesday, August 17, 2022 at 11:24:34 AM UTC-4, olcott wrote:
>> On 8/17/2022 9:51 AM, Dennis Bush wrote:
>>> On Wednesday, August 17, 2022 at 10:23:17 AM UTC-4, olcott wrote:
>>>> On 8/17/2022 6:40 AM, Dennis Bush wrote:
>>>>> On Wednesday, August 17, 2022 at 12:28:52 AM UTC-4, olcott wrote:
>>>>>> On 8/16/2022 11:02 PM, Dennis Bush wrote:
>>>>>>> On Tuesday, August 16, 2022 at 11:57:51 PM UTC-4, olcott wrote:
>>>>>>>> On 8/16/2022 10:53 PM, Dennis Bush wrote:
>>>>>>>>> On Tuesday, August 16, 2022 at 11:39:32 PM UTC-4, olcott wrote:
>>>>>>>>>> On 8/16/2022 10:23 PM, Dennis Bush wrote:
>>>>>>>>>>> On Tuesday, August 16, 2022 at 11:18:46 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 8/16/2022 9:52 PM, Dennis Bush wrote:
>>>>>>>>>>>>> On Tuesday, August 16, 2022 at 10:47:57 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>> On 8/16/2022 9:34 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>> On Tuesday, August 16, 2022 at 10:12:55 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>> On 8/16/2022 8:55 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 8/16/22 9:20 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 8/16/2022 8:10 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 8/16/22 10:27 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 8/16/2022 9:07 AM, Skep Dick wrote:
>>>>>>>>>>>>>>>>>>>>> On Tuesday, 16 August 2022 at 15:55:30 UTC+2, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> The correct and complete x86 emulation of the input to H(P,P) by H
>>>>>>>>>>>>>>>>>>>>>> WOULD
>>>>>>>>>>>>>>>>>>>>>> never stop running.
>>>>>>>>>>>>>>>>>>>>> Sounds like you are stuck in a loop.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Maybe your Decider/Maker should terminate you.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I have been trying to get an honest person to acknowledge the
>>>>>>>>>>>>>>>>>>>> correct software engineering of my system so that we can move on to
>>>>>>>>>>>>>>>>>>>> the next point for a year now. (bot many honest people here, mostly
>>>>>>>>>>>>>>>>>>>> trolls).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The problem is that what you say ISN'T CORRECT software engineering.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> You use the wrong definition of things and incorrect assumptions
>>>>>>>>>>>>>>>>>>> about thing, so it just isn't true.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> H(P,P) does correctly predict that its correct and complete x86
>>>>>>>>>>>>>>>>>>>> emulation of its input would never stop running, thus does correctly
>>>>>>>>>>>>>>>>>>>> reject this input as non-halting.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Nope. And in fact, you even acknoldge it doesn't but just don't see it.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> So you are saying that the correct and complete x86 emulation by
>>>>>>>>>>>>>>>>>> H(P,P) of its input WOULD STOP RUNNING?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No, I am saying that you H doesn't do a correct and complete emulation
>>>>>>>>>>>>>>>>> of its input, and thus to say it did is just a LIE.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I said that H correctly predicts what the behavior of its correct and
>>>>>>>>>>>>>>>> complete x86 emulation of H(P,P) would be
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The fixed source code of H (and everything it calls) that aborts is Ha. Ha *always* aborts Pa, so "the correct and complete simulation of Ha(Pa,Pa)" does not exist, just like the shoes that Napoleon wore on Mars do not exist.
>>>>>>>>>>>>>> So you are another brain dead moron the believes it is utterly
>>>>>>>>>>>>>> impossible for H to correctly predict that its correct and complete x86
>>>>>>>>>>>>>> emulation of its input would never stop running unless H actually
>>>>>>>>>>>>>> performed a correct and complete emulation of its input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The correct and complete emulation of Ha(Pa,Pa) doesn't exist,
>>>>>>>>>>>> Neither does the correct and complete emulation of Infinite_Loop()
>>>>>>>>>>>
>>>>>>>>>>> Yes it does. If you simulate Infinite_Loop(), it won't halt. But if you run Ha(Pa,Pa), it won't do a correct and complete simulation because it aborts.
>>>>>>>>>> When you run H0((u32)Infinite_Loop)
>>>>>>>>>> "it won't do a correct and complete simulation because it aborts"
>>>>>>>>>> How long are you going to keep the head game up?
>>>>>>>>>
>>>>>>>>> That you don't understand what I'm saying doesn't make it a head game.
>>>>>>>>>
>>>>>>>> You reject Ha(Pa,Pa) on this basis
>>>>>>>> run Ha(Pa,Pa), it won't do a correct and complete simulation because it
>>>>>>>> aborts.
>>>>>>>> Yet accept P0(Infinite_Loop), on the same basis
>>>>>>>> it won't do a correct and complete simulation because it aborts.
>>>>>>>> ∴ You are playing head games.
>>>>>>>
>>>>>>> What does P0 do? Does it abort? If so, then yes P0(Infinite_Loop) doesn't do a correct and complete simulation because it aborts, so it's invalid to predict what the correct and complete simulation of P0(Infinite_Loop) would do.
>>>>>>>
>>>>>>> On the other hand, UTM(Infinite_Loop) does do a correct and complete simulation, so it *is* valid to predict what it will do.
>>>>>>>
>>>>>> In other words you are not bright enough to see that it is very easy for
>>>>>> H0 to recognize an infinite loop would never halt in a finite number of
>>>>>> steps of simulation?
>>>>>
>>>>> I'm saying that H0 can see that the correct and complete simulation performed by UTM(Infinite_Loop) does not halt. It does not and cannot see that the correct and complete simulation performed by H0(Infinite_Loop) (i.e. your basis for correctness) does not halt because H0 does not perform a correct and complete simulation.
>>>>>
>>>> This is what I mean by H evaluating what its correct and complete
>>>> simulation of its input would be:
>>>>
>>>> void P(ptr x)
>>>> {
>>>> int Halt_Status = Simulate(x, x);
>>>> if (Halt_Status)
>>>> HERE: goto HERE;
>>>> return;
>>>> }
>>>>
>>>> Although H itself does not perform a correct and complete simulation of
>>>> non-halting inputs H does correctly predict that such a simulation would
>>>> never halt.
>>>
>>> You changed the input from Pa to Pn.
>>>
>>> So you're again saying that Ha(Pa,Pa) reports the halt status of the non-input Pn(Pn) instead of Pa(Pa) as it is required to:
>>>
>> H0(Infinite_Loop)
>> reports on Simulate(Infinite_Loop)
>>
>> H(Infinite_Recursion, 0x777)
>> reports on Simulate((Infinite_Recursion, 0x777)
>>
>> In every case a simulating halt decider reports on what the behavior of
>> its simulated input would be if this SHD was swapped for a simulator.
>
> And in the case of Ha(Pa,Pa) you change the input in doing so which is not allowed. Remember, what is being decided on is the FIXED source code of Pa and everything it calls, which includes the FIXED source code of Ha and everything it calls.

THIS JUST SEEMS OVER YOUR HEAD.
H correctly determines that its input would never halt by correctly
predicting that its input would never halt if H never aborted its
simulation of this input.

H does the same thing for:
H0(Infinite_Loop)
H(Infinite_Recursion, 0x777)
H(P,P)

*What you are doing is like Zeno's Paradox*
In its simplest form, Zeno's Paradox says that two objects can never
touch. The idea is that if one object (say a ball) is stationary and the
other is set in motion approaching it that the moving ball must pass the
halfway point before reaching the stationary ball. As there are an
infinite number of half way points the two balls can never touch - there
will always be another halfway point to cross before reaching the
stationary ball.
https://owlcation.com/stem/understanding-and-solving-Zenos-paradox

You can name and rename different variations of H, none-the-less H does
correctly predict what the behavior of its hypothetical correct and
complete simulation of its input would be without the need for H to
perform this complete emulation itself.

>>> For *any* algorithm X and input Y:
>>> H(X,Y)==1 if and only if X(Y) halts, and
>>> H(X,Y)==0 if and only if X(Y) does not halt
>> The only reason that anyone ever said that is they they falsely assumed
>> that the behavior of the direct execution of X(Y) must always be the
>> same as the correct simulation of (X,Y) by a simulating halt decider.
>
> FALSE. You only think they're different because you change the input. Besides, what is being asked about is the direct execution, so even if the simulated behavior is different (which it isn't) it's irrelevant.
>
>>
>> In those cases where the behavior is the same, the behavior of X(Y) is a
>> good proxy for the behavior of the simulated input to H(X,Y).
>>
>> In those cases where the behavior is not the same then what the behavior
>> would be if H(X,Y) performed a correct and complete simulation of its
>> input is the correct behavior to report on.
>>
>> 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.
>
> FALSE. A halt decider must compute the halting function:
>
> For *any* algorithm X and input Y:
> H(X,Y)==1 if and only if X(Y) halts, and
> H(X,Y)==0 if and only if X(Y) does not halt
>
>>
>> int sum(int x, int y)
>> {
>> return x + y;
>> }
>>
>> *THE BEHAVIOR OF A NON-INPUT IS IRRELEVANT*
>
> Says the guy that expects Ha(Pa,Pa) to report the halt status of the non-input Pn(Pn).
>
>> Because we don't expect sum(3,4) to return the sum of 5 + 7, I don't see
>> why this is so hard for you.
>
> Because we don't expect Ha(Pa,Pa) to return the halt status of Pn(Pn),

Yet that is what H was designed to do. H was designed to detect infinite
behavior patterns in a finite number of steps.

> I don't see why this is so hard for you.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer