Parallelizing through a meta programming language

The big issue in computing today is how to write programs so the things that can happen in parralel are executed at the same time and solving the problem of what parts of the program are dependent on which other parts to take advantage of today's computers with their multiple processors. 

The way I am thinking of to approach it is to make a meta programming language that takes individual simple programs and has ways of telling the computer which things can be done in parallel and what parts of the meta program depend on the other parts. Here's a diagram:

This meta program consists of 5 smaller programs that are ordered in columns from left to right. Every column further to the right depends on results from one or more programs from a column to its left. Each of these programs has a list of things that it needs to do and the metaprogram handles communication between them. The parralization comes in for instance in function f at the top left. Because it's to do list is an unordered list, the metaprogram will know that all of the things on its to do list can happen at the same time, so it will run in this case 3 simultaneous copies of f doing each of the things on its list. And also anything else in the first column can also happen at the same because programs in that column don't have dependencies as there is nothing further to the left. But h in the bottom left unlike f has an ordered list so those things have to happen sequentially. 

G is an indexed function which consists of multiple copies of the same program waiting on different inputs from the multiple copies of f that run. And j is an example of a program that depends on everything to the left of it and is supposed to sequentially reply back to h to get the next input. The metaprogram would keep track of when j's inputs have all been satisfied and it can be run. This would happen when every copy of g finishes and it's received an input from h. 

The metaprogram could potentially run many times faster than a regular program run sequentially step by step depending on how many processors the system has. 

So now the thing would be to find a good syntax for the meta programming language and write an implementation. I think this is the gist of a good way to approach the problem though. 

Easy way to factor a number or tell whether it's prime

If T is the number you want to factor or know whether it is prime you can repeat this process recursively down until every factor is prime. First find s^2 the largest perfect square less than T. Then check whether this formula:

evaluates to a natural number for any natural number from 1 to s-2.  If it does the number is composite and is (s-a)*(s+f(a)). If it doesn't the number is prime.
For example the number 32 with everything plugged in:

You start with 1 and that evaluates to an integer: 3 so you know that 32=(5-1)*(5+3) or 4*8. We might have had to try 2 and 3 but didn't have to in this case. 

But if you try 31... 

This is never a natural number for n = {1...3} so 31 must be prime. 

*** Todo write out the proof I have it in my head but am trying to find the best way to say it**

Calculating the tail of the Zeta function

The well known Zeta function is this:

I found this function:

as A get's larger this function get's closer and closer to the true value. For instance:

whereas the sum on the left by itself is only:

So the integral appears to be adding very close to the right amount. 

and making A larger...

The integral on the right actually has a definite form (for each value k):

where the Ci function is:

And the gamma constant is:

Now back to the original formula I found:

There is a simple reason why it works... the integral of cos(pi*x)^2 from an integer minus .5 to that integer plus .5 gets closer and closer to 1/2 for larger integers. So a function you multiply it by is made like a discrete sum over the integers divided by 2. It is actually a handy way to convert from a discrete sum to an integral that I'll probably go more into in the future. 

The example for k=3...

So the integral is adding something around .02 and getting a lot of decimal places correct. 

A faster approximation of e

Of course there's this approximation of e:

But the 5 has to be a large number to get very close to e, this next one is faster:

But I found this one that is even faster for just a little more arithmetic:

This one is 3 more digits correct for n=5. 

I looked online for a list of many different possible power series for e but the first two I listed here are the only ones I found so maybe this one is new. I thought of it as kind of a combination of the first two and it seems to work. 

***

A proof of why it converges faster is that the terms inside the parenthesis are actually the Taylor series for the 5th root of e^x centered around x = 0 evaluated at x=1. And since the terms of that series are getting smaller so much faster than  the Taylor series for e^x centered around 0 (because of the 5^i terms in the denominators , less terms must converge to it's limit faster.  Then you raise it to the 5th power to get e. 

The fives in the denominator of the terms in the parenthesis can be increased to any number as long as the exponent on the parenthesis matches, or the series in the parenthesis can be lengthened and still raised to the same power on the parenthesized expression. So since there are two ways to go I'm not sure which is easier to calculate or whether there is a difference in the rate of convergence but maybe I'll look more into it at some point. 

The two classical approaches to calculating e that I first listed can thus both be thought of as special cases of the formula I've found. The first uses the first two terms of the nth root series raised to the nth power, the second uses the first root equation to the power of 1.

**Update**
Actually my professor Dr. Rose recalled a paper he had read by Harlan Brothers and John Knox that discussed different faster approximation's for e and it turns out an improved version of this one I found was found by Harlan Brothers here: http://www.brotherstechnology.com/math/e-formulas.html Formula 25 results from what he calls compressing the series I have here.

T list of a graph

So to create this list T, you first label all nodes of a graph as 1 in the first step. Then in the second step each vertex becomes the sum of it's label in step 1 summed with the label of each node it's connected to in the first graph. Then this process iterates until the number of steps equals the diameter of the graph, which is the max number of edges one has to cross between any two points on the graph. For example the point labeled 43 in the bottom right graph was labeled so because it had a label of 12 in the bottom left graph and it was connected to 16 and 15. 43 = 12+15+16. 

Then the list T is just the value of the vertices listed in increasing order: T={23,36,38,39,40,43,47,55,59,67}

So I believe that isomorphic graphs yield the same list, but I'm conjecturing that the only graphs that produce the same list are isometries. 

But even if this doesn't end up true there is an interesting use for this T list: I can say whatever graph you have and whatever labeling to pick one of the vertices with the lowest value in the T list. Because I believe that if two vertices have the same value in the T list if the graph looks the same from either of those two points... Then this gives a way to distinguish one point on any graph. Or at least one of the points that the rest of the graph looks the same from. So no matter how they have a graph labeled or drawn this gives a way to specify a vertex. 

***

The last thing I said doesn't necessarily apply if you have for instance a graph with two disconnected subgraphs, then you might have two vertices that end up with the same number but the graph doesn't look the same from their two perspectives...

estimating Gauss's circle problem series

Just something I noticed that:

The average of the exterior square's number of grid points and the diagonally set interior square's dots and gridpoints come out close to the number of grid points withing the circle.

For a circle of radius 46 this calculation above is within ~3%, not sure if it stays close indefinitely...

A solution to Gauss's circle problem

This I'll put forward as the solution to Gauss's circle problem, a previously unsolved problem. See:
http://en.wikipedia.org/wiki/Gauss%27s_circle_problem

This formula tells how many integer points are inside or on a boundary of a circle of radius r.

for instance at r = 10 it outputs 317 which is the right answer. 

Basically it adds infinitely tall infinitely narrow functions at all the integer points from 0 to the radius in the y direction. Then integrates from 0 to the height of the circle at x for each x from 1 to the radius. This gives all the integer points within the first quadrant of the circle not counting those on x=0 or y=0 lines. Then that is multiplied by four for the four quadrants and add those on the x=0 or y=0 lines and then 1 for the center point. 

Now, the Dirac function is a logistic function but it can be considered as the limit of:

as s goes to 0. But smaller and smaller values of s can be used to make the answer my formula gives more exact. This is just if it is required of the solution to be purely algebraic.  

The function just above is just a normal curve with mean of j, so it's integral is 1, and you make the deviation smaller and smaller which doesn't change the integral but makes it taller and taller. In the limit it is just infinitely tall at only the point j.