4 ms·

> But "fencepost 0" or "fencepost 1" are both ambiguous to me Which is good, because it means that you are not confused :-) The confusion is the idea that the

> But "fencepost 0" or "fencepost 1" are both ambiguous to me Which is good, because it means that you are not confused :-) The confusion is the idea that there is an inherent link between "1" and "first" or "0" and "first", which there isn't, because one of them is a label, while the other is an ordinal number. You need a definition of how to map one to the other, and as long as you don't have that, the labels do indeed remain ambiguous, which you correctly recognize. Now, there is an argument to be made for why array indexing should use a definition that maps the first element to label 0, and that is, as I wrote, that array indexing is an additive operation. As for how that connects to your fence example: What you necessarily need in addition if you want to model your fence with an array(!) is a definition that maps your fence posts' positions to ordinal numbers, which you then can map to array indices via the definition above. That exact mapping is necessarily arbitrary to a degree, and the only really important thing is that you are consistent. But within the implementation, you are likely to encounter problems such as "find the third fencepost of the part of the fence that starts at the second fencepost". And that would be the fourth fencepost of the overall fence, not the fifth, or in indices: 1 + 2 = 3 vs. 2 + 3 != 4. > There are nearly no cases where there is a natural "element zero" that exists at zero in the physical world Well, nor is there a natural "element one" that exists "at one".

derefr 10y ago
> Well, nor is there a natural "element one" that exists "at one". Right. I'm on the "no natural mapping" side as well, here, not with the "first = 1" people. Actually, consider for a moment, a programming language that tried to avoid both of these mappings, at least in its programmer-facing syntax (it might compile down to one or the other mapping, but that's an implementation detail.) It might not be so bad! Of course, you wouldn't be able to index arrays by a single ordinal number at all, instead being forced to do speak in terms of intervals: letters = char{'A', 'B', 'C'} letters[0ch .. 1ch] # => ['A'] letters[1ch .. 2ch] # => ['B'] pairs = short{'AB', 'CD', 'EF'} pairs.slice(0sh .. 1sh) # => ['AB'] pairs[0sh .. 1sh] # => 'AB' pairs[0ch .. 1ch] # => ['A'] or a type error, as the language author pleases pairs[0sh .. 2sh] # => argument error pairs.slice(0sh .. 2sh) # => ['AB', 'CD'] Effectively, the single-element index operation would just be a specialization of a slice operation. Both operations would take a mantissa indicating where the "left edge" and "right edge" containing the value you want is in the array's memory space. And you'd be forced to specify explicit units for the "addresses" of the mantissa, even though the language might reject a mantissa of the wrong type. This seems kind of annoying to write. But, I swear, it feels so pleasant to read. Much moreso than any language I've used. It's not hard at all to "keep the logic in my head" when I read the above back.
- zAy0LfpBZLC8mAC 10y ago
  > pairs[0sh .. 1sh] # => 'AB' ['AB'], no? Or the letters without []? > This seems kind of annoying to write. But, I swear, it feels so pleasant to read. Much moreso than any language I've used. It's not hard at all to "keep the logic in my head" when I read the above back. Well, yeah, but you conveniently left out index arithmetic :-) If it's only about hard-coded indices, it really doesn't matter, IMO, as long as it's consistent, and you could just use any ordered set of symbols for indexing, and let the compiler figure out the mapping to binary numbers and machine code that's functionally equivalent. The interesting case is when you, as the programmer, want to do arithmetic with indices. Of course, you could have a separate number type for array indices, say. But there really is no way around making its algebraic behaviour isomorphic to 0-based indices, because 1-based arithmetic is hell, and if you do that, it's probably a good idea to use the established names such as "0" or "1" for the established concepts such as "neutral element of addition" or "neutral element of multiplication", in order to avoid confusion.
  - derefr 10y ago
    > ['AB'], no? Or the letters without []? Without. The dyadic arr[range] operator would always return one (unwrapped) element, a bit like how SQL ORMs frequently have a Query#get_one method to match Query#get_all. `letters` was a char[], `pairs` was a short[], so you're grabbing a short by its interval-address (+0 shorts from origin, +1 shorts from origin). (Or, to clarify if you were confused by the not-quite-C pseudocode, by 'AB' I meant the short 0x4142.) > But there really is no way around making its algebraic behaviour isomorphic to 0-based indices Oh, sure, it's "zero-based arithmetic" because we're still fundamentally dealing with offsets (and when you slice the array, you take offsets from the beginning of the slice, etc.) I think it's just better—in some vague human-factors sense—to be forced to mention, in each indexing operation, both where the offset (position of hyperplane separating the element from its previous) and the offset+size (position of hyperplane separating the element from its successor) will land, so that you realize explicitly what two numbers those are in your program, as you write them. Humans—especially beginner programmers—don't intuitively realize that array indexes are offsets. They just want to talk about cardinal-numbered positions, and find themselves unable to, so they guess at a mapping and make mistakes.† This syntax sort of short-circuits that by giving them an indexing operation that doesn't ask them to decide on any cardinal:ordinal mapping at all. It just asks for two numbers that are clearly "offsets of the positions between array elements", rather than offsets (or counts) of elements. But even for experienced programmers who understand that indexing operations are pointer offset math, such an indexing-by-continuous-slicing scheme is potentially still a bit helpful, somewhat like being asked to write out a deductive proof for a hand-wavy argument: it makes you aware of when you've made a leap of logic that has no rule allowing you to make it. Or, in this case, it makes you aware of what element you're actually capturing with your hand-wavy math. > The interesting case is when you, as the programmer, want to do arithmetic with indices. I think—and this I find even weirder to say than my first thought—that it might be good to restrict this "humane" indexing operation from containing compound expressions. Instead of this: foo[(a * 3 + 2)ch .. (a * 3 + 5)ch] ...you'd be forced to write this: offset = a * 3 + 2 foo[(offset)ch .. (offset+1)ch] or maybe the x86 LEA-alike: pos = a * 3 + 2 foo[(pos)ch : 0ch..1ch] This forces the programmer to give a name to the number they're using as the "base" in the indexing operation—which pushes them even further toward noticing when they've borked up the fencepost math. --- † A tangent: "pointers are hard" for beginning programmers because C tries very hard to make array access, and even plain pointer math, "act like" reference-by-cardinal-rank, but then still uses zero-based offsets, munging up the ability to deduce a coherent semantics of pointers as memory-address-valued variables. In C, when you add an (ordinal!) integer to a pointer, it multiplies that integer by the sizeof() the pointer's referent type because it wants you to model the pointer as being an iterator-handle for a collection of things, rather than just being a memory-address-valued variable. It makes sense, for practical reasons, that you can't create a short︎＊-typed variable containing a non-short-stride-aligned memory-address... but that should be a domain error on the result of the addition, not something you're mathematically unable to express.
goatlover 10y ago
This sounds like sophistry. There are no 0 things in the world, it's just an abstract concept. I have 1 car, not 0. If I had a lineup of cars, the first one would be 1, not 0.
- zAy0LfpBZLC8mAC 10y ago
  > There are no 0 things in the world, it's just an abstract concept. So, empty water bottles don't exist? Or do you object to saying "this bottle contains 0 ml of water"? Why? Or do you think that no water bottle is the same thing as a water bottle with no water in it? > I have 1 car, not 0. And what about someone who has no car? Are there no people who don't have cars? Or do you object to saying "this person has zero cars"? Why? Or do you think that no garage is the same as a garage with no car in it? > If I had a lineup of cars, the first one would be 1, not 0. No, it wouldn't. Unless you arbitrarily decided to label it as such. It would be the first. That's an ordinal number. Also, you would have 1 car. That's a cardinal number.
  - goatlover 10y ago
    >> So, empty water bottles don't exist? Or do you object to saying "this bottle contains 0 ml of water"? Why? They exist conceptually, because a water bottle could be empty of anything that fits inside. We say it has 0 ml of water and not coke or sand because we've designated it to be a water bottle, but nature obviously doesn't care what goes in the bottle, as long as it fits. It's just a useful idea we have to say there is zero something to designate a lack of something. But there isn't zero water in nature, anymore than there are zero unicorns, or zero Kings of France. >> And what about someone who has no car? Are there no people who don't have cars? Or do you object to saying "this person has zero cars"? Why? Or do you think that no garage is the same as a garage with no car in it? << Are there no people who don't have dinosaurs or time machines? The things we have zero of are infinite. But you don't actually have zero pink elephants in your backyard. >> No, it wouldn't. Unless you arbitrarily decided to label it as such. It would be the first. That's an ordinal number. Also, you would have 1 car. That's a cardinal number. So if we were to label to cars in increasing numeric order from one end to the other, we would start with 0 instead of 1 at the first car? We don't do that with building levels. You enter on the first floor, go to the elevator, and you push a button for the floor level. The first floor is 1. 0 Would be the basement level.

