The 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]
b would be included twice in that case, wouldn't it?
Always use [closed, open) intervals
121–130 of 169 posts
Re: Always use [closed, open) intervals
#122Earlier quoted context omitted.
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…
[deleted]
Re: Always use [closed, open) intervals
#123Earlier quoted context omitted.
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.
Which shows that you weren't born in Japan: people there are born 1 year old.
Re: Always use [closed, open) intervals
#124> 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 like Raymond Chen's formulation of this point:
> Good advice comes with a rationale so you can tell when it becomes bad advice. If you don't understanding why something should be done, then you've fallen into the trap of cargo cult programming, and you'll keep doing it even when it's no longer necessary or even becomes deleterious.
from: https://web.archive.org/web/20100104031036/http://blogs.msdn...
Re: Always use [closed, open) intervals
#125> 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 like Raymond Chen's formulation of this point: > Good advice comes with a rationale so you can tell when it becomes bad advice. If you don't understanding why something should be done, then you've fallen into the trap of cargo cult programming, and you'll keep doing it even when it's no longer necessary or even becomes deleterious. from: https://web.archive.org/web/20100104031036/http://blogs.msdn...
Twain's Corollary:
"We should be careful to get out of an experience only the wisdom that is in it -and stop there; lest we be like the cat that sits down on a hot stove-lid. She will never sit down on a hot stove-lid again -and that is well; but she will never sit down on a cold one anymore."
-Mark Twain
Re: Always use [closed, open) intervals
#126Just for completeness I'll mention that there is another style: start, count This seems to be popular in .NET ecosystem.
That’s for creating an enumerable of discrete integers, not for defining an interval.
Re: Always use [closed, open) intervals
#127The 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…
[deleted]
Re: Always use [closed, open) intervals
#128There are convincing cases one can make in favour of half-open intervals (at least in certain circumstances), but this isn’t it. This is just a rambling, absolutist mess.
I am more surprised it is about numbers. I found it more important to take care when dealing with date ranges in databases. And SQL "BETWEEN" lures you into using [from, to], which is great way to shoot yourself in foot. So just my 2 cents: - what are you going to do when you need to split [a,b] into multiple parts, for performance reasons? [a,c], (c,b] ? Can your codebase handle different interval types? Having [a,b…
A system I work on chose to use [closed, closed] intervals for date time intervals, where multiple intervals should be adjacent, but not overlapping. So the intervals look like 2022-11-22T00:00:00.000Z - 2022-11-22T23:59:59.999Z. Of course the codebase is sprinkled with +/- 1ms, and off-by-one issues causing date times to match _no_ interval. [closed, open) would've been so much easier to work with and reason about.
Re: Always use [closed, open) intervals
#129> You could try [T, T-1], but that's a bit clunky and it won't work if T is a decimal number.
Huh? What do they mean by "decimal number"?
Re: Always use [closed, open) intervals
#130Just for completeness I'll mention that there is another style: start, count This seems to be popular in .NET ecosystem.
That’s for creating an enumerable of discrete integers, not for defining an interval.
If by "enumerable of discrete integers" you meant Enumerable.Range, it's not just that. Other examples include String.Substring, Array.Fill, Stream.Read, Span constructor etc.
If you meant it's not practical for non-integer types such as floats or dates, then of course you are right.