Genetic Programming: Difference between revisions

From Hegemon Wiki
Jump to navigation Jump to search
Line 14: Line 14:
* Maybe some made up IR that is then converted to X86-64, SPIPR-V or whatever (Isn't that LLVM bytecode?).
* Maybe some made up IR that is then converted to X86-64, SPIPR-V or whatever (Isn't that LLVM bytecode?).


==Ideas==
=Ideas=
Make the genetic program evolve genetic algorithms.
Make the genetic program evolve genetic algorithms.


Break it up into functions. Evolve selection, crossover, mutation functions for example.
Break it up into functions. Evolve selection, crossover, mutation functions for example.


Maybe allow higher levels or program to evolve
Maybe allow higher levels or program to evolve. Give some kind of weights to the chance of something evolving.


How do I avoid infinite loops? Some hard limit?


Does uninitialised memory need to be avoided? Or could that be useful.


Is is possible to evolve the algorithm of the program evolving the algorithms. Ie pick the current best? Or would that evolve itself into a corner?


==Fitness==
How do I avoid infinite loops? Some hard limit?
Can't evolve fitness functions...?

* Speed of evolution.
* Best solutions.
* Efficiency.
** CPU Time?
** Number of instructions?


==Random numbers.==
Share the same random number for all programs in the same run to prevent randomness messing with the evolutionary randomness?


Need to be reproducible. Make a random number generator generator.
Does uninitialised memory need to be avoided?


How do I do this in ASM?
Random numbers.
* Share the same random number for all programs in the same run?
* Need to be reproducible. Make a random number generator generator.
* How do I do this in ASM?

Revision as of 22:53, 1 November 2016

Possible targets

  • LLVM - Can run as bytecode or compile to machine code.
  • Web Assembly - New.
  • JVM - I hate Java.
  • MonoVM - Meh.
  • SPIR-V - For the GPU. Can run naively (and fast), but would need to learn Vulkan/OpenCL at the same time. Problems with the GPU<->CPU differences.
  • X86-64 - Native but CISC... Could use a subset...
  • RISC-V - I love RISC-V (needs to be emulated).
  • AVR - For a microcontroller (needs to be emulated).
  • ARM - For a microcontroller (needs to be emulated).
  • MIR - Rust intermediate level. Not sure if it would be any advantage over LLVM.
  • BrainFuck - It's simplicity be good for genetic programming?
  • GPTree - A Genetic Programming AST. Traditional.
  • Maybe some made up IR that is then converted to X86-64, SPIPR-V or whatever (Isn't that LLVM bytecode?).

Ideas

Make the genetic program evolve genetic algorithms.

Break it up into functions. Evolve selection, crossover, mutation functions for example.

Maybe allow higher levels or program to evolve. Give some kind of weights to the chance of something evolving.

How do I avoid infinite loops? Some hard limit?

Does uninitialised memory need to be avoided? Or could that be useful.

Is is possible to evolve the algorithm of the program evolving the algorithms. Ie pick the current best? Or would that evolve itself into a corner?

Fitness

Can't evolve fitness functions...?

  • Speed of evolution.
  • Best solutions.
  • Efficiency.
    • CPU Time?
    • Number of instructions?


Random numbers.

Share the same random number for all programs in the same run to prevent randomness messing with the evolutionary randomness?

Need to be reproducible. Make a random number generator generator.

How do I do this in ASM?