feat: better defaults for GA builder

[kkafar]

Description

Add better defaults for builder.

Right now this PR is stuck, due to problems with implementation.

Rust lacks few important language mechanisms:

• Trait specialization (same as C++ template spec.) is in early development process:
  • https://github.com/rust-lang/rfcs/blob/master/text/1210-impl-specialization.md
  • Tracking issue for specialization (RFC 1210) rust-lang/rust#31844
• Negative impls are unstable
  • Tracking issue for negative impls rust-lang/rust#68318
  • https://doc.rust-lang.org/beta/unstable-book/language-features/negative-impls.html

It is an issue, because:

1. We want to provide a blanket implementation over T: Chromosome for Builder struct. It would be ridiculous to force user to implement custom Builder.
2. Different operators require different trait bounds on Chromosome, thus defaults for different chromosome types must be different (there is really no common ground).

Due to aforementioned language restrictions it seems impossible to implement defaults depending on incoming chromosome type.

Edit:

There is hope however: Rust's macros - as they are quite powerfull - you can operate directly on AST -- so it seems doable, but some research has to be done first.

Edit 2:

Defaults rarely make any sense as operators are problem specific. There are really no operators that fit the needs of all problems (or are at least valid).

It seems to me, that we must force end-user to specify operators alongside fitness function.

Can we se macros somehow to manage this?

Selected solution

So far we focus mostly on two types of chromosome:

1. real valued (RVC)
2. bit string (BSC)

Therefore I went with following approach: for each chromosome type I created a dedicated builder for which all parameters except operators (outside the fixed type) can be modified.

There is also a single "dispatcher" - ecrs::ga::Builder which has factory methods for other builders.

Following API is now available:

  ecrs::ga::Builder::with_rvc()
    .fitness_fn(rastrigin::rastrigin_fitness)
    .dim(5)
    .build()
    .run()

We should consider separating our API into two categories:

• static
• dynamic

Because most of API shape issues arise from the fact that we went for fully static API. We could also expose dynamic API, which is configurable in much easier way.

Linked issues

Resolves #128
Resolves #179
Resolves #180