## consistent Sagittal 37-Limit

cmloegcmluin
Site Admin
Posts: 799
Joined: Tue Feb 11, 2020 3:10 pm
Location: San Francisco, California, USA
Real Name: Douglas Blumeyer
Contact:

### Re: consistent Sagittal 37-Limit

I feel like a recap of this thread might be handy, because I feel like we're a few layers deep into dependencies, and I keep having to remind myself what in the world is happening.

TL;DR:
Layer A: find new comma to make 37-limit
Layer B, v1: resolve overlapping commas between and .: by shifting their boundary
Layer C, v1: resolve overlapping commas between and .: by invalidating one or the other
Layer B (and C), v2: resolve overlapping commas in 12 different places, potentially requiring invalidating some symbols — or decide that OoBSoE exceptions are not critical

1. I propose we compress the Extreme Precision JI notation into the 37 limit, out of consistency with other meaningful instances of 37-limit throughout Sagittal, and also because there is only a single symbol beyond 37-limit which is flagrantly exceptional, skipping right over 41 and 43 right to 47. That symbol is , the 75th mina, the 47S. @Dave Keenan agrees this is worth looking into. So we begin searching for alternative commas for this symbol — a 37-limit comma inside that symbol's capture zone, 36.326¢ to 36.588¢. Let's call this Layer A.
2. @herman.miller finds a comma suitable by this criteria, but Dave points out that it wouldn't be common enough per the Scala usage stats. I find a comma which seems to be a good candidate: ~36.529¢ = [ 1 -4 1 1 -1 1 > = 910/891, AKA the 455/11C. However Dave points out that this comma is a sum-of-subsets for a different symbol, the next one over,  , the 75.489th mina, the 11:23S, with a capture zone from 36.588¢ to 36.888¢. He suggests this means that the boundary between these two commas needs to be shifted. In doing so, we implicitly commit ourselves to experimentally ensuring that symbols' sum-of-subsets are inside their bounds. At this point I, at least, have not become precise enough in my apprehension of the problem, and am not making distinctions between different types of SoS and different types of bounds. I agree with this boundary move, but do not immediately attack the issue. Let's call this Layer B.
3. Instead, Dave and I remain focused on Layer A, the problem of choosing a replacement 37-limit comma for . He asks for an exhaustive list of SoS commas for this symbol, including variations using the secondary commas for the elements. Instead of doing the work to fully understand and follow this approach he's suggested, I keep using my own script. Still, no one has gotten this list to Dave. Dave is nice anyway and calls my list "Cool list." The actual choosing of the comma gets paused, though, because...
4. On Layer B, I discover a second boundary that would need shifting (I won't reproduce it here since it's tangential because this was later proven wrong), as well as an issue with our ability to move the boundary between and .: : there is no good place to move it, because there is a comma which is a SoS for both of and .: . I propose this means that one or the other of the symbols should be invalidated, and suggest replacing with . Let's call this Layer C.
5. Dave drops bombs of huge emails and spreadsheets. I by no means comprehensively ingest them, but focusing on the most obviously relevant bits, I retract my proposal to replace with since I've just learned it would constitute a DAFLL exception, and exchange it for a proposal to eliminate the splitting of the 75th mina by shifting over the boundary at the Very High precision level, for which I recognize that allowing the higher complexity stuff to impact the simpler stuff is generally a no-no, so I'm not super stoked about this proposal either.
6. Dave and I get in a bit of cross-talk, since he's still apparently working on Layer A, since no one has assisted him with that yet; he's still asking about the secondary commas for the mina accents. I'm thinking he's on Layer C with me, dealing with the issue of the mutually invalid symbols, so my response to him is probably a bit confusing and off. Nonetheless, something that Dave says helps me realize that not only do we have sum-of-elements but that each symbol can have up to very many different sum-of-subsets depending on how you slice and dice it. I also realize that I've been using the wrong slicing-and-dicing. So I redo my work. That involves striking out the original Layer B and Layer C since they were based on incorrect work. I instead discover that we've actually got a much worse problem, if we indeed want to respect these OoBSoE errors: there are 12 exceptions. Let's call this Layer B (and C), v2, since we're not sure if any of these 12 will lead to an equivalent of Layer C (SoE being the same for multiple symbols) until more analysis is done.
I do still owe @Dave Keenan a response on Layer A, of course. I will do that in my next post. Layer A does not depend on Layer B (or C) so we can very well continue on that layer while simmering on Layer B (or C) if we want.

