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.
consistent Sagittal 37-Limit
- cmloegcmluin
- Site Admin
- Posts: 1516
- Joined: Tue Feb 11, 2020 3:10 pm
- Location: San Francisco, California, USA
- Real Name: Douglas Blumeyer
- Contact:
- cmloegcmluin
- Site Admin
- Posts: 1516
- Joined: Tue Feb 11, 2020 3:10 pm
- Location: San Francisco, California, USA
- Real Name: Douglas Blumeyer
- Contact:
Re: consistent Sagittal 37-Limit
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
- Posts: 66
- Joined: Mon May 18, 2020 7:03 am
- Location: Earth
- Contact:
Re: consistent Sagittal 37-Limit
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.)cmloegcmluin wrote: ↑Sat May 30, 2020 2:30 pm I suspect the 499S there is a typo because 499 is a relatively huge prime.
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"...
Last edited by volleo6144 on Sun Nov 01, 2020 1:49 am, edited 1 time in total.
A random guy who sometimes doodles about Sagittal and microtonal music in general in his free time.
- Dave Keenan
- Site Admin
- Posts: 1814
- Joined: Tue Sep 01, 2015 2:59 pm
- Location: Brisbane, Queensland, Australia
- Contact:
Re: consistent Sagittal 37-Limit
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.
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) .
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) .