Dave Keenan wrote: ↑Fri Jan 01, 2021 9:39 am
But why take the log at all? Isn't it simpler to just leave it like that? Then you could say the complexity ranking is simply the product complexity of the ratio, 3-smoothed.
In fact you can go one better in the simple-description stakes and drop the "3-smoothed". And I already did say that.
Ah, right, since they have the same 2,3-free content. Sure. And so you did. But that still doesn't explain to me why to take the log...
The fact that lb(3) is irrational means there can never be any ties of a certain kind.
Oh is that the reason for taking the log, then?
No.
Then what is the reason? Sorry to make you spell it out.
But think about how you are actually going to write the code that computes what ratio is meant by something like "5-complex-3-comma". AFAIK, you just have to generate successively more complex commas, with the same prime content above 3, and in the same size category, and count them. And to generate successively more complex commas, you're going to have to increment the 2 and 3 exponents in such a way that complexity always increases, without skipping any potential combinations, but using the fact that a "comma" is something smaller than half an octave.
I already
have implemented the code already, a while ago. You can check it out
here if you're curious. I just haven't implemented any tie-breaker. And it doesn't reflect the most recent understanding we've come to with respect to comma naming where the super and sub directions of a given comma share a complexity level.
And it actually works the opposite way. You try to find successively
less complex commas, until you reach [0 0⟩ as the 3-smooth content. That way, if you find no other commas in that size category between you and nothing, then you're not a complex comma. That's how you described it yourself
back on page 1 of this thread... wait, okay, you described it the same way you did just now, starting at [0 0⟩ and working your way up to the comma. Well, I realize now that they work the same (they wouldn't if you started at the comma and worked your way up forever, of course). I guess I just felt it was more intuitive to start at the comma.
But there may still be ties where the signs of both 2 and 3 exponents are reversed, so we still have to decide on a tie-breaking convention for those.
Not up to finding such an example at this time. But I have no reason to think it couldn't exist.
We just have to find a comma that has 2 and 3 exponents of zero, then add and subtract a small 3-comma from it. For the small 3-comma we can use [-84 53⟩ at 3.6 cents. Lets find a 7-limit case. So the power of 7 has to be close to the power of 5. When I ask Wolfram alpha for convergents of ln(7)/ln(5), and work my way up the list, I come to 52/43 which gives [0 0 52 -43⟩ at 28.8 cents. So then we add and subtract the 3-comma [-84 53>, to get
[-84 53 52 -43> at 32.4c and
[84 -53 52 -43> at 25.2c. Both in the "comma" size category.
Interesting trick. I don't understand the first part — why you took the ln of 7/5, or why you knew the list of its convergents (1/1, 5/4, 6/5, 23/19, 29/24, 52/43, 81/67, 133/110, 347/287, 1521/1258, etc. (found using
this tool, which I've come to love)) would give you a 2,3-free ratio which is at least one Mercator comma away from both ends of a size category — but I'm glad you found one.
That little exercise made me realise there are still cases that can't be tie-broken on the signs of the 2 and 3 exponents. To create one, we just need to make the 7-limit comma be the small one and be added to and subtracted from a medium 3-comma.
Excellent insight. Yes.
For the 3-comma we can use [-19 12⟩ at 23.5 cents. Further up the list of convergents of ln(7)/ln(5), I come to 133/110 which gives [0 0 133 -110⟩ at 8.9 cents. So then we add and subtract it from the 3-comma [-19 12>, to get
[-19 12 133 -110> at 32.3c and
[-19 12 -133 110> at 14.6c.
Of course these are all very far removed from any musical significance, but we should still be able to deal with it.
Agreed.
In both of these cases, the two commas of the pair have the same product complexity. That makes me think we should just accept that, and use a further modifier such as "greater" and "lesser" to distinguish them. e.g. the greater-13-complex-5133/7110-comma and the lesser-13-complex-5133/7110-comma. I just made up the "13-complex" part. I have no idea what it really is.
I love this idea. Yes! Instead of agonizing over some arbitrary tie-breaker regarding their complexity, we flip back to the other aspect they exhibit — size — and implicitly recognize that while the size category bounds established work quite well for commas of musical significance, they fail us at higher levels of complexity, and therefore it's occasionally necessary within a size category to have a greater and lesser for the otherwise same named comma. Brilliant brilliant brilliant.
Unfortunately they will need to hand over their entire prime content, as that is needed to determine whether the commas are in the same size category.
Well, yeah... but I was talking about a method just for tie-breaking complexity. Perhaps this is another difference between you and me as software engineers of different generations. I understand the trend is nowadays to break things down into as small, focused methods as possible, where in earlier times the fashion was more to have big beefy methods that "did it all". And surely it swings back and forth over time, and I'm not saying one way is better than the other. But I certainly do, myself, go for small methods. One to ten lines. The complexity method I linked above is not a good example of my style. I was embarrassed when I moved on from it.