PeteOlcott wrote: ↑Sun May 08, 2022 8:58 pm
Eventually, the whole process may terminate, which we achieve in a Turing machine by putting it into a halt state. A Turing machine is said to halt whenever it reaches a configuration for which δ is not defined; this is possible because δ is a partial function. In fact, we will assume that no transitions are defined for any final state, so the Turing machine will halt whenever it enters a final state. (Linz-1990:234)
Do you understand that you, as the observer of the Turing machine cannot determine whether it halted because it reached a final state; or whether it halted because it reached an undefined state.
That's why Turing machines suck! They are terrible models of computation if you expect them to interact with the outside world.
If you want to differentiate between abort and halt you need an effect system which signals an exit status!
exit(0) -> Terminated without error (halt)
exit(1) -> Terminated with error (abort)
PeteOlcott wrote: ↑Sun May 08, 2022 8:58 pm
Eventually, the whole process may terminate, which we achieve in a Turing machine by putting it into a halt state. A Turing machine is said to halt whenever it reaches a configuration for which δ is not defined; this is possible because δ is a partial function. In fact, we will assume that no transitions are defined for any final state, so the Turing machine will halt whenever it enters a final state. (Linz-1990:234)
As soon as you allow for signaling you are no longer talking about computation, you are talking about process algebras. Distributed dynamic systems.
PeteOlcott wrote: ↑Sun May 08, 2022 8:58 pm
Eventually, the whole process may terminate, which we achieve in a Turing machine by putting it into a halt state. A Turing machine is said to halt whenever it reaches a configuration for which δ is not defined; this is possible because δ is a partial function. In fact, we will assume that no transitions are defined for any final state, so the Turing machine will halt whenever it enters a final state. (Linz-1990:234)
Do you understand that you, as the observer of the Turing machine cannot determine whether it halted because it reached a final state; or whether it halted because it reached an undefined state.
Since I am creating a Turing machine interpreter from scratch on the basis of this system I know that your statement is ridiculously ignorant: http://www.lns.mit.edu/~dsw/turing/turing.html
It easy for a UTM to see that its simulated slave TM reaches a point where there are no transitions out of the current state of this slave TM.
PeteOlcott wrote: ↑Sun May 08, 2022 9:18 pm
Since I am creating a Turing machine interpreter from scratch on the basis of this system I know that your statement is ridiculously ignorant: http://www.lns.mit.edu/~dsw/turing/turing.html
It easy for one TM to see that its simulated slave TM reaches a point where there are no transitions out of its current state.
Sigh. Idiot.
There is no way for you to prove the liveness property of a process you are executing because you have the wait() operator.
So you can trivially implement a system of two processes (A and B) such that A waits until B terminates and B waits until A terminates.
PeteOlcott wrote: ↑Sun May 08, 2022 9:18 pm
Since I am creating a Turing machine interpreter from scratch on the basis of this system I know that your statement is ridiculously ignorant: http://www.lns.mit.edu/~dsw/turing/turing.html
It easy for one TM to see that its simulated slave TM reaches a point where there are no transitions out of its current state.
Sigh. Idiot.
There is no way for you to prove the liveness property of a process you are executing because you have the wait() operator.
So you can trivially implement a system of two processes (A and B) such that A waits until B terminates and B waits until A terminates.
If your interpreter solves this problem then you have solved the Dining philosophers problem.
It is a very common practice in operating system design to make context switches between processes even when there is only one actual physical processor. I implemented this in the x86utm operating system. I had to write all of the operating system calls myself from scratch. x86utm directly executes the COFF object file output from the Microsoft C compiler.
PeteOlcott wrote: ↑Sun May 08, 2022 9:31 pm
It is a very common practice in operating system design to make context switches between processes even when there is only one actual physical processor. I implemented this in the x86utm operating system. I had to write all of the operating system calls myself from scratch. x86utm directly executes the COFF object file output from the Microsoft C compiler.
Yeah.... it's a very common practice. Context switches are handled by your operating system. Without getting bogged down into the various multi-tasking strategies (cooperative vs pre-emptive etc.)
The operating system is a process which DOES NOT HALT. It loops indefinitely by design until signaled to terminate.
Literally every daemon/background process has an infinite control loop - a conditional jump!
PeteOlcott wrote: ↑Sun May 08, 2022 9:31 pm
It is a very common practice in operating system design to make context switches between processes even when there is only one actual physical processor. I implemented this in the x86utm operating system. I had to write all of the operating system calls myself from scratch. x86utm directly executes the COFF object file output from the Microsoft C compiler.
Yeah.... it's a very common practice. Context switches are handled by your operating system. Without getting bogged down into the various multi-tasking strategies (cooperative vs pre-emptive etc.)
The operating system is a process which DOES NOT HALT. It loops indefinitely by design. and until instructed to terminate.
Literally every daemon/background process has an infinite control loop.
x86utm executes H which invokes an excellent open source x86 emulator to emulate the input to H(P,P) in debug step mode. https://www.researchgate.net/publicatio ... ulation_V5
Shows exactly how H(P,P) correctly determines that its input does not halt.
PeteOlcott wrote: ↑Sun May 08, 2022 9:41 pm
x86utm executes H which invokes an excellent open source x86 emulator to emulate the input to H(P,P) in debug step mode. https://www.researchgate.net/publicatio ... ulation_V5
Shows exactly how H(P,P) correctly determines that its input does not halt.
Debug step mode
The debugger itself is subject to non-termination! Prove that the debugger will terminate!
The debugger terminates only after the program being debugged terminates.
If the program being debugged doesn't terminate then the debugger won't terminate either. Unless you force premature termination! Say ... via timeouts!
So now you need a debugger to debug the debugger to debug the debugger to debug the debugger...
H simulates its input one x86 instruction at a time until it correctly matches a non-halting behavior pattern, as H(P,P) correctly does. Then it aborts this simulation and rejects this input as H(P,P) correctly does.
PeteOlcott wrote: ↑Sun May 08, 2022 9:54 pm
H simulates its input one x86 instruction at a time until it correctly matches a non-halting behavior pattern, as H(P,P) correctly does. Then it aborts this simulation and rejects this input as H(P,P) correctly does.
This non-halting C program doesn't exhibit non-halting behavior!
It doesn't exhibit ANY behavior!
PeteOlcott wrote: ↑Sun May 08, 2022 9:54 pm
H simulates its input one x86 instruction at a time until it correctly matches a non-halting behavior pattern, as H(P,P) correctly does. Then it aborts this simulation and rejects this input as H(P,P) correctly does.
This non-halting C program doesn't exhibit non-halting behavior!
It doesn't exhibit ANY behavior!
PeteOlcott wrote: ↑Sun May 08, 2022 9:54 pm
H simulates its input one x86 instruction at a time until it correctly matches a non-halting behavior pattern, as H(P,P) correctly does. Then it aborts this simulation and rejects this input as H(P,P) correctly does.
This non-halting C program doesn't exhibit non-halting behavior!
It doesn't exhibit ANY behavior!
PeteOlcott wrote: ↑Sun May 08, 2022 9:54 pm
H simulates its input one x86 instruction at a time until it correctly matches a non-halting behavior pattern, as H(P,P) correctly does. Then it aborts this simulation and rejects this input as H(P,P) correctly does.
This non-halting C program doesn't exhibit non-halting behavior!
It doesn't exhibit ANY behavior!