Skip to content

2D: if boundary point fails it will never be re-evaluated ... #82

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
basnijholt opened this issue Dec 19, 2018 · 4 comments
Closed

2D: if boundary point fails it will never be re-evaluated ... #82

basnijholt opened this issue Dec 19, 2018 · 4 comments

Comments

@basnijholt
Copy link
Member

(original issue on GitLab)

opened by Bas Nijholt (@basnijholt) at 2018-05-23T22:27:59.419Z

... also not if you start the runner again.

@basnijholt
Copy link
Member Author

originally posted by Joseph Weston (@jbweston) at 2018-05-25T08:12:07.237Z on GitLab

I guess the solution is to create a new learner? The boundary points are evaluated first, so you're not throwing too much data away

@basnijholt
Copy link
Member Author

originally posted by Joseph Weston (@jbweston) at 2018-05-25T08:25:31.945Z on GitLab

I guess this is the learner's responsibility, but it seems a rare edge case to add a separate branch for. Every time we fill the stack we'd have to first check whether the boundary points are either in the (evaluated or unevaluated) data or in the stack. If not we put them at the top of the stack

@basnijholt
Copy link
Member Author

originally posted by Joseph Weston (@jbweston) at 2018-05-25T08:28:25.997Z on GitLab

Actually I don't understand how this happens at all:

def remove_unfinished(self):
    self._interp = set()
    for p in self._bounds_points:
       if p not in self.data:
          self._stack[p] = np.inf

so the stack should get the boundary points put onto it when remove_unfinished is called (as it is in the finally block of runners), and the boundary points have not been evaluated.

@basnijholt
Copy link
Member Author

originally posted by Bas Nijholt (@basnijholt) at 2018-05-30T00:26:49.870Z on GitLab

I think you are right.

We fixed the issue, the person that had the issue was having some other bugs that led us to incorrect conclusions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant