I'm not here. But

@volleo6144 is right, that 499S is not a typo. Ratios of 499 weirdly occur a few times in the Scala archive. I think that George and I held on too long to the idea that we should give priority to commas that occur more often in the Scala archive. In hindsight, once you get beyond the 100-or-so most common 2,3-reduced ratios (maybe only the first 40-or-so) then the numbers of occurrences are so small as to be due to historical accidents that are unlikely to be predictive of future use.

Part of the reason we held on so long, is that in the early days, in order for the Sagittal idea to survive politically, we had to be seen to be basing the comma choices on something objective like the Scala archive stats, not some "arbitrary complexity function" that, it would be argued, merely suited our biases. The only reason SoPF>3 had

*any *respectability, at least in the minds of George and I, is that it gives a ranking that is similar to the Scala archive ranking, for those first 40-or-so 2,3-reduced ratios. And it is easy to calculate mentally.

But perhaps the time has come, to try to find a better complexity function for our purposes. One that matches the Scala archive stats even better, but filters out the historical noise. And it need not be easily mentally calculated. For starters, the weighting of each prime need not be the prime itself.

But more importantly, one area where SoPF>3 has always fallen down, is that it ignores the relative signs of the different prime exponents. e.g. it treats 5:7 as having the same rank as 1:35, and 5:11 the same as 1:55, and 7:11 same as 1:77, which they are not. The ratios where the primes are on opposite sides are more common.

Even more complicated: In order of decreasing frequency of occurrence, we have the ratios 11:35, 7:55. 5:77 and 1:385, which are all treated equally by SoPF>3.

I challenge readers to come up with a simple function that treats them differently, and whose coefficients can be fitted to the Scala stats. But beware

Von Neumann's elephant (second-last paragraph).

Compare:

viewtopic.php?p=259#p259
and

viewtopic.php?f=4&t=99#rank
Thanks

@volleo6144 for reverse-engineering George's "weighted complexity". It does seem to have some redundant multiple uses of the 3-exponent.

@cmloegcmluin, Thanks for the table. I've rearranged things a bit and included "other" as an option for the comma with the better SoPF>3 below. I also corrected the current sagittal for the 69th mina.

old old
# of default primary other current better
minas ratio ratio ratio Sagittal SoPF>3
----- ------- ------- ------- ------- -------
1 31:49n 455n primary primary
2 13:37n 65:77n primary primary
11 11:31k 605k default primary *
22 5:53k 5:161k 13:49k other other
31 5:47C 7:143C primary primary
42 19:73C 19:169C 253C other other
59 13:47C 605C 325C other other
66 53C 19:49C 11:91C other other
69 29S 13:17S default default
75 47S 11:23S both primary *
91 499S 17:49S primary primary
98 83M 5:187M 11:325M other primary *
108 7:29M 2375M 7:275M other other
110 47M 11:85M primary primary

This shows that George and I moved away from using Scala archive stats ("default") and towards a complexity measure that was dominated by SoPF>3, at least in deciding the primary commas for such unpopular minas as these.

* I find it conceivable that a better complexity measure than SoPF>3 could justify all the asterisked choices, except for the choice to retain 47S as an option in a split 75th mina. The splitting of the 75th mina is not justified by having two popular commas as options, nor is it justified by the DEfLL property (Drop Elements for Lower Level, previously DAFLL = Drop Accents For Lower Level) .