make the runner request points until it's using all cores

[jbweston]

(original issue on GitLab)

opened by Bas Nijholt (@basnijholt) at 2017-09-06T09:14:54.989Z

Right now, when the runner requests n_cores points, and the learner returns n (where n < n_cores) points, the maximum number of jobs will be n.

Because of this behavior, we have the following code in BalancingLearner and Learner2D:

    def choose_points(self, n, add_data=True):
        if not add_data:
            raise NotImplementedError('')

I think we can fix this by having the learner return n (where n ≤ n_requested) points and writing the runner in a way such that it will request n_requested points until n_requested == n_cores.

@jbweston what do you think about this?

I consider gitlab:!7 blocked until we make a decision on this because if we decide not do to this, I'll have to change the code to if not add_data: raise NotImplementedError().

[jbweston]

originally posted by Anton Akhmerov (@anton-akhmerov) at 2017-09-06T09:16:01.309Z on GitLab

I think this is a bad design. Instead the learner should always return n points when requested n points.

[jbweston]

originally posted by Bas Nijholt (@basnijholt) at 2017-09-06T09:17:54.102Z on GitLab

OK, but in that case we cannot deal with add_data=False.

[jbweston]

originally posted by Anton Akhmerov (@anton-akhmerov) at 2017-09-06T10:36:49.536Z on GitLab

I don't think these are related issues. I suggest closing this issue, because requesting n points seems like a good interface.

[jbweston]

originally posted by Joseph Weston (@jbweston) at 2017-09-06T11:20:16.729Z on GitLab

I would tend to agree that choose_points should return n points.

If the behaviour is "it could return < n points, and in such a case you should call choose_points again until you have n points", then we could as well implement this logic inside choose_points

[jbweston]

originally posted by Anton Akhmerov (@anton-akhmerov) at 2017-09-06T14:37:46.243Z on GitLab

Closing, following the above discussion.