Talk:Swissen Machine
Difficulties of the Swissen Machine, definition 1
Whoever has defined the Hugo language, who claimed that Hugo conforms part of the Swissen Machine, has an invalid point and might have not obtained the right idea of the Swissen Machine. In this subsection, it will be shown that the Swissen Machine is trivial, and the exististance of it is impossible.
End Of File consderations
The "Hugo" language described above requires 2 symbols: the symbol 1 and the End Of File; The End Of File stops the program from continuously running. Otherwise, Hugo will not reach the part where it prints the ASCII character. This contradicts with part A of the criteria, which explicitly states that it uses the one state.
There is already one changable state in Hugo, which is the state that shows whether Hugo will run or not. When Hugo's instruction processor reaches the End Of File, it negates that state and does an alternative state transition. This shows that Hugo can do logical operations, which contradicts with the definition "a Swissen Machine runs on only state 1".
All language/machine definitions cannot fullfill the definition of the Swissen Machine
This mechanism can be extended to all languages that contains commands. For languages that run in implicit infinite loops, an End Of File character has to specified so that the language can loop back to whatever place the reference documentation specified. For languages that run sequentially, an End Of File character has to be specified so that the language can stop normally. This mechanism cannot be avoided in every language, as when a command list is presented in a file, it(somehow) has to contain the End Of File character. Moreover, this cannot be avoided in a language where everything is an End Of File character, as there is already a process that executes a file, and it can already halt conditionally when an EOF character was encountered.
What about taking a program from Standard input?
All programs taken from Standard Input seems to function normally even when all commands are no-operation commands. However, there is still a state transition behind the scene; the characters taken from Standard Input has to be preserved somewhere, or else the user cannot input commands. There is an input copier behind the scene, and it does not matter whether it discards the input; the state of the input has changed anyway.
A computer with no programs
You may argue that a computer with no programs fullfills the definition of the Swissen Machine. However, it still cannot succeed in it, as it already implements two states when it starts up and shuts down. This is inevitable if you want to call it a computer, because a computer/machine has to succeed in doing a computation. If it does not start up and shut down(which is indeed a computation), then it does not perform computation at all, which contradicts with the definition of the computer.
The definition of "Machine" is "A piece of equipment with moving parts that is designed to do a particular job". Doing a particular job is an extension of doing a computation; a person can not want a computer to do anything they want except of doing computation. Also, doing a particular job changes the state of various environmental variables, which shows that any machine still supports state transition. This contradicts with the 1st definition of the Swissen Machine.
Partial Conclusion
Implementing the Swissen machine is trivial and impossible, and even if a Swissen machine has been documented, it cannot perform useful computations by any means. Any language/architecture cannot avoid state transitions no matter what they do to the language. In fact, the Swissen Machine is a computer architecure, and it(too) cannot fullfill its own definitions.
We have come up to the conclusion that the Swissen Machine cannot fullfill the definitions of the Swissen Machine, which turns out to be a contradiction.
Definition 2
Definition 2 states that a machine has to "Instead uses the one state it has to perform computations based on environmental factors." In fact, this can be counterargumented quite easily that every computer has a stable state. For example, the instructions of a computer is stable; its instruction inputting mechanism is stable; its instruction counter is also stable accordingly. As for the computer that only has an End Of File instruction, this can be shown quite easily that its instruction processor and its instruction set input is stable. Now, we came up with the conclusion that all computers fullfill the definition 2 of the Swissen machine, the definition of Hugo in the page is also insignificant.
The defintion's significance
Definition 2 of the Swissen machine is trivial, as it includes every computer in this world, and this definition does not do anything to limit down the number of computers that fullfill this definition. Now that Definition 1 does not include any computers in its definition, Definition 2 cannot limit down the number of computers that are in this null set. Everything that you pick in a null set is nothing. Also, it cannot extend this null set; is there everything in a null set?
Conclusion
Definition 2 of the Swissen machine is not significant; it does not contribute anything to the validity of the definition of the Swissen Machine. This verifies that the Swissen Machine is impossible to exist.
- The Swissen Machine was never meant to exist. It was obvious when I said, "simple computer knowledge should tell you that this would be near impossible to implement IRL." However, it was fun to create a hypothetical that involves a computer with one state. This induces the question "Could this work?", and makes people think. Jussef Swissen (talk) 12:14, 16 July 2019 (UTC)
- The idea of having two symbols is a non-issue, because symbols and states are not the same thing. But if it makes you happy, let's create an interpreter that only accepts empty files, ie files containing only the EOF character. The next point I'd like to address is that the computer does have at least two states, on and off. But we can counter this with an interpreter that never turns off. So during compile time non-empty files are rejected, and during run time the program runs indefinitely doing nothing - a valid if completely pointless machine. Plokmijnuhby (talk) 20:56, 25 July 2019 (UTC)
- In fact, your compiler+interpreter is invalid, because it has 4 states in total; for the compiler, it is quite obvious that it has 2 states: accepted and not accepted. For the interpreter, it is quite hard to find but still exists: there are two states in the interpreter: looping and non-looping. If you want to execute a program, you have to load it into memory (it does not matter whether you discard it or not afterwards); that makes sure that the interpreter is in the non-looping state. After it has done loading the program into memory, it enters the looping state, where it loops forever non-stoppingly. So, no, a machine is impossible to construct that fullfills the definition of the Swissen machine. --A (talk) 10:26, 26 July 2019 (UTC)
- What if the interpreter, however, doesn't reject any file that's not an EOF file, and also only runs the file given to it in its source code (Assuming the interpreter mentioned by User: Plokmijnuhby prompts the user for a file to open at runtime.) I believe this would eliminate the remaining states, and become a valid Swissen machine. Jussef Swissen (talk) 12:01, 26 July 2019 (UTC)
- Prompting for the source file takes time, and storing the program given into the source code also takes time (of course, if you use an array, a list, etc. to store the file contents, then it will be an O(1) algorithm. Prompting for the source file still takes time, as prompting takes at least one instruction, and it has to be at least an O(1) algorithm.). Given that these processes exist (an O(0) algorithm shows that the algorithm does not exist), this shows that your limits still have separate states (for the first one, the states are prompting and executing; for the second one, the states are loading program and running program). Your restrictions still does not create a valid Swissen Machine, as there are still different states in your limited machine. --A (talk) 13:36, 26 July 2019 (UTC)
- What if the contents of the file itself is incorporated into the source code of the interpreter? That way, the program isn't loaded, but is instead executed as part of the interpreter. Jussef Swissen (talk) 02:40, 28 July 2019 (UTC)
- If the contents of the file was incorporated into the source code of the intepreter, it takes the interpreter time to load it. Storing the program given into the source code of the interpreter takes time (of course, if you use an array, a list, etc. to store the file contents, then it will be an O(1) algorithm. Given that this process exists (an O(0) algorithm shows that the algorithm does not exist), this shows that your limits still have separate states (loading program and running program). Even if your program was given to the source code, there are still internal state changes in the interpreter. --A (talk) 03:41, 28 July 2019 (UTC)
- What if the contents of the file itself is incorporated into the source code of the interpreter? That way, the program isn't loaded, but is instead executed as part of the interpreter. Jussef Swissen (talk) 02:40, 28 July 2019 (UTC)
- Prompting for the source file takes time, and storing the program given into the source code also takes time (of course, if you use an array, a list, etc. to store the file contents, then it will be an O(1) algorithm. Prompting for the source file still takes time, as prompting takes at least one instruction, and it has to be at least an O(1) algorithm.). Given that these processes exist (an O(0) algorithm shows that the algorithm does not exist), this shows that your limits still have separate states (for the first one, the states are prompting and executing; for the second one, the states are loading program and running program). Your restrictions still does not create a valid Swissen Machine, as there are still different states in your limited machine. --A (talk) 13:36, 26 July 2019 (UTC)
- What if the interpreter, however, doesn't reject any file that's not an EOF file, and also only runs the file given to it in its source code (Assuming the interpreter mentioned by User: Plokmijnuhby prompts the user for a file to open at runtime.) I believe this would eliminate the remaining states, and become a valid Swissen machine. Jussef Swissen (talk) 12:01, 26 July 2019 (UTC)
- In fact, your compiler+interpreter is invalid, because it has 4 states in total; for the compiler, it is quite obvious that it has 2 states: accepted and not accepted. For the interpreter, it is quite hard to find but still exists: there are two states in the interpreter: looping and non-looping. If you want to execute a program, you have to load it into memory (it does not matter whether you discard it or not afterwards); that makes sure that the interpreter is in the non-looping state. After it has done loading the program into memory, it enters the looping state, where it loops forever non-stoppingly. So, no, a machine is impossible to construct that fullfills the definition of the Swissen machine. --A (talk) 10:26, 26 July 2019 (UTC)