It might be off topic but I just had this thought and like to write down… If you treat your program (and your problem) as math, then it is necessary to explici

It might be off topic but I just had this thought and like to write down… If you treat your program (and your problem) as math, then it is necessary to explicitly define all its boundaries. However many (most) problems in real life are not strictly math problems due to their nature of ambiguity. The ambiguity has its physical source of unknown boundaries. For example, you may think you only need 32-bit integer and you may be sure of it today, but your assessment may change in the future. Similarly, you may think today you should use arbitrary precision and the constant boundary check does not matter, but it may matter some day. In the effort to eliminate undefined behavior, we are projecting our ideas from real world onto math realm. That projection may be quite lossy. I am aware that the actual compiled program is always well defined and can be a perfect mathematical object, but it's source as a language do have ambiguity -- e.g. compiler implementations and undefined behavior. Ambiguous language sometimes can express ideas better than a mathematical language -- if we treat the legacy of our code more in its source rather than in its binary.