Operators with bounds do not work correctly when bounds are provided as list instead of iterator.

[cmd-ntrf]

From chrison...@gmail.com on February 28, 2014 16:05:20

I took the example code, replaced the evaluate to use zdt4, and uncommented:

Functions zdt4 has bounds x1 = [0, 1], xn = [-5, 5], with n = 2, ..., 10

BOUND_LOW, BOUND_UP = [0.0] + [-5.0]_9, [1.0] + [5.0]_9

The problem in cxSimulatedBinaryBounded is that the 'low' and 'up' arguments can be iterable(lists) but are not iterators. This doesn't show up in the original example (zdt1) because the bounds are made into iterators with 'repeat'. I fixed this by adding some else statements: size = min(len(ind1), len(ind2)) if not isinstance(low, Iterable): low = repeat(low, size) else: low = iter(low) if not isinstance(up, Iterable): up = repeat(up, size) else: up = iter(up) What steps will reproduce the problem? 1. Run python 3.3 on the attached file, with deap 1.0.0 installed What is the expected output? What do you see instead? Expect a normal optimization, get: python nsga2_zdt4.py gen evals std min avg max
0 100 [ 0.2886756 30.82218893] [ 1.63319464e-02 8.39760854e+01] [ 0.48056234 154.56092183] [ 0.99361487 229.82580722] Traceback (most recent call last): File "nsga2_zdt4.py", line 126, in pop, stats = main() File "nsga2_zdt4.py", line 101, in main toolbox.mate(ind1, ind2) File "/opt/local/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/deap/tools/crossover.py", line 307, in cxSimulatedBinaryBounded xl = next(low) TypeError: 'list' object is not an iterator What version of the product are you using? On what operating system? deap 1.0.0 on OSX 10.9 Please provide any additional information below.

Attachment: nsga2_zdt4.py

Original issue: http://code.google.com/p/deap/issues/detail?id=26

[cmd-ntrf]

From felix.antoine.fortin on February 28, 2014 15:43:11

Excellent observation. This also affects three mutation operators: mutUniformInt, mutPolynomialBounded, and mutGaussian.

This is now fixed in dev branch: https://code.google.com/p/deap/source/detail?r=fee46dc23fc9a20a7d5861845d7669cde77936ad&name=dev FM: could you check my patch and make sure everything work as originally intended?

This will be part of release 1.0.1.

Thanks for the bug report!

Summary: Operators with bounds do not work correctly when bounds are provided as list instead of iterator. (was: The example nsga2 changed to use zdt4 with custom bounds crashes)
Status: Started
Owner: felix.antoine.fortin
Cc: f.derain...@gmail.com
Labels: -Priority-Medium Priority-High OpSys-All Component-Logic Usability Milestone-Release1.0.1

[cmd-ntrf]

From marc.andre.gardner on February 28, 2014 18:31:53

The only thing I would like to point out is that the proposed patch suppress the implicit validation of "low" and "up" lengths (as zip will just stop at the end of the shorter iterable, without error). Don't know if it's really worth caring (as the user have to make a mistake), but it may confuse some.

[cmd-ntrf]

From f.derain...@gmail.com on March 03, 2014 05:23:26

Using Iterables (or Iterators) doesn't seem like a good idea, it works for the first individual but not for the next ones as shown by the next example providing an iterable to the mutate function:

from deap import tools a = [1,2,3,4] from itertools import repeat mu = repeat(1, 4) print tools.mutGaussian(a, mu, 5, 1.0) ([1.6038949918853382, 3.586461546071653, 10.645379238040125, 5.001139284339358],) print tools.mutGaussian(a, mu, 5, 1.0) Traceback (most recent call last): File "", line 1, in File "deap/tools/mutation.py", line 44, in mutGaussian m = next(mu_iter) StopIteration

I think we have to use at least sequences.

[cmd-ntrf]

From felix.antoine.fortin on March 03, 2014 06:18:01

The same problem arises when using the toolbox. We therefore need to do the following 1- check wether low and up variable are sequences 1.a- If they are not, create an iterator with repeat with the proper size 1.b- If they are, make sure they are at least as long as the size of the individual.

Is the benefits of supporting single number and vectors as parameters for most mutation sufficient to justify this complexity?

[cmd-ntrf]

From f.derain...@gmail.com on March 05, 2014 07:35:39

Fixed by revisions b17243 and 9d4718 in default and revisions fee46d and 7a2090 in dev.

Status: Fixed