Talk:Normal forms: Difference between revisions

Line 11:

== How best to handle the new canonical form for RTT matrices w/r/t normal form ==

I recently published [[Canonical form|a page on the xen wiki proposing a canonical form for RTT mappings (or comma-bases)]]. This new page of mine solves a problem that this page seems to have set out to solve but not finished the job: establishing a form for RTT matrices which ''uniquely identifies them'', for a definition of uniqueness that is appropriate to the RTT domain. And so my page refers to this page in several places, mostly critiquing it.

I recently published [[Canonical form|a page on the xen wiki proposing a canonical form for RTT mappings (or comma bases)]]. This new page of mine solves a problem that this page seems to have set out to solve but not finished the job: establishing a form for RTT matrices which ''uniquely identifies them'', for a definition of uniqueness that is appropriate to the RTT domain. And so my page refers to this page in several places, mostly critiquing it.

I note that this page doesn't even present a unified front. It presents both HNF and IRREF as ''potential'' normal forms. But it is not clear whether a given matrix on a temperament page marked as "normal" is its HNF or IRREF (sometimes they are the same, other times different).

But in particular I note that neither the HNF nor IRREF methods discussed here reliably defactor matrices (or in other words, saturate them, or remove contorsion, though those are confusing terms for the issue that my new page sets out to eliminate). This is what I'm referring to when I speak of a definition of uniqueness that is appropriate to the RTT domain. The HNF of a matrix is unique, yes, as is the IRREF. But these definitions of uniqueness treat e.g. {{map|12 19 28}} and {{map|24 38 56}} as distinct, when from a strict RTT perspective the latter is not distinct ''insofar as how it tempers JI'' from the former. At least when enfactoring is found in mappings, it has musical reality, but in comma-bases it's meaningless and confusing (I can still play music in 24-ET that sounds different than 12-ET, but I can't pump the comma {{vector|-8 8 -2}} any differently than the comma {{vector|-4 4 -1}})). So: enfactored matrices are pathological. (If you're interested in this issue, my new page discusses it in detail.)

But in particular I note that neither the HNF nor IRREF methods discussed here reliably defactor matrices (or in other words, saturate them, or remove contorsion, though those are confusing terms for the issue that my new page sets out to eliminate). This is what I'm referring to when I speak of a definition of uniqueness that is appropriate to the RTT domain. The HNF of a matrix is unique, yes, as is the IRREF. But these definitions of uniqueness treat e.g. {{map|12 19 28}} and {{map|24 38 56}} as distinct, when from a strict RTT perspective the latter is not distinct ''insofar as how it tempers JI'' from the former. At least when enfactoring is found in mappings, it has musical reality, but in comma bases it's meaningless and confusing (I can still play music in 24-ET that sounds different than 12-ET, but I can't pump the comma {{vector|-8 8 -2}} any differently than the comma {{vector|-4 4 -1}})). So: enfactored matrices are pathological. (If you're interested in this issue, my new page discusses it in detail.)

My concern is that the normal forms for RTT matrices which are discussed here have proliferated widely, but I believe that now that a canonical form has been developed (by [[Dave Keenan]], in collaboration with myself, [[Douglas Blumeyer]], inspired in no small part by many insights from [[Gene Ward Smith]]) should be the primary form of RTT matrices used throughout the wiki. Of course I don't plan to do this myself immediately, for numerous reasons. For starters, that'd be a Herculean task. But mostly I wouldn't do something that impactful without soliciting input from the community first.

Line 53:

:::: I think the technique to link out to the canonical form page works fine. Maybe I'll keep it the way it is, i.e. not work to rename it to simply "defactoring" (I did add a redirect page for that, though).

:::: Re: the beep example. I recently fixed that example myself. But I've since noticed it's not quite perfect. Normal form (and canonical form) require the pivots to be positive. And you find the pivots for comma-bases by anti-transposing them, i.e. flipping them across the anti-diagonal, between top-right and bottom-left, so that when the HNF tries to put all the zeros in the bottom-left corner, it gravitates them toward where we want them: the higher primes, and commas earlier in the list. Technically, then, the canonical commas for beep should be 25/27 and 35/36, even though with n < d those are negative in pitch and that's not the typical way we write commas. It looks less off-putting when the canonical form is presented as a matrix, i.e. {{map|{{vector|0 -3 2 0}} {{vector|2 2 -1 -1}}}}, so I suggest we write them like that. Or I'm open to other suggestions.

:::: Re: the beep example. I recently fixed that example myself. But I've since noticed it's not quite perfect. Normal form (and canonical form) require the pivots to be positive. And you find the pivots for comma bases by anti-transposing them, i.e. flipping them across the anti-diagonal, between top-right and bottom-left, so that when the HNF tries to put all the zeros in the bottom-left corner, it gravitates them toward where we want them: the higher primes, and commas earlier in the list. Technically, then, the canonical commas for beep should be 25/27 and 35/36, even though with n < d those are negative in pitch and that's not the typical way we write commas. It looks less off-putting when the canonical form is presented as a matrix, i.e. {{map|{{vector|0 -3 2 0}} {{vector|2 2 -1 -1}}}}, so I suggest we write them like that. Or I'm open to other suggestions.

