Live data from Hacker News

Always use [closed, open) intervals

fhur.me

71–80 of 169 posts

Re: Always use [closed, open) intervals

#71

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

I've moved away from this. Advice is supposed to convey information simply and efficiently, and "asterisks" for every edge case just muddle it. Now my pet peeve has moved to folk wheedling about 100% accuracy in advice. ;-) e.g. Great advice: "Never run a red light" vs Technically-correct-but-will-never-be-read advice: "Don't run a red light, unless you're on a bicycle and you know that the intersesction you're at is…

There is still a difference between leaving out special cases to give more succinct advice and going out of your way to repeat the words "never"/"ever" three times to imply the absolute absense of any exceptions.

Re: Always use [closed, open) intervals

#72

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

I've moved away from this. Advice is supposed to convey information simply and efficiently, and "asterisks" for every edge case just muddle it. Now my pet peeve has moved to folk wheedling about 100% accuracy in advice. ;-) e.g. Great advice: "Never run a red light" vs Technically-correct-but-will-never-be-read advice: "Don't run a red light, unless you're on a bicycle and you know that the intersesction you're at is…

[deleted]

Re: Always use [closed, open) intervals

#74

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

I've moved away from this. Advice is supposed to convey information simply and efficiently, and "asterisks" for every edge case just muddle it. Now my pet peeve has moved to folk wheedling about 100% accuracy in advice. ;-) e.g. Great advice: "Never run a red light" vs Technically-correct-but-will-never-be-read advice: "Don't run a red light, unless you're on a bicycle and you know that the intersesction you're at is…

You could just say "Generally don't run a red light"

Re: Always use [closed, open) intervals

#75

I know Dijkstra's paper and it's short, good and should be read but this article is wrong in saying always . It feels like a newbie programmer came across a good thing then lost all proportion; use the right tool for the right job, as ever.

Fuck Dijkstra, his only argument was "this is ugly"

It's a short paper so read it. He justifies it then backs it up with experience from Mesa.

Re: Always use [closed, open) intervals

#76

Ehh, this post misses the important tidbid. You should keep your code consistent across your organization, so that a large number of programmers knows how your code works. You should have a "default writing style", and the "default writing style" should be used unless you have very, very, very good reasons to avoid it. (And an errant +1 or -1 here and there isn't a good enough reason to switch). There are four styles…

Once you go beyond integers, using [closed, open) or (open, closed] becomes more important, because otherwise you cannot represent adjacent intervals.

Re: Always use [closed, open) intervals

#77
FWIW, Postgres converts all ranges (=interval in this context) for discrete data types to half open intervals even when a closed one was requested.

So the daterange '[2022-01-01, 2022-01-07]' will result in [2022-01-01,2022-01-08) and the integer range '[1,7]' will result in '[1,8)'

So it seems the Postgres devs agree with the author.

Edit: typo fixed for integer range

Re: Always use [closed, open) intervals

#78

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

> as opposed to start.. This is not just a convenience thing. ..(end+1) is dangerous, if end is the largest representable number.

start..inf

Re: Always use [closed, open) intervals

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

Ignoring user experience, I would argue that this is actually an implicit half-open interval. You aren't really saying "give me flights from feb 24 to feb 24", you're saying "give me flights ON feb 24", which can be rephrased as "give me flights that take off feb 24th at midnight up to but not including february 25th at midnight".

Re: Always use [closed, open) intervals

#80
post #62
post #29

Half-open intervals are why I try as much as possible to stay away from languages that use 1-based indexing (Lua, Julia, Matlab, R, ...) - 1-based indexing lends itself to closed intervals because an array of N elements has [1,N] as its index range, whereas 0-based indexing lends itself to half-open intervals because an array of N elements has [0,N) as its index range. ------- However, I know of one case where closed…

I wonder if a lot of Lua's 1-indexed pain would be avoided by encouraging for-each style loops. Unless you need a specific sub range within an array, for-each will get you pretty far.

Yeah, but it's hard to argue with the fact that pairs/ipairs in loops are 25% to 2.5x slower than using `for i = 1,#tbl do v = tbl[i] end`. Performance isn't everything, but it's not nothing either.

https://springrts.com/wiki/Lua_Performance#TEST_9:_for-loops

Post reply on HN