You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
|
Feb
(1) |
Mar
(6) |
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(3) |
Oct
(2) |
Nov
(3) |
Dec
(2) |
2007 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(13) |
Jun
(3) |
Jul
(3) |
Aug
|
Sep
|
Oct
(1) |
Nov
(15) |
Dec
(7) |
2009 |
Jan
(12) |
Feb
(5) |
Mar
(2) |
Apr
(4) |
May
(10) |
Jun
(6) |
Jul
(2) |
Aug
(6) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
From: Gary P. <gpa...@gm...> - 2009-05-04 07:03:26
|
Hi, The MOPSO class has actually been removed from the repository. The new Multi-objective framework within CIlib, will enable MOPSO by defining how guides (knowledge) is transferred between the sub-swarms. So in essence: Yes, we've fix it :) Regards, Gary lab...@gm... wrote: > Is that going to be updated in 0.7? I see a lot of "todo" in the code > and I might have to use it soon. > TIA > M > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Register Now & Save for Velocity, the Web Performance & Operations > Conference from O'Reilly Media. Velocity features a full day of > expert-led, hands-on workshops and two days of sessions from industry > leaders in dedicated Performance & Operations tracks. Use code vel09scf > and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf > > > ------------------------------------------------------------------------ > > _______________________________________________ > Cilib-users mailing list > Cil...@li... > https://lists.sourceforge.net/lists/listinfo/cilib-users |
From: Gary P. <gpa...@gm...> - 2009-05-03 09:14:45
|
Hi, I'll find out and let you know about this on Monday. Regards, Gary lab...@gm... wrote: > Is that going to be updated in 0.7? I see a lot of "todo" in the code > and I might have to use it soon. > TIA > M > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Register Now & Save for Velocity, the Web Performance & Operations > Conference from O'Reilly Media. Velocity features a full day of > expert-led, hands-on workshops and two days of sessions from industry > leaders in dedicated Performance & Operations tracks. Use code vel09scf > and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf > > > ------------------------------------------------------------------------ > > _______________________________________________ > Cilib-users mailing list > Cil...@li... > https://lists.sourceforge.net/lists/listinfo/cilib-users |
From: <lab...@gm...> - 2009-04-29 19:05:45
|
Is that going to be updated in 0.7? I see a lot of "todo" in the code and I might have to use it soon. TIA M |
From: <lab...@gm...> - 2009-04-29 17:35:58
|
I see that there is something to compute the diameter of a swarm but is there something to measure diversity in PSO? |
From: <lab...@gm...> - 2009-04-24 15:44:57
|
Great! On Apr 19, 2009 9:51am, Gary Pampara <gpa...@gm...> wrote: > Hi all, > It's been a while since we posted any info regarding a new release of > CIlib, so here we go :) > We recently have had quite a few patch submissions, thanks to the > authors for the patches, most of them have been added to the framework > with little or zero changes needed. > The next version of CIlib, version 0.7, will be a rather large release > with many features being added, together with probably even more bug > fixes. > Notable feature changes are: > - Inclusions to enable the operation of Multi-Objective (MO) algorithms > such as VEPSO, VEGA etc. While VEPSO will be implemented, VEGA and > other MO Algorithms will be very simple to add. > - Next iteration of the Games framework (it's still very young so expect > a lot of changes in the future. > - A lot of documentation has been added to the API - always a good > thing. > - Niching algorithm support, including the NichePSO. > - Ability to have dynamic environments applied to multi-objective > algorithms. > Various bug fixes have been applied and a few core framework API changes > have been made - all of which are a very good step forward. The number > of unit tests have increased quite a bit, which makes me VERY happy. > So, that's it :) Small update but I'm sure that you all are looking > forward to the functionality. > We are planning the release for the end of April / early May. Give us a > shout if you are unsure of something :) > Regards, > Gary > ------------------------------------------------------------------------------ > Stay on top of everything new and different, both inside and > around Java (TM) technology - register by April 22, and save > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. > 300 plus technical and hands-on sessions. Register today. > Use priority code J9JMT32. http://p.sf.net/sfu/p > _______________________________________________ > Cilib-users mailing list > Cil...@li... > https://lists.sourceforge.net/lists/listinfo/cilib-users |
From: Gary P. <gpa...@gm...> - 2009-04-19 13:51:24
|
Hi all, It's been a while since we posted any info regarding a new release of CIlib, so here we go :) We recently have had quite a few patch submissions, thanks to the authors for the patches, most of them have been added to the framework with little or zero changes needed. The next version of CIlib, version 0.7, will be a rather large release with many features being added, together with probably even more bug fixes. Notable feature changes are: - Inclusions to enable the operation of Multi-Objective (MO) algorithms such as VEPSO, VEGA etc. While VEPSO will be implemented, VEGA and other MO Algorithms will be very simple to add. - Next iteration of the Games framework (it's still very young so expect a lot of changes in the future. - A lot of documentation has been added to the API - always a good thing. - Niching algorithm support, including the NichePSO. - Ability to have dynamic environments applied to multi-objective algorithms. Various bug fixes have been applied and a few core framework API changes have been made - all of which are a very good step forward. The number of unit tests have increased quite a bit, which makes me VERY happy. So, that's it :) Small update but I'm sure that you all are looking forward to the functionality. We are planning the release for the end of April / early May. Give us a shout if you are unsure of something :) Regards, Gary |
From: Gary P. <gpa...@gm...> - 2009-03-30 18:54:14
|
Hi, Basically, we need another output defined. We are currently working on a generic solution whereby multiple output formats etc will be allowed, but until then, you could look at the MeausementSuite class. It uses a SynchronizedOutputBuffer to collect the data, you could create a new class that returns the data to stdout for example so that the calling application can capture it. Regards, Gary David wrote: > Hi, > The CILib user guide (direct usage in code) seems to assume that the user > will look to write results out to a file. Initially, I began looking into > writing XML classes to do what I want to do. However, I would rather have > results returned to the calling program. > > Can I ask, how should I be arranging my code to support that requirement? > > > Regards, > David > |
From: David <dav...@nt...> - 2009-03-30 17:48:37
|
Hi, The CILib user guide (direct usage in code) seems to assume that the user will look to write results out to a file. Initially, I began looking into writing XML classes to do what I want to do. However, I would rather have results returned to the calling program. Can I ask, how should I be arranging my code to support that requirement? Regards, David |
From: Gary P. <gpa...@gm...> - 2009-02-05 13:08:45
|
Hi, I spent some time looking at the code, and I believe that you are correct. It should be dimension and not i that is replaced. I have corrected the error and committed to the Git repository. http://github.com/gpampara/cilib/commit/3575d8cdc4cc839f70670aab2ca26ee111604edc Kind regards, Gary lab...@gm... wrote: > Yes, that works but it seems to me that there is a bug in the dimension > that is set. Shouldn't it be: > position.setReal(dimension,tmp) instead of position.setReal(i,tmp) in > the mutate(particle) function. Do you agree? > TIA. > > On Jan 30, 2009 8:23am, Gary Pampara <gpa...@gm...> wrote: >> Patch attached. >> >> >> >> I've had no means to test it and the change is very small. Please let > me know if it works. From the looks of the error, this should solve it. >> >> >> >> I've committed the patch to the master branch already. >> >> >> >> Regards, >> >> Gary >> >> >> >> Gary Pampara wrote: >> >> >> Sure thing. >> >> >> >> I'll post the patch once it's done. Should be a very minor change. >> >> >> >> Regards, >> >> Gary >> >> >> >> lab...@gm... wrote: >> >> >> Hello, >> >> >> >> If the patch for this problem could be posted on the mailing list, I > could update my local version before waiting for the new version. TIA. >> >> >> >> >> >> On Jan 29, 2009 11:09am, Gary Pampara gpa...@gm...> wrote: >> >> > Hi, >> >> > >> >> > >> >> > >> >> > Yes, this is definitely a bug. It should work for Ints as well. > I'll post a patch for a correction to this issue in a while. >> >> > >> >> > >> >> > >> >> > We are currently refactoring quite a bit in the library to make > various operations / usage issues better, as well as a major update to > the Javadoc. I'll just need to create a branch to apply the fix. >> >> > >> >> > >> >> > >> >> > Would you like the patch posted on the mailing list, or a direct > email? This will then also be included in the next release. >> >> > >> >> > >> >> > >> >> > Thanks for raising this :) >> >> > >> >> > >> >> > >> >> > Regards, >> >> > >> >> > Gary >> >> > >> >> > >> >> > >> >> > myriam abramson wrote: >> >> > >> >> > >> >> > Hello, >> >> > >> >> > I am trying to evolve integers for an allocation problem, > Z(0,20)^10, and I tried to specific MutationPositionUpdateStrategy but > unfortunately it does not seem to work for integers. See trace below. Is > there a rational for that that I'm missing? I was thinking that instead > of evolving a position by incremental velocity changes, mutation would > sometimes just produce a new integer. Please let me know if that makes > sense. It wouldn't be too hard to implement it on my end. >> >> > >> >> > >> >> > >> >> > Exception in thread "main" java.lang.ClassCastException: > net.sourceforge.cilib.type.types.Int > http://net.sourceforge.cilib.type.types.Int> cannot be cast to > net.sourceforge.cilib.type.types.Real >> >> > >> >> > at > net.sourceforge.cilib.pso.positionupdatestrategies.MutationPositionUpdateStrategy.mutate(MutationPositionUpdateStrategy.java:141) >> >> > >> >> > at > net.sourceforge.cilib.pso.positionupdatestrategies.MutationPositionUpdateStrategy.updatePosition(MutationPositionUpdateStrategy.java:118) >> >> > >> >> > at > net.sourceforge.cilib.pso.particle.StandardParticle.updatePosition(StandardParticle.java:156) >> >> > >> >> > at > net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:70) >> >> > >> >> > at > net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:36) >> >> > >> >> > at net.sourceforge.cilib.pso.PSO.algorithmIteration(PSO.java:125) >> >> > >> >> > at > net.sourceforge.cilib.algorithm.Algorithm.performIteration(Algorithm.java:140) >> >> > >> >> > at net.sourceforge.cilib.algorithm.Algorithm.run(Algorithm.java:182) >> >> > >> >> > at > mil.navy.nrl.optimization.route.RoutePlanning.run(RoutePlanning.java:142) >> >> > >> >> > at > mil.navy.nrl.optimization.route.RoutePlanning.main(RoutePlanning.java:192) >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > > ------------------------------------------------------------------------ >> >> > >> >> > >> >> > >> >> > > ------------------------------------------------------------------------------ >> >> > >> >> > This SF.net email is sponsored by: >> >> > >> >> > SourcForge Community >> >> > >> >> > SourceForge wants to tell your story. >> >> > >> >> > http://p.sf.net/sfu/sf-spreadtheword >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > > ------------------------------------------------------------------------ >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > >> >> > Cilib-users mailing list >> >> > >> >> > Cil...@li... >> >> > >> >> > https://lists.sourceforge.net/lists/listinfo/cilib-users >> >> > >> >> > >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> >> >> > ------------------------------------------------------------------------------ >> >> This SF.net email is sponsored by: >> >> SourcForge Community >> >> SourceForge wants to tell your story. >> >> http://p.sf.net/sfu/sf-spreadtheword >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> >> Cilib-users mailing list >> >> Cil...@li... >> >> https://lists.sourceforge.net/lists/listinfo/cilib-users >> >> >> >> >> > ------------------------------------------------------------------------------ >> >> This SF.net email is sponsored by: >> >> SourcForge Community >> >> SourceForge wants to tell your story. >> >> http://p.sf.net/sfu/sf-spreadtheword >> >> _______________________________________________ >> >> Cilib-users mailing list >> >> Cil...@li... >> >> https://lists.sourceforge.net/lists/listinfo/cilib-users >> >> > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > > > ------------------------------------------------------------------------ > > _______________________________________________ > Cilib-users mailing list > Cil...@li... > https://lists.sourceforge.net/lists/listinfo/cilib-users |
From: Gary P. <gpa...@gm...> - 2009-02-02 17:33:53
|
Hi, While the domain strings allow for the mixed types, a PositionUpdateStrategy to handle the data types in the manner in which you are describing would need to be written :) I cannot see any reason why it would not be reasonable. It naturally depends on the current problem, but if that's a valid solution, the library can accommodate such a PositionUpdateStrategy. Regards, Gary lab...@gm... wrote: > I was wondering that if I had a domain string with mixed types like > "B^10,R(0.0,5.0)^10,Z(0,20)^10", I should make my own > PositionUpdateStrategy to handle those various types? For example, I > would like to apply BinaryPositionUpdate for the bits, and > StandardPositionUpdate for the rest? Does that sound reasonable? > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > > > ------------------------------------------------------------------------ > > _______________________________________________ > Cilib-users mailing list > Cil...@li... > https://lists.sourceforge.net/lists/listinfo/cilib-users |
From: Gary P. <gpa...@gm...> - 2009-02-02 17:31:37
|
Hi, The email server was down for the weekend, some maintenance required the servers to be powered off. I'm still looking at the question regarding the dimension instead of the i-th dimension. I'll need to find that paper describing the process again just to double check. Yeah, that is correct. Strictly speaking though, the comparison should be done with Double.compare(). I'm currently working on the Type system and doing a large refactor to make the API a little simpler to use. I'll make sure this is corrected. Regards, Gary lab...@gm... wrote: > Also, I think that to handle mutation for a bit vector, the setReal > method in Bit.java should be: > > public void setReal(double value) { > if (value <= 0.5) > this.state = false; > else this.state = true; > > } > > instead of > public void setReal(double value) { > if (value == 0.0) > this.state = false; > else this.state = true; > > } > Do you agree? > > > On Jan 30, 2009 10:52am, lab...@gm... wrote: > > Yes, that works but it seems to me that there is a bug in the > dimension that is set. Shouldn't it be: > > position.setReal(dimension,tmp) instead of position.setReal(i,tmp) in > the mutate(particle) function. Do you agree? > > TIA. > > > > On Jan 30, 2009 8:23am, Gary Pampara gpa...@gm...> wrote: > > > Patch attached. > > > > > > > > > > > > I've had no means to test it and the change is very small. Please > let me know if it works. From the looks of the error, this should solve it. > > > > > > > > > > > > I've committed the patch to the master branch already. > > > > > > > > > > > > Regards, > > > > > > Gary > > > > > > > > > > > > Gary Pampara wrote: > > > > > > > > > Sure thing. > > > > > > > > > > > > I'll post the patch once it's done. Should be a very minor change. > > > > > > > > > > > > Regards, > > > > > > Gary > > > > > > > > > > > > lab...@gm... wrote: > > > > > > > > > Hello, > > > > > > > > > > > > If the patch for this problem could be posted on the mailing list, > I could update my local version before waiting for the new version. TIA. > > > > > > > > > > > > > > > > > > On Jan 29, 2009 11:09am, Gary Pampara gpa...@gm...> wrote: > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, this is definitely a bug. It should work for Ints as well. > I'll post a patch for a correction to this issue in a while. > > > > > > > > > > > > > > > > > > > > > > > > > > > > We are currently refactoring quite a bit in the library to make > various operations / usage issues better, as well as a major update to > the Javadoc. I'll just need to create a branch to apply the fix. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Would you like the patch posted on the mailing list, or a direct > email? This will then also be included in the next release. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for raising this :) > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > > > > > > > > > > myriam abramson wrote: > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > I am trying to evolve integers for an allocation problem, > Z(0,20)^10, and I tried to specific MutationPositionUpdateStrategy but > unfortunately it does not seem to work for integers. See trace below. Is > there a rational for that that I'm missing? I was thinking that instead > of evolving a position by incremental velocity changes, mutation would > sometimes just produce a new integer. Please let me know if that makes > sense. It wouldn't be too hard to implement it on my end. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Exception in thread "main" java.lang.ClassCastException: > net.sourceforge.cilib.type.types.Int > http://net.sourceforge.cilib.type.types.Int> cannot be cast to > net.sourceforge.cilib.type.types.Real > > > > > > > > > > > > > > at > net.sourceforge.cilib.pso.positionupdatestrategies.MutationPositionUpdateStrategy.mutate(MutationPositionUpdateStrategy.java:141) > > > > > > > > > > > > > > at > net.sourceforge.cilib.pso.positionupdatestrategies.MutationPositionUpdateStrategy.updatePosition(MutationPositionUpdateStrategy.java:118) > > > > > > > > > > > > > > at > net.sourceforge.cilib.pso.particle.StandardParticle.updatePosition(StandardParticle.java:156) > > > > > > > > > > > > > > at > net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:70) > > > > > > > > > > > > > > at > net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:36) > > > > > > > > > > > > > > at net.sourceforge.cilib.pso.PSO.algorithmIteration(PSO.java:125) > > > > > > > > > > > > > > at > net.sourceforge.cilib.algorithm.Algorithm.performIteration(Algorithm.java:140) > > > > > > > > > > > > > > at > net.sourceforge.cilib.algorithm.Algorithm.run(Algorithm.java:182) > > > > > > > > > > > > > > at > mil.navy.nrl.optimization.route.RoutePlanning.run(RoutePlanning.java:142) > > > > > > > > > > > > > > at > mil.navy.nrl.optimization.route.RoutePlanning.main(RoutePlanning.java:192) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > > > This SF.net email is sponsored by: > > > > > > > > > > > > > > SourcForge Community > > > > > > > > > > > > > > SourceForge wants to tell your story. > > > > > > > > > > > > > > http://p.sf.net/sfu/sf-spreadtheword > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > Cilib-users mailing list > > > > > > > > > > > > > > Cil...@li... > > > > > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/cilib-users > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > This SF.net email is sponsored by: > > > > > > SourcForge Community > > > > > > SourceForge wants to tell your story. > > > > > > http://p.sf.net/sfu/sf-spreadtheword > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > _______________________________________________ > > > > > > Cilib-users mailing list > > > > > > Cil...@li... > > > > > > https://lists.sourceforge.net/lists/listinfo/cilib-users > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > This SF.net email is sponsored by: > > > > > > SourcForge Community > > > > > > SourceForge wants to tell your story. > > > > > > http://p.sf.net/sfu/sf-spreadtheword > > > > > > _______________________________________________ > > > > > > Cilib-users mailing list > > > > > > Cil...@li... > > > > > > https://lists.sourceforge.net/lists/listinfo/cilib-users > > > > > > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > > > ------------------------------------------------------------------------ > > _______________________________________________ > Cilib-users mailing list > Cil...@li... > https://lists.sourceforge.net/lists/listinfo/cilib-users |
From: <lab...@gm...> - 2009-02-02 17:16:59
|
Also, I think that to handle mutation for a bit vector, the setReal method in Bit.java should be: public void setReal(double value) { if (value <= 0.5) this.state = false; else this.state = true; } instead of public void setReal(double value) { if (value == 0.0) this.state = false; else this.state = true; } Do you agree? On Jan 30, 2009 10:52am, lab...@gm... wrote: > Yes, that works but it seems to me that there is a bug in the dimension that is set. Shouldn't it be: > position.setReal(dimension,tmp) instead of position.setReal(i,tmp) in the mutate(particle) function. Do you agree? > TIA. > > On Jan 30, 2009 8:23am, Gary Pampara gpa...@gm...> wrote: > > Patch attached. > > > > > > > > I've had no means to test it and the change is very small. Please let me know if it works. From the looks of the error, this should solve it. > > > > > > > > I've committed the patch to the master branch already. > > > > > > > > Regards, > > > > Gary > > > > > > > > Gary Pampara wrote: > > > > > > Sure thing. > > > > > > > > I'll post the patch once it's done. Should be a very minor change. > > > > > > > > Regards, > > > > Gary > > > > > > > > lab...@gm... wrote: > > > > > > Hello, > > > > > > > > If the patch for this problem could be posted on the mailing list, I could update my local version before waiting for the new version. TIA. > > > > > > > > > > > > On Jan 29, 2009 11:09am, Gary Pampara gpa...@gm...> wrote: > > > > > Hi, > > > > > > > > > > > > > > > > > > > > Yes, this is definitely a bug. It should work for Ints as well. I'll post a patch for a correction to this issue in a while. > > > > > > > > > > > > > > > > > > > > We are currently refactoring quite a bit in the library to make various operations / usage issues better, as well as a major update to the Javadoc. I'll just need to create a branch to apply the fix. > > > > > > > > > > > > > > > > > > > > Would you like the patch posted on the mailing list, or a direct email? This will then also be included in the next release. > > > > > > > > > > > > > > > > > > > > Thanks for raising this :) > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > > myriam abramson wrote: > > > > > > > > > > > > > > > Hello, > > > > > > > > > > I am trying to evolve integers for an allocation problem, Z(0,20)^10, and I tried to specific MutationPositionUpdateStrategy but unfortunately it does not seem to work for integers. See trace below. Is there a rational for that that I'm missing? I was thinking that instead of evolving a position by incremental velocity changes, mutation would sometimes just produce a new integer. Please let me know if that makes sense. It wouldn't be too hard to implement it on my end. > > > > > > > > > > > > > > > > > > > > Exception in thread "main" java.lang.ClassCastException: net.sourceforge.cilib.type.types.Int http://net.sourceforge.cilib.type.types.Int> cannot be cast to net.sourceforge.cilib.type.types.Real > > > > > > > > > > at net.sourceforge.cilib.pso.positionupdatestrategies.MutationPositionUpdateStrategy.mutate(MutationPositionUpdateStrategy.java:141) > > > > > > > > > > at net.sourceforge.cilib.pso.positionupdatestrategies.MutationPositionUpdateStrategy.updatePosition(MutationPositionUpdateStrategy.java:118) > > > > > > > > > > at net.sourceforge.cilib.pso.particle.StandardParticle.updatePosition(StandardParticle.java:156) > > > > > > > > > > at net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:70) > > > > > > > > > > at net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:36) > > > > > > > > > > at net.sourceforge.cilib.pso.PSO.algorithmIteration(PSO.java:125) > > > > > > > > > > at net.sourceforge.cilib.algorithm.Algorithm.performIteration(Algorithm.java:140) > > > > > > > > > > at net.sourceforge.cilib.algorithm.Algorithm.run(Algorithm.java:182) > > > > > > > > > > at mil.navy.nrl.optimization.route.RoutePlanning.run(RoutePlanning.java:142) > > > > > > > > > > at mil.navy.nrl.optimization.route.RoutePlanning.main(RoutePlanning.java:192) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > This SF.net email is sponsored by: > > > > > > > > > > SourcForge Community > > > > > > > > > > SourceForge wants to tell your story. > > > > > > > > > > http://p.sf.net/sfu/sf-spreadtheword > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Cilib-users mailing list > > > > > > > > > > Cil...@li... > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/cilib-users > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > ------------------------------------------------------------------------------ > > > > This SF.net email is sponsored by: > > > > SourcForge Community > > > > SourceForge wants to tell your story. > > > > http://p.sf.net/sfu/sf-spreadtheword > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > > > Cilib-users mailing list > > > > Cil...@li... > > > > https://lists.sourceforge.net/lists/listinfo/cilib-users > > > > > > > > > > ------------------------------------------------------------------------------ > > > > This SF.net email is sponsored by: > > > > SourcForge Community > > > > SourceForge wants to tell your story. > > > > http://p.sf.net/sfu/sf-spreadtheword > > > > _______________________________________________ > > > > Cilib-users mailing list > > > > Cil...@li... > > > > https://lists.sourceforge.net/lists/listinfo/cilib-users > > > > |
From: <lab...@gm...> - 2009-02-02 17:13:41
|
I was wondering that if I had a domain string with mixed types like "B^10,R(0.0,5.0)^10,Z(0,20)^10", I should make my own PositionUpdateStrategy to handle those various types? For example, I would like to apply BinaryPositionUpdate for the bits, and StandardPositionUpdate for the rest? Does that sound reasonable? |
From: <lab...@gm...> - 2009-01-30 15:52:30
|
Yes, that works but it seems to me that there is a bug in the dimension that is set. Shouldn't it be: position.setReal(dimension,tmp) instead of position.setReal(i,tmp) in the mutate(particle) function. Do you agree? TIA. On Jan 30, 2009 8:23am, Gary Pampara <gpa...@gm...> wrote: > Patch attached. > > > > I've had no means to test it and the change is very small. Please let me know if it works. From the looks of the error, this should solve it. > > > > I've committed the patch to the master branch already. > > > > Regards, > > Gary > > > > Gary Pampara wrote: > > > Sure thing. > > > > I'll post the patch once it's done. Should be a very minor change. > > > > Regards, > > Gary > > > > lab...@gm... wrote: > > > Hello, > > > > If the patch for this problem could be posted on the mailing list, I could update my local version before waiting for the new version. TIA. > > > > > > On Jan 29, 2009 11:09am, Gary Pampara gpa...@gm...> wrote: > > > Hi, > > > > > > > > > > > > Yes, this is definitely a bug. It should work for Ints as well. I'll post a patch for a correction to this issue in a while. > > > > > > > > > > > > We are currently refactoring quite a bit in the library to make various operations / usage issues better, as well as a major update to the Javadoc. I'll just need to create a branch to apply the fix. > > > > > > > > > > > > Would you like the patch posted on the mailing list, or a direct email? This will then also be included in the next release. > > > > > > > > > > > > Thanks for raising this :) > > > > > > > > > > > > Regards, > > > > > > Gary > > > > > > > > > > > > myriam abramson wrote: > > > > > > > > > Hello, > > > > > > I am trying to evolve integers for an allocation problem, Z(0,20)^10, and I tried to specific MutationPositionUpdateStrategy but unfortunately it does not seem to work for integers. See trace below. Is there a rational for that that I'm missing? I was thinking that instead of evolving a position by incremental velocity changes, mutation would sometimes just produce a new integer. Please let me know if that makes sense. It wouldn't be too hard to implement it on my end. > > > > > > > > > > > > Exception in thread "main" java.lang.ClassCastException: net.sourceforge.cilib.type.types.Int http://net.sourceforge.cilib.type.types.Int> cannot be cast to net.sourceforge.cilib.type.types.Real > > > > > > at net.sourceforge.cilib.pso.positionupdatestrategies.MutationPositionUpdateStrategy.mutate(MutationPositionUpdateStrategy.java:141) > > > > > > at net.sourceforge.cilib.pso.positionupdatestrategies.MutationPositionUpdateStrategy.updatePosition(MutationPositionUpdateStrategy.java:118) > > > > > > at net.sourceforge.cilib.pso.particle.StandardParticle.updatePosition(StandardParticle.java:156) > > > > > > at net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:70) > > > > > > at net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:36) > > > > > > at net.sourceforge.cilib.pso.PSO.algorithmIteration(PSO.java:125) > > > > > > at net.sourceforge.cilib.algorithm.Algorithm.performIteration(Algorithm.java:140) > > > > > > at net.sourceforge.cilib.algorithm.Algorithm.run(Algorithm.java:182) > > > > > > at mil.navy.nrl.optimization.route.RoutePlanning.run(RoutePlanning.java:142) > > > > > > at mil.navy.nrl.optimization.route.RoutePlanning.main(RoutePlanning.java:192) > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > This SF.net email is sponsored by: > > > > > > SourcForge Community > > > > > > SourceForge wants to tell your story. > > > > > > http://p.sf.net/sfu/sf-spreadtheword > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > _______________________________________________ > > > > > > Cilib-users mailing list > > > > > > Cil...@li... > > > > > > https://lists.sourceforge.net/lists/listinfo/cilib-users > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by: > > SourcForge Community > > SourceForge wants to tell your story. > > http://p.sf.net/sfu/sf-spreadtheword > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Cilib-users mailing list > > Cil...@li... > > https://lists.sourceforge.net/lists/listinfo/cilib-users > > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by: > > SourcForge Community > > SourceForge wants to tell your story. > > http://p.sf.net/sfu/sf-spreadtheword > > _______________________________________________ > > Cilib-users mailing list > > Cil...@li... > > https://lists.sourceforge.net/lists/listinfo/cilib-users > > |
From: Gary P. <gpa...@gm...> - 2009-01-30 13:23:39
|
Patch attached. I've had no means to test it and the change is very small. Please let me know if it works. From the looks of the error, this should solve it. I've committed the patch to the master branch already. Regards, Gary Gary Pampara wrote: > Sure thing. > > I'll post the patch once it's done. Should be a very minor change. > > Regards, > Gary > > lab...@gm... wrote: >> Hello, >> >> If the patch for this problem could be posted on the mailing list, I >> could update my local version before waiting for the new version. TIA. >> >> >> On Jan 29, 2009 11:09am, Gary Pampara <gpa...@gm...> wrote: >> > Hi, >> > >> > >> > >> > Yes, this is definitely a bug. It should work for Ints as well. I'll >> post a patch for a correction to this issue in a while. >> > >> > >> > >> > We are currently refactoring quite a bit in the library to make >> various operations / usage issues better, as well as a major update to >> the Javadoc. I'll just need to create a branch to apply the fix. >> > >> > >> > >> > Would you like the patch posted on the mailing list, or a direct >> email? This will then also be included in the next release. >> > >> > >> > >> > Thanks for raising this :) >> > >> > >> > >> > Regards, >> > >> > Gary >> > >> > >> > >> > myriam abramson wrote: >> > >> > >> > Hello, >> > >> > I am trying to evolve integers for an allocation problem, Z(0,20)^10, >> and I tried to specific MutationPositionUpdateStrategy but unfortunately >> it does not seem to work for integers. See trace below. Is there a >> rational for that that I'm missing? I was thinking that instead of >> evolving a position by incremental velocity changes, mutation would >> sometimes just produce a new integer. Please let me know if that makes >> sense. It wouldn't be too hard to implement it on my end. >> > >> > >> > >> > Exception in thread "main" java.lang.ClassCastException: >> net.sourceforge.cilib.type.types.Int >> http://net.sourceforge.cilib.type.types.Int> cannot be cast to >> net.sourceforge.cilib.type.types.Real >> > >> > at >> net.sourceforge.cilib.pso.positionupdatestrategies.MutationPositionUpdateStrategy.mutate(MutationPositionUpdateStrategy.java:141) >> > >> > at >> net.sourceforge.cilib.pso.positionupdatestrategies.MutationPositionUpdateStrategy.updatePosition(MutationPositionUpdateStrategy.java:118) >> > >> > at >> net.sourceforge.cilib.pso.particle.StandardParticle.updatePosition(StandardParticle.java:156) >> > >> > at >> net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:70) >> > >> > at >> net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:36) >> > >> > at net.sourceforge.cilib.pso.PSO.algorithmIteration(PSO.java:125) >> > >> > at >> net.sourceforge.cilib.algorithm.Algorithm.performIteration(Algorithm.java:140) >> > >> > at net.sourceforge.cilib.algorithm.Algorithm.run(Algorithm.java:182) >> > >> > at >> mil.navy.nrl.optimization.route.RoutePlanning.run(RoutePlanning.java:142) >> > >> > at >> mil.navy.nrl.optimization.route.RoutePlanning.main(RoutePlanning.java:192) >> > >> > >> > >> > >> > >> > ------------------------------------------------------------------------ >> > >> > >> > >> > >> ------------------------------------------------------------------------------ >> > >> > This SF.net email is sponsored by: >> > >> > SourcForge Community >> > >> > SourceForge wants to tell your story. >> > >> > http://p.sf.net/sfu/sf-spreadtheword >> > >> > >> > >> > >> > >> > ------------------------------------------------------------------------ >> > >> > >> > >> > _______________________________________________ >> > >> > Cilib-users mailing list >> > >> > Cil...@li... >> > >> > https://lists.sourceforge.net/lists/listinfo/cilib-users >> > >> > >> >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Cilib-users mailing list >> Cil...@li... >> https://lists.sourceforge.net/lists/listinfo/cilib-users > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Cilib-users mailing list > Cil...@li... > https://lists.sourceforge.net/lists/listinfo/cilib-users |
From: Gary P. <gpa...@gm...> - 2009-01-29 17:51:20
|
Sure thing. I'll post the patch once it's done. Should be a very minor change. Regards, Gary lab...@gm... wrote: > Hello, > > If the patch for this problem could be posted on the mailing list, I > could update my local version before waiting for the new version. TIA. > > > On Jan 29, 2009 11:09am, Gary Pampara <gpa...@gm...> wrote: > > Hi, > > > > > > > > Yes, this is definitely a bug. It should work for Ints as well. I'll > post a patch for a correction to this issue in a while. > > > > > > > > We are currently refactoring quite a bit in the library to make > various operations / usage issues better, as well as a major update to > the Javadoc. I'll just need to create a branch to apply the fix. > > > > > > > > Would you like the patch posted on the mailing list, or a direct > email? This will then also be included in the next release. > > > > > > > > Thanks for raising this :) > > > > > > > > Regards, > > > > Gary > > > > > > > > myriam abramson wrote: > > > > > > Hello, > > > > I am trying to evolve integers for an allocation problem, Z(0,20)^10, > and I tried to specific MutationPositionUpdateStrategy but unfortunately > it does not seem to work for integers. See trace below. Is there a > rational for that that I'm missing? I was thinking that instead of > evolving a position by incremental velocity changes, mutation would > sometimes just produce a new integer. Please let me know if that makes > sense. It wouldn't be too hard to implement it on my end. > > > > > > > > Exception in thread "main" java.lang.ClassCastException: > net.sourceforge.cilib.type.types.Int > http://net.sourceforge.cilib.type.types.Int> cannot be cast to > net.sourceforge.cilib.type.types.Real > > > > at > net.sourceforge.cilib.pso.positionupdatestrategies.MutationPositionUpdateStrategy.mutate(MutationPositionUpdateStrategy.java:141) > > > > at > net.sourceforge.cilib.pso.positionupdatestrategies.MutationPositionUpdateStrategy.updatePosition(MutationPositionUpdateStrategy.java:118) > > > > at > net.sourceforge.cilib.pso.particle.StandardParticle.updatePosition(StandardParticle.java:156) > > > > at > net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:70) > > > > at > net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:36) > > > > at net.sourceforge.cilib.pso.PSO.algorithmIteration(PSO.java:125) > > > > at > net.sourceforge.cilib.algorithm.Algorithm.performIteration(Algorithm.java:140) > > > > at net.sourceforge.cilib.algorithm.Algorithm.run(Algorithm.java:182) > > > > at > mil.navy.nrl.optimization.route.RoutePlanning.run(RoutePlanning.java:142) > > > > at > mil.navy.nrl.optimization.route.RoutePlanning.main(RoutePlanning.java:192) > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > ------------------------------------------------------------------------------ > > > > This SF.net email is sponsored by: > > > > SourcForge Community > > > > SourceForge wants to tell your story. > > > > http://p.sf.net/sfu/sf-spreadtheword > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > > > Cilib-users mailing list > > > > Cil...@li... > > > > https://lists.sourceforge.net/lists/listinfo/cilib-users > > > > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > > > ------------------------------------------------------------------------ > > _______________________________________________ > Cilib-users mailing list > Cil...@li... > https://lists.sourceforge.net/lists/listinfo/cilib-users |
From: <lab...@gm...> - 2009-01-29 17:46:43
|
Hello, If the patch for this problem could be posted on the mailing list, I could update my local version before waiting for the new version. TIA. On Jan 29, 2009 11:09am, Gary Pampara <gpa...@gm...> wrote: > Hi, > > > > Yes, this is definitely a bug. It should work for Ints as well. I'll post a patch for a correction to this issue in a while. > > > > We are currently refactoring quite a bit in the library to make various operations / usage issues better, as well as a major update to the Javadoc. I'll just need to create a branch to apply the fix. > > > > Would you like the patch posted on the mailing list, or a direct email? This will then also be included in the next release. > > > > Thanks for raising this :) > > > > Regards, > > Gary > > > > myriam abramson wrote: > > > Hello, > > I am trying to evolve integers for an allocation problem, Z(0,20)^10, and I tried to specific MutationPositionUpdateStrategy but unfortunately it does not seem to work for integers. See trace below. Is there a rational for that that I'm missing? I was thinking that instead of evolving a position by incremental velocity changes, mutation would sometimes just produce a new integer. Please let me know if that makes sense. It wouldn't be too hard to implement it on my end. > > > > Exception in thread "main" java.lang.ClassCastException: net.sourceforge.cilib.type.types.Int http://net.sourceforge.cilib.type.types.Int> cannot be cast to net.sourceforge.cilib.type.types.Real > > at net.sourceforge.cilib.pso.positionupdatestrategies.MutationPositionUpdateStrategy.mutate(MutationPositionUpdateStrategy.java:141) > > at net.sourceforge.cilib.pso.positionupdatestrategies.MutationPositionUpdateStrategy.updatePosition(MutationPositionUpdateStrategy.java:118) > > at net.sourceforge.cilib.pso.particle.StandardParticle.updatePosition(StandardParticle.java:156) > > at net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:70) > > at net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:36) > > at net.sourceforge.cilib.pso.PSO.algorithmIteration(PSO.java:125) > > at net.sourceforge.cilib.algorithm.Algorithm.performIteration(Algorithm.java:140) > > at net.sourceforge.cilib.algorithm.Algorithm.run(Algorithm.java:182) > > at mil.navy.nrl.optimization.route.RoutePlanning.run(RoutePlanning.java:142) > > at mil.navy.nrl.optimization.route.RoutePlanning.main(RoutePlanning.java:192) > > > > > > ------------------------------------------------------------------------ > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by: > > SourcForge Community > > SourceForge wants to tell your story. > > http://p.sf.net/sfu/sf-spreadtheword > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Cilib-users mailing list > > Cil...@li... > > https://lists.sourceforge.net/lists/listinfo/cilib-users > > |
From: Gary P. <gpa...@gm...> - 2009-01-29 16:09:39
|
Hi, Yes, this is definitely a bug. It should work for Ints as well. I'll post a patch for a correction to this issue in a while. We are currently refactoring quite a bit in the library to make various operations / usage issues better, as well as a major update to the Javadoc. I'll just need to create a branch to apply the fix. Would you like the patch posted on the mailing list, or a direct email? This will then also be included in the next release. Thanks for raising this :) Regards, Gary myriam abramson wrote: > Hello, > I am trying to evolve integers for an allocation problem, Z(0,20)^10, > and I tried to specific MutationPositionUpdateStrategy but unfortunately > it does not seem to work for integers. See trace below. Is there a > rational for that that I'm missing? I was thinking that instead of > evolving a position by incremental velocity changes, mutation would > sometimes just produce a new integer. Please let me know if that makes > sense. It wouldn't be too hard to implement it on my end. > > Exception in thread "main" java.lang.ClassCastException: > net.sourceforge.cilib.type.types.Int > <http://net.sourceforge.cilib.type.types.Int> cannot be cast to > net.sourceforge.cilib.type.types.Real > at > net.sourceforge.cilib.pso.positionupdatestrategies.MutationPositionUpdateStrategy.mutate(MutationPositionUpdateStrategy.java:141) > at > net.sourceforge.cilib.pso.positionupdatestrategies.MutationPositionUpdateStrategy.updatePosition(MutationPositionUpdateStrategy.java:118) > at > net.sourceforge.cilib.pso.particle.StandardParticle.updatePosition(StandardParticle.java:156) > at > net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:70) > at > net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:36) > at net.sourceforge.cilib.pso.PSO.algorithmIteration(PSO.java:125) > at > net.sourceforge.cilib.algorithm.Algorithm.performIteration(Algorithm.java:140) > at net.sourceforge.cilib.algorithm.Algorithm.run(Algorithm.java:182) > at > mil.navy.nrl.optimization.route.RoutePlanning.run(RoutePlanning.java:142) > at > mil.navy.nrl.optimization.route.RoutePlanning.main(RoutePlanning.java:192) > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > > > ------------------------------------------------------------------------ > > _______________________________________________ > Cilib-users mailing list > Cil...@li... > https://lists.sourceforge.net/lists/listinfo/cilib-users |
From: myriam a. <lab...@gm...> - 2009-01-29 14:40:00
|
Hello, I am trying to evolve integers for an allocation problem, Z(0,20)^10, and I tried to specific MutationPositionUpdateStrategy but unfortunately it does not seem to work for integers. See trace below. Is there a rational for that that I'm missing? I was thinking that instead of evolving a position by incremental velocity changes, mutation would sometimes just produce a new integer. Please let me know if that makes sense. It wouldn't be too hard to implement it on my end. Exception in thread "main" java.lang.ClassCastException: net.sourceforge.cilib.type.types.Int cannot be cast to net.sourceforge.cilib.type.types.Real at net.sourceforge.cilib.pso.positionupdatestrategies.MutationPositionUpdateStrategy.mutate(MutationPositionUpdateStrategy.java:141) at net.sourceforge.cilib.pso.positionupdatestrategies.MutationPositionUpdateStrategy.updatePosition(MutationPositionUpdateStrategy.java:118) at net.sourceforge.cilib.pso.particle.StandardParticle.updatePosition(StandardParticle.java:156) at net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:70) at net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:36) at net.sourceforge.cilib.pso.PSO.algorithmIteration(PSO.java:125) at net.sourceforge.cilib.algorithm.Algorithm.performIteration(Algorithm.java:140) at net.sourceforge.cilib.algorithm.Algorithm.run(Algorithm.java:182) at mil.navy.nrl.optimization.route.RoutePlanning.run(RoutePlanning.java:142) at mil.navy.nrl.optimization.route.RoutePlanning.main(RoutePlanning.java:192) |
From: Gary P. <gpa...@gm...> - 2009-01-08 05:11:48
|
The other option is of course to convert to a matrix first and then do the multiplication? Many ways to skin a cat :P Just let us know how we can help. Regards, Gary lab...@gm... wrote: > yes, that's true. I was just trying with an existing function. It might > be better to just do the translation from a simple vector when I need it > and leave the rest as is. I was concerned with matrix multiplication but > there is only scalar multiplication in the update equations for PSO so > the matrix representation does not matter after all. I'm trying to do a > task assignment problem and that's nice to do with matrices. > > > On Jan 7, 2009 12:15am, Gary Pampara <gpa...@gm...> wrote: >> Hi, >> >> >> >> I would actually consider writing a two new classes (one for the >> >> velocity and another for the position). >> >> >> >> The only remaining question is how the problem is defined. In the >> >> example you provided, you are using a spherical function. The function >> >> naturally does not understand matrix representations, as per the >> >> definition of the problem. >> >> >> >> Let me know if we can help in any way. >> >> >> >> Regards, >> >> Gary >> >> >> >> >> >> lab...@gm... wrote: >> >> > Yes, thanks. I think I can modify the velocityupdatestrategy program to >> >> > handle a matrix representation. It's a tradeoff between doing it like >> >> > that or translating back and forth in other places. >> >> > >> >> > On Jan 6, 2009 12:13am, Gary Pampara gpa...@gm...> wrote: >> >> >> Hi, >> >> >> >> >> >> >> >> >> >> >> >> There is absolutely nothing wrong with the XML specification. The >> >> >> >> >> >> problem is in fact with the representation and the current standard >> >> >> >> >> >> classes in CIlib. >> >> >> >> >> >> >> >> >> >> >> >> By default, the larger majority of Swarm Intelligence problems have >> >> >> >> >> >> candidate solutions that are represented by a single vector. In your >> >> >> >> >> >> XML, you have defined that the domain in which the you want the >> >> >> >> >> >> algorithm to operate in, is a space that can effectively be represented >> >> >> >> >> >> as a matrix (or multi-dimensional array). >> >> >> >> >> >> >> >> >> >> >> >> During the algorithm setup and construction, the particles that are >> >> >> >> >> >> generated do in fact have matrices as their internal representations. >> >> >> >> >> >> The problem comes in that the default Velocity and Position update >> >> >> >> >> >> equations expect Vectors and not a Vector of Vectors (which is the >> >> >> >> >> >> current manner a Matrix is built using the domain strings - this may >> >> >> >> >> >> change in the near future). >> >> >> >> >> >> >> >> >> >> >> >> There should be 3 things that need to change. >> >> >> >> >> >> - The particles need to be told that their velocity and position update >> >> >> >> >> >> equations need to be altered so that they can handle Matrix instances. >> >> >> >> >> >> - The problem needs to be aware that the candidate solution that it >> >> >> >> >> >> needs to evaluate is in fact a matrix and not a simple Vector class. >> >> >> >> >> >> >> >> >> >> >> >> Does this all make sense? >> >> >> >> >> >> >> >> >> >> >> >> Regards, >> >> >> >> >> >> Gary >> >> >> >> >> >> >> >> >> >> >> >> lab...@gm... wrote: >> >> >> >> >> >> > Sorry, I was on vacation. Happy New Year to all, BTW :-) >> >> >> >> >> >> > >> >> >> >> >> >> > Here's an xml file. Maybe I'm doing something wrong? TIA. >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > ]> >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> > maximumIterations="1000" /> >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> > domain="[R(-5.0,5.0)^5]^5"/> >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> > resolution="10" samples="1"> >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> > file="data/spherical3.gbest.p20w1.0c1_2c2_2NoVmax.txt"/> >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> >> > On Dec 23, 2008 6:54am, Gary Pampara gpa...@gm...> wrote: >> >> >> >> >> >> >> Continuing this discussion on the developer list. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Gary Pampara wrote: >> >> >> >> >> >> >> >> >> >> >> >> >> >> > Hi, >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> > I'll have a look at this. >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> > Regards, >> >> >> >> >> >> >> >> >> >> >> >> >> >> > Gary >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> > lab...@gm... wrote: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> registry.setDomainString("[R(-5.0, 5.0)^10]^10"); >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> yeah, that does not work too well. I get the following error: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Exception in thread "main" > java.lang.UnsupportedOperationException: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Attempted to perform a numeric operation on non-numeric type >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> at >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> > > net.sourceforge.cilib.type.types.container.Vector.getNumeric(Vector.java:414) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> at >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> > > net.sourceforge.cilib.type.types.container.Vector.getReal(Vector.java:466) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> at >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> > > net.sourceforge.cilib.pso.velocityupdatestrategies.StandardVelocityUpdate.updateVelocity(StandardVelocityUpdate.java:89) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> at >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> > > net.sourceforge.cilib.pso.particle.StandardParticle.updateVelocity(StandardParticle.java:186) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> at >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> > > net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:69) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> at >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> > > net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:36) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> at net.sourceforge.cilib.pso.PSO.algorithmIteration(PSO.java:125) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> at >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> > > net.sourceforge.cilib.algorithm.Algorithm.performIteration(Algorithm.java:140) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> at > net.sourceforge.cilib.algorithm.Algorithm.run(Algorithm.java:182) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > ------------------------------------------------------------------------ >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> > > ------------------------------------------------------------------------------ >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > ------------------------------------------------------------------------ >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Cilib-users mailing list >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Cil...@li... >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> https://lists.sourceforge.net/lists/listinfo/cilib-users >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> > > ------------------------------------------------------------------------------ >> >> >> >> >> >> >> >> >> >> >> >> >> >> > _______________________________________________ >> >> >> >> >> >> >> >> >> >> >> >> >> >> > Cilib-users mailing list >> >> >> >> >> >> >> >> >> >> >> >> >> >> > Cil...@li... >> >> >> >> >> >> >> >> >> >> >> >> >> >> > https://lists.sourceforge.net/lists/listinfo/cilib-users >> >> >> >> >> >> >> >> >> >> >> >> > >> >> > >> >> > ------------------------------------------------------------------------ >> >> > >> >> > > ------------------------------------------------------------------------------ >> >> > Check out the new SourceForge.net Marketplace. >> >> > It is the best place to buy or sell services for >> >> > just about anything Open Source. >> >> > http://p.sf.net/sfu/Xq1LFB >> >> > >> >> > >> >> > ------------------------------------------------------------------------ >> >> > >> >> > _______________________________________________ >> >> > Cilib-users mailing list >> >> > Cil...@li... >> >> > https://lists.sourceforge.net/lists/listinfo/cilib-users >> > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Check out the new SourceForge.net Marketplace. > It is the best place to buy or sell services for > just about anything Open Source. > http://p.sf.net/sfu/Xq1LFB > > > ------------------------------------------------------------------------ > > _______________________________________________ > Cilib-users mailing list > Cil...@li... > https://lists.sourceforge.net/lists/listinfo/cilib-users |
From: <lab...@gm...> - 2009-01-07 22:42:44
|
yes, that's true. I was just trying with an existing function. It might be better to just do the translation from a simple vector when I need it and leave the rest as is. I was concerned with matrix multiplication but there is only scalar multiplication in the update equations for PSO so the matrix representation does not matter after all. I'm trying to do a task assignment problem and that's nice to do with matrices. On Jan 7, 2009 12:15am, Gary Pampara <gpa...@gm...> wrote: > Hi, > > > > I would actually consider writing a two new classes (one for the > > velocity and another for the position). > > > > The only remaining question is how the problem is defined. In the > > example you provided, you are using a spherical function. The function > > naturally does not understand matrix representations, as per the > > definition of the problem. > > > > Let me know if we can help in any way. > > > > Regards, > > Gary > > > > > > lab...@gm... wrote: > > > Yes, thanks. I think I can modify the velocityupdatestrategy program to > > > handle a matrix representation. It's a tradeoff between doing it like > > > that or translating back and forth in other places. > > > > > > On Jan 6, 2009 12:13am, Gary Pampara gpa...@gm...> wrote: > > >> Hi, > > >> > > >> > > >> > > >> There is absolutely nothing wrong with the XML specification. The > > >> > > >> problem is in fact with the representation and the current standard > > >> > > >> classes in CIlib. > > >> > > >> > > >> > > >> By default, the larger majority of Swarm Intelligence problems have > > >> > > >> candidate solutions that are represented by a single vector. In your > > >> > > >> XML, you have defined that the domain in which the you want the > > >> > > >> algorithm to operate in, is a space that can effectively be represented > > >> > > >> as a matrix (or multi-dimensional array). > > >> > > >> > > >> > > >> During the algorithm setup and construction, the particles that are > > >> > > >> generated do in fact have matrices as their internal representations. > > >> > > >> The problem comes in that the default Velocity and Position update > > >> > > >> equations expect Vectors and not a Vector of Vectors (which is the > > >> > > >> current manner a Matrix is built using the domain strings - this may > > >> > > >> change in the near future). > > >> > > >> > > >> > > >> There should be 3 things that need to change. > > >> > > >> - The particles need to be told that their velocity and position update > > >> > > >> equations need to be altered so that they can handle Matrix instances. > > >> > > >> - The problem needs to be aware that the candidate solution that it > > >> > > >> needs to evaluate is in fact a matrix and not a simple Vector class. > > >> > > >> > > >> > > >> Does this all make sense? > > >> > > >> > > >> > > >> Regards, > > >> > > >> Gary > > >> > > >> > > >> > > >> lab...@gm... wrote: > > >> > > >> > Sorry, I was on vacation. Happy New Year to all, BTW :-) > > >> > > >> > > > >> > > >> > Here's an xml file. Maybe I'm doing something wrong? TIA. > > >> > > >> > > > >> > > >> > > > >> > > >> > > > >> > > >> > > > >> > > > >> > > >> > > > >> > > >> > > > >> > > >> > ]> > > >> > > >> > > > >> > > >> > > > >> > > >> > > > >> > > >> > > > >> > > >> > > > >> > maximumIterations="1000" /> > > >> > > >> > > > >> > > >> > > > >> > > >> > > > >> > > >> > > > >> > > >> > > > >> > > >> > > > >> > domain="[R(-5.0,5.0)^5]^5"/> > > >> > > >> > > > >> > > >> > > > >> > > >> > > > >> > > >> > > > >> > resolution="10" samples="1"> > > >> > > >> > > > >> > > >> > > > >> > > >> > > > >> > > >> > > > >> > > >> > > > >> > > >> > > > >> > > >> > > > >> > > >> > > > >> > file="data/spherical3.gbest.p20w1.0c1_2c2_2NoVmax.txt"/> > > >> > > >> > > > >> > > >> > > > >> > > >> > > > >> > > >> > > > >> > > >> > > > >> > > >> > On Dec 23, 2008 6:54am, Gary Pampara gpa...@gm...> wrote: > > >> > > >> >> Continuing this discussion on the developer list. > > >> > > >> >> > > >> > > >> >> > > >> > > >> >> > > >> > > >> >> Gary Pampara wrote: > > >> > > >> >> > > >> > > >> >> > Hi, > > >> > > >> >> > > >> > > >> >> > > > >> > > >> >> > > >> > > >> >> > I'll have a look at this. > > >> > > >> >> > > >> > > >> >> > > > >> > > >> >> > > >> > > >> >> > Regards, > > >> > > >> >> > > >> > > >> >> > Gary > > >> > > >> >> > > >> > > >> >> > > > >> > > >> >> > > >> > > >> >> > lab...@gm... wrote: > > >> > > >> >> > > >> > > >> >> >> registry.setDomainString("[R(-5.0, 5.0)^10]^10"); > > >> > > >> >> > > >> > > >> >> >> yeah, that does not work too well. I get the following error: > > >> > > >> >> > > >> > > >> >> >> > > >> > > >> >> > > >> > > >> >> >> Exception in thread "main" java.lang.UnsupportedOperationException: > > >> > > >> >> > > >> > > >> >> >> Attempted to perform a numeric operation on non-numeric type > > >> > > >> >> > > >> > > >> >> >> at > > >> > > >> >> > > >> > > >> >> >> > > >> > > >> > > > > net.sourceforge.cilib.type.types.container.Vector.getNumeric(Vector.java:414) > > >> > > >> >> > > >> > > >> >> >> at > > >> > > >> >> > > >> > > >> >> >> > > >> > > >> > > > > net.sourceforge.cilib.type.types.container.Vector.getReal(Vector.java:466) > > >> > > >> >> > > >> > > >> >> >> at > > >> > > >> >> > > >> > > >> >> >> > > >> > > >> > > > > net.sourceforge.cilib.pso.velocityupdatestrategies.StandardVelocityUpdate.updateVelocity(StandardVelocityUpdate.java:89) > > >> > > >> >> > > >> > > >> >> >> at > > >> > > >> >> > > >> > > >> >> >> > > >> > > >> > > > > net.sourceforge.cilib.pso.particle.StandardParticle.updateVelocity(StandardParticle.java:186) > > >> > > >> >> > > >> > > >> >> >> at > > >> > > >> >> > > >> > > >> >> >> > > >> > > >> > > > > net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:69) > > >> > > >> >> > > >> > > >> >> >> at > > >> > > >> >> > > >> > > >> >> >> > > >> > > >> > > > > net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:36) > > >> > > >> >> > > >> > > >> >> >> at net.sourceforge.cilib.pso.PSO.algorithmIteration(PSO.java:125) > > >> > > >> >> > > >> > > >> >> >> at > > >> > > >> >> > > >> > > >> >> >> > > >> > > >> > > > > net.sourceforge.cilib.algorithm.Algorithm.performIteration(Algorithm.java:140) > > >> > > >> >> > > >> > > >> >> >> at net.sourceforge.cilib.algorithm.Algorithm.run(Algorithm.java:182) > > >> > > >> >> > > >> > > >> >> >> > > >> > > >> >> > > >> > > >> >> >> > > >> > > >> >> > > >> > > >> >> >> > > >> > > >> > ------------------------------------------------------------------------ > > >> > > >> >> > > >> > > >> >> >> > > >> > > >> >> > > >> > > >> >> >> > > >> > > >> > > > > ------------------------------------------------------------------------------ > > >> > > >> >> > > >> > > >> >> >> > > >> > > >> >> > > >> > > >> >> >> > > >> > > >> >> > > >> > > >> >> >> > > >> > > >> > ------------------------------------------------------------------------ > > >> > > >> >> > > >> > > >> >> >> > > >> > > >> >> > > >> > > >> >> >> _______________________________________________ > > >> > > >> >> > > >> > > >> >> >> Cilib-users mailing list > > >> > > >> >> > > >> > > >> >> >> Cil...@li... > > >> > > >> >> > > >> > > >> >> >> https://lists.sourceforge.net/lists/listinfo/cilib-users > > >> > > >> >> > > >> > > >> >> > > > >> > > >> >> > > >> > > >> >> > > > >> > > >> > > > > ------------------------------------------------------------------------------ > > >> > > >> >> > > >> > > >> >> > _______________________________________________ > > >> > > >> >> > > >> > > >> >> > Cilib-users mailing list > > >> > > >> >> > > >> > > >> >> > Cil...@li... > > >> > > >> >> > > >> > > >> >> > https://lists.sourceforge.net/lists/listinfo/cilib-users > > >> > > >> >> > > >> > > > > > > > > > ------------------------------------------------------------------------ > > > > > > ------------------------------------------------------------------------------ > > > Check out the new SourceForge.net Marketplace. > > > It is the best place to buy or sell services for > > > just about anything Open Source. > > > http://p.sf.net/sfu/Xq1LFB > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > Cilib-users mailing list > > > Cil...@li... > > > https://lists.sourceforge.net/lists/listinfo/cilib-users > |
From: Gary P. <gpa...@gm...> - 2009-01-07 05:15:53
|
Hi, I would actually consider writing a two new classes (one for the velocity and another for the position). The only remaining question is how the problem is defined. In the example you provided, you are using a spherical function. The function naturally does not understand matrix representations, as per the definition of the problem. Let me know if we can help in any way. Regards, Gary lab...@gm... wrote: > Yes, thanks. I think I can modify the velocityupdatestrategy program to > handle a matrix representation. It's a tradeoff between doing it like > that or translating back and forth in other places. > > On Jan 6, 2009 12:13am, Gary Pampara <gpa...@gm...> wrote: >> Hi, >> >> >> >> There is absolutely nothing wrong with the XML specification. The >> >> problem is in fact with the representation and the current standard >> >> classes in CIlib. >> >> >> >> By default, the larger majority of Swarm Intelligence problems have >> >> candidate solutions that are represented by a single vector. In your >> >> XML, you have defined that the domain in which the you want the >> >> algorithm to operate in, is a space that can effectively be represented >> >> as a matrix (or multi-dimensional array). >> >> >> >> During the algorithm setup and construction, the particles that are >> >> generated do in fact have matrices as their internal representations. >> >> The problem comes in that the default Velocity and Position update >> >> equations expect Vectors and not a Vector of Vectors (which is the >> >> current manner a Matrix is built using the domain strings - this may >> >> change in the near future). >> >> >> >> There should be 3 things that need to change. >> >> - The particles need to be told that their velocity and position update >> >> equations need to be altered so that they can handle Matrix instances. >> >> - The problem needs to be aware that the candidate solution that it >> >> needs to evaluate is in fact a matrix and not a simple Vector class. >> >> >> >> Does this all make sense? >> >> >> >> Regards, >> >> Gary >> >> >> >> lab...@gm... wrote: >> >> > Sorry, I was on vacation. Happy New Year to all, BTW :-) >> >> > >> >> > Here's an xml file. Maybe I'm doing something wrong? TIA. >> >> > >> >> > >> >> > >> >> > >> > >> >> > >> >> > >> >> > ]> >> >> > >> >> > >> >> > >> >> > >> >> > >> > maximumIterations="1000" /> >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> > domain="[R(-5.0,5.0)^5]^5"/> >> >> > >> >> > >> >> > >> >> > >> > resolution="10" samples="1"> >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> > file="data/spherical3.gbest.p20w1.0c1_2c2_2NoVmax.txt"/> >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > On Dec 23, 2008 6:54am, Gary Pampara gpa...@gm...> wrote: >> >> >> Continuing this discussion on the developer list. >> >> >> >> >> >> >> >> >> >> >> >> Gary Pampara wrote: >> >> >> >> >> >> > Hi, >> >> >> >> >> >> > >> >> >> >> >> >> > I'll have a look at this. >> >> >> >> >> >> > >> >> >> >> >> >> > Regards, >> >> >> >> >> >> > Gary >> >> >> >> >> >> > >> >> >> >> >> >> > lab...@gm... wrote: >> >> >> >> >> >> >> registry.setDomainString("[R(-5.0, 5.0)^10]^10"); >> >> >> >> >> >> >> yeah, that does not work too well. I get the following error: >> >> >> >> >> >> >> >> >> >> >> >> >> >> Exception in thread "main" java.lang.UnsupportedOperationException: >> >> >> >> >> >> >> Attempted to perform a numeric operation on non-numeric type >> >> >> >> >> >> >> at >> >> >> >> >> >> >> >> >> > > net.sourceforge.cilib.type.types.container.Vector.getNumeric(Vector.java:414) >> >> >> >> >> >> >> at >> >> >> >> >> >> >> >> >> > > net.sourceforge.cilib.type.types.container.Vector.getReal(Vector.java:466) >> >> >> >> >> >> >> at >> >> >> >> >> >> >> >> >> > > net.sourceforge.cilib.pso.velocityupdatestrategies.StandardVelocityUpdate.updateVelocity(StandardVelocityUpdate.java:89) >> >> >> >> >> >> >> at >> >> >> >> >> >> >> >> >> > > net.sourceforge.cilib.pso.particle.StandardParticle.updateVelocity(StandardParticle.java:186) >> >> >> >> >> >> >> at >> >> >> >> >> >> >> >> >> > > net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:69) >> >> >> >> >> >> >> at >> >> >> >> >> >> >> >> >> > > net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:36) >> >> >> >> >> >> >> at net.sourceforge.cilib.pso.PSO.algorithmIteration(PSO.java:125) >> >> >> >> >> >> >> at >> >> >> >> >> >> >> >> >> > > net.sourceforge.cilib.algorithm.Algorithm.performIteration(Algorithm.java:140) >> >> >> >> >> >> >> at net.sourceforge.cilib.algorithm.Algorithm.run(Algorithm.java:182) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > ------------------------------------------------------------------------ >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > ------------------------------------------------------------------------------ >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > ------------------------------------------------------------------------ >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> >> >> >> Cilib-users mailing list >> >> >> >> >> >> >> Cil...@li... >> >> >> >> >> >> >> https://lists.sourceforge.net/lists/listinfo/cilib-users >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> > > ------------------------------------------------------------------------------ >> >> >> >> >> >> > _______________________________________________ >> >> >> >> >> >> > Cilib-users mailing list >> >> >> >> >> >> > Cil...@li... >> >> >> >> >> >> > https://lists.sourceforge.net/lists/listinfo/cilib-users >> >> >> >> > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Check out the new SourceForge.net Marketplace. > It is the best place to buy or sell services for > just about anything Open Source. > http://p.sf.net/sfu/Xq1LFB > > > ------------------------------------------------------------------------ > > _______________________________________________ > Cilib-users mailing list > Cil...@li... > https://lists.sourceforge.net/lists/listinfo/cilib-users |
From: <lab...@gm...> - 2009-01-06 22:45:51
|
Yes, thanks. I think I can modify the velocityupdatestrategy program to handle a matrix representation. It's a tradeoff between doing it like that or translating back and forth in other places. On Jan 6, 2009 12:13am, Gary Pampara <gpa...@gm...> wrote: > Hi, > > > > There is absolutely nothing wrong with the XML specification. The > > problem is in fact with the representation and the current standard > > classes in CIlib. > > > > By default, the larger majority of Swarm Intelligence problems have > > candidate solutions that are represented by a single vector. In your > > XML, you have defined that the domain in which the you want the > > algorithm to operate in, is a space that can effectively be represented > > as a matrix (or multi-dimensional array). > > > > During the algorithm setup and construction, the particles that are > > generated do in fact have matrices as their internal representations. > > The problem comes in that the default Velocity and Position update > > equations expect Vectors and not a Vector of Vectors (which is the > > current manner a Matrix is built using the domain strings - this may > > change in the near future). > > > > There should be 3 things that need to change. > > - The particles need to be told that their velocity and position update > > equations need to be altered so that they can handle Matrix instances. > > - The problem needs to be aware that the candidate solution that it > > needs to evaluate is in fact a matrix and not a simple Vector class. > > > > Does this all make sense? > > > > Regards, > > Gary > > > > lab...@gm... wrote: > > > Sorry, I was on vacation. Happy New Year to all, BTW :-) > > > > > > Here's an xml file. Maybe I'm doing something wrong? TIA. > > > > > > > > > > > > > > > > > > > > > > > ]> > > > > > > > > > > > > > > > > > maximumIterations="1000" /> > > > > > > > > > > > > > > > > > > > > domain="[R(-5.0,5.0)^5]^5"/> > > > > > > > > > > > > > > resolution="10" samples="1"> > > > > > > > > > > > > > > > > > > > > > > > > > > file="data/spherical3.gbest.p20w1.0c1_2c2_2NoVmax.txt"/> > > > > > > > > > > > > > > > > > > On Dec 23, 2008 6:54am, Gary Pampara gpa...@gm...> wrote: > > >> Continuing this discussion on the developer list. > > >> > > >> > > >> > > >> Gary Pampara wrote: > > >> > > >> > Hi, > > >> > > >> > > > >> > > >> > I'll have a look at this. > > >> > > >> > > > >> > > >> > Regards, > > >> > > >> > Gary > > >> > > >> > > > >> > > >> > lab...@gm... wrote: > > >> > > >> >> registry.setDomainString("[R(-5.0, 5.0)^10]^10"); > > >> > > >> >> yeah, that does not work too well. I get the following error: > > >> > > >> >> > > >> > > >> >> Exception in thread "main" java.lang.UnsupportedOperationException: > > >> > > >> >> Attempted to perform a numeric operation on non-numeric type > > >> > > >> >> at > > >> > > >> >> > > > net.sourceforge.cilib.type.types.container.Vector.getNumeric(Vector.java:414) > > >> > > >> >> at > > >> > > >> >> > > > net.sourceforge.cilib.type.types.container.Vector.getReal(Vector.java:466) > > >> > > >> >> at > > >> > > >> >> > > > net.sourceforge.cilib.pso.velocityupdatestrategies.StandardVelocityUpdate.updateVelocity(StandardVelocityUpdate.java:89) > > >> > > >> >> at > > >> > > >> >> > > > net.sourceforge.cilib.pso.particle.StandardParticle.updateVelocity(StandardParticle.java:186) > > >> > > >> >> at > > >> > > >> >> > > > net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:69) > > >> > > >> >> at > > >> > > >> >> > > > net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:36) > > >> > > >> >> at net.sourceforge.cilib.pso.PSO.algorithmIteration(PSO.java:125) > > >> > > >> >> at > > >> > > >> >> > > > net.sourceforge.cilib.algorithm.Algorithm.performIteration(Algorithm.java:140) > > >> > > >> >> at net.sourceforge.cilib.algorithm.Algorithm.run(Algorithm.java:182) > > >> > > >> >> > > >> > > >> >> > > >> > > >> >> > > > ------------------------------------------------------------------------ > > >> > > >> >> > > >> > > >> >> > > > ------------------------------------------------------------------------------ > > >> > > >> >> > > >> > > >> >> > > >> > > >> >> > > > ------------------------------------------------------------------------ > > >> > > >> >> > > >> > > >> >> _______________________________________________ > > >> > > >> >> Cilib-users mailing list > > >> > > >> >> Cil...@li... > > >> > > >> >> https://lists.sourceforge.net/lists/listinfo/cilib-users > > >> > > >> > > > >> > > >> > > > > ------------------------------------------------------------------------------ > > >> > > >> > _______________________________________________ > > >> > > >> > Cilib-users mailing list > > >> > > >> > Cil...@li... > > >> > > >> > https://lists.sourceforge.net/lists/listinfo/cilib-users > > >> > |
From: Gary P. <gpa...@gm...> - 2009-01-06 05:13:42
|
Hi, There is absolutely nothing wrong with the XML specification. The problem is in fact with the representation and the current standard classes in CIlib. By default, the larger majority of Swarm Intelligence problems have candidate solutions that are represented by a single vector. In your XML, you have defined that the domain in which the you want the algorithm to operate in, is a space that can effectively be represented as a matrix (or multi-dimensional array). During the algorithm setup and construction, the particles that are generated do in fact have matrices as their internal representations. The problem comes in that the default Velocity and Position update equations expect Vectors and not a Vector of Vectors (which is the current manner a Matrix is built using the domain strings - this may change in the near future). There should be 3 things that need to change. - The particles need to be told that their velocity and position update equations need to be altered so that they can handle Matrix instances. - The problem needs to be aware that the candidate solution that it needs to evaluate is in fact a matrix and not a simple Vector class. Does this all make sense? Regards, Gary lab...@gm... wrote: > Sorry, I was on vacation. Happy New Year to all, BTW :-) > > Here's an xml file. Maybe I'm doing something wrong? TIA. > > <?xml version="1.0"?> > > <!DOCTYPE simulator [ > <!ATTLIST algorithm id ID #IMPLIED> > <!ATTLIST problem id ID #IMPLIED> > <!ATTLIST measurements id ID #IMPLIED> > ]> > > <simulator> > <algorithms> > <algorithm id="gbest" class="pso.PSO"> > <addStoppingCondition class="stoppingcondition.MaximumIterations" > maximumIterations="1000" /> > </algorithm> > </algorithms> > > <problems> > <problem id="spherical" class="problem.FunctionMinimisationProblem"> > <function class="functions.continuous.Spherical" > domain="[R(-5.0,5.0)^5]^5"/> > </problem> > </problems> > > <measurements id="fitness" class="simulator.MeasurementSuite" > resolution="10" samples="1"> > <addMeasurement class="measurement.single.Fitness"/> > </measurements> > > <simulations> > <simulation> > <algorithm idref="gbest"/> > <problem idref="spherical"/> > <measurements idref="fitness" > file="data/spherical3.gbest.p20w1.0c1_2c2_2NoVmax.txt"/> > </simulation> > </simulations> > </simulator> > > > On Dec 23, 2008 6:54am, Gary Pampara <gpa...@gm...> wrote: >> Continuing this discussion on the developer list. >> >> >> >> Gary Pampara wrote: >> >> > Hi, >> >> > >> >> > I'll have a look at this. >> >> > >> >> > Regards, >> >> > Gary >> >> > >> >> > lab...@gm... wrote: >> >> >> registry.setDomainString("[R(-5.0, 5.0)^10]^10"); >> >> >> yeah, that does not work too well. I get the following error: >> >> >> >> >> >> Exception in thread "main" java.lang.UnsupportedOperationException: >> >> >> Attempted to perform a numeric operation on non-numeric type >> >> >> at >> >> >> > net.sourceforge.cilib.type.types.container.Vector.getNumeric(Vector.java:414) >> >> >> at >> >> >> > net.sourceforge.cilib.type.types.container.Vector.getReal(Vector.java:466) >> >> >> at >> >> >> > net.sourceforge.cilib.pso.velocityupdatestrategies.StandardVelocityUpdate.updateVelocity(StandardVelocityUpdate.java:89) >> >> >> at >> >> >> > net.sourceforge.cilib.pso.particle.StandardParticle.updateVelocity(StandardParticle.java:186) >> >> >> at >> >> >> > net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:69) >> >> >> at >> >> >> > net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:36) >> >> >> at net.sourceforge.cilib.pso.PSO.algorithmIteration(PSO.java:125) >> >> >> at >> >> >> > net.sourceforge.cilib.algorithm.Algorithm.performIteration(Algorithm.java:140) >> >> >> at net.sourceforge.cilib.algorithm.Algorithm.run(Algorithm.java:182) >> >> >> >> >> >> >> >> >> > ------------------------------------------------------------------------ >> >> >> >> >> >> > ------------------------------------------------------------------------------ >> >> >> >> >> >> >> >> >> > ------------------------------------------------------------------------ >> >> >> >> >> >> _______________________________________________ >> >> >> Cilib-users mailing list >> >> >> Cil...@li... >> >> >> https://lists.sourceforge.net/lists/listinfo/cilib-users >> >> > >> >> > > ------------------------------------------------------------------------------ >> >> > _______________________________________________ >> >> > Cilib-users mailing list >> >> > Cil...@li... >> >> > https://lists.sourceforge.net/lists/listinfo/cilib-users >> |
From: <lab...@gm...> - 2009-01-05 14:57:49
|
Sorry, I was on vacation. Happy New Year to all, BTW :-) Here's an xml file. Maybe I'm doing something wrong? TIA. <?xml version="1.0"?> <!DOCTYPE simulator [ <!ATTLIST algorithm id ID #IMPLIED> <!ATTLIST problem id ID #IMPLIED> <!ATTLIST measurements id ID #IMPLIED> ]> <simulator> <algorithms> <algorithm id="gbest" class="pso.PSO"> <addStoppingCondition class="stoppingcondition.MaximumIterations" maximumIterations="1000" /> </algorithm> </algorithms> <problems> <problem id="spherical" class="problem.FunctionMinimisationProblem"> <function class="functions.continuous.Spherical" domain="[R(-5.0,5.0)^5]^5"/> </problem> </problems> <measurements id="fitness" class="simulator.MeasurementSuite" resolution="10" samples="1"> <addMeasurement class="measurement.single.Fitness"/> </measurements> <simulations> <simulation> <algorithm idref="gbest"/> <problem idref="spherical"/> <measurements idref="fitness" file="data/spherical3.gbest.p20w1.0c1_2c2_2NoVmax.txt"/> </simulation> </simulations> </simulator> On Dec 23, 2008 6:54am, Gary Pampara <gpa...@gm...> wrote: > Continuing this discussion on the developer list. > > > > Gary Pampara wrote: > > > Hi, > > > > > > I'll have a look at this. > > > > > > Regards, > > > Gary > > > > > > lab...@gm... wrote: > > >> registry.setDomainString("[R(-5.0, 5.0)^10]^10"); > > >> yeah, that does not work too well. I get the following error: > > >> > > >> Exception in thread "main" java.lang.UnsupportedOperationException: > > >> Attempted to perform a numeric operation on non-numeric type > > >> at > > >> net.sourceforge.cilib.type.types.container.Vector.getNumeric(Vector.java:414) > > >> at > > >> net.sourceforge.cilib.type.types.container.Vector.getReal(Vector.java:466) > > >> at > > >> net.sourceforge.cilib.pso.velocityupdatestrategies.StandardVelocityUpdate.updateVelocity(StandardVelocityUpdate.java:89) > > >> at > > >> net.sourceforge.cilib.pso.particle.StandardParticle.updateVelocity(StandardParticle.java:186) > > >> at > > >> net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:69) > > >> at > > >> net.sourceforge.cilib.pso.iterationstrategies.SynchronousIterationStrategy.performIteration(SynchronousIterationStrategy.java:36) > > >> at net.sourceforge.cilib.pso.PSO.algorithmIteration(PSO.java:125) > > >> at > > >> net.sourceforge.cilib.algorithm.Algorithm.performIteration(Algorithm.java:140) > > >> at net.sourceforge.cilib.algorithm.Algorithm.run(Algorithm.java:182) > > >> > > >> > > >> ------------------------------------------------------------------------ > > >> > > >> ------------------------------------------------------------------------------ > > >> > > >> > > >> ------------------------------------------------------------------------ > > >> > > >> _______________________________________________ > > >> Cilib-users mailing list > > >> Cil...@li... > > >> https://lists.sourceforge.net/lists/listinfo/cilib-users > > > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > > > Cilib-users mailing list > > > Cil...@li... > > > https://lists.sourceforge.net/lists/listinfo/cilib-users > |