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 set.min(0)
4 set.min(1)
-1037935314
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