Releases: JedS6391/LGP
5.3
View the full changelog here.
Additions:
- Add logging abstractions. Logging can now be configured using SLF4J to gain deeper introspection into the system.
Breaking Changes:
- Move to multi-module project structure. The main repository now includes the
core
andlib
packages. - The artifacts published to Maven have changed to reflect the new structure:
nz.co.jedsimson.lgp:LGP
is nownz.co.jedsimson.lgp:core
nz.co.jedsimson.lgp:LGP-lib
is nownz.co.jedsimson.lgp:lib
Fixes:
- Maven publication POM did not declare dependencies in the 5.2 release. This has been resolved.
5.2
5.1
View the full changelog here.
Breaking changes:
- The
TournamentSelection
operator now has an additional (non-optional) propertynumberOfOffspring
which supersedes
the oldnumOffspring
Configuration
property. EventDispatcher
no longer contains methods for registerEventListener
definitions. The registration
methods have been moved toEventRegistry
.
Changes:
-
Any components which make use of the experimental co-routine APIs have been marked with the
@ExperimentalCoroutinesApi
attribute. -
A new
DiagnosticEvent
has been exposed which allows introspection into the system. The majority of the built-in
components have been updated to dispatchDiagnosticEvent
s for various actions. For example, to register a listener
for trace events:EventRegistry.register(object : EventListener<DiagnosticEvent.Trace> { override fun handle(event: DiagnosticEvent.Trace) { // Do something with event } })
-
Unit tests have been added for the following components (and there are more to come!):
- Tournament selection operator
- Recombination operator
Fixes:
5.0
View the full changelog here.
Breaking changes:
Type definitions
- The majority of the core library has been modified to accept a generic target type parameter, to allow the target
of the data set to be strongly-typed through the system. Previously, only the program data type and type of program
output was generic. The main benefit of the introduced target type parameter, is to simplify the usage and
implementation of fitness functions.
Modules
ModuleContainer
has been moved to thenz.co.jedsimson.lgp.core.modules
package.- The module resolution functions
instance
andinstanceUnsafe
are no longer the responsibility ofModuleContainer
and have been relocated to theModuleFactory
class.
The intended usage is thatModuleContainer
defines a set ofModuleBuilder
s, and
theModuleFactory
can be used to resolve instances from a givenModuleContainer
.
Environment
- Direct dependency on
Environment
has been removed from all core implementations and is recommended for any custom implementations.
The public contract is now defined inEnvironmentFacade
and this should be the contract relied upon. Environment
can no longer be directly used to resolve dependencies as theregisteredModule
andregisterModuleUnsafe
functions have been removed. Dependencies should be resolved usingEnvironmentFacade.moduleFactory
.
Evolution operators
- The
nz.co.jedsimson.lgp.core.evolution
package was restructured significantly. It is now split up as below:
nz.co.jedsimson.lgp.core.evolution.operators
├── mutation
│ ├── macro
│ ├── micro
│ └── strategy
├── recombination
└── selection
MacroMutationOperator
now accepts an optionalMutationStrategyFactory
which can be used to customise the mutation behaviour.MicroMutationOperator
now accepts an optionalMutationStrategyFactory
which can be used to customise the mutation behaviour.- When no
MutationStrategyFactory
is given to eitherMacroMutationOperator
orMicroMutationOperator
, they will use the default
strategy factory which preserves the previous behaviour of these implementations. The main reason behind this change is internal,
but it can be used externally too.
Program
- The properties
instructions
,registers
, andoutputRegisterIndices
are now abstract properties ofProgram
. - The properties
arity
andfunc
(now renamed tofunction
) are now abstract properties ofOperation
.
Registers
- RegisterSet is now an interface and the implementation has been moved to ArrayRegisterSet.
Miscellaneous
- The built-in Kotlin
Random
is now used instead ofjava.util.Random
. - Moved
Random
extension functionschoice
,randInt
,sample
to thenz.co.jedsimson.lgp.core.environment
package. - Move
MutableList
extension functionslice
into thenz.co.jedsimson.lgp.core.evolution.operators
package. - Moved
Valid
andInvalid
ConfigurationValidity
implementations into the parent class (i.e. no longer accessValid
, instead useConfigurationValidity.Valid
).
4.2
Breaking changes:
- The
nz.co.jedsimson.lgp.lib
andnz.co.jedsimson.lgp.examples
packages have been removed and split into their own modules:
If you are relying on these then please reference LGP core as well as the modules you require and change the package names as required. This should be a relatively minor breaking change (as far as breaking changes go).
4.1
Changes:
BaseProgramGenerator
now only generates random program instancesEffectiveProgramGenerator
can be used to generate effective program instances
Fixes:
- The algorithm used for generating effective program instances would previously not always generate effective programs.
Additions:
- Added
RandomRegisterGenerator<T>.getRandomInputAndCalculationRegisters()
helper method for getting a given number
of input and calculation registers (with a random distribution).
4.0
Breaking changes:
- Rename top-level package from
lgp
tonz.co.jedsimson.lgp
to match Maven deployment.
Enhancements/Additions:
- Facilitate the deployment of the LGP artefact to Maven central.
- RegisterSet performance improvements (
Array
vsMutableList
)
The version has been bumped to 4.0 to reflect these breaking changes.
3.1
Version 3.1 includes some minor changes:
Minor changes:
- Kotlin 1.3.11
- kotlinx-coroutines 1.0.1
- dokka 0.9.17
- Removes IntelliJ project files
Acknowledgements:
- @skalarproduktraum -- updated Kotlin, kotlinx-coroutines, dokka, and tidied up IntelliJ files.
3.0
Version 3.0 has some significant changes, primarily towards the facilitation of handling programs that have different output targets (e.g. single-output, multiple-output, custom).
The full set of changes is as described below:
Breaking changes:
- Most of the core components in the system now require an extra type parameter:
TOutput
. This is used to determine what type of output the programs have, enabling programs with single and multiple outputs - Addition of classes/helpers to aid in handling programs with different numbers of outputs
The version has been bumped to 3.0 to reflect these breaking changes.
Enhancements/Additions:
- New
ExclusiveOr
bitwise operation - Allow operations to be serialised with a
toString
method for easier program translation - New example problem
FullAdder
to demonstrate the use of multiple-output programs
Bug fixes:
- Fix an issue where the
Or
operation was incorrectly performing a logical and - Address a logic error in the Island Migration implementation that could cause problems with certain configurations
Acknowledgements:
- @HongyuJerryWang -- contributions to the implementation of multiple program outputs, full adder example, new operations, and bug fixes.
2.0
Version 2.0 brings a few big changes. A summary from the changelog is below:
Breaking changes:
- The
Trainers
object no longer exists - Related to above, the
Trainer
implementations have moved fromlgp.core.evolution
tolgp.core.evolution.training
- A new package
lgp.core.program
has been created and quite a few classes fromlgp.core.evolution
were migrated
The version was bumped to 2.0 to reflect these potentially breaking changes.
Enhancements:
- Added the ability to train asynchronously using the built-in
Trainer
implementations - Update to the Kotlin 1.3 release candidate to make use of the soon to be stable co-routine APIs