developing 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 »

Alright, I figured out how to get all the primes up to that size in the code. Here's my SoS(-1)-all's now:

sopfgtt	0.025688552370194503 (you had 0.025688583)
cwyks	0.009961246398661677
k	0.02029684279291744
j	0.02011979439894244
hyg	0.016264645830458384
wyb	0.012917909471059096
wyk	0.014789897590205842
wyks	0.01332132380834697
xwyks	0.012378411686737876
wb	0.015000562472113942
laj	0.01748753375123353
kl	0.017214288652642313
c	0.019656945407935004 (you had 0.019810858)
ak	0.016007748516318428
kj	0.01870946395615243
aux	0.015231920121779288
wab	0.015208328211588898
lak	0.016027176584402853
wbl1	0.010348665836817516 (you had 0.010794472)
wybl1	0.009077679300818776
wbl	0.009531497791251748 (you had 0.009854584)
wybl	0.008686329735371714
waybl	0.008102832492800228
wabl1	0.009313836409696243
wabl	0.009228303840092307

So it looks like we're essentially in agreement now.
Dave Keenan wrote: Thu Aug 13, 2020 9:11 am But I do have a problem in that I'm only extracting prime factors up to 97, and then assuming that what's left over is a single prime number.
So — while of course I recognize that you had it essentially correct from the beginning, and that you caught the issue and pressed us to get this bit right — perhaps we should lean on my code for our final more accurate figures then?
Last edited by Dave Keenan on Thu Aug 13, 2020 4:50 pm, edited 1 time in total.
Reason: Vertically-aligned the SoS values so I could compare them
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 »

[Edit: Once again, I did not see the (2 messages!) above until after I posted the below.]
cmloegcmluin wrote: Thu Aug 13, 2020 10:52 am
Dave Keenan wrote: Thu Aug 13, 2020 9:11 am
cmloegcmluin wrote: Thu Aug 13, 2020 2:32 am Re: my request to keep the first proposed "wbl" as such and call the new, "true" wbl "wbll": I realized that by the same naming logic we'd need to go back and rename cwyks and cwyk to ccwyks and ccwyk, respectively, since they both use a coefficient on the copfr. I dunno how you feel about that.
Crazy idea. ...
...
Anyway, but I have been spending my free minutes today investigating metrics for which it's important to distinguish between c and cc in this way, so I might be worried about it myself. Sorry if it seems crazy.
What seemed crazy to me was not that you would want to distinguish them, but that you would want to go back and rename existing metrics in this way, rather than coming up with new names for the new metrics.

I assume that having accepted my l1 proposal, you will now leave the existing "c" names to live out their remaining few days undisturbed, and will use c1 for a constant unity copfar coefficient, if these prove to be of any interest.
I wouldn't want one letter to be used for gpf and another letter to be used for lb(gpf).
Why isn't it at as important to distinguish gpf from lb(gpf) as it is to distinguish constant non-zero l and c from parameter l and c?
I am finding that sometimes metrics do want combinations of lb and non-lb submetrics, despite them being "incommensurate", and in these cases I am not sure how to account for that in the name. But I'd prefer if it was some other way than having a different letter for a property (presence of gpf at all) which is orthogonal.
We don't have to design the ultimate metric naming scheme here. What other submetric do you think we might have lb and non-lb versions of, on the shortlist?
I'm chuckling to myself that I'm agreeing to something which has a lower case l followed by a 1 as a good name for anything, but yes, I think that's a good idea and maybe the best :)
Yes, using "l" (lowercase-L) at all, was the original sin. But not everything worth doing is worth doing well. Some things it is just better to do quickly. :)
What SoS do you get for wbl1 for the first 383 ratios? I get 0.008583853. I'm using the parameter values given here:
viewtopic.php?p=2193#p2193
No, I get 0.008107801. It's closer, at least! This is the same one for which you said "For wbl I get 0.010794472 where you get 0.1323321."
Yeah. Down from a factor-of-13 error to a 7% error, by omitting the last 437 ratios, most of which have a count of 1. That has to be a big clue. There has to be a bug in your code, or your database.

