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

- Dave Keenan
- Site Admin
**Posts:**2092**Joined:**Tue Sep 01, 2015 2:59 pm**Location:**Brisbane, Queensland, Australia-
**Contact:**

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

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.

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.

- cmloegcmluin
- Site Admin
**Posts:**1689**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

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

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

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

- Dave Keenan
- Site Admin
**Posts:**2092**Joined:**Tue Sep 01, 2015 2:59 pm**Location:**Brisbane, Queensland, Australia-
**Contact:**

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

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

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

You might also hard-code:

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?

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

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?

- Dave Keenan
- Site Admin
**Posts:**2092**Joined:**Tue Sep 01, 2015 2:59 pm**Location:**Brisbane, Queensland, Australia-
**Contact:**

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

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!

- cmloegcmluin
- Site Admin
**Posts:**1689**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

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:

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?

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:

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

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?

- Dave Keenan
- Site Admin
**Posts:**2092**Joined:**Tue Sep 01, 2015 2:59 pm**Location:**Brisbane, Queensland, Australia-
**Contact:**

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

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 2cmloegcmluin wrote: ↑Thu Dec 31, 2020 11:33 amIs 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?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.

^{abs(2_exponent)}× 3

_{abs(3_exponent)}part. And when you take the log of that you get abs(2_exponent) + lb(3)×abs(3_exponent).

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

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.

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

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

- cmloegcmluin
- Site Admin
**Posts:**1689**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

I assume you meant to write "2Dave 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 2^{abs(2_exponent)}× 3_{abs(3_exponent)}part. And when you take the log of that you get abs(2_exponent) + lb(3)×abs(3_exponent).

^{abs(2_exponent)}× 3

^{abs(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.

Oh is that the reason for taking the log, then?The fact that lb(3) is irrational means there can never be any ties of a certain kind.

Not up to finding such an example at this time. But I have no reason to think it couldn't exist.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.

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.

Okay, will do.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.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?

- Dave Keenan
- Site Admin
**Posts:**2092**Joined:**Tue Sep 01, 2015 2:59 pm**Location:**Brisbane, Queensland, Australia-
**Contact:**

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

Oops. Yes. Thanks.cmloegcmluin wrote: ↑Fri Jan 01, 2021 3:04 am I assume you meant to write "2^{abs(2_exponent)}× 3^{abs(3_exponent)}", with both of them [sup]'s.

In fact you can go one better in the simple-description stakes and drop the "3-smoothed". And I already did say that.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.

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.

No.Oh is that the reason for taking the log, then?The fact that lb(3) is irrational means there can never be any ties of a certain kind.

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 getNot up to finding such an example at this time. But I have no reason to think it couldn't exist.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.

[-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-5

^{133}/7

^{110}-comma and the lesser-13-complex-5

^{133}/7

^{110}-comma. I just made up the "13-complex" part. I have no idea what it really is.

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

*will*need to hand over their entire prime content, as that is needed to determine whether the commas are in the same size category.

- cmloegcmluin
- Site Admin
**Posts:**1689**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

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...Dave Keenan wrote: ↑Fri Jan 01, 2021 9:39 amIn fact you can go one better in the simple-description stakes and drop the "3-smoothed". And I already did say that.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.

Then what is the reason? Sorry to make you spell it out.No.Oh is that the reason for taking the log, then?The fact that lb(3) is irrational means there can never be any ties of a certain kind.

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

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

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.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 getNot up to finding such an example at this time. But I have no reason to think it couldn't exist.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.

[-84 53 52 -43> at 32.4c and

[84 -53 52 -43> at 25.2c. Both in the "comma" size category.

Excellent insight. Yes.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.

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

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.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-5^{133}/7^{110}-comma and the lesser-13-complex-5^{133}/7^{110}-comma. I just made up the "13-complex" part. I have no idea what it really is.

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.Unfortunately theywillneed to hand over their entire prime content, as that is needed to determine whether the commas are in the same size category.

- Dave Keenan
- Site Admin
**Posts:**2092**Joined:**Tue Sep 01, 2015 2:59 pm**Location:**Brisbane, Queensland, Australia-
**Contact:**

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

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

It's really not very important, since you don't need to actually calculate

*any*complexity measure.

Cool. I didn't burrow down to see how you are generating the candidates. It's not important. It's well tested by now.I alreadyhaveimplemented 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.

Sure. That works too.And it actually works the opposite way. You try to find successivelylesscomplex 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.

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

_{5}(7).

I wanted 5

^{n}≈ 7

^{m}. Take the base-2 log of both sides.

lb(5)×n ≈ lb(7)×m therefore

n/m ≈ lb(7)/lb(5)

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

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.

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

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.