28th mina OoBSoLFS exception resolution

User avatar
cmloegcmluin
Site Admin
Posts: 1700
Joined: Tue Feb 11, 2020 3:10 pm
Location: San Francisco, California, USA
Real Name: Douglas Blumeyer (he/him/his)
Contact:

28th mina OoBSoLFS exception resolution

Post by cmloegcmluin »

Recently I pulled on a weird-looking thread I spied in the Extreme Precision JI notation, and it led to a few other concerns coming to light, and @Dave Keenan digging up some old emails between him and George about how the Extreme Precision level was developed. One of the things we noticed there is that there's a problem at the 28th mina where a symbol's sum-of-lowest-fewest-symbol decomposition (SoLFS) is out-of-bounds (OoB) of its secondary comma zone. Specifically:

:,,::~|(: → SoFLS → :~|(: + :,,::!: = 14.730¢ + -0.833¢ = 13.898¢

The secondary comma zone of a symbol is defined as the capture zone at the precision level at which the symbol is introduced. Since :,,::~|(: is introduced at the Extreme precision level, and its capture zone at that level is from 13.420¢ to 13.842¢, its secondary comma zone is 13.420¢ to 13.842¢. So the problem is that :,,::~|(: 's SoLFS is outside that zone — just barely, but outside nonetheless.

The purpose of respecting OoBSoLFS exceptions is to ensure that the symbols used to represent swaths of pitch space do not stray too far from where one would expect they'd be given the primary commas of their key sub-symbols. This 28th mina's situation was one of only 2 spots where such an issue was identified.

So what are our options for resolving this exception?


1. Shift the boundary

This was my original proposition.
cmloegcmluin wrote: Fri May 15, 2020 3:59 pm We can't move the upper bound of :,,::~|(: any higher than 14.191¢, because the next symbol up, :,::~|(: , has a default value of 14.191¢ coming from its primary comma, the 245C. Its sum-of-flags value is 14.307¢ (14.730¢ - 0.423¢), even higher, so we don't need to worry about it. In other words, we need to land it somewhere between 13.897¢ and 14.191¢. It looks like if you move it up by half a mina you get 14.123¢. Good enough?
Moving the boundary up by half a mina means moving it from the 28.5th mina to the 29th mina. We usually prefer to keep the boundaries on the half-minas, so moving it onto a whole mina may be the least desirable place to move it (simple though it was for me to propose that at the time, given that I was focusing on other issues).

Perhaps it would be slightly better if we moved the boundary to halfway in between the two commas? This is another desirable technique. Locally, of course, it's a quite fair way to distribute the space (well, perhaps it would be more fair to weight the allocation by popularity, but I digress) but it was decided not to do this everywhere in the JI Precision Level notations because a rigid equal-division based parceling of pitch space ameliorated some of the struggle with comma selection, which gets increasingly challenging and arbitrary-feeling:
George Secor, 2-Oct-2007 in email wrote:As I stated above, the problem is that we must then be very careful in
our choice of primary commas, because it's going to affect the location
of the symbol boundaries. The more symbols in the notation, the more
complicated (unpopular, obscure) the commas eligible for the
definitions. The more complicated the commas eligible for the
definitions, the less clear it is which of those eligible commas should
be chosen. Mina boundaries solve that problem by making boundaries
independent of comma choices (except where minas are split).

If minas are split, then they're split in order to notate some worthy
comma (which by definition excludes highly unpopular or complex commas)
from a more popular comma with the same mina boundaries. It's a simple
matter to put the sub-mina boundary halfway between these two commas,
assuming that there are suitable symbols available.
It may not be too crazy to suggest that in at least this one position we may need to use comma-midpoint bounds not within one mina, but across two minas.

This would result in the boundary being placed at:

( :,,::~|(: + :,::~|(: ) / 2 = (13.795¢ + 14.191¢) / 2 = 13.993¢

which indeed is high enough that :,,::~|(: 's SoLFS at 13.898¢ is in bounds, while not going so far as to surpass 14.308 or 14.191¢, :,::~|(: 's SoLFS and primary comma, respectively.


2. Change the symbol — more complex spelling of 2-mina adjustment

As mentioned, the SoLFS for :,,::~|(: is only barely out of bounds, too big by about 0.05 cents. It's so barely out of bounds, in fact, that the next symbol down, following Sagittal's accenting conventions, is too small! Which is unsurprising, since :`::.::~|(: is used as the symbol for the next mina down.

I suspected that this extremely unfortunate happening could be explained by a feature of the SoLFS calculation, that :`::.::~|(: 's SoLFS would be calculated as :.::~|(: + :`::|: , i.e. that it would be relative to whatever comma :.::~|(: represented, which might be just different enough from the comma that :~|(: + :.::!: represented to account for the OoBSoLFS exception. However, this suspicion was allayed when I determined that :~|(: + :.::!: exactly equals :.::~|(: . So that's not the problem.

It really is just a most unfortunate alignment of the 233-EDA grid with the commas in this one spot. :`::.::~|(: to :,,::~|(: jumps from 13.199¢ to 13.898¢, a 0.699¢ wide gap, which straddles all the way across that 13.842¢ - 13.420¢ = 0.422¢ zone. This swath of Extreme precision JI just happens to fall entirely in the gaps between Sagittal's accents' primary comma intervals.

Now it's important to point out that four :`::|: 's do not exactly make one :'::|: . Actually it's closer to five :`::|: to a :'::|: , despite them getting mapped to the 1st and 4th minas. Sagittal typically spells a 2-mina deviation with :``::|: , rather than :,,::'::|: , obviously because the former is one mark on the page simpler (and the same is true of their inverses). But the difference in actual value between :``::|: and :,,::'::|: is just enough that it would resolve the OoBSoLFS exception in this position.

To be clear, if we represented the 7/125C at the 28th mina with :``::.::~|(: instead of with :,,::~|(:, we get

:``::.::~|(: → SoFLS → :.::~|(: + :``::|: = 12.777¢ + 0.833¢ = 13.609¢

which is inside the 13.420¢ to 13.842¢ bounds.

This is a possibility, but I do not recommend it, because I dislike exceptions.


3. Change the symbol — change of core

Currently, no symbol has accents totaling greater than 5 minas deviation from the core. Only one core other than :~|(: is within this 5-mina range of the 28th mina and thus could be used as an alternate base for its symbol, and that core is :)~|: . The core :|~: comes within 1 mina, mais ceci n'est pas une cigar. (Also it couldn't work without a DAFLL exception).

The problem I have with replacing :,,::~|(: with :'::)~|: is that it compounds another problem I see right in this vicinity. Here is the problem:

There is only one spot in the entire Very High precision level where one cannot drop accents for a lower level, whether that lower level be High or Medium, and that is with :.::~|(: (covering the same pitch space as the 26th and 27th minas in the Extreme precision level). In the High precision level, this area is covered by :)~|: ; in the Medium precision level, this area is covered by :)|(: . This is something I would like to see changed, if at all possible. I expect, given the thoroughness and methodical nature of the crafting of the precision level notations as they are now, there was quite a bit of struggle in this territory, and good reason to prefer this outcome, but I don't know what that was and I can't suss it out myself.

And the way replacing :,,::~|(: with :'::)~|: compounds that problem is this: it would introduce a second example of this very DAFLL exception, its mirror image in fact. Now an accented :)~|: would overhang :~|(: in lower levels, just as an accented :~|(: overhangs :)~|: in lower levels. Thus, the problem would be rendered nigh unsolvable, because moving the boundary between :)~|: and :~|(: in lower levels, in either direction, would not solve it.

What we could do to solve this problem, then, is change the core for not only the 28th mina from :~|(: to :)~|: , but also the core from :~|(: to :)~|: for the 27th and 26th minas too.

:,,::~|(::,::'::)~|:
:`::.::~|(::``::)~|:
:.::~|(::`::)~|:

We have :,::'::)~|: in our notation, but not :'::)~|: . This would be the first such example of including a :,::':-notated core without its :':-notated core. Besides, the point of this exercise is avoiding DAFLL exceptions, so we'd also be replacing :.::~|(: in the Very High precision level with :'::)~|: anyway. So we must replace yet a fourth :~|(:-core symbol with a :)~|:-core symbol: :,::~|(::'::)~|: . This solution also involves extending the boundary between :)~|: and :~|(: in the High precision level.

What's sad about this is that we lose some exactness in the element arithmetic. As mentioned previously, :.::~|(: has the exact same value as :~|(: + :.::!: , which is a desirable property for a symbol to have; the core is the 17C, 14.730¢, while the accented symbol is the 17/5C, 12.777¢, exactly one 5s (schisma) away. If we keep all the commas as they are now, the element arithmetic would no longer be exact.

But what's the real bummer here is that we get an OoBSoLFS exception taking this approach too! :)~|: + :``::|: = 12.064¢ + 0.833¢ = 12.897¢ which is outside the 12.999¢ to 13.420¢ secondary comma zone for the 27th mina. So we'd have to apply the type of solution proposed in solution 1 here to resolve that.

So this is strictly more complex of a change than solution 1. I like how it fixes the single DAFLL exception in the Very High precision level, but I recognize it's a big change.


4. Accept the problem

A perfectly reasonable solution: accept that one tiny OoBSoLFS exception exists in the Extreme precision level notation.

...And set the stage for acceptance of many such OoBSoLFS exceptions in the Insane precision level.


So, in conclusion, I can only recommend solution 1 or 3. I don't recommend solutions 2 or 4. I am open to further solutions. If anyone would like visualizations of this discussion made akin to the ones I used in the topics for the 75th and 140th minas, please let me know.
Last edited by Dave Keenan on Tue May 26, 2020 10:35 pm, edited 2 times in total.
Reason: Restored links
User avatar
Dave Keenan
Site Admin
Posts: 2180
Joined: Tue Sep 01, 2015 2:59 pm
Location: Brisbane, Queensland, Australia
Contact:

Re: 28th mina OoBSoLFS exception resolution

Post by Dave Keenan »

You seem to be having trouble remembering your own acronym. :) What makes sense to me is SoFLS as Sum of Fewest Lower Subsets. It was previously (but less generally) SoCA for Sum of Core and Accents.

The problem of the 28th mina symbol having its SoFLS comma falling outside its capture zone, occurred when the boundaries that were on half minas, were snapped to the nearest half tina. I'm amazed that there were not more such SoFLS-OoB's.

I think the right thing to do is to move the boundary. i.e. Your first solution. But possibly with a slightly different value.

98.5 tinas	13.842 ¢	(present upper bound - bad)
Symbol SoLFS	13.898 ¢		
28.5 minas	13.906 ¢	98.955 tinas (upper bound before snapping to nearest half-tina)
99.5 tinas	13.982 ¢	(nearest half-tina to mean of commas, close 2nd-nearest to 28.5 minas)
Mean of commas 	13.993 ¢	(cmloegcmluin proposal)

George decided to snap the boundaries to odd half-tinas some years after the extreme precision level had otherwise been finalised with a boundary at every odd half-mina and a few others (the "split minas") at the mean of the primary commas on either side of them. I supported the snapping to odd half tinas. But I didn't realise until recently, that George had only snapped the half-mina boundaries to their nearest odd half-tinas, and had not snapped the mean-of-commas boundaries to their nearest odd half-tinas, instead leaving them as mean-of-commas. That seems to me like the wrong thing to do.

Unfortunately, some split minas do not have an odd half-tina in between the two commas, so mean-of-commas remains the best compromise. Unless we think we can eliminate those particular split minas. But the 28th mina is not a split mina, so this doesn't need to enter into the decision as to where to put its upper boundary.

We could place the 28|29 mina boundary at 99.5 tinas. We could view this either as taking the mean-of-commas and snapping it to the nearest odd half-tina, or we could view it as taking 28.5 minas and snapping it to the nearest odd half-tina that encompasses its SoFLS (without stealing the SoFLS of the other symbol).
User avatar
cmloegcmluin
Site Admin
Posts: 1700
Joined: Tue Feb 11, 2020 3:10 pm
Location: San Francisco, California, USA
Real Name: Douglas Blumeyer (he/him/his)
Contact:

Re: 28th mina OoBSoLFS exception resolution

Post by cmloegcmluin »

Dave Keenan wrote: ↑
Mon May 25, 2020 7:20 am
We could place the 28|29 mina boundary at 99.5 tinas. We could view this either as taking the mean-of-commas and snapping it to the nearest odd half-tina, or we could view it as taking 28.5 minas and snapping it to the nearest odd half-tina that encompasses its SoFLS (without stealing the SoFLS of the other symbol).
In short: I 100% agree with your revision to my proposal.
User avatar
cmloegcmluin
Site Admin
Posts: 1700
Joined: Tue Feb 11, 2020 3:10 pm
Location: San Francisco, California, USA
Real Name: Douglas Blumeyer (he/him/his)
Contact:

Re: 28th mina OoBSoLFS exception resolution

Post by cmloegcmluin »

Dave Keenan wrote: ↑
Mon May 25, 2020 7:20 am
You seem to be having trouble remembering your own acronym. :) What makes sense to me is SoFLS as Sum of Fewest Lower Subsets. It was previously (but less generally) SoCA for Sum of Core and Accents.
I was afraid I was doing that! Yes, SOFLS is better (I like uppercasing the "O" myself, unless we also lowercase the "f" in DAFLL or DEFLS or DAFSS or whatever becomes of the "Drop Accent/Element for Lower/Smaller Level/Subset/Sub-symbol").
User avatar
cmloegcmluin
Site Admin
Posts: 1700
Joined: Tue Feb 11, 2020 3:10 pm
Location: San Francisco, California, USA
Real Name: Douglas Blumeyer (he/him/his)
Contact:

Re: 28th mina OoBSoLFS exception resolution

Post by cmloegcmluin »

To be clear: I recognize that this proposed change (moving the 28|29 mina boundary to 99.5 tinas, from 98.5 tinas) is not greenlit yet, unlike the recent change to the 140th mina, which is. Let's give this one a little time to simmer.
User avatar
cmloegcmluin
Site Admin
Posts: 1700
Joined: Tue Feb 11, 2020 3:10 pm
Location: San Francisco, California, USA
Real Name: Douglas Blumeyer (he/him/his)
Contact:

Re: 28th mina OoBSoLFS exception resolution

Post by cmloegcmluin »

I have an observation that may dissuade me from the change to snap this bound from 98.5°/809-EDA to 99.5°/809-EDA.

Upon un-splitting all minas, the counts of tinas-per-mina follow a potentially maximally evenly distributed pattern of 3's and 4's, such as one sees in MOS scale specific step size patterns. By potentially I mean that since we're only considering a slice of about 60% of the apotome, we can't be certain, but it sure as heck looks like someone just snapped every midpoint of 233 to the nearest 809 and given that 809/233 is just under 3.5 that's why we see the overall alternation of 3 and 4 punctuated with the occasional extra 3.5. Here's the full pattern:

34343434334
3434343434343434334
34343434343434334
3434343434343434334
34343434343434334
3434343434343434334
34343434343434334
34343434343434334
3434 (...)

So what's the problem? Shifting from 98.5 to 99.5 fortunately does not create any 2- or 5- tina wide minas, but it does disrupt the pattern to the point of rendering impossible it being maximally evenly distributed:

34343434334
343434343434343434334
343434343434334
3434343434343434334
34343434343434334
3434343434343434334
34343434343434334
34343434343434334
3434 (...)

While this is an incredibly subtle point, I do feel like it could be considered to make the notation more complex and harder to understand. Since precedent already exists for snapping to comma means, and thus snapping to a comma mean doesn't add new concepts or complicate existing ones, I believe that changing this bound to the comma mean should remain under consideration.

I recognize that attempting to eliminate all snaps to comma means at the Extreme precision level is under consideration. And if we were to accomplish this, we would be simplifying the notation. So, if we were to snap all bounds at the Extreme level to EDA midpoints, there may be a case that this simplification would outweigh the corresponding cost of introducing one irregularity to the distribution of tinas per mina.
User avatar
Dave Keenan
Site Admin
Posts: 2180
Joined: Tue Sep 01, 2015 2:59 pm
Location: Brisbane, Queensland, Australia
Contact:

Re: 28th mina OoBSoLFS exception resolution

Post by Dave Keenan »

You've convinced me. Better to have another boundary midway between commas than have a fourth category of boundary — a "wrong" half-tina boundary — with only one example.

And, as you say, if we end up snapping them all to half-tinas (except those at square roots of 3-commas), it will then end up at 99.5 tinas. It would then be just one among many such irregularities, due to split minas.

But wait a minute, if we put it at the mean of commas, won't that give an uneven sequence anyway? Won't that mean there is a jump of 7 tinas at that point?
User avatar
cmloegcmluin
Site Admin
Posts: 1700
Joined: Tue Feb 11, 2020 3:10 pm
Location: San Francisco, California, USA
Real Name: Douglas Blumeyer (he/him/his)
Contact:

Re: 28th mina OoBSoLFS exception resolution

Post by cmloegcmluin »

Dave Keenan wrote: Sat Jun 13, 2020 11:44 pm But wait a minute, if we put it at the mean of commas, won't that give an uneven sequence anyway? Won't that mean there is a jump of 7 tinas at that point?
A good point! Yes, it would mean that. But I still think it's slightly better to have one missing member of this maximally even pattern of 3- and 4- tina minas than it is to have one tina-snapped mina which doesn't conform to it. In other words, I think a strict subset is better than a set with one exceptional member.

Although if we do snap all comma-mean bounds at the Insane level to tinas, then we'd end up with many irregular mina snaps that are in addition to the even 3- and 4- pattern, plus just a single one of them missing, here at the 28th mina. So we'd have mostly a superset but with one exceptional missing member!

But I do really want to snap everything to tinas. I think it's the right thing to do. Comma mean snaps should only be a last resort, when no -ina to snap to between commas is available, as you said on another thread. I wouldn't want to not snap everything to tinas just because of this incredibly obscure imperfection with the tina distribution across the minas.

If I had to choose between (a) preserving the situation where either a strict subset or strict superset of the maximally even distribution of tinas per mina and (b) resolving this 28th mina's OoBSoFLS exception and snapping everything possible to tinas, I would choose option (b) any day.

So let's not worry too much about the maximal distribution of tinas per mina, yeah?

If you'd like, I could check how many minas per ultrina (experimental name for step of 58-EDA) there are and if those have been similarly well distributed. And the same for ultrinas per highinas/hyinas (experimental name for step of 47-EDA) and highinas/hyinas per medina (experimental name for step of 21-EDA). If maximal evenness seems common across all the levels, maybe we should take it more seriously. Though these would all be in terms of the tinas they've been snapped to, as well.
User avatar
volleo6144
Posts: 81
Joined: Mon May 18, 2020 7:03 am
Location: Earth
Contact:

Re: 28th mina OoBSoLFS exception resolution

Post by volleo6144 »

cmloegcmluin wrote: Tue May 26, 2020 3:48 pm There is only one spot in the entire Very High precision level where one cannot drop accents for a lower level, whether that lower level be High or Medium, and that is with :.::~|(: (covering the same pitch space as the 26th and 27th minas in the Extreme precision level). In the High precision level, this area is covered by :)~|: ; in the Medium precision level, this area is covered by :)|(: . This is something I would like to see changed, if at all possible. I expect, given the thoroughness and methodical nature of the crafting of the precision level notations as they are now, there was quite a bit of struggle in this territory, and good reason to prefer this outcome, but I don't know what that was and I can't suss it out myself.
Wait, was there some sort of change somewhere (outside of the shift from :|::': to :`::|:) since SagittalJI.gif was last updated, or are you just forgetting :'::~|): 245S (the apotome-complement of :.::~~||: 245SS = 245:256, and also :'::/|: plus :,::~|(:), which is represented by :/|~: 5:23S = 45:46 in the High precision level and :(|(: 5:11S = 44:45 in the Medium precision level?

Aren't there actually two places in the Very High precision level that have this property?
I'm in college (a CS major), but apparently there's still a decent amount of time to check this out. I wonder if the main page will ever have 59edo changed to green...
User avatar
cmloegcmluin
Site Admin
Posts: 1700
Joined: Tue Feb 11, 2020 3:10 pm
Location: San Francisco, California, USA
Real Name: Douglas Blumeyer (he/him/his)
Contact:

Re: 28th mina OoBSoLFS exception resolution

Post by cmloegcmluin »

You are correct, @volleo6144, I missed that one! Nice find. Thank you.

Just another reason for me to keep working on this representation of the JI precision level notation in code, so can simply script up queries for stuff like this, and make myself less susceptible to manual error.

I don't think it changes the course of the decision about the 28th mina, but definitely worth addressing that DEfLL exception eventually if we can, too.
Post Reply