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

41–50 of 169 posts

Re: Always use [closed, open) intervals

#41

Post by mananaysiempre »

ChrisMarshallNY wrote: post #14

> Never, ever, ever use [closed, closed] intervals I’m not really a fan of “never,” or “always” rules, when it comes to programming. I’ve found it’s usually better to have a “make sure to justify deviations from” heuristics. I usually use [closed..open) ranges (as they are called in Swift), but sometimes, an inclusive range is a lot more appropriate, for expressing an operation (for example, I may express a range as…

See also “My least favourite Rust type”[1] for an argument that Rust’s (polymorphic) range type should have used inclusive bounds.

[1] https://ridiculousfish.com/blog/posts/least-favorite-rust-ty..., discussed two years ago in https://news.ycombinator.com/item?id=24546928

Re: Always use [closed, open) intervals

#42

Post by Rygian »

sshine wrote: post #35
Rygian wrote: post #13

Earlier quoted context omitted.

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)…

So it boils down to what is being represented: an amount of items versus an amount of _boundaries_ across items.

When I'm booking that stay between Jan 13th and Jan 14th, and I am presented with options, the ones that say "sleeps 2" does not mean [1, 2) but rather [1, 2] and the one that says "sleeps 6" does not mean [1, 6) but rather [1, 6].

Re: Always use [closed, open) intervals

#44

Post by twiss »

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

AirBnB bookings are actually half-open, because you book a number of nights - so if you book December 1 - 3, you book the nights of December 1 and 2 - excluding 3. This seems expected to me.

However, as an AirBnB host, this bit me once because if you set that you're available on December 1, 2 and 3, guests can actually book December 1 - 4. But this is more because availability uses individual dates (almost like closed ranges) instead of half-open ranges like bookings do.

For booking flights, though, it's more like you're booking two individual flights on specific dates, it's not really a range at all, and so it doesn't really matter whether you think of it as open or closed. The flight search engine might want to check that the second flight departs after the first flight lands, but that has more to do with the flight times than the dates you enter.

Re: Always use [closed, open) intervals

#45

Post by chkas »

Python uses "closed open" intervals with `range(0, n)`, the reverse is then `range(n - 1, -1, -1)`, which is then highly unintuitive. This in connection with 0-based array indexing makes certain algorithms then very cumbersome. For example Knuth-Shuffle. In Python this is:

    from random import randrange
    x = [10, 20, 30, 40, 50 ]
    for i in range(len(x) - 1, 0, -1):
        r = randrange(i + 1)
        x[i], x[r] = x[r], x[i]
    print(x)
With 1-based indexing and inclusive ranges it would be much more understandable:

    a[] = [ 10 20 30 40 50 ]
    for i = len a[] downto 2
        r = random i
        swap a[i] a[r]
    end
    print a[]

Re: Always use [closed, open) intervals

#46

Post by Archelaos »

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.

I am entrusted with a database application for a tour operator. The actual use cases for start and end dates can be quite tricky.

For some of them arrival and departure date are most relevant, for others it is arrival and nights (or first and last date of the evening of the night). In the latter case, think of a calendar that shows the occupancy of a room for the manager. The only reasonable way to do this is to mark the days where the room is occupied in the evening and ignore the morning.

With rental cars it is even trickier, because there a 24 hour cycle form pickup time to drop off time is the basis for counting the days of rental.

Some metrics are best made available to managers in two versions for convinience, e.g. trip price per person per day vs. trip price per person per night (where day = night + 1).

For the business logic (except for rental cars, which use a modified one) I implemented a special general purpose Duration class with the following properties:

  DateOfArrival
  
  DateOfDeparture
  
  DateFirst /* same as DateOfArrival */
  
  DateLast /* day before DateOfDeparture */
  
  Nights
  
  Days /* Nights plus 1 */
The class comes with some operations for combining Durations or calculate/check-for intersections, etc.

With this class, it is easy to switch between an open and a closed interval view of the same data, and it is very transparent in the source code which is actually used.

Re: Always use [closed, open) intervals

#47

Post by mananaysiempre »

chkas wrote: post #45

Python uses "closed open" intervals with `range(0, n)`, the reverse is then `range(n - 1, -1, -1)`, which is then highly unintuitive. This in connection with 0-based array indexing makes certain algorithms then very cumbersome. For example Knuth-Shuffle . In Python this is: from random import randrange x = [10, 20, 30, 40, 50 ] for i in range(len(x) - 1, 0, -1): r = randrange(i + 1) x[i], x[r] = x[r], x[i] print(x) W…

In Python, reversed(range(0, n)) (which is also a thing you can write—does that help?) is indeed written range(n-1, -1, -1), but I think I recently encountered a language where that was written as (the local syntax’s equivalent of) range(n, 0, -1), that is to say the rule was not “start inclusive, end exclusive” but “low inclusive, high exclusive”. I’m not sure what language it was and whether this option ultimately ends up more intuitive, but in any case it’s a valid option.

(One difference is that the start-end rule can work polymorphically with equality only, while the low-high rule requires an ordering.)

Re: Always use [closed, open) intervals

#48

Post by [deleted] »

chkas wrote: post #45

Python uses "closed open" intervals with `range(0, n)`, the reverse is then `range(n - 1, -1, -1)`, which is then highly unintuitive. This in connection with 0-based array indexing makes certain algorithms then very cumbersome. For example Knuth-Shuffle . In Python this is: from random import randrange x = [10, 20, 30, 40, 50 ] for i in range(len(x) - 1, 0, -1): r = randrange(i + 1) x[i], x[r] = x[r], x[i] print(x) W…

[deleted]

Re: Always use [closed, open) intervals

#49

Post by formerly_proven »

mananaysiempre wrote: post #47
chkas wrote: post #45

Python uses "closed open" intervals with `range(0, n)`, the reverse is then `range(n - 1, -1, -1)`, which is then highly unintuitive. This in connection with 0-based array indexing makes certain algorithms then very cumbersome. For example Knuth-Shuffle . In Python this is: from random import randrange x = [10, 20, 30, 40, 50 ] for i in range(len(x) - 1, 0, -1): r = randrange(i + 1) x[i], x[r] = x[r], x[i] print(x) W…

In Python, reversed(range(0, n)) (which is also a thing you can write—does that help?) is indeed written range(n-1, -1, -1), but I think I recently encountered a language where that was written as (the local syntax’s equivalent of) range(n, 0, -1), that is to say the rule was not “start inclusive, end exclusive” but “low inclusive, high exclusive”. I’m not sure what language it was and whether this option ultimately…

A potential issue with reversed(range(...)) is reversed() eagerly constructing the entire range.

Re: Always use [closed, open) intervals

#50

Post by pwg »

zx8080 wrote: post #20

Am I the only one who noticed a bit unusual (or not?) ligature for 'st'?

Yes, terribly ugly ligature.

You can turn it off by using dev tools to remove the '"dlig" 1' entry in the "font-feature-settings:" CSS attached to the body element.

Post reply on HN