Naming commas and other intervals: a compilation of various sources

[Dave Keenan]

I would vote for standardizing to directed comma names, following the factoring threshold we've determined here, in all Sagittal materials, yes.

Cool.

My code will still support them, though, just not by default, so I wanted to get it correct.

Doubly cool.

Only if you remove the {...}_2,3 from them. That notation is not standard, is not explained in the article, and is redundant because the column heading tells you what they are. I think it will just confuse readers, and it has a cluttered look. And even then, I think the factorisations (using the same rules as for comma names) should not replace the existing ratio, but should appear only as an alternative, perhaps following an equals sign.

Okay. Yes, those were my thoughts too.

Triply cool.

[cmloegcmluin]

Should I build in the ability to recognize and substitute (parse and format) words such as Pythagorean, classic, septimal, etc. for numbers 3-, 5-, 7- etc. where appropriate?

Sure, if it's easy. But not as the default name on output, only as an option.

I'm looking through the "Comma Namer" sheet and realizing that I don't really understand the rules for when substituting words for the quotient part of the comma name is acceptable. I was hoping to find some rules there for automatically labelling them like this, but it looks like all these sorts of worded names are just hardcoded individually.

For example, the "vicesimotertial comma" seems pretty straightforward, because it has only a single factor beyond the 3-limit:

