”Computer decisions are binary decisions, representing yes/.no. Computers can’t handle “maybe this” as a decision.”
– Binary is just the most fundamental data type at the very lowest level. Computers are far more capable than humans of instantly doing complex math with very large numbers.
– Computer programs are also entirely capable of doing “maybe this” decisions. Almost every computer program is written to handle unknown data and respond to it in a variety of ways. It is also very possible to make programs that operate with “fuzzy logic”, where various input is used to alter the probability the program will respond in different ways to various combinations of data.
”You are not capable of making a decision tree in more than two dimensions, what makes you think a computer can?”
– While RedDeerGuy1’s questions often are so overly binary in nature that they create bizarre misunderstandings, these questions nevertheless often ask open-ended humorous questions, which allows for an endless variety of possible responses.
– So too for computer programs. The possible branching of a computer program could not only be non-binary, and involve any number of possible responses, but those responses could even change the code itself (though that’s uncommon), which could mean that the flowchart could change as a result of logic.
Flowcharts, however, are a tool to offer human a useful and hopefully clear perspective on how a program operates, to reduce the amount of complexity a human needs to try to understand in their mind, to fully understand the program. So, for most people, it is a good thing that a chart is simple and easy to read. If it can be laid out in two dimensions in a simple-to-understand way, then that’s good. If, on the other hand, a flowchart were presented in multiple dimensions, I would expect that would tend to add complexity to the presentation, rather than help. Unless maybe you have human programmers who are particularly good at relating to such diagrams.
Generally though what you want to do is the opposite. That is, with a complex program, you’d tend to want to break up the logic into multiple two-dimensional flowcharts, so each can be easily understood. Then maybe have other flowcharts showing the relationships between them.
Some programs also have behavior that can’t very easily be flowcharted, because there are many different logic elements working on data, and complicated data is actually driving what tends to happen, in ways that aren’t really something it’s possible to clarify by flowcharting, particularly because there are many elements all doing their own things.
For example, one of my space combat games has a fairly simple high-level flow-chart during combat – it keeps calling the game resolution loop over and over, and another loop draws the display over and over. But the data for the game includes spaceships, AI pilots, and various debris and weapons, all of which have their own logic which may respond to some or all of the other data, which results in the data changing. Some of the logic is about determining what an AI pilot notices about the data, what their simulated mental state is, what they are trying to do, and their attempts to predict what is about to happen in the future, and to maneuver to try to achieve a result by flying the ship using thrusters and weapons.
Some of the logic for that is mathematical, like calculating an interception vector.
All kinds of chaos ensues, but the logic of what a squadron does, or who survives a battle, is more a product of what happens in the data and what it represents. Each low-level system can be usefully flowcharted, and higher-level program navigation can be usefully flowcharted, and so on, but each topic wants its own flowchart (if I bother to flowchart it at all – in practice, I don’t think I flowcharted anything). But the behavior that is seen during combat is an emergent data-driven result of many pieces of logic working together, which holds together and makes coherent sense because of the logic of what the game situation is, how things work, and so on.
