Inverse-complexity-prescaled complexity: Difference between revisions

This article is a cautionary tale for anyone who (as I, [[Douglas Blumeyer]], did) got temporarily seduced and totally confused about: using a [[simplicity prescaler|''simplicity'' prescaler]] inside a [[interval complexity|''complexity'']] function (that is, one that is [[Dave_Keenan_%26_Douglas_Blumeyer%27s_guide_to_RTT:_all-interval_tuning_schemes#Normifying_complexities|in (prescaled) norm form]]), ''even if'' the resultant complexity values are being reciprocated to be used for [[simplicity-weight]] [[damage]]. Simplicity-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 schemes 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.

For our control case, here's what normal reasonable [[complexity-weight|complexity-weighting]] looks like, i.e. where our [[target-interval weight matrix|weight matrix]] <math>W</math> increases weight with complexity, and so we call it <math>C</math>. Again, we're using a prescaled <math>q</math>-norm as the complexity, where <math>C_{\text{p}}</math> is the prescaler. We've gone ahead and somewhat arbitrarily picked a demo list of [[target-interval]]s <math>[\frac21, \frac32, \frac54, \frac53]</math>, but at this time we want to demonstrate the general relationships here and so haven't specified the actual complexity or its prescaler yet:

‖C_{\text{p}}[1 \; 0 \; 0 \; ⟩‖_q & 0 & 0 & 0 \\

0 & ‖C_{\text{p}}[{-1} \; 1 \; 0 \; ⟩‖_q & 0 & 0 \\

0 & 0 & ‖C_{\text{p}}[{-2} \; 0 \; 1 \; ⟩‖_q & 0 \\

0 & 0 & 0 & ‖C_{\text{p}}[0 \; {-1} \; 1 \; ⟩‖_q \\

And here's ''simplicity''-weighting (the inverse slope of complexity-weighting, where weight is meant to ''decrease'' with complexity, and so <math>W = S</math> instead; these changes indicated in blue) but while using a ''simplicity'' prescaler (<math>S_{\text{p}}</math>, which is the inverse of the complexity prescaler; these changes indicated in red):

{\color{blue}\dfrac{1}{{\color{black}‖}{\color{red}S_{\text{p}}}{\color{black}[1 \; 0 \; 0 \; ⟩‖_q}}} & 0 & 0 & 0 \\

0 & {\color{blue}\dfrac{1}{{\color{black}‖}{\color{red}S_{\text{p}}}{\color{black}[{-1} \; 1 \; 0 \; ⟩‖_q}}} & 0 & 0 \\

0 & 0 & {\color{blue}\dfrac{1}{{\color{black}‖}{\color{red}S_{\text{p}}}{\color{black}[{-2} \; 0 \; 1 \; ⟩‖_q}}} & 0 \\

0 & 0 & 0 & {\color{blue}\dfrac{1}{{\color{black}‖}{\color{red}S_{\text{p}}}{\color{black}[0 \; {-1} \; 1 \; ⟩‖_q}}} \\

* the log-prime matrix <math>L</math> in place of <math>C_{\text{p}}</math>, and  

* its inverse <math>L^{-1}</math> in place of <math>S_{\text{p}}</math>.  

{\color{blue}\dfrac{1}{{\color{black}‖C_{\text{p}}[1 \; 0 \; 0 \; ⟩‖_q}}} & 0 & 0 & 0 \\

0 & {\color{blue}\dfrac{1}{{\color{black}‖C_{\text{p}}[{-1} \; 1 \; 0 \; ⟩‖_q}}} & 0 & 0 \\

0 & 0 & {\color{blue}\dfrac{1}{{\color{black}‖C_{\text{p}}[{-2} \; 0 \; 1 \; ⟩‖_q}}} & 0 \\

0 & 0 & 0 & {\color{blue}\dfrac{1}{{\color{black}‖C_{\text{p}}[0 \; {-1} \; 1 \; ⟩‖_q}}} \\

‖{\color{red}S_{\text{p}}}[1 \; 0 \; 0 \; ⟩‖_q & 0 & 0 & 0 \\

0 & ‖{\color{red}S_{\text{p}}}[{-1} \; 1 \; 0 \; ⟩‖_q & 0 & 0 \\

0 & 0 & ‖{\color{red}S_{\text{p}}}[{-2} \; 0 \; 1 \; ⟩‖_q & 0 \\

0 & 0 & 0 & ‖{\color{red}S_{\text{p}}}[0 \; {-1} \; 1 \; ⟩‖_q \\

So in conclusion, this should really be a red flag; it should never make sense to use a ''simplicity'' 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 the interval's PC-vector (and in this case, then, the 'p' subscript of <math>C_{\text{p}}</math> stands only for "pretransform", not also for "prime" as it does with all-interval tuning schemes), but we ''never'' use simplicity prescalers except as inverse prescalers in the dual retuning magnitude norm for all-interval tuning schemes.