Dave Keenan wrote: ↑Sat Aug 01, 2020 6:06 pm
Currently the four which can take these forms are a, j, k, and the total weight on a submetric (like how we'd sometimes weight `text{copfr}` by `c`). I don't currently allow this, but there's no particular reason not to (it just seemed really unlikely that a winning metric would call for more than one of a base, an exponent, or a coefficient in the same position).

You don't currently allow what? A total weight on a submetric? Or locking to 2, any parameter that is a log base?

Sorry for the pronoun abuse. Neither of your two guesses are correct. What I said "I don't currently allow this", the "this" was referring to "allow [a parameter's] coexistence with its variant as a coefficient."

curmudgeon, cmloegcmluin

This juxtaposition is suitable, since apparently the etymology of curmudgeon is unknown! Maybe in 500 years people will call each other cmloegcmluins and there'll be no evidence why

But I meant I still wanted to be able to ask questions about a metric with in the form with a base not equal to 2 if it was convenient or historical.

I don't understand how, in this application, a base other than 2 might be historical or more convenient.

Well, I do keep one file in the repo which is a historical record of every metric of interest we've proposed, and some of them have non-2 bases, and I'm trying to stay backwards compatible with those. And I've got valuable example metrics all over the tests which involve non-2 bases. That's all I mean. It's for my convenience.

Or if someone popped up on the thread with a 0.0039 SoS metric which involved a non-2 base and I wanted to check it immediately without undoing a bunch of changes to the code. That's all I mean: I think it's valuable to maintain the code's ability at all to work with non-2 bases. I think if I could just articulate it well there'd be no argument.

And as I mentioned before, I have now limited the solver to running only with bases equal to 2.

Whether a is 4/3 or 2, it's still a chunk to me.

Why isn't setting a=2 analogous to setting k = 1, and therefore not counting as a chunk? When it was 4/3, that was the value of a variable, the optimal value found by your search.

I'm afraid I don't follow your thought here at all, but maybe that's just a negative result of this inline format. Perhaps we'll resolve our confusion inside another one of these inline sections.

I would not characterize "convert log_{(4/3)} to lb by multiplying j and k" as involving "trade a for k". I would characterize it as involving "newly require k".

I'm not talking about changing `a` from 4/3 to 2. I'm talking about eliminating `a` entirely, by changing from a two-argument `log` function to a single-argument `\text{lb}` function. You are treating `a` as a variable, so `log_ap` is a function of two arguments, 'a' and 'p'. In Excel it is even written as log(p,a). I'm using `k×\text{lb}(p)` where `\text{lb}` is a function of a single argument, `p` and so overall, `k×\text{lb}(p)` is also a function of two arguments. They both contribute two chunks, one of which is a model parameter, the other of which is some kind of log function.

I agree that `log_a(p)` is a 2-argument function of `a` and `p` and that `text{lb}(p)` is a 1-argument function of `p`. I also agree that they are both the same number of chunks of complexity to explain, because under the hood `text{lb}` is of course `log_2(p)`. Where we disagree is on how many chunks each of these functions represents. You think two, I think one.

My case for one chunk is this: while applying `a` as a logarithmic base takes a bit more ink than applying it as a coefficient or exponent, it is no more complex. For example, we don't count `y=0.85` as 2 chunks (one chunk for using the exponentiation function, and one for the argument 0.85). To me, an atomic chunk involves at least two subatomic particles: a value, and an application.

I guess I've become used to thinking of soapfr as a type of sopfr, as that's how it is in my code.

OK. I think the opposite. There's only one sopfr function. I think of sopfr as one kind of soapfr, namely the special case where ap = p.

I meant to have said more here but forgot to, and what I meant to say more about was exactly this. I completely agree with your reasoning that sopfr is a kind of soapfr.

It will probably not surprise you that often in object oriented programming, a child type inherits from a parent type and then extends it with new functionality. That's how it is in my code, roughly: soapfr inherits from sopfr and extends it. So in the code it makes more sense to say soapfr is a type of sopfr. Although to us outside the code, it does make more sense to say soapfr is a more general case and sopfr a more specific case, therefore sopfr is a type of soapfar.

And again, I think of it as one soapfar, not two, and will probably not easily be able to break that conception.

I can live with that, provided it doesn't make you count chunks where there aren't any, as you initially did with wyb.

The extra 2 chunks I initially counted for wyb were both due to my mcompfr vs sompfar (or whatever) confusion (per:

viewtopic.php?p=2096#p2096 if we need the reference)

There does still remain the issue where I can only realize wyb as two submetrics, one with j=0 and w and the other with k=0 and b, which forces my code to add an extra chunk, but that's my code which is struggling, not me. I know I need to fix this somehow. And I think just this morning a solution finally came to me, so I'll see if I can get to implementing that today.

This is clearly another consequence of me thinking of metrics with things in a form like soapfr(n) + k*soapfr(d) as one thing, not two. In my world, the part of a submetric which applies to n is modified by j, the part of a submetric which applies to d is modified by k, and then the submetric as a whole is modified by a parameter I call "weight".

Thanks for explaining. Of course "weight" is completely redundant when j and k are coefficients (i.e. multipliers), but I understand it might not be redundant when j and k have other roles.

That's exactly correct. It's designed to support balancing submetrics against each other in all possible ways. It may turn out that the best metric involves j and k as coefficients within a submetric to balance n and d but then the submetric as a whole raised to some power to put it in balance with another submetric.

This (and your original formulation of it) looks like 4 chunks to me: lb, gpf, k, l.

No, my original formulation is 3 chunks: log_a, gpf, and j.

I'm sorry, but I don't understand how you can claim that `log_a` is one chunk. To me, every parameter is a chunk and every function other than + - × ÷ is a chunk. `log_a` is not simply a function. It is a function and one of its arguments, which happens to be a model parameter. Perhaps you are being fooled by its visual similarity to `log_2` which

*is* simply a function, as is made clear by writing it as `\text{lb}`.

Hopefully this is addressed by my above statement about the difference between arguments and chunks, and we can come to some agreement on this.

It seems you think applying a value as a logarithmic base adds a chunk of complexity where applying it as a coefficient does not. I would be curious, if you do maintain that position, whether applying it as an exponent counts as 1 or 2.

If I must go on, + - × ÷ are all functions too. If I'm understanding your perspective correctly, you would say the function +7 has two chunks of complexity: one for the + itself, and one for the 7; however the function called "increment" which is equivalent to +1 would have only chunk of complexity, since it assumes 1 is the added value. Why couldn't I just name a new function "sevencrement" or whatever which does +7 and then say voila it's only 1 chunk of complexity? Or, to circle back to the lb vs log(4/3) issue, why couldn't I just name a new function l走 which is equivalent to log(4/3) and say that it's now 1 chunk instead of 2? This seems obviously silly to me, so I'm beginning to worry there's just something I profoundly fail to understand about logarithms in particular which circumvents this sort of reasoning.

Another way I might argue this case is from the other direction. Does "7" by itself count as a chunk of complexity, introduced to a metric, but without any application yet? I don't think so. I don't think these values can stand alone.

Now if there ever was a function which had an optional argument, I would say that providing that optional argument would count as an extra chunk. But the base for a logarithmic function is not optional. A logarithm has no existence without a value for its base. Same thing with the addition function and its addend, or the exponentiation function and its exponent.