developing a notational comma popularity metric

Post Reply
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: developing a notational comma popularity metric

Post by cmloegcmluin »

I was reflecting on the original ask this morning. In my head it was something like "SoPF>3 is super simple; for our improved metric, it can be super-complicated, within reason, as long as it fits the data really well." But when I reviewed Dave's original ask, a couple phrases stuck out:
it need not be easily mentally calculated.
I challenge readers to come up with a simple function
So I think the level of complexity Dave is looking for is something like this: not necessarily mental-math-able, but people should be able to easily remember the formula. And whether or not that's exactly what Dave was thinking, I now think that's a pretty good standard.

And I don't think that previous formula is memorable. So I set out this morning to see if a simplification of it could fit the data almost as well. I would trade a little bit of accuracy for simplicity. And so I tried simplifying the sopf part of the equation:

sopafr(num) + k×sopafr(den) +
u×sopf(num/den) +
s×primelimit(num/den)

And, with mixed feelings, my code spat out an even lower sum of squares.

I must admit that part of my process is still manual. I simply don't have the computing power to brute force the optimal values for these parameters k, a, s, u. What I'm doing is choosing for each one a reasonable range of values and a resolution of points between them, and just running it for every point in that lattice. Then waiting for the code to give me the best results, and then tightening in around the best value gradually shrinking the search space and increasing the resolution of points within it that I check. So the explanation for finding a better sum of squares despite having strictly constrained the formula can only be that I goofed previously and didn't proceed methodically enough and somehow zeroed in on a local minimum but not the overall minimum.

If anyone knows a better process, let me know.

I guess I could automate it to make a list of any minima aka any point that gives a better sum of squares than any of its neighbor points (those off by 1 resolution step in either direction for any of the parameters), and then recursively for each of those points drill into the volume bounded by all of those neighbor points, and keep branching until I hit some accuracy threshold and then settle on the absolute minimum.

I should probably share something else that I glossed over in the previous post, but just for the record: I did in fact experiment in the other direction, with an even more complicated formula, where for sopf, I used a different scalar than k (called it j) on the smaller of the numerator and denominator, and I also used a different exponent on the primes there (called it b, instead of a). Unsurprisingly, the best values for k and j came out close to each other, and the best values for a and b came out close to each other, so I decided this level of complexity was not worth including.

So for my simplified formula, the best coefficients are coming out something like this now:

sopfr(num) + ⅜sopfr(den) + ⅛sopf(num/den) + ⅙primelimit(num/den)

To be exact, k =0.368, a=0.624, s=0.171, u=0.127, z=-1, cut-off-point=80 gives a sum-of-squares of 0.005357700411912983.

Without using sopf at all, the best fit I can find is 0.006905116251199162 (k=0.397, a=0.872, s=0.168, u=0, z=-1, cut-off-point=80). So I think we should keep sopf in there.

And I thought we should keep prime limit in on principle alone, to differentiate e.g. 25/7 from 17/1. But maybe raising the primes to powers could somehow cover that need. No. The best fit I could find without prime limit was 0.007112286611103173, (k=0.753, a=0.517, s=0.285, u=0, z=-1, cut-off-point=80).

And if I try reintroducing the complexity of splitting the numerator and denominator for sopf, as well as raising the primes to a power for sopf, the best values seem to be very near 1. So that's further evidence to just leave that complexity out. (Another would be that I didn't like how sometimes the numerator and denominator would get flipped for sopf but not for sopfr, or vice versa... just made me a little uncomfortable... probably fine but felt really strange.)

Perhaps there's a better way someone knows to express the formula to capture the effect of how it's not really the denominator part of the ratio that gets modified by k but whichever of the numerator and denominator is smallest after processing it by sopfr. Maybe we have to put it like this:

𝜈(rough5(c1/c2)) = max(sopfr(c1), sopfr(c2)) + ⅜min(sopfr(c1), sopfr(c2)) + ⅙sopf(c1/c2) + ⅛gpf(c1/c2)

It looks like a lowercase "v", but it's the Greek lowercase "nu", which I chose because it could stand for "notational unpopularity". Maybe typing "v" would generally be okay when it's clear from context what we're talking about.

You'll also notice I replaced primelimit() with a better name. In the mathematical literature seems to be either P() for "largest prime divisor" (where p() is the "smallest prime divisor") or gpf() for "greatest prime factor".

http://www.nathanmcnew.com/PopularPrimes.pdf
https://projecteuclid.org/download/pdf_ ... 1250127234
http://www.math.cmu.edu/~mlavrov/arml/1 ... utions.pdf
http://nntdm.net/papers/nntdm-19/NNTDM-19-1-55-58.pdf
https://link.springer.com/chapter/10.10 ... -3638-9_27
https://mathworld.wolfram.com/GreatestPrimeFactor.html

