min hours per day, max hours per day

Started by nouvakis, October 18, 2013, 09:39:47 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

nouvakis

I use these constraints but there is a problem.
If I set
min_hours = 3 and
max hours = 5
and a teacher should work 21 hours per week we could have combination: 5 + 5 + 5 + 3 + 3
but a better one should be: 5 + 5 + 4 + 4 + 3

So, I recommend a new constraint like "frequency of max hours per day"
For my example this new parameter would be 2 (5+5)

Liviu Lalescu

#1
OK, I'll add this in the TODO, but it is difficult to implement. It is also a bit weird constraint.

But I suggest you a trick: add another duration 1 activity to this teacher, and make min hours daily = 4. (but be careful, this new activity might add a gap, so you may need to reconsider gaps constraints.)

nouvakis

#2
QuoteIt is also a bit weird constraint.
5+5+4+4+3 is more balanced than 5+5+5+3+3.

QuoteBut I suggest you a trick: add another duration 1 activity to this teacher, and make min hours daily = 4. (but be careful, this new activity might add a gap, so you may need to reconsider gaps constraints.)
I would like to try your trick, but I don't understand it. I should add another activity duration 1 without students? Is that correct?

Liviu Lalescu

Quote from: nouvakis on October 19, 2013, 08:31:55 AM
QuoteIt is also a bit weird constraint.
5+5+4+4+3 is more balanced than 5+5+5+3+3.

Yes, you are right, sorry.

Quote
I would like to try your trick, but I don't understand it. I should add another activity duration 1 without students? Is that correct?

Yes.

Silver

- if the problem in 1 teacher timetable you can used "teacher avelible" - the first time constraint.

- you can used "max hours for teacher" :
max hours = 4
recommended = 95 %
= 5 - 4 - 4 - 4 - 4

nouvakis

Quote from: Silver on October 21, 2013, 08:07:10 PM
- if the problem in 1 teacher timetable you can used "teacher avelible" - the first time constraint.

- you can used "max hours for teacher" :
max hours = 4
recommended = 95 %
= 5 - 4 - 4 - 4 - 4

This one could produce (min=3 100%, max=4 95%)
6, 6, 3, 3, 3

not acceptable !

nouvakis

#6
I think that I managed to "inject" the right source code to manage this constraint (at least the teacher's max hours per day occurance).
Maybe the code is not optimal, but it seems to work.

1) modify forms Teacher Max hours per day as below


2) defines in generate_pre.cpp
int teachersMaxOccursDailyMaxHours1[MAX_TEACHERS];
int teachersMaxOccursDailyMaxHours2[MAX_TEACHERS];

3) init code in same file (function computeTeachersMaxHoursDaily) line 1906
teachersMaxOccursDailyMaxHours1=-1;
teachersMaxOccursDailyMaxHours2=-1;

line 1940 (and similar)

if (teachersMaxHoursDailyMaxHours1[tmd->teacher_ID]==-1 ||
   (teachersMaxHoursDailyMaxHours1[tmd->teacher_ID] >= tmd->maxHoursDaily &&
          teachersMaxHoursDailyPercentages1[tmd->teacher_ID] <= tmd->weightPercentage))
{
    teachersMaxHoursDailyMaxHours1[tmd->teacher_ID] = tmd->maxHoursDaily;
         if (tmd->maxOccur>0)
                    teachersMaxOccursDailyMaxHours1[tmd->teacher_ID] = tmd->maxOccur;  // nouvakis
    teachersMaxHoursDailyPercentages1[tmd->teacher_ID] = tmd->weightPercentage;
}

4) generate.cpp line 7536 (this one could be better ... maybe by using an array ?)
if (limitHoursDaily>=0 && limitMaxOccurs>0 && increased)
{
                    int count_max_occurs;
                    count_max_occurs = 0;
                    for (int tmp_d=0; tmp_d < gt.rules.nDaysPerWeek; tmp_d++)
                        if (newTeachersDayNHours(tch, tmp_d)>=limitHoursDaily)
                        {
                            count_max_occurs++;
                            if (count_max_occurs>limitMaxOccurs)
                            {
                                okteachersmaxhoursdaily=false;
                                goto impossibleteachersmaxhoursdaily;
                            }
                        }
}

I will send the files by email

Liviu Lalescu

#7
I agree with the above, but not on 4). It is more complicated. You need to not abandon search so easily if things are not the way you want. It works, but not perfectly.

Firstly, I think you should consider also max gaps per day/week, like I do. Also, there are two phases. In the first phase you do a preliminary test, and if it is OK you exit with success. In the second phase you compute the exact current timetable and only exit without success if you cannot remove any useful activity anymore. I think you can see this two phase approach in the (majority of?) teachers' and students' constraints.

Are you sure this is an important constraint?

I don't know if I can add it to the official. I am afraid not to mess things up, making a critical mistake.

If you want, I could give you a section to expose your custom version, so we can get feed-back from other users.

Later edit: in your files, you forgot to modify the fitness and get(Detailed)Description in timeconstraint.cpp.

Also, this max occurs should have only weight 100%?

Also, in modifyconstraintteachermaxhoursdailyform.cpp, line 48 is wrong.

