In the Sagittal-SMuFL-Map, we provide information about each sagittal's membership in different notations, and in the column for the Prime Factor notation, we do not report primes higher than 37. In this case, it is because:
- The Sagittal-SMuFL-Map concerns itself with font characters. A character may represent a sagittal or it may represent a diacritic, but not both; symbols which are combinations of sagittals and diacritics do not get their own font characters.
- 41 is the next prime after 37, and it is the first prime which requires a diacritic to distinguish it from a simpler prime (see here). In other words, it is the first Prime Factor notation symbol which does not consist only of a sagittal.
- Therefore, the ability to report membership in the Prime Factor notation in a table about characters breaks down past 37.
And a few posts later, 37 is also where he capped his enumeration of common combinations of primes a WinCompose sequence set could handle (see here).
Dave also gives 37 as the prime limit for his scraping of the Scala usage statistics (see here).
Dave also wrote me some time ago in an email that the extreme precision standard JI notation includes primes up to 37.
Given these few pieces of evidence, it feels like if we did want to propose a consistent prime limit for situations in Sagittal that may call for one, 37 would be our prime candidate (sorry, I had to do it). Any prime would be fairly arbitrary, but the fact that 41 needs a diacritic in Prime Factor notation is because it is the first one which is almost the same as an earlier prime (5), so that's a pretty good signal to cut ourselves off.
The reason I write all this today is because, as taken from the original JI Notation Spreadsheet that George produced (latest version of that document here), the extreme precision JI notation does actually include one prime above 37 (perhaps I misunderstood the point Dave was trying to make in that email). In fact, it skips right over 41 and 43, going straight to 47. It is the 47-small-diesis, represented by . So I was thinking that it might be preferable to set the default value of this symbol to a 37-limit comma instead, unless anyone knows a compelling reason for it to be so high limit.
As for suggestions, I'm sure I could come up with an algorithm for finding 37-limit commas between 36.326¢ and 36.588¢ and then choose one which is simple and ranks not too badly on the Scala usage statistics. However, I expect that Dave may already have such infrastructure for comma determination ready-to-go, if he agrees this is a worthwhile endeavor. I guess we could just sum the monzos of and and be done with it though.