Just saying.

On 1/17/2024 5:38 AM, immibis wrote:
> Just saying.

DD correctly simulated by HH can simulates DD to an arbitrary
depth of recursive simulation until it crashes from stack overflow.

I have said what correctly simulated means far too many times and
you simply ignore what I say.

Correctly simulated means that HH simulates the actual x86
machine code steps of the computation specified by DD.

I did not write this x86 emulator. It is a third party
open source project with decades of development effort.

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

On 1/17/24 15:56, olcott wrote:
> On 1/17/2024 5:38 AM, immibis wrote:
>> Just saying.
>
> DD correctly simulated by HH can simulates DD to an arbitrary
> depth of recursive simulation until it crashes from stack overflow.
>
> I have said what correctly simulated means far too many times and
> you simply ignore what I say.

So you define a correct simulation as a stack overflow crash? Because
that is the only thing you said about it.

>
> Correctly simulated means that HH simulates the actual x86
> machine code steps of the computation specified by DD.
>

So your H isn't a correct simulator.

> I did not write this x86 emulator. It is a third party
> open source project with decades of development effort.
>

But you made it incorrect by making it stop too soon.

On 1/17/2024 9:47 AM, immibis wrote:
> On 1/17/24 15:56, olcott wrote:
>> On 1/17/2024 5:38 AM, immibis wrote:
>>> Just saying.
>>
>> DD correctly simulated by HH can simulates DD to an arbitrary
>> depth of recursive simulation until it crashes from stack overflow.
>>
>> I have said what correctly simulated means far too many times and
>> you simply ignore what I say.
>
> So you define a correct simulation as a stack overflow crash? Because
> that is the only thing you said about it.

Do you understand what infinite recursion is?
When a correct simulator correctly simulates
infinite recursion the system does crash when
stack overflow is reached.

>
>>
>> Correctly simulated means that HH simulates the actual x86
>> machine code steps of the computation specified by DD.
>>
>
> So your H isn't a correct simulator.
>

The definition of a correct simulator is a simulator
that correctly simulates each of the x86 instructions
that its input specifies.

The x86 emulator was written by a third party and
has decades of validation.

>> I did not write this x86 emulator. It is a third party
>> open source project with decades of development effort.
>>
>
> But you made it incorrect by making it stop too soon.

I proved that it does not stop too soon when DD correctly
simulated by HH only stops when it runs out of stack space.

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

On 1/17/24 17:23, olcott wrote:
> On 1/17/2024 9:47 AM, immibis wrote:
>> On 1/17/24 15:56, olcott wrote:
>>> On 1/17/2024 5:38 AM, immibis wrote:
>>>> Just saying.
>>>
>>> DD correctly simulated by HH can simulates DD to an arbitrary
>>> depth of recursive simulation until it crashes from stack overflow.
>>>
>>> I have said what correctly simulated means far too many times and
>>> you simply ignore what I say.
>>
>> So you define a correct simulation as a stack overflow crash? Because
>> that is the only thing you said about it.
>
> Do you understand what infinite recursion is?
> When a correct simulator correctly simulates
> infinite recursion the system does crash when
> stack overflow is reached.
>
>>
>>>
>>> Correctly simulated means that HH simulates the actual x86
>>> machine code steps of the computation specified by DD.
>>>
>>
>> So your H isn't a correct simulator.
>>
>
> The definition of a correct simulator is a simulator
> that correctly simulates each of the x86 instructions
> that its input specifies.
>

Your H ignores some of the instructions.

> The x86 emulator was written by a third party and
> has decades of validation.
>

Nobody is disputing the correct simulation of basic x86 instructions,
only the things you added to the simulator.

>>> I did not write this x86 emulator. It is a third party
>>> open source project with decades of development effort.
>>>
>>
>> But you made it incorrect by making it stop too soon.
>
> I proved that it does not stop too soon when DD correctly
> simulated by HH only stops when it runs out of stack space.
>

This proves that you do not understand the difference between inner and
outer simulation levels. How much is your software engineering experience?

On 1/17/2024 10:50 AM, immibis wrote:
> On 1/17/24 17:23, olcott wrote:
>> On 1/17/2024 9:47 AM, immibis wrote:
>>> On 1/17/24 15:56, olcott wrote:
>>>> On 1/17/2024 5:38 AM, immibis wrote:
>>>>> Just saying.
>>>>
>>>> DD correctly simulated by HH can simulates DD to an arbitrary
>>>> depth of recursive simulation until it crashes from stack overflow.
>>>>
>>>> I have said what correctly simulated means far too many times and
>>>> you simply ignore what I say.
>>>
>>> So you define a correct simulation as a stack overflow crash? Because
>>> that is the only thing you said about it.
>>
>> Do you understand what infinite recursion is?
>> When a correct simulator correctly simulates
>> infinite recursion the system does crash when
>> stack overflow is reached.
>>
>>>
>>>>
>>>> Correctly simulated means that HH simulates the actual x86
>>>> machine code steps of the computation specified by DD.
>>>>
>>>
>>> So your H isn't a correct simulator.
>>>
>>
>> The definition of a correct simulator is a simulator
>> that correctly simulates each of the x86 instructions
>> that its input specifies.
>>
>
> Your H ignores some of the instructions.
>
>> The x86 emulator was written by a third party and
>> has decades of validation.
>>
>
> Nobody is disputing the correct simulation of basic x86 instructions,
> only the things you added to the simulator.
>

