21–30 of 169 posts
I prefer [a, b) intervals because they encode two pieces of important information directly: 1. The first element (a) 2. The length (b-a) Which are what we most often need.
Am I the only one who noticed a bit unusual (or not?) ligature for 'st'?
I prefer [a, b) intervals because they encode two pieces of important information directly: 1. The first element (a) 2. The length (b-a) Which are what we most often need.
If, however, a and b are dates, these operations are nonsensical, as is using anything else except closed intervals: for date range comparisons it is much more understandable to use start-of-day on a and end-of-day on b.
If you encode dates as number of days since some fixed date, they can be seen as numbers on a timeline, so the start date and the length (in days) of a "date interval" could be useful information. If you mean that subtracting two dates represented as strings of "YYYY-MM-DD" form is nonsensical... well, duh.
> for date range comparisons it is much more understandable to use start-of-day on a and end-of-day on b
I personally agree with this, but then again, "more understandable" is a subjective notion. I don't see how it make open intervals for dates nonsensical in itself.
"You're arriving on 15th and going home 23rd" implies that you're there 23-15=8 full days (unless we count the arrival/departure half-days as full days, in which case the arithmetic itself breaks down, so it doesn't matter which intervals we use mathematically) - that's an open interval.
Earlier quoted context omitted.
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?
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.
Am I the only one who noticed a bit unusual (or not?) ligature for 'st'?
https://old.reddit.com/r/programming/comments/z18gb6/comment...
And while I agree that [closed, open) intervals are often the best choice... sometimes what you want is [closed, closed], or (open, open), and it's nice to use a language that makes that easy.
For example, Raku makes it easy to do:
[closed, closed] with ($a .. $b)
[closed, open) with ($a ..^ $b)
(open, open) with ($a ^..^ $b)
(open, closed] with ($a ^.. $b)-------
However, I know of one case where closed intervals really shine. Consider displaying a zoomable map in tiles. On a given zoom level, each tile has some coordinates (x;y) where x and y are integers denoting the virtual column and row. Suppose that we allow zooming out by a factor 2, so that two-by-two tiles are aggregated into a single tile. Then a natural choice for the coordinates of the zoomed-out tile are (floor(x/2);floor(y/2)), that is, divide by two and round down. Suppose that a dataset has data on tile coordinates [x1,x2]×[y1,y2], meaning that there's only data on tiles (x;y) where x1≤x≤x2 and y1≤y≤y2. These are closed intervals, but stay with me - the reason they are nice in this case is because of how you compute the range of valid tile coordinates when you zoom out: The range becomes [floor(x1/2),floor(x2/2)]×[floor(y1/2),floor(y2/2)] - that is, you simply divide the range endpoints by two and round down. If you try to do this with half-open intervals, then you need some +1/-1 shenanigans, which are normally what I try to avoid by going for half-open intervals.
In my experience, half opened integer intervals lead to fewer `- 1` in the code.