From where should the index start?
-
I think you are still thinking ONLY about pointers. Suppose I have a listbox and I want to loop through all of its items (elements). I can start a loop like this in VB.NET "For i=0 to ListBox1.Items.Count-1" in Zero based index. Here you can see that there is one more calculation performed (ListBox1.Items.Count-1). If the index is based on One, the loop can be transformed to "For i=1 to ListBox1.Items.Count" which is using one less calculation than Zero based (Actually, this also depends on number of items in the listbox. The loop will need to calculate "Count-1" up to the number of items in the listbox.) In common sense, if there is "nothing" it means Zero and everything starts with One. And programmers are not computers, programming languages can be designed to use starting index as Zero or One or anything most preferred. The compiled code can address anything using the zero based index but this must not be necessary for a programmer/programming language to use the same. More and more programming languages feature are added just to ease programming, otherwise programming can be done directly in Binary.
Using VB, is the problem there :-D. Seriously in C# it'd be:
for (int i = 0, i < ListBox1.Items.Count, i++) {
ListBox1.Items\[i\].property = stuff;}
But also you can use foreach construct:
foreach (Object obj in ListBox1.Items) {
o0bj.property = stuff;
}nikunjbhatt84 wrote:
The compiled code can address anything using the zero based index but this must not be necessary for a programmer/programming language to use the same.
So if you don't like indexes, don't use them.
nikunjbhatt84 wrote:
More and more programming languages feature are added just to ease programming, otherwise programming can be done directly in Binary.
If you'd actually done any machine code, you'd understand the problem with this statement. Higher level languages abstract mnore and more of the machine away, but saying that means you don't need to understand what is happening is stoopid.
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
I disagree that
(p-s)is constant. It does not changemuch, but aspcan be changed, re-assign the array for instance, the pointer cannot be taken as being to a constant place.
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
it is a simple "translation transformation", i.e. a shift of origin: just make the pointer to an array of some type point to the zero-th element of the array, as is done in C-style languages; whether the zero-th element exists or not is immaterial. For a 1-based array of ints at address 0x1000, p would equal 0x0FFC (assuming a 4-byte int). So when allocating an int array in C, say malloc returns 0x1000 and you want that to point to an int array, subtract 4 and store the pointer. The compiler can do that for you; it also can adjust for size differences when you cast one pointer type to another (say casting a char* to an int*). In fact, the malloc case isn't special, just treat void as a type with size zero! :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
-
Erm: what about DataRow selectedRow = selectionEventArgs.SelectedRow If the UI control is data bound to the same list/data source, perhaps. But what if you want to use something in that row as a lookup in another table? OK, granted the packet was a fixed length That's a very big and unreasonable thing to grant ... one would only make that restriction because of language constraints, it's not natural to say a message must be exactly X bytes. Or how about simply reading strings out of a stream? Typically the stream will encode the length first, and then the content you want is stream[headerlength + 1 ... headerlength + length]. You can't map it onto a fixed structure because you don't know how big the content is going to be. I'm not convinced that every usage of Substring can be replaced so easily. After all, most modern languages have Split (or explode or something else that does the same job) for delimiter-separated fields, and people still use Substring a lot. Don't get me wrong, I agree that reducing the number of places indices (or offsets, as they are in most languages) are necessary is a good thing. I'm a big fan of enumeration and array operations. But I don't think a language without the capability of using them would be practical, particularly when you consider trying to interface with existing systems.
BobJanova wrote:
If the UI control is data bound to the same list/data source, perhaps. But what if you want to use something in that row as a lookup in another table?
Well, a better implementation would be:
Person somePerson = selectionEventArgs.Person;
Address personAddress = Person.Address;One of things I would definitely design into a new language is the ability to utilize foreign key and unique key schema information to reference other tables, and that those tables and their fields could be used directly, at compile time, from the schema definition. No ORM required.
BobJanova wrote:
That's a very big and unreasonable thing to grant ... one would only make that restriction because of language constraints, it's not natural to say a message must be exactly X bytes.
Agreed, but I would provide a mechanism in the language to specify variable length fields with the IOC option to determine lengths at runtime.
BobJanova wrote:
Or how about simply reading strings out of a stream? Typically the stream will encode the length first, and then the content you want is stream[headerlength + 1 ... headerlength + length]. You can't map it onto a fixed structure because you don't know how big the content is going to be.
Well, by definition, a stream is read sequentially, so indexing shouldn't be done on the stream itself. And again, I'd create the language so that variable length fields can be defined in a structure into which the stream can be read. I'm just trying to think outside the box, how to eliminate indexing completely through language supported syntax and features. Marc
-
You are missing the step that computers have to do. You placed those apples somewhere no? How is the computer suppose to know where that is? We as humans SEE them. A computer needs the reference. That reference is the what??? Thats right, the 0th index. If you switch it you are now forcing the computer to subract 1 off of every access.
Apples[] myAppleCollection; //In human terms the apple collection sitting right in front of me
By using the "Label" as you put it as the accessor the computer is able to be more efficient and access the first apple because it is the what? Yes, now you are getting it. The 0th index. If I want the second apple I reference it by adding the size of the apple to the collection. You can say this is the 'old' way of doing it, but under the hood it will always do it this way. It has to. If you can not grasp it you should not program.
BobJanova wrote:
The fundamental question is really: do you want a language for the computer, or one for the people who write it? I would prefer to write one for people and let the compiler or interpreter deal with the translation.
This may be the question but your answer is not complete. I want one that allows people to speak easily but at no cost to performance, i.e. the person still needs to understand what is being compiled. You can't get around that. I don't know the details of how a microwave works, but I know not to stick my fork in it. I also know that it will cook my cat (did anyone see that article.. I mean WTF?). If you do not understand the BASE technology of what you are using, you should not use it.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
'First [1st] apple' ... '0th index'. And you're still trying to claim this is a natural approach? The indexer on a collection class is rarely just a memory lookup anyway. In C#/Java, even an array is not just a memory lookup (the implementation is something like
struct array<T> { int l; T* content; }) so even the 'efficiency' argument doesn't add up once you move away from C (the address in memory is the collection's home plus some constant plus the index/offset anyway, you can just adjust the constant for a different index origin on the collection) – even aside from the fact that the performance hit on pure pointer arrays (even in the few cases it actually happens) is negligible to zero anyway. the person still needs to understand what is being compiled. You can't get around that. How much does the average programmer know about Intel/AMD chip opcodes, graphics memory, keyboard drivers and all the other things that their compiled program interacts with? This, honestly, is nonsense. A good language is there to insulate the programmer from needing to know about all the low level crap that the computer is actually doing. I shouldn't have to care what the compiled result of using a List<T> is in order to make decisions about when to use one. -
In almost all programming languages, the index number of arrays, strings and other starts with 0 (Zero). Now suppose, presently you are going to design a new language and forget that any programming language already exist. Then from where would start the index number? Zero or One or something else? Here I am mentioning the reason behind coming this question in my mind. The problem with Zero based index is faced (a little) in the function of finding position of a string inside another string and/or checking existence of one string into another. When the searched string is found at the first character (index=Zero), the function will return Zero and if it is found elsewhere, it will return that Zero based position, and it is NOT found, it may return -1 (depending on the language). { In PHP, however there is a good function which return "false" if the string is not found. } But what if we just want to check weather a string exist in another string or not? There could be another function for this purpose OR you may need to check 2 conditions, one for its index and second for its existence. Now, if the index starts from 1, the function will return 1 if the searched string found at the first character, and this will make easy for checking existence of one string into another, because if the string is not found, the function can return Zero and thus making the IF condition false. So, what do you think about starting number for index in a language if you are going to be the founder of the language?
From Wiki[^] Advantages [Using 0 based Index] One advantage of this convention is in the use of modular arithmetic as implemented in modern computers. Every integer is congruent modulo N to one of the numbers 0, 1, 2, ..., N − 1, where N ≥ 1. Because of this, many arithmetic concepts (such as hash tables) are more elegantly expressed in code when the array starts at zero. A second advantage of zero-based array indexes is that this can improve efficiency under certain circumstances. To illustrate, suppose a is the memory address of the first element of an array, and i is the index of the desired element. In this fairly typical scenario, it is quite common to want the address of the desired element. If the index numbers count from 1, the desired address is computed by this expression: where s is the size of each element. In contrast, if the index numbers count from 0, the expression becomes this: This simpler expression can be more efficient to compute in certain situations. Note, however, that a language wishing to index arrays from 1 could simply adopt the convention that every "array address" is represented by a′ = a – s; that is, rather than using the address of the first array element, such a language would use the address of an imaginary element located immediately before the first actual element. The indexing expression for a 1-based index would be the following: Hence, the efficiency benefit of zero-based indexing is not inherent, but is an artifact of the decision to represent an array by the address of its first element. A third advantage is that ranges are more elegantly expressed as the half-open interval, [0,n), as opposed to the closed interval, [1,n], because empty ranges often occur as input to algorithms (which would be tricky to express with the closed interval without resorting to obtuse conventions like [1,0]). On the other hand, closed intervals occur in mathematics because it is often necessary to calculate the terminating condition (which would be impossible in some cases because the half-open interval isn't always a closed set) which would have a subtraction by 1 everywhere. This situation can lead to some confusion in terminology. In a zero-based indexing scheme, the first element is "element number zero"; likewise, the twelfth element is "element number eleven". Therefore, an analogy f
-
BobJanova wrote:
foreach doesn't require indexing
You don't know what's going on in the background.
Actually, I do, if the thing I'm foreaching over is an IEnumerable in .Net, I know that it really isn't using indexing in many cases (typically it's a linked list type forward reference chaser). But we're talking about languages here, what is going on in the background doesn't matter. (Obviously, go digging far enough and you find the 0 based memory offsets that the processor architecture uses, but that's not a useful thing to talk about in this context.)
-
Walt Fair, Jr. wrote:
I'd make it specifiable so you could decide in each case what made better sense as the base index.
That seems dangerous. If the system is changing its base index how is a maintainer of the system suppose to understand the logic of the one whom developed it in the previous decade? Yes in some cases you want 1 base. The only time I run into this is if some values are making it to the UI. E.g. I have a grid displaying products. Users understand it as 1,1; 1,2; 1,3 but the system understands it as 0,0; 0,1; 0,2 This is exactly why patterns exist for what we display versus the business logic (MVVM, MVC etc.) Your business logic should NOT be using a modified index as it is leads to confusion in other parts of the system (non viewable). I have seen code where the developers tried to be clever and do these things. You end up with a freaking mess. Keep it consistent across the board.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
No, I wouldn't be so stupid as to suggest a blanket system wide change. Note that Basic allows that with its OPTION BASE -- another reason not to use BASIC! I'd let it work on an array by array basis, like Algol. For example, when you declare an array, you specify its base array, with a default of 0. Sort of like A[1:10] or B[-2:15] or C[0:19] which would be equivalent to C[20] or some such syntax. I'd have to give it more thought before actually proposing a specification. Requiring that an array start with a specific index in all cases is just an unnecessary limitation. Why can't I make an array that goes from -22 to +46, if it makes my code more intelligible? Obviously it's possible, since we can map indices in most any language right now or use an associative array in the languages that support that structure. The index limitation, in my opinion, is a throw back to earlier times when compilers were more limited. It sounds like your applications and mine are much different. I find a lot of cases where it's convenient to use arrays with indices that don't start at either 1 or 0 and end up having to map them back to 0 or 1 based indices or use a different data structure. It's no big deal, but the question was asked what I would do, and that's what I would do. Pretty much just like Algol. I just don't care for arbitrary, compiler imposed limitations when the compiler can automatically do the mapping and the programmer/developer could use whatever base is most convenient, clear, and logical for the algorithm description.
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
-
'First [1st] apple' ... '0th index'. And you're still trying to claim this is a natural approach? The indexer on a collection class is rarely just a memory lookup anyway. In C#/Java, even an array is not just a memory lookup (the implementation is something like
struct array<T> { int l; T* content; }) so even the 'efficiency' argument doesn't add up once you move away from C (the address in memory is the collection's home plus some constant plus the index/offset anyway, you can just adjust the constant for a different index origin on the collection) – even aside from the fact that the performance hit on pure pointer arrays (even in the few cases it actually happens) is negligible to zero anyway. the person still needs to understand what is being compiled. You can't get around that. How much does the average programmer know about Intel/AMD chip opcodes, graphics memory, keyboard drivers and all the other things that their compiled program interacts with? This, honestly, is nonsense. A good language is there to insulate the programmer from needing to know about all the low level crap that the computer is actually doing. I shouldn't have to care what the compiled result of using a List<T> is in order to make decisions about when to use one.BobJanova wrote:
so even the 'efficiency' argument doesn't add up once you move away from C (the address in memory is the collection's home plus some constant plus the index/offset anyway, you can just adjust the constant for a different index origin on the collection)
I will agree that this can make the efficiency argument a moot point, however you just make things more complicated for the purpose of simplicity. That doesn't make sence. The reference to the collection IS the first item. yes you can trick it and build a new reference (minus one) and use that and now you have a 1 based array. Hooray! What is the point. My thought (again) is if you can't understand the purpose of it being 0 based you should not be programming. See my post from Wiki (responed to the OP). There are other reasons we use 0 as well. and I have tried giving human comparisons. The idea that the human languange (any language be it English, Japanese, French or even Arabic), is able to speak with implicit definitions. Computer languages do not because math does not. If this reasoning is a mystery to you, you are simply in the wrong field. Sure sure, you can call yourself a programmer. But please for the love of god stay out of my algorithms! Go ahead tweak som UI stuff, but when it comes to the inner workings clearly you should not stir the pot.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
No, I wouldn't be so stupid as to suggest a blanket system wide change. Note that Basic allows that with its OPTION BASE -- another reason not to use BASIC! I'd let it work on an array by array basis, like Algol. For example, when you declare an array, you specify its base array, with a default of 0. Sort of like A[1:10] or B[-2:15] or C[0:19] which would be equivalent to C[20] or some such syntax. I'd have to give it more thought before actually proposing a specification. Requiring that an array start with a specific index in all cases is just an unnecessary limitation. Why can't I make an array that goes from -22 to +46, if it makes my code more intelligible? Obviously it's possible, since we can map indices in most any language right now or use an associative array in the languages that support that structure. The index limitation, in my opinion, is a throw back to earlier times when compilers were more limited. It sounds like your applications and mine are much different. I find a lot of cases where it's convenient to use arrays with indices that don't start at either 1 or 0 and end up having to map them back to 0 or 1 based indices or use a different data structure. It's no big deal, but the question was asked what I would do, and that's what I would do. Pretty much just like Algol. I just don't care for arbitrary, compiler imposed limitations when the compiler can automatically do the mapping and the programmer/developer could use whatever base is most convenient, clear, and logical for the algorithm description.
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
I understand your logic but it seems that it makes it less legible. If you have numerous algorithms all using different index base, the single algorothm may be easier to understand but the integration of them would be difficult (except for the creator). The reason being is 0 is like your starting point. If I I have a need for -22 to +46 I will use a -22 START constant for its offset and an END. Not doing this causes the reader to still do the math because that is also not human language. So you gained nothing it seems, other than your algorithm was easier to write (at first. I say at first because it may need to be adjusted and it is now hard to maintain). If this algorithm passes data to another algorithm that is better suited for 17232 thru 22222 I have to figure out what the heck that means and where they line up. If 0 is my universal starting point they all line up at 0. Back to the 1 index, yes more human readable but many algorithms work happily at 0 based index. Since they will still remain why not keep them as the true base and use offsets for where you need the -22 and +46?
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
This makes no sense. Counting and indexing are completely different things – even the 0 based computing world accepts that a collection of things A, B and C has 3 items, even if it calls them '0', '1' and '2'. The fact is if a person is counting objects they do use 0, it is just omitted. That doesn't mean anything either. A count of 0 is when there are no things to count. But if there are 6 apples, it doesn't matter what indexing system you use, or how many you count at once, there are always 6. What 'indexing' is about it labelling. Ask anyone to label those apples with numbers and everybody (unless they're being deliberately silly) will call them '1', '2', '3', '4', '5' and '6'. Look at things which are labelled in the real world: bases on a rounders/baseball field, quarters or halves in a sports match, aisle numbers in the supermarket. Even in the computing world this is often true; look at the MRU on Excel or Word, it numbers your recently used files from the first (1) up. Well starting the index at 1 for computers is inefficient As I'm discussing with Nagy above, technically true in a small number of cases (many of which are due to language deficiencies regarding array operations in C family languages) but so small as to be irrelevant as a consideration in the modern world. The fundamental question is really: do you want a language for the computer, or one for the people who write it? I would prefer to write one for people and let the compiler or interpreter deal with the translation.
Also I wasn using 'Counting" because that was what was posted in whome I responded to. They used Counting as the argument of why it should be 1,2,3... I pointed out we do count 0, implicityly. Computers count it explicitly upon definition.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
From Wiki[^] Advantages [Using 0 based Index] One advantage of this convention is in the use of modular arithmetic as implemented in modern computers. Every integer is congruent modulo N to one of the numbers 0, 1, 2, ..., N − 1, where N ≥ 1. Because of this, many arithmetic concepts (such as hash tables) are more elegantly expressed in code when the array starts at zero. A second advantage of zero-based array indexes is that this can improve efficiency under certain circumstances. To illustrate, suppose a is the memory address of the first element of an array, and i is the index of the desired element. In this fairly typical scenario, it is quite common to want the address of the desired element. If the index numbers count from 1, the desired address is computed by this expression: where s is the size of each element. In contrast, if the index numbers count from 0, the expression becomes this: This simpler expression can be more efficient to compute in certain situations. Note, however, that a language wishing to index arrays from 1 could simply adopt the convention that every "array address" is represented by a′ = a – s; that is, rather than using the address of the first array element, such a language would use the address of an imaginary element located immediately before the first actual element. The indexing expression for a 1-based index would be the following: Hence, the efficiency benefit of zero-based indexing is not inherent, but is an artifact of the decision to represent an array by the address of its first element. A third advantage is that ranges are more elegantly expressed as the half-open interval, [0,n), as opposed to the closed interval, [1,n], because empty ranges often occur as input to algorithms (which would be tricky to express with the closed interval without resorting to obtuse conventions like [1,0]). On the other hand, closed intervals occur in mathematics because it is often necessary to calculate the terminating condition (which would be impossible in some cases because the half-open interval isn't always a closed set) which would have a subtraction by 1 everywhere. This situation can lead to some confusion in terminology. In a zero-based indexing scheme, the first element is "element number zero"; likewise, the twelfth element is "element number eleven". Therefore, an analogy f
I fully agree with your second advantage, however the third one puzzles me a bit, as you can turn the closed interval [1,n] into a half-open one if you so wish, here is one way of doing that:
(0, n], which is very similar to[0, n). :)Luc Pattyn [My Articles] Nil Volentibus Arduum
-
I fully agree with your second advantage, however the third one puzzles me a bit, as you can turn the closed interval [1,n] into a half-open one if you so wish, here is one way of doing that:
(0, n], which is very similar to[0, n). :)Luc Pattyn [My Articles] Nil Volentibus Arduum
Similar but not the same. Convention is to use [0, n) [Edit.. I put the wrong convention in. HA! The irony!] Yes it can be done. But I think the point of the thirda advantage is purely based on conventions. Which is IMO a critical argument as the argument is by definition stating 1 is more 'conventional' to start your index at. Math proofs don't. Been that way well before computers.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
I understand your logic but it seems that it makes it less legible. If you have numerous algorithms all using different index base, the single algorothm may be easier to understand but the integration of them would be difficult (except for the creator). The reason being is 0 is like your starting point. If I I have a need for -22 to +46 I will use a -22 START constant for its offset and an END. Not doing this causes the reader to still do the math because that is also not human language. So you gained nothing it seems, other than your algorithm was easier to write (at first. I say at first because it may need to be adjusted and it is now hard to maintain). If this algorithm passes data to another algorithm that is better suited for 17232 thru 22222 I have to figure out what the heck that means and where they line up. If 0 is my universal starting point they all line up at 0. Back to the 1 index, yes more human readable but many algorithms work happily at 0 based index. Since they will still remain why not keep them as the true base and use offsets for where you need the -22 and +46?
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
Collin Jasnoch wrote:
I understand your logic but it seems that it makes it less legible.
No, it gives the programmer the option of how to write it in the most legible way.
Collin Jasnoch wrote:
If this algorithm passes data to another algorithm that is better suited for 17232 thru 22222 I have to figure out what the heck that means and where they line up. If 0 is my universal starting point they all line up at 0.
I certainly wouldn't write the compiler to force that!
Collin Jasnoch wrote:
Back to the 1 index, yes more human readable but many algorithms work happily at 0 based index. Since they will still remain why not keep them as the true base and use offsets for where you need the -22 and +46?
I would submit that most all algorithms that use arrays can be written to use an arbitrary base and offset. However, if the compiler can figure out how to do the base and offset, then why should the programmer be forced to do it manually if it is more natural to use a particular base and offset? To me the question boils down to: Do you want to do higher or lower level coding? In my opinion, the compiler should do what ever it can, or I'd go back to coding in C or ASM or something.
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
-
Collin Jasnoch wrote:
I understand your logic but it seems that it makes it less legible.
No, it gives the programmer the option of how to write it in the most legible way.
Collin Jasnoch wrote:
If this algorithm passes data to another algorithm that is better suited for 17232 thru 22222 I have to figure out what the heck that means and where they line up. If 0 is my universal starting point they all line up at 0.
I certainly wouldn't write the compiler to force that!
Collin Jasnoch wrote:
Back to the 1 index, yes more human readable but many algorithms work happily at 0 based index. Since they will still remain why not keep them as the true base and use offsets for where you need the -22 and +46?
I would submit that most all algorithms that use arrays can be written to use an arbitrary base and offset. However, if the compiler can figure out how to do the base and offset, then why should the programmer be forced to do it manually if it is more natural to use a particular base and offset? To me the question boils down to: Do you want to do higher or lower level coding? In my opinion, the compiler should do what ever it can, or I'd go back to coding in C or ASM or something.
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
I think you missed my point. And I did not understand your second remark... Maybe you have not worked on large teams or done any integration with other systems. Say I have 2 algorithms dealing with 2 different (yet coupled) objects. In algorithm 1, the logic makes senc to go from -22 thru +46. And in Algorithm 2 the logic makes sence to go grom 17232 thru 22222. If you define the algorithm as such the integration of these collections and objects is hidden from the developer having to integrate. The develop has no idea that 17232 thru 18345 refers to -22 and that 18345 thru 19246 refers to -21 (obviously I am just throwing out numbers... Thats the point). If however they are sharing the same base talk (0 base index), the developer will clearly see the reasoning of the the one whome wrote the algorithm. Because you would have something like this
const int ALGO1_OFFSET = -22;
const int ALGO1_END_OFFSET = 46;const int ALGO1_TO_ALGO2_MOD = 31;//Making it up again
These values would have real world meaning. They bring the algorithm back to the same starting point. Yes, I understand you can do that manually everytime you look at the algorithms. But the more you have and the more they pass data (which they often do), the worse it gets. For a simple application dealing with one or 2 heavy computation it would be fine. But most applications deal with a lot more than one or 2 algorithms.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
That I honestly would not like at all. I think a bad standard is better than no standard at all. It would be a nightmare if everytime you had to get your hands dirty with some codebase you had to factor in the index base whoever wrote the code decided to use on that given day/project/etc.
-
Indices start from 1. (When did you ever hear someone talking about the 'zeroth' anything, outside of certain computing circles?) Offsets start from 0. The confusion comes because the C family really uses offsets (you can see this in the original C, with the identity a[i] = a + i), but they've always been called 'indices', and that has fed forward into '0 based indexing' (which means subscripts are offsets, really) in its modern siblings. Once you know whether you want to base your language on indices or offsets, the mechanics become obvious. Index: start from 1. ("What's the first/second/etc character of a string?" -> "s[1/2/etc]".) Offsets start from 0. ("What's the character 0/1/etc away from the start?" -> "s[0/1/etc]".) Since I come from the real world and not a computer science course I naturally think in terms of index origin 1 – particularly as I started out programming in APL with that setting. I've written conventional languages enough that I can deal with the offset-based approach but if I was choosing I'd still start at 1.
BobJanova wrote:
outside of certain computing circles?
Actually you need to grow the group significantly. It is math circles which is the basis for all sciences. We use non-zero base index when it comes to physical stuff that exists in the world. Because we imply the 0th element (nothing) by talking about the object. In math and sciences you can not imply this, and must therefore define it. The 0th base index dates back to before computers. It just so happens that computers made it more common knowledge.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
nikunjbhatt84 wrote:
Then from where would start the index number?
I wouldn't allow indexing. At least, I wouldn't expose it to the programming language. Indexing is an archaic left-over from the days for for-next loops and arrays. Even for strings, it's absurd. Folks should take a page from assembly language, where you could map memory into a structure and reference specific elements of the structure with meaningful symbols. This includes handling strings dynamically as well, if people were just to put there minds to it. Marc
You have a very good point. I don't use for loops at all, unless the algorithm requires it. If I am iterating through a collection there is rarely a need to know if I am at 0 or 1. I just care about the order, and that is why we have sorting algorithms out of the box. It is all hidden and makes it very easy. When there is a need your loop takes that into account.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
In almost all programming languages, the index number of arrays, strings and other starts with 0 (Zero). Now suppose, presently you are going to design a new language and forget that any programming language already exist. Then from where would start the index number? Zero or One or something else? Here I am mentioning the reason behind coming this question in my mind. The problem with Zero based index is faced (a little) in the function of finding position of a string inside another string and/or checking existence of one string into another. When the searched string is found at the first character (index=Zero), the function will return Zero and if it is found elsewhere, it will return that Zero based position, and it is NOT found, it may return -1 (depending on the language). { In PHP, however there is a good function which return "false" if the string is not found. } But what if we just want to check weather a string exist in another string or not? There could be another function for this purpose OR you may need to check 2 conditions, one for its index and second for its existence. Now, if the index starts from 1, the function will return 1 if the searched string found at the first character, and this will make easy for checking existence of one string into another, because if the string is not found, the function can return Zero and thus making the IF condition false. So, what do you think about starting number for index in a language if you are going to be the founder of the language?
-
I think you missed my point. And I did not understand your second remark... Maybe you have not worked on large teams or done any integration with other systems. Say I have 2 algorithms dealing with 2 different (yet coupled) objects. In algorithm 1, the logic makes senc to go from -22 thru +46. And in Algorithm 2 the logic makes sence to go grom 17232 thru 22222. If you define the algorithm as such the integration of these collections and objects is hidden from the developer having to integrate. The develop has no idea that 17232 thru 18345 refers to -22 and that 18345 thru 19246 refers to -21 (obviously I am just throwing out numbers... Thats the point). If however they are sharing the same base talk (0 base index), the developer will clearly see the reasoning of the the one whome wrote the algorithm. Because you would have something like this
const int ALGO1_OFFSET = -22;
const int ALGO1_END_OFFSET = 46;const int ALGO1_TO_ALGO2_MOD = 31;//Making it up again
These values would have real world meaning. They bring the algorithm back to the same starting point. Yes, I understand you can do that manually everytime you look at the algorithms. But the more you have and the more they pass data (which they often do), the worse it gets. For a simple application dealing with one or 2 heavy computation it would be fine. But most applications deal with a lot more than one or 2 algorithms.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
So why do you think a compiler couldn't figure that out for you? If we're going to write a compiler and define how we set up indices, I don't see any problem. If your algorithm depends on some constants, that could be changed outside the interface, it doesn't sound like a good algorithm design to me. You're right, I don't work on large teams. But I was always told that encapsulation is a good thing in a team environment. In that case, the algorithms are basically a black box to the rest of the team and it shouldn't matter how they are written internally. For example, I have some simultaneous PDE's to solve with sufficient boundary conditions that my natural (physically meaningful) indices go from 2 to N-2. But when we solve the resulting difference equations, the algorithms always start with index 1 in FORTRAN or index 0 in C. It really doesn't matter much, since those details are hidden. The mathematicians use index = 1 as the base, so sticking with that is much more readable from a numerical methods point of view. In fact when translating the algorithms, I usually get it working with a base 1 array, realizing I'm wasting the memory for the 0 entries. Then I shift the loop indices and increment the values and test everything again, then finally replace the indices and reduce the array size by 1. Doing it that way allows me to implement complicated array manipulations without introducing errors that can't be detected. I see no reason whatsoever that the compiler couldn't do those rote manipulations.
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
-
So why do you think a compiler couldn't figure that out for you? If we're going to write a compiler and define how we set up indices, I don't see any problem. If your algorithm depends on some constants, that could be changed outside the interface, it doesn't sound like a good algorithm design to me. You're right, I don't work on large teams. But I was always told that encapsulation is a good thing in a team environment. In that case, the algorithms are basically a black box to the rest of the team and it shouldn't matter how they are written internally. For example, I have some simultaneous PDE's to solve with sufficient boundary conditions that my natural (physically meaningful) indices go from 2 to N-2. But when we solve the resulting difference equations, the algorithms always start with index 1 in FORTRAN or index 0 in C. It really doesn't matter much, since those details are hidden. The mathematicians use index = 1 as the base, so sticking with that is much more readable from a numerical methods point of view. In fact when translating the algorithms, I usually get it working with a base 1 array, realizing I'm wasting the memory for the 0 entries. Then I shift the loop indices and increment the values and test everything again, then finally replace the indices and reduce the array size by 1. Doing it that way allows me to implement complicated array manipulations without introducing errors that can't be detected. I see no reason whatsoever that the compiler couldn't do those rote manipulations.
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
I am starting to wonder if you are actually reading what I am posting. I never said the compiler can't figure it out. I am saying it shouldn't have to. If you change the base index variably to what one specific algorithm needs integration is a nightmare. Yes Black box is great. BUT you need a consistent API. Imagine if everyone defined their own integers. i.e. One system said its integers can go out to 32 bit and another said 33 and still another said 34. The complexity in integrating the systems would get ridiculous real fast. The same thing goes for your starting index. If I pass you a collection and also have to pass you the starting 'label (as some are refering to index) I have added a complexity to the API. If that alone is not enough, when I string 3 or 3 dozen algorithms together and have to do the integration testing I can't find my data. Encapsulation is important but you still have to test integration of the components. Now if everything miraculously works from the get go and you need not ever touch again (Wake up Alice your dreaming!!!), you are fine. But more likely something will not work during integration testing or when an upgrade occurs. To narrow down which component is failing you will have to follow the data. If you are using different based indecies you will spend an enormous amount of time calculating back to a single base (beit 1 or 0)
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.