Menu
▾
▴
cilib-users — CILib Users
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-10-29 08:16:47
|
Hi everyone, Version 0.7.3.1 of CIlib has been released. The new version corrects a few performance problems and corrects an issue related to randomization of Reals. Please head on over to http://code.google.com/p/cilib/downloads/list and get a copy of the new release. Regards, Gary |
|
From: Gary P. <gpa...@gm...> - 2009-10-19 10:00:47
|
Hi all, Version 0.7.3 of CIlib has been released. Notable changes: - New Neural Network framework that provides a very simple and extensible base for future additions. - Cooperative framework cleanup and addition of heterogeneous cooperative algorithms. Rename of various packages to make the intention of the packages clearer. - Addition of the Dynnamic enviroment changes that have been outstanding. - Initial commit of the new data framework. - Restructure of the Entity hierarchy ensuring a more modular design. - Numeric type updates (particularly around the manner in which Bound instances are used). - A number of bug fixes pertaining to memory usage and performance. The new version is available from our new hosting at Google Code (http://code.google.com/p/cilib) Regards, Gary |
|
From: Gary P. <gpa...@gm...> - 2009-09-18 07:03:35
|
Hi all, It's been a while since the last release, but I'm glad to announce that 0.7.2 of CIlib has been released. Changes are as follows: Additions: - New domain parser implementation with simplified usage API. - Generic EP algorithm has been included. - Initial generic Niching framework (including the NichePSO) has been included with a selection of different available operators. - Updates to the Immutable Matrix API. - Algorithm hierarchy has been simplified to facility more testability. - Documentation updates. Removed: - Entity.getBehavioralDomain() method as it was no longer used - Algorithm.reset() method did not do anything - EntityType.Individual* enum has been removed as the manner in which strategy parameters are handled was not correct. Head on over to the website http://www.cilib.net and grab a copy. As always, feature / support / bug reports are welcome. Regards, CIlib Team. |
|
From: Gary P. <gpa...@gm...> - 2009-08-31 06:04:26
|
Version 0.7.1.1 of CIlib has been released. This is a maintenance release that addresses some concurrency problems with multiple threads reading the same XML specification. Other than that, the release is no different to the 0.7.1 release, however, it is recommended to upgrade to 0.7.1.1 Regards, The CIlib team. |
|
From: Gary P. <gpa...@gm...> - 2009-08-14 07:02:19
|
Version 0.7.1 of CIlib has been released. Changes include: * PSO: - Addition of Constriction velocity update enabling the Constriction PSO. * DE: - Added rand-to-best-selection. * Measurements: - Bound violation measurements have been included. * Types: - Immutable Matrix class added. * General: - Enabled "unique" selection in Selection<E>. - Corrections to various Function classes. - Function<F, T> interface is now generic. Defining the types that the Function converts "from" and "to". - Default ordering for Entity classes is now a "natural ordering" from smallest to largest. - Better usage of Random number generation instances. - Removed ambiguous getPopulationSize() methods. - Generalized the Initialization strategies. - Parser generated DomainParser. DomainParser is now based on a grammar. Head on over to http://www.cilib.net. |
|
From: Gary P. <gpa...@gm...> - 2009-08-14 05:38:18
|
Hi, Could you be a little more specific regarding the type? The current version (0.7) uses a rather poor parser implementation. As a result, one of the key changes in the 0.7.1 release is the addition of a generated parser that is a lot more flexible. 0.7.1 will be released today. I'm currently finalizing the remainder of the patches and will be releasing in about 2 hours or so. With the new release, the DomainValidator and DomainBuilder classes fall away completely. This is definitely a step forward but it's a needed change :) Regards, Gary On Thursday 13 August 2009 18:08:36 lab...@gm... wrote: > Hello, > > I want to make a new type so that I could make specific updates for it. So, > I've extended the Int type to an Enum type and gave it a string > representation. However, DomainValidator does not recognize it. What to do? > > TIA, > > myriam |
|
From: <lab...@gm...> - 2009-08-13 16:08:47
|
Hello, I want to make a new type so that I could make specific updates for it. So, I've extended the Int type to an Enum type and gave it a string representation. However, DomainValidator does not recognize it. What to do? TIA, myriam |
|
From: <da...@on...> - 2009-08-08 14:18:03
|
I am out of the office until 2009/08/10. Hi, Please note that I am on leave and will be back in the office on the 10th of August. For any urgent matters please contact Enrico or Danny. Kind Regards Dawid Joubert Note: This is an automated response to your message "Cilib-users Digest, Vol 22, Issue 1" sent on 2009/08/08 02:03:45 PM. This is the only notification you will receive while this person is away. |
|
From: Gary P. <gpa...@gm...> - 2009-08-07 14:24:45
|
Hi all, CIlib now is hosting a phpbb forum for additional discussions. Please head to http://forums.cilib.net and register an account. Regards, Gary |
|
From: gpampara <gpa...@cs...> - 2009-07-16 15:24:49
|
Hi, Have a look at the src/test/java/net/sourceforge/cilib/ec/ECTest.java unit test. You will need to create a SeedSelectionStrategy that will use the seed that you need. You will, however, need to ensure that the SeedSelectionStrategy is set before any RNGs are instantiated. Regards, Gary On Thu, 16 Jul 2009 14:19:27 +0000, lab...@gm... wrote: > How do I set the seed to get the same results each time? > Sorry, I'm against a deadline and i thought it will be faster to ask. > > myriam |
|
From: <lab...@gm...> - 2009-07-16 14:19:35
|
How do I set the seed to get the same results each time? Sorry, I'm against a deadline and i thought it will be faster to ask. myriam |
|
From: Gary P. <gpa...@gm...> - 2009-06-08 09:24:38
|
Hi, I'm not following your question? The calculatefitness() method is defined on the Entity interface. StandardParticle does in fact expose this method and implement it using an EntityBasedFitnessCalculator. Could you perhaps provide an example of the usage? Regards, Gary On Friday 05 June 2009 23:36:40 lab...@gm... wrote: > I have another question. > > I am trying to get the fitness of a particle (individual) through some > agent-based simulation. However, the calculateFitness method is called with > the solution vector and not the particle object. Has anybody done that > before? > > TIA, > > myriam |
|
From: <da...@on...> - 2009-06-06 14:01:44
|
I am out of the office until 09/06/2009. Hi, Please note that I am on study leave and will only be back to attend to queries on the 9th of June arounf 13:30. For any urgent matters please call Sharief or Danny or contact me on my cellphone. Note: This is an automated response to your message "Cilib-users Digest, Vol 20, Issue 2" sent on 2009/06/06 02:03:17 PM. This is the only notification you will receive while this person is away. |
|
From: <lab...@gm...> - 2009-06-05 21:37:24
|
I have another question. I am trying to get the fitness of a particle (individual) through some agent-based simulation. However, the calculateFitness method is called with the solution vector and not the particle object. Has anybody done that before? TIA, myriam |
|
From: Gary P. <gpa...@gm...> - 2009-06-03 05:11:38
|
Hi, Let us know if you need any assistance with the usage of the new MOO stuff (if you don't come right based on the VEPSO example). Always willing to help. Regards, Gary On Wednesday 03 June 2009 02:21:24 Wiehann Matthysen wrote: > Hallo, > > MOPSO have been replaced with MOVelocityUpdateStrategy and > GuideSelectionStrategy classes. The reason for this is that most (if not > all) MOPSO's work on the basis of selecting two guides: a local guide > and a global guide. Thus, if you can specify how these guides gets > selected then you can construct a MOPSO. A guide selection strategy for > VEPSO have already been implemented. Just take a look at the vepso.xml > file for an example of how to compose a MOPSO. > > Regards, > > Wiehann Matthysen > > On Tue, Jun 2, 2009 at 6:48 PM, <lab...@gm...> wrote: > > how do I do MOO with PSO in 7.0? I recall that there was MOPSO before but > > I don't see it now. > > TIA > > m > > > > ------------------------------------------------------------------------- > >----- OpenSolaris 2009.06 is a cutting edge operating system for > > enterprises looking to deploy the next generation of Solaris that > > includes the latest innovations from Sun and the OpenSource community. > > Download a copy and enjoy capabilities such as Networking, Storage and > > Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get > > _______________________________________________ > > Cilib-users mailing list > > Cil...@li... > > https://lists.sourceforge.net/lists/listinfo/cilib-users |
|
From: Wiehann M. <wie...@ro...> - 2009-06-03 00:52:18
|
Hallo, MOPSO have been replaced with MOVelocityUpdateStrategy and GuideSelectionStrategy classes. The reason for this is that most (if not all) MOPSO's work on the basis of selecting two guides: a local guide and a global guide. Thus, if you can specify how these guides gets selected then you can construct a MOPSO. A guide selection strategy for VEPSO have already been implemented. Just take a look at the vepso.xml file for an example of how to compose a MOPSO. Regards, Wiehann Matthysen On Tue, Jun 2, 2009 at 6:48 PM, <lab...@gm...> wrote: > how do I do MOO with PSO in 7.0? I recall that there was MOPSO before but I > don't see it now. > TIA > m > > ------------------------------------------------------------------------------ > OpenSolaris 2009.06 is a cutting edge operating system for enterprises > looking to deploy the next generation of Solaris that includes the latest > innovations from Sun and the OpenSource community. Download a copy and > enjoy capabilities such as Networking, Storage and Virtualization. > Go to: http://p.sf.net/sfu/opensolaris-get > _______________________________________________ > Cilib-users mailing list > Cil...@li... > https://lists.sourceforge.net/lists/listinfo/cilib-users > > |
|
From: <lab...@gm...> - 2009-06-02 18:48:11
|
how do I do MOO with PSO in 7.0? I recall that there was MOPSO before but I don't see it now. TIA m |
|
From: Gary P. <gpa...@gm...> - 2009-05-13 05:25:05
|
No problem. Glad it was as simple as that :) lab...@gm... wrote: > Oh, I see. There is already a get(index) method in the Vector class that > returns the type, so I can use it right now. I knew I was missing > something :-) thanks for clarifying that up. > > > On May 12, 2009 12:26pm, Gary Pampara <gpa...@gm...> wrote: >> Indeed it does. >> >> >> >> Well, with the 0.7.1 release of CIlib we will be removing the > getType() method and will be adding a simple get(index) method on the > Vector class. Vectors will be defined to work only on Numeric types > (Nuemric is the super class of Real, Bit and Int). We are still chatting > about the API on the developers list but the current notion of a Vector > of types will most probably become a TypeList type class (where TypeList > is a general list object that can take any Type instances). Bottom line > is that the code will be simplified and easier to use. >> >> >> >> You're calls to check if the returned type is a Real or a Bit should > still work and your PositionUpdateStrategy class shouldn't require any > additional changes. >> >> >> >> Would this solve your current problem? >> >> >> >> Regards, >> >> Gary >> >> >> >> lab...@gm... wrote: >> >> >> Hi, >> >> >> >> Yes, getType() was protected all along. My question is why? I need to > access it. I subclass PositionUpdateStrategy so that I can have mixed > types in a solution vector. So, I need to check for the type of each > element in the solution vector to see if it's a bit or a number and call > the appropriate position udate functions. Does that make sense? >> >> >> >> On May 12, 2009 7:30am, Gary Pampara gpa...@gm...> wrote: >> >> > Hi, >> >> > >> >> > >> >> > >> >> > Hmm.... that's strange. Wasn't the method protected all along? It > was intended to be an internal accessor if I remember correctly. We are > changing the Vector at the moment. We want the Vector to be specialized > with Numeric types. This greatly reduces the API complexity and we allow > you to directly vector.get(i) the elements of the vector. >> >> > >> >> > >> >> > >> >> > For now, please keep with your current work around. Sorry for any > issues it has caused. 0.7.1 of CIlib will be released relatively soon > and this will hopefully be corrected in that release through altering > the Vector class. >> >> > >> >> > >> >> > >> >> > Kind regards, >> >> > >> >> > Gary >> >> > >> >> > >> >> > >> >> > lab...@gm... wrote: >> >> > >> >> > > Hi! >> >> > >> >> > > >> >> > >> >> > > I'm now trying to integrate 0.7 with my code. >> >> > >> >> > > >> >> > >> >> > > I have a solution vector composed of bits and reals, so I need a >> >> > >> >> > > positionupdate method that takes care of this mix of data types. >> >> > >> >> > > I have a PositionUpdateStrategyMixin class that takes care of > that but >> >> > >> >> > > it relies on getType(index) to get the type of the element in the >> >> > >> >> > > solution vector. However, this method is protected in the Vector >> >> > >> >> > > container class. Why is it protected? I did recompile cilib to change >> >> > >> >> > > that but maybe you have another suggestion? >> >> > >> >> > > >> >> > >> >> > > TIA, >> >> > >> >> > > >> >> > >> >> > > myriam >> >> > >> >> > > >> >> > >> >> > > >> >> > >> >> > > > ------------------------------------------------------------------------ >> >> > >> >> > > >> >> > >> >> > > > ------------------------------------------------------------------------------ >> >> > >> >> > > The NEW KODAK i700 Series Scanners deliver under ANY > circumstances! Your >> >> > >> >> > > production scanning environment may not be a perfect world - but > thanks to >> >> > >> >> > > Kodak, there's a perfect scanner to get the job done! With the > NEW KODAK i700 >> >> > >> >> > > Series Scanner you'll get full speed at 300 dpi even with all image >> >> > >> >> > > processing features enabled. http://p.sf.net/sfu/kodak-com >> >> > >> >> > > >> >> > >> >> > > >> >> > >> >> > > > ------------------------------------------------------------------------ >> >> > >> >> > > >> >> > >> >> > > _______________________________________________ >> >> > >> >> > > Cilib-users mailing list >> >> > >> >> > > Cil...@li... >> >> > >> >> > > https://lists.sourceforge.net/lists/listinfo/cilib-users >> >> > >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> >> >> > ------------------------------------------------------------------------------ >> >> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your >> >> production scanning environment may not be a perfect world - but thanks to >> >> Kodak, there's a perfect scanner to get the job done! With the NEW > KODAK i700 >> >> Series Scanner you'll get full speed at 300 dpi even with all image > processing features enabled. http://p.sf.net/sfu/kodak-com >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> >> Cilib-users mailing list >> >> Cil...@li... >> >> https://lists.sourceforge.net/lists/listinfo/cilib-users >> >> > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your > production scanning environment may not be a perfect world - but thanks to > Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 > Series Scanner you'll get full speed at 300 dpi even with all image > processing features enabled. http://p.sf.net/sfu/kodak-com > > > ------------------------------------------------------------------------ > > _______________________________________________ > Cilib-users mailing list > Cil...@li... > https://lists.sourceforge.net/lists/listinfo/cilib-users |
|
From: <lab...@gm...> - 2009-05-12 21:25:46
|
Oh, I see. There is already a get(index) method in the Vector class that returns the type, so I can use it right now. I knew I was missing something :-) thanks for clarifying that up. On May 12, 2009 12:26pm, Gary Pampara <gpa...@gm...> wrote: > Indeed it does. > Well, with the 0.7.1 release of CIlib we will be removing the getType() > method and will be adding a simple get(index) method on the Vector class. > Vectors will be defined to work only on Numeric types (Nuemric is the > super class of Real, Bit and Int). We are still chatting about the API on > the developers list but the current notion of a Vector of types will most > probably become a TypeList type class (where TypeList is a general list > object that can take any Type instances). Bottom line is that the code > will be simplified and easier to use. > You're calls to check if the returned type is a Real or a Bit should > still work and your PositionUpdateStrategy class shouldn't require any > additional changes. > Would this solve your current problem? > Regards, > Gary > lab...@gm... wrote: > Hi, > Yes, getType() was protected all along. My question is why? I need to > access it. I subclass PositionUpdateStrategy so that I can have mixed > types in a solution vector. So, I need to check for the type of each > element in the solution vector to see if it's a bit or a number and call > the appropriate position udate functions. Does that make sense? > On May 12, 2009 7:30am, Gary Pampara gpa...@gm...> wrote: > > Hi, > > > > > > > > Hmm.... that's strange. Wasn't the method protected all along? It was > intended to be an internal accessor if I remember correctly. We are > changing the Vector at the moment. We want the Vector to be specialized > with Numeric types. This greatly reduces the API complexity and we allow > you to directly vector.get(i) the elements of the vector. > > > > > > > > For now, please keep with your current work around. Sorry for any > issues it has caused. 0.7.1 of CIlib will be released relatively soon and > this will hopefully be corrected in that release through altering the > Vector class. > > > > > > > > Kind regards, > > > > Gary > > > > > > > > lab...@gm... wrote: > > > > > Hi! > > > > > > > > > > I'm now trying to integrate 0.7 with my code. > > > > > > > > > > I have a solution vector composed of bits and reals, so I need a > > > > > positionupdate method that takes care of this mix of data types. > > > > > I have a PositionUpdateStrategyMixin class that takes care of that but > > > > > it relies on getType(index) to get the type of the element in the > > > > > solution vector. However, this method is protected in the Vector > > > > > container class. Why is it protected? I did recompile cilib to change > > > > > that but maybe you have another suggestion? > > > > > > > > > > TIA, > > > > > > > > > > myriam > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! > Your > > > > > production scanning environment may not be a perfect world - but > thanks to > > > > > Kodak, there's a perfect scanner to get the job done! With the NEW > KODAK i700 > > > > > Series Scanner you'll get full speed at 300 dpi even with all image > > > > > processing features enabled. http://p.sf.net/sfu/kodak-com > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > _______________________________________________ > > > > > Cilib-users mailing list > > > > > Cil...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/cilib-users > > > ------------------------------------------------------------------------ > ------------------------------------------------------------------------------ > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your > production scanning environment may not be a perfect world - but thanks to > Kodak, there's a perfect scanner to get the job done! With the NEW KODAK > i700 > Series Scanner you'll get full speed at 300 dpi even with all image > processing features enabled. http://p.sf.net/sfu/kodak-com > ------------------------------------------------------------------------ > _______________________________________________ > Cilib-users mailing list > Cil...@li... > https://lists.sourceforge.net/lists/listinfo/cilib-users |
|
From: Gary P. <gpa...@gm...> - 2009-05-12 16:26:57
|
Indeed it does. Well, with the 0.7.1 release of CIlib we will be removing the getType() method and will be adding a simple get(index) method on the Vector class. Vectors will be defined to work only on Numeric types (Nuemric is the super class of Real, Bit and Int). We are still chatting about the API on the developers list but the current notion of a Vector of types will most probably become a TypeList type class (where TypeList is a general list object that can take any Type instances). Bottom line is that the code will be simplified and easier to use. You're calls to check if the returned type is a Real or a Bit should still work and your PositionUpdateStrategy class shouldn't require any additional changes. Would this solve your current problem? Regards, Gary lab...@gm... wrote: > Hi, > > Yes, getType() was protected all along. My question is why? I need to > access it. I subclass PositionUpdateStrategy so that I can have mixed > types in a solution vector. So, I need to check for the type of each > element in the solution vector to see if it's a bit or a number and call > the appropriate position udate functions. Does that make sense? > > On May 12, 2009 7:30am, Gary Pampara <gpa...@gm...> wrote: > > Hi, > > > > > > > > Hmm.... that's strange. Wasn't the method protected all along? It was > intended to be an internal accessor if I remember correctly. We are > changing the Vector at the moment. We want the Vector to be specialized > with Numeric types. This greatly reduces the API complexity and we allow > you to directly vector.get(i) the elements of the vector. > > > > > > > > For now, please keep with your current work around. Sorry for any > issues it has caused. 0.7.1 of CIlib will be released relatively soon > and this will hopefully be corrected in that release through altering > the Vector class. > > > > > > > > Kind regards, > > > > Gary > > > > > > > > lab...@gm... wrote: > > > > > Hi! > > > > > > > > > > I'm now trying to integrate 0.7 with my code. > > > > > > > > > > I have a solution vector composed of bits and reals, so I need a > > > > > positionupdate method that takes care of this mix of data types. > > > > > I have a PositionUpdateStrategyMixin class that takes care of that but > > > > > it relies on getType(index) to get the type of the element in the > > > > > solution vector. However, this method is protected in the Vector > > > > > container class. Why is it protected? I did recompile cilib to change > > > > > that but maybe you have another suggestion? > > > > > > > > > > TIA, > > > > > > > > > > myriam > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! > Your > > > > > production scanning environment may not be a perfect world - but > thanks to > > > > > Kodak, there's a perfect scanner to get the job done! With the NEW > KODAK i700 > > > > > Series Scanner you'll get full speed at 300 dpi even with all image > > > > > processing features enabled. http://p.sf.net/sfu/kodak-com > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > _______________________________________________ > > > > > Cilib-users mailing list > > > > > Cil...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/cilib-users > > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your > production scanning environment may not be a perfect world - but thanks to > Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 > Series Scanner you'll get full speed at 300 dpi even with all image > processing features enabled. http://p.sf.net/sfu/kodak-com > > > ------------------------------------------------------------------------ > > _______________________________________________ > Cilib-users mailing list > Cil...@li... > https://lists.sourceforge.net/lists/listinfo/cilib-users |
|
From: <lab...@gm...> - 2009-05-12 15:29:16
|
Hi, Yes, getType() was protected all along. My question is why? I need to access it. I subclass PositionUpdateStrategy so that I can have mixed types in a solution vector. So, I need to check for the type of each element in the solution vector to see if it's a bit or a number and call the appropriate position udate functions. Does that make sense? On May 12, 2009 7:30am, Gary Pampara <gpa...@gm...> wrote: > Hi, > Hmm.... that's strange. Wasn't the method protected all along? It was > intended to be an internal accessor if I remember correctly. We are > changing the Vector at the moment. We want the Vector to be specialized > with Numeric types. This greatly reduces the API complexity and we allow > you to directly vector.get(i) the elements of the vector. > For now, please keep with your current work around. Sorry for any issues > it has caused. 0.7.1 of CIlib will be released relatively soon and this > will hopefully be corrected in that release through altering the Vector > class. > Kind regards, > Gary > lab...@gm... wrote: > > Hi! > > > > I'm now trying to integrate 0.7 with my code. > > > > I have a solution vector composed of bits and reals, so I need a > > positionupdate method that takes care of this mix of data types. > > I have a PositionUpdateStrategyMixin class that takes care of that but > > it relies on getType(index) to get the type of the element in the > > solution vector. However, this method is protected in the Vector > > container class. Why is it protected? I did recompile cilib to change > > that but maybe you have another suggestion? > > > > TIA, > > > > myriam > > > > > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------------ > > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your > > production scanning environment may not be a perfect world - but thanks > to > > Kodak, there's a perfect scanner to get the job done! With the NEW > KODAK i700 > > Series Scanner you'll get full speed at 300 dpi even with all image > > processing features enabled. http://p.sf.net/sfu/kodak-com > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Cilib-users mailing list > > Cil...@li... > > https://lists.sourceforge.net/lists/listinfo/cilib-users |
|
From: Gary P. <gpa...@gm...> - 2009-05-12 11:28:44
|
Hi, Hmm.... that's strange. Wasn't the method protected all along? It was intended to be an internal accessor if I remember correctly. We are changing the Vector at the moment. We want the Vector to be specialized with Numeric types. This greatly reduces the API complexity and we allow you to directly vector.get(i) the elements of the vector. For now, please keep with your current work around. Sorry for any issues it has caused. 0.7.1 of CIlib will be released relatively soon and this will hopefully be corrected in that release through altering the Vector class. Kind regards, Gary lab...@gm... wrote: > Hi! > > I'm now trying to integrate 0.7 with my code. > > I have a solution vector composed of bits and reals, so I need a > positionupdate method that takes care of this mix of data types. > I have a PositionUpdateStrategyMixin class that takes care of that but > it relies on getType(index) to get the type of the element in the > solution vector. However, this method is protected in the Vector > container class. Why is it protected? I did recompile cilib to change > that but maybe you have another suggestion? > > TIA, > > myriam > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your > production scanning environment may not be a perfect world - but thanks to > Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 > Series Scanner you'll get full speed at 300 dpi even with all image > processing features enabled. http://p.sf.net/sfu/kodak-com > > > ------------------------------------------------------------------------ > > _______________________________________________ > Cilib-users mailing list > Cil...@li... > https://lists.sourceforge.net/lists/listinfo/cilib-users |
|
From: <lab...@gm...> - 2009-05-11 19:52:44
|
Hi! I'm now trying to integrate 0.7 with my code. I have a solution vector composed of bits and reals, so I need a positionupdate method that takes care of this mix of data types. I have a PositionUpdateStrategyMixin class that takes care of that but it relies on getType(index) to get the type of the element in the solution vector. However, this method is protected in the Vector container class. Why is it protected? I did recompile cilib to change that but maybe you have another suggestion? TIA, myriam |
|
From: <da...@on...> - 2009-05-07 12:55:04
|
I am out of the office until 2009/05/11. Hi, Please note that I am on leave and will only be back to attend to queries on the 11th of May at around 11:00am. For any urgent matters please call Enrico or Sharief. Note: This is an automated response to your message "Cilib-users Digest, Vol 19, Issue 3" sent on 2009/05/07 02:03:04 PM. This is the only notification you will receive while this person is away. |
|
From: Gary P. <gpa...@gm...> - 2009-05-07 09:04:48
|
Hi,
It's been a long time coming and we have decided to make the version
jump to 0.7.
This release contains a load of new features. Most notable are:
- New game playing framework.
- Generic Multi-Objective algorithms.
- Several important memory optimizations and an execution speedup.
- Slightly more API documentation (Yes, this is something we are
focusing on).
Thank you to all who have contributed!
Your patches are most welcome. To those whose patches are still
outstanding, please be patient - upcoming releases will be smaller
in size and have a lot more additions.
Regards,
Gary
|
4 messages has been excluded from this view by a project administrator.
