Re: People are still trying to get away with disagreeing with the semantics of the x86 language

On 6/30/24 5:37 PM, olcott wrote:

On 6/30/2024 2:31 PM, Richard Damon wrote:

On 6/30/24 10:07 AM, olcott wrote:

On 6/30/2024 7:34 AM, Richard Damon wrote:

On 6/29/24 10:46 PM, olcott wrote:

On 6/29/2024 6:46 PM, Richard Damon wrote:

On 6/29/24 6:54 PM, olcott wrote:

On 6/29/2024 4:19 PM, Richard Damon wrote:

On 6/29/24 4:33 PM, olcott wrote:

On 6/29/2024 3:25 PM, Richard Damon wrote:

On 6/29/24 4:17 PM, olcott wrote:

On 6/29/2024 3:10 PM, Richard Damon wrote:

On 6/29/24 3:25 PM, olcott wrote:

On 6/29/2024 2:08 PM, Richard Damon wrote:

On 6/29/24 2:47 PM, olcott wrote:

On 6/29/2024 1:38 PM, Richard Damon wrote:

On 6/29/24 2:06 PM, olcott wrote:

>
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
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.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>

>
>
>
But that only applies if H determines a CORRECT SIMULATION per HIS definition does not halt
.
That means the DIRECT EXECUTION of the program represented by the input does not halt, since that is the DEFINITION of the results of a correct simuation.
>
That also requires that the simulation does not stop until it reaches a final state. You H neither does that nor correctly determines that (since it does halt) thus you can never use the second paragraph to be allowed to abort, even though you do anyway, which is why you get the wrong answer.
>

>

>
*N steps of correct simulation are specified*
H correctly simulates its input D until H
H correctly simulates its input D until H
H correctly simulates its input D until H
H correctly simulates its input D until H

>
Which does not determine the ACTUAL behavor
>

>
_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]
>
That you already know that it does prove that DDD correctly
emulated by HHH would never stop running unless aborted
or out-of-memory error
>
*proves that you are trying to get away with a bald-faced lie*
I really hope that you repent before it is too late.
>
>

>
Nope, just shows your stupidity, as the above code has NO defined behavior as it accesses code that is not defined by it.
>

>
*Its behavior is completely defined by*
(a) The finite string x86 machine code that includes
     the recursive emulation call from DDD to HHH(DDD).

>
But by the semantics of the x86 langugage, the call to HHH does NOT do a "recursive simulation" since that is not a term in that language.
>
The Call to HHH just cause the
>

>
(b) The semantics of the x86 language.
>
(c) That HHH is an x86 emulator that correctly emulates
     N steps of DDD.

>
Which isn't an ACTUALY correct emulation, but only a PARTIAL correct emulation (since correct emulation implies EVERY instruction but a terminal one is followed by the next instruction).
>
The key fact is that PARTIAL emulation doesn't reveal the future of the behavior past the point of the emulation.

>
In other words you are trying to get away with claiming
that professor Sipser made a stupid mistake:
>
H correctly simulates its input D until H correctly determines
that its simulated D would never stop running unless aborted

>
Nope, he just laid a trap that you fell into.
>

>
He could not have possibly laid any trap you dumb bunny.
All of the words were my own verbatim words. It took me
two years to compose those exact words.
>

>
Right, and he could have seen the errors in your apparent misunderstanding of the words and accepted them, knowing that they were actually meaningless.
>

The ONLY simulation that Professor Sipser accepts as correct, is one that shows EXACTLY the behavior of the machine being simulated.
>

>
So you are stupid enough to believe that professor Sipser
is stupid enough to to try and get away with disagreeing
with the semantics of the x86 language?

>
The question said NOTHING of the x86 language, so it doesn't matter.
>

>
Liar Liar pants on fire !!!
Liar Liar pants on fire !!!
Liar Liar pants on fire !!!
Liar Liar pants on fire !!!
Liar Liar pants on fire !!!

>
But the question to Professor Sipser was, as you quoted:
>
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
   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.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>
>
Which said NOTHING about the x86 language,
>
So, who is the liar now?
>

