Inverse-complexity-prescaled complexity - Revision history

ArrowHead294: Update links

2024-11-02T19:01:20Z

Update links

← Older revision		Revision as of 19:01, 2 November 2024
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 [[~~Dave_Keenan_%26_Douglas_Blumeyer%27s_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.		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 [[~~Dave_Keenan_%26_Douglas_Blumeyer%27s_guide_to_RTT:_all~~-~~interval_tuning_schemes~~#~~Power_norms~~\|norm power]] <math>q</math>,		* <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>.

Cmloegcmluin: prime-count vector → vector

2023-02-21T18:17:28Z

prime-count vector → vector

← Older revision		Revision as of 18:17, 21 February 2023
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 ~~the~~ interval~~'s prime-count~~ 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.		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]]

Cmloegcmluin: update info re: code libraries

2023-02-08T22:59:08Z

update info re: code libraries

← Older revision		Revision as of 22:59, 8 February 2023
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]]		[[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 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~~.		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.

			[https://github.com/FloraCanou/temperament_evaluator Flora Canou's temperament utilities] technically supports inverse-complexity-prescaled complexities, because one can set her <code>wamount</code> parameter to a negative value (<code>wamount</code> does have other legitimate reasons to be there, e.g. as Mike Battaglia's <math>s</math> value for [[BOP tuning]]). A similar thing is also possible in my own [[RTT library in Wolfram Language]] by setting <code>intervalComplexityNormPreTransformerPrimePower</code> or <code>intervalComplexityNormPreTransformerLogPrimePower</code> to a negative value. But there's not a good reason to do it.

	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:		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:

Cmloegcmluin: revise intro per recent terminology changes

2023-02-06T20:24:49Z

revise intro per recent terminology changes

← Older revision		Revision as of 20:24, 6 February 2023
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 ~~(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 going to be reciprocated to be used for [[simplicity-weight]] [[damage~~]]. 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.		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_%26_Douglas_Blumeyer%27s_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.

	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>X</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:		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>X</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:

Cmloegcmluin: Cmloegcmluin moved page Simplicity-prescaled complexity to Inverse-complexity-prescaled complexity: simplicity prescaling is a misleading concept

2023-02-04T18:11:44Z

Cmloegcmluin moved page Simplicity-prescaled complexity to Inverse-complexity-prescaled complexity: simplicity prescaling is a misleading concept

← Older revision	Revision as of 18:11, 4 February 2023
(No difference)

Cmloegcmluin: simplicity prescaler → inverse of complexity prescaler

2023-02-04T18:11:12Z

simplicity prescaler → inverse of complexity prescaler

← Older revision		Revision as of 18:11, 4 February 2023
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 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.		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 (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 going to be reciprocated to be used for [[simplicity-weight]] [[damage]]. 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 ~~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.		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.

	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:		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>X</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 19:		Line 19:
	C \\		C \\
	\left[ \begin{array} {c}		\left[ \begin{array} {c}
	~~‖C_{\text{p}}~~[1 \; 0 \; 0 \; ⟩‖_q & 0 & 0 & 0 \\		‖X[1 \; 0 \; 0 \; ⟩‖_q & 0 & 0 & 0 \\
	0 & ~~‖C_{\text{p}}~~[{-1} \; 1 \; 0 \; ⟩‖_q & 0 & 0 \\		0 & ‖X[{-1} \; 1 \; 0 \; ⟩‖_q & 0 & 0 \\
	0 & 0 & ~~‖C_{\text{p}}~~[{-2} \; 0 \; 1 \; ⟩‖_q & 0 \\		0 & 0 & ‖X[{-2} \; 0 \; 1 \; ⟩‖_q & 0 \\
	0 & 0 & 0 & ~~‖C_{\text{p}}~~[0 \; {-1} \; 1 \; ⟩‖_q \\		0 & 0 & 0 & ‖X[0 \; {-1} \; 1 \; ⟩‖_q \\
	\end{array} \right]		\end{array} \right]
	\end{array}		\end{array}
Line 28:		Line 28:


	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):		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 the inverse of a complexity prescaler (<math>X^{-1}</math>); these changes indicated in red):


Line 44:		Line 44:
	{\color{blue}S} \\		{\color{blue}S} \\
	\left[ \begin{array} {c}		\left[ \begin{array} {c}
	{\color{blue}\dfrac{1}{{\color{black}‖}{\color{red}S_{~~\text{p}~~}}{\color{black}[1 \; 0 \; 0 \; ⟩‖_q}}} & 0 & 0 & 0 \\		{\color{blue}\dfrac{1}{{\color{black}‖}{\color{red}X^{-1}}{\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 & {\color{blue}\dfrac{1}{{\color{black}‖}{\color{red}X^{-1}}{\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 & {\color{blue}\dfrac{1}{{\color{black}‖}{\color{red}X^{-1}}{\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}}} \\		0 & 0 & 0 & {\color{blue}\dfrac{1}{{\color{black}‖}{\color{red}X^{-1}}{\color{black}[0 \; {-1} \; 1 \; ⟩‖_q}}} \\
	\end{array} \right]		\end{array} \right]
	\end{array}		\end{array}
Line 57:		Line 57:
	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 [[Dave_Keenan_%26_Douglas_Blumeyer%27s_guide_to_RTT:_all-interval_tuning_schemes#Power_norms\|norm power]] <math>q</math>,		* <math>1</math> in place of our [[Dave_Keenan_%26_Douglas_Blumeyer%27s_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>~~C_{\text{p}}~~</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>S_{~~\text{p}~~}</math>.		* its inverse <math>L^{-1}</math> in place of <math>X^{-1}</math>.

	Working that out, we find for our complexity-weight case:		Working that out, we find for our complexity-weight case:
Line 136:		Line 136:
	{\color{blue}S} \\		{\color{blue}S} \\
	\left[ \begin{array} {c}		\left[ \begin{array} {c}
	{\color{blue}\dfrac{1}{{\color{black}~~‖C_{\text{p}}~~[1 \; 0 \; 0 \; ⟩‖_q}}} & 0 & 0 & 0 \\		{\color{blue}\dfrac{1}{{\color{black}‖X[1 \; 0 \; 0 \; ⟩‖_q}}} & 0 & 0 & 0 \\
	0 & {\color{blue}\dfrac{1}{{\color{black}~~‖C_{\text{p}}~~[{-1} \; 1 \; 0 \; ⟩‖_q}}} & 0 & 0 \\		0 & {\color{blue}\dfrac{1}{{\color{black}‖X[{-1} \; 1 \; 0 \; ⟩‖_q}}} & 0 & 0 \\
	0 & 0 & {\color{blue}\dfrac{1}{{\color{black}~~‖C_{\text{p}}~~[{-2} \; 0 \; 1 \; ⟩‖_q}}} & 0 \\		0 & 0 & {\color{blue}\dfrac{1}{{\color{black}‖X[{-2} \; 0 \; 1 \; ⟩‖_q}}} & 0 \\
	0 & 0 & 0 & {\color{blue}\dfrac{1}{{\color{black}~~‖C_{\text{p}}~~[0 \; {-1} \; 1 \; ⟩‖_q}}} \\		0 & 0 & 0 & {\color{blue}\dfrac{1}{{\color{black}‖X[0 \; {-1} \; 1 \; ⟩‖_q}}} \\
	\end{array} \right]		\end{array} \right]
	\end{array}		\end{array}
Line 163:		Line 163:
	C \\		C \\
	\left[ \begin{array} {c}		\left[ \begin{array} {c}
	‖{\color{red}S_{~~\text{p}~~}}[1 \; 0 \; 0 \; ⟩‖_q & 0 & 0 & 0 \\		‖{\color{red}X^{-1}}[1 \; 0 \; 0 \; ⟩‖_q & 0 & 0 & 0 \\
	0 & ‖{\color{red}S_{~~\text{p}~~}}[{-1} \; 1 \; 0 \; ⟩‖_q & 0 & 0 \\		0 & ‖{\color{red}X^{-1}}[{-1} \; 1 \; 0 \; ⟩‖_q & 0 & 0 \\
	0 & 0 & ‖{\color{red}S_{~~\text{p}~~}}[{-2} \; 0 \; 1 \; ⟩‖_q & 0 \\		0 & 0 & ‖{\color{red}X^{-1}}[{-2} \; 0 \; 1 \; ⟩‖_q & 0 \\
	0 & 0 & 0 & ‖{\color{red}S_{~~\text{p}~~}}[0 \; {-1} \; 1 \; ⟩‖_q \\		0 & 0 & 0 & ‖{\color{red}X^{-1}}[0 \; {-1} \; 1 \; ⟩‖_q \\
	\end{array} \right]		\end{array} \right]
	\end{array}		\end{array}
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 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. 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.		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 the interval's prime-count 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]]

Cmloegcmluin: remove Dave from the authorial "we"

2023-02-01T03:46:39Z

remove Dave from the authorial "we"

← Older revision		Revision as of 03:46, 1 February 2023
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:		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]]		[[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 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:Regular temperament theory]]
	[[Category:Tuning]]		[[Category:Tuning]]

Cmloegcmluin: update to reflect new name of page

2023-01-31T23:27:58Z

update to reflect new name of page

← Older revision		Revision as of 23:27, 31 January 2023
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]]. ~~Inverse prescaling~~: don't ~~do it~~!		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.

	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.		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.

Cmloegcmluin: Cmloegcmluin moved page Inverse prescaling to Simplicity-prescaled complexity: we recently changed "dual prescaler" to "inverse prescaler" so this problem needs a new name

2023-01-31T23:23:48Z

Cmloegcmluin moved page Inverse prescaling to Simplicity-prescaled complexity: we recently changed "dual prescaler" to "inverse prescaler" so this problem needs a new name

← Older revision	Revision as of 23:23, 31 January 2023
(No difference)

Cmloegcmluin at 17:42, 31 January 2023

2023-01-31T17:42:39Z

← Older revision		Revision as of 17:42, 31 January 2023
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]].		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]]. Inverse prescaling: don't do it!

	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.		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.