Dave Keenan wrote: ↑Tue Jul 28, 2020 9:05 am
The "k" entry is `text{sopfr}` where `k` = 0.7901235.
The "j" entry is `text{sopfr}` where `j` = 1.0954774 and is an exponent.
At first, this made no sense to me. "sopfr" is sopfr(nd). Where could a "k" or a "j" go? Exponent of what? But I had only just woken up.
Eventually I figured out that you probably mean:
Name | Description |
k | sopfr(n) + k × sopfr(d), where sopfr(n) ≥ sopfr(d) |
j | (sopfr(n)) j + sopfr(d)), where sopfr(n) ≥ sopfr(d) |
Is that correct? If so, under my naming scheme they should be called ks and js, where the trailing s indicates that numinator and diminuator are decided by comparing soapfars (which in this case happen to be sopfrs).
No, that's not what I meant. I meant:
Name | Description |
k | sopfr(n) + k × sopfr(d), where n ≥ d |
j | (sopfr(n)) j + sopfr(d)), where n ≥ d |
I was aware of your new usage for 's' in these names and understood that if that's what I meant I should have called them `ks` and `js`.
It's clear we have some different assumptions/intuitions about stuff sometimes. I thought it would be clear enough what I meant by `text{sopfr}` with a k, because in my world, `text{sopfr}` in a sense always has a potential `k` or `j` in it, and when you don't acknowledge them, they're essentially both set at 1. Sorry for the confusion!
(I wrote the above before you submitted your latest post where you figured out what I meant for yourself. I'm keeping it here anyway.)
Doing this task has made me realize that it does not support recognizing `text{wyb}` as 7 chunks. It'd consider it an 8-chunk metric.
To me, it's at most 5 chunks, as described here:
viewtopic.php?p=2054#p2054
$$\text{wyb_metric}(n,d) = \sum_{p=5}^{p_{max}} \big((\operatorname{lb}{p}+w){n_p}^y + (\operatorname{lb}p+b){d_p}^y)\big), \text{where }n>=d$$
$$y=0.865618551, w=-1.472615144, b=-2.02634047, \text{ gives } SoS=0.006057649$$
Hm, okay, let's set aside the struggle between 7 and 8 chunks which is only in the domain of my implementation, and focus here on the difference in your and my conceptualization of this metric, and determine what constitutes the difference between your 5 chunks and my 7 chunks. My 7 chunks are:
- the soapfar term
- the sompfar term
- lb
- w
- b
- y
- ...I'm not sure. I did come up with that 7 number right when I woke up I suspect I may have thrown one in for whatever the `m`'s value was, under the assumption it was that thing you used at some point which halved all values totaled but only for the 5 term of the monzos or something. But I think I see now that may be calling it `text{sompfar}` just to underscore the fact that it uses a different `w` (called `b`) than the `w` the `text{soapfar}` uses.
And so if the "m" in `text{sompfar}` doesn't mean anything functionally different, then I do agree with your 5 chunk conceptualization. I'll go back and correct it in your table in the recent post.
Heh. This exchange brings to light another shortcoming with my code which I'll need to address in order for it to recognize this as 5 chunk. Unlike the "cross-submetric parameter chunk" problem, however, my code is set up for success against this "when all submetrics are of the same type, that should constitute only 1 chunk" problem. I'll have a fix for it soon.
The points of disagreement is this: I think that using one submetric on `n` and another on `d` feels like a single chunk of complexity; however, my code can only realize this as the first submetric adding a chunk (`k` = 0) to zero out its `d`, and the other adding a chunk (`j` = 0) to zero out its `n`. Unfortunately, a "cross-submetric parameter chunk" such as this would add a surprising amount of complexity to the code, which I'm not convinced is worth it.
All that shows is that you made a poor decision in how your code is structured.
Perhaps so. Yup. I think this pain could be summed up like this: I started building the solver before we recognized that chunks were going to be of such utmost importance. Had I built the thing chunk-first, it may have been no problem. However, I built the thing the simplest way I could manage to achieve the different parameters we were discussing, without recognizing at that time that we'd reach a place where I'd want to run a big automatic script
for a given chunk count to tell us the best metric possible for that chunk count, rather than it being okay to just compute the chunk count per metric after the fact.
My gut says that using different submetrics on `n` and `d` feels psychoacoustically unmotivated.
Remember that n and d are not numerator and denominator, but big side and small side, when compared either directly, or after the application of some soapfar function (where such indirection should count as a chunk). Treating n and d differently is absolutely essential if we are to account for 35/1 being less popular than 7/5. To me, even sopfr(n) + k × sopfr(d) is applying different submetrics to n and d. You may recall my
earlier reaction to what, to me, continues to seem a strange definition of "submetric" on your part, and is the cause of your difficulty in implementing wyb.
I agree that treating `n` and `d` separately is necessary. Can we also agree that, whatever we call things (submetrics or otherwise) that there is a line — however fuzzy it may be — between metrics which treat `n` and `d` differently in a psychoacoustically justifiable way, and metrics which treat `n` and `d` differently in an artificial way?
I'll also say that if `text{sompfar}` is simply a different `w` and not functionally different, then that is well within my tolerance for a psychoacoustically justifiable difference in the treatment of `n` and `d`. Had it been that weird half-5 trickery, or a completely different thing like `text{gpf}`, then I'd've continued to push back.