This guy setup a geiger counter next to some radioisotope and interfaced it with a computer and now he serves up entropy generated this way through this website:

http://www.fourmilab.ch/hotbits/

lacking a hardware random number generator of my own as of yet, i decided to collect some entropy from here and audit it with autocorrelation. The result is pleasing.

Here is the autocorrelation. I also checked the ratio of values above standard error to values below standard error, and it was less than 5%, which means that we are not seeing periodicity.

sum(cor > 9.233785107408778E-003)/numel(cor)
ans =
0.013

theres how i did it.

You can see that very often the autocorrelation is larger than the standard error, so we can say that this stuff is periodic and therefore not random. The standard error is that red line, it is sort of hard to see but trust me its there. Unfortunately the wordpress software makes the image smaller than it really is so it makes it harder to see.

some would argue that this is proof of GODS EXISTENCE OMG!!!!!1!!!

but yeah, it makes sense that a genome should not be random, the development of organisms is bassed of of outside inputs such as: environment, materials(what we are working with), etc. Which affect it at all levels.

here is the code:

        PROGRAM bob
        USE OMP_lib
        INTEGER, PARAMETER :: P=140067,M=70000
        REAL(8) :: sum,out(M),data(P),VAR,P2,tmp
        INTEGER :: k,j
	P2 = P;
        open (unit = 2, file = "data.txt")
        do k=1,P
                read(2,*) data(k)
        end do
	sum=0
	do k=1,P
                sum = sum + data(k)
        end do
	u = sum/P
        sum = 0
        do k=1,P
               sum = sum + (data(k)-u)*(data(k)-u)
        end do
	VAR = sum/(P-1)
	write (*,*) "STANDARD ERROR:"
	write (*,*) 1.96/SQRT(P2)
	!$OMP PARALLEL PRIVATE(k,tmp,j) DEFAULT(SHARED)
	!$OMP DO
        do k=1,M
                tmp = 0
                do j=k+1,P
                        tmp = tmp + (data(j)-u)*(data(j-k)-u);
                end do
		!$OMP CRITICAL
		out(k) = tmp/(VAR*P)
		!$OMP END CRITICAL
        end do
        !$OMP END DO
        !$OMP END PARALLEL

        open (unit = 7, file = "CORR.txt")
        do k=1,M
                write (7,*) out(k)
        end do

        close(7)
        END PROGRAM

if i compile it with openmp it gives me:
1.369807396630835E-003

as the first element of the answer set

if i compile it without openmp it gives me:
1.369807396632110E-003

every other element seems to be the same

this could be a big problem or nothing.

to get around the silly fortran limitations i actually wrote a perl script to take inputs and write out a fortran source and compile it and run it for me, very goofy. but now i can use this code without manually fiddling around everytime i want to run it and it doesnt really slow it down to any appreciable extent.

here is the time for the parrallel code running on a set of about 140k with a max dimension of 70k

real	0m3.086s
user	0m9.237s
sys	0m0.168s

here it is as it was previously:

real	0m7.776s
user	0m7.628s
sys	0m0.148s

so i wrote some autocorrelation in fortran. fortran is terrible at a lot of modern programming stuff, but its fast. For example, it is a major pain to set a parameter from a command line argument, or to get the length of a file. I am not a master at fortran, so i might just be incompetent but believe me it seems like too much of a pain.

So i have to set the autocorrelation dimension and data set size manually before compiling it. but anyways, here it is:

        PROGRAM bob
!       USE OMP_lib
        INTEGER, PARAMETER :: P=140067,M=70000
        REAL(8) :: sum,out(M),data(P),VAR,P2
        INTEGER :: k,j
	P2 = P;
        open (unit = 2, file = "data.txt")
        do k=1,P
                read(2,*) data(k)
        end do
	sum=0
	do k=1,P
                sum = sum + data(k)
        end do
	u = sum/P
        sum = 0
        do k=1,P
               sum = sum + (data(k)-u)*(data(k)-u)
        end do
	VAR = sum/(P-1)
	write (*,*) "STANDARD ERROR:"
	write (*,*) 1.96/SQRT(P2)
        do k=1,M
                out(k) = 0
                do j=k+1,P
                        out(k) = out(k) + (data(j)-u)*(data(j-k)-u);
                end do
		out(k) = out(k)/(VAR*P)
        end do
        open (unit = 7, file = "CORR.txt")
        do k=1,M
                write (7,*) out(k)
        end do
        close(7)
        END PROGRAM

the parameter P is the length of the file data.txt, i find it with wc -l. M is the dimension, must be less than half the length of the data set. it outputs a file CORR.txt which is the autocorrelation data to let you load it in matlab with data = load(‘CORR.txt’). As of now, the input file is a list of numbers seperated by newlines

it rips through the ~140000 element set in a few seconds

future directions will be making it so it can read a binary file and so i dont have to set the damn set length manually and set the correleation dimension at the command line.

