From rubyforge at lokorin.org  Wed Aug  6 15:36:55 2008
From: rubyforge at lokorin.org (Andreas Launila)
Date: Wed, 06 Aug 2008 21:36:55 +0200
Subject: [gecoder-devel] Sugar for "composite" constraints -
 a.k.a.	"extended sugar"
In-Reply-To: <488ECB50.2030304@lokorin.org>
References: <488ECB50.2030304@lokorin.org>
Message-ID: <4899FD57.7090302@lokorin.org>

Andreas Launila wrote:
> 
> With such a separation only the "non-composite" constraints would
> actually be called constraints. The goal would be to make the user think of
> 
>   set.min.must == 17
> 
> as selecting the minimum of the set and then placing a relation
> constraint on that minimum (rather than directly placing a constraint
> that constrains the minimum of a set).
> 

I'm in the process of rewriting the code (in /branches/composite_sugar)
to reflect this distinction. It's more or less a rewrite of the
underpinnings and changes the terminology used in the code. There are no
longer such things as expressions, stubs and composite constraints.
Everything to do with constraints is now divided into:

* Operands
* Operand properties
* Constraint receivers
* Constraints

"Operands" is used to denote anything that can be turned into a
variable. For instance all the following are int variable operands,
meaning that they all define a #to_int_var method that return an int
variable:
* int_var
* int_var1 + int_var2
* (int_enum[int_var1] + int_var2) * int_var3

There are several types of operands: IntVarOperand, BoolVarOperand,
SetVarOperand, IntVarEnumOperand, BoolVarEnumOperand, SetVarEnumOperand,
SelectedSetEnumOperand, SetElementsOperand, FixnumEnumOperand. The last
three are special cases that are only needed by one or two constraints each.

Most of the operand types have operand properties (methods) that each
return a new operand (not necessarily of the same type).
IntVarOperand#+ is one such property. It takes one integer operand and
returns a new integer operand.

All places that previously accepted a variable of a specific type will
now accept an operand of the same type. All constraint statements are
now written as

  <operand>.<must|must_not>.<constraint_method>([parameters,] options)

e.g.

  (int_var1 + int_var2).must_be.in([1,3,5], :reify => bool1 | bool2)

The only change that is not backwards-compatible from the user's point
of view is the distinct constraint with offsets. The offsets will be
made an optional parameter (i.e. "int_enum.must_be.distinct(:offsets =>
[1,2])" rather than "int_enum.with_offsets([1,2]).must_be.distinct").

All operands define #must and its variants. Calling that method returns
a constraint receiver of the appropriate type. For instance, calling
#must on an int var oprand returns an int var constraint receiver which
defines methods for all constraints that can be placed on an integer
variable. Calling a constraint receiver's method returns an instance of
Constraint (which is unchanged).

This is roughly how things map from the previous design to the new one:
* Operands subsume the role of variables. Code should check whether an
object defines e.g. #to_int_var rather than checking whether it is an
integer variable.
* Constraints that previously did not use stubs or composites are now
defined in the appropriate constraint receiver.
* Constraints that did use stubs are now operand properties defined in
the appropriate operand.
* Composite constraints are now operand properties that, if they have
#must called, return custom constraint receivers that short circuit
equality constraints if possible (to avoid needless constraints).
* The custom hacks used to accomplish things such as linear constraints
are now operands and operand properties.

Hopefully I haven't overextended myself in terms of the amount of
rewriting needed.

-- 
Andreas Launila


From rubyforge at lokorin.org  Tue Aug 12 08:53:33 2008
From: rubyforge at lokorin.org (Andreas Launila)
Date: Tue, 12 Aug 2008 14:53:33 +0200
Subject: [gecoder-devel] Sugar for "composite" constraints -
 a.k.a.	"extended sugar"
In-Reply-To: <4899FD57.7090302@lokorin.org>
References: <488ECB50.2030304@lokorin.org> <4899FD57.7090302@lokorin.org>
Message-ID: <48A187CD.3010101@lokorin.org>

