On 10/17/24 12:07 PM, olcott wrote:
On 10/17/2024 6:09 AM, Richard Damon wrote:
On 10/16/24 8:55 PM, olcott wrote:
On 10/16/2024 7:37 PM, Richard Damon wrote:
On 10/16/24 8:25 PM, olcott wrote:
On 10/16/2024 6:44 AM, Richard Damon wrote:
On 10/15/24 10:23 PM, olcott wrote:
On 10/15/2024 9:11 PM, Richard Damon wrote:
On 10/15/24 4:01 PM, olcott wrote:
On 10/15/2024 2:33 PM, joes wrote:
Am Tue, 15 Oct 2024 13:25:36 -0500 schrieb olcott:
On 10/15/2024 10:17 AM, joes wrote:
Am Tue, 15 Oct 2024 08:11:30 -0500 schrieb olcott:
On 10/15/2024 6:35 AM, Richard Damon wrote:
On 10/14/24 10:13 PM, olcott wrote:
On 10/14/2024 6:50 PM, Richard Damon wrote:
On 10/14/24 11:18 AM, olcott wrote:
On 10/14/2024 7:06 AM, joes wrote:
Am Mon, 14 Oct 2024 04:49:22 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>> On 10/14/2024 4:04 AM, Mikko wrote:
On 2024-10-13 12:53:12 +0000, olcott said:
https://chatgpt.com/
share/6709e046-4794-8011-98b7-27066fb49f3e When
you click on the link and try to explain how HHH must be >>>>>>>>>>>>>>> wrong when
it reports that DDD does not terminate because DDD does >>>>>>>>>>>>>>> terminate it
will explain your mistake to you.
I did that, and it admitted that DDD halts, it just tries >>>>>>>>>>>>>> to justify
why a wrong answer must be right.
It explains in great detail that another different DDD >>>>>>>>>>>>> (same machine
code different process context) seems to terminate only >>>>>>>>>>>>> because the
recursive emulation that it specifies has been aborted at >>>>>>>>>>>>> its second
recursive call.
Yes! It really has different code, by way of the static Root >>>>>>>>>>>> variable.
No wonder it behaves differently.
There are no static root variables. There never has been any >>>>>>>>>>> "not a pure
function of its inputs" aspect to emulation.
Oh, did you take out the check if HHH is the root simulator? >>>>>>>>>>
There is some code that was obsolete several years ago.
No, that code is still active. it is the source of the value for >>>>>>>> the variable Root that is passed around, and is checked in the >>>>>>>> code to alter the behavior.
It has no effect on the trace itself.
Yes it does.
HHH is correctly emulating (not simulating) the x86 language
finite string of DDD including emulating the finite string of
itself emulating the finite string of DDD up until the point
where the emulated emulated DDD would call HHH(DDD) again.
Nope, not to a degree that determine the final behavior of the input.
This is your ADD. You are responding to something that I did not say.
Like I said that I do, try rereading the above paragraph sixteen times.
I will dumb it down for you so you can get the gist of it.
HHH correctly emulates N steps of DDD therefore N steps of
DDD are correctly emulated by HHH.
Right, but just because N steps don't get to the return, doesn't mean
that the input doesn't return.
This is just over your head.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
When DDD is correctly emulated by HHH according
to the semantics of the x86 language DDD cannot
possibly reach its own machine address [00002183]
no matter what HHH does.
But it is also a fact that the HHH that tries to correctly emulate that
DDD in a way that shows the final behavior of that input, doesn't ever
answer.
Since your HHH does abort its emulation, to give an answer, it doesn't
do a proper "correct emulation" by the definition that allows it to say something about the final behavior of DDD, so that fact isn't applicable.
But, the actually correct and complete emulation of that DDD (that
calls that HHH that does abort and return and thus not show what you
claim) does reach the return statement, showing that the actually
correct emulation reaches that point, and thus HHH is wrong.
It also shows that you are nothing but a stupid liar that doesn't know
what he is talking about.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)