cmloegcmluin
Site Admin
Posts: 799
Joined: Tue Feb 11, 2020 3:10 pm
Location: San Francisco, California, USA
Real Name: Douglas Blumeyer
Contact:

### Re: consistent Sagittal 37-Limit

Dave Keenan wrote:
Fri May 15, 2020 2:18 pm
In the above sum-of-subsets, we should also consider the common secondary commas for and  .

I'm pretty sure they exist — one for each diacritic — but I can't readily find what they are.

They can be found by subtraction. i.e. take the primary comma for a symbol with a mina diacritic, and subtract the primary comma the same symbol with the mina diacritic removed, and see if you get something other than 455n or 65:77n.
This came up between Dave and me previously in a private correspondence:
cmloegcmluin wrote:
Sat Mar 21, 2020 12:12 pm
Working through the pitches provided for the standard Olympian JI Notation in the JI Notation Spreadsheet, I observe that indeed the mina takes these forms.
• It is used in its primary role when making the 91-schisma from the 5-schisma.
• It is used in its secondary role when making the 19:4375s from the 19s.
• It is even used in a tertiary role when making the 49:55s from the 19s (3135:3136).
• There may be even more roles, since that's still less than 4 cents of the way along.
In the time since then, at one point I did go ahead and every value that and  could be said to take when subtracting the rest of the symbol out from the Extreme Precision (Olympian) JI notation. Here those all are. There are actually 25 different values for and 13 different values for :