You're effectively claiming that the z=-1 SoS of the last 437 ratios is 0.1323321 - 0.008107801 = 0.124224299. That's an average squared error in the reciprocal rank of 0.124224299 / 437 = 0.000284266. That's an average error in the reciprocal rank of √0.000284266 = 0.016860194. Given that most of them have a reciprocal rank of 1/604.5 = 0.00165426, the typical reciprocal rank given by the metric would have to be 0.00165426 + 0.016860194 = 0.018514454. So the typical rank given by the metric would have to be 1/0.018514454 ≈ 54. That's just not possible as a typical model-given rank for the last 437 ratios.

The average wbl1 rank I have for the last 437 ratios is 533.
I do have 329 for all those with 2 votes, but I have 604.5 for those with 1 vote. I confirm that I have exactly 820 ratios.

In your fractional ranks, do you have any 0.5's, or have you been rounding them? As an experiment I rounded all mine up but I still don't match your values.
Yes. I have plenty ending in 0.5. It should end in .5 whenever there is an even number of ratios with the same count, and end in .0 when there is an odd number. I checked how many there are with a count of 1 and found it to be even, so the rank should indeed end in .5. Then I realised the problem was that I made the rank column too narrow, so Excel was rounding it for display (but not for calculation). Mine are really 604.5, same as yours. Sorry. So that's no explanation for any difference.
The z=-1 helps to take the edge off the pain in this vicinity, at least.
It's apparently not taking enough of the edge off the pain in your case.
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 »

I hereby declare the winner to be ....

some metric in the wbl family.
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: Thu Aug 13, 2020 10:52 am I was surprised to find that copfr and wb are not friends! copfr does not seem to ever significantly improve wb (nor does coapfr, ap = lb(p)), and when using c*copfr it always sends c to 0. Curious if you find otherwise.
Doesn't surprise me at all. w and b are equivalent to c (or whatever two variable names would be used as coefficients for copfr(n) and copfr(d) ). But before I explain, I must point out that the concept of a "coapfr" (count of altered prime factors with repeats) is meaningless. The values of the primes themselves do not enter into copfr, so it doesn't make any difference how you alter the primes, the result will be the same.

In fact copfr(r) is just a shorthand for a soapfr(r), where ap = 1. And so a soapfr(r), where ap = w, is the same as w × copfr(r). And a soapfr(r) with ap = w + lb(p) is the same as w × copfr(r) + soapfr(r), where ap = lb(p), which is the same as w × copfr + lb(r).

So wbl1(r) = soapfr(n) + sompfr(d) + lb(gpf(n×d)), where ap = lb(p)+w, mp = lb(p)+b
can be written as

lb(n×d) + w × copfr(n) + b × copfr(d) + lb(gpf(n×d))

= lb(n×d×gpf(n×d)) + w × copfr(n) + b × copfr(d)

= lb(n×d×gpf(n×d)) + lb(2w ^ copfr(n)) + lb(2b ^ copfr(d))

= lb(n × d × gpf(n×d) × 2w ^ copfr(n) × 2b ^ copfr(d))

And because lb is an increasing monotonic function, it can be dropped, to give another metric that will give exactly the same ranking, and hence SoS. I dunno how we'd name it.

n × d × gpf(n×d) × Wcopfr(n) × Bcopfr(d), where W = 2w, B = 2b

Perhaps it can be called WBL1, pronounced "big wobble one".

So there's a way to name lb and non-lb versions of a parameter — i.e. lowercase versus uppercase.

But it might be easier to calculate (maybe even mentally) as

n × d × gpf(n×d) × 2w×copfr(n)+b×copfr(d)

I put the above into a spreadsheet and confirmed that it gave exactly the same SoS's as wbl1.

I think that's the winning metric. What a team!
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 »

Here's another transformation of
wbl1(r) = soapfr(n) + sompfr(d) + lb(gpf(n×d)), where ap = lb(p)+w, mp = lb(p)+b

ap = lb(p) + w
= lb(p) + lb(W), where W = 2w
=lb(p×W)

mp = lb(p×B), where B = 2b

w = -0.944786888
so W = 0.519506287

b = -1.561335378
so B = 0.338837304

It does little damage to round these to
w = -1
so W = 1/2

b = lb(1/3) = -1.584962501
so B = 1/3

so ap = lb(p/2), mp = lb(p/3).

And here's yet another transformation, using the same rounding. This is the best version I can find for ease of describing and remembering.

n × d × gpf(n×d)
2copfr(n) × 3copfr(d)

