Sorry I missed this bit last night in my haste before going to bed (also sorry for letting my haste show in the lack of finesse in the presentation on my previous reply... I just really wanted to wake up to a new message from you, rather than delay us another half-day on this).I think "under the hood" must mean something different to you. To me, in this context, it means "as implemented in library code or hardware".

Yes, I think for me, I had been using the term "under the hood" only to mean "under the icing".

I also think implementations in library code or hardware is irrelevant to chunk count. As it turns out, I think anyway, we both agree that icing is irrelevant to chunk count too. I think what we disagreed over was the parameter vs. constant point.

I understand. That's fine with me. I mean, in the end, I think the plan is to choose one of these metrics, balancing a number of factors including SoS, chunk count, how it looks, etc. which is going to be a pretty subjective decision. So it's probably not that big of a deal if we can't come to an agreement on a single definition of chunk count. Both chunk counts can be presented.Dave Keenan wrote: ↑Mon Aug 03, 2020 9:39 pmI'm sorry, but I really don't want to spend any more time on this, or soon we'll be trying to come up with a metric for comparing the function-complexity metrics that we're using to compare chunk-counting metrics for comparing ratio popularity metrics.

That has to ground out somewhere. The justification for any of these chunk-counting schemes is all pretty vague and arbitrary. I'm happy to admit that they are only intended to be quick and dirty. How about we just have two chunk-count columns. "DK chunk count" and "DB chunk count".

I don't feel like you owe me anything, but I do appreciate that you did a little bit of extra explanation. Unfortunately, we may talking past each other on this particular front. I have no disagreement with the above paragraph. But that's the problem; it fails to address any issue which I thought we were in disagreement about, which means you may not have understood my explanations or questions. I too may have reached my point of exhaustion for explanation and questioning.1. To me, for the purpose of crudely measuring the complexity of a model, the functions log_{2}(x), √x, x^{2}, 2^{x}(where the "2"s are true constants) are boxes with one input and one output, as are x! (factorial), sin(x), cos(x) and tan(x), along with their inverses and their hyperbolic cousins (not that I see any application of them here). For this (model complexity) purpose, it makes no difference to me, that the formercanbe drawn as a box with two inputs (with a "2" feeding into one input) while the latter cannot.

For you and me, all eight of those functions would be 1 chunk, and always had been. What I thought our disagreement was over was counting parameters and true constants. That is, log

_{2}(x) and log

_{a}(x), a = 2.017, where you thought the latter would be 2 chunks while I still considered it to be 1 chunk.

I don't want to drag it out any further, though. I think we understand the nature of the disagreement here, which is enough:

- Your chunk count will count functions in-and-of-themselves, and then count their arguments as a chunk when they are parameters but not when they are true constants, leading to log
_{2}(x) as 1 chunk and log_{a}(x), a = 2.017 as 2 chunks. - My chunk count will count parameters as 1 chunk always, where a parameter chunk is comprised of some value and some function application of that value, leading to log
_{2}(x) as 1 chunk and log_{a}(x), a = 2.017 as 1 chunk.

_{2}or lb at all. One day one of us ran our solver and it came up with stuff with values close to 2 as being good fits for the data. We both said "ah ha, that looks familiar! I think that value is

*trying*to be a 2, and that would make total sense in this domain, so let's just snap it to 2 henceforth" so in that sense we may already have cheated these laws of metric validity by claiming this 2 as a true constant when honestly we found it by solving for it as a parameter. If I got the story wrong, I'm sorry. Hopefully the story is accurate, and hopefully it helps illustrate for you why I don't understand the reasoning underlying your point of view, or if I do understand it, why I disagree with it. But feel no obligation to correct me. We really should move on.

This is a relief to see explicitly. Thank you. I know understand unequivocally that you disagree with me on the issue of bringing mathematical complexity into the decision space at all. I was just guessing at that being your opinion until now.2. It would be perfectly reasonable to treat + and - as 1 chunk, × and ÷ as 2 chunks and power, exponential, root and log as 3 chunks, or some similar scheme. I just don't think such fine resolution is warranted. You might think of me as having taken such a scheme, divided those chunk numbers by 5 and rounded them to the nearest integer.

As I stated before, that's not a road I want to go down, period. So I certainly don't think such fine resolution is warranted either; I'm more of the mind that it's a slippery slope and we shouldn't even start down it. Not even a gesture toward it. You seem to be confident enough to break mathematical functions into 0- and 1- chunk categories.

So your chunk count can factor that it. Mine will not. This will be our second of two points of disagreement over the implementation of chunks: you will give + - × ÷ for free, while I still count them. Or to be more specific (and preventing confusion with respect to the differences in how we see things via the other point of disagreement addressed above), you would count +1 as 0 chunks, because + is free, and 1 is a constant. While I would count +1 as 1 chunk, because it is an application of a value as a function where that value is 1 and the function is addition. And you would count +w, w=-1.88 as 1 chunk, because + is free, and w is a parameter. While I would +w as 1 chunk, because it is an application of a value as a function where that value is -1.88 and the function is addition.