Re: [tablix-list] 0.2.0 configuration format

From: Nicholas Robinson <>
Date: Sun Jan 09 2005 - 21:47:36 CET


> | 1. More consideration needs to be given to being able to prove that
> | the input file is a valid description of the requirement. At the
> | moment, we lack the ability to confirm by any programmatic method
> | that we have scheduled the right number of lessons of each subject to
> | each class and not overloaded individual teachers. If your input file
> | doesn't converge, you don't know if it is because you have a mistake
> | in the input or that the algorithm has failed.
> This has been discussed before. As far as I know, proving that a Tablix
> timetabling problem has a solution is equal to finding a solution. It is
> impossible to take into account the effects of interactions of all used
> modules. I would be happy if somebody could show me I'm wrong, but until
> that happens, this feature won't be available in Tablix.

Not really what I meant. If you have a composite timetable for a class that
uses three tablix classes related by 'conflicts-with' then it is quite a task
to check by hand that the total doesn't exceed the number of lessons per
week. Similarly, across the whole timetable, that you haven't allocated a
teacher to teach more lessons than is possible. It might sound trivial, but
my input file is around a 1000 lines of XML. Tablix quite rightly can't
converge to a solution to schedule 43 lessons into a timetable that only has
41 slots available! Knowing that a solution can't possibly exist is not the
same as finding it.

> | As this mailing list has (silently) observed, my timetable can be
> | divided into three bits and each bit will converge successfully with
> | the correct number of lessons. Running it as a whole results in
> | missing lessons and so the algorithm has to be slightly buggy.
> | Relying on the output as a guide to the correctness of the input is
> | therefore invalid.
> If you think something is buggy, please provide a short and simple
> example how to replicate that bug. So far all missing lessons I've seen
> in the examples you've sent are simply because of wrong interpretations
> of the resulting HTML timetable.

I did with the CVS build - reporting that it was building shared libraries but
for me, at least, it was actually building static ones. You didn't respond to
say either that it was fine for you or that I'd spotted a bug.

I've also sent through various input files that haven't got as far as
producing html so I don't see how these can be down to my challenged literacy
skills. For example, I've sent the whole timetable broken down into the three
bits and explained that each one works ok but together I don't get
convergence. Occasionally, I can get html files that will have gaps in and
with the same input file on a subsequent run, it won't have gaps.

In the roadmap you mentioned that extensive use of 'place-capability' results
in hard-to-converge situations, so I've taken out all place-capability and
used preferred-room instead. This seems to reach a minimum much more quickly,
but still not a completely converged solution. So I now don't execute the
'more-rooms' module, but I still get the same outcome. You haven't responded
at any stage either to say that I am right or wrong.

The only way I can learn from my mistakes is if I know they are mistakes!

> | 2. The parser needs to be improved hugely. At the moment, it accepts
> | what it recognises and silently throws away about 80% of what it
> | doesn't. This leads to a false conclusion that the input ins being
> | executed as intended. It is very frustrating when you find that it
> | has been completely ignored.
> There is already a DTD file that you can use to validate a config file.
> XML validation will in most cases find tags and properties that are not
> recognized by Tablix. Future versions of Tablix could automatically
> validate the config file before parsing it, but most of the XML parsers
> I know simply ignore unknown parts of the XML files.
> | 3. Point 2 can be addressed by the implementation of a complete user
> | interface to generate the input file - but gtablix is broken for me
> | (it has been for about six weeks) and wasn't complete the last time I
> | was able to use it. A critical component that is independent and so
> | outwith the control of the core project doesn't seem the best design
> | philosophy.
> My design philosophy is to separate the interface from the engine. This
> is the case with most unix software and I intend to stick to it.

I'm not saying they should be bundled in to one component, I'm saying that if
tablix can only be used effectively with a front-end (which is almost a given
since XML was never intended as a vehicle for humans to build input files)
then a front-end component should be in the scope of the tablix project.
Bostjan is reporting that he isn't getting much feedback on gtablix, but this
seems to be a vital component of the project, to me at least. Given the
interdependencies of the various bits of the input, even an XML editor isn't

> | 5. The code needs an overhaul to improve readability and commenting -
> | and the documentation is sparse. I have only ever supervised work on
> | GAs rather than programming myself, but the difference is I was able
> | to understand the resulting code. Given the virtually non-existent
> | response to mailing list queries, having readable code and fullsome
> | documentation are the only viable alternatives for busy people.
> If you think something is missing from the documentation, feel free to
> add something. At 50 pages of documentation and man pages for all
> executables, Tablix isn't exactly the least documented project I've seen.

I agree that it's by no means the least documented but the project is based on
very complex and difficult underlying algorithms. It may be that simply
having a wider range of example xml files could fill in many of the gaps I
have struggled with.

> Code readability is a problem, but if you would check the 0.2.0 branch,
> you would see this is improving.

Just need a bit more confidence or reassurance that I'm not going down a blind
alley! I'm not being lazy, but I've put in over 100 hours work on tablix and
I really would like to use it for real.

Kind Regards

Nick Robinson

Fight Prejudice - Fight the Ban (see
Received on Sun Jan 09 22:09:04 2005

This archive was generated by hypermail 2.1.8 : Tue Aug 16 2005 - 20:42:54 CEST