:::: Speaking of lists vs. matrices, I would like to rename the page from "normal lists" to "normal form". I see that this reflects my preference to think of RTT structures as matrices rather than lists of vectors or covectors. Because we are using linear algebra extensively here, I think this is the natural and appropriate way to think of them. What do you think?

Line 65:

:::: That's all for now. Thanks for helping with this. --[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 18:54, 29 September 2021 (UTC)

:::: I would also like to see across the wiki places where "normal list", "normal comma list", "normal interval list", "normal val list", "normal list basis", etc. standardized to "canonical mapping" or "canonical comma-basis", linking here. What do you think? --[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 19:54, 29 September 2021 (UTC)

:::: I would also like to see across the wiki places where "normal list", "normal comma list", "normal interval list", "normal val list", "normal list basis", etc. standardized to "canonical mapping" or "canonical comma basis", linking here. What do you think? --[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 19:54, 29 September 2021 (UTC)

::::: Sounds like a lot of work to be done!

Line 147:

::::::::::::::: I've reworked it and pls give it a review. [[User:FloraC|FloraC]] ([[User talk:FloraC|talk]]) 14:39, 2 October 2021 (UTC)

:::::::::::::::: W00t! That's basically exactly how I was going to do it: for the mapping side, build them cumulatively on top of each other: HNF, canonical, positive generator, equave-reduced, mingen. Then a similar progression for the comma-basis side. Great work.

:::::::::::::::: W00t! That's basically exactly how I was going to do it: for the mapping side, build them cumulatively on top of each other: HNF, canonical, positive generator, equave-reduced, mingen. Then a similar progression for the comma basis side. Great work.

:::::::::::::::: I just layered on an edit myself which came out bigger than I was expecting as I added some context that I think is helpful and some further explanations and examples. Let me know what you think. I didn't disagree with anything you had put on the page, so if in my edit I screwed up anything you cared about, please go right ahead and rework/redo. --[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 00:51, 4 October 2021 (UTC)

@@ Line 11: / Line 11: @@
 == How best to handle the new canonical form for RTT matrices w/r/t normal form ==
-I recently published [[Canonical form|a page on the xen wiki proposing a canonical form for RTT mappings (or comma-bases)]]. This new page of mine solves a problem that this page seems to have set out to solve but not finished the job: establishing a form for RTT matrices which ''uniquely identifies them'', for a definition of uniqueness that is appropriate to the RTT domain. And so my page refers to this page in several places, mostly critiquing it.
+I recently published [[Canonical form|a page on the xen wiki proposing a canonical form for RTT mappings (or comma bases)]]. This new page of mine solves a problem that this page seems to have set out to solve but not finished the job: establishing a form for RTT matrices which ''uniquely identifies them'', for a definition of uniqueness that is appropriate to the RTT domain. And so my page refers to this page in several places, mostly critiquing it.
 I note that this page doesn't even present a unified front. It presents both HNF and IRREF as ''potential'' normal forms. But it is not clear whether a given matrix on a temperament page marked as "normal" is its HNF or IRREF (sometimes they are the same, other times different).
-But in particular I note that neither the HNF nor IRREF methods discussed here reliably defactor matrices (or in other words, saturate them, or remove contorsion, though those are confusing terms for the issue that my new page sets out to eliminate). This is what I'm referring to when I speak of a definition of uniqueness that is appropriate to the RTT domain. The HNF of a matrix is unique, yes, as is the IRREF. But these definitions of uniqueness treat e.g. {{map|12 19 28}} and {{map|24 38 56}} as distinct, when from a strict RTT perspective the latter is not distinct ''insofar as how it tempers JI'' from the former. At least when enfactoring is found in mappings, it has musical reality, but in comma-bases it's meaningless and confusing (I can still play music in 24-ET that sounds different than 12-ET, but I can't pump the comma {{vector|-8 8 -2}} any differently than the comma {{vector|-4 4 -1}})). So: enfactored matrices are pathological. (If you're interested in this issue, my new page discusses it in detail.)
+But in particular I note that neither the HNF nor IRREF methods discussed here reliably defactor matrices (or in other words, saturate them, or remove contorsion, though those are confusing terms for the issue that my new page sets out to eliminate). This is what I'm referring to when I speak of a definition of uniqueness that is appropriate to the RTT domain. The HNF of a matrix is unique, yes, as is the IRREF. But these definitions of uniqueness treat e.g. {{map|12 19 28}} and {{map|24 38 56}} as distinct, when from a strict RTT perspective the latter is not distinct ''insofar as how it tempers JI'' from the former. At least when enfactoring is found in mappings, it has musical reality, but in comma bases it's meaningless and confusing (I can still play music in 24-ET that sounds different than 12-ET, but I can't pump the comma {{vector|-8 8 -2}} any differently than the comma {{vector|-4 4 -1}})). So: enfactored matrices are pathological. (If you're interested in this issue, my new page discusses it in detail.)
 My concern is that the normal forms for RTT matrices which are discussed here have proliferated widely, but I believe that now that a canonical form has been developed (by [[Dave Keenan]], in collaboration with myself, [[Douglas Blumeyer]], inspired in no small part by many insights from [[Gene Ward Smith]]) should be the primary form of RTT matrices used throughout the wiki. Of course I don't plan to do this myself immediately, for numerous reasons. For starters, that'd be a Herculean task. But mostly I wouldn't do something that impactful without soliciting input from the community first.
@@ Line 53: / Line 53: @@
 :::: I think the technique to link out to the canonical form page works fine. Maybe I'll keep it the way it is, i.e. not work to rename it to simply "defactoring" (I did add a redirect page for that, though).
-:::: Re: the beep example. I recently fixed that example myself. But I've since noticed it's not quite perfect. Normal form (and canonical form) require the pivots to be positive. And you find the pivots for comma-bases by anti-transposing them, i.e. flipping them across the anti-diagonal, between top-right and bottom-left, so that when the HNF tries to put all the zeros in the bottom-left corner, it gravitates them toward where we want them: the higher primes, and commas earlier in the list. Technically, then, the canonical commas for beep should be 25/27 and 35/36, even though with n < d those are negative in pitch and that's not the typical way we write commas. It looks less off-putting when the canonical form is presented as a matrix, i.e. {{map|{{vector|0 -3 2 0}} {{vector|2 2 -1 -1}}}}, so I suggest we write them like that. Or I'm open to other suggestions.
+:::: Re: the beep example. I recently fixed that example myself. But I've since noticed it's not quite perfect. Normal form (and canonical form) require the pivots to be positive. And you find the pivots for comma bases by anti-transposing them, i.e. flipping them across the anti-diagonal, between top-right and bottom-left, so that when the HNF tries to put all the zeros in the bottom-left corner, it gravitates them toward where we want them: the higher primes, and commas earlier in the list. Technically, then, the canonical commas for beep should be 25/27 and 35/36, even though with n < d those are negative in pitch and that's not the typical way we write commas. It looks less off-putting when the canonical form is presented as a matrix, i.e. {{map|{{vector|0 -3 2 0}} {{vector|2 2 -1 -1}}}}, so I suggest we write them like that. Or I'm open to other suggestions.
 :::: Speaking of lists vs. matrices, I would like to rename the page from "normal lists" to "normal form". I see that this reflects my preference to think of RTT structures as matrices rather than lists of vectors or covectors. Because we are using linear algebra extensively here, I think this is the natural and appropriate way to think of them. What do you think?
@@ Line 65: / Line 65: @@
 :::: That's all for now. Thanks for helping with this. --[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 18:54, 29 September 2021 (UTC)
-:::: I would also like to see across the wiki places where "normal list", "normal comma list", "normal interval list", "normal val list", "normal list basis", etc. standardized to "canonical mapping" or "canonical comma-basis", linking here. What do you think? --[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 19:54, 29 September 2021 (UTC)
+:::: I would also like to see across the wiki places where "normal list", "normal comma list", "normal interval list", "normal val list", "normal list basis", etc. standardized to "canonical mapping" or "canonical comma basis", linking here. What do you think? --[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 19:54, 29 September 2021 (UTC)
 ::::: Sounds like a lot of work to be done!
@@ Line 147: / Line 147: @@
 ::::::::::::::: I've reworked it and pls give it a review. [[User:FloraC|FloraC]] ([[User talk:FloraC|talk]]) 14:39, 2 October 2021 (UTC)
-:::::::::::::::: W00t! That's basically exactly how I was going to do it: for the mapping side, build them cumulatively on top of each other: HNF, canonical, positive generator, equave-reduced, mingen. Then a similar progression for the comma-basis side. Great work.
+:::::::::::::::: W00t! That's basically exactly how I was going to do it: for the mapping side, build them cumulatively on top of each other: HNF, canonical, positive generator, equave-reduced, mingen. Then a similar progression for the comma basis side. Great work.
 :::::::::::::::: I just layered on an edit myself which came out bigger than I was expecting as I added some context that I think is helpful and some further explanations and examples. Let me know what you think. I didn't disagree with anything you had put on the page, so if in my edit I screwed up anything you cared about, please go right ahead and rework/redo. --[[User:Cmloegcmluin|Cmloegcmluin]] ([[User talk:Cmloegcmluin|talk]]) 00:51, 4 October 2021 (UTC)