Re: [tablix-list] Unexpected sametime behavior

From: Tomaz Solc <tomaz.solcREMOVE@THIStablix.org>
Date: Thu Sep 21 2006 - 09:42:42 CEST

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

Hi

> Obviously there is a feasible solution where Alice teaches one class in
> Room 1 and Bob teaches the other in Room 2, however when I run tablix
> the sametime module failes to precalculate with the following error:
>
> [xmlsup] Too many events for teacher 'Alice'
> [xmlsup] 2 events with only 1 available time slots
> [xmlsup] fatal: One or more modules failed to precalculate
>
> What seems to be happening is that the algorithm first assigns Alice to
> every event and this causes the entire execution to fail, rather than
> that permutation simply being considered infeasible. If I were to
> comment out that fatal error it seems the fitness function in sametime
> would throw out that case, but perhaps I am missing something more simple.

The problem is that the precalculate function uses the "dat_tuplemap"
structure to check the assignments of teachers to events. This structure
however only holds data about assignments of constant resources (for
variable resources, the resource id stored there is negative). This is
different from the fitness function, which checks the chromosomes.

The precalculate function in "sametime.so" does not check if resource
types "teacher" and/or "class" are variable. In that case the checks in
the "precalculate" function don't serve any purpose and should be
skipped. I'm surprised that it doesn't crash since it uses a negative
index for an array.

> So, do I need to alter sametime.c if I am using teachers as a variable
> resource?

You can safely comment out this check. I'll also add a fixed version of
"sametime.so" module to the CVS.

Best regards
Tomaz Solc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFEkJysAlAlRhL9q8RAiTMAJ9W5b9BN/TNdXk166e7Zntbed8iTwCfSpEq
UPbZyvwfa9ZUqG0ohwTW1MY=
=fy5x
-----END PGP SIGNATURE-----
Received on Thu Sep 21 09:42:45 2006

This archive was generated by hypermail 2.1.8 : Fri Sep 22 2006 - 06:28:50 CEST