I suggest we use gpf() as it looks more similar to sopf and is less ambiguous.

So then the only thing we'd really have to explain is what the heck sopfr means; perhaps the best way to describe it is as the "sum of prime factors with repetition, but where each prime is raised to the power of 5/8".

And of this 𝜈(c) function we can say that it maximizes Spearman's ρ for rankz where z is Zipf's exponent, -1, over the top commas in Scala's popularity statistics where the entry had at least 0.05% of the total votes (that's another way of saying at least 19 of them, which in turn is the same as saying in the top 80).

Finally, how does 𝜈(c) perform on the simple pairs of low primes?

7/5 → 5.59 (1318 votes)
35/1 → 11.71 (875 votes)

11/5 → 6.99 (339 votes)
55/1 → 7.32 (119 votes)

11/7 → 7.55 (324 votes)
77/1 → 7.72 (111 votes)

So it's not exactly proportional, but then, the goal hasn't been for them to be proportional since Dave focused us in on matching ranks rather than values.

and how does it look?

Image

So, interestingly, it is not a better fit by R2, which is what we were going for before. But Spearman's ρ is more what we want.

I do have another question though: should we experiment with taking the logarithms of the primes rather than raising them to some power < 1?
Attachments
SoPFgt3 vs v.png
(169.76 KiB) Not downloaded yet
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: developing a notational comma popularity metric

Post by cmloegcmluin »

I've just experimented with using a logarithmic weight on the primes rather than a sublinear (<1) exponent. This also was capable of giving a really low sum of squares, but not quite as low.

And here's a visual of an example of a sublinear exponent vs. a logarithm, so you can see the different in the shape of the curve. This should help you understand how logarithms will punish bigger primes less and smaller primes more.

Image

