[gecode-users] int vs. unsigned int for Matrix dimensions

Gregory Crosswhite gcross at phys.washington.edu
Wed Jan 19 19:54:35 CET 2011


Actually, I just came up with a simpler idea:  rather than creating a 
new iterator class, you could simply use a pointer as the iterator type, 
so that adding a full set of begin()/end() methods is easy:

#include <iterator> // STL iterator classes

template<class Var> VarArray {
protected:
     int n;
     Var* v;
public:
     Var* VarArray::begin() { return v; }
     Var* VarArray::end() { return v+n; }
     const Var* VarArray::begin() const { return v; }
     const Var* VarArray::end() const { return v+n; }

     Var* VarArray::rbegin() { return std::reverse_iterator(end()); }
     Var* VarArray::rend() { return std::reverse_iterator(begin()); }
     const Var* VarArray::rbegin() const { return 
std::reverse_iterator(end()); }
     const Var* VarArray::rend() const { return 
std::reverse_iterator(begin()); }
...
};

(And of course the same can be done for ArgArrayBase.)

Adding these methods should be sufficient to allow library users to 
iterate over your arrays using the standard idioms.

Cheers,
Greg

On 1/17/11 5:47 AM, Christian Schulte wrote:
> Hi,
>
> Yes, this list is a good forum...
>
> Again you caught us red-handed... I know that begin() and end() is the
> standard idiom but some of our iterators do not naturally fit in this
> concept (that iterators that iterate over values and ranges of variables and
> views).
>
> I think what one could do is providing a wrapper class that translates a
> Gecode-style iterator (using a constructor or init function for
> initialization, operator ++() for moving to the next element, and operator
> ()() for testing whether the operator is done). If you can come up with
> something like that we would of course integrate it.
>
> Best
> Christian
>
> --
> Christian Schulte, www.ict.kth.se/~cschulte/
>
>
> -----Original Message-----
> From: Gregory Crosswhite [mailto:gcross at phys.washington.edu]
> Sent: Monday, January 17, 2011 12:36 AM
> To: users at gecode.org; cschulte at kth.se
> Subject: Re: [gecode-users] int vs. unsigned int for Matrix dimensions
>
> Part of the reason I am asking how to talk to the developers,
> by-the-way, is because I was thinking it might be useful for the
> arrays/argument arrays to have an iterator interface added to them, to
> make it easier to do things like applying generics algorithms to them
> and traversing them using the c++0x "for each" statement as well as
> BOOST_FOREACH.  Would there be any interest in a contribution to Gecode
> to provide this?  The supporting code that I had in mind would include
> new classes for the iterators and new methods .begin() and .end() for
> the arrays.
>
> Cheers,
> Greg
>
> On 1/16/11 1:46 PM, Gregory Crosswhite wrote:
>> Okidoke;  thanks for the explanation!  :-)
>>
>> Also, is this list the best way to talk to the developers of Gecode?
>>
>> Thanks,
>> Greg
>>
>> On 1/16/11 1:10 PM, Christian Schulte wrote:
>>> Hi Gregory,
>>>
>>> You are touching a slightly weird aspect of Gecode... The choice of
>>> int as
>>> opposed to unsigned int for the Matrix class is actually deliberate.
>>> This
>>> choice is not only done for Matrix but for many other datastructures
>>> that
>>> are defined by Gecode (for example, VarArray, ViewArray, etc). I know
>>> that
>>> the choice of unsigned int sounds more appealing but we have made the
>>> opposite decision and try to be as consistent with the choice of int
>>> rather
>>> than unsigned int.
>>>
>>> There are two reasons. The first is simple and maybe is not even very
>>> convincing. The average loop written to iterate over arrays etc is
>>> typically
>>> an int and not an unsigned int. To avoid compiler warnings, Gecode
>>> follows
>>> in this. Then, the second reason (possibly not more convincing than the
>>> first one) is that integer variables take int values and very often
>>> array
>>> access is wrt a value included in the domain of an integer variable.
>>> Here we
>>> go.
>>>
>>> We tried to use unsigned int but it was in fact just too painful
>>> (lots of
>>> explicit casts in order to avoid warnings). Changing int to unsigned
>>> int and
>>> be consistent about that change would be a massive effort with little
>>> gain.
>>>
>>> I know. Sad but true.
>>>
>>> Cheers
>>> Christian
>>>
>>> -- 
>>> Christian Schulte, web.ict.kth.se/~cschulte/
>>>
>>>
>>> -----Original Message-----
>>> From: users-bounces at gecode.org [mailto:users-bounces at gecode.org] On
>>> Behalf
>>> Of Gregory Crosswhite
>>> Sent: Friday, January 14, 2011 6:26 PM
>>> To: users at gecode.org
>>> Subject: [gecode-users] int vs. unsigned int for Matrix dimensions
>>>
>>> Hey everyone,
>>>
>>> Is there a reason why the Matrix class uses "int" for the type of its
>>> dimensions instead of "unsigned int"?  If there isn't a reason not to
>>> use "unsigned int" for the type of the dimensions, then may I submit a
>>> patch or something to change it to use "unsigned int"?
>>>
>>> Thanks!
>>> Greg
>>>
>>> _______________________________________________
>>> Gecode users mailing list
>>> users at gecode.org
>>> https://www.gecode.org/mailman/listinfo/gecode-users
>>>
>>
>> _______________________________________________
>> Gecode users mailing list
>> users at gecode.org
>> https://www.gecode.org/mailman/listinfo/gecode-users
>




More information about the users mailing list