Naming commas and other intervals: a compilation of various sources

User avatar
Dave Keenan
Site Admin
Posts: 2180
Joined: Tue Sep 01, 2015 2:59 pm
Location: Brisbane, Queensland, Australia
Contact:

Re: Naming commas and other intervals: a compilation of various sources

Post by Dave Keenan »

I'm fine with allowing "half" before any comma name, and I'm fine with the scaled monzos. But I dont like the square rooty ones.

Yes, we can have a default comma for every size category when no ratio is given, and it is certainly 3 in the apotome and medium semitone categories. But the default comma and schisma are 5. shismina is 5.7.13. Others I'd have to look up. It's based on historical usage.
User avatar
cmloegcmluin
Site Admin
Posts: 1700
Joined: Tue Feb 11, 2020 3:10 pm
Location: San Francisco, California, USA
Real Name: Douglas Blumeyer (he/him/his)
Contact:

Re: Naming commas and other intervals: a compilation of various sources

Post by cmloegcmluin »

Alright. I thought my proposals didn't create ambiguities, but I was wrong. Since in this context we conventionally use single-letter abbreviations (elsewhere I had gotten accustomed to using 2-letter abbreviations), we actually can't use "h" as the abbreviated form of "half" (like how "c" is the abbreviated form of "complex"), since that'd be ambiguous with the "h" of "hc" (hypercomplex) when applied to a complex comma. Any other suggestions? "s" for "semi-" or "square root" is ambiguous with "sc" (supercomplex) in the same way. "demi-" is another common prefix for half, so we could have "d3A" for the half apotome, but I don't really like that at all. I think I may need to break from the pattern of abbreviated and unabbreviated versions always being on the same side of the comma name, and make the suggestion that unabbreviated names prefix with "half-", while abbreviated names suffix with "/2".

If/when you get a list of hardcoded default commas per size category based on your knowledge of historical usage, I can work that in. But it won't block anything.

And no rush, but just in case you missed it (as I have been known to do), I'm still waiting for a reply re: hyphens and spaces, and the preferred outputs. (I was also kinda hoping I'd get at least a high-five or something for finding two 5²⋅7/11C's, haha).
User avatar
Dave Keenan
Site Admin
Posts: 2180
Joined: Tue Sep 01, 2015 2:59 pm
Location: Brisbane, Queensland, Australia
Contact:

Re: Naming commas and other intervals: a compilation of various sources

Post by Dave Keenan »

Sorry. I've had little time to devote to Sagittal in the past 3 days. So I was only able to respond to those things I knew off-the-top-of-my-head, not anything I had to investigate such as your purported simple counter-examples to my 3-exponent-based "<n>-complex" naming scheme.