Here's what I found:
sum of squares: 0.00557595331155862
k=0.355
j=0.8 (again, j is k but for the sopf term)
a=1.411
b=1.343 (again, b is a but for the sopf term)
s=0.582
u=0.178
r=-1 (AKA z)
cutOffPoint=80
soπfr=false (I haven't been using π for a while, but just to be clear)
soπf=false (I haven't been using π for a while, but just to be clear)
logarithmicA=true
logarithmicB=true

So I think we should stick to the sublinear exponent.
Attachments
log vs sublinear exponent.png
(21.81 KiB) Not downloaded yet
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: developing a notational comma popularity metric

Post by cmloegcmluin »

I know we haven't settled on a metric yet, but I elected to get the infrastructure in place to check the primary commas for symbols in the JI notations, i.e. to verify that they are the most popular commas in their secondary comma zones according to this metric.

Only about half of the time was this true. But fret not: I realized that we shouldn't hold ourselves to this condition.

Almost straight away its clear this couldn't be the case everywhere. Consider the 5s: it is a notationally popular comma, but it doesn't get assigned a symbol until we reach the Ultra precision level, where it gets :'::|: . In the High precision level, just below Ultra, pitches in that vicinity are represented by :)|: , whose primary comma is the 19s. Even by SoPF>3, it's obvious that 5s would be preferable were that the only condition. There must be a lot else going on here than SoPF>3 or an improvement upon it. While this popularity metric we're developing is important, it is not the only criterion; we already also know about apotome slope, abs3exp, etc. and there are probably many more considerations. There must be other reasons why when the High precision level was locked in, 19s was chosen instead of 5s.
User avatar
Dave Keenan
Site Admin
Posts: 2180
Joined: Tue Sep 01, 2015 2:59 pm
Location: Brisbane, Queensland, Australia
Contact:

Re: developing a notational comma popularity metric

Post by Dave Keenan »

cmloegcmluin wrote: Sun Jun 28, 2020 2:07 am When limiting to the first 80 items, I get -1.38. Almost exactly the same as -1.37. When I extend it out to all 820 of them, I get -1.39, also very close.

How are you finding your match for this rank exponent?
I've attached a spreadsheet that does nothing but calculate that exponent. I'm estimating the votes as est_votes = c×rankz. You'll see c and z in yellow cells. I gave them reasonable initial guesses (8000 and -1). Then I calculate the squared differences between the estimated and actual votes. Then I sum those squared errors for the first 80 ratios, in the pink cell. Then I choose Data→Solver and ask it to minimise the pink cell by adjusting the two yellow cells, c and z.

The result is z = 1.12. If instead I sum the squared errors for all 820, I get z = 1.13. If I sum them only for the first 7 ratios I get z = 0.99.

I agree it would be useful to have different names for this result and the exponent we choose to use in weighting the errors for optimising the (un)popularity metric. "r" is fine with me, for the latter. But I also agree it would be simpler, and defensible, to use r = -1, in which case we don't need a variable for it.

However, I think we should try to figure out why our different methods come up with such wildly different values for z. I suspect it's because my method effectively gives more weight to the ratios that have more votes.

Thanks for investigating π(p). I'm happy for us to forget about it now.
Attachments
ZipfExponent.xlsx
(75.57 KiB) Downloaded 139 times
User avatar
Dave Keenan
Site Admin
Posts: 2180
Joined: Tue Sep 01, 2015 2:59 pm
Location: Brisbane, Queensland, Australia
Contact:

Re: developing a notational comma popularity metric

Post by Dave Keenan »

cmloegcmluin wrote: Mon Jun 29, 2020 9:39 am There must be a lot else going on here than SoPF>3 or an improvement upon it. While this popularity metric we're developing is important, it is not the only criterion; we already also know about apotome slope, abs3exp, etc. and there are probably many more considerations. There must be other reasons why when the High precision level was locked in, 19s was chosen instead of 5s.
No, not a lot else. It's really just the 3-exponents. (for schismas and schisminas, apotome slope and abs3exp are essentially the same thing).

So strictly-speaking, we're not even working on a notational-comma popularity metric in this thread. We're only working on a 2,3-reduced-pitch-ratio popularity metric, which is the last point at which we have direct contact with the Scala archive stats. The next step will be to figure out how best to combine that with apotome slope and/or abs3exp to give a notational-comma popularity metric.
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: developing a notational comma popularity metric

Post by cmloegcmluin »

Dave Keenan wrote: Mon Jun 29, 2020 10:00 am Then I choose Data→Solver and ask it to minimise the pink cell by adjusting the two yellow cells, c and z.
This Solver is pretty powerful! It's pretty much what I debated implementing myself. Perhaps I should have trusted you and "read [your] spiel on how to make Excel's solver do a good approximation of minimax" earlier.
However, I think we should try to figure out why our different methods come up with such wildly different values for z. I suspect it's because my method effectively gives more weight to the ratios that have more votes.
What you're doing is my understanding of what Sheets should be doing under the hood when calculating its trendlines. But it's a black box so I can't tell you what it's doing. We'll just have to trust what you've got.
...But I also agree it would be simpler, and defensible, to use r = -1, in which case we don't need a variable for it.
Let's stick with z then.
Dave Keenan wrote: Mon Jun 29, 2020 10:12 am So strictly-speaking, we're not even working on a notational-comma popularity metric in this thread. We're only working on a 2,3-reduced-pitch-ratio popularity metric, which is the last point at which we have direct contact with the Scala archive stats. The next step will be to figure out how best to combine that with apotome slope and/or abs3exp to give a notational-comma popularity metric.
I agree.

I'd change the subject of the topic again, but something I've noticed is that it only updates the subjects for replies that occur after the topic subject change. One time I went back and manually updated all the reply subjects to match the new topic subject, but that was in a situation where there were only a few of them; with 6 pages of replies on this topic already, I'm not excited about that. So maybe we just keep the subject how it is.

Maybe we even want the discussion as we develop this notational-comma popularity metric to occur on this topic, in which case I shouldn't change the name.
User avatar
Dave Keenan
Site Admin
Posts: 2180
Joined: Tue Sep 01, 2015 2:59 pm
Location: Brisbane, Queensland, Australia
Contact:

Re: developing a notational comma popularity metric

Post by Dave Keenan »

cmloegcmluin wrote: Sun Jun 28, 2020 4:55 am Here’s something that’s been bugging me a bit: considering the handful of situations we know of with commas we are going to run this metric against, most those commas are “off the charts” in the sense that they have 0 votes. Is this metric really meaningful in the off-the-charts world? Do we feel like we’re truly tapping into the underlying forces that determine the precedence of notational commas, even extending into that uncharted territory? I would say hesitantly “yes” — otherwise I wouldn’t be here — but I wonder if anyone else has also doubted this.
Of course. But what alternative do we have?

But it's not like we're aliens from an other planet trying to figure out this model of human psychology, based purely on the Scala stats. We're also relying on the fact that we know human psychology "from the inside". i.e. we've at least played around listening to frequency ratios, and at least thought about designing musical scales, and musical works, that use them, and so we're trying to choose factors that are likely to be psychoacoustically salient for human composers, on which to base our metric.

That's one reason why you've convinced me that we need to include the prime-limit in this metric. And I agree we should call if gpf(). You said "gcp()" in one place. Was that an error?

And it's one reason why I am not yet convinced of the validity of sopf() or sopaf() in this metric, while I am convinced of the value of sopfr() or sopafr().

What is the argument for why a composer would prefer ratios with lower sopf, as opposed to merely lower sopfr?
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: developing a notational comma popularity metric

Post by cmloegcmluin »

Dave Keenan wrote: Mon Jun 29, 2020 10:39 am Of course. But what alternative do we have?
Fair enough. Makes me feel better to explicitly recognize all this though. Thank you.
Dave Keenan wrote: Mon Jun 29, 2020 10:39 am And I agree we should call if gpf(). You said "gcp()" in one place. Was that an error?
I did that in a couple places, so it was a bit more than a typo... the part of my brain that deals in three-letter-acronyms-starting-with-g subconsciously gravitates toward Google Cloud Platform, it would seem. I've corrected the errors. Thank you for pointing them out.
Dave Keenan wrote: Mon Jun 29, 2020 10:39 am What is the argument for why a composer would prefer ratios with lower sopf, as opposed to merely lower sopfr?
I agree the metric should with little contention represent things composers are likely to make their decisions on. For me, sopf seems pretty reasonable (as reasonable as π did, anyway), because many scales are based on just generators which are iterated repeatedly. Does it not seem reasonable to you that we should give ratios like 625/1 even the littlest bit of a pass for using only 5's? And wouldn't we want to punish e.g. 5.11/7.13 vs. 13.13/5.5?

I feel like sopfr, sopf, and gpf are each capturing a different aspect of the harmonic content which is important to capture: sopfr the overall harmonic content, sopf the variety of it, and gpf the extremeness of it. My stats vocab is lacking here; perhaps someone else knows better terms for these abstract aspects of data than "variety" and "extremeness".

That all said, I'm not precious about sopf just because I brought it up.
User avatar
Dave Keenan
Site Admin
Posts: 2180
Joined: Tue Sep 01, 2015 2:59 pm
Location: Brisbane, Queensland, Australia
Contact:

Re: developing a notational comma popularity metric

Post by Dave Keenan »

cmloegcmluin wrote: Mon Jun 29, 2020 10:36 am Maybe we even want the discussion as we develop this notational-comma popularity metric to occur on this topic, in which case I shouldn't change the name.
Good point. Yes, it seems like an obvious evolution of the discussion.

But we're certainly not ready for that yet, since I can't trust your optimisations.
volleo6144 wrote: Sun Jun 28, 2020 2:30 am I imagine that the way Excel's optimizer works is by nudging your starting number around to minimize a cost function or something (or it's something close to Newton's method, in which case you can't really use absolute values either), and I'm also pretty sure Excel doesn't have a function to sort things without using an actual sort command (like, a function that you can just put in a formula).
Yes, nudging your starting numbers (plural). The Excel solver does indeed do some kind of gradient-descent/Newton's-method but without needing algebraic derivatives. It must find the derivatives (i.e. gradients) numerically. But it does require that the function be continuously differentiable, which is why I can't use any absolute value functions, as you note.

It's up to you to set up the calculations for the cost function (typically you would use sum of squared errors). Ultimately you just tell it "minimise the value in this cell, by fiddling these other cells".

My version of Excel (2007) doesn't have sort() as a function, but I think recent versions do (taking and returning a matrix/array). But of course I still couldn't use it with the solver as it would be a discontinuous function and hence not continuously differentiable.

But my choice of (monotonic) function, to turn my candidate metric into an estimated rank, namely est_rank = brank, where 1 < b < 2, is almost certainly biasing the result (the optimal k and a) in some way, even though I include b among the "cells to be fiddled with".
User avatar
volleo6144
Posts: 81
Joined: Mon May 18, 2020 7:03 am
Location: Earth
Contact:

Re: developing a notational comma popularity metric

Post by volleo6144 »

Dave Keenan wrote: Mon Jun 29, 2020 10:12 am No, not a lot else. It's really just the 3-exponents. (for schismas and schisminas, apotome slope and abs3exp are essentially the same thing).
Yeah, pretty much. The definition of a comma's apotome slope is equivalent to "the comma's 3-exponent minus its size, where the size is measured in 7eda (~72edo) twelfthtones", and the s/k boundary is less than 0.3 steps of 7eda.
So strictly-speaking, we're not even working on a notational-comma popularity metric in this thread. We're only working on a 2,3-reduced-pitch-ratio popularity metric, which is the last point at which we have direct contact with the Scala archive stats. The next step will be to figure out how best to combine that with apotome slope and/or abs3exp to give a notational-comma popularity metric.
These two aren't really completely separate: I'm pretty sure some 2,3-reduced ratios are less popular than others because they don't really have that many full ratios that are that useful: 1:31 is useful as a 31:32 quartertone, while 1:29 ... doesn't exactly have anything like that going for it.
I'm in college (a CS major), but apparently there's still a decent amount of time to check this out. I wonder if the main page will ever have 59edo changed to green...
Post Reply