Mina	Value																				count	Symbols Used
¢	Ratio				Prime Exponent Vector
Numerator	Denominator	2	3	5	7	11	13	17	19	23	29	31	37	41	43	47
0.223	192937984	192913083	23	13	0	0	2	0	0	0	-1	0	0	0	0	0	0	1	,.(|(
	0.280	6175		6174		-1	-2	2	-3	0	1	0	1	0	0	0	0	0	0	0	1	,'(|
0.297	5832		5831		3	-6	0	-3	0	0	-1	0	0	0	0	0	0	0	0	2	,~|	,)/|\
	0.310	115343360	115322697	21	-12	1	-1	1	0	0	0	0	0	-1	0	0	0	0	1	,|(
0.363	61965		61952		-9	6	1	0	-2	0	1	0	0	0	0	0	0	0	0	5	,(|(	,(|)	,'(|)	./|\	/|\
	0.396	4375		4374		-1	7	4	1	0	0	0	0	0	0	0	0	0	0	0	12	,)|	,'|(	,.(|\	,(|\	/|	'/|	|)	'|)	.//|	//|	/|)	'/|)
0.400	24117248	24111675	20	-9	-2	-2	0	0	0	0	1	0	0	0	0	0	0	1	,|~
	0.423	4096		4095		12	-2	-1	-1	0	-1	0	0	0	0	0	0	0	0	0	21	|	'|	|\	(|(	)//|	'/|\	|\)	.(|\	(|\	,./|	,/|	,.|)	,|)	,'|)	,.//|	,//|	,/|)	,'/|)	,(/|	,.(|)	,)|\\
	0.436	3969		3968		-7	4	0	2	0	0	0	0	0	0	-1	0	0	0	0	4	,~|)	,|\)	~~|	(/|
0.445	3888		3887		4	5	0	0	0	-2	0	0	-1	0	0	0	0	0	0	1	|~
0.466	152361		152320		-8	6	-1	-1	1	0	-1	1	0	0	0	0	0	0	0	1	,)|)
	0.469	2342912		2342277		14	-9	0	-1	1	1	-1	0	0	0	0	0	0	0	0	2	~|(	(|
0.492	3520		3519		6	-2	1	0	1	0	-1	0	-1	0	0	0	0	0	0	1	.~|(
0.506	117440512	117406179	24	-6	0	1	-5	0	0	0	0	0	0	0	0	0	0	1	,)|(
	0.522	5907360375	5905580032	-29	9	3	4	-1	0	0	0	0	0	0	0	0	0	0	1	,')|(
0.526	352107		352000		-8	7	-3	1	-1	0	0	0	1	0	0	0	0	0	0	1	,(|
	0.540	1003833		1003520		-12	10	-1	-2	0	0	1	0	0	0	0	0	0	0	0	2	~|)	,~|(
	0.543	226304		226233		10	-5	0	-2	0	1	1	-1	0	0	0	0	0	0	0	1	,'//|
0.552	3136		3135		6	-1	-1	2	-1	0	0	-1	0	0	0	0	0	0	0	1	)|
0.572	3025		3024		-4	-3	2	-1	2	0	0	0	0	0	0	0	0	0	0	3	,/|\	)|(	(|)
	0.592	2926		2925		1	-2	-2	1	1	-1	0	1	0	0	0	0	0	0	0	1	'//|
	0.606	20007		20000		-5	4	-4	0	0	1	0	1	0	0	0	0	0	0	0	1	,)/|
0.609	22151168	22143375	17	-11	-3	0	0	2	0	0	0	0	0	0	0	0	0	2	)|\\	,)//|
0.698	4296700485	4294967296	-32	13	1	2	1	0	0	0	0	0	0	0	0	0	0	1	.|)
0.721	2401		2400		-5	-1	-2	4	0	0	0	0	0	0	0	0	0	0	0	2	|(	)/|\
	0.752	2304		2303		8	2	0	-2	0	0	0	0	0	0	0	0	0	0	-1	1	~|)
	0.796	301465600	301327047	-19	16	-2	1	0	0	0	0	-1	0	0	0	0	0	0	1	,,|~
	0.818	256000		255879		11	-9	3	0	0	-1	0	0	0	0	0	0	0	0	0	2	/|	//|
	0.829	10097379	10092544	17	-12	0	1	1	0	0	-1	0	0	0	0	0	0	0	1	,,)/|
	0.833	2080		2079		5	-3	1	-1	-1	1	0	0	0	0	0	0	0	0	0	6	,,|(	,,|)	,,(|(	,,/|)	|	(|\
	0.936	57375		57344		13	-3	-3	1	0	0	-1	0	0	0	0	0	0	0	0	1	,,~|(
	0.958	1949696		1948617		14	-11	0	1	-1	0	1	0	0	0	0	0	0	0	0	1	~~|
	1.018	1701		1700		-2	5	-2	1	0	0	-1	0	0	0	0	0	0	0	0	2	)/|\	,,//|
	1.040	1665		1664		-7	2	1	0	0	-1	0	0	0	0	0	1	0	0	0	2	)//|	,,)|\\
	1.099	20493		20480		-12	4	-1	0	1	0	0	0	1	0	0	0	0	0	0	3	,,/|	,,/|\	(|)
	1.121	13640319	13631488	-20	11	0	1	1	-1	0	0	0	0	0	0	0	0	0	2	)|(	|)
	1.125	1540		1539		2	-4	1	1	1	0	0	-1	0	0	0	0	0	0	0	1	)|
	1.135	382976		382725		11	-7	-2	-1	1	0	1	0	0	0	0	0	0	0	0	1	(|		

I note that the and come perilously close to crossing into each other's territory: the highest value represents is 0.7211972814¢ while the lowest value that represents is 0.7515667794¢.

I will use these when finding the list of possible new commas for that Dave asked for, including the sum-of-subset for every possible subset, crossed with every possible secondary value of the minas.

cmloegcmluin
Site Admin
Posts: 799
Joined: Tue Feb 11, 2020 3:10 pm
Location: San Francisco, California, USA
Real Name: Douglas Blumeyer
Contact:

### Re: consistent Sagittal 37-Limit

I have reduced the SoS possibilities to:
+ + +
+ +
+ +
+ +
+
+
+
These ones, I realized while doing this work, were not actually real:
+ +
+
+
The third of those three unreal ones was the one I suggested. These three are not real because and are not valid symbols.

Here are the thusly-calculated commas for . Because I included the original 47S, some of these aren't 37 limit. And many of them are outside the cents range they should be in. But I thought folks would be interested in the full possibility set. Unfortunately the results were just over the character limit for posts on this forum, so here's a link to a shared Google Sheet:
https://docs.google.com/spreadsheets/d/ ... sp=sharing

For now I am assuming that Layer B (and C) of this thread does not exist, so I went ahead and highlighted the 455/11S in the results, assuming we're not changing any boundaries due to SoS-related issues.

With respect to Layer B (or C) of this thread, I haven't broken it out into a separate topic because I don't know yet to what extent the old emails and documents from George and Dave may affect either layer. So I'm not assuming yet that they aren't still interconnected.

Dave Keenan
Site Admin
Posts: 1099
Joined: Tue Sep 01, 2015 2:59 pm
Location: Brisbane, Queensland, Australia
Contact:

### Re: consistent Sagittal 37-Limit

Sorry I have no time to digest all this. The review was a good idea and I think your investigations are useful. But any SoS other than SoE or SoCA is probably only useful as a way of generating potential candidate commas.

I just realised that I should have included EDA degrees as well as EDO degrees when I wrote:
"Yes I usually meant to include diacritics when I have said "flag arithmetic" in the past. "Sum of flags", and now "sum of elements", can refer to the untempered size in cents or the tempered size in EDO degrees, depending on the context."

This suggests you should investigate whether it is possible to assign an integer number of minas (233-EDA) to every flag and accent in such a way that every Olympian symbol represents the correct SoE. Or is it only by assigning integer minas to whole cores and using SoCA that this works?

To begin with, of course we have:
= 1
= 2
= 5 [Edit: Wrong! It's 4]

cmloegcmluin
Site Admin
Posts: 799
Joined: Tue Feb 11, 2020 3:10 pm
Location: San Francisco, California, USA
Real Name: Douglas Blumeyer
Contact:

### Re: consistent Sagittal 37-Limit

Dave Keenan wrote:
Mon May 18, 2020 12:22 pm
any SoS other than SoE or SoCA is probably only useful as a way of generating potential candidate commas.
Totally agreed. In fact I thought I wrote something to that effect myself. I may not have actually made it to the page.
I just realised that I should have included EDA degrees as well as EDO degrees when I wrote:
"Yes I usually meant to include diacritics when I have said "flag arithmetic" in the past. "Sum of flags", and now "sum of elements", can refer to the untempered size in cents or the tempered size in EDO degrees, depending on the context."

This suggests you should investigate whether it is possible to assign an integer number of minas (233-EDA) to every flag and accent in such a way that every Olympian symbol represents the correct SoE. Or is it only by assigning integer minas to whole cores and using SoCA that this works?
Excellent insight, and excellent question. Here are the rest:

= 1
= 2
= 4
= 7
= 12
= 18
34
44
56
65
68

And then here are the results for SoE:

symbol	EDA	SoE EDA
|	0	0
|	1	1
|	2	2
.)|	3	3
'|	4	4
'|	5	5
,)|	6	6
)|	7	7
)|	8	8
)|	9	9
,,|(	10	10
,|(	11	11
|(	12	12
|(	13	13
.~|	14	14
,'|(	15	15
'|(	16	16
,~|	17	17
~|	18	18
,)|(	19	18	-1
)|(	20	19	-1
)|(	21	20	-1
)|(	22	21	-1
,')|(	23	22	-1
')|(	24	23	-1
)~|	25	25
.~|(	26	26
.~|(	27	27
,,~|(	28	28
,~|(	29	29
~|(	30	30
~|(	31	31
,,|~	32	32
,|~	33	33
|~	34	34
|~	35	35
~~|	36	36
~~|	37	37
~~|	38	38
,./|	39	39
./|	40	40
)|~	41	41
,,/|	42	42
,/|	43	43
/|	44	44
/|	45	45
/|	46	46
.)/|	47	47
'/|	48	48
'/|	49	49
,,)/|	49.597	49	-0.597
,)/|	50	50
)/|	51	51
,.|)	51.504	51	-0.504
.|)	52	52
.|)	53	53
,,|)	54	54
,|)	55	55
|)	56	56
|)	57	57
|)	58	58
,'|)	59	59
'|)	60	60
'|)	61	61
,)|)	62	62
)|)	63	63
.(|	64	64
|\	65	65
|\	66	66
,(|	67	67
(|	68	68
(|	69	69
(|	70	70
,'(|	71	71
'(|	72	72
,~|)	72.475	73	0.525
~|)	73	74	1
~|)	74	75	1
~|)	75	76	1
,.(|(	75.489	75	-0.489
.(|(	76	76
'~|)	77	78	1
/|~	78	78
,,(|(	78.509	78	-0.509
,(|(	79	79
(|(	80	80
(|(	81	81
~|\	82	83	1
,.//|	83	83
.//|	84	84
.//|	85	85
,,//|	86	86
,//|	87	87
//|	88	88
//|	89	89
//|	90	90
,'//|	91	91
'//|	92	92
'//|	93	93
,)//|	94	94
)//|	95	95
)//|	96	96
)//|	97	97
,,/|)	98	98
,/|)	99	99
/|)	100	100
/|)	101	101
(|~	102	102
,'/|)	103	103
'/|)	104	104
'/|)	105	105
./|\	105.476	105	-0.476
./|\	106	106
,,/|\	107	107
,/|\	108	108
/|\	109	109
/|\	110	110
,(/|	111	111
(/|	112	112
(/|	113	113
'/|\	113.42	113	-0.42
'/|\	114	114
,)/|\	115	115
)/|\	116	116
)/|\	117	117
)/|\	118	118
,.(|)	119	119
.(|)	120	120
,|\)	120.58	120	-0.58
|\)	121	121
|\)	122	122
,(|)	123	123
(|)	124	124
(|)	125	125
(|)	126	126
,'(|)	127	127
'(|)	128	128
,.(|\	128.524	128	-0.524
.(|\	129	129
.(|\	130	130
|\\	131	130	-1
,(|\	132	132
(|\	133	133
(|\	134	134
(|\	135	135
,,)|\\	136	135	-1
,)|\\	137	136	-1
)|\\	138	137	-1
)|\\	139	138	-1


Of course it's not surprising that the non-integer halves of each split mina are off (though I had hoped for more of them to be less than |0.5| off). But a few cores are off too:  ,  ,  ,  , and  .

If instead we go by SoCA, then indeed the EDA-based arithmetic works out.
Last edited by Dave Keenan on Wed May 20, 2020 7:36 pm, edited 1 time in total.
Reason: Changed "= 5" to "= 4"

Dave Keenan
Site Admin
Posts: 1099
Joined: Tue Sep 01, 2015 2:59 pm
Location: Brisbane, Queensland, Australia
Contact:

### Re: consistent Sagittal 37-Limit

Based on what we agreed in this admin topic regarding the relative unimportance of SoE, and SoS that aren't based on symbols at the same or lower level, and your reading of my email bomb, I'm thinking that maybe you can now state a simple proposal (maybe with a diagram of the 75th mina) to make the extreme precision JI notation have only 37-limit defaults/primary commas, giving arguments only for objections you think I (or others) may still have, not for all the problems I have ever raised in this thread.

cmloegcmluin
Site Admin
Posts: 799
Joined: Tue Feb 11, 2020 3:10 pm
Location: San Francisco, California, USA
Real Name: Douglas Blumeyer
Contact:

### Re: consistent Sagittal 37-Limit

Dave Keenan wrote:
Wed May 20, 2020 3:22 pm
Based on what we agreed in this admin topic regarding the relative unimportance of SoE, and SoS that aren't based on symbols at the same or lower level, and your reading of my email bomb, I'm thinking that maybe you can now state a simple proposal (maybe with a diagram of the 75th mina) to make the extreme precision JI notation have only 37-limit defaults/primary commas, giving arguments only for objections you think I (or others) may still have, not for all the problems I have ever raised in this thread.
Agreed. We spent some good time expanding the thread out and tying off a bunch of fraying ends. But now it is time to bring all back in toward an actionable proposal.

In terms of my Layers, I would say that:
• Layer B (and C) became this: neither resolve overlapping commas in 12 different places, potentially requiring invalidating some symbols — nor decide that OoBSoE exceptions are not critical. Instead replace OoBSoE exceptions with OoBSoLFS exceptions, of which there are two.

This Layer comes full circle since these two exceptions are the exact same two exceptions surfaced before we got more rigorous about our definitions of SoS and zones that mattered. One of them is the 75th mina, the original topic of this thread. The other one is the 28th mina, and I will make a separate thread to address its problems soon, as it is its own can of worms.
• Layer A, the search for a replacement comma, is canceled.

This is because my proposal involves not suggesting a new 37-limit comma to replace the 47-limit 1/47S, but rather eliminating the split of the 75th mina, so that the 11/23S covers that entire mina.
75th Mina.pdf
(70.8 KiB) Downloaded 58 times

Edit: I have since noticed that the split mina in the diagram above should have been labelled the ≈75.538th mina, not the ≈75.489th. Not sure how that happened.

Here's something @Dave Keenan coached me in an email recently:
We need to find out what the Athenian and Promethean boundaries were, before they got tweaked to half-mina and then half-tina boundaries. Were they all at midpoints between primary commas, or were some of them half-way between 21-EDA or 58-EDA or 27-EDA or whatever EDA boundaries?
In other words, we must be mindful of where bounds for zones were in the Medium and High precision levels before the Very High and Extreme levels were introduced. While I'm not aware of any further Sagittal archaeological developments, I have included 809-EDA, 233-EDA, 58-EDA*, 47-EDA, and 21-EDA** in this chart to help make sense of the boundaries (much as can be seen in an alternate/early version of the Precision Levels diagram Dave shared in this post earlier in this thread). I don't expect to be able to reverse engineer every thought and decision just from the final result (e.g. when snapping at a higher precision, does one snap cumulatively — snapping from the previous snap — or undo the previous snap before re-snapping?) (though maybe a dedicated Sagittal archaeologist might be able to prove such conclusions) but it should at least help.
Dave Keenan wrote:
Fri May 15, 2020 5:21 pm
Commas on the point of an arrow.
Angels on the head of a pin?

We need to understand why George split the 75th mina.
According to George in one of the emails Dave dropped on us here:
While I did find it necessary to split some minas, there were not very many (only 6 up to 1/2-apotome in olympian, where there were two fairly popular commas within the same mina boundaries).
I think it is safe to infer from this that (at least one) purpose of splitting minas is to accommodate situations where more than one fairly popular comma occurs within the same mina boundaries.

I may not understand fully how to use the Scala stat files Dave shared out early on in this thread. As far as I can tell, these show that the 1/47S is fairly popular (something I find hard to believe) and the 11/23S — the comma the 75th mina was split with — does not occur at all (something I do not find hard to believe).

Another file was shared in this post called "NotDeriv" (short for Note Derivation, I assume, in an environment where filenames were limited to 8 characters) has the values 72 and 113 for the 47S (which we are referring to here in directed form as 1/47S) and the 11:23S (which we are referred to here in directed form as 11/23S) in the Pop2 column under Popularity Ranking, which corresponds with the values George gives for them in the email I quote of his below, but unfortunately these values are hard-coded there so without doing actual mathematical archaeology I don't know how they were derived.

What am I missing? Clearly something must have led Dave and George to want to include both of these commas because of the importance of the commas themselves. And it must have been something fairly important, because otherwise, especially as the diagram I've attached illuminates, there seems to be every reason not to split this mina:
1. limit reduction

It reduces the Extreme precision level from needing to be processed with 47-limit machinery down to 37-limit, which was our original goal. While it is the case that as far as I can tell, in terms of popularity, it is the 1/47S which is the comma of the two which should be kept, not the 11/23S. But again, I'm not super confident about my ability to gauge this popularity. And popularity is not of utmost importance at this degree of precision anyway.
2. OoBSoFLS exception resolution

Un-splitting this mina resolves one of the two OoBSoFLS exceptions currently in the Extreme precision level. That is, it fixes one of the places where the sum of lowest fewest symbols a symbol can be decomposed into is outside the bounds of its secondary comma zone.

The OoBSoFLS exception was technically for , however, of the two OoBSoFLS exceptions, this was the more insidious one, since in this case the problem was that not only was 's SoFLS out-of-bounds, but it was precisely the same as the SoFLS for its neighbor and thus it would not be possible to solve the problem by merely moving the boundary. One or the other symbol needed to be invalidated.

Respecting DAFLL, only these two cores are candidates in this position, so the only replacement symbols possible are re-accentings of one or the other.

Replacing with would be technically possible, although it would also be the only symbol using a combination of the schisma accent plus the bi-mina accent both in the same direction for a total alteration of 6 minas, which seems a bit extreme (and also it feels especially wrong to introduce such a one-time-only exception here when what brought us here in the first place was resolving a one-time-only exception in the same position).

And replacing with could work, but then, in order to resolve the DAFLL exception it would introduce, we'd have to move the boundary between and in the Very High precision level in the direction which further inequalizes the size of their zones, leaving with only a 1-mina wide zone (which is not unheard of in the Very High precision level — I think there are maybe a dozen or so of them).

But if we could move the boundary in the other direction by covering the entire mina with some form of , then there are so many benefits! We'll get to those next.
3. Very High precision level boundary move - halfway between commas

The split was allegedly to fix a DAFLL*** exception:
Update: Here are the changes I made to remove the DAFLL exceptions. I
unsplit one olympian mina in the above list and split two others, so
now olympian has 7 split minas.
75th mina:
In olympian I split this mina between ~|)'' 47S (rank 72) and .(|(.
11:23S (rank 113) and moved the herculean-X boundary between ~|) and
.(|( to coincide with the split.
This suggests that before the mina was split, it was assigned to either an accented or an accented and that therefore, since that mina straddles both of those cores in the next level down, one of the two halves would represent a DAFLL exception.

What I don't understand is this: since minas (233-EDA) never line up with the 58-EDA of the immediately lower level, given that 233 is not a multiple of 58, doesn't that mean that literally every change of core would require a mina split? Or is it only in cases where the 58-EDA boundary fell too close to the middle of the 233-EDA boundary, beyond some tolerance threshold, where splitting the mina was considered the only acceptable solution, rather than moving the lower level precision level's boundary too far, since preventing the lower levels from getting distorted too much when introducing the higher levels is important?

I just don't understand from where the herculean-X (what we call today the "Very High" precision level) boundary was moved, or even from what direction.

But maybe we don't have to, because if you move the boundary at the Very High precision level, you can see that it brings the boundary almost exactly onto the point halfway between the two commas (not exactly, but within a thousandth of a cent), which is quite desirable.
4. Very High precision level boundary move - comma centering

Moving this boundary also results in the in the Very High precision level becoming close to centered in its capture zone. (On the other hand, becomes less centered, so there's a bit of a trade-off. But I think the balancing of the size of their zones is more important).
5. Very High precision level boundary move - half-step-of-EDA proximity

Moving this boundary brings it very close to a half-mina, the 74.5. It also brings it close to a half-step of 58-EDA, 18.5.
6. simplification

This change overall simplifies and standardizes notation, which is good.
Let me know what you think!

*I sometimes see it as 59-EDA but I don't understand what it would mean to be 58-EDA/59-EDA. Neighboring ED's are in some senses as different as possible. Does this mean actually 58 * 59 = 3422-EDA where some steps are 58 and some are 59? Or does it mean that both EDA's co-exist and bounds can be snapped to one or the other of them?
** In this chart it is shown as 27-EDA but I believe the intention was for it to say 21-EDA. Clearly there is some lingering confusion between 21- and 27- EDA since Dave's recent email mentioned both in a seemingly slightly frazzled manner. Though I also note that I find no references to 27-EDA on the forum so maybe it's just when he's not running on a full brain.
*** I suggest we should call it DEFLL, though: Drop Elements for Lower Levels.
Attachments
75th Mina.png
(220.63 KiB) Downloaded 592 times

Dave Keenan
Site Admin
Posts: 1099
Joined: Tue Sep 01, 2015 2:59 pm
Location: Brisbane, Queensland, Australia
Contact:

### Re: consistent Sagittal 37-Limit

cmloegcmluin wrote:
Tue May 26, 2020 8:52 am
I think it's probably a good thing, actually. Doesn't it just mean that a great variety of commatic alterations are captured at the Extreme level, leveraging the fact that so many different prime exponent vectors are close to the primary commas for and ?
You have probably seen by now, that Ash has come up with a new use for that table — deciding tina commas. Would it be difficult for you to go back and add an occurrence count for each such comma, and add commas that correspond to zero minas (preferably without requiring horizontal scroll bars).
Okay, that would make sense. That convincingly answers my question about where the boundary probably was before it was moved as part of splitting the mina.

Except I think in the last sentence you meant "which should have predisposed George to using for the 75th mina."
I did indeed. I copied and pasted the wrong smiley conglomeration. I've added an edit note to the original. Thanks.
That's an excellent consideration to surface. The stats are not everything. We have no frequency of use data to weight them by. They're noisy and a lot of junk in there. And they're only historical.

The Scala scale archives do indeed correspond with what you've noticed.

So we've got a bunch of mere catalogs of harmonics / primes:
...
rational "temperings" of logarithmic tunings:
...
impositions of ratios on traditional tunings that do not traditionally use them:
...
similar to the above category, perhaps (see: http://www.tonalsoft.com/enc/s/schlesinger.aspx):
...
Wow! All those had 47's in them? Thanks for doing this survey.
and then a few that may actually be indicative of future needs:
• George Secor's 24-triad proportional-beating well-temperament (24e) (maybe George was just tying to slip the 1/47S by us so he could notate this scale exactly... )
Hah!
• M. Schulter, scale from mainly prime-to-prime ratios and octave complements (Gb-D#) (another friend! Hi @mschulter )
• Sparschuh's epimoric two- and one-7th part of syntonic comma (2010) (epimoric!)
• Modified Sparschuh temperament with a'=419 Hz by Tom Dent
• Andreas Sparschuh WTC temperament. 1/1=250 Hz, modified Collatz sequence
• E scale (link here: https://github.com/cmloegcmluin/Scala-s ... iter26.scl)
• 31-tone Tetraphonic Cycle, conjunctive form on 5/4, 6/5, 7/6 and 8/7

Now of course we might audit any one of the commas in this way and be similarly disappointed with the quality of the results. The point of the Scala stats is to keep us honest. As more of a heuristic.
Agreed.
36.706¢, [ -2 0 -1 -1 1 1 ⟩, 143/140, 143/35S, 13 limit, -2.260 slope, 36 SoPF
`

This is the only other interesting one, I think, if you're willing to take a dent in SoPF. It's opened up now that I widened the scope for my script to the entirety of the 75th mina (it was in the upper half before).
Thanks for that survey too. Let's keep 11:23S.
So... George is fallible.
Yes. He wasn't really a Greek god.
But I do think we should assume he knew what he was doing, and it was for better reason than exactly notating his 24-triad proportional-beating well-temperament. Perhaps if we can find a reason why the 11/23S would also have been really important to him, that would be enough.
And failing that, we should try to at least find a plausible story about how the sequencing of events left him in a cul de sac.

I hadn't considered that he might have felt it was important to notate 11:23. Good point! Perhaps he felt we should be able to notate the entire 23-limit diamond exactly, equivalent to notating all pairs of opposing primes from 5 to 23 exactly. Are there any other 11:23 commas? Are all the other pairs exactly notatable?

Dave Keenan
Site Admin
Posts: 1099
Joined: Tue Sep 01, 2015 2:59 pm
Location: Brisbane, Queensland, Australia
Contact:

### Re: consistent Sagittal 37-Limit

[Reverse-engineered from browser cache after disaster. Originally posted Mon May 25, 2020 2:11 pm]
cmloegcmluin wrote:
Mon May 18, 2020 7:02 am
... I did go ahead and [find] every value that and  could be said to take when subtracting the rest of the symbol out from the Extreme Precision (Olympian) JI notation. Here those all are. There are actually 25 different values for and 13 different values for :
This blew me away. I had no idea there were so many. Or that they came so close to crossing over. It seems bad. But I think simply noting it and moving on, is the right approach.

Dave Keenan
Site Admin
Posts: 1099
Joined: Tue Sep 01, 2015 2:59 pm
Location: Brisbane, Queensland, Australia
Contact:

### Re: consistent Sagittal 37-Limit

[Reverse-engineered from browser cache after disaster. Originally posted Mon May 25, 2020 5:45 pm]

NotDeriv was short for "Notation Derivation".

Thanks for yet another wonderful diagram. I'm almost ready to agree with unsplitting the 75th mina in the way you suggest.

It comes down to three questions for me:
• Was there ever really any point in splitting the 75th mina?
• If it is not split, what symbol should it have?
• If it is not split, what comma should it default to on playback? Or equivalently, what comma should be exactly represented by that symbol.

I think it's very safe to assume that before George split the 75th mina, the whole mina was assigned to 47S, because it has so many more Scala archive occurrences than 11:23S. But which of the two valid (by mina arithmetic) symbols was assigned to the whole 75th mina before it was split? I can only assume it must have been because if it had been there would not have been any DAFLL violation, which George clearly states as the reason for the split.

Then we must ask, why was George so resistant to assigning to 47S? Surely the pre-existing boundary at the VH precision level (one level down), between and would have either been at 18.5/58 of an apotome, or midway between their commas 49S and 11S, which you have shown amount to practically the same thing, which is very near 74.5 minas, which should have predisposed George to using [Edit: I meant ] for the 75th mina.

Or else we have to answer, why was the boundary at the VHP level not set near 18.5/58 apotomes or the midpoint between the commas?

Basically, I need a convincing explanation of how someone as smart of George could have got this so wrong.

On the other questions: I agree that slavishly assigning symbols in order of frequency in the Scala archive doesn't make a lot of sense when we get to such rare ratios. Such frequencies of occurrence can be accidents of history which are unlikely to reflect the probability of future notational needs.

One such effect I've noticed in the past is some historical scales that appear to be "tempered by ratios". Or at least ratios seem to sometimes be used merely to describe approximate pitches, possibly because that's the tool the author was most familiar with. It might be worth searching the archive to look for these 47's to see if it looks like their use might be predictive of future notational requirements or not.

If not, we should probably shift to using the sum-of-prime-factors (SoPF) metric that seems to be a reasonable match for the ranking of commas for notating more popular ratios. Is 11:23S the 37-limit comma with the lowest SoPF in the 75th mina (say with absolute slope ≤ 12)?

I would also need to do some archaeology to answer your question as to how we went from simple Scala archive occurrence counts for ratios with their factors of 2 and 3 removed (which I think is what's in the ratio popularity spreadsheet) to assigning notional occurrence counts to the commas that might be used to notate those ratios in various spellings (which I think is what's in the comma popularity spreadsheet).