Inverse-complexity-prescaled complexity: Difference between revisions

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

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