consistent Sagittal 37-Limit

[cmloegcmluin]

Thanks for digging it up, @Dave Keenan , and thanks for breaking it down, @volleo6144 !

I'll just go ahead and use this as the consolidated complexity metric we've been looking for to objectify the decisions we're trying to make about primary commas for the Insane precision level's symbols over on the Magrathean accents topic.

I'll give it a little time before I pull the trigger on unsplitting the 75th mina, eliminating the 47S from the Extreme precision level (on the JI precision level diagram, JI notation spreadsheet, etc.). Just in case anyone does think of any objections. But I think we've done about as much as we can reasonably expect ourselves to do at this point in order to find a good reason not to do so.

[cmloegcmluin]

I went back and added the column to the chart in my earlier post (here) showing which -- between the default and primary commas considered when developing the Extreme precision level -- had the lower SoPF>3. I suspect the 499S there is a typo because 499 is a relatively huge prime. Otherwise, as you can see all but the 69th mina worked out so that the primary comma had the lower SoPF>3, and there the default comma was 29 while the primary comma was 30 so it only beat it out by 1. So I guess that's another tiny argument in favor of 11:23S over 47S.

[volleo6144]

I suspect the 499S there is a typo because 499 is a relatively huge prime.

The 499S is a pretty simple ratio (499:512), and it is in the range of 91 minas (at 91.28 in 2460-EDO and 91.25 in 233-EDA), so if it is a typo, someone must have just went along with it. And this was in or before 2007, because there's a reference to it in a quote from 2007 here. (Edit now that N2D3P9 has been found: our N2D3P9 for "499" is 499/2 × 499/9 = 249001/18 = 13833.)

The 49S is also a particularly simple ratio (even simpler, at 48:49), but it's only 73 minas, and I can't think of any other ratios of 91 minas that could be confused with "499S"...

[Dave Keenan]

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) .