Fine, let's exclude 0 as a counting number. That wasn't my point though. Ignore it. *you* omitted the irrefutable point that in set theory there is such a thing as the empty set, and there's such a thing as a set's size, and thus 0 is unavoidable. You're stuck with 0 as a concept whether you use 0-offset or 1-offset indices.
If 0 is less unnatural than -1, then, all further arguments flow from there. subList(i, i) isn't "unnatural", it occurs all the time. I've got a word X, I know it ends with "foo" and I'd like to strip that out: String fooless = X.substring(0, X.length() - "foo".length()); - that looks nice, is only correct if range description works according to the a <= i < b principle, and introduces substring(0, 0) if the entire string is itself "foo". Your argument about losing an addressable argument seemed like bogus to me. java has an exclusively end-of-range concept in all its APIs and I never lost an addressable argument. What are you talking about? You may judge Dijkstra on the fact that he's Dijkstra. Yes, even more argumentation might be better, but at some point one takes a man's accomplishments as having some intrinsic value. Finally, indexing and offsetting is not entirely the same. Sometimes you're working with a pointer-esque mechanic even in java. For example, most operations in java that work with byte arrays offer a (byte[] array, int offset, int length) concept. As annoying as it is that this isn't consistent with sublist and substring (those have 'end' instead of 'length'), imagine if you will that you're working instead with a filter that removes parts. You're now talking in offsets: you have a given index into the array and you need to move X slots over to the right. If you'd like to remain with the first element, X could only be 0. And there's 0 again. It is unavoidable. -1 and 1, on the other hand, are entirely avoidable. The APIs are more consistent with 0. 0 wins. On Apr 17, 12:56 pm, Peter Becker <[email protected]> wrote: > Reinier, > > you very conveniently pick pieces. Let me show you inline... > > On 17/04/10 13:16, Reinier Zwitserloot wrote:> replies inline. > > > On Apr 17, 2:15 am, Peter Becker<[email protected]> wrote: > > >> Traditionally zero is not a natural number. > > > Who cares about natural numbers? > You wrote: > > RULE 1: Counting elements in a list is in the domain of the natural > > numbers. Therefore, if negative numbers are needed the solution is > > inferior. > > This is what I was replying to, only that you removed that part.> This is > about the counting numbers, > > and zero is undisputably a counting number. > > Funny, the first three hits for "counting number" on Google are for me: > > http://mathworld.wolfram.com/CountingNumber.htmlhttp://wiki.answers.com/Q/What_is_a_counting_numberhttp://www.mathsisfun.com/whole-numbers.html > > Wolfram (admittedly the best of those sources) says that " However, zero > (0) is sometimes also included in the list of counting numbers.", the > other two exclude zero. Not exactly what I call "undispatable". But > let's not go there.> After all, if you're > > counting and there's nothing there, you need some name for this > > concept as well as a notation. The name is 'zero' and the notation is > > '0' - at least, that seems the most sensible thing to pick. Given the > > axiomatic need to represent the empty range somehow, there's no > > dodging the need for the 0 concept. > > Who's trying to dodge the zero concept? I just don't think it is common > to start counting from zero. Feasible: yes. Common: no.>>> RULE 2: In a list > of, say, 10 elements, it would be odd if '11' is > >>> anything other than an Out-Of-Bounds number. > > >> It isn't in either scheme. > > > But of course it is; in the indices start at 1 system, to make a copy > > of a list you'd have to write list.subList(1, 11); and yet this won't > > cause an IndexOutOfBoundsException. > > No, it is not. The second parameter is the index behind the last, thus > not necessary part of the index range.> One could of course switch to a > > system where the end is inclusive and not exclusive like java's. In > > this case you'd end up with list.subList(1, 10), but now you get into > > all the points dijkstra raised: The difference between the indices is > > offset by 1 from the length of the sublist, and the thing I mentioned: > > To represent an empty list you'd now need to write: list.subList(1, > > 0), which is weird. I'm going to make that axiomatic, by the way: I'm > > taking it as natural and given that subList(1, 0) looks awkward. If > > this is not axiomatic for you I'm not sure there's a point arguing, as > > that would come down to taste. We could however spew facts about the > > size of the population that thinks subList(1, 0) is acceptable, of > > course. > > I agree that his is about taste. I still think that subList(i,i) is > rather odd and unexpected unless you grew up in C world. But I don't > have any stats on population sizes either. > > > > >> What is the smallest natural number? I studied math in Germany and there > >> I learned that there is a set N (let's not add too much TeX -- the N > >> should have the double bar on the left), which is the sequence starting > >> at one, then repeatedly adding one. The numbers including zero are N_0 > >> (subscript zero). That is a bit old school, and there are many different > >> conventions (see e.g.http://en.wikipedia.org/wiki/Natural_number). But > >> saying "there is a smallest natural number" and implying it is zero > >> hides the fact that conventions have been and continue to be different. > > > Dijkstra's point WASNT that the smallest natural number is zero. His > > point instead was that the number BELOW whatever one picks as > > 'smallest natural number' will be required in most of the schemes that > > aren't java. So, if you think 0 is ugly, then you could start at > > offset 1, but you then also have to choose that end indices are > > exclusive. Because if you don't, to describe the empty set you need to > > write subList(1, 0) - and that 0 is one less than the lowest natural > > number, and therefore, 'unnatural'. > > What is the problem with an "unnatural" number?> The same argument applies if > one > > DOES consider 0 as a natural number - if you do the end indicing as > > inclusive you'd have to write subList(0, -1), which also includes an > > unnatural number. This part of dijkstra's argumentation attempts to > > prove that the only proper way to designate a range is for the start > > index to be inclusive, and the end index to be exclusive. > > For which you have to assume that this number outside the range is > somehow unwanted. Matter of taste again.> You've also mentioned a few times > that you don't consider the benefits > > raised so far as relevant, but, let's flip it around then: What does > > counting from 1 get you? > > A common behaviour with other scenarios. AFAIK not a single spreadsheet > application starts row or column count at 0. And if I do the thought > experiment of standing at central station asking all bypassers to number > a list of something (let's say words), I somehow think that the number > of people labeling starting with 1 would be much higher than the number > of those starting with 0. You even talk about the "first element of an > array", not the "zeroest". > > Do you think everyone should change their ways and start counting at zero? > > > At least counting from 0 gets you the ability > > to describe the smallest and largest sublists in a way that is > > consistent and doesn't have to dip into unnatural numbers on either > > end. > > Actually, by having the second parameter of subList(..) exclusive you > lose one addressable element. If you have an array that spans the whole > addressable range, then you can't clone the array using the subList(..) > method. Not that this would be common, but neither is creating empty > arrays using subList(..).>>> Adhering to convention a) yields, when starting > with subscript 1, the > >>> subscript range 1 ≤ /i/< /N/+1; starting with 0, however, gives the > >>> nicer range 0 ≤ /i/< /N/. > > >> What makes the second range nicer? I miss an argument supporting this > >> statement. > > > The range 0< i< N includes only numbers that fit within the set's > > own counting numbers, whereas 1< N + 1 contains a number that isn't a > > counting number of the set (N + 1 itself). > > I don't get this at all. Either you start counting at 0 (consistent with > your index), in which case N is not a number within the counting > numbers. Or you count from 1, in which case 0 isn't. Your index has N > values, the range 0..N has N+1.>> My personal opinion is that there are valid > reasons why it is convenient > >> for an implementation of array structures to use the convention Dykstra > >> proposes as (a). You basically take the perspective of pointers (oddly > >> enough not an argument Reinier or Dykstra made). > > > Of course not. Implementation is utterly irrelevant here. It would be > > completely trivial for C to consider a[1] as simply dereferencing 'a' > > as a pointer. In java in particular the same logic can be made. I'm > > speaking now from the perspective of the compiler itself. If you'd > > like to claim that it's easier for library writers (who are after all > > 'users' of the programming language) to work with 0 offsets then that > > is of course a fine argument for why 0 offsetting is the only right > > answer. > > I claim it is easier to use 0-based indexing if you use a pointer mindset.>> > I believe pretty much anyone else (including most > >> mathematicians) tend to prefer 1-based indexing. > > > As dijkstra tried to highlight with his Mesa example, in practice 0- > > based indicing is more consistent. > > His example seems limited to the statement " Extensive experience with > Mesa has shown that the use of the other three conventions has been a > constant source of clumsiness and mistakes" -- without any more > information on what Mesa exactly did and how that caused problems it is > pretty hard to judge.> It's a lesson you need to grok, but > > once you do so it's all consistent. With 1-offsetting you lose some of > > this, as for example a location offset has to be 0 based to make any > > sense, and thus you always have to think: Is this 1-offset or 0- > > offset? In other words, 0-offset is unavoidable, but 1-offset is. By > > avoiding 1-offsets, all offsetting is 0 based and even if this feels > > less natural for a beginning programmer its easier for everyone that's > > been programming for longer than 7 days. As most programmers spend > > more than 14 days programming, 0 offsetting wins. I freely admit I > > pulled the number '7 days' out of you know where, but you get the > > point, I presume. > > How is indexing and offsetting the same? We are still assuming we are > not arguing in pointer arithmetics, aren't we? > > Peter > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group > athttp://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
