I'm still trying. I'm using the examples posted, but I haven't found anything consistent.
I'm trying to spittball a few ideas. I get the Newtons method idea, using derivatives to find errors and correcting them, but I'm still not 100% on the what the derivatives are. I see the pattern used with regards to D and D2, but I lack an understanding as to why those are considered the derivatives / rate of change.
All in all, I'm trying. I like where it is heading, but I still have work to do.
Right, there might be multiple functions to use for estimates. I'm working now on trying to figure out some. I get that p of t would work, so I'll try to figure out how it would fit in. I figure at best I'll end up with a few bad estimator functions. At least, I assume I'll need more than one, since we got three variables to update (d, n, x).
I've been trying to figure it out without using the tree. I figure that there must be an underlying pattern, but I also figure it might not be necessary to include a tree for that particular solution.
It seems like it's just adjustments being made, but I'm still not understanding the grid.
Got any suggestions for paths to explore? I figure it might be related to the different patterns we know of. "Not Chris, Maybe Still Chris" previously mentioned that we could estimate it by estimating n0 from -f and then calculating the error rate from p of t. I'm wondering now if the patterns in >>9984 is just that.
I was thinking it went something like:
Estimate i, estimate j. Compute then look for error in the new respective e and -f columns. But if we do that, we'll be moving aimlessly, right? So I'm thinking. Use estimate i, estimate j and compute the cell. Use that cell to try and calculate an error rate based on the original e and -f columns.
Although easier said than done.
Excuse me
I'm a big boy and need my energy.
Remember all those squares we made with triangles?
I though about those when I was thinking about a potential fractal.
One though I had, but I only got to play with it a little bit was using the a and b from (e, 1).
Take (1, 1). Every a is 1 + 4 triangles. Arrange them like a square, the middle unit is the 1 and four symmetrical triangles are spread around it. Then add the b which is again 1 + 4 triangles. Ignore the 1 for now then add the b's triangle in an alternating series to the triangle.
You'll end up with a square with "leftovers" (which will be the base of the triangles from b. Or if you wish, ignore the square but look at the triangle.
Not entirely sure how that is a fractal, but that was where my brain was heading to a long time ago.
Note though, since they are seperated by n in (e, 1) the difference between the triangle bases would be quite a lot larger, might be pretty still though.
https://primepatterns.tumblr.com/post/132225816026/riemann-zeta-function-the-iteration-fractal-near
I didn't make, don't give me credit for it. Also I don't know. Maybe, I'd have to figure out how it's made.
But do we stick to our original e and -f, or do we carry on with the new ones? I mean like I said, then we would just aimlessly be moving about wouldn't we?
So our new estimates would be depending on the e and -f, not necessarily origin c? I can see that. If I was given just an e and -f, I could of course generate the correct c (and it should be possible to then solve it too, but that's a bit beyond my knowledge right now). Since (e, -f) are a unique pair.
So we'll bounce the estimates back and forth (e, -f) (or in combination) until we converge on the answer.
Newton's method, gradient descent I guess in the grand scheme it doesn't matter. It's about the error function. It's about how you correct your squares to get closer to the target.
Once you get that part, maybe you'll c i[t].
You know, there are some older hints (suggestions?) that Chris came with. I don't remember the exact details of it, it was a couple of threads ago. I'll see if I can find it.
It was about taking the columns from -f to 0 to create a matrix and then transpose them. Like I said, I don't remember much. There were some people who didn't get it. I figured, instead of transposing it on a variable size, treat each variable as an element and transpose the elements themselves.
Either way, I think it is one of those hints we never really dug into. Who knows, maybe it is relevant now?
Was from thread #14. Didn't see much, just three posts about it, no one seemed to follow up. Neither poster nor us. Guess it might not have been relevant.
Yes. I'm still working hard at it.
Still working on it. Since I lost my 'puter I've had to write a lot of code from scratch. I finished up with some base grid code for big integers and I started thinking about the estimation function. I've been thinking with regards to Newton's method, but I'm still not grasping >>9718, nor have I grasped the patterns in updating i, j in >>9972 >>9973 and >>9974.
At this point I'm pretty ready to start testing with some numbers so I'll try a few estimate functions and see what sticks.
What confuses me about this example is that the correct n = 1 and d exists in (37, 1). So if we are to lookup the d in (e, 1) and if the d exists, we've found the record. So why keep iterating? Which makes me think, this example didn't lookup the elements where d was between d[t]. It uses another way of doing the estimations. c it maybe?
Laws and Relations of D?
But then, the initial estimates for i and j is based on the values i (e, 1) where d is between the elements. So I'm finding this example a bit confusing.