Thank you VQC. Following so far.
>Why are there gaps?
Horizontal Gaps:
There is a repeating pattern of gaps as you move horizontally from (0, n) to the right.
The pattern of gaps repeats every 2n if n is even.
The pattern of gaps repeats every n if n is odd.
Example:
(0,5) =
(0, 5) | (1, 5) | GAP | GAP | (4, 5)
(5, 5) | (6, 5) | GAP | GAP | (9, 5)
(10, 5) | (11, 5) | GAP | GAP | (14, 5)
(0,4) =>
(0,4) | GAP | GAP | GAP
(4,4) | GAP | GAP | (7,4)
(8,4) | GAP | GAP | GAP
(12,4)| GAP | GAP | (15,4)
Vertical Gaps:
A cell will not be empty if it is listed in the set of any a in any cell above it.
Put another way, for any cell p0 = (p0.e, p0.n) one can find a cell p1 = (p0.e, p0.a) where n is listed in the set of a's.
I dont know how to relate this more generally though.
Example, for cell (2, 1):
the set of all a's for t=0 -10:
[1, 3, 9, 19, 33, 51, 73, 99, 129, 163]
The cells (2, 3), (2, 9), (2, 19), etc will all be non-empty.
Subsequently the list of all a's at each of these cells will also be non-empty at (2, a) (tree pattern).
actually, this doesn't work everywhere… my previous post still holds though.
The input is n.
I'm going from e=0, and incrementing each time.
And I'm printing out Y or N based on whether the cell at (e, n) is empty or not.
I put a newline at every n if n is odd, or every 2n if n is even.
The columns of Y's and N's repeat :)
Well, there's a pattern, I'm sure VQC already knows the exact formula, but I can't get it just yet.
I've noticed that Y is always in the first and last column.
Which columns in between that and why are still uncertain to me.
Any thoughts?
I've shared quite a bit of code via pastebins in the previous threads, you can recreate everything i have produced. Let me know if you find a pattern or formula!
I'm currently switching gears to give a visualization of the vertical gaps, should be done in 15 mins (will be text visualization again because i'm lazy).
Does everyone here have nodejs installed?
My beloved Javascript!!!
I have a very simple reason for using it over anything else. It is the fastest for me to trial an idea.
I've used many languages over the years, and really it comes down to python or js for me for simplicity of syntax vs power.
The only reason JS wins out is because of npm. I dont have to fuss about with virtualenv or worry about silly dependencies. Its all nice and clean, just share your package.json.
See my original code pastebins here:
https:/ /pastebin.com/jf5Vqax5
Look for the createTE method in db.js. Thats the main method missing from my code screenshot before. Ive made a fair number of changes of my code today in preparation for the new formula and algorithms to come in the next week, (getting it ready to share) but the createTE method hasn't changed.
Also, this method works to generate any cell (e, 1, t), without iteration, but with calculation.
https:/ /pastebin.com/tP36ypZB
I'm moderately proud of this one. Hopefully I can make it generate any cell e,n,t soon.
Yep, exactly, a tree. Also, at each corresponding records in the tree that you've observed, the x's are the same.
Unfortunately, this is not the complete pattern.
It works for e < 9 and e = 10, and some other values, but not for most large e.
It is still true for that all the cells will be non-empty, but others will also be non-empty, (look at e=9).
See images. Sorry for small font. The first is e=3, the second is e=9.
For c instead of e, n, t:
function calcGenesisCellC(c) {
return calcGenesisCell(c-Math.pow(Math.floor(Math.sqrt(c)), 2));
}
You can move forwards or backwards through the tree at any point.
Move backwards by following a (at t=1) to (e, a).
Move forwards by following a or b at any t when a or b are bigger than n for some t.
Each way through this tree, x will be the same.
I posted an example back in RSA #3 I think.
My trick is to always use a depth parameter when doing recursion, then you can format a prefix string.
Also, for those who choose to follow the JS path, I've got a BigInteger library selected, and a sqrt function tested for when we get big:
https:/ /pastebin.com/y8AXtFFr
Sure, I'm sorry for being so brief.
If you look at e=9.
Get the list of a's for n=1:
(9,1) =5, 9, 17, 29, 45, 65, 89, 117, 149, 185, 225
Follow each of those to (9, a):
(9, 5), (9, 9), (9, 17), etc
These will all be non-empty.
However, look at (9,3). It is also non-empty.
Following the rules above will never lead to (9,3).
So there must be more to it.
Does that make sense?
Another example:
e=14, n=1, set of a's = [7, 9, 15, 25, 39, 57, 79, 105, 135, 169, 207]
You can follow the tree all the way down for each of those a's.
Goto (14, a) for each a, and it'll be non-empty, and you can repeat for the list of a's there, and so on and so forth.
However, (14,3) is also non-empty, and it is not in the set of a's starting from n=1. You'll never reach (14,3) using the method above.
Actually, hmmm….
My theory can't be true, maybe its just 3 for even and odd? I'm not sure. I'll look into it though.
Thanks!
I'm finding that some "chains" ie following the tree of a's takes a long time to loop back to previous elements, but i think it ultimately might.
I just realized a condition in my code that could be causing me to not find (9,3)… I'm going to try something real quick!
Good idea, if you want to choose an example, I'll follow along.
I have a function for generating the cells at (e,1,t).
In order to test this, I'll need a function for generating (e,2,t) and (e,3,t).
If we can do that, I can climb the trees easily.
Some variables are easier than others, and I believe we can get away with hardcoding some values for now.
I think the tough one will be d.
Any help in figuring out an equation for d given e, and t, when n=2, and separately for n=3?
I've tested a few theories for the 2 tree hypothesis, and I've had no luck.
My testing shows that even growing 4 trees from (e,1), (e,2), (e,3) and (e, sqrt(e)), the list of differences grows over time.
I think this implies that there's is clearly more to the vertical gaps than just following the tree of a's. There's more to it, just can't see how.
Thinking a little ahead…
VQC was saying that he'd show us how to build a virtual quantum computer.
I've been trying to keep this in mind while reviewing the grid.
My thoughts on this are that we can generalize the process we've used here to pretty much any np problem. The process?
Generally speaking, what we've done is instead of traditionally using a piece of input information and searching for an answer through a large set, we've calculated many examples of the set, and are using information about the relationship of the input and output to find "intermediary" relationships.
In our case, c is the input, and normally we'd check for factors of c by iterating from 2 to sqrt(c), dividing and checking for a remainder. We can improve by only checking the primes.
But in the grid version, we're using additional relationships between c and the factors a & b (e,x,d,n and t).
Some of these relationships are "constant" like e and d. And ordinarily we can imagine that when using an iterative model, we would expect these relationships to occur as we iterate, represented by t in the grid.
So, we're figuring out the calculations and relations relative to t, time of a turing machine.
Using this, if we model the relationships of variables correctly (maybe via machine learning?) we can find out all variables in a given system relative to time, hence we can "fast forward" time.
Does any of that make sense, or am I crazy now?
I agree with everything you said.
I'm excited about the possibilities. Free/cheap energy really excites me.
I'd love to pursue a life off the grid, try to live self sustained. Free energy devices would be great for that.
I think efficient travel would change everything. Imagine living in Australia and working in China.
Not to mention health tech…
Ramanujan was one of my fav's of all time.
I was stronger with numbers when I was younger, my parents used to force me to study but they never checked what i was studying, so I only read my math textbook.
I have an older sibling, so I'd steal their math textbook and read it when I was done with mine.
I used to try to imagine I was Ramanujan and "knew every number personally", although I realized in college that other were far more gifted in math than I was, so I focused on computers instead.
But I've always been deeply envious of those who continue to hold strong relationships with numerals.
I've got an output of the change in x for (e,n).
https:/ /pastebin.com/VGeUupHR
What you see here is [e,n] =x0, x1-x0, x2-x1, x3-x2, etc, etc.
We're increasing e by 2n.
x remains the same
d increases by 1.
a increases by 1.
b increases by 1.
So geometrically, if hold x and n steady, (the small square), and we increase d by 1:
(looking at the image on the right)
a will have to increase by one.
and so will b, since n is halfway between them.
and the difference will be 2 lots of n, which we add to e (see the little black boxes in the image).
>Any thoughts to the movement I noticed in x where n > 1?
I'm trying to work this out too. I mapped all the x_deltas for all (e,n), where the first entry is x at t=1.
https:/ /pastebin.com/VGeUupHR
They're clearly all divisible by 2.
And the deltas are always in groups of 2 and no more.
And the delta x pattern repeats for a given n, as e increases. I think the number of elements before repeating seems related to root n.
For your x calcs, instead of calculating the total change, what about calculating the midpoint between the two, and the distance?
The difference between x as t increases.
Find any given cell, calculate:
x0 = x at t = 0
x1 = x at t = 1
etc
calculate:
x1-x0, x1-x2, x2-x3, etc
You'll either get the same number again and again, or repeating 2 numbers.
The x0 and x_delta set (the numbers above) for all e,n are here:
https:/ /pastebin.com/VGeUupHR
I'm dumb, don't mind me, disregard my last statement.
Here's another pastebin with more info on the first element (t=0) per (e,n) and just the 2 deltas, their midpoint and distance from the midpoint (diff).
https:/ /pastebin.com/R3pd10f1
Ok, I think I have something here…
Use this pastebin: https:/ /pastebin.com/R3pd10f1
Pick any cell (e,n)
If n is even:
If e is a multiple of n, the midpoint is n.
If e + 1 is a multiple of n, and n is even, the midpoint is n/4.
Otherwise it's n/2.
If n is odd:
If e is a multiple of n, the midpoint is 2n.
Otherwise it's n.
I think this works for most cells. Please help me confirm!
Also, one more thing…
You might be right. I think I'm slightly off with the equations, but make sure to use the pastebin, the midpoint i'm referring to is only on that paste.
I think I have more insight into the horizontal gaps.
For a given n, moving right, you'll find cells filled if it is a multiple of n - a square number!
Example:
n=7
so you'll find e can equal:
0, 7, 14, 21, etc
As well as
7-1, 14-1, 21-1, etc
7-4, 14-4, 21-4, etc
14-9, 21-9, etc
21-16 etc
Definitely. Its a great film, although the creator is trying to link it to the Russia fake news, I think probably just to sell more tickets though.
Ok all, I'm off to bed!
Great progress tonight, see you all tomorrow.
>There are quite a number of e records where (e,2) and (e,3) exist, but aren't in the root (e,1) key.
How about this pattern here, for e=1, the list of a's are:
(1,1) =1, 5, 13, 25, 41, 61, 85, 113, 145, 181
= (0^2 + 1^2), (1^2 + 2^2), (2^2 + 3^2), (3^2 + 4^2), etc
= (t-1)^2 + t^2
(1,5) =1, 5, 17, 29, 53, 73, 109, 137, 185, 221
= (0^2 + 1^2), (1^2 + 2^2), (1^2 + 4^2), (2^2 + 5^2), (4^2 + 7^2), (3^2 + 8^2) etc
= pattern every 2 recs
(1,13) =1, 17, 37, 85, 125, 205, 265, 377
= (0^2 + 1^2), (1^2 + 4^2), (1^2 + 6^2), (2^2 + 9^2), (2^2 + 11^2), (3^2 + 13^2) etc
= pattern every 2 recs
>Odd values of e:
>small square (x+n)^2 = (2t)^2
>large square (d+n)^2 = (2 * ( (t+1)*(t+1) - 2 * (t + 1) + 2 ) + ( ( e / 2 ) - 1 ) )^2
>Even values of e:
>small square (x+n)^2 = (2t-1)^2
>large square (d+n)^2 = (2 * ( (t*t) - t + 1 ) + ( ( e / 2 ) - 1 ) )^2
I'm currently trying to confirm that the above equations is equal to the below equations, I think so, so far, will confirm in a few with a proof.
>if (e is even) (d + n)^2 = (2t)^2 + c
>if (e is odd) (d + n)^2 = (2t - 1)^2 + c
>if (e is even) (x + n)^2 = (2t)^2
>if (e is odd) (x + n)^2 = (2t - 1)^2
Actually, I'm not sure either of these sets of equations are correct.
For the first one, we can see that for odd values of e, the area of the small square should be (2t)^2. And the claim is that it works everywhere.
However, (2t)^2 is constant for a given t, eg, t=1, (2t)^2 = 4.
So if this were to work in every cell, then the first (x+n) should = 2 for every cell. Which is clearly not the case.
This equation works fine for n=1 though.
As for the second set of equations, as VA just stated, these work for n=1. Unfortunately that's where they end.
So for n=1, I believe these both state the same thing. For n 1, I'd imagine we'd need to factor in the n parameter when calculating values, somehow.
Well, as you already are aware, qubits are programmed by pairing (or coupling) states of a qubit to another. Q1 == Q2 or Q1 != Q2.
Take a look at digital logic circuits. With this qubit configuration, you can practically code an entire digital logic gate to test all paths simultaneously.
If you were to program a quantum computer to factor a number into its primes, it could do this in constant time (DWave achieved this with quantum annealing, factoring 21 into 7 and 3).
Looking at these "paths" were able to understand the factorization "progress" in terms of time, t.
My understanding is that were using integer factorization as an example. The intermediary variables (e,n,d,x) are like the qubit configuration, and t is time.
So (guessing with this part) essentially what were doing is "simulating how a quantum computer would solve integer factorization", by calculating all variables in terms of t.
Does that make more sense?
Just got off the phone, I was super excited when I read it and yes, I'll look at it now.
As far as I'm aware, the only working quantum computers right now are the quantum annealing machines from DWave.
Here are their explanation videos, good educational material:
https:/ /www.youtube.com/watch?v=zvfkXjzzYOo&list=PLPvKnT7dgEsvVQwGgrlUVXBa2J6PAW8a4
Please let me know if I'm wrong with that above statement, I know there's a lot of theory out there but as far as I'm aware they're the only ones with working machines in production.
Ok, finished reading, and understanding your claims, I'm going to write a test harness for it.
If this is true… this could be big!!
I hope we're not just reproving stuff.
Great work PMA!
>From: (1,53,12) is the prime solution record we are looking for where a=5 and b=157.
>To: (1,5,12) is the record created by variables e,n,x where n=(1,53,12).a and x=(1,53,12).x.
I'm following through your example.
Are the t values correct?
Instead of (1,53,12), I get (1,53,1).
And instead of (1,5,12) I get (1,5,5).
Am i missing something?
I understand your confusion.
I would suggest going back through all the posts from vqc so far (here and in the rsa 1-4 threads on cbts).
I think this will be your fastest path to learning.
I'm going to continue to focus on the math work, but I welcome any lessons have you along the way.
Yes please :)
The truth is we all are confused.
Imagine how you'd go about trying to code a quantum computer program.
Now, I'm not talking about the online simulators that link qubits etc. I'm talking algorithms.
A regular old computer (turing machine) can only calculate one thing at a time, so you program variables and at any point in time a variable has a value that can be used to calculate the next value.
In a quantum computer, imagine instead expressing relations as a set of simultaneous equations, and now you've defined all variables relative to each other at any time (this is our t variable).
Oh I see, I'll take it! Either way.
"Look and Feel" - well I'll be…
Its been about 6 years since I last touched Java, should be ok though.
Such a tease.
Ok, I think I got the vertical gaps down.
Starting at (e, 1), we already know we can follow each a to (e, a) and the cell will be non-empty.
But for some cells, (eg, n=9) we can follow the a's all day and never get to (9, 3).
But there's one more rule…
We also have to include the set of all n's at any factor of a or b (i believe just at t=1 still have to confirm that bit).
Example:
(32, 1, 1) ={32:1:16:0:16:18}
We expect to find cells n=a=16, and n=b=18 to be non-empty which is true.
But also, 16 can be factored by 2, 4 & 8, so we'll find (32, 2), (32, 4) and (32, 8) will be non-empty.
Also, 18 can be factored by 2,3,6 & 9, so we'll find (32, 3), (32, 6) and (32, 9) non-empty too.
I'm going to try to figure out how to write a test for this.
What's interesting here is that if we're to use this, then we have to factor at least 'a', which is a recursion of the original problem. Could be useful.
Actually…
I think you proved x+a = d…
Both the jump cells have x+n = x+n (never mind the square).
Thats because they both came by following a.
And for the a=1, b=c cell, as well as the answer cell, d is constant.
And we know that d = x+a, so if we follow a, we end up with d = x+n for both cells.
Another thought…
Similar to when we moved horizontally noting that while holding (x+n) constant, and increasing d, e = e+2n.
I've calculated what happens when we increase n by 1.
For a given (e,n), holding d, x and a constant, increment n (n=n+1):
e = e+2a
b = b+2
c = c+2a
Good morning all.
Thank you, I've run your code, looks great, I'm going to try to read and understand your getRecord and getX method, and test them. Great work Baker!
Morning VA, I believe this is correct for n=1. I was up last night when VQC posted, but like you pointed out, I think this is just a continuation of his full explanation, and this is stuff we've been given before.
Still, it helped me a lot to understand the p/t relationship much better!
I'm kinda impressed by Baker's getRecord method… If I can confirm the results, I think this is huge!
Shit, I see… sorry!
Whats the pattern then? Do I increase t each time I move to a new n?
Eg, if I'm at (1,1,7), is t for the (n, a) cell always t+1 ie, 8?
>From Baker's (friend's?) code:
public class VQC {
public static BigInteger negOne = new BigInteger("-1");
public static BigInteger zero = BigInteger.ZERO;
public static BigInteger one = BigInteger.ONE;
public static BigInteger two = BigInteger.valueOf(2);
public VQCElement getRecord(BigInteger e, BigInteger n, BigInteger t) {
VQCElement v = new VQCElement();
try {
v.e = e;
v.n = n;
v.t = t;
v.x = getX(e, t);
v.a = (v.x.pow(2)).add(e).divide(two.multiply(v.n));
v.d = v.a.add(v.x);
v.b = v.a.add(two.multiply(v.x)).add(two.multiply(v.n));
v.c = v.a.multiply(v.b);
} catch (ArithmeticException ae) {
v.isInvalid = true;
}
return v;
}
public BigInteger getX(BigInteger e, BigInteger t) {
BigInteger subtrahend = one;
if ((e.and(one)).equals(zero)) subtrahend = two;
return two.multiply(t).subtract(subtrahend);
}
}
>My js version, (no big ints yet):
function getRecord(e, n, t) {
var v = {};
try {
v.e = e;
v.n = n;
v.t = t;
v.x = getX(e, t);
v.a = (Math.pow(v.x, 2) + e) / (2 * v.n);
v.d = v.a + v.x;
v.b = v.a + (2 * v.x) + (2 *v.n);
v.c = v.a * v.b;
} catch (e) {
v.isInvalid = true;
}
return v;
}
function getX(e, t) {
var subtrahend = 1;
if ((e%2) == 0){
subtrahend = 2;
}
return (2 * t) - subtrahend;
}
FYI, that ent function doesn't work for n>1 yet.
Although the latest function posted by Baker's Friend (BF?) does work for all n.
The one last thing we're trying to figure out is the seed t value for a given n.
Looks like we're actually using this equation already. The only problem with the getRecord function is actually producing the correct t record given e,n & t.
The output we get is incorrect corresponding to the grid, however by increasing t, we'll get to the rec in the grid for some t. So all the equations "work" except t is "seeded" incorrectly.
Ok, here's my thoughts.
Starting at (e,1) you can move forward through t.
At any point, you can jump to (e, a), and t will begin wherever you were before.
So the mistake I've been making is considering all cells start at t=1.
They don't.
They're a tree.
From each t in (e,1, t), you can branch to (e,1,t+1), or (e,a,t), or (e,b,t).
Combine this with the factor p of a at t, and I think we have the full answer here.
Just gotta put it all together.
We can walk up the tree and down the tree.
I'm sorry, you're right. I see that now.
Looking at (3,13), using the getRecord method, the rows in the grid occur for:
t=4 to start, then 10, 17, 23, 30, 36, 43…
eg, t=4 (which follows from a), then t increases by 6,7,6,7,6,7…
6+7 = 13 = e
Confirming this pattern for other cells now.
Hi all, just got home, getting caught up on the thread now.
A couple of pics for you. I reiterate though, I don't condone the man's actions.
Nice work PMA.
I think you're close man.
Thanks VA, I was examining the 0 column earlier today, but I had to go to work.
Back at it again now, I think its a useful tip.
We're increasing our d by 1.
Start there.
The d = floor_sqrt(c), so (d+1) * (d+1) is a square slightly bigger than our c.
But we're fixing a and b, and hence c, so because of that, our e has to decrease by the difference of the square d^2 and (d+1)^2.
There's something wrong with this.
Not sure exactly what, but a=5, b=7 doesn't work.
Certainly there is a relationship between n and x, in that n is a multiple of x.
So close Chris! I can taste it!
>If c is an integer, particularly an integer that is the product of two different primes, where the c squared appear in COLUMN ZERO. How many times does it appear? What are the patterns of these appearances?
It appears 3 times, (0,0,c).
Then where a=ca, b=b
And b=cb, a=a
>How do you USE the Row and Column to find what you need?
I'm not sure!!!!
Trying to put it all together now man!
The incorrect assumption was that x=n.
x is a factor of n, as is a.
This the row movement in column zero.
Oh, and 1xc^2… so four times?
Morning all.
Here's where I got to last night focusing on the 0 col, and changes to x & n:
X can only be even, since we need to split x^2 into 2 lots of an.
Each time we increment x by 2:
c = c - (4 * (x+1));
And increasing n by 1, increases c:
c = c + 2*d
Since increasing x decreases c, and increasing n increases c, if c is constant, there will be some multiple of:
-
(4 * (x+1))
will equal a multiple of 2d.
I can't make sense of how to use the row and column! Any progress PMA?
Here's a list of the 100 first primes * the 100 first primes (except squares).
Included in the paste is the cells:
a=1, b=c (starting cell)
a=a, b=b (answer cell)
a=c, b=c (0 column c*c)
a=a, b=cb (0 column 2nd occurrence)
a=ca, b=b (0 column 3rd occurrence)
a=1, b=cc (0 column 4th occurrence)
https:/ /pastebin.com/DMb1j5z7
Evening all - just checking in now, getting caught up.
Thank you for establishing and fostering this community.
PMA have you taken a look at the 0 col for:
a=ca, b=b
a=a, b=ca
There are many interesting relationships. I'm trying to figure it out and write it up at the same time.
But there's a relationship from one row to the other, where the in the first occurence:
x = b(a-1)
and in the 2nd:
x = a(b-1)
I haven't fully figured it out, but have you put any cycles there yet?
Shit, Teach here… forgot the name field…
I somewhat explained the first record wrong.
a=b, b=ca. Its the same thing, just the other way around.
I get the following rows:
65 = 5 * 13
1 x c {"c":65,"e":1,"n":25,"d":8,"x":7,"a":1,"b":65,"t":4}
a x b {"c":65,"e":1,"n":1,"d":8,"x":3,"a":5,"b":13,"t":2}
c x c {"c":4225,"e":0,"n":0,"d":65,"x":0,"a":65,"b":65,"t":1}
a x cb {"c":4225,"e":0,"n":360,"d":65,"x":60,"a":5,"b":845,"t":31}
b x ca {"c":4225,"e":0,"n":104,"d":65,"x":52,"a":13,"b":325,"t":27}
1 x cc {"c":4225,"e":0,"n":2048,"d":65,"x":64,"a":1,"b":4225,"t":33}
For e=0, a=ca, b=b, or e=0, b=cb,
D is known, as is e (0).
I'm trying to relate the 4 variables left (a, b, n, x).
I have n is always a multiple of x.
I think we can say that n = (a((b-1)^2))/2 or (b((a-1)^2))/2 for those rows.
Thats where I'm at.
I agree, I enjoy it here.
There's a lot of noise still in the community (non-math stuff) but I enjoy it. I like the active feeling and I like seeing that there's a new post, regardless of what its about.
Trying to explain it geometrically:
These are some very useful relationships.
When making a difference of 2 squares for a number c*c, we're making a big square, c by c (in our case c = d).
If c is actually ab, then the cc square could be divided up by aa squares of size bb, or bb squares of size aa.
When trying to make a difference of 2 squares, where x is not 0, we are heavily restricted in this choice if a and b are prime.
As we increase x, we are "eating away" at c*c, we have to make up for this, by increasing n.
If we just focus on the smaller squares inside cc (of size aa or b*b), there's only 1 choice.
We have to choose x such that it is equal to a *
(b-1).
b-1 will always be even, and when we use the small squares that we've taken away via x, we build them up via increasing n, half on the side, half on the top.
We need to guarantee that the small squares taken away = the small squares added. And that will always be true for the largest even square (b-1) times the other prime a.
I know I'm not doing a good job of explaining it.
My big question is how do i use row and column in the process of finding the answer.
Saved!
Julian is a hero of mine too.
I love these old photos, these men on both sides were our family. Its our history!
Every time I try to solve these things simultaneously I end up proving what is known.
I think I want to go back over all of VQC's posts and try to gather every single equation into one spot again.
This thread is almost at limit. I don't feel confident enough to bake, but I can certainly help collect and surmise.
In the Q threads, they had a summary in the form question/answer. Maybe we can attempt something like that.