ConstraintActivityTagPreferredTimes

Started by aliponte, February 22, 2010, 04:41:30 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

aliponte

Recently I made a plan for my school. Activity tags proved to be very useful. I would like to use them not only for assigning rooms to certain activities, but for assigning preferred times and time slots as well.

Wouldn't it be a good idea to create such constraints which would be analogue to room constraints:

ConstraintActivityTagPreferredTime
ConstraintActivityTagPreferredTimes
ConstraintActivityTagPreferredTimeSlots ?

aliponte

Liviu Lalescu

They are already available as:

ConstraintActivitiesPreferredStartingTimes
and
ConstraintActivitiesPreferredTimeSlots
(specify only the activity tag).

aliponte

I know both "ConstraintActivtity..." and "ConstraintActivities..." and I used them already at a great extend. But the constraints i suggest are important on their own. That's why I suggest to add them to all the other constraints already available.

Let me explain why I feel "ConstraintActivityTagPreferredTime" is in many situations not only more convenient but also a rich extension of FET.

If I want to assign a time constraint to a single activity I don't need the new ones. No doubt about that. Please think of say 300 activities with all the same need to constrain to a specific set of starting times or time slots.

Advantage 1:
It would be a simple matter to assign a tag "ABC" to all of them. You need not open one of the dialogs to define a time constraint, AND you need not do it 300 times! You just need to doubleclick on Activity tag = "ABC" when you create the activity. And then I only had to define what "ABC" means in a single step. (That's the way I do it with room constraints. These are really a great help!)

Advantage 2:
Imagine you want to change a time constraint for all these 300 activities. (For instance I want them to be in periods 1..3 instead of periods 1..4.) It would be more then boring to open 300 times a dialog. If there were a "ConstraintActivityTagPreferredTime" I only had to change this constraint one time. (OK, if you have a good text editor and know how to use it you can edit the xml file and do some "search and replace". But this is not what everybody likes.)

aliponte

Liviu Lalescu

#3
I think you are mistaking here. ConstraintActivitiesPreferredStartingTimes (or TimeSlots) are for more activities. You can specify the activity tag and add only one constraint, not 300. They are exactly what you need.

Take care, it is "Activities", plural, not singular.

More precise, in the interface it is "A set of activities has a set of preferred starting times (time slots)".

aliponte

#4
I see. You are absolutely right. I must have overlooked that. Sorry.

But what do you think of that construct


<ConstraintActivitiesPreferredRooms>
     <Weight_Percentage>100</Weight_Percentage>
     <Teacher_Name>AAA</Teacher_Name>
     <Students_Name></Students_Name>
     <Subject_Name></Subject_Name>
     <Activity_Tag_Name></Activity_Tag_Name>
     <Number_of_Preferred_Rooms>2</Number_of_Preferred_Rooms>
     <Preferred_Room>R1</Preferred_Room>
     <Preferred_Room>R2</Preferred_Room>
</ConstraintActivitiesPreferredRooms>

With this constraint implemented, you don't need the following 3 any more, do you? They are special cases of the above. (I know, you cannot throw them away: compatibility with older versions should be guaranteed.) Forgive me, I am mathematician and I like symmetry.


<ConstraintSubjectPreferredRooms>
     <Weight_Percentage>100</Weight_Percentage>
     <Subject>A</Subject>
     <Number_of_Preferred_Rooms>2</Number_of_Preferred_Rooms>
     <Preferred_Room>w1000</Preferred_Room>
     <Preferred_Room>w1001</Preferred_Room>
</ConstraintSubjectPreferredRooms>

<ConstraintActivityTagPreferredRooms>
     <Weight_Percentage>100</Weight_Percentage>
     <Activity_Tag>AK1</Activity_Tag>
     <Number_of_Preferred_Rooms>2</Number_of_Preferred_Rooms>
     <Preferred_Room>w1001</Preferred_Room>
     <Preferred_Room>w1002</Preferred_Room>
</ConstraintActivityTagPreferredRooms>

<ConstraintSubjectActivityTagPreferredRooms>
     <Weight_Percentage>100</Weight_Percentage>
     <Subject>A</Subject>
     <Activity_Tag>AK1</Activity_Tag>
     <Number_of_Preferred_Rooms>2</Number_of_Preferred_Rooms>
     <Preferred_Room>w1001</Preferred_Room>
     <Preferred_Room>w1002</Preferred_Room>
</ConstraintSubjectActivityTagPreferredRooms>

Volker told me, the conditions in bold letters are logical AND connected. Therefore my suggestion is a substitute even for the last constraint.

Liviu Lalescu

QuoteI see. You are absolutely right. I must have overlooked that. Sorry.

But what do you think of that construct


<ConstraintActivitiesPreferredRooms>
     <Weight_Percentage>100</Weight_Percentage>
     <Teacher_Name>AAA</Teacher_Name>
     <Students_Name></Students_Name>
     <Subject_Name></Subject_Name>
     <Activity_Tag_Name></Activity_Tag_Name>
     <Number_of_Preferred_Rooms>2</Number_of_Preferred_Rooms>
     <Preferred_Room>R1</Preferred_Room>
     <Preferred_Room>R2</Preferred_Room>
</ConstraintActivitiesPreferredRooms>


Every aspect in FET is thought and taken care of very thoroughly. I thought about constraint activities preferred rooms a long time ago and it is not possible. I don't remember the exact reasons. I remember that I thought about it, saw that it is impossible/not practical, and then somebody again suggested it, and again I thought about it and came to the conclusion again that it is impossible/not practical.

I think that the problem is with activities with more teachers or students sets.

I'll search my e-mail archive for the exact reasoning a time ago.

Liviu Lalescu

I found 2 old e-mails from summer 2007 (at that time, activity tags were named subject tags). I am writing a part of one of them:

---------
I would like to add ConstraintActivitiesPreferredRoom(s), so you can specify multiple activities like in ActivitiesPreferredTimes (with teacher, subject, subject tag and students set), but I have some reasons not to like that:

Suppose a user adds a home room H and preferred room(s) for all activities with students X to room H. And then he has a preferred room(s) for all activities with subject S to room R. If students X have activity A with subject S, then the user obtains an impossible timetable, because A cannot take place in any room (preferred room is H intersected with R). The correct way would be to set preferred rooms for students X with both rooms H and R and preferred room for subject S to room R.

But I fear most users would obtain impossible timetables by not knowing the exact procedure.
---------

aliponte

#7
Thank you for your answer.

Two thaughts come into my mind.
1) If it's just care about schedulers who are not quite familiar with FET, why not lock this constraint like it is done with "Max hours daily with an activity tag for a teacher"?

