From adam.david.rose at googlemail.com Thu Aug 14 03:17:44 2008 From: adam.david.rose at googlemail.com (Adam Rose) Date: Thu, 14 Aug 2008 08:17:44 +0100 Subject: [gecoder-users] Mixin ? Message-ID: <3a130fb0808140017m278ef94m48dcb296c6ba6cc1@mail.gmail.com> Hi, Are there any plans to make Gecode a Mixin rather than something I inherit from ? If it were a Mixin then it becomes easier to add constraints to an existing inheritance hierarchy. Thanks, Adam. -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.david.rose at googlemail.com Thu Aug 14 04:17:29 2008 From: adam.david.rose at googlemail.com (Adam Rose) Date: Thu, 14 Aug 2008 09:17:29 +0100 Subject: [gecoder-users] next_solution ? Message-ID: <3a130fb0808140117ua6f3642y5fbcb113bde6fec0@mail.gmail.com> I might be being stupid here, but I would like to do something like this : 3.times { t.next_solution! p t } t.solve! gives me the first solution each time - and so does t.solution {} Have I missed something ? . -------------- next part -------------- An HTML attachment was scrubbed... URL: From rubyforge at lokorin.org Thu Aug 14 05:07:39 2008 From: rubyforge at lokorin.org (Andreas Launila) Date: Thu, 14 Aug 2008 11:07:39 +0200 Subject: [gecoder-users] next_solution ? In-Reply-To: <3a130fb0808140117ua6f3642y5fbcb113bde6fec0@mail.gmail.com> References: <3a130fb0808140117ua6f3642y5fbcb113bde6fec0@mail.gmail.com> Message-ID: <48A3F5DB.80003@lokorin.org> Adam Rose wrote: > > I might be being stupid here, but I would like to do something like this : > > 3.times { > t.next_solution! > p t > } > > t.solve! gives me the first solution each time - and so does t.solution {} > > Have I missed something ? > . t.each_solution do |solution| p solution end If you only want three solutions (admittably not that pretty): i = 0 q.each_solution do |solution| puts solution i += 1 break unless i < 3 end -- Andreas Launila From rubyforge at lokorin.org Thu Aug 14 05:23:22 2008 From: rubyforge at lokorin.org (Andreas Launila) Date: Thu, 14 Aug 2008 11:23:22 +0200 Subject: [gecoder-users] Mixin ? In-Reply-To: <3a130fb0808140017m278ef94m48dcb296c6ba6cc1@mail.gmail.com> References: <3a130fb0808140017m278ef94m48dcb296c6ba6cc1@mail.gmail.com> Message-ID: <48A3F98A.3000207@lokorin.org> Adam Rose wrote: > Are there any plans to make Gecode a Mixin rather than something I > inherit from ? > Making it a mixin hasn't been considered before. Could you give an example when one would want to define a model in a class inheriting from a class other than Gecode::Model? It does seem possible since Gecode::Model doesn't depend on its constructor being called by subclasses. Gecode::Model does define a slew of methods and instance variables though, but they should hopefully have unique enough names to not be overwritten by accident. Although #method_missing needs to be altered so it wraps that method in the class that it's mixed into. I'm not sure if it would be a good idea to remove the ability of inheriting from Gecode::Model all together. At any rate the mixin would have to be called something other than Gecode::Model, since that doesn't strike me as a good mixin name. Do you have any name suggestions? On a related note: there is some sugar coming in the next version (currently in the trunk) that allows simple problems to be written without using classes. For instance, the problem on the Gecode/R front page[1] could be written as follows. solution = Gecode.solve do variables_is_an int_var_array(3, 0..9) x, y, z = variables (x + y).must == z x.must == y - 3 branch_on variables end puts solution.variables.values.join(' ') [1] http://gecoder.rubyforge.org/ -- Andreas Launila From rubyforge at lokorin.org Fri Aug 15 05:00:50 2008 From: rubyforge at lokorin.org (Andreas Launila) Date: Fri, 15 Aug 2008 11:00:50 +0200 Subject: [gecoder-users] Mixin ? In-Reply-To: <3a130fb0808150040q3bf33fcfq28dafb0cc36a8853@mail.gmail.com> References: <3a130fb0808140017m278ef94m48dcb296c6ba6cc1@mail.gmail.com> <48A3F98A.3000207@lokorin.org> <3a130fb0808150040q3bf33fcfq28dafb0cc36a8853@mail.gmail.com> Message-ID: <48A545C2.8040200@lokorin.org> Adam Rose wrote: > This snippet of pseudo code illustrates various problems : > - we inherit from a "electronics industry specific base class" so it's a > bit painful to get the randomization by inheriting from the base class > which provides the randomization I have attached a patch for the changes needed to make Gecode::Model a mixin in Gecode/R 0.8.3. Basically just replace all occurrences of "class Model" with "module Model". I would include a separate mixin alternative in the next version if I had a better name for a mixin than "Gecode::Model". The only names I can think of off the top of my head are: Gecode::Modellable Gecode::Constrainable Gecode::Mixin The last one is probably the best one, but there should be far better names. > - we define what are really something like ints but then we define > constraints on bit wise slices of those ints There is no direct support for that. What you could do is to let each slice you use be an integer variable and then place a linear constraint on those slices to construct the entire "address" (if you need to place a constraint on that too). > - we need some way to get a sequence of randomly selected solutions > separated by ad-hoc bits of functionality. The only way to get a random solution at this point in Gecode/R is to fetch a number of solutions and then select one of them randomly (or rather, iterate through the solutions and stop at some random point). If you need a uniform sample then it would entail fetching all solutions and then sampling those. If you were using Gecode directly then I think it would be possible to define a custom branching strategy that would act in a random fashion. There is some randomization support coming in Gecode 3.0[1]. > > I will try to find what you're doing with missing_method in the rdoc > documentation. In my experiments I have also defined missing_method, so > this could cause some problems. > #method_missing is only used in the current trunk, not in 0.8.3 apparently. So there is no need to worry about that. [1] http://www.gecode.org/gecode-users/2008-June/002331.html -- Andreas Launila -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mixin.diff URL: From rubyforge at lokorin.org Mon Aug 18 07:58:20 2008 From: rubyforge at lokorin.org (Andreas Launila) Date: Mon, 18 Aug 2008 13:58:20 +0200 Subject: [gecoder-users] [ANN] Gecode/R 0.9.0 Message-ID: <48A963DC.5070201@lokorin.org> Gecode/R 0.9.0 has been released. This release contains all the functionality that has been planned for 1.0.0. Most of the work has gone into changing the way that constraints work. This change replaces the concept of "composite constraints" with "operands"[1]. It doesn't break backwards compatibility, except for the distinct constraint with offsets (noted in the change log), so you can keep on writing without worrying too much about it. The point is that it allows combinations of constraints that previously were not possible, such as "(set1.size + set2.size).must > int.abs - 3". The RDoc documentation[2] has largely been reorganized in the process. Feedback is welcome, especially pointing out weak/non-existent documentation. Another change that breaks backwards-compatibility is that an exception (Gecode::NoSolutionError) is now thrown if no solution could be found (rather than returning nil). Some sugar has also been added. It allows solving a problem without explicitly having to define a class for it. The equation system on the Gecode/R frontpage[3] can for instance be solved using: solution = Gecode.solve do x, y, z = vars_is_an int_var_array(3, 0..9) (x + y).must == z x.must == y - 3 branch_on vars end puts solution.vars.values.join(' ') See [4,5,6] for explanation. The focus is now on getting ready for the 1.0.0 release. This means improving the documentation and checking for performance problems (cases when Gecode/R does a poor translation of constraints to Gecode). This is also the last chance to make backwards-compatibility-breaking changes before putting stakes in the ground == Short introduction to operands Variables, as well as combinations of variables (such as "int_var1 + int_var2"), are now called operands. The type of operand decides what constraints can be used. For instance, the integer relation constraint (==, <, >, <=, >=) can be placed on any integer operand. Examples of integer operands are: int_var1 + int_var2 set.size int_enum[int_var] so we can place the constraint "> 17" on all of them, just like we have always been able to. (int_var1 + int_var2).must > 17 set.size.must > 17 int_enum[int_var].must > 17 All operands define a number of "properties" that produce new operands. For instance the set operand defines the property #size that produces an integer operand. A set variable is a set operand, that is why "set.size" is a integer operand. All other examples are also the result of properties being used. the first uses the #+ property of integer operands. The third uses the #[] property of integer enum operands (enumerations of each type have their own operand type). This allows us to continue chaining operands and properties to produce new operands. The following are all integer operands too. (int_var1 + int_var2)*17 set.size + int_var int_enum[int_var].squared Hence we can place the constraint "> 17" on all of them too. ((int_var1 + int_var2)*17).must > 17 (set.size + int_var).must > 17 int_enum[int_var].squared.must > 17 The full list of constraints and properties accepted by each type of operand are found in the documentation for each operand, accessed through the menu on the right of page[1]. == Changes: http://gecoder.rubyforge.org/details/changes.html * Variables that should be accessible from outside the model can now easily be created by calling "_is_a " where "" is the desired name of the variable and "" is the variable (e.g. "int_var(17)"). Take a look at the examples to see it in action. * Gecode.solve, Gecode.maximize and Gecode.minimize can now be used to solve a problem without first having to explicitly create a class for the model. * An exception (Gecode::NoSolutionError) is now thrown if a solution can not be found when using Model#solve!, Model#minimize!, Model#maximize! and Model#optimize! (rather than returning nil). This change breaks backwards compatibility. If you feel that this is a bad change then please tell the mailing list. * The offset option to the distinct constraint is now given as "int_enum.must_be.distinct(:offset => offsets)" rather than the previous "int_enum.with_offsets(offsets).must_be.distinct". * Complex combinations of several constraints such as "(set1.size + set2.size).must > int.abs - 3" can now be used. The underlying code has been changed quite a bit, but it should remain backwards compatible except for above mentioned exception. The change also brings about some changed terminology, which mostly aims to remove the concept of "composite constraints" and replace them with the more general "operands" (see the documentation for further details). * [#21578] Fixed a bug that caused options given to the boolean "false" domain constraint to not be processed. * [#21579] Fixed a bug that caused the integer enumeration equality constraint to not work at all (threw an exception). * [#21580] Fixed a bug that caused ranges that use three dots to not be correctly interpreted by the negated integer domain constraint. * [#21581] Fixed a bug that caused the abs constraint to prune away valid solutions in some cases. [1] http://gecoder.rubyforge.org/documentation/operands/index.html [2] http://gecoder.rubyforge.org/rdoc/index.html [3] http://gecoder.rubyforge.org/ [4] http://gecoder.rubyforge.org/documentation/index.html#accessing_variables_from_the_outside [5] http://gecoder.rubyforge.org/documentation/index.html#creating_models [6] http://gecoder.rubyforge.org/rdoc/classes/Gecode.html#M000002 From rubyforge at lokorin.org Mon Aug 18 08:21:23 2008 From: rubyforge at lokorin.org (Andreas Launila) Date: Mon, 18 Aug 2008 14:21:23 +0200 Subject: [gecoder-users] Mixin ? In-Reply-To: <3a130fb0808140017m278ef94m48dcb296c6ba6cc1@mail.gmail.com> References: <3a130fb0808140017m278ef94m48dcb296c6ba6cc1@mail.gmail.com> Message-ID: <48A96943.1020201@lokorin.org> Adam Rose wrote: > > Are there any plans to make Gecode a Mixin rather than something I > inherit from ? > I have added a branch at /branches/mixin in SVN that defines a mixin Gecode::Mixin and has Gecode::Model mix it in. I'm not that happy with the straight forward approach used as it would mean moving all documentation to Gecode::Mixin and require a decent amount changes to the documentation (since the documentation pointing to Model would have to be rewritten to use Mixin). I'm also not convinced that I would want to mixin rather than inherit if given a choice. It might be that I'm too used to thinking of the created class, the model, as something encapsulated that has as only purpose to define the problem (rather than the problem being defined inside some other context, using tools provided by a mixin). Hence I did not include the straight forward approach in the newly released version 0.9.0. An alternative would be to keep all the methods in Gecode::Model and do something tricky to make Gecode::Mixin act as a mixin version of Gecode::Model (e.g. hook the mixin call, create an instance of Model and then delegate all calls to it). I'm not sure whether that's possible (and I haven't tried it), but such a solution would just add a Mixin as an option (without requiring any other change). If you have any other suggestions (or working solutions) then please tell me. -- Andreas Launila From rubyforge at lokorin.org Mon Aug 18 16:10:20 2008 From: rubyforge at lokorin.org (Andreas Launila) Date: Mon, 18 Aug 2008 22:10:20 +0200 Subject: [gecoder-users] [ANN] Gecode/R 0.9.0 In-Reply-To: <48A963DC.5070201@lokorin.org> References: <48A963DC.5070201@lokorin.org> Message-ID: <48A9D72C.40702@lokorin.org> There are some problems with the packaging. The gems have a load of unnecessary dependencies due to RubyGems bug #21510 [1], The problem has been corrected and the uploaded gems have been replaced. There does however seem to be some caching going on as directly downloading a gem results in getting the buggy packaging. Additionally, gems does not seem to see the Windows-specific gem. Or at least Windows machines are getting the Ruby gem rather than the precompiled one. I'm not sure whether this is due to the gem servers not having circulated the Windows gem yet or due to me having upgraded to using RubyGems 1.2.0. Downloading the gem directly from the download page still works, but has the above mentioned problem with caching. If gems does not detect the Windows platform by tomorrow then I will install the older (working) version of RubyGems and issue new packages. I will also use a new version number if the caching of direct downloads still remains by then. [1] http://rubyforge.org/tracker/?group_id=126&atid=575&func=detail&aid=21510 -- Andreas Launila From rubyforge at lokorin.org Tue Aug 19 05:57:41 2008 From: rubyforge at lokorin.org (Andreas Launila) Date: Tue, 19 Aug 2008 11:57:41 +0200 Subject: [gecoder-users] [ANN] Gecode/R 0.9.0 In-Reply-To: <48A9D72C.40702@lokorin.org> References: <48A963DC.5070201@lokorin.org> <48A9D72C.40702@lokorin.org> Message-ID: <48AA9915.7050808@lokorin.org> Andreas Launila wrote: > There are some problems with the packaging. The gems have a load of > unnecessary dependencies due to RubyGems bug #21510 [1], > > [...] > > Additionally, gems does not seem to see the Windows-specific gem. Or at > least Windows machines are getting the Ruby gem rather than the > precompiled one. > Both problem have been fixed. The gems should now work correctly, both through RubyGems (1.2.0 at least) and direct downloads from the file list. -- Andreas Launila From emmanueloga at gmail.com Thu Aug 21 09:33:22 2008 From: emmanueloga at gmail.com (Emmanuel Oga) Date: Thu, 21 Aug 2008 10:33:22 -0300 Subject: [gecoder-users] 2d bin packing with gecoder Message-ID: Hey I just put together what wants to be a 2d rectangle packer... http://pastie.org/257193 Download the file, place it in ROOT/lib, place a couple of images in ROOT/img, and run the script. You will need: require 'rubygems' require 'RMagick' require 'gecoder' I have a problem with the constraints... I'm not sure how can I branch for getting minimal area of the final result. What do you think? Currently it just builds a linear strip of photos, something I could do without a constraint solver hehehe. This is the first time I use this kind of algorithms, thanks for your patience :). Thanks for All! ...by the way, I believe this would be an excellent addition to the already cool selection of examples! -- -------------------------------------------------------------- EmmanuelOga.Wordpress.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rubyforge at lokorin.org Thu Aug 21 13:11:47 2008 From: rubyforge at lokorin.org (Andreas Launila) Date: Thu, 21 Aug 2008 19:11:47 +0200 Subject: [gecoder-users] 2d bin packing with gecoder In-Reply-To: References: Message-ID: <48ADA1D3.7040603@lokorin.org> Emmanuel Oga wrote: > I just put together what wants to be a 2d rectangle packer... > > http://pastie.org/257193 > > [...] > I have a problem with the constraints... I'm not sure how can I > branch for > getting minimal area of the final result. What do you think? > For the minimization you should use Model#minimize! [1] or Model#optimize! [2] (the former is sugar for using the latter). < # # This does not work. < # area_is_an int_var(1..(max_width * max_height)) < # < # area = @xs.max * @ys.max < # < # branch_on area, :variable => :smallest_size, :value => :min --- > area_is_an int_var(1..(max_width * max_height)) > (@xs.max * @ys.max).must == area 79c74 < solve! --- > minimize! :area This is not quite complete though since @xs.max * @ys.max is not the actual area since the coordinates are the upper left corners of the images. Two ways to solve it is to use bottom right corners as coordinates or construct a pair of variables that are constrained to be the bottom-right-most corner. I would try the second one since I don't think you need the upper-left corner representation anywhere (although changing the representation will require changing many of the constraints). Also you forgot to remove this #solve! (in the paste the problem is solved twice): 118c113 < @tiler = Tiler.new(image_structs).solve! --- > @tiler = Tiler.new(image_structs) 160c155 [1] http://gecoder.rubyforge.org/rdoc/classes/Gecode/Model.html#M000104 [2] http://gecoder.rubyforge.org/rdoc/classes/Gecode/Model.html#M000102 -- Andreas Launila From AEtzold at gmx.de Fri Aug 22 09:11:43 2008 From: AEtzold at gmx.de (Axel Etzold) Date: Fri, 22 Aug 2008 15:11:43 +0200 Subject: [gecoder-users] Sets of solutions from gecoder ? In-Reply-To: References: Message-ID: <20080822131143.74780@gmx.net> Dear all, is it possible to use gecoder to output a set of solutions, rather than a single one ? I would like to do this for two reasons: 1.) One problem I'm working on can be described as a matrix equation Ax=b, where A and b are given, and the searched-for x has only non-negative integer entries. Now, I'd like to be able to find all x such that the norm of (Ax-b) doesn't become larger than some value c, or the, say, ten vectors x with the smallest norm values for (Ax-b). 2.) I'd like to identify non-relevant constraints, such as in a set of constraints x must be smaller than 6, x must be smaller than 4, x must be bigger than 0, the first constraint is redundant, as it is always fulfilled if the second constraint holds. Constraint sets like this come up at runtime in a problem I'm dealing with (and in larger numbers) .... Thank you very much. Best regards, Axel -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf at gmx From rubyforge at lokorin.org Fri Aug 22 11:37:24 2008 From: rubyforge at lokorin.org (Andreas Launila) Date: Fri, 22 Aug 2008 17:37:24 +0200 Subject: [gecoder-users] Sets of solutions from gecoder ? In-Reply-To: <20080822131143.74780@gmx.net> References: <20080822131143.74780@gmx.net> Message-ID: <48AEDD34.1000200@lokorin.org> Axel Etzold wrote: > is it possible to use gecoder to output a set of solutions, rather than a single one ? > What you can do is to fetch the first k solutions using Model#each_solution [1], or, if you're optimizing some variable, record the solutions given to Model#optimize! [2]. > I would like to do this for two reasons: > > 1.) One problem I'm working on can be described as a matrix equation Ax=b, > where A and b are given, and the searched-for x has only non-negative integer entries. > Now, I'd like to be able to find all x such that the norm of (Ax-b) doesn't become larger > than some value c, or the, say, ten vectors x with the smallest norm values for > (Ax-b). What norm are you using? If you can express the norm in terms of a variable with constraints, then doing that and constraining the variable to be less than c would work. > > 2.) I'd like to identify non-relevant constraints, such as in a set of constraints > > x must be smaller than 6, > x must be smaller than 4, > x must be bigger than 0, > > the first constraint is redundant, as it is always fulfilled if the second constraint holds. > Constraint sets like this come up at runtime in a problem I'm dealing with (and in larger numbers) .... > I don't quite understand how outputting a set of solutions would help identifying these sort of cases. Some information that might be useful is that the above type of constraints, constraints that constrain a variable's domain using a constant, are applied upon the constraint being placed (by Gecode altering the domain of the variable). Hence redundant constraint of that type do not affect the amount of work done during the search (which is typically the costly part), they only create a bit of extra work during the initialization. [1] http://gecoder.rubyforge.org/rdoc/classes/Gecode/Model.html#M000100 [2] http://gecoder.rubyforge.org/rdoc/classes/Gecode/Model.html#M000102 -- Andreas Launila From rubyforge at lokorin.org Sun Aug 24 14:53:10 2008 From: rubyforge at lokorin.org (Andreas Launila) Date: Sun, 24 Aug 2008 20:53:10 +0200 Subject: [gecoder-users] Mixin ? In-Reply-To: <48A96943.1020201@lokorin.org> References: <3a130fb0808140017m278ef94m48dcb296c6ba6cc1@mail.gmail.com> <48A96943.1020201@lokorin.org> Message-ID: <48B1AE16.9090309@lokorin.org> Andreas Launila wrote: > Adam Rose wrote: >> Are there any plans to make Gecode a Mixin rather than something I >> inherit from ? >> > An alternative would be to keep all the methods in Gecode::Model and do > something tricky to make Gecode::Mixin act as a mixin version of > Gecode::Model (e.g. hook the mixin call, create an instance of Model and > then delegate all calls to it). I'm not sure whether that's possible > (and I haven't tried it), but such a solution would just add a Mixin as > an option (without requiring any other change). > Such a solution is now in the trunk as of r719. It mimics a real mixin rather well and works fine when the mixee defines #method_missing. -- Andreas Launila From rubyforge at lokorin.org Tue Aug 26 16:33:21 2008 From: rubyforge at lokorin.org (Andreas Launila) Date: Tue, 26 Aug 2008 22:33:21 +0200 Subject: [gecoder-users] Mixin ? In-Reply-To: <48A96943.1020201@lokorin.org> References: <3a130fb0808140017m278ef94m48dcb296c6ba6cc1@mail.gmail.com> <48A96943.1020201@lokorin.org> Message-ID: <48B46891.8020808@lokorin.org> Andreas Launila wrote: > I have added a branch at /branches/mixin in SVN that defines a mixin > Gecode::Mixin and has Gecode::Model mix it in. I'm not that happy with > the straight forward approach used as it would mean moving all > documentation to Gecode::Mixin and require a decent amount changes to > the documentation (since the documentation pointing to Model would have > to be rewritten to use Mixin). I'm also not convinced that I would want > to mixin rather than inherit if given a choice. It might be that I'm too > used to thinking of the created class, the model, as something > encapsulated that has as only purpose to define the problem (rather than > the problem being defined inside some other context, using tools > provided by a mixin). > I think it might be best to remove the Gecode::Model inheritance all together. I.e. make mixing in Gecode::Mixin the only way to define a problem (bar sugar). The reasoning would be that mixins are more general than classes and that there is nothing preventing using mixins instead. On the other hand Gecode::Model does define plenty of methods and uses plenty of instance variables, but I don't think any of the method names would run a risk of being too common. The change would mean that class Foo < Gecode::Model def initialize # Formulate the problem. end end could no longer be used and would have to be replaced by class Foo include Gecode::Mixin def initialize # Formulate the problem. end end This would break backwards-compatibility, but this would be the right time to do it (before 1.0). I would like to hear some opinions about such a change. Is there anyone who would like to share their thoughts on the subject? [1] http://gecoder.rubyforge.org/rdoc_dev/classes/Gecode/Model.html -- Andreas Launila From adam.david.rose at googlemail.com Tue Aug 26 17:54:56 2008 From: adam.david.rose at googlemail.com (Adam Rose) Date: Tue, 26 Aug 2008 22:54:56 +0100 Subject: [gecoder-users] Mixin ? In-Reply-To: <48B46891.8020808@lokorin.org> References: <3a130fb0808140017m278ef94m48dcb296c6ba6cc1@mail.gmail.com> <48A96943.1020201@lokorin.org> <48B46891.8020808@lokorin.org> Message-ID: <3a130fb0808261454w21c0c8fawa12278aa9bec8190@mail.gmail.com> Andreas, Can't you do something like : module Gecode: module Mixin # put all the meat in here end class Model include Mixin end end ? All, This thread started off as a suggestion from me. My point is simply that we might want to do constraint programming in an inheritance hierarchy that starts from somewhere other than Gecode::Model. In general, I prefer that "toolkit" type stuff, even if it's a pretty complex toolkit, should be done as a mixin. Then any given class can include any number of toolkits ( assuming we can avoid name clash issues ). Thanks, Adam. On Tue, Aug 26, 2008 at 9:33 PM, Andreas Launila wrote: > Andreas Launila wrote: >> I have added a branch at /branches/mixin in SVN that defines a mixin >> Gecode::Mixin and has Gecode::Model mix it in. I'm not that happy with >> the straight forward approach used as it would mean moving all >> documentation to Gecode::Mixin and require a decent amount changes to >> the documentation (since the documentation pointing to Model would have >> to be rewritten to use Mixin). I'm also not convinced that I would want >> to mixin rather than inherit if given a choice. It might be that I'm too >> used to thinking of the created class, the model, as something >> encapsulated that has as only purpose to define the problem (rather than >> the problem being defined inside some other context, using tools >> provided by a mixin). >> > > I think it might be best to remove the Gecode::Model inheritance all > together. I.e. make mixing in Gecode::Mixin the only way to define a > problem (bar sugar). The reasoning would be that mixins are more general > than classes and that there is nothing preventing using mixins instead. > On the other hand Gecode::Model does define plenty of methods and uses > plenty of instance variables, but I don't think any of the method names > would run a risk of being too common. > > The change would mean that > > class Foo < Gecode::Model > def initialize > # Formulate the problem. > end > end > > could no longer be used and would have to be replaced by > > class Foo > include Gecode::Mixin > > def initialize > # Formulate the problem. > end > end > > This would break backwards-compatibility, but this would be the right > time to do it (before 1.0). > > I would like to hear some opinions about such a change. Is there anyone > who would like to share their thoughts on the subject? > > > [1] http://gecoder.rubyforge.org/rdoc_dev/classes/Gecode/Model.html > > -- > Andreas Launila > From rubyforge at lokorin.org Wed Aug 27 04:04:28 2008 From: rubyforge at lokorin.org (Andreas Launila) Date: Wed, 27 Aug 2008 10:04:28 +0200 Subject: [gecoder-users] Mixin ? In-Reply-To: <3a130fb0808261454w21c0c8fawa12278aa9bec8190@mail.gmail.com> References: <3a130fb0808140017m278ef94m48dcb296c6ba6cc1@mail.gmail.com> <48A96943.1020201@lokorin.org> <48B46891.8020808@lokorin.org> <3a130fb0808261454w21c0c8fawa12278aa9bec8190@mail.gmail.com> Message-ID: <48B50A8C.2020506@lokorin.org> Adam Rose wrote: > Can't you do something like : > > module Gecode: > module Mixin > # put all the meat in here > end > class Model > include Mixin > end > end Yes, that would be mostly equivalent to what is in the trunk at the moment (except that Model is the preferred method). I don't really see any reason to keep the Model class though, and I would rather not confuse users by having multiple ways to do the same thing when one is enough. > > This thread started off as a suggestion from me. My point is simply > that we might want to do constraint programming in an inheritance > hierarchy that starts from somewhere other than Gecode::Model. > > In general, I prefer that "toolkit" type stuff, even if it's a pretty > complex toolkit, should be done as a mixin. Then any given class can > include any number of toolkits ( assuming we can avoid name clash > issues ). > I didn't really consider making it a mixin before your suggestion. If I had considered that option in the beginning then there would never have been a Model class. Therefore I'm very thankful for your timely suggestion. My primary concern against removing the Model class is that users will not like to have to change all their existing programs. On the other hand there's a clear warning in the installation instructions saying that there will be backwards-compatibility breaking changes time and time again, so it shouldn't come as a surprise. -- Andreas Launila From rubyforge at lokorin.org Fri Aug 29 10:05:50 2008 From: rubyforge at lokorin.org (Andreas Launila) Date: Fri, 29 Aug 2008 16:05:50 +0200 Subject: [gecoder-users] Mixin ? In-Reply-To: <48B50A8C.2020506@lokorin.org> References: <3a130fb0808140017m278ef94m48dcb296c6ba6cc1@mail.gmail.com> <48A96943.1020201@lokorin.org> <48B46891.8020808@lokorin.org> <3a130fb0808261454w21c0c8fawa12278aa9bec8190@mail.gmail.com> <48B50A8C.2020506@lokorin.org> Message-ID: <48B8023E.6070005@lokorin.org> Andreas Launila wrote: > Adam Rose wrote: >> Can't you do something like : >> >> module Gecode: >> module Mixin >> # put all the meat in here >> end >> class Model >> include Mixin >> end >> end > > Yes, that would be mostly equivalent to what is in the trunk at the > moment (except that Model is the preferred method). I don't really see > any reason to keep the Model class though, and I would rather not > confuse users by having multiple ways to do the same thing when one is > enough. > There is actually at least one reason for having Model around. Many specs directly instance Model (and then call its methods from outside) since it's too cumbersome to define a new trivial class for each spec. Hence I have left Model alone as a convenience class for that purpose. -- Andreas Launila From rubyforge at lokorin.org Fri Aug 29 12:44:30 2008 From: rubyforge at lokorin.org (Andreas Launila) Date: Fri, 29 Aug 2008 18:44:30 +0200 Subject: [gecoder-users] [ANN] Gecode/R 0.9.1 Message-ID: <48B8276E.3060605@lokorin.org> Gecode/R 0.9.1 has been released. The primary change is that the preferred way to define a model is now to define a class that mixes in Gecode::Mixin (it can also be mixed into the top level context for simple scripts and irb experimentation). Gecode::Model will remain as a convenience class, but it is recommended to start using the mixin rather than inheritance when possible. I.e. class Foo < Gecode::Model def initialize # Define the problem. end end becomes class Foo include Gecode::Mixin def initialize # Define the problem. end end or even include Gecode::Mixin # Define the problem. On another note: The backend has been updated to Gecode 2.2.0 (released earlier this week). If you are using the gecoder gem then you will need to update the Gecode version to use 0.9.1 (or switch to the gecoder-with-gecode gem if you don't want to update the entire system's Gecode version). == Changes: http://gecoder.rubyforge.org/details/changes.html * Added Gecode::Mixin which can be mixed in rather than inheriting from Gecode::Model. Thanks goes to Adam Rose for the suggestion. * Updated the backend to Gecode 2.2.0. See http://www.gecode.org/gecode-doc-latest/PageChanges_2_2_0.html for a list of changes.