On 06/12/2008, Thomas Weber <[EMAIL PROTECTED]> wrote:
> Hi,

Hi.


> when building ga 0.9.4 with Octave 3.0.3, the following errors occur:
>
> =====================================================================
> Checking package...
[...]
> [ga]

Most of failing xtests in the ga function are tests related to some
behaviours that are not "wrong" (because these tests are statistical!)
but I didn't understand them when I tested the package (in August).


> warning: __ga_problem_return_variables__: some elements in list of return
> values are undefined

This kind of warning is expected, because at the moment some return
values are not implemented (patches welcome :)).


>   ***** xtest
>  min = [-1, 2];
>  assert (ga (struct ("fitnessfcn", @(x) rastriginsfcn (x - min), "nvars", 2,
> "options", gaoptimset ("FitnessLimit", 1e-7, "Generations", 1000,
> "PopInitRange", [-5; 5], "PopulationSize", 200))), min, 1e-6)
> !!!!! known failure
> error: assert (ga (struct ("fitnessfcn", @(x) rastriginsfcn (x - min);
> , "nvars", 2, "options", gaoptimset ("FitnessLimit", 1e-7, "Generations",
> 1000, "PopInitRange", [-5; 5], "PopulationSize", 200))),min,1e-6) expected
>   -1   2
> but got
>   -0.99999   2.00000
> maximum absolute error 7.67953e-06 exceeds tolerance 1e-06

In this xtest, the absolute error is very near to tolerance.
This xtest could be removed, but... is it possible that with 1000
GENERATIONS and POPULATIONS OF SIZE 200 there is not an absolute error
of at least 1e-13???

Please keep this xtest because it is interesting.


[...]
>   ***** xtest assert (ga (struct ("fitnessfcn", @rastriginsfcn, "nvars", 2,
> "options", gaoptimset ("FitnessLimit", 1e-7, "Generations", 1000))), zeros
> (1, 2), 1e-6)
> !!!!! known failure
> error: assert (ga (struct ("fitnessfcn", @rastriginsfcn, "nvars", 2,
> "options", gaoptimset ("FitnessLimit", 1e-7, "Generations", 1000))),zeros
> (1, 2),1e-6) expected
>    0   0
> but got
>    9.9496e-01  -3.5461e-10
> maximum absolute error 0.994959 exceeds tolerance 1e-06

More interesting of the xtest above: why the absolute error is 0.9?
There are 1000 GENERATIONS!

Please keep this xtest.


[...]
>   ***** xtest assert (ga (struct ("fitnessfcn", @rastriginsfcn, "nvars", 2,
> "options", gaoptimset ("FitnessLimit", 1e-7, "PopulationSize", 200))), zeros
> (1, 2), 1e-6)
> !!!!! known failure
> error: assert (ga (struct ("fitnessfcn", @rastriginsfcn, "nvars", 2,
> "options", gaoptimset ("FitnessLimit", 1e-7, "PopulationSize", 200))),zeros
> (1, 2),1e-6) expected
>    0   0
> but got
>    7.2191e-06   6.7790e-06
> maximum absolute error 7.21906e-06 exceeds tolerance 1e-06

Similar to the xtest above (that with 1000 generations and population
size of 200), but now there is only a great population (200): why the
absolute error is not at least 1e-10?

This xtest is interesting, but not as above: we could remove this if
it is necessary.


[...]
>   ***** xtest assert (ga (struct ("fitnessfcn", @(x) rastriginsfcn (x(1:2))
> + ((x(3) ** 2) - (cos (2 * pi * x(3))) + 1) + (x(4) ** 2), "nvars", 4,
> "options", gaoptimset ("EliteCount", 5, "FitnessLimit", 1e-7,
> "PopInitRange", [-2; 2], "PopulationSize", 200))), zeros (1, 4), 1e-6)
> !!!!! known failure
> error: assert (ga (struct ("fitnessfcn", @(x) rastriginsfcn (x (1:2)) + ((x
> (3) ^ 2) - (cos (2 * pi * x (3))) + 1) + (x (4) ^ 2);
> , "nvars", 4, "options", gaoptimset ("EliteCount", 5, "FitnessLimit", 1e-7,
> "PopInitRange", [-2; 2], "PopulationSize", 200))),zeros (1, 4),1e-6)
> expected
>    0   0   0   0
> but got
>    2.1638e-05  -2.5169e-05   1.0871e-04  -1.8070e-02
> maximum absolute error 0.0180704 exceeds tolerance 1e-06

Same as the previous one, but with 4 variables; why is not the error smaller?

This is interesting (because there are 4 variables), please keep this xtest.
We could instead put the tolerance from 1e-6 to 1e-3 (because working
with more variables it is less likely to find the minimum).







Now you are testing the functions in the ga/doc/old_stuff folder.

These functions are there because they were useful in previous
versions of the package, but now they are not useful and some are not
API compatible with the rest of the current package.

Some of these functions could be used as a skeleton for future work in
the ga package.
Others (i.e. bin2hex, bin2num, hex2bin, num2bin) could be useful in
the future for others packages of octave with only minor fixes.

I understand that it is not clean to put in the public repository not
working functions, but I decided to put them there to ensure that all
the work is public.
Is there a cleaner way to host in the package these "draft functions"?

[...]
> [crossoversinglepoint]
[...]
> [__bin2num__]
> PASSES 2 out of 2 tests
> [__bin2hex__]
[...]
> [__num2bin__]
> PASSES 2 out of 2 tests
> [__hex2bin__]
> PASSES 2 out of 2 tests
> =====================================================================
>
> Are all of these to be expected?

I hope I answered above.


>
>       Thomas

At the moment I'm busy at school (and I'm contributing more to the
control package than to the ga package :)), but I hope in next
hours/days to spend some time on the ga package.


Thanks,
Luca Favatella

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Octave-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/octave-dev

Reply via email to