On 7/30/2021 9:05 PM, André G. Isaak wrote:
> On 2021-07-30 17:34, olcott wrote:
>> On 7/30/2021 6:01 PM, André G. Isaak wrote:
>>> On 2021-07-30 16:43, olcott wrote:
>>>> On 7/30/2021 5:13 PM, André G. Isaak wrote:
>>>>> On 2021-07-30 15:53, olcott wrote:
>>>>>> On 7/30/2021 4:46 PM, André G. Isaak wrote:
>>>>>>> On 2021-07-30 11:11, olcott wrote:
>>>>>>>> On 7/30/2021 12:06 PM, André G. Isaak wrote:
>>>>>>>>> On 2021-07-30 07:46, olcott wrote:
>>>>>>>>>
>>>>>>>>>> int Simulate(u32 P, u32 I)
>>>>>>>>>> {
>>>>>>>>>>    ((int(*)(int))P)(I);
>>>>>>>>>>    return 1;
>>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Why is this function called 'Simulate'?
>>>>>>>>>
>>>>>>>>> There's nothing remotely resembling simulation going on there.
>>>>>>>>> The function is simply calling the function pointer that was
>>>>>>>>> passed to it. That's execution, not simulation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> It is the simplest possible function that is computationally
>>>>>>>> equivalent to a simulation. Since every single instruction of
>>>>>>>> the entire x86utm operating system is simulated the name is also
>>>>>>>> literally true.
>>>>>>>
>>>>>>> Well, no, it isn't. The name 'simulator' suggests that this
>>>>>>> function performs simulation. From what you suggest above,
>>>>>>> 'simulator' is, itself, being simulated. That's something
>>>>>>> altogether different which makes the name incredibly misleading.
>>>>>>>
>>>>>>
>>>>>> Then think of it as being named Big_Freds_Pizza(), the point is
>>>>>> that my code seems to defeat Rice.
>>>>>>
>>>>>> Didn't you make a claim that you could fool it?
>>>>>>
>>>>>>>>> Which raises all sorts of questions regarding your previous
>>>>>>>>> usage of the term 'simulate'. Does your 'simulating decider'
>>>>>>>>> actually involve simulation at all?
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> The x86utm operating system is based on an x86 emulator that has
>>>>>>>> decades of development.
>>>>>>>
>>>>>>> That doesn't answer my question at all (and I don't know why you
>>>>>>> think anyone cares how many decades something has been under
>>>>>>> development).
>>>>>>>
>>>>>>> You consistently referred to your H as a 'simulating halt
>>>>>>> decider', but every time you present code snippets of H it shows
>>>>>>> H making a direct call to its input rather than invoking any kind
>>>>>>> of simulator.
>>>>>>>
>>>>>>> So is H actually the thing doing the simulation, or is H simply
>>>>>>> *being* simulated in much the same way as your so-called
>>>>>>> 'Simulate' function above is?
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>
>>>>>> Why can't you seem to stay focused on the key point at hand?
>>>>>> Why do you diverge off on inconsequential trivialities?
>>>>>
>>>>> Because it *isn't* an inconsequential triviality. I'm trying to
>>>>> figure out the actual architecture of your system, and you are
>>>>> being deliberately unhelpful.
>>>>>
>>>>> Just because you don't understand why a particular question is
>>>>> being asked isn't a good reason to refuse to answer it.
>>>>
>>>> int Simulate(u32 P, u32 I)
>>>> {
>>>>    ((int(*)(int))P)(I);
>>>>    return 1;
>>>> }
>>>>
>>>> // H and H2 are partial halt deciders
>>>> u32 PSR_Decider(u32 P, u32 I)
>>>> {
>>>>    u32 Input_Halts1 = H((u32)P, (u32)I);
>>>>    u32 Input_Halts2 = H2((u32)Simulate, (u32)P, (u32)I);
>>>>    Output("Input_Halts1 = ", Input_Halts1);
>>>>    Output("Input_Halts2 = ", Input_Halts2);
>>>>    if (Input_Halts1 != Input_Halts2)
>>>>      return 1;
>>>>    return 0;
>>>> }
>>>>
>>>> void P(u32 x)
>>>> {
>>>>    if (H(x, x))
>>>>      HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    Output("PSR_Decider = ", PSR_Decider((u32)P, (u32)P));
>>>> }
>>>>
>>>> The point of this post is whether or not my PSR_Decider() is correct.
>>>> The name that I choose for my functions is not related to that.
>>>
>>> I'm not asking about the name. I'm asking whether your "simulating
>>> halt decider" H actually performs any simulation or whether it is
>>> simply being simulated as you claim that 'Simulate' above is.
>>>
>>> And once again you've failed to answer. It's a simple straightforward
>>> question. It can be answered in a single short sentence. So why not
>>> simply answer it rather than coming up with excuses for not answering
>>> it?
>>>
>>
>> I have aready answered this many hundreds of times, asking the same
>> quesition again seems quite disingenuous. Here is an additional detail
>> that I have only provided about a dozen times:
>>
>> This is *how* H simulates its slave process one x86 instruction
>> at-a-time.
>>
>> u32  DebugStep(Registers* master_state,
>>                 Registers* slave_state,
>>                 Decoded_Line_Of_Code* decoded) {}
>>
>> master_state has the machine register values of H and slave_state has
>> the machine register values of P. decoded has the simplified machine
>> code that was executed.
>
> That doesn't answer my question, though. I am interested in *where* the
> simulation actually takes place. Does H actually initialize the
> simulation