derefr 10y ago

> Well, nor is there a natural "element one" that exists "at one". Right. I'm on the "no natural mapping" side as well, here, not with the "first = 1" people. Actually, consider for a moment, a programming language that tried to avoid both of these mappings, at least in its programmer-facing syntax (it might compile down to one or the other mapping, but that's an implementation detail.) It might not be so bad! Of course, you wouldn't be able to index arrays by a single ordinal number at all, instead being forced to do speak in terms of intervals: letters = char{'A', 'B', 'C'} letters[0ch .. 1ch] # => ['A'] letters[1ch .. 2ch] # => ['B'] pairs = short{'AB', 'CD', 'EF'} pairs.slice(0sh .. 1sh) # => ['AB'] pairs[0sh .. 1sh] # => 'AB' pairs[0ch .. 1ch] # => ['A'] or a type error, as the language author pleases pairs[0sh .. 2sh] # => argument error pairs.slice(0sh .. 2sh) # => ['AB', 'CD'] Effectively, the single-element index operation would just be a specialization of a slice operation. Both operations would take a mantissa indicating where the "left edge" and "right edge" containing the value you want is in the array's memory space. And you'd be forced to specify explicit units for the "addresses" of the mantissa, even though the language might reject a mantissa of the wrong type. This seems kind of annoying to write. But, I swear, it feels so pleasant to read. Much moreso than any language I've used. It's not hard at all to "keep the logic in my head" when I read the above back.

