This is a major rewrite of the serialization strategy for nodes.

Improvements include:

• much faster serial performance (especially with pypy)
• removed numpy as a dependency
• any pickle-able object can be assigned to node.state (no longer needs to be a numpy float array)
  • old way:

  def save_state(self, node):
      node.resize(2)
      node.state[:] = (self.lb, self.ub)
  def load_state(self, node):
      self.lb, self.ub = node.state[:]
  

  • new way:

  def save_state(self, node):
      node.state = (self.lb, self.ub)
  def load_state(self, node):
      self.lb, self.ub = node.state
  

• lexicographic node priorities can now be used (fixes #4):
  • example: solver.solve(problem, queue_strategy=('bound','objective'))
• added a config object to allow users to adjust serialization settings (e.g., use dill instead of pickle)

Hey, cool library!

Maybe I'm missing something here, but it doesn't seem like there's any way to get the answers or the path to the answers out? SolverResults doesn't have the best node and there's no bookeeping to keep the chain of nodes?

Hi ! Thank you for the development of this package ! I was wondering if there was a way to call the solver attributes inside the problem methods. For instance, I would like to have access to the best objective within the bound method in the following way :

class Problem(pybnb.Problem):
    ...
    def bound(self):
        best_objective = self.retrieve_solver_attribute("best_objective")
        return do_bounding_using_best_objective()
    ...

Thank you for your answer, Théo

Hi Gabriel

Thanks for a great project!

I am struggling to find a way to obtain the variables' assignments once I have solved the example knapsack problem and obtained an optimal solution. Somehow I cannot access the decision variables' values leading to the obtained optimal objective value.

I am assuming there must be a way to obtain the values of each integer variables in the results object, but I cannot figure out how. I have gone through the documentation, but can't seem to find anything. Any help? :)

This PR adds a solver option, track_bound, that allows one to disable functionality that tracks the global queue bound until the solve terminates. This can significantly reduce the overhead for certain queue implementations (except for worst-bound first, which tracks the bound for free).

This PR tracks changes that can be made when support for Python 2 is dropped at the end of 2019. So far, changes are almost entirely cosmetic:

• drop enum34 and six dependency
• replace class Name(object): with class Name:
• drop 2 or 3 lines that dealt with bytes <-> str casting
• use keyword-only arguments

Type annotations are not included in this PR as they are not entirely supported in Python 3.5. In particular, x: <type> = <value> is only supported outside function declarations in Python 3.6+.

If the objective/bound computation uses NumPy and happens to return, for instance, a numpy.float64 type, this creates issues when serializing these node attributes through marshal.dumps(...). When the dispatcher receives the node, the call to marshal.loads produces an object of type bytes rather than a number that can be used for computation.

I think the best fix is to add some code on the worker side that appropriately casts the objective/bound value returned from the problem to an int or float built-in type (possibly do the same with the queue_priority attribute in case the user sets this).

An alternative would be to use pickle to serialize these node attributes, but I believe this can be noticeable slower than marshal (double check this).

Can you include a knapsack implementation in your examples? I'm struggling a bit with the documentation. It would be helpful for newcomers to familiarize with your library.

Things to address:

• [ ] Setting up the communicator tree and listeners could be made easier
• [ ] Allow load balance and timing statistics to be sent up to the root solver

This would require allowing a tuple to be assigned to Node.queue_priority rather than just a number. One could utilize this either by implementing a custom queue strategy, or by setting the queue_strategy option to a tuple of queue strategy names.

It can currently be done by the user using optional Problem methods, but it should probably done by the solver.

Possible implementation:

• When a worker thinks it has a new best node, send it to the dispatcher on the next update.
• The dispatcher sends the best node to workers on the final update (or possibly earlier with every update).
• If load_solution=True (new solver options, default True), load_state will be called with this node rather than the root at the end of the solve. If load_solution=False, the node will be placed on the results object.

Hi there, Will there ever be a multithreading support instead of the already implemented multiprocess version? This may be very useful if multiple nodes share a child, and the bound() function makes use of all parents infos.