Always use [closed, open) intervals
1–10 of 169 posts
Re: Always use [closed, open) intervals
#2*half-open intervals. There have been times I needed an (open, closed] interval. But there have also been times when I wanted a fully closed interval because I was setting an arbitrary limit and it's easier to tell a user "100 is the maximum" versus "it must be below 100”, so what value should be put to max out out, 99? 99.99? etc
To add some nuance I'd say that if you're dividing a larger interval into smaller subintervals then a half-open one is probably what you want.
Re: Always use [closed, open) intervals
#3This is not universal advice. If it’s nonsensical for your app to have start-end events of zero length, nothing in the article applies, and using closed intervals does make things a bit cleaner.
Re: Always use [closed, open) intervals
#4There are convincing cases one can make in favour of half-open intervals (at least in certain circumstances), but this isn’t it.
This is just a rambling, absolutist mess.
Re: Always use [closed, open) intervals
#5This depends on use case. If you are doing a frontend layer on top of closed-open, then the frontend will have to handle the points the article is rambling about.
Users are used to selecting a daterange in closed closed format for example.
Re: Always use [closed, open) intervals
#6There are convincing cases one can make in favour of half-open intervals (at least in certain circumstances), but this isn’t it. This is just a rambling, absolutist mess.
Why not? The precision one sounds convincing and I don't have any obvious counters
Re: Always use [closed, open) intervals
#7This depends on use case. If you are doing a frontend layer on top of closed-open, then the frontend will have to handle the points the article is rambling about. Users are used to selecting a daterange in closed closed format for example.
It depends on the use-case. Selecting an airbnb booking for example, you pay by the night, and the last day is check-out day, so it's sort of [bookingStart, bookingEnd).
Though from a user perspective, they are still there on the final day. Still, I think there's some nuance to this, as it's generally understood the date range they select isn't the number of nights they expect to pay for.
Re: Always use [closed, open) intervals
#8I think this advice could be better summed up into: to minimise off-by-one errors, choose a consistent strategy for describing intervals, and stick with it as much as is sensible.
Re: Always use [closed, open) intervals
#9It's the default in Python, and it's more helpful that not, so I would say it's a good design decision. But "always" is a dangerous word in engineering, and in this case, definitly not warranted.
Case in point, last week I worked with list ofdates, and I needed the last date to bracket my sliding windows as a time period cleanly.
Re: Always use [closed, open) intervals
#10I think this advice could be better summed up into: to minimise off-by-one errors, choose a consistent strategy for describing intervals, and stick with it as much as is sensible.
[closed, open) isn’t the only strategy that works, but it should be preferred because it’s so common.