I think it would be nice when can assign time constraints to tags.
And with the tags: maybe can use tag on subjects and teachers.
For example the PE, draw and the music activities should be the latter activities (on a day) than mathematics. It would be simplier if I could create a tag "later" and assign it to PE, draw and music subjects and add a time constraint to "later" tag.
Now I have to add these constraints for all activities.
I am not sure I understand completely. Now you have constraints activities preferred times, in which you can use activity tags. Also, the constraints activities end students' day can be specified by an activity tag.
Could you tell me how what constraints do you add now (with the current version of FET) to say that PE, Draw and Music should be later than Mathematics?
Quote from: Liviu Lalescu on July 24, 2017, 02:13:39 PM
Could you tell me how what constraints do you add now (with the current version of FET) to say that PE, Draw and Music should be later than Mathematics?
Maybe my explanation wasn't perfect.
So I don't prefer the following timetable:
| Mon | Tue | Wed | Thu | Fri |
| 1. | PE | Draw | ... | Music | ... |
| 2. | Music | PE | Draw | | PE |
| ... |
| 6. | Math | Literature | English | Phys | German |
| 7. | Phys | Math | Math | English | Math |
Please note a lot of PE, Draw, Music are at the early of the days and the "difficult" subjects are at one of the last hours of day.
So it would be better inversly. It isn't important that first Math and after Math will the PE. The important thing is as many Math (and Phys, Literature, ...) as possible will be placed at early (or middle but not the end) of the days. And its result is that the PE, Draw, Music (and similar "easy" subjects) should be placed at the near of the end of the days.
Volker can explain better.
You don't need new constraints. The correct constraints to use are subactivities preferred times. Note, SUBactivities, not activities. Add for the first component of Math activity a required time, in the first hours of the days. Then, if the timetable is still solvable, add for the second component of the Math, etc. You only add for each subject and number of component, not for each activity. And you may want to add for the "easy" subjects, late in the day. As you prefer.
Edit: you can see an example in the file Germany/secondary-school-1/using_subactivities_constraints.fet
Yes, I know about this practice - I do it similar. But I think it's a lot of work and the quantity of this work would decrease with subject's tag.
But do you think my idea would be not so good to solve my problem?
Quote from: Zsolt Udvari on July 24, 2017, 04:27:22 PM
Yes, I know about this practice - I do it similar. But I think it's a lot of work and the quantity of this work would decrease with subject's tag.
You could add a tag "easy" or "hard" to each activity. But you would like to add a tag to each subject, instead (less work). I'll add this in the TODO. But it is a complication of the simple set of FET data.
Quote
But do you think my idea would be not so good to solve my problem?
What idea, with tags for subject? I'll add it in the TODO, but I don't like it too much, as I wrote above.
Quote from: Liviu Lalescu on July 24, 2017, 04:44:06 PM
You could add a tag "easy" or "hard" to each activity. But you would like to add a tag to each subject, instead (less work). I'll add this in the TODO. But it is a complication of the simple set of FET data.
I can use tag to each activity, of course. If it's complicated and only a little bit useful don't do it.
Quote from: Liviu Lalescu on July 24, 2017, 04:44:06 PM
Quote
But do you think my idea would be not so good to solve my problem?
What idea, with tags for subject? I'll add it in the TODO, but I don't like it too much, as I wrote above.
Yes, tags for subject. But if you think the more work is better because of timetable generate I accept - you're the programmer of FET and you can see the problems (about programming and generate). I don't want a feature that causes an impossible case ;)
It isn't much work.
I do it only with main subjects, so there are only a few "early" constraints.
Your suggestion will with subject "music" and tag "late" will be impossible for most schools, because a few "music" lessons must be also early (because the rooms is always full late and/or the teacher is already always working late.)
So i do it only with some "early" activities. the others will be automatically late if the others are early.
Quote from: Zsolt Udvari on July 24, 2017, 05:10:52 PM
Yes, tags for subject. But if you think the more work is better because of timetable generate I accept - you're the programmer of FET and you can see the problems (about programming and generate). I don't want a feature that causes an impossible case ;)
The only complication is that the user now has, next to activity tags, also subject tags. This is a bit complicated to manage and I prefer to keep things as simple as possible.
The generation algorithm would stay the same.
I added in the TODO:
327---------------------------------------------------------
From Zsolt Udvari (on forum):
Add a subject tag for each subject (like: "easy" or "hard") and add time constraints for these subject tags.
Also tagging some subjects as "early" will be impossible for guys that teach main subjects only. (since they can't teach only early, except they are half time teachers)
Quote from: Volker Dirr on July 24, 2017, 05:34:06 PM
So i do it only with some "early" activities. the others will be automatically late if the others are early.
Yes I thought about it and the constraint's weight don't will be 100%.
in my opinion weight with less than 100% should be disallowed at all.
it is a nice feature if the timetable is easy, because it is working well than and you don't need to understand much to use that.
but if you have got difficult timetables with weight less than 100% is much to much waste of time. You don't understand your dataset perfect and add to many bugs by that and must wait much longer for a solution; but waiting longer for a solution if your dataset is already difficult doesn't help much.
Quote from: Volker Dirr on July 24, 2017, 05:55:40 PM
in my opinion weight with less than 100% should be disallowed at all.
it is a nice feature if the timetable is easy, because it is working well than and you don't need to understand much to use that.
but if you have got difficult timetables with weight less than 100% is much to much waste of time. You don't understand your dataset perfect and add to many bugs by that and must wait much longer for a solution; but waiting longer for a solution if your dataset is already difficult doesn't help much.
Hm. So do you say should I add 100% weighted time constraints to some (not all!) subactivities? I think maybe you've right because FET can try impossible (not 100% weighted) constraints many times (depends on weight) and maybe for each subactivities! And user doesn't know why takes too long...
I'll try your suggestion.
of course if your dataset is still to difficult, you can lower that 100% values also. The "needed" stuff is that you didn't waste time anymore by trying something impossible if you use/check 100% weight constraints only.
Hi!
It's again time for generating new schedules at our university, so I'm active again with FET. And by entering my schedule data I thought that it would be pretty nifty I FET would allow adding time constraints to tags. This is why I found this thread here.
My scenario is the following:
Each semester we're asking our student's council for wishes on new schedules. And one of the major wishes each semester is that first term lectures shall be placed in the morning, third term lectures may also take place on noon, etc. Hence, they would like to see specific kind of activities to be scheduled to specific times of the day.
At the moment I'm realizing these wishes by specifying a time constraint to each of my activities, which is quite time consuming. Especially when it comes to modifying constraints: for instance, if I decide to schedule first term lectures also to noon time, I have to modify all constraints of all affected activities.
It would be beautiful if FET would support the following workflow:
a) in "Data -> Tags" I create all the tags that I need (e.g. "lecture 1st", "lecture 3rd", ...)
b) in "Data -> Activities" I then add tags to my activities (e.g. adding "lecture 1st" tag to "Database 1" activity)
c) in "Time -> Tags -> A tag has a set of preferred time slots" I finally specify time slots for my tag (e.g. "lecture 1st" may only be scheduled to first and second block from Monday to Friday)
a) and b) is already existing in FET, so I'm "just" suggesting c).
At schedule generation time, FET would simply have to check which time constraints have been specified for the assigned tags, combining them with time constraints that have been specified for the activity itself. This shouldn't be too complicated, because tag constraints could just be "copied" from the tags to the set of activity constraints, perhaps merging them.
For example:
1) There is a time constraint on the TAG as specified above (only first and second block is allowed)
2) There is a time constraint on the ACTIVITY (Time -> Activities -> An activity has a set of preferred time slots), specifying that the activity must NOT be scheduled to the first block.
FET would have to consider both constraints at schedule generation time, so that the activity could only be planned to the second block on some day.
I'm aware that you did not react enthusiasticly on Zslot's suggestion, but I hope that it was because of his idea to also tag subjects. I'm only aiming at tags for activities. Time constraints on such tags would really make my life much easier.
Hello, math!
I don't understand. (c) exists, it is Activities preferred time slots/starting times, or Subactivities preferred time slots/starting times - specify only the activity tag. This is also what I wrote to Zsolt - it is best to keep the number of constraints to the minimum necessary.
I think Zsolt suggested to add for each subject a tag, if it is easy or hard for instance. But I prefer not to complicate things - it would be a bit more work to add an activity tag to each activity instead of to a subject, but the data is easier to follow in my opinion.
Hi Liviu!
Assume the following scenario:
- I have 20 lectures for 1st term students
- I want to specify ONE single constraint for all these lectures (saying that such actities can only be scheduled to first and second block from Monday to Friday)
- If it is impossible to generate a schedule with that constraint, I want to modify ONE SINGLE constraint (e.g. allowing also the third block to be used)
At the moment I have to add a time constraint for all my activities. This means:
- I have to add 20 time constraints (for my 20 first term lectures)
- If necessary, I have to modify all these 20 time constraints
From the technical perspective, I fully agree with you: it is possible to get first term lectures scheduled in the way I want. But it takes quite some effort to add/modify all these 20 constraints. And it's not only just these 20 constraints. We also have constraints for 1st term exercises, 2nd term lectures, 2nd term exercises, seminars, etc.
So instead of managing constraints for a handful of tags, I have to deal with hundreds of activities.
And besides the time aspect, this way of constraint management is also quite error prone. It happens quite easy to miss constraints when modifying them or changing them in the wrong way.
Hence, I really would appreciate time constraints on tags.
Yes, of course, this is what I am talking about. Just add an activity tag to these 20 activities, and a constraint activities preferred time slots, specifying only this activity tag and the allowed times. I don't understand the problem. Please see this constraint: Activities preferred time slots (not activity, but activities, plural).
Please let me know.
Hi Liviu!
INCREDIBLE! This seems to be EXACTLY what I was looking for. Sorry, I did not recognize the plural (activities) in your answers, so I was checking the wrong constraint. Thanks a LOT. It's really fascinating to still find new functionality even though I'm using FET for quite some time. I guess "FET" is the abbreviation for "FEature beasT". ;)
I am glad it works :)