Skip to content
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

get_soft_bounds should never exceed the hard bounds #490

Closed
jbednar opened this issue Jun 25, 2021 · 0 comments · Fixed by #498
Closed

get_soft_bounds should never exceed the hard bounds #490

jbednar opened this issue Jun 25, 2021 · 0 comments · Fixed by #498
Labels
type-bug Bug report
Milestone

Comments

@jbednar
Copy link
Member

jbednar commented Jun 25, 2021

At least up to version 1.10.1, get_soft_bounds respects the hard bounds if there is no soft bounds, but it doesn't actually crop to the hard bounds:

    def get_soft_bounds(self):
        """
        For each soft bound (upper and lower), if there is a defined
        bound (not equal to None) then it is returned, otherwise it
        defaults to the hard bound. The hard bound could still be None.
        """
        if self.bounds is None:
            hl, hu = (None, None)
        else:
            hl, hu= self.bounds

        if self.softbounds is None:
            sl, su = (None, None)
        else:
            sl, su = self.softbounds

        if sl is None: l = hl
        else:          l = sl

        if su is None: u = hu
        else:          u = su

        return (l, u)

I think it should not only enforce the hard bounds where softbounds is None, but also crop any soft bounds provided by the hard bounds. Right now if softbounds are provided that are outside the hard bounds, get_soft_bounds will return an illegal range of values. Such a softbounds are arguably an error, but since we don't prevent that error, we should presumably deal with such a case at least here.

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

Successfully merging a pull request may close this issue.

1 participant