Inverse-complexity-prescaled complexity: Difference between revisions

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:

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