Andreas Launila wrote:
> Andreas Launila wrote:
>> With such a separation only the "non-composite" constraints would
>> actually be called constraints. The goal would be to make the user think of
>>
>>   set.min.must == 17
>>
>> as selecting the minimum of the set and then placing a relation
>> constraint on that minimum (rather than directly placing a constraint
>> that constrains the minimum of a set).
>>
> 
> I'm in the process of rewriting the code (in /branches/composite_sugar)
> to reflect this distinction. It's more or less a rewrite of the
> underpinnings and changes the terminology used in the code. [...]
>
> Hopefully I haven't overextended myself in terms of the amount of
> rewriting needed.
> 

Let's see how things are progressing. The following are the old
constraints broken down as in the quick reference[1] (x means that the
constraint has been rewritten).


== Int

[x] relation
[x] linear
[x] domain
[ ] abs
[ ] mult
[ ] square
[ ] square_root


== Int enum

[ ] min
[ ] max
[ ] channel with int enum
[ ] count
[x] distinct
[x] element
[ ] sort
[ ] sort with options
[ ] tuple
[ ] regexp


== Bool

[x] domain
[x] equality
[x] implication
[ ] channel with int


== Bool enum

[ ] conjunction
[ ] disjunction
[ ] tuple
[ ] channel with int
[ ] regexp


== Set

[ ] cardinality
[ ] min
[ ] max
[ ] sum
[ ] include
[x] domain
[x] operation
[x] relation
[ ] elements
[ ] channel with bool enum


== Set enum

[ ] channel with int enum
[x] at most once
[x] operation
[ ] select
[ ] select union
[ ] select intersection
[ ] select disjoint


== Fixnum enum

[x] elements
[x] operation


I have tried to take one of every major type and get the least straight
forward ones (linear, operation, ...) done first. As a result most of
the underlying code should now have been rewritten. From here on out it
should mostly be quantitative work that should be automated as much as
possible.

The constraints to go, broken down by how they need to be reimplemented,
are:

= Properties

== Short circuit int equality

=== Int
[ ] abs
[ ] mult
[ ] square
[ ] square_root

=== Int enum
[ ] min
[ ] max

=== Set
[ ] cardinality
[ ] min
[ ] max
[ ] sum


== Short circuit int relations

[ ] count
[ ] elements


== Short circuit bool equality

[ ] conjunction
[ ] disjunction


== Short circuit set equality

[ ] select
[ ] select union
[ ] select intersection



= Constraints

== Int enum constraints

[ ] channel with int enum
[ ] sort
[ ] sort with options
[ ] tuple
[ ] regexp


== Bool constraints

[ ] channel with int (+ commutativity)


== Bool enum constraints

[ ] tuple
[ ] channel with int (+ commutativity)
[ ] regexp


== Set constraints

[ ] include
[ ] channel with bool enum (+ commutativity)


== Set enum constraints

[ ] channel with int enum (+ commutativity)


== Selected set constraints

[ ] select disjoint



[1]
http://gecoder.rubyforge.org/documentation/constraints/quick-reference.html

-- 
Andreas Launila

From rubyforge at lokorin.org  Thu Aug 14 15:21:14 2008
From: rubyforge at lokorin.org (Andreas Launila)
Date: Thu, 14 Aug 2008 21:21:14 +0200
Subject: [gecoder-devel] Sugar for "composite" constraints -
 a.k.a.	"extended sugar"
In-Reply-To: <4899FD57.7090302@lokorin.org>
References: <488ECB50.2030304@lokorin.org> <4899FD57.7090302@lokorin.org>
Message-ID: <48A485AA.3030204@lokorin.org>

Andreas Launila wrote:
> Andreas Launila wrote:
>> With such a separation only the "non-composite" constraints would
>> actually be called constraints. The goal would be to make the user think of
>>
>>   set.min.must == 17
>>
>> as selecting the minimum of the set and then placing a relation
>> constraint on that minimum (rather than directly placing a constraint
>> that constrains the minimum of a set).
>>
> 
> I'm in the process of rewriting the code (in /branches/composite_sugar)
> to reflect this distinction. It's more or less a rewrite of the
> underpinnings and changes the terminology used in the code.
> 

The rewrite is complete to the point that all code has been rewritten
and all specs pass. Things left to do:

