MSC: Update - July 8, 2011

. Friday, July 29, 2011
  • Agregar a Technorati
  • Agregar a Del.icio.us
  • Agregar a DiggIt!
  • Agregar a Yahoo!
  • Agregar a Google
  • Agregar a Meneame
  • Agregar a Furl
  • Agregar a Reddit
  • Agregar a Magnolia
  • Agregar a Blinklist
  • Agregar a Blogmarks

for the 3rd track, listed below are the modifications i made:

update 30/6/11
changed the way v and u is stored

  • initial idea was flawed, as in, v and u are reset at every update loop.
  • hence corrected it by giving every neuron their own v and u values, which could lasts throughout the whole run, which would only be reset at every generation.
added a reset function for the neural network (brain) to reset the values of v and u.
added lastlaptime and a brain.reset in the drivers' reset function.
added initialization for lastlaptime in genetic algorithm

update 1/7/11
  • modified the fitness function to (distraced + steps inside track - damage). Took out the average speed as score.
  • changed the way v and u is stored
    • initial idea was flawed, as in, v and u are reset at every update loop.
    • hence corrected it by giving every neuron their own v and u values.
  • added a reset function for the neural network (brain) to reset the values of v and u.
  • added lastlaptime and the brain.reset() function call in the drivers' reset function.
  • added initialization for lastlaptime in the evolutionary algorithm

update 4/7/11 7.16pm
  • normalized the input to the neuron to [0,10]
  • discovered after the 1st attempt, the values of v overflowed and produced -1.#IND as its value.
  • printed the values of v again, with this time, having values of v & u reset at every time-step. Found out that v has very large values (to the thousands).
  • big values of v added confirmation that it went infinity, and that the inputs could be too big.
  • put back the average speed as score.
  • discovered a probable reason why the drivers could not gain back it's fitness as printed in the results, reason could be that the inputs are too big.
NB: damage of the car might shutdown the client. have to take note if this would happen. hopefully not. otherwise, how to implement damage into fitness calc?
NB: after this attempt with 3001 and 3002, test it in display and note the fitness. make sure it is the same as the last generation results when evolving.

update 5/7/11
 - made the client restart the race with the next driver if the current driver's damage is more than 1000 (dmg > 1000).
 - this method stopped the server from shutting down when the car reached max damage. This method also made it possible to save time by skipping drunk drivers.

update 6/7/11
 - opted to try using back the previously flawed method of reseting v and u at every timestep to test/try it on track 3.
 - just as a preliminary experiment.

update 8/7/11
moved the reset to the onRestart function of the driver class.
set the server to have a time out of 100,000 microsecond = 100 millisecond.
  • discovered another reason why the drivers dont get the same fitness scores. it's because of the timeout problem.the server's timeout was too short for the client to answer, so the behavior of the car changed, to reuse the outputs from the previous timestep.
  • this caused the drivers to drive differently each time there is a timeout for the client to answer. Hence the varying fitness.

0 comments:

me me