Inverse-complexity-prescaled complexity: Difference between revisions
Cmloegcmluin (talk | contribs) update info re: code libraries |
ArrowHead294 (talk | contribs) m Update links |
||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
This article is a cautionary tale for anyone who (as I, [[Douglas Blumeyer]], did) got temporarily seduced and totally confused about: using the inverse of a complexity prescaler with a [[interval complexity|complexity]] function, i.e. one that is [[ | This article is a cautionary tale for anyone who (as I, [[Douglas Blumeyer]], did) got temporarily seduced and totally confused about: using the inverse of a complexity prescaler with a [[interval complexity|complexity]] function, i.e. one that is [[Dave Keenan & Douglas Blumeyer's guide to RTT/All-interval tuning schemes#Normifying complexities|in (prescaled) norm form]]. Inverse-complexity-prescaled complexity functions: don't use them! Now that I have good enough terminology for the constituent parts, the name itself seems as self-contradictory as the concept. | ||
So why would someone ever want to try this? Well, I had looked into it because I was curious about the limitation of [[all-interval tuning scheme]]s whereby they only work with [[simplicity-weight]] [[damage]]. I'd wondered if there was nonetheless a way to achieve complexity-weight-like effects anyway. As you will see from this article, the answer is a very slight "sort of", but at such a cost of reasonableness that there's no way it could be worth it. | So why would someone ever want to try this? Well, I had looked into it because I was curious about the limitation of [[all-interval tuning scheme]]s whereby they only work with [[simplicity-weight]] [[damage]]. I'd wondered if there was nonetheless a way to achieve complexity-weight-like effects anyway. As you will see from this article, the answer is a very slight "sort of", but at such a cost of reasonableness that there's no way it could be worth it. | ||
| Line 56: | Line 56: | ||
Let's see what we'd get if we chose our default complexity, [[log-product complexity|log-product]] <math>\text{lp-C}()</math> in this case. This means substitute in: | Let's see what we'd get if we chose our default complexity, [[log-product complexity|log-product]] <math>\text{lp-C}()</math> in this case. This means substitute in: | ||
* <math>1</math> in place of our [[ | * <math>1</math> in place of our [[Dave Keenan & Douglas Blumeyer's guide to RTT/All-interval tuning schemes#Power norms|norm power]] <math>q</math>, | ||
* the log-prime matrix <math>L</math> in place of <math>X</math>, and | * the log-prime matrix <math>L</math> in place of <math>X</math>, and | ||
* its inverse <math>L^{-1}</math> in place of <math>X^{-1}</math>. | * its inverse <math>L^{-1}</math> in place of <math>X^{-1}</math>. | ||
| Line 176: | Line 176: | ||
So those values are 1, 1/1.631 = 0.613, 1/2.431 = 0.411, and 1/1.062 = 0.942 by the way. So this is now our scare-quoted "complexity-weight" matrix, because our weights are generally going down as complexity goes up, but also there's the chaotic noise effect where — given that — <math>\frac53</math> is found on the wrong side of <math>\frac32</math>. | So those values are 1, 1/1.631 = 0.613, 1/2.431 = 0.411, and 1/1.062 = 0.942 by the way. So this is now our scare-quoted "complexity-weight" matrix, because our weights are generally going down as complexity goes up, but also there's the chaotic noise effect where — given that — <math>\frac53</math> is found on the wrong side of <math>\frac32</math>. | ||
So in conclusion, this should really be a red flag; it should never make sense to use the inverse of a complexity prescaler inside a ''complexity'' function. I do recognize that it can be confusing to realize that we ''do'', however, use ''complexity'' functions in simplicity-weight matrices, as we did just a moment ago. Now, there is an alternative way to think of it as calling <math>\text{lp-S}()</math> there, but I expect for most readers it is still more comfortable to think of this is as <math>\frac{1}{\text{lp-S}()}</math>. So we do use complexity prescalers outside of the context of all-interval tunings; they may occur in any complexity-weight or simplicity-weight damage that defines its complexity as a prescaled norm of | So in conclusion, this should really be a red flag; it should never make sense to use the inverse of a complexity prescaler inside a ''complexity'' function. I do recognize that it can be confusing to realize that we ''do'', however, use ''complexity'' functions in simplicity-weight matrices, as we did just a moment ago. Now, there is an alternative way to think of it as calling <math>\text{lp-S}()</math> there, but I expect for most readers it is still more comfortable to think of this is as <math>\frac{1}{\text{lp-S}()}</math>. So we do use complexity prescalers outside of the context of all-interval tunings; they may occur in any complexity-weight or simplicity-weight damage that defines its complexity as a prescaled norm of an interval vector, but we ''never'' use inverses of complexity prescalers except in the [[retuning magnitude]], the dual norm to the interval complexity norm, for all-interval tuning schemes. | ||
[[Category:Regular temperament theory]] | [[Category:Regular temperament theory]] | ||
[[Category:Tuning]] | [[Category:Tuning]] | ||