[ 5 -6 0 0 0 0 0 0 1 ⟩

But what about the "classic chromatic semitone, minor chroma"? First of all, my code has no sense of "chroma" or "chromatic semitone"; that section of the size categorization is called "small semitone" and nothing else at this time. But what's more concerning is that it has two 5's in it; it's actually a 25SS! How would I programmatically know, just from looking at:

[ -3 -1 2 ⟩

That there's no simpler 5-limit, SS-sized comma, at least one with only one 5 in it? I mean, I assume that's the approach, seeking the simplest comma possible; it's related to the idea of how the 1/5C is the classic-comma, and not the 5C, because the 1/5C is simpler.

Another example, and this one really throws me for a loop:

[ -5 2 2 -1 ⟩

That's the "septimal kleisma", even though it also has 5's in it. How could that be? And now I'm seeing that the schisma used in Sagittal is called the "tridecimal schisma", even though it has a 5 and a 7 in it! Anyway, it's just a little weird to me because it seems like there's a strong pattern of commas named in this way having only the single factor beyond the 2's and 3's, but it's only like 75-80% of the time.

Or should I instead approach this problem with a goal of just hardcoding a handful of commonly known aliases, rather than trying to generalize this? Unless there's a really straightforward rule to follow, I feel that may be best.

[Dave Keenan]

Eff those common names. They are so inconsistent. If you're going to allow "septimal" etc at all, only do it automatically (no hard coding) and only do it for the case where there is only one prime above 3 with exponent 1 or -1. Forget "chroma". Also too inconsistent. It really describes the function of the comma (failing to vanish = giving colour) in some temperament.

[cmloegcmluin]

Well, I don’t think it’d be a good idea to do it automatically in the way you describe if it’s going to lead to naming something the “septimal kleisma” other than the thing which is commonly known as such. That would be horribly confusing. So... it’s not easy, and I’ve got other things to do! Thanks

[cmloegcmluin]

Hey, here's another minor wrinkle.

I just set out to implement the "complex-", "supercomplex-", etc. prefixes when I realized that absolute 3-exponent, or ATE — according to the structure we agreed upon recently whereby badness = error + complexity, and complexity = uselessness + unpopularity — is a metric of uselessness, which is only one of the two parts of a complexity metric. So mightn't it be slightly more accurate to call these commas "useless-", "superuseless-", etc.?

I don't think "superuseless" would ever catch on. It makes me think: why are you even naming such things, in this case?

It also makes me realize a flaw with "useless" as opposed to "unuseful" is that "useless" already implies a complete lack of use, such that "superuseless" doesn't feel like it's any meaningfully more useless than something that was already (completely) useless. Perhaps I should do a global find & replace for "useless" to "unuseful" in the code base. I note that "complex" does not exhibit this problem; I have no trouble imagining things getting more and more and more complex. Well, in either case, "unuseful-" and "superunuseful-" still don't have as nice a ring to them as "complex-" and "supercomplex-" do.

Because complexity metrics include both unusefulness and unpopularity, if there was an argument for why an increase in the absolute 3-exponent would also increase a comma's unpopularity (despite it having no effect on either of the unpopularity metrics we've made serious leverage of in Sagittal: SoPF>3 and N2D3P9), then I suppose there's no problem. I certainly have no problem accepting that the 5C is less popular than the 1/5C, just taking a step back from things and being reasonable, even though they'd tie in popularity, objectively, according to our formulae.

Sorry 'bout this. Cleaning up the code is just involving tying up a bunch of little loose ends like this.

[Dave Keenan]

Well, I don’t think it’d be a good idea to do it automatically in the way you describe if it’s going to lead to naming something the “septimal kleisma” other than the thing which is commonly known as such. That would be horribly confusing. So... it’s not easy, and I’ve got other things to do! Thanks

I find your argument, for inaction on this front, to be flawless.

[Dave Keenan]

Hey, here's another minor wrinkle.

I just set out to implement the "complex-", "supercomplex-", etc. prefixes when I realized that absolute 3-exponent, or ATE — according to the structure we agreed upon recently whereby badness = error + complexity, and complexity = uselessness + unpopularity — is a metric of uselessness, which is only one of the two parts of a complexity metric. So mightn't it be slightly more accurate to call these commas "useless-", "superuseless-", etc.?

I don't think "superuseless" would ever catch on. It makes me think: why are you even naming such things, in this case?

"Superuseless" I think "Superunuseful" is superunlikely to catch on as well.

I have never found any complex comma to be useful, with the possible exception of the c3C. And I've certainly never found a supercomplex comma to be useful. So the names would at least be appropriate in meaning. But please stick with "complex", "supercomplex" etc. For reasons given below.

It also makes me realize a flaw with "useless" as opposed to "unuseful" is that "useless" already implies a complete lack of use, such that "superuseless" doesn't feel like it's any meaningfully more useless than something that was already (completely) useless. Perhaps I should do a global find & replace for "useless" to "unuseful" in the code base.

That's fine with me. "Unusefulness' follows the same pattern as "unpopularity".

I note that "complex" does not exhibit this problem; I have no trouble imagining things getting more and more and more complex. Well, in either case, "unuseful-" and "superunuseful-" still don't have as nice a ring to them as "complex-" and "supercomplex-" do.

Agreed. This will be resolved below.

Because complexity metrics include both unusefulness and unpopularity, if there was an argument for why an increase in the absolute 3-exponent would also increase a comma's unpopularity (despite it having no effect on either of the unpopularity metrics we've made serious leverage of in Sagittal: SoPF>3 and N2D3P9), then I suppose there's no problem. I certainly have no problem accepting that the 5C is less popular than the 1/5C, just taking a step back from things and being reasonable, even though they'd tie in popularity, objectively, according to our formulae.

Sorry 'bout this. Cleaning up the code is just involving tying up a bunch of little loose ends like this.

No worries. There are different kinds of complexity metric used in tuning theory. There is no requirement that they all include a combination of unpopularity and unusefulness. That's just what served our purposes in deciding what commas were best for notating as many pitches as possible. We could call this a "notational complexity" metric. When you don't have such a specific purpose in mind, the simplest complexity measure for a comma n/d is its "product complexity" n*d, or the closely related "log product complexity" lb(n*d) = lb(n)+lb(d), which stupidly get named after certain historical personages, so no one knows what you're talking about.

I think it is effectively log product complexity that we are using in naming these commas. You can obtain log product complexity directly from the monzo by taking the absolute value of every exponent and multiplying it by the log of its prime, then summing all these products. But we don't need to calculate their full product complexity to decide which is more complex, because we are comparing commas that have the same absolute exponents for every prime above 3, and the exponent of 2 is completely determined by the other prime exponents because it has to be a comma (much smaller than an octave). So to determine which comma has the greater product complexity, we only need to compare their 3 exponents.

Even if this isn't quite right. The important thing is that it's a different kind of complexity.

[cmloegcmluin]

Thanks for the previous post. That all makes total sense.

I'm thinking that the whole "n-complex" thing is only convenient if you rarely have to use it. But 3-commas seem to use it too much. And the "n-edo" thing is convenient for 3-commas.

So we have:
3s = [-84 53⟩ = 53edo 3-schisma = 53e3s
c3s = [-569 359⟩ = 359edo 3-schisma = 359e3s
sc3s = [970 -612⟩ = 612edo 3-schisma = 612e3s

There are actually a lot more in between. [-1054 665> (0.0756¢) is the c3n if [485 -306> (1.77¢) is the 3n

Agreed. 3n = 306e3n and c3n = 665e3n.

A few questions:

1. Does the "e" in 665e3n stand for "exponent", or "equal division of the octave"? The connection with the exponent is clear (and you stated it explicitly here), but I'm confused, then, by what you mean by 'the "n-edo" thing'. If there's a connection between the 3s and 53-EDO, I'm unaware of it. I especially need to know so that when it spells the words out (like schismina, complex, etc...) it knows what to put there. Would it be "665-exponent-3-schismina" or "665-EDO-3-schismina"?
2. I'd like to avoid adding an additional option to the code if I can. For a feature as obscure as this, I want the code to just do it the smartest way without anyone needing to think about it. In this case, I could avoid it if this e-form was not an alternative to the c-form for 3-limit commas, but the only form for naming complex 3-limit commas. I could make it able to parse 306e3n, but it would not be configurable to spit it out itself, in its tabular results for comma searches, etc.
3. Whether or not e-form is an option, I need to know whether the simplest 3-limit comma in each category should drop the e-part of its name. My gut says it should be dropped, much in the same way no c- prefix is necessary for the simplest comma in each size category for 5-limit and above commas, though if the e-form is an option, there is argument for the case that ever dropping it might be confusing. Let me know what you think. Again, I could make the code able to parse c3n, but not configurable to spit it out itself.

[Dave Keenan]

A few questions:

1. Does the "e" in 665e3n stand for "exponent", or "equal division of the octave"? The connection with the exponent is clear (and you stated it explicitly here), but I'm confused, then, by what you mean by 'the "n-edo" thing'. If there's a connection between the 3s and 53-EDO, I'm unaware of it. I especially need to know so that when it spells the words out (like schismina, complex, etc...) it knows what to put there. Would it be "665-exponent-3-schismina" or "665-EDO-3-schismina"?

The "e" stands for "edo". The connection between the 3s and 53edo is that 3s is the generalised Pythagorean comma (3-comma) that is tempered out in 53-edo just as the specific Pythagorean Comma 3C is the 3-comma that is tempered out in 12edo. The absolute 3 exponent of a 3-limit comma is the EDO in which it is tempered out, because it's equivalent to chaining fifths and octave reducing until you almost come back to an octave or unison.

• I'd like to avoid adding an additional option to the code if I can. For a feature as obscure as this, I want the code to just do it the smartest way without anyone needing to think about it. In this case, I could avoid it if this e-form was not an alternative to the c-form for 3-limit commas, but the only form for naming complex 3-limit commas. I could make it able to parse 306e3n, but it would not be configurable to spit it out itself, in its tabular results for comma searches, etc.

Sure. Make the "e" form the only form for output of 3-commas. If it's easy to also parse the "c" form on input, that would be good.

• Whether or not e-form is an option, I need to know whether the simplest 3-limit comma in each category should drop the e-part of its name. My gut says it should be dropped, much in the same way no c- prefix is necessary for the simplest comma in each size category for 5-limit and above commas, though if the e-form is an option, there is argument for the case that ever dropping it might be confusing. Let me know what you think. Again, I could make the code able to parse c3n, but not configurable to spit it out itself.

Yes, you should drop the e-part for the simplest 3-comma in each size category. I note that
1c3C = c3C = 41e3C and
0c3C = 3C = 12e3C.
The form for output is bolded.

[cmloegcmluin]

The absolute 3 exponent of a 3-limit comma is the EDO in which it is tempered out, because it's equivalent to chaining fifths and octave reducing until you almost come back to an octave or unison.

I still don't see the connection between the two ideas, sorry.

Let's look at this example of the 3s [ -84 53 ⟩ and 53-EDO. The 3-limit patent val for 53-EDO is ⟨ 53 84 ]. Okay, so I suppose that's obvious enough that it would map to 0 steps (temper out). I can understand why the patent val would work this way for a tiny commatic interval such as a schisma, but what about a diesis — would the 3-term of the patent val always match the 3-term of a commatic interval, up to the half apotome?

And I also think I see why this works best for the 3-limit, because there's no other prime in between 2 and 3 to confuse the issue. I could replicate this concept in the 5-limit, e.g. the 1/125C [ 7 0 -3 ⟩ is similarly associated with 3-EDO because it is tempered out there by the patent val ⟨ 3 5 7 ] (where the 3-term is irrelevant, and thus not bolded), or in 5-EDO ⟨ 5 8 12 14 ] the comma [ -14 0 0 5 ⟩ is tempered out, etc. etc.

But I still don't see how we can safely assume the patent val will accommodate (match) all commatic intervals like this, unless you chose the size categories specifically to handle it.

I could make it able to parse 306e3n, but it would not be configurable to spit it out itself, in its tabular results for comma searches, etc. [/list]

If it's easy to also parse the "c" form on input, that would be good.

Oops. I wrote my sentence wrong. Sorry about that. I meant to say "I could make it able to parse c3n, but it would not..." So yes, the goal is: input anything, output only e-form.