Minor documentation updates.

Author: CodeReclaimers

CHANGELOG.md

@@ -41,6 +41,8 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
   - Includes test/visualization script for trained controllers
   - Full documentation in example README with usage tips
 
+- **New Example**: Better Lunar Lander example (as in, it actually solves the environment)
+
 ### Changed
 - Dropped support for Python 3.6 and 3.7; neat-python now requires Python 3.8 or newer.
 - Modernized internal implementation in `neat/` and `examples/` to use Python 3 features

docs/config_essentials.rst

@@ -194,6 +194,14 @@ Let's walk through the XOR example config with explanations:
    # Legacy values ``full`` and ``partial`` are accepted for backward compatibility but
    # are deprecated; prefer the explicit variants above.
    initial_connection      = full_direct
+
+   # Note: The original NEAT paper emphasizes starting from minimal structure (no hidden nodes
+   # and sparse connectivity) and then complexifying over time. NEAT-Python follows this
+   # philosophy by treating ``unconnected`` as the canonical "no edges" option (see
+   # :ref:`initial-connection-config-label` and :doc:`neat_overview`). In simple examples like XOR
+   # we use ``full_direct`` for convenience so networks make progress quickly, while still
+   # starting with zero hidden nodes. If you want the sparsest possible starting networks,
+   # set ``initial_connection = unconnected`` instead.
    
    # Activation function for neurons
    # sigmoid: outputs in range (0, 1) - good for most problems

docs/reproducibility.rst

@@ -61,6 +61,10 @@ The ``seed`` parameter takes precedence over the config file setting:
    # Config file has seed=100, but this uses seed=42
    pop = neat.Population(config, seed=42)
 
+Note that passing ``seed=None`` explicitly to :class:`~neat.population.Population` disables seeding from the
+configuration file even if ``[NEAT]`` contains a ``seed = ...`` entry; omitting the ``seed`` argument entirely
+causes :class:`~neat.population.Population` to use ``config.seed`` if present.
+
 Random Behavior (Default)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -184,6 +188,36 @@ Checkpoints preserve:
 
 This means checkpointing maintains reproducibility even without explicitly setting a seed when restoring.
 
+.. note::
+
+   **Checkpoint vs. uninterrupted-run trajectories**
+
+   Restoring the *same* checkpoint multiple times produces a deterministic
+   continuation of evolution: given a fixed checkpoint file and fitness
+   function, repeated restores followed by additional generations will take
+   the same evolutionary path.
+
+   However, there is one subtle limitation: the sequence of populations you
+   get when running **without** checkpointing is not currently guaranteed to be
+   *bit-for-bit identical* to the sequence you get when running **with**
+   checkpointing and later restoring from a checkpoint at generation ``N``.
+
+   The reason is that some helper objects involved in evolution (such as the
+   reproduction and stagnation helpers) are reconstructed when a checkpoint is
+   restored rather than being pickled and resumed exactly as-is.  Although
+   their behavior is designed to be equivalent, and key invariants (population,
+   species, random state, innovation tracking) are preserved, there are still
+   rare edge cases where the evolutionary trajectory after generation ``N`` may
+   differ slightly between an uninterrupted run and a resumed run.
+
+   In practice this means:
+
+   * Checkpoints are suitable for pausing/resuming long runs and for
+     experiment management.
+   * Checkpoints do **not** currently provide a strict guarantee that
+     "run-with-checkpoint" and "run-without-checkpoint" will produce
+     identical post-``N`` populations, even when using the same seed.
+
 Limitations
 -----------
 

docs/xor_example.rst

@@ -33,10 +33,11 @@ then the fitness value of A should be greater than the value of B.  The absolute
 are not important, only their relative values.
 
 In this example, we create a :term:`feed-forward` neural network based on the genome, and then for each case in the
-table above, we provide that network with the inputs, and compute the network's output.  The error for each genome
-is :math:`1 - \sum_i (e_i - a_i)^2` between the expected (:math:`e_i`) and actual (:math:`a_i`) outputs, so that if the
-network produces exactly the expected output, its fitness is 1, otherwise it is a value less than 1, with the fitness
-value decreasing the more incorrect the network responses are.
+ table above, we provide that network with the inputs, and compute the network's output.  The fitness for each genome
+is computed as :math:`4.0 - \\sum_i (e_i - a_i)^2`, where :math:`e_i` and :math:`a_i` are the expected and actual outputs
+for each of the four XOR test cases. If the network produces exactly the expected output on all cases, its fitness is
+4.0; otherwise it is a value less than 4.0, with the fitness value decreasing the more incorrect the network responses
+are.
 
 This fitness computation is implemented in the ``eval_genomes`` function.  This function takes two arguments: a list
 of genomes (the current population) and the active configuration.  neat-python expects the fitness function to calculate