From rubyforge at lokorin.org Sat Jun 9 16:38:18 2007 From: rubyforge at lokorin.org (Andreas Launila) Date: Sat, 09 Jun 2007 22:38:18 +0200 Subject: [gecoder-devel] Syntax direction Message-ID: <466B0FBA.903@lokorin.org> For the record: A discussion on the style of the syntax has been held over at ruby-talk[1]. Based on that discussion I have decided to go with the must/must_not syntax. The reason is mainly readability. It's a syntax that I think reads naturally for every example except possibly for count and channel. It also seems to be flexible enough to adapt for sets without consistency-problems. The downside to it is that the line must be read to understand what constraint is being used, i.e. it's harder to quickly scan the lines than with for example constrain_* . [1] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/254467 -- Andreas Launila From rubyforge at lokorin.org Mon Jun 18 13:13:07 2007 From: rubyforge at lokorin.org (Andreas Launila) Date: Mon, 18 Jun 2007 19:13:07 +0200 Subject: [gecoder-devel] Rebinding variables in solutions Message-ID: <4676BD23.4090700@lokorin.org> How should the binding of variables to solutions be handled? Currently each variable is independant of space (i.e. the state of the search, the same variable can be used in definition as well as in the solution) until the underlying methods are used such as #val and #assigned?. The problem comes when one wants to inspect a solution: one wants to bind to the solution's space when using the variables through the solution, but still bind the variables to the old space when not accessed through a solution. At the moment each variable is informed of which model it belongs to and then queries that model for a space when it needs to bind to one (delegating methods to the bound variable). We want to be able to do things such as the following: puts model.solution.var.val # Should print the value of the variable in # the solution. puts model.var.val # Should print the value of the variable before any # search has been performed. Some different ways to accomplish that: == Copy The current way that's done is to copy the model and then go through its instance variables, copying any variable and linking the copy to the new copy of model. The limitation of this is that it's not especially general, it will for instance not work when the variables are stored in a hash. We can generalize it to cover every data structure defining map! and Hash (which does not define map!), but it will still not cover custom data structures with variables. == Indirection Somehow making sure that each access to a variable is routed through its model would also work, the question is mostly if that can be done in a clean enough manner. == Block Instead of making a copy we could provide the option of giving a block which is evaluated using the solution space. E.g. as follows: model.solution{ |s| puts s.var.val } The model would provide the solution space to all variables wanting to bind while evaluating the block, then switching back to the old space. Problems include thread safety (but that's probably not a big loss) and the question of whether the method should return the result of the block. If it does then returning variables and then using them might lead to contra-intuitive results. model.solution{ |s| s.var }.val # Fetches the value before the search. == Deep copy We could do a deep copy[1] of the model and then iterate over every instance variables and any enumerables, rebinding every variable we see. == Using the stack Something such as call_stack[2] could possibly be used to figure out which model accessed the variable (and then use that model for requesting the space to bind to). I'm not quite sure on how one would figure that out though. == Destructive solution Fetching the solution could be a destructive operation. E.g. something like the following: model.solve! model.var.val # Should print the value of the variable in the solution. This is a simple and clean solution, the question is whether anyone can come up with a good reason for keeping the old model around. == Links [1] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/43424 [2] http://eigenclass.org/hiki/call_stack -- Andreas Launila From rubyforge at lokorin.org Tue Jun 26 12:21:29 2007 From: rubyforge at lokorin.org (Andreas Launila) Date: Tue, 26 Jun 2007 18:21:29 +0200 Subject: [gecoder-devel] Strange behavior of Gecode::Raw::IntSet Message-ID: <46813D09.6090106@lokorin.org> There are 6 examples that fail in the specs, they are all because of some strange behavior in Gecode::Raw::IntSet. Example: > require 'rubygems' > require 'gecoder' > set = Gecode::Raw::IntSet.new([1,3,5], 3) > set.size 3 <- This is correct > set.min(0) 4 <- This is not correct, 1 is expected. > set.min(1) -1037935314 <- This is not correct, 3 is expected. It works fine through Gecode/J, so it's probably not something in Gecode that's causing the strange behavior. Possibly it's something in the conversion of the arrays through the bindings, but I can't find any other method that uses constant arrays to test with. I'm looking for ideas on how to fix this, if someone knows what component is causing the problem then that information would also be useful. This is not a big problem right now, but it will be when the int set part of the interface is implemented. -- Andreas Launila From rubyforge at lokorin.org Tue Jun 26 16:20:52 2007 From: rubyforge at lokorin.org (Andreas Launila) Date: Tue, 26 Jun 2007 22:20:52 +0200 Subject: [gecoder-devel] Strange behavior of Gecode::Raw::IntSet In-Reply-To: <46813D09.6090106@lokorin.org> References: <46813D09.6090106@lokorin.org> Message-ID: <46817524.2080508@lokorin.org> Andreas Launila wrote: > I'm looking for ideas on how to fix this, if someone knows what > component is causing the problem then that information would also be > useful. This is not a big problem right now, but it will be when the int > set part of the interface is implemented. > A bug-report[1] was filed for this and fixed, thanks David. [1] http://rubyforge.org/tracker/index.php?func=detail&aid=11861&group_id=3553&atid=13720 -- Andreas Launila