You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We noticed that many use cases of VariableListener are simply to update arrivalTime for Visit instances on a Vehicle, where Vehicle is an entity with a list variable of the Visit type. This is a very simple use case for which implementing a full variable listener is overkill and the solver can help here. This is the core idea:
class Visit {
@InverseRelationShadowVariable
Vehicle vehicle = ...
@PreviousElementShadowVariable
Visit previous = ...
@TailShadow("updateArrivalTime") // TailShadow is a working name; discussion pending.
LocalDateTime arrivalTime = ...
void updateArrivalTime() {
arrivalTime = previous.getDepartureTime() + previous.distanceTo(this);
}
}
Since we know that arrivalTime can only change if the vehicle or previous changes, we can generate a full-fledged variable listener under the hood, without bothering the user. The only user code is in updateArrivalTime(). Some considerations:
This will only be implemented for list variable, not for chain variable.
If two TailShadow fields point to the same method, it means that two variables are updated by
the same method. The tests should ensure that this will only be triggered once in that case and not twice or more.
The generated variable listener implements short-cutting. It stores previous and new values of the variables and if they do not differ, it does not continue iterating down the tail chain. The values will be compared using equality and not identity; if identity were used, LocalDateTime etc. would not work.
If neither PreviousElementShadowVariable nor InverseRelationShadowVariable are specified on Visit, we will not fail fast. The user still might have specified Index..., or simply has some calculation that they want to do without either of those.
As part of this work, we want to see this in action on the VRP quickstart, and we want to make sure that the performance is the same if not better.
The remainder of a feature previously known as "shadow streams" will be re-evaluated after we have seen the fruit of this labor. It is likely that the vast majority of variable listeners will already have been removed by this. Future work may include:
Declarative shadow variables.
Loop detection.
The text was updated successfully, but these errors were encountered:
We noticed that many use cases of
VariableListener
are simply to updatearrivalTime
forVisit
instances on aVehicle
, whereVehicle
is an entity with a list variable of theVisit
type. This is a very simple use case for which implementing a full variable listener is overkill and the solver can help here. This is the core idea:Since we know that
arrivalTime
can only change if thevehicle
orprevious
changes, we can generate a full-fledged variable listener under the hood, without bothering the user. The only user code is inupdateArrivalTime()
. Some considerations:TailShadow
fields point to the same method, it means that two variables are updated bythe same method. The tests should ensure that this will only be triggered once in that case and not twice or more.
LocalDateTime
etc. would not work.PreviousElementShadowVariable
norInverseRelationShadowVariable
are specified onVisit
, we will not fail fast. The user still might have specifiedIndex...
, or simply has some calculation that they want to do without either of those.As part of this work, we want to see this in action on the VRP quickstart, and we want to make sure that the performance is the same if not better.
The remainder of a feature previously known as "shadow streams" will be re-evaluated after we have seen the fruit of this labor. It is likely that the vast majority of variable listeners will already have been removed by this. Future work may include:
The text was updated successfully, but these errors were encountered: