(no title)
balddenimhero | 6 years ago
> There is no need to define “game progress” or implement a naive game AI, as formal verification methods appear to require.
> The mathematical verification code is about one-third the size of the formal verification code presented by the TTTM author
Most of the author's argumentation stems from the different levels of modelling. He pursues verification at model-level. That is, he does the interpretation that a "game progress"/"native game AI" would provide, and lifts the problem from the source-level to a formal representation as Markov process.
With that in mind, it should be clear that reasoning on that higher level can be done more efficiently. In fact, if the author of TTTM would have chosen to verify just the transition relation, an even simpler modelling would have sufficed, e.g. via Prism, ITSTools/GAL, SMV.
I just want to stress that the author of TTTM did not just formally verify that the concrete transition relation can not reach a "bad state", but proved that the actual implementation indeed cannot reach said states. For example, this also includes proving that the game's pseudo-random generation of initial states is safe to use.
> The TTTM formal verification code requires a value called MAX_FINISH_DEPTH, which represents the maximum number of steps required to finish the game from any valid state. It is unclear how the TTTM author arrived at the number 18, but the value can easily be calculated using the matrix representation of the game.
Again, when reasoning at the level of an actual implementation, i.e. software/binaries, such high-level reasoning is not applicable. Therefore, when employing bounded verification techniques, an educated guess about a sufficiently high number of steps must be provided.
tptacek|6 years ago
balddenimhero|6 years ago
> The mathematical method described here has a number of advantages over formal verification, including reduced code size and complexity.
My comment was intended to stress that the authors achieved different things. This article proved that the game design is sound, i.e. verification at model-level, while the original one proved that the implementation cannot reach certain undesired states. Both are perfectly reasonable, justifiable and necessary.