Closed/open makes sense for continuous measures, for integers closed/closed is more readable
Only for integer ranges that are not concatenated.
Always use [closed, open) intervals
111–120 of 169 posts
Re: Always use [closed, open) intervals
#112What's with the funny connected "st" in the article? I've never seen that before.
I don't see it, perhaps a different font loaded for me, but maybe you mean a ligature?
Re: Always use [closed, open) intervals
#113Don't call you integer bound vars `start` and `end` please. Either use `start` and `endExclusive` or start and length - this greatly reduces confusion. In my experience, half opened integer intervals lead to fewer `- 1` in the code.
Good luck with the C++/STL standards committee.
Re: Always use [closed, open) intervals
#114Don't call you integer bound vars `start` and `end` please. Either use `start` and `endExclusive` or start and length - this greatly reduces confusion. In my experience, half opened integer intervals lead to fewer `- 1` in the code.
how about `start` and `stop`?
Re: Always use [closed, open) intervals
#115As 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.
Yes, this is relevant for discrete distributions.
Why is X= 0) = 1 – Pr(–X <= 0) = 0.
Re: Always use [closed, open) intervals
#116Half-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…
>+1/-1 shenanigans
"There are two hard problems in programming, cache invalidation, naming things, and off by one errors."
Re: Always use [closed, open) intervals
#117The notation here really bothered me. The author defines the [closed, open) interval [a, b) as the list of all numbers number x that fulfill a ≤ x I think this is a problem when borrowing math concepts to programming. What the author is really talking about here is slicing, not intervals, and the slicing behavior is hopefully well defined on the construct you are working with, most of the time in a manner that makes sense to each construct, or in a consistent manner to other related constructs in the language.
If the author would stick with programming concepts, I don’t think this is a rule we should abide to, rather, a guideline which can be employed. And I think most programmers value consistency, so this really isn’t that much of an issue.
Re: Always use [closed, open) intervals
#118> 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…
This is the sort of thing that's great for helping engineers go from junior to mid-level and then dangerous for going from mid to senior. Thinking clearly about exceptions to "rules" is one of the most important skills you can impart.
Don't Repeat Yourself is great advice... but only if you start thinking about all the caveats where over-application leads to architectural disasters.
The GP is largely correct here: If your advice includes "never" or "always", you're probably doing more long-term harm than good.
Re: Always use [closed, open) intervals
#119The other nice property of [closed, open) intervals is that they concatenate perfectly:
[a, b) ++ [b, c) == [a, c)
Re: Always use [closed, open) intervals
#120The other nice property of [closed, open) intervals is that they concatenate perfectly: [a, b) ++ [b, c) == [a, c)
Even [closed, closed] intervals have that property: [a, b] + [b, c] == [a, c]