zAy0LfpBZLC8mAC 10y ago
> pairs[0sh .. 1sh] # => 'AB' ['AB'], no? Or the letters without []? > This seems kind of annoying to write. But, I swear, it feels so pleasant to read. Much moreso than any language I've used. It's not hard at all to "keep the logic in my head" when I read the above back. Well, yeah, but you conveniently left out index arithmetic :-) If it's only about hard-coded indices, it really doesn't matter, IMO, as long as it's consistent, and you could just use any ordered set of symbols for indexing, and let the compiler figure out the mapping to binary numbers and machine code that's functionally equivalent. The interesting case is when you, as the programmer, want to do arithmetic with indices. Of course, you could have a separate number type for array indices, say. But there really is no way around making its algebraic behaviour isomorphic to 0-based indices, because 1-based arithmetic is hell, and if you do that, it's probably a good idea to use the established names such as "0" or "1" for the established concepts such as "neutral element of addition" or "neutral element of multiplication", in order to avoid confusion.
- derefr 10y ago
  > ['AB'], no? Or the letters without []? Without. The dyadic arr[range] operator would always return one (unwrapped) element, a bit like how SQL ORMs frequently have a Query#get_one method to match Query#get_all. `letters` was a char[], `pairs` was a short[], so you're grabbing a short by its interval-address (+0 shorts from origin, +1 shorts from origin). (Or, to clarify if you were confused by the not-quite-C pseudocode, by 'AB' I meant the short 0x4142.) > But there really is no way around making its algebraic behaviour isomorphic to 0-based indices Oh, sure, it's "zero-based arithmetic" because we're still fundamentally dealing with offsets (and when you slice the array, you take offsets from the beginning of the slice, etc.) I think it's just better—in some vague human-factors sense—to be forced to mention, in each indexing operation, both where the offset (position of hyperplane separating the element from its previous) and the offset+size (position of hyperplane separating the element from its successor) will land, so that you realize explicitly what two numbers those are in your program, as you write them. Humans—especially beginner programmers—don't intuitively realize that array indexes are offsets. They just want to talk about cardinal-numbered positions, and find themselves unable to, so they guess at a mapping and make mistakes.† This syntax sort of short-circuits that by giving them an indexing operation that doesn't ask them to decide on any cardinal:ordinal mapping at all. It just asks for two numbers that are clearly "offsets of the positions between array elements", rather than offsets (or counts) of elements. But even for experienced programmers who understand that indexing operations are pointer offset math, such an indexing-by-continuous-slicing scheme is potentially still a bit helpful, somewhat like being asked to write out a deductive proof for a hand-wavy argument: it makes you aware of when you've made a leap of logic that has no rule allowing you to make it. Or, in this case, it makes you aware of what element you're actually capturing with your hand-wavy math. > The interesting case is when you, as the programmer, want to do arithmetic with indices. I think—and this I find even weirder to say than my first thought—that it might be good to restrict this "humane" indexing operation from containing compound expressions. Instead of this: foo[(a * 3 + 2)ch .. (a * 3 + 5)ch] ...you'd be forced to write this: offset = a * 3 + 2 foo[(offset)ch .. (offset+1)ch] or maybe the x86 LEA-alike: pos = a * 3 + 2 foo[(pos)ch : 0ch..1ch] This forces the programmer to give a name to the number they're using as the "base" in the indexing operation—which pushes them even further toward noticing when they've borked up the fencepost math. --- † A tangent: "pointers are hard" for beginning programmers because C tries very hard to make array access, and even plain pointer math, "act like" reference-by-cardinal-rank, but then still uses zero-based offsets, munging up the ability to deduce a coherent semantics of pointers as memory-address-valued variables. In C, when you add an (ordinal!) integer to a pointer, it multiplies that integer by the sizeof() the pointer's referent type because it wants you to model the pointer as being an iterator-handle for a collection of things, rather than just being a memory-address-valued variable. It makes sense, for practical reasons, that you can't create a short︎＊-typed variable containing a non-short-stride-aligned memory-address... but that should be a domain error on the result of the addition, not something you're mathematically unable to express.

goatlover 10y ago

This sounds like sophistry. There are no 0 things in the world, it's just an abstract concept. I have 1 car, not 0. If I had a lineup of cars, the first one would be 1, not 0.

zAy0LfpBZLC8mAC 10y ago
> There are no 0 things in the world, it's just an abstract concept. So, empty water bottles don't exist? Or do you object to saying "this bottle contains 0 ml of water"? Why? Or do you think that no water bottle is the same thing as a water bottle with no water in it? > I have 1 car, not 0. And what about someone who has no car? Are there no people who don't have cars? Or do you object to saying "this person has zero cars"? Why? Or do you think that no garage is the same as a garage with no car in it? > If I had a lineup of cars, the first one would be 1, not 0. No, it wouldn't. Unless you arbitrarily decided to label it as such. It would be the first. That's an ordinal number. Also, you would have 1 car. That's a cardinal number.
- goatlover 10y ago
  >> So, empty water bottles don't exist? Or do you object to saying "this bottle contains 0 ml of water"? Why? They exist conceptually, because a water bottle could be empty of anything that fits inside. We say it has 0 ml of water and not coke or sand because we've designated it to be a water bottle, but nature obviously doesn't care what goes in the bottle, as long as it fits. It's just a useful idea we have to say there is zero something to designate a lack of something. But there isn't zero water in nature, anymore than there are zero unicorns, or zero Kings of France. >> And what about someone who has no car? Are there no people who don't have cars? Or do you object to saying "this person has zero cars"? Why? Or do you think that no garage is the same as a garage with no car in it? << Are there no people who don't have dinosaurs or time machines? The things we have zero of are infinite. But you don't actually have zero pink elephants in your backyard. >> No, it wouldn't. Unless you arbitrarily decided to label it as such. It would be the first. That's an ordinal number. Also, you would have 1 car. That's a cardinal number. So if we were to label to cars in increasing numeric order from one end to the other, we would start with 0 instead of 1 at the first car? We don't do that with building levels. You enter on the first floor, go to the elevator, and you push a button for the floor level. The first floor is 1. 0 Would be the basement level.