Re: Bad faith and dishonesty

On 29/05/2025 17:42, olcott wrote:

On 5/29/2025 10:49 AM, Fred. Zwarts wrote:

Op 29.mei.2025 om 17:45 schreef olcott:

On 5/29/2025 3:33 AM, Mikko wrote:

On 2025-05-28 19:41:23 +0000, olcott said:
>

On 5/28/2025 1:54 PM, Fred. Zwarts wrote:

Op 28.mei.2025 om 17:02 schreef olcott:

On 5/28/2025 3:40 AM, Fred. Zwarts wrote:

Op 27.mei.2025 om 16:51 schreef olcott:

On 5/27/2025 3:33 AM, Fred. Zwarts wrote:

Op 26.mei.2025 om 21:44 schreef olcott:

On 5/26/2025 2:30 PM, Fred. Zwarts wrote:

Op 26.mei.2025 om 21:11 schreef olcott:

On 5/26/2025 2:02 PM, Fred. Zwarts wrote:

Op 26.mei.2025 om 20:48 schreef olcott:

On 5/26/2025 1:34 PM, Fred. Zwarts wrote:

Op 26.mei.2025 om 18:21 schreef olcott:

On 5/26/2025 11:11 AM, Fred. Zwarts wrote:

Op 26.mei.2025 om 17:25 schreef olcott:

On 5/26/2025 3:42 AM, Fred. Zwarts wrote:

Op 26.mei.2025 om 04:22 schreef olcott:

On 5/25/2025 9:00 PM, Mike Terry wrote:

On 25/05/2025 21:30, olcott wrote:

On 5/25/2025 3:05 PM, dbush wrote:

On 5/25/2025 3:56 PM, olcott wrote:

*Mike understood this perfectly*
On 5/14/2025 7:36 PM, Mike Terry wrote:
--------- Sipser quote -----
    If simulating halt decider H correctly simulates its input D until H
    correctly determines that its simulated D would never stop running
    unless aborted then H can abort its simulation of D and correctly
    report that D specifies a non-halting sequence of configurations.
----------------------------
>
we can easily interpret that as saying exactly what I said a SHD
does above.  It tells PO that in the tight loop example, H correctly
simulates as far as [A], at which point it correctly determines that
"its simulated input would never stop running unless aborted", so
it can decide "non-halting".
>
All correct and natural, and no deliberately
false premises to mislead PO.
>
On 5/14/2025 7:36 PM, Mike Terry wrote:
https://al.howardknight.net/? STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont- email.me%3E

>
And you dishonestly left out the part that immediately follows where he states that you are wrong:
>

>
*VERFIED FACT*
Mike Terry Proves ---
How the requirements that Professor Sipser agreed to are exactly met

>
Just for the record:
>
1)  I didn't offer any proofs of /anything/
>
-  I did explain how Sipser's words can be naturally interpreted as explaining
    how a simulating halt decider can operate. [That is not a proof.]
>

>
It seems like proof to me.
When-so-ever anyone provides complete and correct reasoning
showing how an expression of language is true, this is a proof.
>

-  I also explained why that explanation *doesn't* apply to your HHH/ DDD pair
>

>
Yes you did do this.
>
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated
far enough, but HHH simply /doesn't/ go far enough
>
_DDD()
[00002192] 55             push ebp
[00002193] 8bec           mov ebp,esp
[00002195] 6892210000     push 00002192
[0000219a] e833f4ffff     call 000015d2  // call HHH
[0000219f] 83c404         add esp,+04
[000021a2] 5d             pop ebp
[000021a3] c3             ret
Size in bytes:(0018) [000021a3]
>
I use the simpler DDD because everyone here gets
completely confused even by this simple example.
>
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
>
Once you and I work through this one point I may
finally have complete closure.

Again you make the same mistake by not only changing the decider, but also the input.
We are discussing the input where DDD calls a HHH that aborts after one cycle.

>
*No we are not. We are discussing this*
>
*On 5/14/2025 7:36 PM, Mike Terry wrote*
the simulated input (DD) /does/ stop running if simulated
far enough, but HHH simply /doesn't/ go far enough
>

And that is the bug in HHH. It does not go far enough.

>
No Mike is just wrong.
>
_DDD()
[00002192] 55             push ebp
[00002193] 8bec           mov ebp,esp
[00002195] 6892210000     push 00002192
[0000219a] e833f4ffff     call 000015d2  // call HHH
[0000219f] 83c404         add esp,+04
[000021a2] 5d             pop ebp
[000021a3] c3             ret
Size in bytes:(0018) [000021a3]
>
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
>

>
>
No, *you* are just wrong.
A correct simulation needs only one recursion more than the simulated HHH. The bug in HHH is, that it aborts one cycle too early.

>
The outermost HHH always sees one whole recursive emulation
more than the next inner one.

>
Only if you change the input with the simulator.
Every simulator that tries to simulate itself, fails.

>
My code proves otherwise.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
>

Your code proves exactly my point. That Halt7.c is part of the input and specifies an abort, so the program specified by the input halts. But HHH fails to see that. It does not even start to simulate itself, but aborts at that point. So, it is in no way a proof that your simulator is able to simulate itself, let alone to simulate itself correctly.

>
It is a verified fact that HHH does simulate itself simulating DDD.
If you are too incompetent to understand that this does not count
as a rebuttal.
>

>
It seems you do not understand what 'simulate' means. HHH does not simulate itself, but aborts the simulation at the point where the simulation of itself should start.

>
Counter-factual, nitwit.
>

It does not simulate itself, but only makes some false assumptions about itself, in particular it assumes that 'itself' does not halt.
That you do not understand your own code is in no way a rebuttal for my claim that no simulator is able to simulate itself up to the end.

>
>

>
It seems you do not even understand what 'counter-factual' means. Your own traces show that the simulation is aborted without simulating the call instruction that calls HHH.

>
It does not show this.
>
New slave_stack at:14e33e
is the point where HHH begins simulating itself simulating DDD.
We can see that this *is* happening because it derives the
correct execution trace of DDD simulated by HHH.
>
  machine   stack     stack     machine        assembly
  address   address   data      code           language
  ========  ========  ========  ============== =============
[000021be][00103872][00000000] 55             push ebp
[000021bf][00103872][00000000] 8bec           mov ebp,esp
[000021c1][0010386e][0000219e] 689e210000     push 0000219e // push DDD
[000021c6][0010386a][000021cb] e823f4ffff     call 000015ee // call HHH

>
You see? The call is not properly simulated.

>
No stupid you are wrong.
I prove that HHH is simulating itself simulating DDD
by the next lines of the correctly simulated DDD.

>
The trace of the simulation of HHH is not shown and the trace of other
simulations do not prove that HHH is simulated. The traces don't show
which simulator produced them.
>
If you don't know how to make a better output program you are free to ask.
>

>
Mike has already verified this, see what he just said.
>
On 5/28/2025 8:02 PM, Mike Terry wrote:
 > Perhaps you slightly misunderstand the presented trace.
 > The instructions starting at 000015ee /are/ simulated,
 > but then simply suppressed from the output PO shows.
>
>

>
And he also added that it does not make a difference, because HHH still forgets to count the conditional branch instruction within the simulation of HHH.
Of course, you remove this most important part of his contribution.

 We must achieve 100% complete closure on each point
one-at-a-time and not endlessly flit back and forth
across many different points never achieving closure
on any of them.
 THIS POINT IS NOW CLOSED
*HHH does correctly simulate itself simulating DDD*
 

Hang on!  HHH's simulation is not "correct" because the simulated HHH does not follow the same code path as the directly executed HHH.  You're forgetting about your misuse of static variables in halt7.c!  That is something you might potentially fix (if you were able to see how to fix it), but while you decline to do that you can't claim your code "correctly simulates" anything, or that it "proves" anything...
Mike.