Projection: Difference between revisions
Cmloegcmluin (talk | contribs) →Examples: note about rank and all-zero rows |
Cmloegcmluin (talk | contribs) clarify information about V, rank, and basis |
||
| Line 1,216: | Line 1,216: | ||
On the left, we've highlighted the diagonalized scaling factors with green if they are for unchanged-intervals, and with red if they are for vanishing commas. Then on the right, we've colored the entire corresponding vector columns, and placed a vertical line between the two green columns corresponding to the two green scaling factors of 1 and the one red column corresponding to the one red scaling factor of 0. And so we can see that the green-colored part of <math>\mathrm{V}</math> is <math>\textrm{U}</math>, and the red-colored part of <math>V</math> is <math>\textrm{C}</math>. | On the left, we've highlighted the diagonalized scaling factors with green if they are for unchanged-intervals, and with red if they are for vanishing commas. Then on the right, we've colored the entire corresponding vector columns, and placed a vertical line between the two green columns corresponding to the two green scaling factors of 1 and the one red column corresponding to the one red scaling factor of 0. And so we can see that the green-colored part of <math>\mathrm{V}</math> is <math>\textrm{U}</math>, and the red-colored part of <math>V</math> is <math>\textrm{C}</math>. | ||
==Unrotated vector lists are not bases== | |||
As seen above, the unrotated vector list <math>V</math> is the concatenation of the unchanged-interval basis <math>\mathrm{U}</math> and the comma-basis <math>\mathrm{C}</math>. Yet <math>V</math> itself is not a basis; it is merely a ''list'' of vectors. Why is this? Perhaps it is best visualized in the diagram below: | |||
[[File:V is not basis.png|frameless|900x900px]] | |||
The basic idea is that any two commas' projections are the zero vector, so an indefinite number of these may be combined with each other. And any unchanged-interval's projection is equal to itself, so an indefinite number of these may be combined as well. But any interval that is a combination of some number of unchanged-intervals and some number of commas will have the comma part projected to zero but the unchanged-interval part left alone, and thus be rotated by the projection. In other words, only intervals with the same scaling factor can be combined and still remain unrotated, which is to say that the commas form one type of unrotated vector basis and the unchanged-intervals form another type of unrotated vector basis, but these bases do not combine into one basis together. | |||
That said, <math>V</math> must still be full-rank, meaning there is some relationship between the comma vectors and the unchanged-interval vectors. Specifically, it means that no unchanged-interval can be a linear combination of other unchanged-intervals and commas. If any were, we'd find an impossible situation, such as two unchanged-intervals off by a comma, so neither interval can change, yet they must both project to the same thing. For another take on this idea, see [[Dave Keenan & Douglas Blumeyer's guide to RTT: tuning computation#Edge cases]]. | |||
==Generator information types== | ==Generator information types== | ||
[[File:Info types - flow chart.png|thumb|602x602px|A diagram showing how the three information types (approximation, embedding, and form) break down across the tuning map, projection, mapping, generator embedding, multimap, and form matrices. ]] | [[File:Info types - flow chart.png|thumb|602x602px|A diagram showing how the three information types (approximation, embedding, and form) break down across the tuning map, projection, mapping, generator embedding, multimap, and form matrices. ]] | ||
One way to think about what's happening in this vicinity of RTT is that we have three different generator information types: | One way to think about what's happening in this vicinity of RTT is that we have three different generator information types: | ||
#approximation | # approximation | ||
#embedding | #embedding | ||
#form | # form | ||
Mappings combine types (1) and (3). Generator embeddings combine types (2) and (3). Projections combine types (1) and (2). So each possible subset of two of these pieces of information is accounted for by these three objects. | Mappings combine types (1) and (3). Generator embeddings combine types (2) and (3). Projections combine types (1) and (2). So each possible subset of two of these pieces of information is accounted for by these three objects. | ||
| Line 1,240: | Line 1,251: | ||
[[File:Info types - checkers.png|frameless|800x800px]] | [[File:Info types - checkers.png|frameless|800x800px]] | ||
==Mapping projected intervals== | == Mapping projected intervals== | ||
For any interval vector <math>\textbf{i}</math> that has already been projected by the projection matrix <math>P</math>, if you then map it by the temperament mapping <math>M</math>, you'll get the same thing as you would have if you hadn't projected it. In other words: | For any interval vector <math>\textbf{i}</math> that has already been projected by the projection matrix <math>P</math>, if you then map it by the temperament mapping <math>M</math>, you'll get the same thing as you would have if you hadn't projected it. In other words: | ||
| Line 1,252: | Line 1,263: | ||
that is, so long as <math>P</math> and <math>M</math> are for the same temperament. Said yet another way, even though temperament mappings are primarily designed to map prime-count vectors with ''all integer'' entries (therefore representing JI intervals), if you happen to try mapping one of the projected prime-count vectors which typically have ''non-integer but at least rational'' entries, it will nonetheless find itself mapped to the same generator-count vector as whatever all-integer JI prime-count vector it came from would have been mapped to. | that is, so long as <math>P</math> and <math>M</math> are for the same temperament. Said yet another way, even though temperament mappings are primarily designed to map prime-count vectors with ''all integer'' entries (therefore representing JI intervals), if you happen to try mapping one of the projected prime-count vectors which typically have ''non-integer but at least rational'' entries, it will nonetheless find itself mapped to the same generator-count vector as whatever all-integer JI prime-count vector it came from would have been mapped to. | ||
==Projecting to other spaces== | == Projecting to other spaces== | ||
The typical use case for a projection matrix is to re-embed a temperament lattice back into the original JI space from which it was tempered. But it is also possible to project to a completely different JI space after tempering, even a higher-dimensional one than the original space, or a lower-dimensional one than the tempered lattice. As long as you know how to translate vectors in the destination space into size, it's fair game. In fact, there's nothing stopping you from taking vectors in that space and projecting again, and again, and again. Though the present author fails to see if there are any meaningful musical purposes for this much temperamental distortion. | The typical use case for a projection matrix is to re-embed a temperament lattice back into the original JI space from which it was tempered. But it is also possible to project to a completely different JI space after tempering, even a higher-dimensional one than the original space, or a lower-dimensional one than the tempered lattice. As long as you know how to translate vectors in the destination space into size, it's fair game. In fact, there's nothing stopping you from taking vectors in that space and projecting again, and again, and again. Though the present author fails to see if there are any meaningful musical purposes for this much temperamental distortion. | ||
| Line 1,260: | Line 1,271: | ||
Projections and generator bases comes up in some methods for calculating tunings according to commonly-used schemes: | Projections and generator bases comes up in some methods for calculating tunings according to commonly-used schemes: | ||
#those that use the pseudoinverse, such as miniRMS and minimax-ES tunings: see [[Dave Keenan & Douglas Blumeyer's guide to RTT: tuning computation#Pseudoinverse method for a miniRMS tuning]] and [[Dave Keenan & Douglas Blumeyer's guide to RTT: all-interval tuning schemes#Minimax-ES]]. | #those that use the pseudoinverse, such as miniRMS and minimax-ES tunings: see [[Dave Keenan & Douglas Blumeyer's guide to RTT: tuning computation#Pseudoinverse method for a miniRMS tuning]] and [[Dave Keenan & Douglas Blumeyer's guide to RTT: all-interval tuning schemes#Minimax-ES]]. | ||
#those that use the sum polytope, such as minimean tunings: see [[Dave Keenan & Douglas Blumeyer's guide to RTT: tuning computation#Sum polytope method for a minimean tuning scheme]]. | # those that use the sum polytope, such as minimean tunings: see [[Dave Keenan & Douglas Blumeyer's guide to RTT: tuning computation#Sum polytope method for a minimean tuning scheme]]. | ||
#tunings based on unchanged-intervals: see [[Dave Keenan & Douglas Blumeyer's guide to RTT: tuning computation#Unchanged-interval method]]. | #tunings based on unchanged-intervals: see [[Dave Keenan & Douglas Blumeyer's guide to RTT: tuning computation#Unchanged-interval method]]. | ||