Re: [tablix-list] Option "recursive-conflicts" in module "sametime.so"

From: S <tomaz.solc_at_tablix.org>
Date: Sun, 07 Oct 2007 13:02:02 +0100

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi

> first of all, I apologise for my English...

No need to apologize :)

> I'm trying to apply Tablix 0.3.5 to a Nurse rostering problem.
> For this reason I'm modifying the module "sametime.so" since I need a
> more generic behaviour concerning resource types that have to be checked
> (not necessarily "class" and "teacher" at the same time); I have
> introduced a module option to specify which resource types must be used,
> but keeping as defaults the previous "class" and "teacher".
> Perhaps, I will introduce also the chance to choice the name of the
> resource type "room"; in this way I think the module could be loaded
> more times, each one with different targets and constraints.
> I hope that my work could be of some interest.

I'm sure others will find your modifications useful. For example there
is the "simplesametime" module that is basically "sametime" modified to
have different restype names. With your version of "sametime" it
wouldn't be necessary to create a new module if you just want to use
different names for resource types.

You can send me a patch and I'll include it in the next release.

> Anyway, studying "sametime.c", in the handler "getconflict()" I've
> notice the code that treats the "recursive-conflicts" option:

> I feel that it should be different:
>
> res_set_conflict(res1, res2);
> res_set_conflict(res2, res1);
> if(recursive) {
> for(n=0;n<restype->resnum;n++) {
> if(res_get_conflict(restype, n, res1->resid)) {
> res_set_conflict(&restype->res[n], res2);
> res_set_conflict(res2, &restype->res[n]);
> }
> }
> }
>
> I think the two calls to "res_set_conflict()" must be executed also in
> case of recursive conflicts enabled, or just the conflict requested by
> the user will be skipped since the following "res_get_conflict()" loop
> won't find it.

Hm. I've never used the "recursive-conflicts" option myself, but your
reasoning seems correct to me. I'm sure two res_set_conflict() calls
must be executed in both cases.

However, I don't think it is necessary for them to be in front of the
loop. In that case the two res_set_conflict() calls in the loop will
just be called once with the same arguments as those two outside the
loop (when n=res2->resid). The purpose of the loop is to find all
resources that already conflict with res1 (aside from res2). So I think
this code would have the same result:

if(recursive) {
        for(n=0;n<restype->resnum;n++) {
                if(res_get_conflict(restype, n, res1->resid)) {
                        res_set_conflict(&restype->res[n], res2);
                        res_set_conflict(res2, &restype->res[n]);
                }
        }
}
res_set_conflict(res1, res2);
res_set_conflict(res2, res1);

Best regards
Tomaz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHCMq5sAlAlRhL9q8RAu/wAJ48kMjCN6NrweI3Y/xdRcVCxlYVmwCePwFF
OqGCSQPVvhi04VOibXRNa4E=
=wjUR
-----END PGP SIGNATURE-----
Received on Sun Oct 07 2007 - 14:02:06 CEST

This archive was generated by hypermail 2.2.0 : Mon Oct 08 2007 - 06:30:20 CEST