Just so we've got this straight, that's the `\text{lpe}` metric (short for lb + pow + exp) with `s = \frac{1}{12}, b = 1.37, t = 2^{-10.5} = 0.00069053396`, right?Dave Keenan wrote: ↑Wed Oct 28, 2020 7:45 pm So far, the best such usefulness-ranking function I have found (based on maximising the number of existing commas that it ranks as the most useful in their zone), is:
usefulness_rank = lb(N2D3P9) + 1/12 × AAS1.37 + 2^(ATE-10.5)
I confirm that this matches 91 of the commas. I do not necessarily confirm that it's the best possible metric (in the lpe family, or otherwise).
By the way, here's the latest (Aug. 16th) list of JI notation commas with high (>137) N2D3P9. We had only committed to changing the 2 worst of them, which were dramatically worse than the others.There are certainly 2 commas (for some rarely-used symbols) where we did a bad job. That is, we assigned commas that were far less useful than the most useful comma in the capture zone. These were identified earlier, based on their N2D3P9 values alone
You said in a recent email that these two replacement commas are each the most useful in their zones by all 8 metrics we're trying. That's certainly a strong argument. I'm fine with them. I note that neither \(\{\frac{143}{5}\}_{\scriptsize{2,3}}\) nor \(\{575\}_{\scriptsize{2,3}}\) are yet notated by a Sagittal comma, so that's nice. The N2D3P9 of the 1/575s but 183.68 is on the higher side and would make that list of commas with high N2D3P9 that I just shared. But maybe we should go back over that list and see if all those commas are the most useful in their zones, therefore justifying their subpar popularity.I believe for
we should replace 19/4375s [-8 10 -4 -1 0 0 0 1⟩ with 1/575s [6 2 -2 0 0 0 0 0 -1⟩
and for
we should replace 14641k [-17 2 0 0 4⟩ with 143/5k [-8 2 -1 0 1 1⟩
We're not jumping the gun by reassigning these before we complete the final step (popularity, usefulness, badness) and create the full badness metric, are we? Or was badness only relevant for assigning tinas — in other words we don't care about mina error?
I think you're on the right track, but slightly confused. The primary comma for has been 85/11M since before I showed up this year. You can find it in row 136 of George's spreadsheet calculator shared here (note: this version I'm linking here is out-of-date; I'm sharing it as proof of how long this 85/11M has been this way. The up-to-date version of the spreadsheet calculator can be downloaded here). The change we made that involved a 47-limit comma was this: we unsplit the 75th mina, eliminating the 1/47S from the notation altogether, because we found that its sum-of-elements was identical to the sum-of-elements for the comma it split the mina with, and therefore said sum-of-elements could not be one side or the other of the bound. My original suggestion was to knock the Extreme notation down three primes from 47- to 37-limit by changing that one comma somehow, but in investigating the possibilities, that's what we discovered and it ultimately became our primary justification for the change. Details here.Our recent replacement of 47M with 85/11M for was validated.
You asked me in a recent email what the other recent changes we made were. There's actually only one that we've actually made, and that was the 140th mina. Although now that I've refined my understanding of the domain, I don't actually think of any minas greater than 116, which is the mina just before the half-apotome. Every mina greater than that may have a novel flag and accent combo (which Dave and I have been calling "flacco" for short, haha) but its bounds and commas are perfectly symmetrical about the half-apotome mirror, or as Dave put it, they are "dependent" on the choices below the half-apotome. So nowadays what I would say we did was change the 93rd mina (140 - 116.5 = 23.5; 116.5 - 23.5 = 93). Although I suppose, since we also patched a bug with the system where in the High precision there was some unnotated no man's land between the largest single-shaft symbol and where things picked up coming back from the next apotome anchor, we were confronting issues which cannot be reduced to the half-apotome equivalent world but which are in fact necessary groundwork for it. And specifically what we did was change the symbol from to and shifted its lower bound to the S|M size category bound, to be symmetrical with the L|SS boundary, AKA the largest single-shaft symbol size. We did not change its comma. Actually, we found that the new symbol suited that comma even better, making its sum-of-elements closer to the primary comma than it was before (looking at it more carefully now, I see that it's not just closer, it's now exact; + = [ 5 -4 -1 0 0 1 ⟩ + [ -5 3 -1 1 1 -1 ⟩ = [ 0 -1 -2 1 1 ⟩ which is the 77/25C exactly).
Probably this call for reconsideration is moot because the specific item under reconsideration was not recently changed. But in case it is valuable, I point to a post I made some time ago which shows that ~41% of Sagittal commas are related by the Pythagorean comma (and therefore are in the same 2,3-equivalence class). And that's just the Pythagorean comma, one of several 3-limit commas that could separate one Sagittal comma from another. Based on this chart (there's some tweaks I'd like to make to it, so don't take it as word of the gods or anything, but for this purpose it should suffice. Well one big tweak is that it contains symbols whose primary commas are greater than the half-apotome and are thus essentially duplicates, per the previous paragraph (oh wait, this chart is better)) one can eyeball that there are a number of 2,3-free classes which have 3 Sagittal commas representing them. So clearly it is the case that pushing for unique 2,3-free class representation was not the highest priority when designing the JI notation. I'm not at all suggesting that was a mis-prioritization; I'm just making the observation.But it might need to be reconsidered in the light of the information below, because we already had a symbol for an 11:85 comma. for 85/11C.
I'm sure there's more reasons. I tried to write something intelligent-sounding about sweet spots in roughly-equally-spaced new useful commas and splitting inas but I couldn't convince myself it was correct. *shrug*I see at least two reasons here, not to use the most "useful" (according to the above function, or others like it).
1. The most "useful" is outside the symbol's capture zone at a higher precision level.
2. The most "useful" is a comma for a 2,3-equivalence class that already has a symbol (based a more useful comma for the same equivalence class).
Reason #1 concerns me a tad, because it runs counter to the way the story is generally told (or at least how I've come to understand it): that each higher precision level was created in sequence, and not allowed to modify the previously established levels (other than to nudge their bounds from the outdated EDA to its latest greatest EDA). An instance of applying the design principle that adding new features shouldn't make it harder to do the simpler stuff. That said, it is hard to explain why 's primary comma is the 19s, other than that you were contemplating introducing the concept of accents, and reserving the 5s as an excellent choice for the first of them.
Whoa. A+ insight right there. You're absolutely right.So optimising the above usefulness function(s) based on sum-of-squared-errors in usefulness, instead of a simple count of commas matched, will not be useful. Assignments like those above will skew the result in ways that are not meaningful.
I see that reverting to a simple count solves the problem because we can then simply "shave off" the 32 or so of the commas which were chosen for reasons other than purely their usefulness.
But I lament that by reverting to a simple count we'd lose some valuable differentiating detail on the results. Couldn't we continue using sum of squares, which is the best measuring technique we've thus far developed, but exclude these 32 commas from the data set we run against?
Short answer: I'm okay with that. Though...I want to remind us of what we're doing here. The most pressing need at present, is a metric for choosing commas (and/or metacommas) for tina accents. I don't think either of the above numbered reasons are likely to occur in the case of candidate commas for tina accents. So I say the above usefulness metric is Good Enough™ and we should just run with it.
- I'll admit I was hoping the best metric would at least have a consistent expando function for AAS and ATE, if not the same breed of function for the N2D3P9 (to be clear, I hoped for either *ee or *pp, but hopefully even lee or rpp).
- And it does seem like for how much we invested into developing N2D3P9 we could proceed a bit more methodically at this step.
- And I'd like to give a day for others who have been active on this topic to weigh in.
- And I would like to at least hear your thoughts on my suggestion to eschew particular commas from the data set so we can stay in sos-mode rather than revert to boolean-mode.
- Or perhaps you'd like me to use my sum-of-squares ability to perfect parameter values in that vicinity. It'd be nice if we could find some psychologically motivated round-ish numbers for everything, like we did for N2D3P9.