IntegerVector Encoding should have more flexible bounds

[abeham]

Exactly as in the RealVectorEncoding, but with an additional column specifying a step size.

[abeham]

r7680:7681: added branch of IntegerVectorEncoding plugin and new operators

[abeham]

r7686: Updated integer vector encoding

• Added advanced bounds to all operators
• Added new operators
• Changed DiscreteCrossover to work with >= 2 parents

[abeham]

r7699: Added UniformSomePositionsManipulator and minor changes

[abeham]

r7715: fixed operator to respect bounds

[abeham]

r8017:

• Renamed some crossovers
• Ported some additional crossovers from the real-vector plugin
• Introduced BoundedIntegerVector* base classes

[abeham]

r8018: synced with trunk

[abeham]

r8019: reintegrated branch

[abeham]

r8020: removed branch

[abeham]

r8021: fixed references

[abeham]

r8023: fixed unit tests

[abeham]

r8025: updated scheduling branch

r8027: updated metaopt branch

[ascheibe]

I have looked over the changes and have some minor comments:

• I think in the IntegerVectorCreator the AfterDeserialization method should throw an exception if min and max are null (though this will probably be never the case?)
• The documentation comments for the Apply method in UniformRandomIntegerVectorCreator should be updated.
• StdDevStrategyVectorCrossover.cs as well as StdDevStrategyVectorCreator.cs are in the Manipulators source folder. Shouldn't they be located in the Creators and Crossovers folders?
• Round/Floor/CeilingFeasible is contained in the Crossover and the Manipulator base classes. Maybe we should move them to an own source file so that the code doesn't get duplicated.
• BoundedIntegerVectorManipulator: The exception thrown by the Manipulate method says UniformSomePositionsManipulator.

[abeham]

Thank you for the review and the comments!

r8184:8185

• Updated documentation and error messages
• Added an extra base class to unify the implementation of the round methods
• Moved strategy parameter vectors to separate folder (as in RealVectorEncoding)

Regarding the other comment:

• Throwing an exception in IntegerVectorCreator.AfterDeserialization would break backwards compatibility. Because they're ValueLookupParameters it is feasible to assume that their value can be null.

If you have no further comments, please set the ticket as readytorelease.

[ascheibe]

Thank you!