Defactoring: Difference between revisions

Line 40:

# Again, it does not have any obvious musical or mathematical meaning in this context.

# It's a word that was invented for RTT and has no meaning outside of RTT<ref>Here is the tuning list post where it was coined by [[Paul Erlich]]: https://yahootuninggroupsultimatebackup.github.io/tuning-math/topicId_2033.html#2456</ref>.

# It was made up due to false assumptions<ref>Authors note: to be absolutely clear, I don’t care who said what or how misconceptions arose (except insofar as it helps dispel any further misconceptions, some of which certainly may be my own). I have basically infinite sympathy for anyone who gets confused over this topic. It took my good friend Dave and I months of back and forth theorization, argumentation, and diagramming before we were able to settle on an explanation we both understood and agreed upon. I am not intending to get in the business of slinging blame (or credit) around. As far as I’m concerned, as long as we can have meaningful discussion with each other, and hopefully eventually arrive at conclusions that are more musically and intellectually empowering than we had previously, then we’re doing well together. Would I have make these mistakes myself? Yes! I have literally dozens of recent emails proving that I would have gone for the same duality myself, due to a case of asymmetry-phobia.</ref>. Through researching on tuning list archives, Dave and Douglas concluded that the associated concept of "torsion" was first described in January of 2002<ref>See: https://yahootuninggroupsultimatebackup.github.io/tuning-math/topicId_2937 which is also referred to here http://tonalsoft.com/enc/t/torsion.aspx</ref>, with regards to commas used to form Fokker periodicity blocks. The concept of enfactoring was recognized in temperament mappings (though of course it did not yet go by that name), and — because torsion in lists of commas for Fokker blocks looks the same way as enfactoring looks in temperament comma-bases — torsion got conflated with it<ref>See: https://yahootuninggroupsultimatebackup.github.io/tuning-math/topicId_2033.html#2405</ref>. But they can't truly be the same thing; the critical difference is that periodicity blocks do not involve tempering, while temperaments do. In concrete terms, while it can make sense to construct a Fokker block with {{vector|-4 4 -1}} in the middle and {{vector|-8 8 -2}} = 2{{vector|-4 4 -1}} at the edge, it does not make sense to imagine a temperament which tempers out 2{{vector|-4 4 -1}} but does not temper out {{vector|-4 4 -1}}. Unfortunately, however, this critical difference seems to have been overlooked, and so it seemed that enfactored comma-bases exhibited torsion, and thus because mappings are the dual of comma-bases, then enfactoring of a mapping should be the dual of torsion, and because the prefix co- or con- means "dual" (as in vectors and covectors), the term "con-torsion" was coined for it. "Torsion" already has the problem of being an obscure mathematical term that means nothing to most people, "contorsion" just compounds that problem by being made up, and it is made up in order to convey a duality which is false. So while "torsion" could be preserved as a term for the effect on periodicity blocks (though there's almost certainly something more helpful than that, but that's a battle for another day<ref>~~I might suggest~~ we call it a "shredded periodicity block", due to the way how the paths that the multiple parallel generators take around the block look like shreds of paper, were the periodicity block imagined as a sheet of paper run through a paper shredder.</ref><ref>Furthermore, care should be taken to recognize the difference in behavior between, say

