Re: [tablix-list] Tablix 0.2.1 development release

From: Tomaz Solc <tomaz.solcREMOVE@THISsiol.net>
Date: Mon May 09 2005 - 19:54:11 CEST

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

Hi

> Presumably, we will have to give the first event a unique name so that it can
> be referred to in the restriction within the second event? I think we have
> lost the ability to use year/class that we used to use with 'same-time-as'
> restrictions?

Why we lost that ability? You can still reference a class. Its name is
now a string instead of a string an a number, but the functionality is
the same.

> If so, would it be better to have a separate attribute for
> events (maybe called ID) to allow the NAME attribute to continue to be used
> for display purposes without having to clean up the generated timetable? In
> my timetable, this will mean that I end up with 12 for each subject that I
> will then need to replace in the generated htmlcss output.

In the 0.1.x branch you also couldn't reference individual tuples in a
restriction unless you defined a tuple restriction. I don't see any
difference here.

> Is it going to be possible to define an event that doesn't require a teacher?
> If the requirement is to have one class, one teacher but two rooms then the
> second event needed to create the extra room is really teacher-less. At the
> moment this generates an error from the parser about missing constant
> resource type 'teacher'. I suppose we could have phantom teachers but this
> again adds to the post-processing burden.

Have a look at the Tablix timetabling model description I've put on the
home page a while ago. It describes in a formal way what kind of
problems current Tablix kernel can solve. What is written there won't
change anymore in the 0.2.x branch.

An event has one teacher, one class, one room and one time slot (one
resource per resource type). This is how the current genetic algorithm
works. Even in the current form the kernel is almost too complicated for
me to keep in my mind at once how all parts affect each other. Adding
the kind of flexibility you talk about would again hugely complicate things.

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

iD8DBQFCf6PDsAlAlRhL9q8RAtc8AKDBQ/Evl052KuJrhhlSxi/aUEs7MQCcDBWF
d5KfNd6ODYtvbz6/TnOvE7U=
=sn6P
-----END PGP SIGNATURE-----
Received on Mon May 09 19:46:45 2005

This archive was generated by hypermail 2.1.8 : Tue Aug 16 2005 - 20:43:31 CEST