cmloegcmluin wrote: ↑Tue Jun 30, 2020 3:44 pm

You're right, and I should have noticed that. Yes, let's make it w. I can go back and edit my previous post from "d" to "w" too.

Thanks. Please do. I've now edited my "w"s to "c"s where necessary.

I'm not sure what "real" name you're referring to. As soon as we went beyond sopfr and sopf, aren't these all new things without established/"real" names? Or do you mean something else by that?

Something else. By "real" names, I meant names that obey the rules for function names in math expressions, that allow humans to parse them correctly based on purely lexical or syntactic information, not the detailed context-sensitive semantic information that we are only able to use because we grew it ourselves. These rules are similar to the rules for function names in most programming languages, namely that they should consist only of alphabetic characters, or at least should not contain special characters that are themselves function names like √ or brackets like {...}, or subscripts or superscripts except at the end.

These unwieldy names are helpful during the development process. Once we reach the final step of naming these functions nicely for the outside world we can rely a lot more on the descriptions of what exactly the functions do, and reduce the name to something optimized for pronounceability, e.g. "soapfar" for "sum of adjusted prime factors (with) adjusted repetition", or something like that.

Agreed.

It might be cool if we added a plugin to the forum for LaTeX or MathJax. That might help get these formulas across in a less disgusting and/or intimidating way

At this point, I think it would just slow us down. We seem to be communicating with each other just fine. And most of what we've written will represent dead-ends by the time we're finished.

Do you still want me to check those, even though I've since found one with 0.004250806?

No.

Actually, scratch that. I think your method will need to fulfill the role of the "home stretch": finding the exact values down to the millionths place or whatnot. The way I'm doing things, it's not really tractable to look deeper than the thousandths place. So if you're already working with SoS-billionths, I'm not going be able to help you get any more precise.

Not at all. The only reason I'm giving max sig figs for SoS is I'm too lazy to round them, and to give confidence we're computing the same thing. Don't forget that my spreadsheet can't find the true minima of SoS because it has to use a proxy SoS, based on a proxy for the estimated rank (the rank derived from the candidate metric), that does not require actually sorting the ratios based on the metric.

My spreadsheet can get into the right ballpark, but only your code can find the true minimum nearby. I can also find the true SoS for any set of parameters you give me (or for the minimum I find in the proxy SoS), by actually doing the sort. But I can't find where the minimum is in the true SoS.

My proxy to avoid sorting is currently to calculate the estimated rank from the metric using est_rank = m×b

^{metric} +

ℓ, where m, b and

ℓ get included, along with our model parameters α w y c etc, as cells for the Solver to adjust in order to minimise the proxy SoS.

The proxy SoS varies smoothly with the model parameters, while the true SoS is stepped. i.e. it consists of many small flat areas with sudden jumps between them. A jump occurs whenever a parameter change causes the metrics for two different ratios to go past each other (i.e. change their ordering) which causes the two ratios to swap ranks. Because of these flat spots, there is no point in fine-tuning the parameters beyond a certain level.

I can't figure out how that works. Is it using a logarithmic identity I'm not familiar with? I'm interested, certainly, since it seems like you found a way to consolidate the count of primes into their sum.

No logarithmic identity involved.

sopfr(i), where i is an integer, is the weighted sum of the terms in the monzo for i, where each prime has a weight equal to that prime.

copfr(i) is simply the sum of the terms in the monzo. But you could also say that it's the weighted sum where each prime has a weight of 1.

And so you could say that w × copfr(i) is the weighted sum where each prime has a weight of w.

So sopfr(i) + w × copfr(i) is the weighted sum where each prime has a weight of that prime plus w.

So sopfr(i) + w × copfr(i) can be called a soapfr(i) where "ap" stands for "adjusted prime" as you suggested, and the adjustment is p → p + w.

Similarly, we can define solpfr(i) as the weighted sum where the weights are the base-2-logs of the primes. Solpfr(i) is also known as the Tenney height of i.

Then solpfr(i) + w × copfr(i) can be called a soapfr(i) where the adjustment is p → log

_{2}(p) + w.

P.S. I didn't get to try any of the things I mentioned in the

previous message.