2) I stumbled across this topic when i opened the dialog "Activity Tags". There are two list views in this dialog. The right one shows properties of the chosen tag. The line "Time constraints directly related to this activity tag:" is always empty. That is why I asked for a symmetry of time and room for an activity tag. In my opinion the property list is a great help to keep track of all constraints an activity tag implies. That is the main reason why I'd suggest to add ConstraintActivityTagPreferredTimes.

Liviu Lalescu

QuoteThank you for your answer.

Two thaughts come into my mind.
1) If it's just care about schedulers who are not quite familiar with FET, why not lock this constraint like it is done with "Max hours daily with an activity tag for a teacher"?

2) I stumbled across this topic when i opened the dialog "Activity Tags". There are two list views in this dialog. The right one shows properties of the chosen tag. The line "Time constraints directly related to this activity tag:" is always empty. That is why I asked for a symmetry of time and room for an activity tag. In my opinion the property list is a great help to keep track of all constraints an activity tag implies. That is the main reason why I'd suggest to add ConstraintActivityTagPreferredTimes.

For 1), I think it is better to keep locked features to a minimum.

For 2), I really prefer to keep constraints to a minimum. There is a possibility to add that ConstraintActivityPreferredStartingTimes (or TimeSlots) is related to an activity tag, but this is not always true, because the constraint may also include a teacher, a students set or a subject.