nouvakis

#8
Quote from: Liviu Lalescu on October 04, 2014, 06:50:28 PM
I agree with the above, but not on 4). It is more complicated. You need to not abandon search so easily if things are not the way you want.

Firstly, I think you should consider also max gaps per day/week, like I do. Also, there are two phases. In the first phase you do a preliminary test, and if it is OK you exit with success. In the second phase you compute the exact current timetable and only exit without success if you cannot remove any useful activity anymore. I think you can see this two phase approach in the (majority of?) teachers' and students' constraints.
I am sure that you are right about this. I am not sure if I realised exactly all of your variables (and all lines of code).

Quote from: Liviu Lalescu
Are you sure this is an important constraint?
As I mentioned at previous messages it will result to more balanced days for teachers.

Quote from: Liviu Lalescu
I don't know if I can add it to the official. I am afraid not to mess things up, making a critical mistake.
I hope ...

Quote from: Liviu Lalescu
Later edit: in your files, you forgot to modify the fitness and get(Detailed)Description in timeconstraint.cpp.
I saw it aftewards (the Description part).
I have no idea about the fitness part !

Quote from: Liviu Lalescu
Also, this max occurs should have only weight 100%?
In my case yes.

Quote from: Liviu Lalescu
Also, in modifyconstraintteachermaxhoursdailyform.cpp, line 48 is wrong.
I changed this line
maxOccursSpinBox->setValue(1);

I am thinking that
a. value -1 should ignore the setting
b. when value of max occurance is equal to nDaysPerWeek the setting should also be ignored

Liviu Lalescu

Yes, you got the variables, but not all the necessary code.

Yes, I understood "more balanced days for teachers", but I mean is it useful for more people in real timetabling? This constraint (max occurs) might be negligible compared to other more important constraints. Also, only few people might use it in their data. But anyway, this is not a good reason not to do it.

If you need only 100% weight, you need to change your source. skipRandom will be done by 100%, and you will need two directions, one with both max hours and max occurs, and one with only max occurs. I think. You might want to do a separate constraint (more work for you).

About the setValue, in the modify dialog it should always come from the constraint. In the add dialog it should be default -1. And don't forget to set the min and max values for the spin box.

Volker Dirr

Quote from: Liviu Lalescu on October 04, 2014, 06:50:28 PMAre you sure this is an important constraint?

It is of course not critical if you don't have it, but it might be a nice way to improve a bit more if the teacher has a lot of "short" activities. (I mean activities that are splittet only in a few parts.)

Quote from: Liviu Lalescu on October 04, 2014, 06:50:28 PMAlso, this max occurs should have only weight 100%?

Less then 100% is unneeded, because in that case you can simply add 2 current existing constraints: For example max 5 hours with 100% and max 4 hours with 95%.
So only the 100% is needed.
I like that 100% variant much more then the "trick" i wrote 2 lines above. So i think it's a nice feature.

Liviu Lalescu

#11
OK, if this is the request of more users, I'll try to do it.

Still, I think it is a bit confusing such a constraint.

I am thinking of making it a separate constraint. And put it before max hours daily in the menu, because it might be better than the old existing constraint. Only 100% weight percentage allowed. How to name it? "Teacher(s)/Students (set) max hours daily max occurences per week"?

It will not be easy. I'll think about it and maybe we'll have it. I'll keep in mind nouvakis' code, but it is not that easy.

Thank you, nouvakis, for your suggestion and code! Could you send me an input file for testing this? (If I will make it.)

Liviu Lalescu

#12
nouvakis,

I thought about this. I looked over the present code (official FET-5.23.3, src/engine/generate.cpp).

1) The changes are very difficult in generate.cpp. There are many possibilities to consider, and maybe a perfect treatment is impossible.

See for instance generate.cpp, lines 7543-7572. These are for a unique limit per day. But if you want two possible limits (5 two times per week, the rest maximum 4), the things become much more difficult.

(I care in these lines above about the gaps.)

2) The changes are critical in generate.cpp. New timetables might become impossible. For instance, in the past, it took much time until I noticed a bug relating to max hours daily, on a locked file it got stuck. And probably it rejected good unlocked file timetables.

Anyway, I'll keep this suggestion in my mind. But for now I do not have the courage/possibility to do it.

I hope you can understand me.

Meanwhile, you can experiment with your code. It will work in some situations. In some other situations you may find that it blocks the timetable generation (like generating on a fixed timetable, or other situations).

Also, I hope that by using some tricks you can overcome the problems.

Liviu Lalescu

#13
nouvakis,

I thought some more. I obtained the attached file (you can see the old original file and the new modified file), you can see the changes with a diff program. I did not compile the new file - it might not work. But it is an idea. The new code is not perfect, because it does not care perfectly about the gaps (I care about gaps in max hours daily, but not in the new constraint - which is nearly perfect, but not perfect). Also, the changes are highly critical - a very small mistake will make many timetables unsolvable.

I will keep thinking of this idea, and is something comes up I will let you know.

nouvakis

Quote from: Liviu Lalescu on October 08, 2014, 05:29:48 PM
I will keep thinking of this idea, and is something comes up I will let you know.

Thanks for your efforts