I DID NOT ADD ANYTHING TO THE SIMULATOR

>>>> I did not write this x86 emulator. It is a third party
>>>> open source project with decades of development effort.
>>>>
>>>
>>> But you made it incorrect by making it stop too soon.
>>
>> I proved that it does not stop too soon when DD correctly
>> simulated by HH only stops when it runs out of stack space.
>>
>
> This proves that you do not understand the difference between inner and
> outer simulation levels. How much is your software engineering experience?

Since 1984

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

On 1/17/24 17:54, olcott wrote:
> On 1/17/2024 10:50 AM, immibis wrote:
>> On 1/17/24 17:23, olcott wrote:
>>> The x86 emulator was written by a third party and
>>> has decades of validation.
>>>
>>
>> Nobody is disputing the correct simulation of basic x86 instructions,
>> only the things you added to the simulator.
>>
>
> I DID NOT ADD ANYTHING TO THE SIMULATOR
So a third party wrote the non-halting pattern detection?

>
>>>>> I did not write this x86 emulator. It is a third party
>>>>> open source project with decades of development effort.
>>>>>
>>>>
>>>> But you made it incorrect by making it stop too soon.
>>>
>>> I proved that it does not stop too soon when DD correctly
>>> simulated by HH only stops when it runs out of stack space.
>>>
>>
>> This proves that you do not understand the difference between inner
>> and outer simulation levels. How much is your software engineering
>> experience?
>
> Since 1984
>

And you still don't understand the difference between outer and inner
simulation levels in a nested simulator. My goodness.

On 1/17/2024 11:24 AM, immibis wrote:
> On 1/17/24 17:54, olcott wrote:
>> On 1/17/2024 10:50 AM, immibis wrote:
>>> On 1/17/24 17:23, olcott wrote:
>>>> The x86 emulator was written by a third party and
>>>> has decades of validation.
>>>>
>>>
>>> Nobody is disputing the correct simulation of basic x86 instructions,
>>> only the things you added to the simulator.
>>>
>>
>> I DID NOT ADD ANYTHING TO THE SIMULATOR
> So a third party wrote the non-halting pattern detection?
>
>>
>>>>>> I did not write this x86 emulator. It is a third party
>>>>>> open source project with decades of development effort.
>>>>>>
>>>>>
>>>>> But you made it incorrect by making it stop too soon.
>>>>
>>>> I proved that it does not stop too soon when DD correctly
>>>> simulated by HH only stops when it runs out of stack space.
>>>>
>>>
>>> This proves that you do not understand the difference between inner
>>> and outer simulation levels. How much is your software engineering
>>> experience?
>>
>> Since 1984
>>
>
> And you still don't understand the difference between outer and inner
> simulation levels in a nested simulator. My goodness.

Unless you somehow prove your technical competence I will
quit talking to you. It seems that you are only a troll.

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

On 1/17/24 11:23 AM, olcott wrote:
> On 1/17/2024 9:47 AM, immibis wrote:
>> On 1/17/24 15:56, olcott wrote:
>>> On 1/17/2024 5:38 AM, immibis wrote:
>>>> Just saying.
>>>
>>> DD correctly simulated by HH can simulates DD to an arbitrary
>>> depth of recursive simulation until it crashes from stack overflow.
>>>
>>> I have said what correctly simulated means far too many times and
>>> you simply ignore what I say.
>>
>> So you define a correct simulation as a stack overflow crash? Because
>> that is the only thing you said about it.
>
> Do you understand what infinite recursion is?
> When a correct simulator correctly simulates
> infinite recursion the system does crash when
> stack overflow is reached.
>
>>
>>>
>>> Correctly simulated means that HH simulates the actual x86
>>> machine code steps of the computation specified by DD.
>>>
>>
>> So your H isn't a correct simulator.
>>
>
> The definition of a correct simulator is a simulator
> that correctly simulates each of the x86 instructions
> that its input specifies.

Then why doesn't your H correctly simulate the call to H that it sees?

Either it needs to simulate the instructions in the H that it finds, or
replace that call with the ACTUAL equivalent of what a call to H(D,D)
will do.

Since your claimed correct H(D,D) returns 0, the correct simulaiton of
D(D) must be compatible with the correct simulation of the call to
H(D,D) returning 0.

>
> The x86 emulator was written by a third party and
> has decades of validation.
>
>>> I did not write this x86 emulator. It is a third party
>>> open source project with decades of development effort.
>>>
>>
>> But you made it incorrect by making it stop too soon.
>
> I proved that it does not stop too soon when DD correctly
> simulated by HH only stops when it runs out of stack space.
>

Nope, DD is not D, so your claim just proves you lie.

On 1/17/24 9:56 AM, olcott wrote:
> On 1/17/2024 5:38 AM, immibis wrote:
>> Just saying.
>
> DD correctly simulated by HH can simulates DD to an arbitrary
> depth of recursive simulation until it crashes from stack overflow.
>
> I have said what correctly simulated means far too many times and
> you simply ignore what I say.
>
> Correctly simulated means that HH simulates the actual x86
> machine code steps of the computation specified by DD.

So, if that is the correct simulaiton of DD, what is the correct
simuation of the OTHER input D?

>
> I did not write this x86 emulator. It is a third party
> open source project with decades of development effort.
>

Note, you have posted the "correct simulation" of the input D(D),
showing that it Halts.

This PROVES that the H that answers didn't do a correct simulation of
its input, but is guilty of mistaken identity because it didn't actually
look at the H that D used.