|
Standard & Mutant ? why was Pascal 1 based? anyone know if Delphi is has one based arrays as it might explain some error generated by a test application I have to use?
|
|
|
|
|
glennPattonWork wrote: why was Pascal 1 based?
It's not, neither is Object-Pascal (Delphi). The type-definition of an array would contain the start-index and the end-index. One would use 0, obviously. Dynamic arrays start at 0.
Even BASIC[^] starts at 0.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Let's call them Zeray and Oneray.
|
|
|
|
|
Yes, zero-based and one-based indexing are correct terms.
/ravi
|
|
|
|
|
Maximilien wrote: Is it simply "0-based array" and "1-based array" ?
Yes.
Veni, vidi, vici.
|
|
|
|
|
(0) The one true path to direct epiphanic experience of ineffable ecstasy in emptiness.
(1) The Mother of All Lies, the Deceiver, the Abomination which is the Canker that rots the Soul from within.
bill
Google CEO, Erich Schmidt: "I keep asking for a product called Serendipity. This product would have access to everything ever written or recorded, know everything the user ever worked on and saved to his or her personal hard drive, and know a whole lot about the user's tastes, friends and predilections." 2004, USA Today interview
|
|
|
|
|
Scary stuff Bill 
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
Looks like you are on a journey of self discovery, lad!!!. Keep going and you will discover the mysterious world of Big Endian and Little Endian.
But Beware, Do not rest until you cross the Byte Boundary, Word Boundary and Double Word boundary.
Beyond that you will start to see some faint light from the tower 64.
------------------
- Wizard of O1
|
|
|
|
|
"0-based array" is called an "offset".
"1-based array" could be called "displayable index"
|
|
|
|
|
So you have never been programming Pascal.
As others have pointed out, in Pascal you set both the lower and upper index limits. (Furthermore, indexes may be any scalar type, such as an enumeration value. Enums are NOT names of integers in Pascal, but distinct value domains.)
You probably confused Pascal with Fortran, where array indexes start at 1.
I never understood this fascination for low-level programming in high-level languages! Say, if my table contains data for the years 1960 to 2020, why shouldn't I address (index) the elements with values from 1960 to 2020? Why would I want to define an index base as a separate constant and for every indexing operation subtract this base from the "real" selector value to get to the right index? Calculating addresses is the job of the compiler (and linker), isn't it? That's why we use a high level language compiler!
Having to subtract some base index value is like abandoning struct (/record) mechanisms and decalre the variable as a byte array, field names being offsets into the array. That gives you full control over packing and that kind of things, doesn't it? Great! Well, we do that in assembler, and it works. We can even do it in machine independent assembler, aka "C".
That's what we called C when it appeared, "machine independent assembler". I had my first university level programming education in Pascal, and we saw C as a great step backwards for modelling problem domain concepts. I still do.
Some languages, such as C#, allows you to define the semantics of the [] acessor for your own data types, so that the user of your class may index by values from 1960 to 2020. But you have to do a lot of programming to achieve this, and although I haven't checked, I am quite sure that the compiler isn't smart enough to reduce your accessor function to a simple subtraction of a base index value, the way the Pascal compiler could (not requiring any sort of programming from you). Technology isn't always moving in the forwards direction!
|
|
|
|
|
Member 7989122 wrote: if my table contains data for the years 1960 to 2020,
If you hardcode that, you're doing it wrong.
That case is what hashtables are for.
Also, in C# you can use Array.CreateInstance to make arrays with arbitrary bounds and dimensions.
You might want to start programming in COBOL.
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
"Given the chance I'd rather work smart than work hard." - PHS241
"'Sophisticated platform' typically means 'I have no idea how it works.'"
|
|
|
|
|
Sentenryu wrote: If you hardcode that, you're doing it wrong.
We all (I assume) have laughed at that old Xerox Fortran manual (yes, Xerox did make computers, long time ago), describing how the PARAMETER statement (roughly equivalent to a C #define) could be used to give a symbolic name to a numeric constant, so that you can write PI instead of 3.14159....
This will reduce typing, improve readability, and ease program maintenance, according to the manual, in case the value of PI changes.
Making software general is a good principle, but it can go too far. Say, if you create a highly specialized program for processing some data related to WW2, and your array of events is indexed by years 1939 to 1945, you could ride your principles so that this program can be adapted to changing conditions, such as starting in 1952 and lasting until 1966. Sure, from an academic point of view, you gain a lot of flexibility; you then have a program system that can handle a lot of different WW2s, not only the real one, but any number of counterfactual ones. Which is valuable from an (information technology) academic point of view.
I guess the historican who uses this program to manage information from the factual WW2 could care less about the counterfactual ones. He would rather relate to "1939" than to "FirstYearOfWar" - is it the first year the US was involved? Or the first year of buildup of the military forces? Or the first full year of war, not counting years which were peaceful for the first months?
Super-generality may be destructive both to readability and understanding. And it might complicate code, both for the programmer and compiler, as the generality opens for a large number of exceptional (and non-exceptional) cases possible in the generalized model, but which will never occur in the factual domain that you are modelling.
|
|
|
|
|
Member 7989122 wrote: Say, if you create a highly specialized program for processing some data related to WW2, and your array of events is indexed by years 1939 to 1945,
And what would be your events? sub arrays? I said alread, the structure for this kind of data is a hastable.
You don't have an event every day, so why allocate 2190+ spaces for events?
Most of the time people want to index arrays by any value that doesn't start at zero or one, they're trying to index sparse data. That's a bad idea. We have high level languages, but the computer is still a computer, if we forget how he deals with our instructions, we start to write code that wastes resources and is slow. Also, how would your program deal with a classified file that got public revealing really important events that occured between years 1939 to 1945 but wasn't public? because that never happened before, you know...
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
"Given the chance I'd rather work smart than work hard." - PHS241
"'Sophisticated platform' typically means 'I have no idea how it works.'"
|
|
|
|
|
Hey, I didn't intend this to describe some real-world archive where the information to be handled is defined in a requirements specification... It could be anything. So the array elements could be anything. My only assumption was that the year is the top level discriminator; nothing more. I can imagine a lot of information that is grouped by year!
The reason for using WW2 as an example was to illustrate a case where the start and end years are definite. Appearently, "1960 to 2020" made people want to generalize for the sake of generalizing, so I had to pull something off the top of my head where such generalization would be completely misplaced.
A continuos range of index values isn't "sparse" by not starting from 0 (or 1)! The range 1960 to 2020 is as dense as 0 to 60; it gives no reason to employ hashing. Hashing is generally a bad idea if you need to traverse your data in sequential order in the most efficient way.
Maybe I would be able to relate to your question about classified files etc. if I actually had been working on such a project, but I haven't. My example was only for illustrating the concept of arbitrary index limits. Considering classified information and access control is a completely different question.
|
|
|
|
|
In C you could do this:
int arrayMemory[2020-1960+1];
int *arrayAccess = arrayMemory - 1960;
int i;
for (i=1960; i<=2020; ++i) {
arrayAccess[i] = ...;
}
C is high level assembler.
If indexing something by 1 makes sense for a piece of code you are writing, then just allocate one extra slot of memory and ignore index 0. I have done that with date based logic before.
P.S. The fact that January is considered month 0 in Java still irks me. Whatever happened to encapsulation?
|
|
|
|
|
In Pascal, January would neither be 0 or 1, it would be January.
That's what we got high level languages for.
|
|
|
|
|
Think globally; act locally.
|
|
|
|
|
Fortran can define both lower and upper bounds for arrays. Useful in matrix or tensor math.
|
|
|
|
|
I guess that nowadays it can.
Who was it (it could have been Dijkstra) who during the Fortan-77 design discussions, after reviewing the proposed extensions (some of them rather extensive!) commented: "I have no idea what languages are going to look like in year 2000, but they will be called FORTRAN" ?
I came across Fortran 2003 a while ago. I think he hit the nail on the head.
(Most of my Fortran programming was done in Fortran IV. I don't miss it, except as a source of anecdotes about programming and languages.)
|
|
|
|
|
Fortran 2003 is a mess. It has a few good ideas, but in trying to be everything for everyone, I think it stopped being what it was.
The ability to specify array bounds was present in the WATFOR 77/87 compiler, but I don't know how far back it goes before that. I didn't use it when I was writing code for NASA with f77, so I don't know if that suppored it or not. And since then, I've tried to avoid it. I can write Fortran in any language, and I choose not to.
|
|
|
|
|
Zero based and One based work great for talking about arrays.
To me the real issue is in talking about the indices.
How do you talk about the first element/index?
1 based array - first
0 based array - ?
How do you talk about the second element/index?
1 based array - second
0 based array - ?
When I used to teach C programming, I would just append "-eth" to the ordinal number of the index.
How do you talk about the first element/index?
1 based array - first
0 based array - zero-eth
How do you talk about the second element/index?
1 based array - second
0 based array - one-eth
The students (usually with a pre-dotNet Visual Basic background) picked up on this device quickly.
|
|
|
|
|
in Ada you can have -index values, for example an array with indexes in the range (-5..5) 
David
|
|
|
|
|
|
Do you know when Fortran got the option to specify the lower index limit?
In "classical" Fortran, arrays indexes always started at 1. I am quite sure that didn't change in Fortran-77; I never read the Fortran 90 standard (and Wikipedia doesn't give enough detail).
Nostalgia: The MIX3 instruction on the 16-bit NORD minicomputers, which subtracted 1 from the accumulator and multiplied by 3. It was made especially made for FORTRAN. NORD used a 48 bit floating point format (3 16 bit words). So MIX3 converted from a FORTRAN logical index to the word offset (the machine was word, not byte, adressable) of the floating point array element. The "multiply by 3" part was done by shifting one left and adding, so it was a lot faster than using the general multiply instruction.
|
|
|
|
|
I made use of it in the WATFOR 77/87 compiler in grad school, but I don't know how far back the capabilty goes before that. I don't know about f77, as I didn't need to use that feature in the code I was writing for it.
I'm afraid the NORD minicomp is a bit before my time  But then, integer math is always easier than floating point. I've tried to write a continued fraction integer based representation of floating point arithmetic in C++, but set it aside when I realized that taking the reciprocal was introducing floating point roundoff into the caluclations, and didn't have the patience to figure out how to fix it. I wasn't doing it for size or speed, but to try to eliminate roundoff error, so my efforts had come full circle at that point.
Maybe I should have written it in Fortran instead?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