function int = chebquad(funct,n,a,b);
f = inline(funct);
x = cos(((2*(1:n) - 1)/(2*n))*pi);
w = pi/n;
fx = ((b-a)/2)*f(((b-a)/2)*x + (b+a)/2).*sqrt(1-x.^2);
int = sum(w.*fx);

goal was to make each thread take different sequential “guess” values for

When you initialize and MPI program you have two important values for each instance of the program running, the rank, and the size. The rank is an identification number assaigned to each instance, starting with 0, ending with the size less 1. The size, obviously, is the number of instances we are running.

So what i did was add the rank to the initial value for the loop, then I added the size to the loop variable every step. So that instead of one loop running adding 1 every time, we have loops running adding every time. They are initially offset by their rank so that each instance will take on different values.

here is the code:

#include <stdlib.h>
#include <stdio.h>
#include <stdarg.h>
#include <gmp.h>
#include "mpi.h"

int main (int argc, char *argv[]){
  int rank,size;
  MPI_Init(&argc, &argv);
  MPI_Comm_rank(MPI_COMM_WORLD, &rank);
  MPI_Comm_size(MPI_COMM_WORLD, &size);

  char		sho [300];
  mpz_t		N; /* For final computation results */
  mpz_t		A,As,B,Bsq,Bsho,Bs;
  mpz_init_set_str (N, "75557863657023047991947", 10);
  mpz_init(A);
  mpz_init(Bsq);
  mpz_init_set_str(Bs,"1",10);
    mpz_init(Bsho);
    mpz_init(As);
   mpz_init_set_str(B,"2",10);
  mpz_sqrt(A,N);
  mpz_add_ui(A,A,rank);
  while( mpz_cmp(Bs,B) != 0){
   mpz_get_str(sho,10,A);
   /*printf("%s - %i\n",sho,rank);*/
   mpz_add_ui(A,A,size);
   mpz_pow_ui(As,A,2);
   mpz_sub(B,As,N);
   mpz_sqrt(Bsq,B);
   mpz_pow_ui(Bs,Bsq,2);
  }
  mpz_sqrt(Bsq,B);
  mpz_sub(Bsho,A,Bsq);
  mpz_get_str(sho,10,Bsho);
  printf("%s\n",sho);
  mpz_cdiv_q(As,N,Bsho);
  mpz_get_str(sho,10,As);
  printf("%s\n",sho);
  MPI_Abort(MPI_COMM_WORLD,1);
  return 0;
}

Fermats method uses difference of squares to accomplish our task: $;atex N = p*q = a^2 – b^2$ We guess until we have a that is a perfect square.

#include <stdlib.h>
#include <stdio.h>
#include <stdarg.h>
#include <gmp.h>
/*#include "mpi.h"*/
int main (int argc, char *argv[]){
  char		sho [300];
  mpz_t		N; /* For final computation results */
  mpz_t		A,As,B,Bsq,Bsho,Bs;
  mpz_init_set_str (N, "2533965587", 10);
  mpz_init(A);
  mpz_init(Bsq);
  mpz_init_set_str(Bs,"1",10);
    mpz_init(Bsho);
    mpz_init(As);
   mpz_init_set_str(B,"2",10);
  mpz_sqrt(A,N);
  while( mpz_cmp(Bs,B) != 0){
   mpz_add_ui(A,A,1);
   mpz_pow_ui(As,A,2);
   mpz_sub(B,As,N);
   mpz_sqrt(Bsq,B);
   mpz_pow_ui(Bs,Bsq,2);
  }
  mpz_sqrt(Bsq,B);
  mpz_sub(Bsho,A,Bsq);
  mpz_get_str(sho,10,Bsho);
  printf("%s\n",sho);
  mpz_cdiv_q(As,N,Bsho);
  mpz_get_str(sho,10,As);
  printf("%s\n",sho);
  return 0;
}

I used GMP so that any size integer may be handled, though it is probably not necisary for any numbers that i can factor with this computer in a timely manner. This method forms the basis for the Quadratic sieve, the second fastest algorithm for this prime factorization problem. The most challenging aspect of implementing the quadratic sieve seems to be evaluating the prime counting function . I know there actually is some approximation of this, some sum that converges to it… That all relates to the riemann hypothesis. It may be very ahrd to implement. I will have to look into it.

The fastest algorithm is the Generalized Number Field Sieve, very hard to implement. It is stated on wikipedia that a working implementation would be a reasonable master’s thesis. whew

Current goals for this thread of work are:

Cryptology aside, i have been meaning to pick up some C. So today happened to be the day i started, and largely because of the GMP – Gnu Multi Precision arithmetic library.

Well i needed the multiprecision arithmetic to deal with numbers as large as $N$ comes for RSA. my algorithm works exploiting two things, the fact that: and that even numbers will never be candidates. It also takes advantage of the modulus, the modulus is cheap computationally(I believe its very basic to a computer). Also, it assumes that the p and q may be close to more often than not.

