This boundary algebra notation from Jeffrey James and William Bricken... I know I've seen this before! Even just the general look of these papers – the font and such. It's driving me nuts. Perhaps one of my pen pals emailed it to me at some point. Or one of my nerdy work friends shared it. All I can think of right now is something I saw a while back about a continuum of operations between addition and multiplication. I'll have to go through these again soon.
In the meantime, here's a Smalltalk quine, on my favorite programming chrestomathy site: http://rosettacode.org/wiki/Quine#Smalltalk
Okay, back on topic...
Do you want me to include the z=1 SoS in the output of my program? It won't make it run much slower.
Every example you give in your table is still sorted the same Can't unsee things as their ranks now. Everything I see is only itself ranked...
Not that this should matter much to you, but: while implementing poapfar it quickly became clear to me that it is not exactly a non-operation. It's `n*d`. And I agree it is not useful to humans, for the reason you said earlier (why not just take the log of everything); I was only introducing it as what I thought would be the least destructive way for my code to recognize that soapfar(n) with ap = lb(p) was a single chunk, since we know soapfar(n) = lb(n). But I had forgotten that I was eliminating the idea of "submetric types" in favor of all defining characteristics of submetrics (whether to use the prime count function, with repetition or not, etc.) being expressed as parameters (such as k, w, a, or whether a is a base or a coefficient, etc.); now that these were both things of the same type, it made it possible to combine the ideas of soapfar and lb as one "chunk". So that was clearly the better way to go.
I can't immediately think of other combinations of parameters/submetrics that can be reduced by humans to single chunks. But if you do think of any, let me know.
Okay, back off topic, sort of...
I had another stray thought while working on the code:
As you know, the code currently supports, for just about every numeric parameter, applying it as a coefficient, base (of a logarithm), or exponent (of a power). It occurs to me that we could imagine applying them in a couple other ways: as bases of powers, or exponents of logarithms. I don't have any particular reason to believe they'd be involved in good fits for the Scala data. But perhaps to be exhaustive we should experiment with them.
It also begs the question: what do we call the fourth type of growth in this analogy:
f(x) = exponential c^x : power x^c :: logarithmic log_c(x) : ???? log_x(c)
There's really a 2x2 matrix here: on one axis, whether the parameter is the base or the exponent; on the other, whether we are powering down (logarithmiation) or powering up (exponentiation). I'm less surprised that powering down is non-commutative, since subtraction and division aren't, but it is interesting to me how powering up isn't, since addition and multiplication are.
And it's kind of interesting that the most common of these two operations – "raising to a power" c, and "taking a logarithm" with base c – are on a diagonal of this matrix from each other. I would wager most people consider those two to be opposites.