>
_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]
>
The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.
>

>
Which wasn't what we were talking about with Professor Sipser, who never saw any of that.
>
I guess you just have a major brain malfunction and can't keep your lies straight.
>
This just proves your unreliability when it comes to statements

>
Partial halt deciders constructed for the x86 language
are isomorphic to this termination analyzer build for
the C programming language.

>
Which still has nothing to do with you LYING about your question to Professor Sipser.
>
And x86 is not fully isomorphic to the C programming language.
>
The x86 language is probably easier to simulate but harder to decide on, because it can create more complicated interactions.
>
Note, there isn't a trivial translation between x86 and C (or LLVM). C to LLVM to x86 is algorithmically doable, but with a lot of options at each step. And when doing the reverse, you normally don't get anything like the original code you started with.
>
And then we get to the fact that "Halt Deciding" and "Termination Analying" are DIFFERENT problems, Halt Deciding being if a particular Program/Input will halt when it is run, while Termination Analysers answer if there is ANY input that might make a given machine not Halt. A much different problem (which you clearly don't understand).
>

>
*AProVE: Non-Termination Witnesses for C Programs*
To prove (non-)termination of a C program, AProVE uses the
Clang compiler [7] to translate it to the intermediate
representation of the LLVM framework [15]. Then AProVE
symbolically executes the LLVM program and uses abstraction
to obtain a finite symbolic execution graph (SEG) containing
all possible program runs.
https://link.springer.com/content/pdf/10.1007/978-3-030-99527-0_21.pdf

>
Which isn't based on "Pure Emulation" like your deciders are. There is a lot of pre-work done to determine what parts might need to be emulated. Note, since "Termination Analyzers" don't have an input to the program, the "emulation" they do needs to be different, but looking at the mapping of possible states to possible states.
>

>
Even a Turing machine based partial halt decider is
locked in to the Turing Machine description language.
Is this really over your head?
>

>
But there isn't a single Turing Machine Description Language that all UTMs use.
>
Also, the Theory isn't about "Partial" Halt Deciders, as those are numerous, but about Correct Halt Decider (implied Complete, i.e. handles ALL inputs), so switching to partial decider is just a deceitful dodge.
>
It is still true that the xemantics of the x86 language define the behavior of a set of bytes, as the behavior when you ACTUALLY RUN THEM, and nothing else.
>

>
That stupid idea forces "interpreting" the call to HHH(DDD)
from DDD simulated by HHH to disagree with the x86 language
and return when the x86 language says this is impossible.

>
Why do you say that?
>
By the x86 language, HHH is just a series of instructions to do something.
>

 Then what you are saying here are just words that are
about something or other and no more specific than that.

No, since you have defined that meaning is based on the x86 instructions set, and its correct emulation, then the ONLY thing a "call HHH" instruction can mean, is that the next steps of the behavior will be the emulation of the instructions of HHH.
There is no "option" to define that HHH is an emulator and that the call to HHH just starts an emulation, because that isn't behavior defined in the x86 instruction set.
Also, HHH is no "a x86 emulator" but a CONDITIONAL x86 emulator, and that fact is important. For one thing, it means that you can not, even under an "equivalency" of emulation replace the emulation of the emulator with the machie it is emulating as you are doing, as that is only valid for an UNCONDITIONAL emulation, which isn't what HHH does.

 

And without the bytes specified, we don't know what they do.
>
There is no way to try to specify AT THE x86 instruction level, that HHH is an "emulator" as that isn't a concept at the x86 instruction level.
>
Also, it is a LIE to say HHH is a "x86 Emulator", as that term, unadorned, means it is an UNCONDITIONAL emulator (like a UTM) which is isn't since you define that it has the power to decide that its input is non-halting (and might do it incorrectly) and thus its emulation at each step is conditional on that logic.
>

>
_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]
>

And that means, you need the code for the COMPLETE program (or sub-program) to talk about behavior, which includes the code for everything that one piece of code calls, so for your D family of inputs, the H family of deciders that it has been paired with.

>

>