Yes

> and set up these state records, or is this something done by
> your "operating system".
>
> When you call H(P, P) does the copy of H inside P set up a second set of
> register state records and initialize a new simulation or not?
>

It is more accurately a copy of P inside of H. H creates a whole process
context including stack, and registers for each virtual machine that it
simulates.

> Also, why would a simulation of P require *two* sets of register states?
> It should only require the state of the machine being simulated.
>

An operating system function switches to the process context of the
slave, executes one instruction then switches back to the master.

>>>>> I can guarantee you that if you ever present your work in a *real*
>>>>> academic environment, you will be asked all sorts of questions of
>>>>> which you might not immediately see the relevance, and you *will*
>>>>> be expected to answer them.
>>>>>
>>>>>> If you think that you can fool my Pathological
>>>>>> self-reference(Olcott 2004) decider go ahead any try this. If it
>>>>>> is impossible to fool it then that proves that it is correct.
>>>>>
>>>>> How can anyone possible answer this?
>>>>>
>>>>> You've apparently now got two different halt decider, H1 and H2.
>>>>> You haven't provided even the vaguest description of what these
>>>>> things do or how they differ from one another.
>>>>>
>>>>
>>>> So before you ever read what I say you first make sure to forget
>>>> everything else that we have discussed.
>>>>
>>>> The P of int main(){ P(P); } reaches its final state.
>>>> The input to H(P,P) cannot possibly reach its final state.
>>>> PSR_Decider() sees this difference.
>>>
>>> So why are you using a different halt decider for each case? What's
>>> the different between H1 and H2? And why do you need Simulate at all?
>>> Why not just call H2(P, P) given that your 'simulate' is no more than
>>> a wrapper for a function call.
>>>
>>
>> H2 take three params so that it can execute the equivalent of
>> int main(){ P(P); }
>
> P(P) is already the equivalent of int main() { P(P); }.
>

Yet we need to see what int main(){ P(P); } does and we can't do that
without a global halt decider so I derived the computational equivalent
using local functions.

> So H2(Simulate, P, P)
>
> should return the exact same answer as
>
> H1(P, P)
>
> given that 'Simulate' is just a wrapper for P(P).
>

No the reason that they give different results is that
H2 is at a different point in the execution trace than H.

// this one corresponds to the point where H(P,P) evaluates its input
u32 Input_Halts1 = H((u32)P, (u32)P);

// this one corresponds to the point before H(P,P) evaluates its input
u32 Input_Halts2 = H2((u32)Simulate, (u32)P, (u32)P);

It has never been the case that one is correct and the other is wrong.

It has always been the case that the correct answer depends on where the
question is asked.

>>> How is it that H2 *correctly* determines that P(P) does halt
>>
>> P reaches its final state.
>
> But how exactly is it that H2 gets this answer right when H1 gets the
> answer wrong?
>

Both answers are correct at the point in the execution trace where they
are asked.

>>> (or that Simulate(P, P) doesn't halt)
>>
>> Simulate does halt.
>
> Yes. That was a typo. I already corrected it.
>
>>> whereas H1 incorrectly claims that P(P) doesn't halt?
>>
>> H1 correctly determines that its input cannot possibly ever halt
>> unless H1 aborts its simulation of P, thus perfectly matching the
>> never halts criteria.
> >
>> int main(){ P(P); } does halt.
>
> Yes. I get that. What I don't get is how your H2 manages to correctly
> determine this if it is using the same broken halting criteria as H1.
>

It is correct halting criteria. Both H and H2 are correct at the point
in the execution trace where they are asked.

It is true that the input to H(P,P) cannot possibly and never does reach
its final state. It is also true that when P(P) is invoked separately
that P does reach its final state. The different points in the execution
trace derive different correct answers.

When we ask whether or not Bill is a criminal we cannot correctly answer
this question on the basis of the behavior of his twin brother.

> In both cases you have P(P) appearing as an input to your halt decider
> rather than as an independent computation.
>
> André
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein