Live data from Hacker News

Always use [closed, open) intervals

fhur.me

51–60 of 169 posts

Re: Always use [closed, open) intervals

#51
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

#52
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.

Flights are just a set of two dates, not a range, like the other comment mentions.

I thought about it and this applies to an AirBnB, or more generally, a vacations, too. A vacation from Nov 25 to Nov 27 doesn't mean you stay from Nov 25 0:00 to Nov 27 23:59:59, but it means "arrive sometime Nov 25, leave sometime Nov 27" - a set of two dates

Re: Always use [closed, open) intervals

#53

Earlier quoted context omitted.

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.

Nope: unlike, say, sorted(), reversed() will never force an iterator into a sequence—it will either call __reversed__ or fall back to __len__ and __getitem__. An iterator needs to know how to reverse itself, or it’s out of luck. (Which is quite annoying because it forces you to write a class rather than a generator function.) Ranges are in the former category, they know how to reverse themselves[1]. (Yet for some reason range(0, 42) and range(41, -1, -1) repr themselves as range(0, 42) and range(41, -1, -1) respectively while reversed(range(0, 42)) is instead . Truly, I cannot touch anything without finding a bug or at least a suspiciously insectoid lifeform.)

[1] https://github.com/python/cpython/blob/7e3f09cad9b783d8968aa...

Re: Always use [closed, open) intervals

#54
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…

With Knuth-Shuffle, it would be: for i in reversed(range(1, len(x))): That makes it better, but not much.

Re: Always use [closed, open) intervals

#55

Earlier quoted context omitted.

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

Nope: unlike, say, sorted(), reversed() will never force an iterator into a sequence—it will either call __reversed__ or fall back to __len__ and __getitem__. An iterator needs to know how to reverse itself, or it’s out of luck. (Which is quite annoying because it forces you to write a class rather than a generator function.) Ranges are in the former category, they know how to reverse themselves[1]. (Yet for some rea…

Thanks, TIL about the __reversed__ protocol despite having lived in chapter three of the Python reference for some time.

Re: Always use [closed, open) intervals

#56
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.

Yeah, when talking to humans about dates, [closed, closed] is useful.

Once you swap to a higher precision format for an actual database search, you get all the messiness from the article.

Re: Always use [closed, open) intervals

#57
Wholeheartedly agree that sticking - where possible - to [closed, open) is a good idea. It has helped me tremendously when implementing, e.g. computational geometry algorithm. Robust triangle rasterization comes to mind.

Another interesting point: in the weird corner of the world where I grew up, half-open intervals were always denoted : [low_bound, hi_bound[

I am of course completely biased, but I've always found this notation much more elegant and intuitively obvious than the [low_bound, hi_bound) that seems to be the prevalent norm in the anglo world.

Using '[' after the upper bound clearly shows that we're open at the top whereas the ')' is fairly arbitrary.

And while I'm on the topic of weird culture-induced quasi-arbitrary biases: I had a math teacher that would bark (and I mean BARK!) at us if we ever used '>' in inequalities.

The justification was that with this constraint, all inequalities ended up written and laid out with its two members respecting the standard "left-to-right" drawing of the real line, which made it much easier to picture what was going on geometrically.

It also enforced consistency throughout a long demonstration - one less thing added to the cognitive load.

He was made fun of a lot by the student body, of course, but later in life, as a programmer, I have found myself sticking to the habit and I always force myself to mostly use '' and ">".

I find this makes code much more readable, just like back in the days of my old teacher with math inequalities., and pretty much for the exact same reasons.

Of course, doing that does not help at all when reading other folks code, those uncivilized heretical users of the 'greater than' form.

Re: Always use [closed, open) intervals

#58

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

Agree, in programing you can always find a contrargument to any "never ever use X". I noticed that people often treat such phrases godmatically and then use it in another context, where it might not be true.

I like more phrasing it like this "in 90 % of the cases it is better to use X over Y", to leave the room for other options. But it is not a catchy phrase if you want to write a blog post.

Nevertheless I really like the points the author gave, something I didn't thought about before.

Re: Always use [closed, open) intervals

#59
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…

There's one pretty common exception that's "closed closed".

    random.randint(a, b)
    Return a random integer N such that a 
https://docs.python.org/3/library/random.html#random.randint

But in reality nowadays you almost always want to use the newer, simpler and more secure "secrets" module.

Re: Always use [closed, open) intervals

#60
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.

> I don’t expect the empty interval.

We're squarely in the realm of preferences here. I'm the exact opposite of you: to me the last day is not included.

Post reply on HN