Skip to content

Events and Subscriptions

Radiate provides an event system that allows you to monitor and react to the evolution process in real-time. This is great for:

  • Tracking the progress of evolution
  • Collecting metrics and statistics
  • Implementing custom logging
  • Visualizing the evolution process

Overview

The event system in Radiate is built around the concept of event handlers or subscribers that can be attached to the GeneticEngine. These subscribers receive events at key points during the evolution process, allowing you to monitor and react to changes in the environment in real-time. The event system is designed to be flexible and extensible, allowing you to create custom event handlers that can perform various actions based on the evolution state.

The GeneticEngine tries it's best to off-load almost the entire compute workload of the subscribers (handlers) to the user - be aware of this when implementing your handlers.

Threading Behavior

Currently, the rust implementation is multi-threaded, meaning if you have multiple subscribers, there is no guarantee of the order in which they will be called. For python, the GIL locks the implementation into a single-thread, so subscribers will be called in the order they were added.


Event Types

Radiate provides several key events that you can subscribe to:

Start Event

This event is triggered when the evolution process starts. It provides an opportunity to initialize any resources or perform setup tasks before the evolution begins.

Stop Event

This event is triggered when the evolution process stops, either due to reaching a stopping condition or being manually stopped. It provides access to:

  • The final metrics of the evolution
  • The best individual found
  • The final score, or fitness, of the best individual
Epoch Start Event

This event is triggered at the start of each generation (epoch) and provides the current generation number. It allows you to perform actions before the evolution step begins, such as resetting counters or logging initial state.

Epoch Complete Event

This event is triggered at the end of each generation (epoch) and provides information about:

  • The current generation number
  • The current metrics from the GeneticEngine
  • The best individual found from the GeneticEngine so far
  • The best score, or fitness, from the best individual
Step Start Event

This event is triggered at the start of each evolution step. It provides the name of the step being executed, allowing you to monitor the progress of specific steps in the evolution process.

Step Complete Event

This event is triggered at the end of each evolution step. It provides the name of the step that was executed, allowing you to log or monitor the completion of specific steps in the evolution process.

Engine Improvement Event

This event is triggered when the engine finds a new best individual during the evolution process. It provides:

  • The index of the generation where the improvement occurred
  • The best individual found at that point
  • The score, or fitness, of the best individual

Subscribing to Events

You can subscribe to events in two ways:

1. Using a Callback Function

The simplest way to subscribe to events is by providing a callback function:

🚧 Under Construction 🚧

These docs are a work in progress and may not be complete or accurate. Please check back later for updates.

2. Using an Event Handler Class

For more complex event handling, you can create a custom event handler class:

🚧 Under Construction 🚧

These docs are a work in progress and may not be complete or accurate. Please check back later for updates.

Best Practices

  1. Keep Event Handlers Light:

    • Event handlers are called frequently during evolution
    • Avoid heavy computations in event handlers
  2. Use Multiple Subscribers:

    • You can subscribe multiple handlers to the same engine
    • Separate concerns into different handlers
      • Example: one for logging, one for metrics, one for visualization
  3. Handle Errors Gracefully:

    • Event handlers should not crash the evolution process
    • Log errors instead of raising exceptions - do not expect the GeneticEngine to throw exceptions
  4. Monitor Performance:

    • Be aware that event handling adds some overhead depending on your implementation
    • Use built in metrics to track certain metrics or performance characteristics if possible
    • Be cautious of your implementation - consider disabling event handling in production if not essential