Naming commas and other intervals: a compilation of various sources

User avatar
ᴄᴍʟᴏᴇɢᴄᴍʟᴜɪɴ
Site Admin
Posts: 1633
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 ᴄᴍʟᴏᴇɢᴄᴍʟᴜɪɴ »

While using the code I'd written for finding and analyzing commas to assist with the selection of primary commas for the Magrathean accents used for tina-sized intervals in the Insane precision level JI notation, I stumbled upon some bugs and incomplete bits in my implementation of the Secor-Keenan comma naming scheme. It's time for me to upgrade it from "mostly works" to "gets it thoroughly right".

Earlier in this topic, Dave proposed that to break a tie between two commas with the same absolute value of their 3-exponent, the negative one should be considered more complex. But then later the notion of directed commas arose, to handle a counterexample volleo6144 had found where two commas had the exact same 3-exponent and size category and absolute value of their exponents beyond 3. I expect that if someone with stronger math skills than I were to review the proof Dave gave here, they might find that it assumes directed comma names to work.

So: do I understand this new development correctly, that now commas with negative 3-exponents and those with positive 3-exponents are independent from each other with respect to the complexity level in their names?

Let me give a concrete example. Previously we would refer to

[-4 4 -1 ⟩ 
81/80
21.506¢

as the 5C, or classic-Comma, and we would refer to

[-34 20 1⟩
17433922005/17179869184
25.414¢

as the c5C, or complex-classic-Comma.

However, nowadays these would be the 1/5C and 5C, respectively. Is that correct? I suspect @Dave Keenan may balk at the prospect of 5C referring to anything other than the syntonic comma, so I thought I should illuminate this example to ensure this is really what we want. Or he might take umbrage with the fact that something with ATE of 20 isn't complex (or is 21 the cutoff?).

I also have a question about 3-limit comma names: should they be directed, e.g. should the Pythagorean large diesis [27 -17⟩ be the "1/3L" because its 3-exponent is negative? Certainly 3-limit comma names behave differently than others — for starters, we don't name by the power of 3; we just name with "3", i.e. the Pythagorean comma is the 3C, not the 531441C. So I wouldn't be surprised if they similarly simplify to being undirected. Also, I do not believe we could ever find a similar counterexample where two 3-limit commas had the same ATE and size category, because then one of them would be negative in cents and the other would be positive (the only thing you have left to change is the 2-exponent, and good luck changing that to get any other size category).



My code currently can do comma names either factorized or unfactorized, i.e. 1/455n or 1/5.7.13n. But over email some time ago Dave and I thought that there might be good reason to go for a hybridized factorization scheme with a threshold, specifically, that whenever any side of a comma's quotient has three or more prime factors, it should be factorized.
  • 65/77n should not be factorized; it has 4 total prime factors, but there's only 2 on each side of the vinculum.
  • The 1/7.7.7.17n should be factorized, because even though it only has two different prime factors, it has 3 or more on one side.
I should point out that this rule would stipulate we write the :`::/|): 's comma as the 5.5.5M rather than the 125M... which seems extraneous. Now, the rationale for this factorization threshold was respecting the average JI-fluent musician's ability to instantly prime factorize numbers. In other words, 49 is better than 7.7 because we should reasonably expect JI peeps to be familiar with it as 7<sup>2</sup>. Certainly I'd expect most JI peeps to instantly recognize 125 as 53, though, and on the other hand, I can't say I'd recognize 289 as fast as I'd recognize 172 or 133 as fast as I'd recognize 7.19. But I don't want to get into a game of setting arbitrary thresholds here and there. And there are other considerations besides instantaneousness of recognition, such as system simplicity, or economy of character count. So perhaps we should drop this whole hybridized scheme?



Should I build in the edo naming approach touched upon here?



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?

User avatar
ᴄᴍʟᴏᴇɢᴄᴍʟᴜɪɴ
Site Admin
Posts: 1633
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 ᴄᴍʟᴏᴇɢᴄᴍʟᴜɪɴ »

You've edited my post instead of quoting it again. :evil:

(I'm not really mad)

Most of my post is still preserved here, but nothing below the horizontal rule. Can you recover it? I can check my cache too.

User avatar
Dave Keenan
Site Admin
Posts: 1954
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 about that. Yeah, it's fun to be able to use the very mad smiley. I managed to reconstruct your post above in full, thanks again to Nir Sofer's wonderful cache viewing tools. So here's my reply again, in the correct place this time.
cmloegcmluin wrote: Fri Nov 06, 2020 5:29 am Earlier in this topic, Dave proposed that to break a tie between two commas with the same absolute value of their 3-exponent, the negative one should be considered more complex.
That is still my recommendation.
But then later the notion of directed commas arose, to handle a counterexample volleo6144 had found where two commas had the exact same 3-exponent and size category and absolute value of their exponents beyond 3.
I wouldn't say directed comma names arose to handle that counterexample. Rather directed comma names arose to convey the information about which primes were in the denominator in the 2,3-reduced ratio being notated by the upward version of the symbol. Or something like that.

But it was noted that such directed comma names would also serve to distinguish the two commas of the counterexample. But I note that, even if their names could not be distinguished in that way, it would not have any practical consequences as the counterexample commas were of no musical relevance.
I expect that if someone with stronger math skills than I were to review the proof Dave gave here, they might find that it assumes directed comma names to work.
The "counterexample" referred to above, is not a counterexample to this proof. The proof says we are not interested in any "complex"-named comma for notation purposes. I believe Volleo indicated that he thought that proof was good.

The "counterexample" was a counterexample to my claim that commas having the same 2,3-reduced ratio and same size category, could always be given distinct names by listing them in order of absolute 3-exponent (with negative exponents treated as slightly greater than positive exponents of the same magnitude) and calling them "<n> complex ..." where <n> is the ordinal number of the comma in that list.

It would only be a counterexample if we were using undirected names. Because we are using directed names, the "counterexample" is not actually a counterexample.
So: do I understand this new development correctly, that now commas with negative 3-exponents and those with positive 3-exponents are independent from each other with respect to the complexity level in their names?
No.
Let me give a concrete example. Previously we would refer to

[-4 4 -1 ⟩ 
81/80
21.506¢

as the 5C, or classic-Comma, and we would refer to

[-34 20 1⟩
17433922005/17179869184
25.414¢

as the c5C, or complex-classic-Comma.
Agreed. Except I wouldn't use "classic" I'd just use "5" pronounced "five". Although the Pythagorean, classic, septimal can be used by those who prefer them, for zero-or-single prime-above-3 commas.
However, nowadays these would be the 1/5C and 5C, respectively. Is that correct?
No. The latter is the c5C or complex-5-comma.
I suspect @Dave Keenan may balk at the prospect of 5C referring to anything other than the syntonic comma,
Indeed.
so I thought I should illuminate this example to ensure this is really what we want.
It isn't.
Or he might take umbrage with the fact that something with ATE of 20 isn't complex (or is 21 the cutoff?).
There is no specific ATE cutoff. One simply lists the commas for the same (undirected) 2.3-reduced ratio and same size category, in order of increasing abs(3_exponent - ϵ), e.g. abs(3_exponent - 0.25) and gives them sequential complexity numbers.
I also have a question about 3-limit comma names: should they be directed, e.g. should the Pythagorean large diesis [27 -17⟩ be the "1/3L" because its 3-exponent is negative? Certainly 3-limit comma names behave differently than others — for starters, we don't name by the power of 3; we just name with "3", i.e. the Pythagorean comma is the 3C, not the 531441C. So I wouldn't be surprised if they similarly simplify to being undirected.
That's correct. There are no 1/3 commas. There was a suggestion above, to name 3 commas after their "EDO".
Also, I do not believe we could ever find a similar counterexample where two 3-limit commas had the same ATE and size category, because then one of them would be negative in cents and the other would be positive (the only thing you have left to change is the 2-exponent, and good luck changing that to get any other size category).
Right.

I'll respond to the stuff below the horizontal rule, later.

User avatar
Dave Keenan
Site Admin
Posts: 1954
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 Nov 06, 2020 5:29 am My code currently can do comma names either factorized or unfactorized, i.e. 1/455n or 1/5.7.13n. But over email some time ago Dave and I thought that there might be good reason to go for a hybridized factorization scheme with a threshold, specifically, that whenever any side of a comma's quotient has three or more prime factors, it should be factorized.
  • 65/77n should not be factorized; it has 4 total prime factors, but there's only 2 on each side of the vinculum.
  • The 1/7.7.7.17n should be factorized, because even though it only has two different prime factors, it has 3 or more on one side.
I should point out that this rule would stipulate we write the :`::/|): 's comma as the 5.5.5M rather than the 125M... which seems extraneous. Now, the rationale for this factorization threshold was respecting the average JI-fluent musician's ability to instantly prime factorize numbers. In other words, 49 is better than 7.7 because we should reasonably expect JI peeps to be familiar with it as 7<sup>2</sup>. Certainly I'd expect most JI peeps to instantly recognize 125 as 53, though, and on the other hand, I can't say I'd recognize 289 as fast as I'd recognize 172 or 133 as fast as I'd recognize 7.19. But I don't want to get into a game of setting arbitrary thresholds here and there. And there are other considerations besides instantaneousness of recognition, such as system simplicity, or economy of character count. So perhaps we should drop this whole hybridized scheme?
I like the hybrid scheme. I'm willing to get into the game of setting thresholds. I think I can argue why they are not entirely arbitrary.

I'm assuming readers will have learned their times tables up to at least 10*, and can recognise larger multiples of 5 by the fact that they end in 0 or 5 and can mentally divide by 5, by dividing by 10 and doubling, at least for some 2 digit numbers beyond 50, and can recognise and factor 2 digit multiples of 11 by the fact that they have two digits the same, and can recognise and factor some 3 digit multiples of 11 where the outer digits sum to the middle one. *For our purpose here, there is no advantage in knowing times tables for 11 and 12, as many people do.

We're only concerned with composite (non-prime) 2,3-free (5-rough) numbers. I'm guessing most people would agree that there's no need to factorise 55 or anything less, and that it wouldn't hurt to factorise all those greater than 625. Here's a list of all such numbers from 55 to 629, showing which ones I think should definitely be factorised, with a "Y", and which should definitely not be factorised, with a <blank>, and the "maybe"s with a "?".

…55			203	Y		319	Y		425	?		533	Y
65	?		205	?		323	Y		427	Y		535	?
77			209	Y		325	?		437	Y		539	Y
85	?		215	?		329	Y		445	?		545	?
91	Y		217	Y		335	?		451	?		551	Y
95	?		221	Y		341	?		455	?		553	Y
115	?		235	?		343	Y		469	Y		559	Y
119	Y		245	?		355	?		473	?		565	?
121			247	Y		361	Y		475	?		575	?
125			253	?		365	?		481	Y		581	Y
133	Y		259	Y		371	Y		485	?		583	?
143	?		265	?		377	Y		493	Y		589	Y
145	?		275	?		385	?		497	Y		595	?
155	?		287	Y		391	Y		505	Y		605	?
161	Y		289	Y		395	?		511	Y		611	Y
169	Y		295	?		403	Y		515	?		623	Y
175	?		299	Y		407	Y		517	Y		625	?
185	?		301	Y		413	Y		527	Y		629…	Y
187	?		305	?		415	?		529	Y			

As you can see, no single simple threshold is possible because, while I agree that 121 and 125 don't need to be factorised, there are some smaller composite 5-rough numbers that I believe should be factorised, despite having only 2 factors. These are 91 = 7 × 13 and 119 = 7 × 17. They should be factorised because they are outside of the times tables and can't be recognised as composite by the simple rules for multiples of 5 and 11.

But we could say, either:
(a) factorise 91, 119 and everything greater than 125, or
(b) factorise everything greater than or equal to 91 except for 121 and 125.
Which of these you prefer, should be influenced by whether or not you think 95 and 115 should be factorised. Of course other options are possible. e.g.
(c) Factorise everything greater than or equal to 85 except for 121 and 125.

I think repeated primes should be shown as powers. e.g. 54 (or 5^4 in plain text), not 5·5·5·5. And we probably should use the unicode dot operator rather than a full stop or middle dot. http://www.fileformat.info/info/unicode ... /index.htm
Should I build in the edo naming approach touched upon here?
Yes. Thanks. But only for 3-commas. It can be the default name on output, if you think that's a good idea.
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.

User avatar
ᴄᴍʟᴏᴇɢᴄᴍʟᴜɪɴ
Site Admin
Posts: 1633
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 ᴄᴍʟᴏᴇɢᴄᴍʟᴜɪɴ »

Dave Keenan wrote: Sat Nov 07, 2020 12:38 pm I like the hybrid scheme. I'm willing to get into the game of setting thresholds. I think I can argue why they are not entirely arbitrary.
Alright, bring it on! :ugeek: (clearly I didn't need much persuading)
But we could say, either:
(a) factorise 91, 119 and everything greater than 125, or
(b) factorise everything greater than or equal to 91 except for 121 and 125.
Which of these you prefer, should be influenced by whether or not you think 95 and 115 should be factorised. Of course other options are possible. e.g.
(c) Factorise everything greater than or equal to 85 except for 121 and 125.
There's probably even more options. One thing that bothers me about all of these suggestions is that it would call for factorizing 143, which is used in some unchangeable SMuFL class names such as accSagittal143CommaUp. And I'd contend that it doesn't need to be factorized, for the same reason 121 doesn't need to be, and maybe not even 187.

So at this point I just went ahead and made a table up to the 37-limit, and colored in ones I thought should and should not be factorized, to see if any pattern emerged:

571113171923293137
5253555658595115145155185
7497791119133161203217259
11121143187209253319341407
13169221247299377403481
17289323391493527629
19361437551589703
23529667713851
298418991073
319611147
371369

First impression was: not much of a pattern. And that I could probably keep drawing the green line up the row for 5 for a really long time, though I wouldn't call it a deep green by any means.

But if I let go of 187, which was no big deal, and sucked it up for 91, then I could get away with a pretty simple, solid rule: everything above 13 must be orange. Like this:

571113171923293137
5253555658595115145155185
7497791119133161203217259
11121143187209253319341407
13169221247299377403481
17289323391493527629
19361437551589703
23529667713851
298418991073
319611147
371369

This chart shows only combinations of 2 factors of course. There're 20 combos of 3 factors under 13: 5.5.5, 5.5.7, 5.5.11, 5.5.13, 5.7.7, 5.7.11, 5.7.13, 5.11.11, 5.11.13, 5.13.13, 7.7.7, 7.7.11, 7.7.13, 7.11.11, 7.11.13, 7.13.13, 11.11.11, 11.11.13, 11.13.13, and 13.13.13. Of these only the first few are remotely contentious, I'd say. And I think it's fine to just say 125 is the sole exception.

Here's what I'd propose:
  • factorize anything with a prime factor greater than 13.
  • factorize anything with more than 2 factors, whether they are the same or different, except 125.
I think repeated primes should be shown as powers. e.g. 54 (or 5^4 in plain text), not 5·5·5·5.
Oh you know what? I do that in the code already. I use the Unicode superscript characters.

² ³ ⁴ ⁵ ⁶ ⁷ ⁸ ⁹

The fact that I left it out of this post (as well as the draft of the submission of the tina primary commas for Steinberg I shared with you recently) was just a lapse on my part. Yes I agree with this.
And we probably should use the unicode dot operator rather than a full stop or middle dot. http://www.fileformat.info/info/unicode ... /index.htm
Sure. If a program is generating these things, that especially makes sense. I had assumed the dot/period/full stop was just a non-North American convention for multiplication or something, or an attempt to make it more accessible to the average mortal who hasn't started using WinCompose yet :)
Should I build in the edo naming approach touched upon here?
Yes. Thanks. But only for 3-commas. It can be the default name on output, if you think that's a good idea.
Okay. Well, I don't understand it yet, but I'll look over your NameCommas.xlsx and figure it out.

By the way, I definitely don't yet understand the ampersand notation which was mentioned in that same linked post too.
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.
Certainly doable. And yes, I would set it to be off by default for output.

User avatar
Dave Keenan
Site Admin
Posts: 1954
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 just asked my wife and my son and his partner if 91 was prime or composite. They are all engineers or software developers (i.e. good at maths). My wife and my son's partner almost immediately said "Prime". One of them even foolishly said, "no doubt". My son was silent for about 30 seconds and then said "it's divisible by 7", then after another few seconds, "and 13".

So I'm sorry. We can''t expect people to "suck it up" for 91. :) 91 needs to be factorised.
cmloegcmluin wrote: Sat Nov 07, 2020 4:54 pm
Should I build in the edo naming approach touched upon here?
Yes. Thanks. But only for 3-commas. It can be the default name on output, if you think that's a good idea.
Okay. Well, I don't understand it yet, but I'll look over your NameCommas.xlsx and figure it out.
I don't think it's in any spreadsheet. It's simply the absolute 3-exponent, followed by "e3" and the size category.
By the way, I definitely don't yet understand the ampersand notation which was mentioned in that same linked post too.
Nor do I, fully. But we don't use it in Sagittal at all, so don't worry.

User avatar
volleo6144
Posts: 66
Joined: Mon May 18, 2020 7:03 am
Location: Earth
Contact:

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

Post by volleo6144 »

Dave Keenan wrote: Sat Nov 07, 2020 7:13 pm I just asked my wife and my son and his partner if 91 was prime or composite. They are all engineers or software developers (i.e. good at maths). My wife and my son's partner almost immediately said "Prime". One of them even foolishly said, "no doubt". My son was silent for about 30 seconds and then said "it's divisible by 7", then after another few seconds, "and 13".

So I'm sorry. We can''t expect people to "suck it up" for 91. :) 91 needs to be factorised.
Probably. Even 51 (3.17) probably would need to too, if 3 weren't something you would have to check for anyway.

I happen to just, like, know my 13's up to around 13.14=182 or so (as well as a few extra prime products like 13.19=247 and 13.23=299, with the intention of learning all the ones, excluding 2,3,5s, up to 23.43 = 989 and maybe a little beyond), but it's probably a good idea to factorize ... well, just about anything that isn't in your standard 12.12 table, with the exception of (2's, 3's,) 5's, and maybe 11's. (Actually, scratch the 11's part, as numbers like 979 = 11.89 aren't very obvious, and even, say, 473 = 11.43 is kind of pushing it.)
A random guy who sometimes doodles about Sagittal and microtonal music in general in his free time.

User avatar
ᴄᴍʟᴏᴇɢᴄᴍʟᴜɪɴ
Site Admin
Posts: 1633
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 ᴄᴍʟᴏᴇɢᴄᴍʟᴜɪɴ »

Hey folks. Sorry about this, but @Dave Keenan and I had a deadline to hit, so we had to fastlane some decisions re: comma name factorization thresholds. Here's basically how it went down.
Dave Keenan wrote: For SMuFL I'd prefer 77/185n was written as 7/5·37n. Note the middle dot
⎄..
to minimise the chance of it being mistaken for a decimal point.

Maybe it should be 7/(5·37)n otherwise it might be read as (7/5)·37n. But readers who have any clue at all of what we're on about, should know that if we'd meant that, we would have written it as 7·37/5n. But strictly, mathematically, / and · have the same precedence and so are applied left to right. I'm in two minds about the parentheses. You decide.

...

• should we use parentheses when the denominator is factorised?
• should we use powers when primes are repeated in factorised numbers, e.g. 7⁴/25-schismina?
cmloegcmluin wrote: I hear you (and your family) re: 91. I think it depends on how one frames it. If you ask "what's the prime factorization of 91?" I think my mind quickly sees the 7×10 + 7×3 = 7×13. But if you ask "is 91 prime?" then the knee-jerk answer is "yes". So assuming you were otherwise on board with the list of rules I proposed, could we then say to factorize:
  • anything with a prime factor greater than 13
  • anything with more than 2 factors (whether they are the same or different), except 125
  • 91
I used parentheses for factorized denominators. I prefer the unambiguity. I've also switched to the middle dot; that's another thing about the full stop that I thought was intentional: because it's not literally a multiplication symbol, it somehow seems to instill less confusion w/r/t to precedence of the vinculum. But no big deal; I'll take parenthesis and the middle dot over the full stop any day.
Dave Keenan wrote: I very deliberately didn't ask "What's the prime factorization of 91?, because it hints at information musicians can't get by just looking at say "91n" on a page, as the name of a comma. Namely that it has factors.
I also didn't ask "Is 91 prime". Nor did I ask "Is 91 composite". Either of which may have introduced bias. The least biased way I could think of to ask the question was "Is 91 prime or composite"?

...

I did the same test with the same sample of 3 mathy people, for 169 and 143. They all got 143 reasonably quickly. But they were all very slow on 169. Two said it was prime. One eventually remembered it was 13 squared,2 but that took about 10 seconds.

I personally memorised squares up to 16×16 when I was quite young. There's that nicely memorable progression 169, 196.

But I think we have to factor 169 as well.

So I suggest :
  • anything with a copfr greater than 2 except 5×5×5.
  • anything with a gpf greater than 11 except 13×5 and 13×11.
So it looks like this:

65 = 5·13
77 = 7·11
85 = 5·17 yes
91 = 7·13 yes
95 = 5·19 yes
115 = 5·23 yes
119 = 7·17 yes
121 = 11·11
125 = 5·5·5
133 = 7·19 yes
143 = 11·13
145 = 5·29 yes
155 = 5·31 yes
161 = 7·23 yes
169 = 13·13 yes
... yes

BTW, the lowest N2D3P9 to be factorised is 17.01 for {175}2,3. The highest to not be factorised is 51.64 for {143}2,3. So there is no relationship between human-factorisability and N2D3P9.
cmloegcmluin wrote: Oh, cool idea to check on [the relationship between N2D3P9 and factorization threshold]. Can't say I'm surprised. Harmony doesn't give a crap how many digits humans evolved with.

Works for me. Again, once the forum is functioning, I'll share an update on the topic.
Please let us know if you have any issue with the above. We may still have time to revise our submission.

Actually, I found that a couple nuances arose which were not yet addressed above.
  • When there is only one unique prime in the denominator, I do not put them in parentheses, e.g. [ 9 -1 0 0 0 -2 ⟩ is the 1/13²C, not the 1/(13²)C.
  • When in undirected form, I do not put factorings in parentheses, because I think you could either say that the colon takes precedence, or that it doesn't even really make sense to multiply an undirected ratio, e.g. [ -14 7 1 0 -1 0 1 ⟩ is the 11:5⋅17M, not the 11:(5⋅17)M.
And a tangential question: shall we use the same factorization rules for 2,3-free class names (see https://en.xen.wiki/w/N2D3P9)?

User avatar
Dave Keenan
Site Admin
Posts: 1954
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 »

Thanks for posting the above, and explaining about the W3C/SMuFL submission.
cmloegcmluin wrote: Tue Nov 10, 2020 12:26 pm Actually, I found that a couple nuances arose which were not yet addressed above.
  • When there is only one unique prime in the denominator, I do not put them in parentheses, e.g. [ 9 -1 0 0 0 -2 ⟩ is the 1/13²C, not the 1/(13²)C.
Good call.
  • When in undirected form, I do not put factorings in parentheses, because I think you could either say that the colon takes precedence, or that it doesn't even really make sense to multiply an undirected ratio, e.g. [ -14 7 1 0 -1 0 1 ⟩ is the 11:5⋅17M, not the 11:(5⋅17)M.
Again, I agree. But why would we use undirected comma names at all in future? I'm tempted to replace them all with directed names in the XH article and everywhere they appear on the forum, to avoid confusing new readers with the two types of name.
And a tangential question: shall we use the same factorization rules for 2,3-free class names (see https://en.xen.wiki/w/N2D3P9)?
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.

User avatar
ᴄᴍʟᴏᴇɢᴄᴍʟᴜɪɴ
Site Admin
Posts: 1633
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 ᴄᴍʟᴏᴇɢᴄᴍʟᴜɪɴ »

Dave Keenan wrote: Tue Nov 10, 2020 2:23 pm But why would we use undirected comma names at all in future? I'm tempted to replace them all with directed names in the XH article and everywhere they appear on the forum, to avoid confusing new readers with the two types of name.
I would vote for standardizing to directed comma names, following the factoring threshold we've determined here, in all Sagittal materials, yes.

My code will still support them, though, just not by default, so I wanted to get it correct.
And a tangential question: shall we use the same factorization rules for 2,3-free class names (see https://en.xen.wiki/w/N2D3P9)?
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. Perhaps I should have gone ahead and shared them in the first place.

Post Reply