# It was made up due to false assumptions<ref>Authors note: to be absolutely clear, I don’t care who said what or how misconceptions arose (except insofar as it helps dispel any further misconceptions, some of which certainly may be my own). I have basically infinite sympathy for anyone who gets confused over this topic. It took my good friend Dave and I months of back and forth theorization, argumentation, and diagramming before we were able to settle on an explanation we both understood and agreed upon. I am not intending to get in the business of slinging blame (or credit) around. As far as I’m concerned, as long as we can have meaningful discussion with each other, and hopefully eventually arrive at conclusions that are more musically and intellectually empowering than we had previously, then we’re doing well together. Would I have make these mistakes myself? Yes! I have literally dozens of recent emails proving that I would have gone for the same duality myself, due to a case of asymmetry-phobia.</ref>. Through researching on tuning list archives, Dave and Douglas concluded that the associated concept of "torsion" was first described in January of 2002<ref>See: https://yahootuninggroupsultimatebackup.github.io/tuning-math/topicId_2937 which is also referred to here http://tonalsoft.com/enc/t/torsion.aspx</ref>, with regards to commas used to form Fokker periodicity blocks. The concept of enfactoring was recognized in temperament mappings (though of course it did not yet go by that name), and — because torsion in lists of commas for Fokker blocks looks the same way as enfactoring looks in temperament comma-bases — torsion got conflated with it<ref>See: https://yahootuninggroupsultimatebackup.github.io/tuning-math/topicId_2033.html#2405</ref>. But they can't truly be the same thing; the critical difference is that periodicity blocks do not involve tempering, while temperaments do. In concrete terms, while it can make sense to construct a Fokker block with {{vector|-4 4 -1}} in the middle and {{vector|-8 8 -2}} = 2{{vector|-4 4 -1}} at the edge, it does not make sense to imagine a temperament which tempers out 2{{vector|-4 4 -1}} but does not temper out {{vector|-4 4 -1}}. Unfortunately, however, this critical difference seems to have been overlooked, and so it seemed that enfactored comma-bases exhibited torsion, and thus because mappings are the dual of comma-bases, then enfactoring of a mapping should be the dual of torsion, and because the prefix co- or con- means "dual" (as in vectors and covectors), the term "con-torsion" was coined for it. "Torsion" already has the problem of being an obscure mathematical term that means nothing to most people, "contorsion" just compounds that problem by being made up, and it is made up in order to convey a duality which is false. So while "torsion" could be preserved as a term for the effect on periodicity blocks (though there's almost certainly something more helpful than that, but that's a battle for another day<ref>Perhaps we call it a "shredded periodicity block", due to the way how the paths that the multiple parallel generators take around the block look like shreds of paper, were the periodicity block imagined as a sheet of paper run through a paper shredder.</ref><ref>Furthermore, care should be taken to recognize the difference in behavior between, say

<math>

