Aside of goal for this project we should describe non-goals, such as - things we do not care or which are not our intention.

For example: we do not care about coding fast, because we develop simple algorithm since month. Code quality is important in general, but for me - it is crucial for code to compile, pass tests. Our non-goal could be not to stray from documentation, so we should be careful and describe new features with proper issues, documentation, tests.

After all it is better to have this written down, as we can have other non-goals in our heads and this may lead to misunderstandings.

It is inside Mutator description, it should be moved up by two paragraphs.

CrossoverService:
+cross(Gene gene1, Gene gene2): void

cross is mutating/mixing genes 1 and 2, using described pattern

MixingHalvesCrossoverServiceImpl:
g1: 1st byte of g1 + 2nd byte of g2
g2: 1st byte of g2 + 2nd byte of g1

OddBitesCrossoverServiceImpl:
g1: has bites with odd positions copied from g2
g2: has bites with odd positions copied from g1

EvenBitesCrossoverServiceImpl:
g1: has bites with even positions copied from g2
g2: has bites with even positions copied from g1

BitPairCrossoverServiceImpl:
g1: starting from bit0, two bits unmodified, then another two bits copied from g2, then two unmodified, and another from g2...

It is something more than internal implementation of one class or functionality, and will be used by Crossover and Mutator classes. It should be somehow mentioned in our docs.

In BitwiseUtil there are two methods setBit() and setByte(), which throw exceptions. Do you agree that these methods should also declare these exceptions?

We could continue with getRandom producing nextInt(), and then convert it to float values, but I think it is better to add getRandomFloat or just getFloat() method to RandomProvider.

I think that unused (outdated) pictures from the images directory should be removed.

Evaluator.setFitness does not set a value, but calculates it.

Adding headings for each paragraph in Code structure section in Readme should increase readability and wholesomeness of our docs.

There are some topics to be added soon:

• branch managing and naming convention
• description of development cycle
• maybe some predictions about future releases and their contents

Variant2EvaluatorImplTest has a bug, which is fatal:

in every test method there is a line:
// given
evaluator = new Variant1EvaluatorImpl(target);

so we are testing Variant1 after all. It needs to be changed.

Evaluator takes only first element of array and ignores the rest. It does not seem right. If other elements of array are not importand, than we should not have an array but single char.
If array is needed, test and documentation should cover it somehow.

testy czy geny są unikalne
interface RandomProvider

interface RandomProvider
int getRandom()

RandomProviderImpl
getRandom(10) -> (LocalThreadRandom.current.nextInt(10)

Gene(RandomProvider)
char[] values

RandomProvider = mock(RP)

when().return(10)

As stated in #52, BitPairCrossoverServiceImpl copied even bit-pairs from another gene, so description should be corrected.

Single Mutator:

• given 100% chance, should mutation occur
• when chance is met, mutation should occur on given position
• when chance is not met, mutation should not occur

Multiple Mutator:

• given 100% chance, should mutation occur
• when chance is met, mutation should occur on given positions
• when chance is not met, mutation should not occur

Gen
char[] value
float mutability
float fitness;

char[] inicjowana losowymi wartościami

descriptive custom Exceptions extending IllegalArgumentException

I was testing this formula 1 / (1+log(1+delta)) in Excel, having in mind logarithm with base 10, ie. Excels =LOG() formula.
Unfortunately Java uses Math.log() for logarithm with base 2 and Math.log10() for base 10.
I could mention this before, but tests are consistent with Excel (log base10) formula, as was the original intention.

Therefore I would like to change in readme formula to use log10() to avoid confusion.

It seems like a part of internal implementation and serves only one purpose - to save calculated value into Gene.value field.

I wonder if there is another context, where Evaluator.calculateFitness is used independently.

• Update Evaluator description
• Update class names
• Update diagram
• Update style for consistency (blockquote)

I think it does not need tests because this is an elementary method, just ordinary setter

• change Mutator diagram - add BitwiseUtils field

• Docs description update

My propositions are:

variant 1: 1 / (1+log10(1+delta))
LogarithmicEvaluatorImpl

variant 2: (65535 - delta) / 65535
MaxDeltaEvaluatorImpl

G1 char[] ,50
G2 ,60
G3 ,09

Hello world
fjfowehfofw 1562
Hfsjfo hfhse 2213
e 2156

Evaluator G -> G.fitness

Crossover G+G -> G

Mutation G -> G

GenePool G{200}
Evaluator.evaluate
Crossover.cross(G1,G2)
Mutation(=.mutate

Main
Evaluation = WorldEvalutaion("H");

GenePool(Evaluation, Crossover, Mutation, RandomProvider)

=========================================
Evaluator
float setFitness(Gene)

EvaluatorImpl(char target)
Gene -> value[0] == target (100)

value[0] - różnica

target

98/100
99/100

100/100

2/100

As I can see this is already done in Kamil's PR, because Evaluator.setFitness is described as void method. Please check if everything is ok and let us know :)

Mutator.mutate(Gene): void
modyfikuje gen. Szansa na mutację to jest pole mutationChance w Mutatorze.

(testowanie przez randomprovider)

Sama modyfikacja genu - wylosowanie bita na dowolnej pozycji (0-15) i zmiana wartości 0/1.

Strategie:
SingleMutator - zmienia 1 bit
MultipleMutator - zmienia losową liczbę bitów (możliwe powtórzenia).

The value should be 65535 as it is equal to Character.MAX_VAL

• added getFloat method
• refactor getRandom -> getInt

I am not happy with having void method generateValue() in constructor, which indirectly sets this.value during object creation.

I think it should be
this.value = generateValue();
so method should return float value.

But I think it is a low priority change and we should consider this case in refactor later, and go to next steps of application first.

I think that we should stick to pattern:
Interface -> InterfaceImpl -> InterfaceImplTest
it is not descriptive from pragmatic perspective, but it shows code hierarchy.

Because CrossoverService changes value field of Gene need to add missing setter.

Add missing info about Gene.getFitness method

Headlines in readme are not displayed correctly on git. But Intelij show them properly. Do you have any idea what is going on with them?

I am pretty sure that test cases are not sufficient to check if implementation is correct.

Adding license could encourage contributors to join in. Besides, I think it is a pro move and I have not done this before, but I want to try. :)

More info: https://choosealicense.com/

• SingleMutator
• MultipleMutator