Isn't connected range implementation a score trap?

[jason076]

I am wondering if the implementation of connected ranges is a score trap. I am referring to the following example from the documentation:
https://docs.timefold.ai/timefold-solver/latest/constraints-and-score/score-calculation#collectorsConnectedRanges

E.G if the solver moves job4 to the right now starting on 9:00 and ending on 10:15. Now Job4 and Job5 will have less overlap but the maximum overlap of the connected range will still be 2 for the truck equipment. Isn't this per definition a score trap? We have a similar constraint in our project and one employee of timefold suggested to us that it is better to sum up the number of jobs per equipment for each time grain. So we can check capacity violation for each time grain. In that implementation the score improves if job4 is moved to the left as previously described.

Of course our constraint is horribly slow but has no score traps. Is this why connected ranges are designed as they are? It is faster and you just accept the score traps?

[triceo]

Hello @jason076! Honestly, I never thought of it as a score trap, but you are correct. It could be one.

Thankfully, the ConnectedRange type also has getLength() method. This makes me think that, for ranges with hasOverlap(), you can use getLength() to avoid the score trap - the bigger the length, the less overlap. Although that's not a perfect proxy either; we're clearly missing a field that would carry the total length of the overlap.

[triceo]

And as I dig through our issues to file one for this, I find that one already exists:
#1398

[jason076]

Ah okay, thats great. Sorry that I did not find that one.

Another issue we face is that our ranges in the connected range have different sizes in terms of how many capacity of the equipment it takes. By default every range counts as 1. Multiplying the maximum overlap value with a fixed value is also not sufficient because each range could have a different size requirement. Is is possible to give this information to the connected range? From the api I don't see any possibility.

[triceo]

I can't think of a way to do that currently. But it stands to reason that, if/when we're allowing for the overlap size, that we take this into scope as well.

[jason076]

Would be great for our use case. Maybe the connected ranges approach is faster than our approach.