3 ms·

There 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, absol

There 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.

cuteboy19 4y ago
Why not? The precision one sounds convincing and I don't have any obvious counters
- kreetx 4y ago
  Let's say you want to find accommodation from day x to y, would you rather have [x, y + 1) as the interval in the code? In other words, I think the blog post lists problems the author has had and in those cases an open-closed interval would have worked better. But one could come up with an opposite case, would that be equally true?
  - zasdffaa 4y ago
    IIRC (bit rusty now) python makes you do exactly [x, y + 1) in code and it pisses me off which is why I did my own trivial end-is-included range for loops.
    - bigDinosaur 4y ago
      Otherwise would result in surprises like range(10) giving 11 values, violating convention. I admit I usually have to pause to remember whether it's inclusive of the upper bound or not.
  - asplake 4y ago
    Of course if datetimes are involved, you need to go up midnight. So you’re back to +1 and a half-open range
rieTohgh6 4y ago
I am more surprised it is about numbers. I found it more important to take care when dealing with date ranges in databases. And SQL "BETWEEN" lures you into using [from, to], which is great way to shoot yourself in foot. So just my 2 cents: - what are you going to do when you need to split [a,b] into multiple parts, for performance reasons? [a,c], (c,b] ? Can your codebase handle different interval types? Having [a,b) everywhere is simpler - stuff like 23:59:59.999999999 is code smell, well until database rounds it up, to next day, then it turns into bug
- bouke 4y ago
  A system I work on chose to use [closed, closed] intervals for date time intervals, where multiple intervals should be adjacent, but not overlapping. So the intervals look like 2022-11-22T00:00:00.000Z - 2022-11-22T23:59:59.999Z. Of course the codebase is sprinkled with +/- 1ms, and off-by-one issues causing date times to match _no_ interval. [closed, open) would've been so much easier to work with and reason about.

There 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.

cuteboy19 4y ago

Why not? The precision one sounds convincing and I don't have any obvious counters

kreetx 4y ago
Let's say you want to find accommodation from day x to y, would you rather have [x, y + 1) as the interval in the code? In other words, I think the blog post lists problems the author has had and in those cases an open-closed interval would have worked better. But one could come up with an opposite case, would that be equally true?
- zasdffaa 4y ago
  IIRC (bit rusty now) python makes you do exactly [x, y + 1) in code and it pisses me off which is why I did my own trivial end-is-included range for loops.
  - bigDinosaur 4y ago
    Otherwise would result in surprises like range(10) giving 11 values, violating convention. I admit I usually have to pause to remember whether it's inclusive of the upper bound or not.
- asplake 4y ago
  Of course if datetimes are involved, you need to go up midnight. So you’re back to +1 and a half-open range

rieTohgh6 4y ago

I am more surprised it is about numbers. I found it more important to take care when dealing with date ranges in databases. And SQL "BETWEEN" lures you into using [from, to], which is great way to shoot yourself in foot. So just my 2 cents: - what are you going to do when you need to split [a,b] into multiple parts, for performance reasons? [a,c], (c,b] ? Can your codebase handle different interval types? Having [a,b) everywhere is simpler - stuff like 23:59:59.999999999 is code smell, well until database rounds it up, to next day, then it turns into bug

bouke 4y ago
A system I work on chose to use [closed, closed] intervals for date time intervals, where multiple intervals should be adjacent, but not overlapping. So the intervals look like 2022-11-22T00:00:00.000Z - 2022-11-22T23:59:59.999Z. Of course the codebase is sprinkled with +/- 1ms, and off-by-one issues causing date times to match _no_ interval. [closed, open) would've been so much easier to work with and reason about.