Live data from Hacker News

Always use [closed, open) intervals

fhur.me

101–110 of 169 posts

Re: Always use [closed, open) intervals

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

The example using closed intervals makes sense. I see why you mention 1-based indexing, but it’s mostly a different beast. I’ll defend 1-based indexing here because, having used Lua a lot, the indexing issue just goes away. People like what they’re used to. Most coders are used to 0-based, but we all start life 1-indexed. We begin counts with 1: chapter 1, the 1st floor of a building (in the US), 1 AD, the 1st of Dec…

I was born 0 years old.

Re: Always use [closed, open) intervals

#102

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

> Advice is supposed to convey information

> Great advice:

> "Never run a red light"

If conveying information is the goal, then that is crappy advice because it conveys no information. The information you're not conveying is that "running red lights adds significant risk of injury and death for both yourself and others because you cannot easily see cross traffic with enough time to save yourself and them."

This is not only informative about stopping at red lights but also about when it might be ok to go through them without enumerating every grain of sand on the beach.

Re: Always use [closed, open) intervals

#104
As it goes with maxims like this, it depends on the problem domain. In probability theory and statistics, a cumulative distribution function is defined as F(x) := Pr(X Like others are saying, it is consistency within the code base that probably matters the most.

Re: Always use [closed, open) intervals

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

The example using closed intervals makes sense. I see why you mention 1-based indexing, but it’s mostly a different beast. I’ll defend 1-based indexing here because, having used Lua a lot, the indexing issue just goes away. People like what they’re used to. Most coders are used to 0-based, but we all start life 1-indexed. We begin counts with 1: chapter 1, the 1st floor of a building (in the US), 1 AD, the 1st of Dec…

0-based is for offset arithmetic, not pointer arithmetic.

Re: Always use [closed, open) intervals

#107

I am surprised I can't see this here. Wasn't anyone else taught [closed; closed] and ]open; open[ notation in school?

Both forms are valid according to ISO 31-11. Your form is often called the "French notation" and I assume used more commonly in France and countries with French influences.

Re: Always use [closed, open) intervals

#108
post #87

Earlier quoted context omitted.

Dijkstra is a smooth talker and sometimes he's able to convince people that an argument is settled even when it is not... Here, he conveniently ignores examples that are better for [closed,closed], such as iterating backwards over the range. That is more annoying for [closed,open) because it turns into the abhorent (open,closed]. An argument I prefer is this: [closed,closed] is better for representing an index into t…

> That is more annoying for [closed,open) because it turns into the abhorent (open,closed]. What's wrong with (open, closed] ?? Especially if you're going backwards? for(int i=559; i>554; i--){ //do stuff with i } Perhaps the most important reason to do zero-indexed + [closed,open> and Its all non-intuitive because humans are really bad with off-by-one errors. ------ EDIT: I guess familiarity with [closed, closed] is…

No one really wants [x, y). That want [0,y) or [x,x+y) because y is the length of the interval.

So no one wants (y,x] when going backwards, because x0 there.

Re: Always use [closed, open) intervals

#109
post #104

As it goes with maxims like this, it depends on the problem domain. In probability theory and statistics, a cumulative distribution function is defined as F(x) := Pr(X Like others are saying, it is consistency within the code base that probably matters the most.

That difference only matters for discrete probability, and has the problem that the empty interval X<0 is impossible to represent.

Re: Always use [closed, open) intervals

#110
post #36

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

== does not exist in floating point, generally speaking.
Post reply on HN