Best bound

[Vorokhalice]

1. I cannot create a new branch in you repo, but it would have been great
2. The foss toolchain for aion is now 2023, not 2020
3. I am not sure, how good this implementation is. As a config, I have now time limit too, which plays role for the BnB trees (they now run while the pool/bag is not empty and time is less than time limit). For nodes, I also have a field for best bounds. I wanted to do it just for minimisation/maximisation problems like PFSP/Knapsack, however, when ...

[Guillaume-Helbecque]

Hi @Vorokhalice, thanks for your PR!

I quickly went through your code and have a few questions:

• It seems that timeStop is not used in the problem-specific procedures, but only in the main while-loop. Therefore, I'm wondering if there is any reason why you included it into the Problem_XYZ classes? If no, I think we should implement it as a global configuration constant (config const timeStop) in the main files, and then use it normally in the search_XYZ codes, as for the saveTime or activeSet variables.
• I'm not sure to understand the meaning of problem.getType(). Is it a procedure that returns the type of the problem (e.g., max or min), or something else?
• You explained in your PR message that you added child.bound also for the non-optimisation problems (N-Queens and UTS), but I don't get why. It seems that your PR message has been cut off.

[Guillaume-Helbecque]

Why this value?

[Vorokhalice]

If no leaf nodes are explored, we still need a minimal 'best' lower bound. I set it to a non-zero value to avoid division by zero in the optimality gap.

[Vorokhalice]

1. I've made a few changes to the code — I hope you can see them. Thanks again, you were right about timeStop: I’ve removed it from the Problems structure and now pass it directly to search_XYZ.
2. I've corrected the typo with Dantzig and Martello — thank you for pointing it out.
3. The type of the problem is 1 for maximisation, -1 for minimisation, and 0 for others. I use it to decide whether we should track the best upper or lower bound in the end.
4. Continuing from the last comment :)
   For the nodes, I also added a field for best bounds. Initially, I planned to use it only for optimisation problems like PFSP or Knapsack. However, when I try to retrieve this field, Chapel tries to access it at compile time even if the problem type is 0 and I do check the type as you can see in search_XYZ. That’s why I had to include this field in problems like NQueens and UTS as well.
   Maybe you know a better workaround for this?

[Guillaume-Helbecque]

Hi @Vorokhalice, I did a second pass on your code and updated few things directly in your branch:

• I fixed a small issue with timeStop in main_pfsp.
• I defined enum ProblemType { Max, Min, Enum } in order to specify the type of the problem. The first advantage is to avoid using the hard-coded 1, 0, and -1 parameters, which are not self-explanatory. Moreover, I stored the problem type inside the variable problem.problemType to get rid of problem.getType(). Actually, this procedure is not needed as the problem type is only a contant defined at the beginning. (May be I could do the same with problem.getInitBound?)
• I slightly improved the Node initializers.

I also have a question: is timeStop always an integer, or would it makes sense to implement it as a real (to allow 0.5 seconds for example)?

Before merging, I still need to perform some performance testing. In particular, these kinds of operation, max reduce [n in bag] n.bound, are sensitive as we iterate over a highly parallel data structure.