Here is what happens:

take

if then you have it, divide out and print answer

#include <stdlib.h>
#include <stdio.h>
#include <stdarg.h>
#include <gmp.h>
#include "mpi.h"
int main (int argc, char *argv[]){
    int rank,size;
  unsigned long int	i;
  int        m;
  char		res [300], sho [300];
  MPI_Init(&argc, &argv);
  MPI_Comm_rank(MPI_COMM_WORLD, &rank);
  MPI_Comm_size(MPI_COMM_WORLD, &size); /* initializing MPI, collecting info about environment*/
  mpz_t		N;
  mpz_t		D,S,I,ds,Ss,Se;
  mpz_init(D);
  mpz_init(S);
  mpz_init(Ss);
  mpz_init(Se);
  mpz_init(ds);
    mpz_init(I);
  mpz_init_set_str (N, "951481467360591658636268654185633689926419097", 10);
  mpz_sqrt(S,N);
  mpz_cdiv_q_ui(ds,S,size); /* divvy up lims for loop! */
  mpz_mul_si(Se,ds,rank);
  mpz_add(Ss,Se,ds);
    if ((mpz_divisible_ui_p(Ss,2)) != 0){
        mpz_add_ui(Ss,Ss,1);
    }

  for (mpz_set(I,Ss);mpz_cmp(I,Se)>0;mpz_sub_ui(I,I,2)) {
    m = mpz_divisible_p(N,I);
    if ((mpz_divisible_ui_p(I,100000001)) != 0){
	mpz_get_str(sho,10,I);
	printf("%s\n",sho);
    }
    if (m != 0){
         mpz_get_str(sho,10,I);
	printf("YAY\n%s\n",sho);
	mpz_cdiv_q(D,N,I)	;
	mpz_get_str(res,10,D);
	printf("\n%s\n", res);
	 	MPI_Abort(MPI_COMM_WORLD, 1); /* Tell all threads to exit(1)*/
    }
  }

  return 0;
}

So there it is, i uopdated the post cause the last code i had posted was terrible….

I added MPI to this, which is beautiful. My first implementation using MPI…

This code isnt going to factor that number unless you have a cluster… Next step is smarter faster algorithms. Next post dealing with this subject should be just that… parallelization of these things makes it much more interesting too.

Contrast translates to the standard deviation of the distribution of pixel values.

When looking at an image what you really want is a close to uniform distribution of colors. This will allow the color map to be used more effectively, more colors will be used so there is more for your eye to see.

Effectively, messing with these arithmatic transforms allows us to change how colors are being assaigned without disturbing the shapes and structures within the image. We are more concerned with the fact that there is as difference in the colors between different areas of the image than the magnitude of this difference.

these transforms change the magnitude of these differences, preserving the fact that there is as difference, so we still are looking at the same shapes.

A more advanced method would involve mapping the pixel value distribution of your image to another distribution directly.

Main thing i meant to say here is that you want a close to uniform distribution of values in your image to fully utilize your color map.

Log Filtering
If an image is too faint so that details refuse to show up, log filtering can increase the visibility of otherwise faint structures. This applys when the distribution of colors/intensity is too large tailed, the range is very large. This causes imaging techniques to assigned their colormaps in a very skewed way. The log reduces the range of the data, making it more normal aswell. The distances between the intensity values are lowered.

Here is a quick little matlab function i wrote to perform log filtering with normalization to keep results predictable.

function A = logfilt(A)
A = A/max(max(A));
A = (A*256);%adjust this max to adjust strength, larger makes it have more effect
A = log10(A+1);%add 1 so not to take log(0)
A = A/max(max(A));
A = (A*256);

Exponential filtering
If an image is too intense, IE: the whole thing is white. Then the values are too close together, intensity/color distribution is too spikey. The pixel values get assigned poorly, such that far too many pixels have the same value. This can be remedied by increasing the distance between all the intensity values. This will spread the distribution of intensity out so that the color map will be assigned properly so that we can see the differences between pixels better. The distances between intensity values are increased.

Here is a matlab function same as above only for exp filtering:

function A = expfilt(A)
A = A/max(max(A));
A = (A*2);%adjust this multiple to change the strength, make it larger and it has more effect
A = exp(A)-1; %minus 1 to change the 1s to 0s as they were prefilter
A = A/max(max(A));
A = (A*256);

Square root filtering
The square root works just like the log only it is inherently weaker. This is a good thing, because sometimes a log is far too much.

I wrote an analogous script…

function A = sqrtfilt(A)
A = A/max(max(A));
A = A*256;%larger and its stronger
A = sqrt(A);
A = A/max(max(A));
A = (A*256);

Trial and error is how you will learn to use these. using these tecniques in combination can turn a totally incoherent image into a very good looking thing, showing all the details. I may add some images to this post later but at this time Im not feeling it.