Namely that both [15 -12 2 1 -1⟩ and [-23 12 2 1 -1⟩ qualify as the 5²⋅7/11C.

So now that I've had time to investigate it, I can say :hand:

I see one trick is to find a simple comma whose 3-exponent is zero, and which is small enough so that when it is both added to and subtracted from a simple 3-comma, it does not push it into a different size-category.

And I agree that the solution is to consider the 2-exponent as well as the 3-exponent, in determining the relative complexities. Specifically, I think we should use abs(3_exponent) + abs(2_exponent)/lb(3) as the complexity ranking value. Or equivalently, and in a more standard form, abs(2_exponent) + lb(3)×abs(3_exponent). This should allow us to enumerate them in order of complexity.

Thanks @volleo6144 and @cmloegcmluin for making me see the error of my ways. :)

I note that your earlier example, cmloegcmluin, of [-84 53 0 -1 2 0 -1⟩ and [84 -53 0 -1 2 0 -1⟩ was already handled by my scheme, because it treated a negative 3-exponent as more complex than a positive 3-exponent of the same magnitude (in the upward versions of the commas). I propose we continue to use the sign of the 3-exponent as the tie-breaker in that manner. The only question I have now is whether it should be the 3-exponent in the upward version of the comma or in the version of the comma that has the upward (superunison) 2,3-removed value. Which is the easiest to enumerate in complexity order?

I agree that your asterisked names in the table above are preferred and should be used in output.

I agree that hyphens should be used when outputting the full comma names, but can be omitted on input. However I might prefer a space, not a hyphen, after the word "half". You decide.

I agree that the only acceptable abbreviation of "half" is as a suffix "/2".

The default commas for the size categories are as follows (mostly found by searching on the category names in the Xen Wiki and Wikipedia):

schismina		4095	4096	0.422716166	
schisma			32768	32805	1.953720788	
kleisma			15552	15625	8.107278862	
comma			80	81	21.5062896	
small diesis		125	128	41.05885841	diesis, lesser diesis
medium diesis		32	33	53.27294323	undecimal diesis
large diesis		625	648	62.565148	greater diesis
small semitone		24	25	70.67242686	chromatic semitone
medium semitone		243	256	90.22499567	limma
large semitome		15	16	111.7312853	diatonic semitone
apotome			2048	2187	113.6850061	

You might also hard-code:

diaschisma		2025	2048	19.55256881

Regarding common names like "septimal kleisma" and "tridecimal schismina", the numeric word gives only the prime-limit of the comma, not its complete prime content above 3. You could hard code these as exceptions to the usual rules if you want (on input only), or not.

Have I missed anything?
User avatar
Dave Keenan
Site Admin
Posts: 2180
Joined: Tue Sep 01, 2015 2:59 pm
Location: Brisbane, Queensland, Australia
Contact:

Re: Naming commas and other intervals: a compilation of various sources

Post by Dave Keenan »

Now that you taught me the trick, I went looking for other simple counterexamples to my (now-abandoned) "<n>-complex" naming scheme, and I can't find simpler than yours, involving adding and subtracting [4 0 -2 -1 1⟩ (9.9 cents) from simple 3-commas. Well found!
User avatar
cmloegcmluin
Site Admin
Posts: 1700
Joined: Tue Feb 11, 2020 3:10 pm
Location: San Francisco, California, USA
Real Name: Douglas Blumeyer (he/him/his)
Contact:

Re: Naming commas and other intervals: a compilation of various sources

Post by cmloegcmluin »

Thanks for all this. I don't think you've missed anything.

I see what you mean about my earlier example. Comparing the two commas, in upward form:

[-84 53 0 -1 2 0 -1⟩
[84 -53 0 -1 2 0 -1⟩

Their 3-exponents have different signs, while my more recent example's two commas, in upward form:

[-15 12 -2 -1 1⟩
[-23 12 2 1 -1⟩

Have exactly identical 3-exponents.

Another difference from the earlier example is that their 2,3-free contents which define the quotient part of the names are flipped relative to each other, but that's irrelevant, because as we've recently established, you can get the other direction of a comma by flipping the quotient part of the name, so one complexity level occupies both up and down.

So my earlier example was not useful. Regardless whether the two commas' 2-exponents had the same absolute value, the existing tie-breaker (sign of 3-exponent) would already have distinguished their names (I had forgotten about this tie-breaker; it was proposed here).

So we still haven't found an example where two commas have identical 3-exponents, and the same absolute value of 2-exponent. If we did find such an example, though, it would show that my proposed 2-exponent tie-breaker was a bad idea. But I don't think we need to pursue such an example, because you've proposed this:
And I agree that the solution is to consider the 2-exponent as well as the 3-exponent, in determining the relative complexities. Specifically, I think we should use abs(3_exponent) + abs(2_exponent)/lb(3) as the complexity ranking value. Or equivalently, and in a more standard form, abs(2_exponent) + lb(3)×abs(3_exponent). This should allow us to enumerate them in order of complexity.
Is that just the tie-breaker though, or supposed to rank all commas in the same size category with the same 2,3-free prime content by complexity? Because if it's the latter, then what you're proposing is not merely a perfected tie-breaker, but a fundamental shift in how complexity is ranked. Right? With lb(3) ≈ 1.585, that means if you had a comma with [2 0 {2,3-free-stuff}⟩ and another comma with [0 1 {the same 2,3-free-stuff}⟩ then the former would be the more complex, even though in the past it would have been less complex. Perhaps you command a more intuitive understanding of this domain and can immediately recognize how that wouldn't, say, compromise the established names for any commas in Sagittal currently (including the ones for Magratheans which we submitted to SMuFL already). I'm just not sure myself. Before I go implementing this I want to make sure we're on the same page.

I had a bunch of other thoughts about this stuff half-drafted here, but apparently half a month is plenty of time to lose context on it and now no longer really understand what I was trying to say. Oh well.

One thing that concerns me is that in the Sagittal-SMuFL-Map we use a different format than we've just decided should be preferred. Do you think we should go back and update that?
User avatar
Dave Keenan
Site Admin
Posts: 2180
Joined: Tue Sep 01, 2015 2:59 pm
Location: Brisbane, Queensland, Australia
Contact:

Re: Naming commas and other intervals: a compilation of various sources

Post by Dave Keenan »

cmloegcmluin wrote: Thu Dec 31, 2020 11:33 am
And I agree that the solution is to consider the 2-exponent as well as the 3-exponent, in determining the relative complexities. Specifically, I think we should use abs(3_exponent) + abs(2_exponent)/lb(3) as the complexity ranking value. Or equivalently, and in a more standard form, abs(2_exponent) + lb(3)×abs(3_exponent). This should allow us to enumerate them in order of complexity.
Is that just the tie-breaker though, or supposed to rank all commas in the same size category with the same 2,3-free prime content by complexity? Because if it's the latter, then what you're proposing is not merely a perfected tie-breaker, but a fundamental shift in how complexity is ranked. Right?
Right! It's one of those "I don't know why I didn't think to do it that way in the first place" things. It is simply ranking the commas by their product complexity n × d. And of course, taking the base-2 log of that doesn't change the ranking. And we're ranking commas with the same prime content above 3, so all that matters is the 2abs(2_exponent) × 3abs(3_exponent) part. And when you take the log of that you get abs(2_exponent) + lb(3)×abs(3_exponent).

With lb(3) ≈ 1.585, that means if you had a comma with [2 0 {2,3-free-stuff}⟩ and another comma with [0 1 {the same 2,3-free-stuff}⟩ then the former would be the more complex, even though in the past it would have been less complex.
Correct. But they would never be in the same size category since the smallest ratio you can make between them by choosing the signs of the 2 and 3 exponents is 4/3. But yes, there could be something like [65 0 {2,3-free-stuff}⟩ and another comma with [0 41 {the same 2,3-free-stuff}⟩ in the same size category (19.8 cents difference). And the one with the zero 3-exponent would now be considered more complex (because its numerator times its denominator would be greater).

The fact that lb(3) is irrational means there can never be any ties of a certain kind. 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.
Perhaps you command a more intuitive understanding of this domain and can immediately recognize how that wouldn't, say, compromise the established names for any commas in Sagittal currently (including the ones for Magratheans which we submitted to SMuFL already). I'm just not sure myself. Before I go implementing this I want to make sure we're on the same page.
I'm sorry I can't immediately give you a proof. So yes, it is only intuition. But I'm pretty sure it doesn't change any of the names that don't have the word complex in them. And I'm pretty sure it doesn't change those few 3-commas of significance that do have the word complex. But an enumeration of them, in increasing order of complexity, would soon tell.
One thing that concerns me is that in the Sagittal-SMuFL-Map we use a different format than we've just decided should be preferred. Do you think we should go back and update that?
Yes. Good idea. We can't change the "SMuFL description". Therefore the old undirected-comma names are preserved there anyway. But we can change the "pitch description" to use the directed-comma names and eliminate the ups and downs.
User avatar
cmloegcmluin
Site Admin
Posts: 1700
Joined: Tue Feb 11, 2020 3:10 pm
Location: San Francisco, California, USA
Real Name: Douglas Blumeyer (he/him/his)
Contact:

Re: Naming commas and other intervals: a compilation of various sources

Post by cmloegcmluin »

Dave Keenan wrote: Thu Dec 31, 2020 6:56 pm And we're ranking commas with the same prime content above 3, so all that matters is the 2abs(2_exponent) × 3abs(3_exponent) part. And when you take the log of that you get abs(2_exponent) + lb(3)×abs(3_exponent).
I assume you meant to write "2abs(2_exponent) × 3abs(3_exponent)", with both of them [sup]'s.

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

Our typical tie-breaker format is positive-simpler-than-negative, or super-simpler-than-sub. Previously we'd wondered whether for the tie-breaker it'd be better to look at the entire comma or just it's 3-smoothed content. It feels like you could argue for either way being more meaningful. I don't have a strong sense for this. But I can say, as a software dev, that it seems probably easier and cleaner if the tie-breaker can be part of a complexity measure defined for 3-smooth numbers, i.e. that commas could hand off just their 3-smooth content to this method and get back an answer re: complexity, i.e. that they wouldn't need to hand their entire prime content over to the method in case it needed the commas' 2,3-free content in the case of a tie. So perhaps it should be whichever comma's 3-smooth content is super (greater than one) is the simpler one.

I briefly looked to see if I could find any mention of established tie-breaking principles for product complexity, or Benedetti height as it is often called in xenharmonic circles. But I didn't find anything. So we're probably free to choose as we wish.
One thing that concerns me is that in the Sagittal-SMuFL-Map we use a different format than we've just decided should be preferred. Do you think we should go back and update that?
Yes. Good idea. We can't change the "SMuFL description". Therefore the old undirected-comma names are preserved there anyway. But we can change the "pitch description" to use the directed-comma names and eliminate the ups and downs.
Okay, will do.
User avatar
Dave Keenan
Site Admin
Posts: 2180
Joined: Tue Sep 01, 2015 2:59 pm
Location: Brisbane, Queensland, Australia
Contact:

Re: Naming commas and other intervals: a compilation of various sources

Post by Dave Keenan »

cmloegcmluin wrote: Fri Jan 01, 2021 3:04 am I assume you meant to write "2abs(2_exponent) × 3abs(3_exponent)", with both of them [sup]'s.
Oops. Yes. Thanks.
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.

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

All monzo directions here are chosen so the comma as a whole is super, and not considering whether the 2,3-reduced ratio is super or sub.

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.

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.

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.

Our typical tie-breaker format is positive-simpler-than-negative, or super-simpler-than-sub. Previously we'd wondered whether for the tie-breaker it'd be better to look at the entire comma or just it's 3-smoothed content. It feels like you could argue for either way being more meaningful. I don't have a strong sense for this. But I can say, as a software dev, that it seems probably easier and cleaner if the tie-breaker can be part of a complexity measure defined for 3-smooth numbers, i.e. that commas could hand off just their 3-smooth content to this method and get back an answer re: complexity, i.e. that they wouldn't need to hand their entire prime content over to the method in case it needed the commas' 2,3-free content in the case of a tie. So perhaps it should be whichever comma's 3-smooth content is super (greater than one) is the simpler one.
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.
User avatar
cmloegcmluin
Site Admin
Posts: 1700
Joined: Tue Feb 11, 2020 3:10 pm
Location: San Francisco, California, USA
Real Name: Douglas Blumeyer (he/him/his)
Contact:

Re: Naming commas and other intervals: a compilation of various sources

Post by cmloegcmluin »

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.
User avatar
Dave Keenan
Site Admin
Posts: 2180
Joined: Tue Sep 01, 2015 2:59 pm
Location: Brisbane, Queensland, Australia
Contact:

Re: Naming commas and other intervals: a compilation of various sources

Post by Dave Keenan »

cmloegcmluin wrote: Sat Jan 02, 2021 4:14 am Then what is the reason [for considering log-product complexity rather than product complexity]? Sorry to make you spell it out.
Only the perhaps-too-obvious fact that, in enumerating the commas with the same prime content above 3, between [0⟩ and the comma being named, no matter which order you do it, you are presumably incrementing or decrementing exponents of 2 and 3, and computing cents by taking the dot product of the monzo with 1200×⟨lb(2) lb(3) lb(5) ... ], not multiplying or dividing by factors of 2 and 3. i.e. you will be working entirely in the log domain.

It's really not very important, since you don't need to actually calculate any complexity measure.
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.
Cool. I didn't burrow down to see how you are generating the candidates. It's not important. It's well tested by now.
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.
Sure. That works too.
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.
I didn't take the ln of 7/5. That would be ln(7) - ln(5). I took lb(7)/lb(5) which is the same as ln(7)/ln(5). It's also log5(7).

I wanted 5n ≈ 7m. Take the base-2 log of both sides.
lb(5)×n ≈ lb(7)×m therefore
n/m ≈ lb(7)/lb(5)
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.
Not so fast. I just realised it's possible for there to be more than 2. Repeat what I did with powers of 5 and 7 using powers of 11 and 13. So we have a small 2,3-comma, a small 5,7-comma (no 2's or 3's) and a small 11,13-comma (no 2's, 3's, 5's or 7's). Then we can add and subtract them in various ways to make 4 commas with the same complexity in the same size category. Then we can do the same again with powers of 17 and 19 and get 8 commas, and so on.

Sorry for the bad news. We can either fall back on:  not musically relevant.

Or we come up with some way of sorting them based on the signs of all the primes. e.g. Treat the signs as a binary number where a minus is a 1 and a plus is a 0, and the sign of the 2-exponent is the least significant bit.
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.
I think it's more that when my generation learned to program (at University in 1980, not High School) we were using machines with 64 KiB of RAM, 170 KiB of (floppy) disk, a bus width of 8 bits and a clock speed of 2 MHz (the MOS 6502), using a text editor and a Pascal compiler via a character-only display (25 lines of 80 characters monospaced). And Computer Programmers made up such a small percentage of the workforce that only the best and brightest need apply. We had to be clever, to do a lot with so little.

Now, the world needs so many programmers we can't require them to all have IQs of 125 or more, because that's only 5% of the population (although you probably do). And we have computing power to squander. About a million times the computing power on our desks now, compared to what I had back then. So who cares if the searching of a list of 3000 words is so inefficient it is doing a thousand times more operations than it really needs to. An efficiency of 0.1%. It causes me pain to think of it. But it's far more important that the programmer can write it quickly and test it easily and still understand how it works a few weeks later.
Post Reply