perpetuation

right now it is about 12:00 and I still have not been able to get solid good simulation. Starting at 10 in the morning I was just running the computers. after every run I would reset the evals and ballPlates. The problem is that after x amount of time...x being some number based on the machines feelings... the runs would have crash...meaning that all the finesses would be either 0.0 or .1928... in some cases when I would start all 10 runs all would fail. This is what my day consisted of. running resetting, waiting, evaluating, sorting, deleting and repeating. In many cases only one run would come out with out more then 10 % collapse per generation. I would not it was based on the mutation rate...more of the machines that I was using. I found that the simulations on joey25 and up would last. my guess is that they are used less then the rest so they last longer. In any case I'm going to leave the runs now going and check in the morning. up to this point I have .1-.8 and I'm just waiting on .99 and .9.

Ps I used .99 because my GenAlgo will not take any mutation rate out of 0-1 so i though .99 would be really close to 1

revitalization

It was discovered that the link to the Utah computer was rejecting my/ Clemson`s request, so that was put on the back burner. Yesterday and today are the same thing. I am running the mutation runs again, but with 40 threads 40 individuals and 50 generations. If all is okay I can sneak in three simulations before the machine starts to pop zeros. The cause is still not  found, but there is a correlation to the work done by the machine. But in any case I'm just finishing up the simulation. In my GenAlgo there's some bugs... not stop the presses type but still... but there is also this nifty... yes, yes i did use that word... design that I can rerun a simulation with a simple yes. So all I have to do is restart the evals and the ballPlates... laziness prevails...

globalization

today is/was kinda chill. I ran a 100 by 100 on clemson network, I have to watch it because the threads tend to quit after a bit. I uploaded my code to a repository so if my computer crashes and cloud 9 crashes and clemson crashes then I will still have my code on the internet. After running a small simulation on a computer in utah, or ohio... it`s one of those... I learned that the source of the zeros in my program is two fold. it was found that there was a different type of error message... one that meant that two attempts for the fitness fail...this error message was a fitness with extremely low value. I had just made a method that rounded all the values to the 4th place, so the value was cut off. When the simulation was run, zeros still popped up, but so did the default value that was chaged. So there is potential another zero emitting entity in the system, but as for now Im just happy everything kinda works.

devaluation

Well all the problems seem to be caught to far, but for some reason some individuals no have a fitness of zero... "well whats the problem" you might ask,... well as far as I have seen no individual can have a fitness of zero and the value is usually a sign that the input was syntactically incorrect, and its not. This only happens in some threads and I know this because if I have 100 individuals and 50 threads then there needs to be 2 evaluations, and the number of 0.0 entries is an even number constant with every generation after some point. I looked at the raw data that was begin spit out from the http get request and it match that of the log files. Also I hand ran some individuals and there fitness in a reset machine was actually goodish... not excellent, but not zero. I have also noticed that if a machine has been running for a period then manually running a fitness loops... ie someone is at the door but no one is coming.  just for the sake of sake Im going to rerun and If i get similar results then I will go from there. To ensure that Its not some haywire method over righting finesses zero I will refresh the evaluations.

decolonisation

Well I figured out the reason for half of the zeroPop being zeros, it turns out that when I wrote the code I switched the parameters... oops =1... so that problem was fixed. the reason that it wasn't a problem was that when ran by file the seeded population was .5 instead of .05 so it was half and half. when i would test the Genalgo I would do whatever number I fancied at the time. Well problem fixed and put away. But I now have a different problem. When I run a simulation nearly all the fitness's come back as zero... before you think "well you had a problem with references before, look", This fitness is strait from the horses mouth... ie its printed right after it is returned from the website, my code barely touches it. So I tried running the individual manually and when I do the browser waits and then I get a time out as if the remote evaluation isn't running... you may ask "is it?", yes it its, ye of little faith... the terminal for it is right next to it, waiting for something. When I refresh the browser the terminal stays as is, so this means that the remote eval is not even getting the green light. Ill see whats up, or try another joey, but this is weird.. I have had this problem all day.

variegation

So on Monday, it was discovered that I was using references wrong and altering my programs genetic materiel in a wrong way. So Monday, Tuesday and Wednesday was used to discover and fix that problem. done. I ran a test program and for some reason when I run my program using the UI i made, things go haywire... like half of the population disappears. So today is ensuring that my program reads the popzero file correctly, ensuring that the results for any fitness test is correct, and trying to discover the root cause of the UI malfunction.
I know it is the UI because if I run the file that actually runs everything then everything works fine, but if I run the GenAlgo... which just asks for the parameters then dynamically fills them, I get half the population of Generations zero set to zero.

disambiguation

upon really fine examination of all the parts of the Ga program I found that two major parts of the program where not quite correct. The effects where seen when the numbers that the computer dealt with and the numbers that where presented in the log files where not matching up. It turns out that when the generation was being read to make the next generation the float arrays that where being altered where for the next generation was them selves being altered. ... ugg references...(-U_0-)  Meaning that if a individual had a good fitness, it would share its genetic code, then have that code be altered to a better or worse fitness and the program would not notice. This could have lead to all the default values. I'm going to run the program again and see if It fails again.