* Get C0 coverage back to 100% (currently at 96%)
* Move around code to reflect the separation of constraints and
properties. I haven't entirely decided on how to reorganise the files,
but I'm currently leaning towards adding a "properties" directory in
/lib/interface and then split it up based on operand (as in the
"constraints" directory).
* Rewrite the documentation to reflect the changes.

During the rewrite I have reorganised the code documentation so that it
is located at the corresponding method (the method that produces the new
operand or places the constraint) rather than at the constraint's class.
This should make it easier to get a good overview from RDoc (since the
user's view will only have a few important modules).

The current constraint documentation on the website will be imported
into the code documentation where suitable. The website documentation
will then be generated from the code documentation. The site will
present the documentation by splitting it up per operand. Each operand's
documentation will begin with a general introduction to the operand
(e.g. int operands) and then list the operand's constraints and
properties. I'm not sure whether that should be split up over several
pages or kept on the same page.

-- 
Andreas Launila

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-devel] [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  Wed Aug 27 14:20:51 2008
From: rubyforge at lokorin.org (Andreas Launila)
Date: Wed, 27 Aug 2008 20:20:51 +0200
Subject: [gecoder-devel] Simplifying the installation
In-Reply-To: <63b5c8b00804110436k53988b8u46332a37e519b39e@mail.gmail.com>
References: <477EB20B.6080502@lokorin.org>
	<479881FC.5040207@lokorin.org>	<47FF4545.8080609@lokorin.org>
	<63b5c8b00804110436k53988b8u46332a37e519b39e@mail.gmail.com>
Message-ID: <48B59B03.7010902@lokorin.org>

Mikael Zayenz Lagerkvist wrote:
> On Fri, Apr 11, 2008 at 1:02 PM, Andreas Launila <rubyforge at lokorin.org> wrote:
>> Andreas Launila wrote:
> 
>>  You should also change
>>
>>   ifeq "no" "yes"
>>   DLLTARGETS= \
>>
>>  in the Makefile to
>>
>>   ifeq "yes" "yes"
>>   DLLTARGETS= \
>>
>>  to build the DLLs. There's probably some easier configuration flag to do
>>  that, but I haven't found it.
> 
> This is controlled by the --enable-shared switch that configure uses.
> 

I tried using the flag when configuring 2.2.0 but it did not work. It
seems as if the following part of configure overrides it.

  if test "${host_os}" = "windows" -a \
      "${ac_gecode_compiler_vendor}" = "gnu"; then
    enable_static="yes"
    enable_shared="no"
  fi

Configure command used:

  ./configure \
    --with-host-os=Windows \
    --host=i386-mingw32 \
    --build=i686-linux \
    --disable-examples \
    --enable-shared \
    CXX="i386-mingw32-gcc"


-- 
Andreas Launila

From rubyforge at lokorin.org  Wed Aug 27 16:24:51 2008
From: rubyforge at lokorin.org (Andreas Launila)
Date: Wed, 27 Aug 2008 22:24:51 +0200
Subject: [gecoder-devel] Simplifying the installation
In-Reply-To: <479881FC.5040207@lokorin.org>
References: <477EB20B.6080502@lokorin.org> <479881FC.5040207@lokorin.org>
Message-ID: <48B5B813.2050403@lokorin.org>

Andreas Launila wrote:
> == Cross-compile Gecode
> 
> This step produces the Gecode DLLs and include files. Those files are
> already included in SVN, so this part should not be needed.
> 
> Download and unpack the Gecode tarball[7] (Gecode/R is currently using
> version 1.3.1). Use the following configuration (possibly with some
> appropriate prefix).
> 
>   ./configure \
>     --with-host-os=Windows \
>     --host=i386-mingw32 \
>     --build=i686-linux \
>     --disable-examples
> 

As of Gecode 2.2.0 you also have to throw in CXX="i386-mingw32-g++". The
complete configuration command is hence

  ./configure \
    --with-host-os=Windows \
    --host=i386-mingw32 \
    --build=i686-linux \
    --disable-examples \
    CXX="i386-mingw32-g++"

-- 
Andreas Launila