So what do we call this. I'm not talking about naming it in a scheme that has to distinguish it from all those other metrics. They are now dead (but feel free to argue otherwise). We just want a name that has some mnemonic value, to recall this equation.

BTW, If you take the value of this metric (the "antivotes") and divide them by 9, you get the approximate rank.

So rank ≈
n × d × gpf(n×d)
2copfr(n) × 3copfr(d)+2
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: Thu Aug 13, 2020 4:22 pm [Edit: Once again, I did not see the (2 messages!) above until after I posted the below.]
No worries. I saw it right before I went to bed. I figured you'd see my recent posts soon enough. Probably we should be on one of these international messaging services (oh wait we are — Facebook — only problem is I almost never use it!) so we can ping each other if we've got pressing updates but just need a little while to articulate it. Sorry that I didn't intercept you before you did all that analysis of the bug in my code. And uh, also, it doesn't look like I actually apologized for wasting our time with the bug in the first place, so — sorry for that too!
What seemed crazy to me was not that you would want to distinguish them, but that you would want to go back and rename existing metrics in this way, rather than coming up with new names for the new metrics.

I assume that having accepted my l1 proposal, you will now leave the existing "c" names to live out their remaining few days undisturbed, and will use c1 for a constant unity copfar coefficient, if these prove to be of any interest.
Yep, leaving them alone.
I wouldn't want one letter to be used for gpf and another letter to be used for lb(gpf).
Why isn't it at as important to distinguish gpf from lb(gpf) as it is to distinguish constant non-zero l and c from parameter l and c?
Sorry, I meant it was important, but I wouldn't want to do it with two different letters. I would prefer to add another letter or something.
I am finding that sometimes metrics do want combinations of lb and non-lb submetrics, despite them being "incommensurate", and in these cases I am not sure how to account for that in the name. But I'd prefer if it was some other way than having a different letter for a property (presence of gpf at all) which is orthogonal.
We don't have to design the ultimate metric naming scheme here. What other submetric do you think we might have lb and non-lb versions of, on the shortlist?
Potentially none so let's not worry about it.
I'm chuckling to myself that I'm agreeing to something which has a lower case l followed by a 1 as a good name for anything, but yes, I think that's a good idea and maybe the best :)
Yes, using "l" (lowercase-L) at all, was the original sin. But not everything worth doing is worth doing well. Some things it is just better to do quickly. :)
For better or worse, the "l" was my doing. And again, agreed on the quicknessnessness.
Dave Keenan wrote: Thu Aug 13, 2020 5:21 pm I hereby declare the winner to be ....

some metric in the wbl family.
I concur!
Dave Keenan wrote: Thu Aug 13, 2020 7:05 pm
cmloegcmluin wrote: Thu Aug 13, 2020 10:52 am I was surprised to find that copfr and wb are not friends! copfr does not seem to ever significantly improve wb (nor does coapfr, ap = lb(p)), and when using c*copfr it always sends c to 0. Curious if you find otherwise.
Doesn't surprise me at all. w and b are equivalent to c (or whatever two variable names would be used as coefficients for copfr(n) and copfr(d) ).
Oh right. I think you explained this before.
But before I explain, I must point out that the concept of a "coapfr" (count of altered prime factors with repeats) is meaningless. The values of the primes themselves do not enter into copfr, so it doesn't make any difference how you alter the primes, the result will be the same.
True, true.
In fact copfr(r) is just a shorthand for a soapfr(r), where ap = 1. And so a soapfr(r), where ap = w, is the same as w × copfr(r). And a soapfr(r) with ap = w + lb(p) is the same as w × copfr(r) + soapfr(r), where ap = lb(p), which is the same as w × copfr + lb(r).

So wbl1(r) = soapfr(n) + sompfr(d) + lb(gpf(n×d)), where ap = lb(p)+w, mp = lb(p)+b
can be written as

lb(n×d) + w × copfr(n) + b × copfr(d) + lb(gpf(n×d))

= lb(n×d×gpf(n×d)) + w × copfr(n) + b × copfr(d)

= lb(n×d×gpf(n×d)) + lb(2w ^ copfr(n)) + lb(2b ^ copfr(d))

= lb(n × d × gpf(n×d) × 2w ^ copfr(n) × 2b ^ copfr(d))

And because lb is an increasing monotonic function, it can be dropped, to give another metric that will give exactly the same ranking, and hence SoS. I dunno how we'd name it.

