Re: [tablix-list] Tablix 0.2.1 development release

From: Nicholas Robinson <>
Date: Wed May 11 2005 - 22:12:10 CEST


On Monday 09 May 2005 18:54, Tomaz Solc wrote:
> 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.

OK, but doing it this way will still massively increase the number of 'false'
classes or events that have to be massaged after the timetable is generated.

> > 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.

Oooh er, reading a manual is bad enough (so I am told), but formal
descriptions? You ask too much!

> 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.

Understood, in fact giving it more thought most of my 'more-rooms'
requirements can be re-written to include 'more-teachers' without difficulty
- but the complexity of 'same-time-as' means a lot more post processing to
make the timetables readable/usable.
> Best regards
> Tomaz Solc
> Version: GnuPG v1.4.0 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird -
> iD8DBQFCf6PDsAlAlRhL9q8RAtc8AKDBQ/Evl052KuJrhhlSxi/aUEs7MQCcDBWF
> d5KfNd6ODYtvbz6/TnOvE7U=
> =sn6P

Fight Prejudice - Fight the Ban (see
Received on Wed May 11 22:07:48 2005

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