Dave Keenan wrote: ↑Tue Nov 03, 2020 5:49 pm
Darn! I can't open the champagne yet. There are problems...
NBD. Let's get it right.
Dave Keenan wrote: ↑Tue Nov 03, 2020 7:01 pm
Part of the problem with
LPEI = lb(N2D3P9) + (AAS / 10)^1.5 + 2^(ATE- 10) + abs(2 * tinavalue - 2 * round(tinavalue))
is probably just a typo/oversight on your part. I expect what you actually computed has the last term as
+ 1.5 * abs(2 * tinavalue - round(2 * tinavalue))
i.e. there's a weight of 1.5 and the second "2 *" goes inside the round(). It might be better written as
+ 1.5 * abs(semitinavalue - round(semitinavalue))
Ugh. This is exactly the kind of fiddly thing that my brain ties itself in knots over. It's so friggin' simple and then I get super frustrated that it's not instantaneous which makes it worse.
Alright, I whipped up a quick spreadsheet to demonstrate why it matters whether the 2* is inside or outside the parentheses. Inside: good. That way you still get a series of consecutive integer results. Outside: bad. Then you only get the even integers.
So, my code definitely has the 2* outside the round, which is bad. My code agrees with what I wrote here. Which I copied and pasted from my previous post
here (guess neither of us caught it then either).
And yet my error calculations agree exactly with those in your spreadsheet, and have agreed since I first laid the code down. I even wrote some unit tests this morning to double-check things to be certain. What could explain this?
Perhaps the difference is that I don't
actually use a round function. Your spreadsheet needed to round some value in order to get the float tina (n.0 or n.5) or integer semitina value it needed, whereas my code just has that tina or semitina value on hand. Back when it was a tina value, I multiplied by 2 in order to get the semitina value, e.g. 3.5 tinas is 7 semitinas. Once we started just thinking and working and coding directly in semitinas, I just starting using the straight semitina value. I hope that explains the confusion away? I guess the only bad scenario would have been if I for some reason had a comma that was 3.501156378 tinas and found its semitina bucket by rounding it to 4 tinas
before multiplying by 2 to get 8 semitinas when it should have been 7 semitinas... yes, that would have been bad. But I could never have been doing that, because I would have already had the 3.5 tina or 7 semitina value handy already.
Currently, working in semitinas, my formula does look like this: 1.5 * abs(semitinavalue - round(semitinavalue)). There's zero trickery to that. It's plain as day. Yes, let's stop thinking about this 2* trickery which unfortunately causes an undue amount of cognitive overhead for me to trust what I'm doing while it's around. Apologies.
or better still
LPEI = lb(N2D3P9) + (AAS / 10)^1.5 + 2^(ATE- 10) + 1.5 * AERR
where N2DP = ...
AAS = ...
ATE = ...
AERR = abs(sizeInSemitinas - round(sizeInSemitinas))
sizeInSemitinas = ...
Yes, at some point we should definitely LaTeX up a pretty looking master formula. This is clearly more your forte than mine.
We need to justify [a version of LPEI] from the extreme level commas alone (with mina error in place of semitina error). It should be a parameterisation of LPEI that matches the maximum number of existing extreme commas (102 out of 123).
So, when you get a chance, would you please:
(a) check that the above set of LPEI parameters, i.e. b = 1.7, s = 1/9.65^1.7, t = 2^-9.65, u = 0.8, do give 102 extreme comma matches (with AERR based on size in minas).
Ok, that makes sense. I wasn't set up to include badness in the usefulness/complexity area of the code, but I hacked something together. And for whatever reason these s and t values don't want to work as you've derived them (it's either an error in your derivation, which is unlikely, or some obnoxious thing I can't see which is wrong in my order of operations and/or JavaScript that I can't identify, which is more likely), but when I just literally transcribe your formula it works (which is how I've been doing it in the occam semitinas script too). And you'll be happy to know that adding that mina error actually improves the situation from a metric score of 21 down to only 18
(b) re-run the metacomma search using this new badness to choose the best comma for each semitina zone (with AERR based on size in semitinas).
In other words, the only changes to the formula are using 0.8 instead of 1.5 for u, 1.7 in place of the other 1.5, and 9.65 in place of both 10's.
I've run it with that configuration, and there's only one difference in the results. For the 7-tina, we now get a tie between the 7/425n and the 143/1715n, each with 12 occams.
The 143/1715n hasn't seen a whole lot of love or attention from us since
@Ash9903b4 included it
in his list of suggestions back in March in the post which kicked this quest off. However, it was
George's original suggestion.
The 7/425n has gotten special attention a couple of times.
Here you prefer it and yet also express an interest in disqualifying it on the basis of tina error (which by the way it does have worse tina error than the 143/1715n). And
here I gave a list of reasons to prefer it:
Re: the 7-tina, I vote for 7:425n:
- made out of the 9, which is the 6 and the 3 which are already in Sagittal
- lowest SoPF>3
- most occurrences in Extreme Precision
- low abs 3 exp
- superparticular
However the first reason should be stricken because you just expressed that we're actually trying to
avoid composing the tinas out of each other at this point, in an effort to reduce redundancy i.e. notate more new 2,3-free classes. Lowest SoPF>3 shouldn't matter (neither should N2D3P9, its successor); we now understand well that the popularity of the pitches directly notated by a tina comma is not as important as those indirectly notated by it via the ultracores the accents will be applied to. I re-read posts before that post, and racked my memory, but I can't figure out what I would have meant by "most occurrences in Extreme Precision". Low abs 3 exp is true but it's not as good as 143/1715n there (
see the table here). And both it and 143/1715n are superparticular, so that's not a differentiating factor.
The 143/1715n is 0-zeta-max consistent, and it is 13-limit where the 7/425n is 17-limit.
I suspect the only reason we didn't choose 143/1715n it back in May was that it didn't have the best SoPF>3.
Perhaps I should invoke the George Was Probably Right Tiebreaker, that we should go with the 143/1715n.
There was one little thing that popped in my head last night though that I just remembered. For our list of 809 best commas per tina zone... we know that there are 21 (well now 18) of those which are not matches for the commas that are actually in Sagittal. When finding the metacommas, I've been doing it against these 18 theoretically best commas, even though those aren't the actual ones the minas would be applying to. Or does it not matter because almost certainly all 18 of those are in the Extreme level? Or even if they weren't, does it make more sense to calculate against the theoretically best ones anyway? It probably barely matters, but just wondered what you thought.