n × d × gpf(n×d) × Wcopfr(n) × Bcopfr(d), where W = 2w, B = 2b

Perhaps it can be called WBL1, pronounced "big wobble one".
So cool!
So there's a way to name lb and non-lb versions of a parameter — i.e. lowercase versus uppercase.
I think this is lb vs non-lb on a different order than I was referring to. But that's no matter. I like uppercasing to distinguish them.
But it might be easier to calculate (maybe even mentally) as

n × d × gpf(n×d) × 2w×copfr(n)+b×copfr(d)

I put the above into a spreadsheet and confirmed that it gave exactly the same SoS's as wbl1.

I think that's the winning metric. What a team!
Woohoo!

▶️ ⏹️ ,  s
Dave Keenan wrote: Thu Aug 13, 2020 9:42 pm Here's another transformation of
wbl1(r) = soapfr(n) + sompfr(d) + lb(gpf(n×d)), where ap = lb(p)+w, mp = lb(p)+b

ap = lb(p) + w
= lb(p) + lb(W), where W = 2w
=lb(p×W)

mp = lb(p×B), where B = 2b

w = -0.944786888
so W = 0.519506287

b = -1.561335378
so B = 0.338837304
I'd thought about doing this at the time we found wbl, but forgot to follow through. Yes, I like where this is going.
It does little damage to round these to
w = -1
so W = 1/2

b = lb(1/3) = -1.584962501
so B = 1/3
That's awesome! I was hoping they'd work out to something nice and round. How little damage is it? Actually I don't really care. Let's not grip this Scala data with white knuckles. Some better data might come along later, and whole 2's or 3's in our equation will age a lot more nicely.
so ap = lb(p/2), mp = lb(p/3).

And here's yet another transformation, using the same rounding. This is the best version I can find for ease of describing and remembering.

n × d × gpf(n×d)
2copfr(n) × 3copfr(d)

So what do we call this. I'm not talking about naming it in a scheme that has to distinguish it from all those other metrics. They are now dead (but feel free to argue otherwise). We just want a name that has some mnemonic value, to recall this equation.
Well, maybe the other metrics like kj and wyk and such are not totally dead, but of little interest now. I think many of them would not be able to undergo this lovely of a transformation.

So I don't think we have to spell it WBL-1, but I do like the word "wobble". I like the idea of an unpopular ratio feeling really "wobbly". I don't see any previous meaning of wobble in math or music theory. How do you feel about "taking the wobble" of a ratio? This ratio has a "wobble of about 30"?

Or, if you were looking for something whose name was actually tied to the original mission, to the application of this metric rather than an amusing artifact of its development process, perhaps we could call it "unpop", short for unpopularity? It's got a bit of internal rhyme with "copfr" too which might help remember it.
BTW, If you take the value of this metric (the "antivotes") and divide them by 9, you get the approximate rank.

So rank ≈
n × d × gpf(n×d)
2copfr(n) × 3copfr(d)+2
That's nice to have. But most of the time when we or others use this metric they won't be comparing results with the Scala stats used to develop the metric, e.g. when we use this on our tina candidates, I think we'll do just as well with the bigger "wobble" or "unpop" values as we would with (approximate) ranks.
Attachments
secret-discovery-sound.mid
(140 Bytes) Downloaded 157 times
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 note that n × d is the Benedetti height, familiar to many xenharmonicists, and I find it tokenized as "BH" here. And gpf(n×d) may be more familiar as the prime limit. Re: copfr, I must remind us that this acronym is not established (a web search for "copfr prime" turns up this forum topic as the first hit) and that the name for this function in mathematics is the prime omega function, specifically big omega since it includes repetitions (little omega does not); I don't expect xenharmonicists to be familiar with this one necessarily, but we could at least then fall back on the mathematical literature. So perhaps we should write the metric:

$$ \frac{\text{BH}(r)\text{p-limit}(r)}{2^{Ω(n)}3^{Ω(d)}}, \text{where } r = \frac{n}{d} \text{ is 5-rough} $$
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 »

It's disappointing that while this metric distinguishes 35/1 from 7/5, and distinguishes 55/1 from 11/5, and 77/1 from 11/7, it does not distinguish 77/5 from 55/7 or 35/11.