\left[

Line 322:

It is not possible for an RREF to be IREF without also being IRREF.

'''[https://en.wikipedia.org/wiki/Hermite_normal_form Hermite Normal Form]''', or '''HNF''', is the last form to discuss. This one's constraints begin with echelon form and integer, therefore every HNF is also IREF. But HNF is not exactly reduced; instead, it is ''normalized'', which — similarly to reduced — is a two-part constraint. Where reduced requires that all pivots be exactly equal to 1, normalized requires only that all pivots be positive (positive integers, of course, due to the other integer constraint). And where reduced requires that all entries in pivot columns besides the pivots are exactly equal to 0, normalized requires only that all entries in pivot columns below the pivots are exactly equal to 0, while entries in pivot columns above the pivots only have to be strictly less than the pivot in the respective column (while still being non-negative).<ref>The exact criteria for HNF are not always consistently agreed upon, however.</ref><ref>There is also a rarely mentioned Hermite Canonical Form, or HCF, described here: http://home.iitk.ac.in/~rksr/html/03CANONICALFACTORIZATIONS.htm, which sort of combines the HNF's normalization constraint and the RREF's reduced constraint (all pivots equal 1, all other entries in pivot columns are 0, both above and below the pivot), but we didn't find it useful because due to its constraint that all pivots be 1, it does not preserve periods that are genuinely unit fractions of an octave. It also doesn't qualify as an echelon form, which becomes apparent only when you use it on rank-deficient matrices, because it doesn't require the rows of all zeros to be at the bottom; instead it (bizarrely~~, as far as I can tell~~, though maybe it's related to how the SNF requires all pivots exactly along the main diagonal) requires the rows to be sorted so that all the pivots fall on the main diagonal.</ref><ref>We are using "row-style" Hermite Normal Form here, not "column-style"; the latter would involve simply flipping everything 90 degrees so that the echelon requirement was that pivots be strictly ''below'' the pivots in the previous ''column'', and that pivot ''rows'' are considered for the normalization constraint rather than pivot ''columns''.</ref> The normalization HNF uses is cool because this constraint, while strictly less strict than the reduced constraint used by RREF, is still strict enough to ensure uniqueness, but loose enough to ensure the integer constraint can be simultaneously satisfied, where RREF cannot ensure that.

'''[https://en.wikipedia.org/wiki/Hermite_normal_form Hermite Normal Form]''', or '''HNF''', is the last form to discuss. This one's constraints begin with echelon form and integer, therefore every HNF is also IREF. But HNF is not exactly reduced; instead, it is ''normalized'', which — similarly to reduced — is a two-part constraint. Where reduced requires that all pivots be exactly equal to 1, normalized requires only that all pivots be positive (positive integers, of course, due to the other integer constraint). And where reduced requires that all entries in pivot columns besides the pivots are exactly equal to 0, normalized requires only that all entries in pivot columns below the pivots are exactly equal to 0, while entries in pivot columns above the pivots only have to be strictly less than the pivot in the respective column (while still being non-negative).<ref>The exact criteria for HNF are not always consistently agreed upon, however.</ref><ref>There is also a rarely mentioned Hermite Canonical Form, or HCF, described here: http://home.iitk.ac.in/~rksr/html/03CANONICALFACTORIZATIONS.htm, which sort of combines the HNF's normalization constraint and the RREF's reduced constraint (all pivots equal 1, all other entries in pivot columns are 0, both above and below the pivot), but we didn't find it useful because due to its constraint that all pivots be 1, it does not preserve periods that are genuinely unit fractions of an octave. It also doesn't qualify as an echelon form, which becomes apparent only when you use it on rank-deficient matrices, because it doesn't require the rows of all zeros to be at the bottom; instead it (bizarrely, though maybe it's related to how the SNF requires all pivots exactly along the main diagonal) requires the rows to be sorted so that all the pivots fall on the main diagonal.</ref><ref>We are using "row-style" Hermite Normal Form here, not "column-style"; the latter would involve simply flipping everything 90 degrees so that the echelon requirement was that pivots be strictly ''below'' the pivots in the previous ''column'', and that pivot ''rows'' are considered for the normalization constraint rather than pivot ''columns''.</ref> The normalization HNF uses is cool because this constraint, while strictly less strict than the reduced constraint used by RREF, is still strict enough to ensure uniqueness, but loose enough to ensure the integer constraint can be simultaneously satisfied, where RREF cannot ensure that.

So HNF has a lot in common with IRREF, which is the IREF you find by converting the RREF, but it is not always the same as IRREF.

Line 387:

# The ''only match'' now is between IRREF and DCF. In other words, the HNF and DCF diverged, and it was the DCF which remained the same as IRREF. Example: enfactored hanson, e.g. {{vector|{{map|15 24 35}} {{map|38 60 88}}}} causes the HNF to be {{vector|{{map|1 0 1}} {{map|0 12 10}}}}.

There is also a final case which is incredibly rare. It can be compared to the #3 cases above, the ones using hanson as their example. The idea here is that when the HNF and DCF diverge, instead of DCF remaining the same as IRREF, it's the HNF that remains the same as IRREF. ~~I haven't found any~~ practical temperoids with this case, but {{vector|{{map|165 264 393}} {{map|231 363 524}}}} will do it<ref>AKA 165b⁴c¹⁹&231b⁶c²⁴, which tempers out the 7.753¢ comma {{vector|-131 131 -33}}!</ref>, with IRREF and HNF of {{vector|{{map|33 0 -131}} {{map|0 33 131}}}}, DCF of {{vector|{{map|1 1 0}} {{map|0 33 131}}}}, and RREF of {{vector|{{map|1 0 <math>\frac{-131}{33}</math>}} {{map|0 1 <math>\frac{131}{33}</math>}}}}.

There is also a final case which is incredibly rare. It can be compared to the #3 cases above, the ones using hanson as their example. The idea here is that when the HNF and DCF diverge, instead of DCF remaining the same as IRREF, it's the HNF that remains the same as IRREF. There may be no practical temperoids with this case, but {{vector|{{map|165 264 393}} {{map|231 363 524}}}} will do it<ref>AKA 165b⁴c¹⁹&231b⁶c²⁴, which tempers out the 7.753¢ comma {{vector|-131 131 -33}}!</ref>, with IRREF and HNF of {{vector|{{map|33 0 -131}} {{map|0 33 131}}}}, DCF of {{vector|{{map|1 1 0}} {{map|0 33 131}}}}, and RREF of {{vector|{{map|1 0 <math>\frac{-131}{33}</math>}} {{map|0 1 <math>\frac{131}{33}</math>}}}}.

That accounts for 7 of the 15 total possible cases for a system of equalities between 4 entities. The remaining 9 cases are impossible due to properties of the domain:

@@ Line 40: / Line 40: @@
 # Again, it does not have any obvious musical or mathematical meaning in this context.
 # It's a word that was invented for RTT and has no meaning outside of RTT<ref>Here is the tuning list post where it was coined by [[Paul Erlich]]: https://yahootuninggroupsultimatebackup.github.io/tuning-math/topicId_2033.html#2456</ref>.
-# It was made up due to false assumptions<ref>Authors note: to be absolutely clear, I don’t care who said what or how misconceptions arose (except insofar as it helps dispel any further misconceptions, some of which certainly may be my own). I have basically infinite sympathy for anyone who gets confused over this topic. It took my good friend Dave and I months of back and forth theorization, argumentation, and diagramming before we were able to settle on an explanation we both understood and agreed upon. I am not intending to get in the business of slinging blame (or credit) around. As far as I’m concerned, as long as we can have meaningful discussion with each other, and hopefully eventually arrive at conclusions that are more musically and intellectually empowering than we had previously, then we’re doing well together. Would I have make these mistakes myself? Yes! I have literally dozens of recent emails proving that I would have gone for the same duality myself, due to a case of asymmetry-phobia.</ref>. Through researching on tuning list archives, Dave and Douglas concluded that the associated concept of "torsion" was first described in January of 2002<ref>See: https://yahootuninggroupsultimatebackup.github.io/tuning-math/topicId_2937 which is also referred to here http://tonalsoft.com/enc/t/torsion.aspx</ref>, with regards to commas used to form Fokker periodicity blocks. The concept of enfactoring was recognized in temperament mappings (though of course it did not yet go by that name), and — because torsion in lists of commas for Fokker blocks looks the same way as enfactoring looks in temperament comma-bases — torsion got conflated with it<ref>See: https://yahootuninggroupsultimatebackup.github.io/tuning-math/topicId_2033.html#2405</ref>. But they can't truly be the same thing; the critical difference is that periodicity blocks do not involve tempering, while temperaments do. In concrete terms, while it can make sense to construct a Fokker block with {{vector|-4 4 -1}} in the middle and {{vector|-8 8 -2}} = 2{{vector|-4 4 -1}} at the edge, it does not make sense to imagine a temperament which tempers out 2{{vector|-4 4 -1}} but does not temper out {{vector|-4 4 -1}}. Unfortunately, however, this critical difference seems to have been overlooked, and so it seemed that enfactored comma-bases exhibited torsion, and thus because mappings are the dual of comma-bases, then enfactoring of a mapping should be the dual of torsion, and because the prefix co- or con- means "dual" (as in vectors and covectors), the term "con-torsion" was coined for it. "Torsion" already has the problem of being an obscure mathematical term that means nothing to most people, "contorsion" just compounds that problem by being made up, and it is made up in order to convey a duality which is false. So while "torsion" could be preserved as a term for the effect on periodicity blocks (though there's almost certainly something more helpful than that, but that's a battle for another day<ref>I might suggest we call it a "shredded periodicity block", due to the way how the paths that the multiple parallel generators take around the block look like shreds of paper, were the periodicity block imagined as a sheet of paper run through a paper shredder.</ref><ref>Furthermore, care should be taken to recognize the difference in behavior between, say<br><br>
+# It was made up due to false assumptions<ref>Authors note: to be absolutely clear, I don’t care who said what or how misconceptions arose (except insofar as it helps dispel any further misconceptions, some of which certainly may be my own). I have basically infinite sympathy for anyone who gets confused over this topic. It took my good friend Dave and I months of back and forth theorization, argumentation, and diagramming before we were able to settle on an explanation we both understood and agreed upon. I am not intending to get in the business of slinging blame (or credit) around. As far as I’m concerned, as long as we can have meaningful discussion with each other, and hopefully eventually arrive at conclusions that are more musically and intellectually empowering than we had previously, then we’re doing well together. Would I have make these mistakes myself? Yes! I have literally dozens of recent emails proving that I would have gone for the same duality myself, due to a case of asymmetry-phobia.</ref>. Through researching on tuning list archives, Dave and Douglas concluded that the associated concept of "torsion" was first described in January of 2002<ref>See: https://yahootuninggroupsultimatebackup.github.io/tuning-math/topicId_2937 which is also referred to here http://tonalsoft.com/enc/t/torsion.aspx</ref>, with regards to commas used to form Fokker periodicity blocks. The concept of enfactoring was recognized in temperament mappings (though of course it did not yet go by that name), and — because torsion in lists of commas for Fokker blocks looks the same way as enfactoring looks in temperament comma-bases — torsion got conflated with it<ref>See: https://yahootuninggroupsultimatebackup.github.io/tuning-math/topicId_2033.html#2405</ref>. But they can't truly be the same thing; the critical difference is that periodicity blocks do not involve tempering, while temperaments do. In concrete terms, while it can make sense to construct a Fokker block with {{vector|-4 4 -1}} in the middle and {{vector|-8 8 -2}} = 2{{vector|-4 4 -1}} at the edge, it does not make sense to imagine a temperament which tempers out 2{{vector|-4 4 -1}} but does not temper out {{vector|-4 4 -1}}. Unfortunately, however, this critical difference seems to have been overlooked, and so it seemed that enfactored comma-bases exhibited torsion, and thus because mappings are the dual of comma-bases, then enfactoring of a mapping should be the dual of torsion, and because the prefix co- or con- means "dual" (as in vectors and covectors), the term "con-torsion" was coined for it. "Torsion" already has the problem of being an obscure mathematical term that means nothing to most people, "contorsion" just compounds that problem by being made up, and it is made up in order to convey a duality which is false. So while "torsion" could be preserved as a term for the effect on periodicity blocks (though there's almost certainly something more helpful than that, but that's a battle for another day<ref>Perhaps we call it a "shredded periodicity block", due to the way how the paths that the multiple parallel generators take around the block look like shreds of paper, were the periodicity block imagined as a sheet of paper run through a paper shredder.</ref><ref>Furthermore, care should be taken to recognize the difference in behavior between, say<br><br>
 <math>
 \left[
@@ Line 322: / Line 322: @@
 It is not possible for an RREF to be IREF without also being IRREF.
-'''[https://en.wikipedia.org/wiki/Hermite_normal_form Hermite Normal Form]''', or '''HNF''', is the last form to discuss. This one's constraints begin with echelon form and integer, therefore every HNF is also IREF. But HNF is not exactly reduced; instead, it is ''normalized'', which — similarly to reduced — is a two-part constraint. Where reduced requires that all pivots be exactly equal to 1, normalized requires only that all pivots be positive (positive integers, of course, due to the other integer constraint). And where reduced requires that all entries in pivot columns besides the pivots are exactly equal to 0, normalized requires only that all entries in pivot columns below the pivots are exactly equal to 0, while entries in pivot columns above the pivots only have to be strictly less than the pivot in the respective column (while still being non-negative).<ref>The exact criteria for HNF are not always consistently agreed upon, however.</ref><ref>There is also a rarely mentioned Hermite Canonical Form, or HCF, described here: http://home.iitk.ac.in/~rksr/html/03CANONICALFACTORIZATIONS.htm, which sort of combines the HNF's normalization constraint and the RREF's reduced constraint (all pivots equal 1, all other entries in pivot columns are 0, both above and below the pivot), but we didn't find it useful because due to its constraint that all pivots be 1, it does not preserve periods that are genuinely unit fractions of an octave. It also doesn't qualify as an echelon form, which becomes apparent only when you use it on rank-deficient matrices, because it doesn't require the rows of all zeros to be at the bottom; instead it (bizarrely, as far as I can tell, though maybe it's related to how the SNF requires all pivots exactly along the main diagonal) requires the rows to be sorted so that all the pivots fall on the main diagonal.</ref><ref>We are using "row-style" Hermite Normal Form here, not "column-style"; the latter would involve simply flipping everything 90 degrees so that the echelon requirement was that pivots be strictly ''below'' the pivots in the previous ''column'', and that pivot ''rows'' are considered for the normalization constraint rather than pivot ''columns''.</ref> The normalization HNF uses is cool because this constraint, while strictly less strict than the reduced constraint used by RREF, is still strict enough to ensure uniqueness, but loose enough to ensure the integer constraint can be simultaneously satisfied, where RREF cannot ensure that.
+'''[https://en.wikipedia.org/wiki/Hermite_normal_form Hermite Normal Form]''', or '''HNF''', is the last form to discuss. This one's constraints begin with echelon form and integer, therefore every HNF is also IREF. But HNF is not exactly reduced; instead, it is ''normalized'', which — similarly to reduced — is a two-part constraint. Where reduced requires that all pivots be exactly equal to 1, normalized requires only that all pivots be positive (positive integers, of course, due to the other integer constraint). And where reduced requires that all entries in pivot columns besides the pivots are exactly equal to 0, normalized requires only that all entries in pivot columns below the pivots are exactly equal to 0, while entries in pivot columns above the pivots only have to be strictly less than the pivot in the respective column (while still being non-negative).<ref>The exact criteria for HNF are not always consistently agreed upon, however.</ref><ref>There is also a rarely mentioned Hermite Canonical Form, or HCF, described here: http://home.iitk.ac.in/~rksr/html/03CANONICALFACTORIZATIONS.htm, which sort of combines the HNF's normalization constraint and the RREF's reduced constraint (all pivots equal 1, all other entries in pivot columns are 0, both above and below the pivot), but we didn't find it useful because due to its constraint that all pivots be 1, it does not preserve periods that are genuinely unit fractions of an octave. It also doesn't qualify as an echelon form, which becomes apparent only when you use it on rank-deficient matrices, because it doesn't require the rows of all zeros to be at the bottom; instead it (bizarrely, though maybe it's related to how the SNF requires all pivots exactly along the main diagonal) requires the rows to be sorted so that all the pivots fall on the main diagonal.</ref><ref>We are using "row-style" Hermite Normal Form here, not "column-style"; the latter would involve simply flipping everything 90 degrees so that the echelon requirement was that pivots be strictly ''below'' the pivots in the previous ''column'', and that pivot ''rows'' are considered for the normalization constraint rather than pivot ''columns''.</ref> The normalization HNF uses is cool because this constraint, while strictly less strict than the reduced constraint used by RREF, is still strict enough to ensure uniqueness, but loose enough to ensure the integer constraint can be simultaneously satisfied, where RREF cannot ensure that.
 So HNF has a lot in common with IRREF, which is the IREF you find by converting the RREF, but it is not always the same as IRREF.
@@ Line 387: / Line 387: @@
 # The ''only match'' now is between IRREF and DCF. In other words, the HNF and DCF diverged, and it was the DCF which remained the same as IRREF. Example: enfactored hanson, e.g. {{vector|{{map|15 24 35}} {{map|38 60 88}}}} causes the HNF to be {{vector|{{map|1 0 1}} {{map|0 12 10}}}}.
-There is also a final case which is incredibly rare. It can be compared to the #3 cases above, the ones using hanson as their example. The idea here is that when the HNF and DCF diverge, instead of DCF remaining the same as IRREF, it's the HNF that remains the same as IRREF. I haven't found any practical temperoids with this case, but {{vector|{{map|165 264 393}} {{map|231 363 524}}}} will do it<ref>AKA 165b⁴c¹⁹&231b⁶c²⁴, which tempers out the 7.753¢ comma {{vector|-131 131 -33}}!</ref>, with IRREF and HNF of {{vector|{{map|33 0 -131}} {{map|0 33 131}}}}, DCF of {{vector|{{map|1 1 0}} {{map|0 33 131}}}}, and RREF of {{vector|{{map|1 0 <span><math>\frac{-131}{33}</math></span>}} {{map|0 1 <span><math>\frac{131}{33}</math></span>}}}}.
+There is also a final case which is incredibly rare. It can be compared to the #3 cases above, the ones using hanson as their example. The idea here is that when the HNF and DCF diverge, instead of DCF remaining the same as IRREF, it's the HNF that remains the same as IRREF. There may be no practical temperoids with this case, but {{vector|{{map|165 264 393}} {{map|231 363 524}}}} will do it<ref>AKA 165b⁴c¹⁹&231b⁶c²⁴, which tempers out the 7.753¢ comma {{vector|-131 131 -33}}!</ref>, with IRREF and HNF of {{vector|{{map|33 0 -131}} {{map|0 33 131}}}}, DCF of {{vector|{{map|1 1 0}} {{map|0 33 131}}}}, and RREF of {{vector|{{map|1 0 <span><math>\frac{-131}{33}</math></span>}} {{map|0 1 <span><math>\frac{131}{33}</math></span>}}}}.
 That accounts for 7 of the 15 total possible cases for a system of equalities between 4 entities. The remaining 9 cases are impossible due to properties of the domain: