Inverse-complexity-prescaled complexity: Difference between revisions

Line 1:

This article is a cautionary tale for anyone who (as we, ~~[[Dave Keenan]] and~~ [[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 ~~Dave's and my~~ terminology ~~has sufficiently matured~~, the name itself seems as self-contradictory as the concept.

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.

~~Why~~ would someone ever want to try this? Well, we looked into it because ~~we were~~ curious about the limitation of all-interval tuning schemes whereby they only work with simplicity-weight damage. We wondered if there was nonetheless a way to achieve complexity-weight-like effects anyway. As you will see from this ~~section~~, the answer is a very slight "sort of", but at such a cost of reasonableness that there's no way it's 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 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:

Line 118:

[[File:The unreasonableness of inverting a norm's complexity prescaler, as seen by comparing our default complexity lp-C against its inverse .png|frameless|700x700px]]

Essentially what's happened is: we still have the setup of a complexity function, where additional prime factors add more weight, however, we've flipped the relative weights of those primes so that the simpler ones count for more! In the extreme, this means that I can take some interval and add tons of factors of 131 to it (that's just an arbitrary big prime we picked) and they will hardly affect its complexity at all. This is what we meant by chaotic noise: as you move along the number line, numbers with greater numbers of smaller prime factors will be more complex than their neighbors, and so, rather than using weight proportions to smoothing out texture of prime compositions of integers along the number line, we do literally the opposite and aggravate that texture into an unpleasantly jagged craziness that no one should want to use. Flora Canou's temperament utilities, for example, suggests that it supports it (though thankfully we find no evidence that it's actually implemented) and we strongly recommend against her doing so, if she's reading this.

Essentially what's happened is: we still have the setup of a complexity function, where additional prime factors add more weight, however, we've flipped the relative weights of those primes so that the simpler ones count for more! In the extreme, this means that I can take some interval and add tons of factors of 131 to it (that's just an arbitrary big prime I picked) and they will hardly affect its complexity at all. This is what I meant by chaotic noise: as you move along the number line, numbers with greater numbers of smaller prime factors will be more complex than their neighbors, and so, rather than using weight proportions to smoothing out texture of prime compositions of integers along the number line, we do literally the opposite and aggravate that texture into an unpleasantly jagged craziness that no one should want to use. Flora Canou's temperament utilities, for example, suggests that it supports it (though thankfully I find no evidence that it's actually implemented) and I strongly recommend against her doing so, if she's reading this.

To clinch this point and bring it home, we'll consider the two cases where we do only one of the inversions at a time. First, just the reciprocating of the weights, so we have simplicity-weighting:

To clinch this point and bring it home, let's consider the two cases where we do only one of the inversions at a time. First, just the reciprocating of the weights, so we have simplicity-weighting:

Line 174:

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 a ''simplicity'' prescaler inside a ''complexity'' function. We 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 we 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.

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.

[[Category:Regular temperament theory]]

[[Category:Tuning]]

@@ Line 1: / Line 1: @@
-This article is a cautionary tale for anyone who (as we, [[Dave Keenan]] and [[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 Dave's and my terminology has sufficiently matured, the name itself seems as self-contradictory as the concept.
+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.
-Why would someone ever want to try this? Well, we looked into it because we were curious about the limitation of all-interval tuning schemes whereby they only work with simplicity-weight damage. We wondered if there was nonetheless a way to achieve complexity-weight-like effects anyway. As you will see from this section, the answer is a very slight "sort of", but at such a cost of reasonableness that there's no way it's 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 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:
@@ Line 118: / Line 118: @@
 [[File:The unreasonableness of inverting a norm's complexity prescaler, as seen by comparing our default complexity lp-C against its inverse .png|frameless|700x700px]]
-Essentially what's happened is: we still have the setup of a complexity function, where additional prime factors add more weight, however, we've flipped the relative weights of those primes so that the simpler ones count for more! In the extreme, this means that I can take some interval and add tons of factors of 131 to it (that's just an arbitrary big prime we picked) and they will hardly affect its complexity at all. This is what we meant by chaotic noise: as you move along the number line, numbers with greater numbers of smaller prime factors will be more complex than their neighbors, and so, rather than using weight proportions to smoothing out texture of prime compositions of integers along the number line, we do literally the opposite and aggravate that texture into an unpleasantly jagged craziness that no one should want to use. Flora Canou's temperament utilities, for example, suggests that it supports it (though thankfully we find no evidence that it's actually implemented) and we strongly recommend against her doing so, if she's reading this.
+Essentially what's happened is: we still have the setup of a complexity function, where additional prime factors add more weight, however, we've flipped the relative weights of those primes so that the simpler ones count for more! In the extreme, this means that I can take some interval and add tons of factors of 131 to it (that's just an arbitrary big prime I picked) and they will hardly affect its complexity at all. This is what I meant by chaotic noise: as you move along the number line, numbers with greater numbers of smaller prime factors will be more complex than their neighbors, and so, rather than using weight proportions to smoothing out texture of prime compositions of integers along the number line, we do literally the opposite and aggravate that texture into an unpleasantly jagged craziness that no one should want to use. Flora Canou's temperament utilities, for example, suggests that it supports it (though thankfully I find no evidence that it's actually implemented) and I strongly recommend against her doing so, if she's reading this.
-To clinch this point and bring it home, we'll consider the two cases where we do only one of the inversions at a time. First, just the reciprocating of the weights, so we have simplicity-weighting:
+To clinch this point and bring it home, let's consider the two cases where we do only one of the inversions at a time. First, just the reciprocating of the weights, so we have simplicity-weighting:
@@ Line 174: / Line 174: @@
 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 a ''simplicity'' prescaler inside a ''complexity'' function. We 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 we 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.
+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.
 [[Category:Regular temperament theory]]
 [[Category:Tuning]]