Earlier quoted context omitted.
I was born 0 years old.
Which shows that you weren't born in Japan: people there are born 1 year old.
They are not even though they start counting from 1. The child is still zero years old.
Always use [closed, open) intervals
131–140 of 169 posts
Re: Always use [closed, open) intervals
#132Don'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.
I prefer `pastEnd`, perhaps in reaction to the original SGI STL, where the documentation called it "past end", but the actual names in the code were just `end`.
For example, look at the...
https://www.boost.org/sgi/stl/stl_introduction.html
...where the documentation is very careful to say "one past the end of the range", and then they proceed to just call `v.end()`. I always thought that was silly.
Re: Always use [closed, open) intervals
#133Earlier quoted context omitted.
Which shows that you weren't born in Japan: people there are born 1 year old.
They are not even though they start counting from 1. The child is still zero years old.
It's a matter of (natural language) terminology. It's the difference between asking "which year of your life are you currently in" as opposed to "how many full years have elapsed since you were born?"
Re: Always use [closed, open) intervals
#134Ehh, 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…
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…
I remember at the time when C++ ranges were getting standardized there was a talk about an alternative replacement for iterators: splitting them into things that point at elements and between them. That solved the reversal / backward iteration problem rather neatly, although IIRC there wasn’t always a clear choice of which kind of thing should now be returned in place of a single iterator.
(Of course, that doesn’t help at all if you’re using raw indices, but then again, people used to describe screen coordinates as pointing between “little square” pixels rather than at sample locations back in the days of the original Macintosh and 16-bit Windows.)
Re: Always use [closed, open) intervals
#135Earlier quoted context omitted.
No, a [closed, open) interval of [Jan 13, Jan 13) would give you 0 nights. A [closed, open) interval of calendar dates incidentally does correspond to the number of nights spent. So booking [Jan 13, Jan 14) would mean spending one night. The hotel gives you until, say, 11:00 to get out the next day without paying for that date. Half-open intervals are neat because they concatenate without overlap. So [Jan 13, Jan 14)…
So it boils down to what is being represented: an amount of items versus an amount of _boundaries_ across items. When I'm booking that stay between Jan 13th and Jan 14th, and I am presented with options, the ones that say "sleeps 2" does not mean [1, 2) but rather [1, 2] and the one that says "sleeps 6" does not mean [1, 6) but rather [1, 6].
But I don't think these are equivalent.
When looking for a booking you are using an interval.
When looking at room capacity you are looking for a minimum. This is not the same as an interval. If you are looking for "sleeps 6" that is your bare minimum acceptance in capacity. You are not interested for the [1, 6] interval. Nothing below 6 makes sense.
Even if you wanted to force the interval use here, I'd say you'd be looking for the [6, INF) interval. That is, rooms with capacity of at least 6 (but having more capacity is fine).
Re: Always use [closed, open) intervals
#136The 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…
"[a, a)" and "a ≤ x < a" are actually shorthand for {x∈ℝ | a ≤ x < a}, which is the empty set ∅. This makes perfect sense.
Re: Always use [closed, open) intervals
#137> 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"?
[deleted]
Re: Always use [closed, open) intervals
#138As 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.
There are distributions that are mostly continuous but also have point-masses.
Re: Always use [closed, open) intervals
#139Dumb question but why is ‘[‘ called ‘closed’ and ‘)’ called ‘open’? I somehow would have thought the reverse.
Re: Always use [closed, open) intervals
#140The other nice property of [closed, open) intervals is that they concatenate perfectly: [a, b) ++ [b, c) == [a, c)
And it's as a result of this that length([a, b)) + length([b, c)) == length([a, c))