Frequently Asked Questions¶
- Why is it so that you cannot have compound/layered boundary conditions in a deCheem session?
- From a linguistic point of view, boundary conditions need to be consistent within itself. We should therefore not have contradictory filtering properties within a single boundary condition (e.g. is_cat=true AND is_dog=true), as the results would not make sense unless we are explicitly testing for the possibility of hybrid situations. If there are multiple boundary conditions, they should be tested in parallel instead of in serial, as it will inevitably cause inconsistent or impossible situations.
- Why can conditional-assertion statements be layered then?
- These statements are meant to filter the table of all possibilities, and layering them simply means defining ways in which different versions of this filtered table can be constructed.
- Why is it important to take note of the sequence of the conditional-assertion statements?
- deCheem is meant to help us define situations in the world, and situations are derived from a certain history, which is basically a sequence of events.
- Where should the boundary conditionals be triggered?
- To get clarity on how to handle them, we need to break them down into its components, the filters and the assertions. The assertions of Always, Possible or Never can be included at any point in the world creation process. But the filters can also be inserted any point in the process, or even at the end, as filters do not trigger conditionals (only assertions do). Boundary conditions can be seen as verbose printing of the implications of only the filter of any statement, and if we want verbose printing for the sake of finding out implications for certain boundary filters, we should use only the IF and ELIF types to avoid unintentional additional assertions.