| Authors | Q | Grade |
|---|
| liss, suissad | Q1 | 100 |
Your report is very good and well-described. You literally leave nothing to the reader
to guess - every issue is covered by the report.
You discussion is also excellent.
- Your fitness measure is very good. You managed to explain very well the reasons that
lead you to use that function and its benefits over Koza's fitness.
- It's a good thing you've paid attention to Koza's paper and use 32 fixed Compare-Exchanges.
This fact is hardly mentioned in Koza's paper...
- To avoid bloating, you might have wanted to implement a mechanism that limits the
size of the offsprings in XO and Mutation operations. This is fairly easy to implement in
non-typed trees.
- Tournament groups of 10% of the population might be a bit too big. I'd usually
go for 0.5-1.5 times log(popsize). But that's me.
- Though you weren't asked to do so, it was responsible of you to test each evolved network
over the entire set of numbers, even though it was trained on a random subset.
Without that evaluation, you wouldn't be able to measure the correctness of
your evolved network...
- Your network annotation is beautiful!
- You have managed to evolve a very good network. 788 errors means that it correctly
sorts 98.80% of the inputs, using 62 Compare & Exchange operations. Well done.
|
| eliyahuu, kertis | Q1 | 98 |
Your report is very good and described very well. Your discussion is also very good.
- To avoid bloating, you might have wanted to implement a mechanism that limits the
size of the offsprings in XO and Mutation operations. This is fairly easy to implement in
non-typed trees.
- Missing: How do you create a random population on generation zero? (-2)
- Using a set of fixed permutations (your second suggested solution for the complexity
problem) can cause to specialist networks to evolve. Such networks will probably perform
very bad for inputs that are not in the learning set...
- Koza uses a fixed set of 32 comparators, and evolves only the second part of the
network. My guess is that by using this fixed set you might have been able to reduce
the runtime of your algorithm, and maybe find better solutions.
- It is also nice that you've tested your algorithm on smaller problems first. This
method is sometimes beneficial when trying to choose evolutionary parameters and when checking
your code validity.
|
| ilankad, wolfsonk | Q1 | 100 |
Very good report, informative and clear. Your discussion is also very good.
- It's a good thing you've paid attention to Koza's paper and use 32 fixed Compare-Exchanges.
This fact is hardly mentioned in Koza's paper...
- Good mutation operator. It is also described very well.
- To avoid bloating, you might have wanted to implement a mechanism that limits the
size of the offsprings in XO and Mutation operations. This is fairly easy to implement in
non-typed trees.
- Though you weren't asked to do so, it was responsible of you to test each evolved network
over the entire set of numbers, even though it was trained on a random subset.
Without that evaluation, you wouldn't be able to measure the correctness of
your evolved network...
- When choosing a subset of numbers for fitness calculation, you managed to
explain very well the ups and downs of methods 2 and 3. Method 1, though, has left
out without any exaplantion (it's a very bad one indeed, since the fitness values of the
individuals within the population are uncomparable if the set is chosen randomly for
each individual).
- It is also nice that you've tested your algorithm on smaller problems first. This
method is sometimes beneficial when trying to choose evolutionary parameters and when checking
your code validity.
|
| liadi, mazory | Q1 | 100 |
Very good report, informative and clear. Your discussion is also very good.
- Koza uses a fixed set of 32 comparators, and evolves only the second part of the
network. My guess is that by using this fixed set you might have been able to reduce
the runtime of your algorithm, and maybe find better solutions.
- To avoid bloating, you might have wanted to implement a mechanism that limits the
size of the offsprings in XO and Mutation operations. This is fairly easy to implement in
non-typed trees.
|
| bas, benichay | Q1 | 100 |
Very good report, informative and clear. Your discussion is also very good.
- Koza uses a fixed set of 32 comparators, and evolves only the second part of the
network. My guess is that by using this fixed set you might have been able to reduce
the runtime of your algorithm, and maybe find better solutions.
- To avoid bloating, you might have wanted to implement a mechanism that limits the
size of the offsprings in XO and Mutation operations. This is fairly easy to implement in
non-typed trees.
- Though you weren't asked to do so, you should have tested each evolved network
on the entire set of numbers. It's true that you gave an estimation of the error,
but the only method to determine the correctness of the network (i.e. % of error) is
to evaluate it with the entire dataset.
|
| einavbit, jasminme | Q1 | 100 |
Your report is very good, specifying all the required information. It
is also very appealing visually. Your discussion is good as well.
- It's a good thing you've paid attention to Koza's paper and use 32 fixed Compare-Exchanges.
This fact is hardly mentioned in Koza's paper...
- To avoid bloating, you might have wanted to implement a mechanism that limits the
size of the offsprings in XO and Mutation operations. This is fairly easy to implement in
non-typed trees.
- Though you weren't asked to do so, it was responsible of you to test each evolved network
over the entire set of numbers, even though it was trained on a random subset.
Without that evaluation, you wouldn't be able to measure the correctness of
your evolved network...
|
| alexta, zhok | Q1 | 50 |
Your report is very informative on the preparations side, yet lacks the actual work part
(and the discussion part, of course). Though this is not a programming course, you were
supposed to implement a working solution - without it your work lacks a major part.
Such solution is possible in both scheme and Java (and in many other programming languages),
and you should have made the effort to debug your code and make it work.
Some general remarks:
- Too much Copy & Paste: You mention that the solution is a route of cities in France... :)
- It's a good thing you've paid attention to Koza's paper and use 32 fixed Compare-Exchanges.
This fact is hardly mentioned in Koza's paper...
- To avoid bloating, you might have wanted to implement a mechanism that limits the
size of the offsprings in XO and Mutation operations. This is fairly easy to implement in
non-typed trees.
- A maximal depth of 20 is pretty big - so big it might be the cause of the crashes. If, for
example, the average branching factor is 2 (each Node in the tree have two children) then
each tree will have 2^20 nodes!!! A more practical value is somewhere between 6 to 12.
|
| amitbenb, merhavi | Q1 | 90 |
Your report is very brief and lacks some descriptions of the work done. Your discussion
is also pretty short and only points out the difference between your results and Koza's.
Here are some remarks:
- All the evolutionary parameters are missing: XO and Mutation types and rates, selection
method etc. Really missing is the Fitness function: how do you evaluate the fitness
of an individual?
- Assuming that you've used Koza's fitness, a fitness of 22.4 means that the network had
22 errors and have used 40 Compare & Exchange operations, not that it was able to perfectly
sort the input set using 224 comparators.
- Koza uses a fixed set of 32 comparators, and evolves only the second part of the
network. My guess is that by using this fixed set you might have been able to reduce
the runtime of your algorithm, and maybe find better solutions.
- To evaluate the performance and correctness of your evolved network, you should
have tested the netword on the entire set of possible inputs. Otherwise you have no
idea how does your evolved network sorts inputs that are not in the random group. Note
that you should only perform this test once per evolved network, and not for each individual.
|
| aharob, blesser | Q1 | 100 |
Your report and discussion are very good, and the work is superb: You have managed to
evolve a very good sorting network.
- Good thing you mentioned the Zero-One theorem!
- It's a good thing you've paid attention to Koza's paper and use 32 fixed Compare-Exchanges.
This fact is hardly mentioned in Koza's paper...
- To avoid bloating, you might have wanted to implement a mechanism that limits the
size of the offsprings in XO and Mutation operations. This is fairly easy to implement in
non-typed trees.
- A maximal depth of 20 is pretty big. If, for example, the average branching factor is 2
(each Node in the tree have two children) then each tree will have 2^20 nodes!!!
A more practical value is somewhere between 6 to 12.
- Though you weren't asked to do so, it was responsible of you to test each evolved network
over the entire set of numbers, even though it was trained on a random subset.
Without that evaluation, you wouldn't be able to measure the correctness of
your evolved network...
- You have managed to evolve a very good network. 768 errors means that it correctly
sorts 98.83% of the inputs, using 64 Compare & Exchange operations. Well done.
|
| beckerli, ohanaar | Q2 | 112 |
Excellent report. It describes your work very well and the discussion is also very good.
It's a good thing you had the guts to publish also the not-so-good results (for example,
when you tried to check your robots on different room settings); in many
papers these parts are left unpublished, but failures are part of the work!
- +10 for doing the second task.
- It's nice that you didn't stick to Koza's paper and took the freedom to add functions
(such as
+) to the function set.
- You've came up with a nice Mutation operator, which serves both to give some variety to
the population as well as fighting the tree bloating phenomenon/
- Another way to avoid bloating, is a mechanism that limits the size of the offsprings in
XO and Mutation operations. This is fairly easy to implement in non-typed trees.
- Your alternative fitness function (which intended to produce shorter paths) is a nice
idea. Too bad it didn't work... :)
- It's nice that you've tested your robot on other rooms too. Too bad the results were
bad... (this is a clear case of overfitting). Maybe eariler generations will perform better
on other rooms?
- Your live demonstration is neat. Maybe a heading indicator would be a great
improvement, since in some solutions the robot is going backward instead forward.
OTHER TEAMS: I recommend to check it out! +2
|
| ronav | Q2 | 107 |
The report is very good indeed, and your code is excellent as always. The lack of discussion
and conclusions is a bummer...
- +10 for doing the second task.
- Too much Copy & Paste - Your document title is "Solving the Bin Packing Problem with GA"... :)
- It's nice that you didn't stick to Koza's paper and took the freedom to add functions
(such as
PROGN3) to the function set.
- The annotations of the evolved programs are beautiful. In addition, the analysis of
similarities between the evolved programs is extremely good.
- The applet simumation is excellent! it really contributes to the understading of
the robot behaviour. Wish I could only set its speed... OTHER TEAMS: I recommend to check it out! +2
- Where is your discussion? This is such a great report - it really need some conclusions. -5
|
| abirs, yaakovog | Q2 | 103 |
Your report is basically very good, but there are some items you missed, all of
them detailed below. Your discussion is also very brief and lacks real conclusions about
the evolutionary process.
- +10 for doing the second task.
- It's nice that you didn't stick to Koza's paper and took the freedom to add functions
(such as
*, +, -) to the function set and some terminals (such as
random and numerical constants) to the terminal set.
- To avoid bloating, you might have wanted to implement a mechanism that limits the
size of the offsprings in XO and Mutation operations. This is fairly easy to implement in
non-typed trees.
- You've misinterpreted our request: We asked for plots of several individuals from the
same run - not for the best individuals from several runs. Your plots are also very informative
and shows the differences between the runs, but the idea was to show how the individuals evolve
as the generation count increases.
- If the fitness value is the number of eaten apples, how do some individuals reach
fitness values of 500?! there are only 56 apples... Either there is a bug in your code,
or you failed to describe the fitness function that you've used in your program.
- Your discussion lacks real conclusions - how the different evolutionary parameters effect
the results etc. Such a large project surely have some conclusions... -5
- Missing: How do you create a random population on generation zero? (-2)
- Your population sizes are extremly small. Under 50 indivudals, it's really hard to
have enough genome variance to sucessfully perform an evolutionary process.
|
| eltzerh, zeharias | Q2 | 115 |
Well, this was a long story... :) I'm glad you made it to the end (I must do it, I get paid for it)
and were able to produce some robots. Your report is very good, though irrelevant
in some parts (the x+1 for example) - I would add it in a separate link.
But that's me. Your discussion is good. It is also nice that you've made some experiments
with different number of sensors.
- +10 for doing the second task.
- To avoid bloating, you might have wanted to implement a mechanism that limits the
size of the offsprings in XO and Mutation operations. This is fairly easy to implement in
non-typed trees.
- Bonus: the experiments with different number of sensors are interesting. Your conclusions
from it are also very good. (+5)
- Your demonstation program is really nice, though I think it has some bugs - when clicking
on the 'next' button, not every generation has its own plot. If you've included only a subset
of the routes (which is legitimate), it would have been nicer to let the 'next' button
jump to the next generation that have a plot connected to it.
|
| nigri | Q2 | 108 |
A very good report, though your evolved robots haven't manage to follow the room walls.
The discussion is also very good.
- +10 for doing the second task.
- To avoid bloating, you might have wanted to implement a mechanism that limits the
size of the offsprings in XO and Mutation operations. This is fairly easy to implement in
non-typed trees.
- A minor remark: Koza's
MF, MB, TL and TR do return values, as
described in p.6 of his paper.
- Missing: How do you create a random population on generation zero? (-2)
|