Andre Pang <[EMAIL PROTECTED]> writes: >> >> --range=1025..2048 >> >> --range=1024..2047 >> > >> > I haven't been following that closely, but how are you going to >> > tell what the user really wants to do if he gives either of those >> > two statements? >> >> Only one of those statements will be a valid way of downloading the >> second kilobyte of a file. The question is, which one. > > Oh! That makes it a bit easier :). I vote for 1025..2048, which > I believe is standard across all functional programming > languages. The [ and ] also correlate nicely to the mathematical > interpretations. (Compare [5..10] with (6..9), for instance).
This is again a misunderstanding. Both of the above are inclusive, they only disagree on whether the first byte is 0 or 1. You have elided parts of my posting that explain that. Note that I never proposed an interval open on both sides, but only on the right side. And you deleted that proposal. Again, the alternatives are: 1025..2048 starting with one, end-closed 1024..2047 starting with zero, end-closed 1024..2048 starting with zero, end-open > The majority of end-user utilities seem to like counting from 1, > whereas programming languages tend to start counting from 0. A > quick look at the GNU text utilities (e.g. tail -c) seems use > 1-counting rather than 0-counting. That makes sense for counting lines. Bytes are almost always indexed from zero. > Basically, I think that from an end-user perspective, they're used > to dealing with 1-counting, not 0-counting. If you're *counting* something, sure. But we're not implementing `wc -c' here -- we are referring to specific bytes, or rather to an interval. 0-based indexing makes much more sense to me.