Rounding W and B to 1/2 and 1/3 increases the SoS over all ratios from 0.010786256 to 0.011129715. These are approximate values due to my way of dealing with primes above 97, but that's only a 3% increase. It increases the SoS over the first 80 ratios from 0.003886596 to 0.004205825 (an 8% increase).

I don't like "wobble" at all, because it tells the first-time reader (or hearer) absolutely nothing useful about the mathematical nature of the function, or its purpose. "unpop" is slightly better. But it's a specifically notational kind of unpopularity. Hence first removing factors of 2 and 3, which we've been able to assume throughout this thread, but needs to go back into any exposition for the wider world (as you've done above), and may influence the name.

"Benedetti height" is a ridiculously-obscure name for something that can be (and often has been) completely described with only one more syllable, as "product complexity". And for goodness sake, why write "BH(n/d)" for what can be written as "n·d", and then have to explain what BH is?

Thanks for reminding me that "copfr" is a (very sensible) name of our own making. Again, "big omega" tells a first-hearer nothing. It has zero mnemonic value relative to any of its many other uses. But we should mention it in passing, in any exposition on this metric, as we should mention "gpf" as an alternative to "prime-limit".

I'm not sure I've finished with potentially-more-memorable transformations of this metric, so it might be a bit premature to name it. But I'm hoping we can come up with an acronym or abbreviation based on its components, possibly including product-complexity and prime-limit.
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: Fri Aug 14, 2020 10:01 am It's disappointing that while this metric distinguishes 35/1 from 7/5, and distinguishes 55/1 from 11/5, and 77/1 from 11/7, it does not distinguish 77/5 from 55/7 or 35/11.
Which have 55, 61, and 92 votes, respectively. Yeah, that is a bummer, huh?

Ooh, well this is interesting... I almost can't believe that with w and b set to such weird numbers as -0.944786887715889 and -1.561335378 that these three ratios can come out with identical antivotes, so I looked them up in my detailed logs, and actually I rank them differently... but not for a good reason. 35/11 gets rank 37 with 8.597237100787783 antivotes; 55/7 and 77/5 get rank 38.5, being tied with 8.597237100787785. Yup: that's one of them famous JavaScript floating point arithmetic discrepancies.

Fun factlet: I actually had to revise one of my tests yesterday to verify values with significantly less precision, because a SoS calculation started failing on CI even though it was passing locally. I was able to reproduce the failure on my work laptop, which shares Linux architecture with the container the tests are running on in my free CI solution. So it's that finicky!

Anyway, probably what I should do is stop dealing with antivote values with any greater precision than the billionths with which we've been exchanging final SoS values. This will apparently make the difference between values tying or not, which as we've already seen, particularly on a large scale, can have nontrivial impacts on the final SoS.

You're kidding yourself if you think I'm going to wait for my scripts to re-run for days to get slightly fixed values, though :P I can at least get them for our selected contenders though.

All that's cool and all, but it doesn't address the main issue which is the failure of WBL-1 to differentiate between 77/5, 55/7, and 35/11. Though I note that this differentiation was not among those enumerated by myself a couple days ago. It's similar to the fourth task, balance, except it's not "prime balance", but just plain old "balance", and thus it would be the only one of the five tasks which is not with respect to primes (i.e. it would be "prime repetitions", "prime content", "prime limit", "prime balance", "balance") but simplify magnitude of the numbers in the numerator and denominator. That makes me a tiny bit suspicious of it. But let's see if it holds for any other permutations of 3 primes:

35/13: 25 votes
65/7: 11 votes
91/5: 11 votes

55/13: 4 votes
65/11: 6 votes
143/5: 13 votes

77/13: 8 votes
95/11: 1 votes
143/7: 9 votes

