Questions regarding the graph design

[AllenChen0958]

Thanks for the great work.
Still, after gone through the paper and the implementation, I got a few questions regarding the graph design and arcs update strategy.

1. It seems add arcs strategy does not contain the information of future operations which require to use the same machine.

Since there is no arc between blue/red/green nodes at the beginning, it implies that the RL agent does not consider the relationship between future operations on the same machine during the scheduling process.
I understand that the state representation of add arch strategy is more efficient to be processed by GIN. But Isn't removing arcs strategy more reasonable?

2. Why RL agent choose actions/operations by only looking back on the past scheduled nodes instead of considering future operations.

The aggregation only collects the information of incoming neighbors, which means that RL agent picks next operation based on the
past scheduled nodes. But shouldn't the RL agent consider the future operations while making the next action?
Is there any special reason for the author to adopt current design?

[zcaicaros]

Hi,

Thank you for your insightful question. I give the answers in the following. I hope it helps.

1. You are right. The adding-arc strategy ignores the relations among future operations on the same machine. The paper states that the adding-arc strategy is more efficient in computing graph embedding than the removing-arc strategy. However, it inevitably suffers from losing information issues. This is a trade-off. Some people have already considered fully connected graph representation, e.g., ScheduleNet, and the performance is better.

2. I believe adding future information will help.

[AllenChen0958]

Thank you for taking the time and effort in writing the response.
I think I'll try to benchmark the performance/time for the different graph representation.