XPost: comp.theory, comp.lang.c++
From: polcott333@gmail.com
On 11/24/2025 5:33 PM, Mike Terry wrote:
> On 24/11/2025 19:27, Kaz Kylheku wrote:
>> On 2025-11-24, Mike Terry
>> wrote:
>>> On 24/11/2025 16:32, Kaz Kylheku wrote:
>>>> On 2025-11-24, olcott wrote:
>>>>> On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
>>>>>> That's just the thing! If this were correctly implemented then in
>>>>>> fact
>>>>>> DD /wold be/ calling HHH1, using the name HHH.
>>>>>>
>>>>>
>>>>> You are trying to get away with this lie
>>>>> about the semantics of C?
>>>>>
>>>>> int main()
>>>>> {
>>>>> HHH(DD);
>>>>> HHH1(DD);
>>>>> return 0;
>>>>> }
>>>>>
>>>>> _main()
>>>>> [000022c4] 55 push ebp
>>>>> [000022c5] 8bec mov ebp,esp
>>>>> [000022c7] 6834220000 push 00002234 ; push DD
>>>>> [000022cc] e833f3ffff call 00001604 ; call HHH
>>>>> [000022d1] 83c404 add esp,+04
>>>>> [000022d4] 6834220000 push 00002234 ; push DD
>>>>> [000022d9] e856f2ffff call 00001534 ; call HHH1
>>>>> [000022de] 83c404 add esp,+04
>>>>> [000022e1] 33c0 xor eax,eax
>>>>> [000022e3] 5d pop ebp
>>>>> [000022e4] c3 ret
>>>>> Size in bytes:(0033) [000022e4]
>>>>
>>>> That's right; even if HHH and HHH1 are separately realized and given
>>>> different adddresses, not recognized as identical by the compiler and
>>>> not folded into one copy, in a correct implementation of your software,
>>>> HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually
>>>> interchangeable operations.
>>>
>>> Right - in terms of their results when called.
>>>
>>> But TM-descriptions can legitimately contain multiple distinct copies
>>> of "the same algorithm", and
>>> there's no reason that an emulator emulating the TM is required to
>>> identify such copies as being
>>> copies - an emulator just has to mimic what the TM would do and the
>>> TM doesn't know that it has
>>> multiple copies of the same algorithm with different state labels...
>>> Your point that the /results/
>>> of those copied algorithms must be the same is spot on though.
>>
>> Olcott's simulator contains abort criteria which rely on comparing
>> addresses pulled from the trace buffer.
>
> Yep. There are two such comparisons:
> - the addresses of the CALL instructions are compared
> - the targets of the CALL instructions are compared
>
>>
>> That logic concludes that when two addresses are not equal, they
>> represent two different functions. I.e. if CALL X and CALL Y occur in
>> the trace buffer, without any intervening conditionals in between but X
>> != Y, then it is not concluded that it is a loop.
>
> Yep. That's not actually a problem. Possibly a genuine loop might be
> overlooked, but the point is that if the addresses /do/ match that could
> be a loop (subject to the other conditions matching).
>
> Hmm, maybe you're thinking that HHH/HHH1 are comparing trace addresses
> against /their own/ addresses? They don't do that. [H/H1 do that.]
> All compared addresses (whether by HHH/HHH1) are trace addresses from
> the DD() simulation, which is the same whether HHH or HHH1 is doing the
> emulation [up to the point HHH aborts and HHH1 carries on]. So if you
> were right, the behaviour would in any case be the same for HHH/HHH1 and
> couldn't account for differing HHH/HHH1 results.
>
>>
>> That is why HHH1 and HHH show different results, even though they are
>> identical.
>>
>> That comparison is the root cause why it matters that DD calls HHH
>> and not HHH1.
>
> Not so, but I'll perform the test...
>
> A complication: there are TWO occasions where trace address comparisons
> occur, as I listed above: the TARGETS of the two call instructions are
> compared, and the ADDRESSES of the call instructions are compared.
>
> You want to equate "equivalent" addresses. For the TARGET addresses
> this is easy-peasy as I will just check if they are both HHH/HHH1. For
> the CALL instruction addresses, these will not be HHH/HHH1, but
> logically the CALL addresses in different (equivalent) routines should
> be considered equivalent??? What would you like done here? [Perhaps if
> addresses are at the same offset within HHH/HHH1 they could be
> considered equivalent. That's a slight pain, but doable.]
>
> You know what - I've just realised HHH/HHH1 are only called from DD, and
> there's only one DD so this issue doesn't matter in our scenario! The
> CALL instruction addresses will always be the same when HHH/HHH1 are
> called. I'll just ignore the issue for now. (I'll trace the
> comparisons and results so we can check this in the logs.)
>
>>
>> Olcott wrongly believes that the fact of DD calling HHH and not HHH1 is
>> the root cause of the difference.
>
> Well that's PO for you! It's simply that HHH/HHH1 are different
> algorithms (each working off their own static trace table).
>
>>
>> If addressees are compared with a CompareFunctions(X, Y) function
>> whch ensures that HHH and HHH1 are considered equal, then that
>> difference will disappear.
>
> But there will still be the problem I explained with the HHH/HHH1
> having /their own/ static trace tables...
>
>
> Mike.
>
It is a matter of verified fact that
DD simulated by HHH does involve HHH simulating
an instance of itself simulating an instance of DD
and
DD simulated by HHH1 never involves HHH1 simulating
an instance of itself simulating an instance of DD
For people with great difficulty paying attention
For people with great difficulty paying attention
For people with great difficulty paying attention
For people with great difficulty paying attention
DOES INVOLVE and NEVER INVOLVES are not the same thing.
DOES INVOLVE and NEVER INVOLVES are not the same thing.
DOES INVOLVE and NEVER INVOLVES are not the same thing.
DOES INVOLVE and NEVER INVOLVES are not the same thing.
--
Copyright 2025 Olcott
My 28 year goal has been to make
"true on the basis of meaning" computable.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