I'm not seeing enough of a pattern to think this is something our metric must capture. What do you think?
Rounding W and B to 1/2 and 1/3 increases the SoS over all ratios from 0.010786256 to 0.011129715. These are approximate values due to my way of dealing with primes above 97, but that's a 3% increase. It increases the SoS over the first 80 ratios from 0.003886596 to 0.004205825 (an 8% increase).
Okay, my code is set up to verify that, as long as I can figure out what the equivalent w and b values would be for those W and B... seems like this should be easy enough... just reverse engineer your transformations... Right okay, so if W = 2w and B = 2b, then I just need to take lb of each to get back. And if W = 1/2 and B = 1/3, then w = -1 and b = -1.58496250072, which is indeed extremely close to their original values of -0.944786887715889 and -1.561335378, respectively. I confirm this gives SoS(-1) of 0.00420582488763467, SoS(-1)-all of 0.010749073335214025 (well that one's actually even lower than your non-rounded SoS(-1)-all... but we've implicitly established that your tool will struggle with SoS(-1)-all), and SoS(1) of 12566.5.
I don't like "wobble" at all, because it tells the first-time reader (or hearer) absolutely nothing useful about the mathematical nature of the function, or its purpose. "unpop" is slightly better.
I agree with not liking wobble for that reason. Okay, let's strike it from consideration.

Yeah, "unpopularity" appears to be an actual word, but it just sounds wrong to me for some reason. It's a mouthful in any case.

Alright, we'll keep thinking on it, then.

Oh — so have you for certain decided that even though wybl beat wbl on SoS(-1), wbl beat wybl on SoS(1) by enough that it's better? I'm just a bit surprised by how much you seem to care about SoS(1) now, when everything I'd spent days running scripts for was to desperately minimize SoS(-1) (why wasn't I running that script for 3 days on SoS(1) and then in the end checking on SoS(-1) to see how that looked? Why was it this way and not the other?)
"Bennedetti height" is a ridiculously-obscure name for something that can be (and often has been) completely described in the same number of syllables, as "product complexity". And for goodness sake, why write "BH(n/d)" for what can be written as "n·d", and then have to explain what BH is?
Ah ok. I'd never heard the phrase product complexity before (and web searches don't readily turn up evidence of it being an accepted or popular mathematic term). From an anecdotal standpoint, Bennedetti height seems to come up all the time when I find myself in discussions of xenharmonics (and not always brought up by myself). Those things both said, if you do not think the appeal to xenharmonicists of seeing BH in our metric will be worth the cost of some people potentially not knowing or caring about it, then I am certainly fine sticking with n·d.
Thanks for reminding me that "copfr" is a (very sensible) name of our own making. Again, "big omega" tells you nothing. It has zero mnemonic value relative to any of its many other uses. But we should mention it in passing, in any exposition on this metric, as we should mention "gpf" as an alternative to "prime-limit".
Yeah, speaking of exposition, who's writing our findings up for Xenharmonikôn?! :)

I thought of asking that earlier, but I wasn't sure you'd think there'd be wider interest in what is essentially an inner mechanic to Sagittal.
I'm not sure I've finished with potentially-more-memorable transformations of this metric, so it might be a bit premature to name it. But I'm hoping we can come up with an acronym or abbreviation based on its components, possibly including product-complexity and prime-limit.
I hope so too. Perhaps my list of 4 (or 3, or 5) tasks our metric has could be a source of inspiration, too. "Simplicity" and "complexity" are another pair of words which have come up when talking about the purpose of this metric. Interestingly, the word "prime" itself contains an essence of fundamentality, simplicity, or importance. How about "primacy"? We could take the "primacy" of a ratio? A problem is that this metric gives bigger numbers for the opposite thing. So it could be ratio obscurity. I kind of like that.
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: Fri Aug 14, 2020 1:30 am
Dave Keenan wrote: Thu Aug 13, 2020 4:22 pm BTW, If you take the value of this metric (the "antivotes") and divide them by 9, you get the approximate rank.

So rank ≈
n × d × gpf(n×d)
2copfr(n) × 3copfr(d)+2
That's nice to have. But most of the time when we or others use this metric they won't be comparing results with the Scala stats used to develop the metric, e.g. when we use this on our tina candidates, I think we'll do just as well with the bigger "wobble" or "unpop" values as we would with (approximate) ranks.
Our metric implies a ranking that is independent of the Scala archive, which is a ranking of all possible 5-rough ratios, whether they occurred in the archive or not. The above formula is an approximation of that ranking, not the ranking of the ratios that just happen to be included in the Scala archive.

The archive probably contains the complete set of ratios up to some maximum value of our metric, but becomes increasing sparse after that.

I fact, if we used the above as our metric, we would be justified in calling it "notational popularity rank", since fractional ranks are not unheard of. Or at least calling it "a" notational popularity rank, since I'm pretty sure I've referred to the old sopfr (SOPF>3) as "notational popularity rank" in the past.
Post Reply