Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Always use [closed, open) intervals

fhur.me

Post reply on HN
Print view View original

31–40 of 169 posts

Re: Always use [closed, open) intervals

#31

Post by eurasiantiger »

bheadmaster wrote: post #23
eurasiantiger wrote: post #21

Earlier quoted context omitted.

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, however, a and b are dates, these operations are nonsensical 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…

Encoding dates in data in any other way than native date datatypes or full ISO date/timestamp strings is incredibly dangerous and prone to tz and dst conversion issues. It still might fit some niche use though. I was thinking more in line with some sort of Date entities.

Your example, as you point out, is flawed with respect to reality: no system would record arrival/departute dates and expect to calculate accurate length of stay, except in full days, as in b-a-1 = 7 days, effectively making the example use a closed interval if it were implemented in reality.

Imagine a hotel reservation system using just dates. Arrival on the 15th and departure on the 23rd would mean a reservation from the 15th to the 22nd, while the 23rd would already be free for someone else to book.

Re: Always use [closed, open) intervals

#32

Post by moring »

enqk wrote: post #25

I think this has to do with the nature of the metric underneath. Closed-open intervals are the way to go for integers. However they don’t seen to be a good fit for sampling from continuuous space

When you are working on a continuous space, what exactly is the difference in a program whether you use a closed-closed or half-open interval?

The only case that comes to my mind where it makes a difference at all is when you take discrete values from the interval and happen to hit exactly the end of the interval. But then the difference comes from the "discrete" part again. As long as you work on the continuous space, everything you typically do (e.g. integral, average, ...) give the same result no matter whether the end is part of the interval.

(You mentioned sampling, but I'd suggest that sampling by just taking values without lowpass filtering first is a bad idea anyway, and with a filter you are back to an integral which doesn't care about open/closed)

Re: Always use [closed, open) intervals

#33

Post by [deleted] »

Rygian wrote: post #13
sshine wrote: post #12

This is one of those "well, of course!" pieces. But I've bookmarked it, in case I run into someone who thinks they disagree, in which case I can offload the explanation. I had a similar incident with colleagues who had discovered the "Default" trait and starting adding defaults to everything, including things that didn't have good defaults, and things where they didn't mean default but actually something quite specif…

So, if I want to book the night from Jan 13th to Jan 14th on AirBNB (which is the very first example given in the post), I should search for "Arrival Jan13th, Departure Jan 13th"? As with any piece of advice, there are cases where it applies and cases where it does not apply. Or, in other words, someone can claim "Well, of course!" for the opposite advice.

[deleted]

Re: Always use [closed, open) intervals

#34

Post by chenglou »

Quite a few APIs use a pair of `{start, length}` instead, which in the context of the post's example, is even clearer. Empty interval would be `length == 0`, time interval would be a single array of `starts`, etc. Fewer subtractions (to get length) usually end up nicer too.

Re: Always use [closed, open) intervals

#35

Post by sshine »

Rygian wrote: post #13
sshine wrote: post #12

This is one of those "well, of course!" pieces. But I've bookmarked it, in case I run into someone who thinks they disagree, in which case I can offload the explanation. I had a similar incident with colleagues who had discovered the "Default" trait and starting adding defaults to everything, including things that didn't have good defaults, and things where they didn't mean default but actually something quite specif…

So, if I want to book the night from Jan 13th to Jan 14th on AirBNB (which is the very first example given in the post), I should search for "Arrival Jan13th, Departure Jan 13th"? As with any piece of advice, there are cases where it applies and cases where it does not apply. Or, in other words, someone can claim "Well, of course!" for the opposite advice.

No, a [closed, open) interval of [Jan 13, Jan 13) would give you 0 nights.

A [closed, open) interval of calendar dates incidentally does correspond to the number of nights spent. So booking [Jan 13, Jan 14) would mean spending one night. The hotel gives you until, say, 11:00 to get out the next day without paying for that date.

Half-open intervals are neat because they concatenate without overlap.

So [Jan 13, Jan 14) + [Jan 14, Jan 15) = [Jan 13, Jan 15).

This is a very convenient property when dealing with dates in particular, but also indices over arrays.

Re: Always use [closed, open) intervals

#36

Post by jmull »

Half-closed is generally good because it tends to reduce off-by-one errors.

But this article overstates the case. Especially for floating-point, where the distinction between a The “splitting by time” section should probably just be removed, since it confuses the point and doesn’t add anything. The scenario doesn’t really make sense (if you wanted this you’d store the registration time and get the hour you’d be better off by truncating the value, not using an interval). Also, if you’re going to be doing math on time values, you better know the precision of the values you’re working with (among many other things). Intervals, however closed or open aren’t going to help you there.

Maybe I shouldn’t criticize so much, since I agree with the general point. But this makes the case awkwardly.

Re: Always use [closed, open) intervals

#37

Post by girvo »

Rygian wrote: post #13
sshine wrote: post #12

This is one of those "well, of course!" pieces. But I've bookmarked it, in case I run into someone who thinks they disagree, in which case I can offload the explanation. I had a similar incident with colleagues who had discovered the "Default" trait and starting adding defaults to everything, including things that didn't have good defaults, and things where they didn't mean default but actually something quite specif…

So, if I want to book the night from Jan 13th to Jan 14th on AirBNB (which is the very first example given in the post), I should search for "Arrival Jan13th, Departure Jan 13th"? As with any piece of advice, there are cases where it applies and cases where it does not apply. Or, in other words, someone can claim "Well, of course!" for the opposite advice.

Or selecting ranges for various UI things — our customers complained that the “end” was exclusive! We had to change it

Re: Always use [closed, open) intervals

#39

Post by q-big »

_xnmw wrote: post #38

Why would you want a half-open interval when booking an AirBnB or flight? If I search for flights from February 24 to February 24 I don’t expect the empty interval.

> If I search for flights from February 24 to February 24 I don’t expect the empty interval.

The expectation depends on how you define "from" and "to" :-D

Since the HN community is quite mathematically-minded, I'd expect there all four possible kinds of definitions in the inner minds of HN members. :-D

Post reply on HN