Quotes from the Chief Engineer and I

[Ether]

Originally Posted by wireties

How members of an array are stored and accessed is a function of the programming language.

True.

It is not something one should worry or argue about...

Unless you're trying to write efficient linear algebra algorithms. Then you better know whether your language is row major or column major.

[John]

Originally Posted by wireties

How members of an array are stored and accessed is a function of the programming language. It is not something one should worry or argue about since the language will reference and de-reference everything for you. "Row" and "Column" mean nothing to the compiler. Notation has nothing to do with the physical location since memory is laid out so one accesses word-sized elements in sequence. In C and C++ matrices and arrays are really done with pointer arithmetic - google it.

I would disagree that you shouldn't care about how elements of a multidimensional array are stored. Knowledge of the underlying structure in physical memory can make a significant difference in performance of code.

Say you have a matrix that you are representing as a 2D array:
|a b c |
|d e f |
|g h i |

C/C++ structures this in row-major order. This means that the elements are physically arranged sequentially in memory in this order:

a, b, c, d, e, f, g, h, i

Fortran structures this in column-major order. Physically, they are represented as:

a, d, g, b, e, h, c, f, i

Each element is at a particular "address" in memory, which is usually expressed as a hexadecimal number. The elements of the array will be stored sequentially. This means that if element 'a' is stored at 0x1AFF3114, then (in C/C++) element 'b' will be stored at 0x1AFF3115, 'c' at 0x1AFF3116, and so on. In Fortran, 'd' would be at 0x1AFF3115, 'g' at 0x1AFF3116, 'b' at '0x1AFF3117' and so on.

Why does this matter? It is much faster to access elements sequentially than nonsequentially for most physical storage media, sometimes even orders of magnitudes faster. It won't make much of a difference for simple problems with 3x3 or other small matrices, but when dealing with very large matrices with thousands or even millions of elements (which appear in many real engineering problems, for example, the matrices created by FEA software-) it becomes very important.

As a result, it is useful to know what order your programming language lays out its multidimensional arrays in memory, and to write your algorithms to access them in sequential order when possible.

[King Nerd III]

Originally Posted by EricH

Sometimes, the older technology JUST WORKS. And that is what is important in the long run. And it wasn't too long ago that FRC used 37-pin ports (like, last year--and there's still the MXP).

I believe you were looking at some form of serial or parallel port. Probably a many-pin one. VGA, if I'm not mistaken, is another form of serial port. You use serial ports on a near-daily basis if I'm not mistaken--on the Universal Serial Bus (USB).


(Incidentally, I had to boot up a Windows 2000 computer last night. Why, you ask? Because it can run program X. Program X serves a key function in this application. Old technology? Yep. Does it JUST WORK? Yep, unless someone turns it off...)

There's absolutely nothing wrong with the old tech. I have a computer in the basement that runs Windows ME. Does it function correctly? No. Does it turn on and do funny things? Oh absolutely.
The other day I had to go find an IEEE-1200 to preferably USB or VGA or anything that would work with an old printer. Just imagine the look on the guy at RadioShack's face when I asked for one. He asked me what VGA was!

[King Nerd III]

Originally Posted by John

I would disagree that you shouldn't care about how elements of a multidimensional array are stored. Knowledge of the underlying structure in physical memory can make a significant difference in performance of code.

Say you have a matrix that you are representing as a 2D array:
|a b c |
|d e f |
|g h i |

C/C++ structures this in row-major order. This means that the elements are physically arranged sequentially in memory in this order:

a, b, c, d, e, f, g, h, i

Fortran structures this in column-major order. Physically, they are represented as:

a, d, g, b, e, h, c, f, i

Each element is at a particular "address" in memory, which is usually expressed as a hexadecimal number. The elements of the array will be stored sequentially. This means that if element 'a' is stored at 0x1AFF3114, then (in C/C++) element 'b' will be stored at 0x1AFF3115, 'c' at 0x1AFF3116, and so on. In Fortran, 'd' would be at 0x1AFF3115, 'g' at 0x1AFF3116, 'b' at '0x1AFF3117' and so on.

Why does this matter? It is much faster to access elements sequentially than nonsequentially for most physical storage media, sometimes even orders of magnitudes faster. It won't make much of a difference for simple problems with 3x3 or other small matrices, but when dealing with very large matrices with thousands or even millions of elements (which appear in many real engineering problems, for example, the matrices created by FEA software-) it becomes very important.

As a result, it is useful to know what order your programming language lays out its multidimensional arrays in memory, and to write your algorithms to access them in sequential order when possible.

We were arguing over whether or not the computer stores them right next to each other in the matrix like I laid it out. The question on the quiz he gave was "True or false: The first set of brackets in a two dimensional array are columns, the second two are rows" and he put the answer as false. But that isn't really true, even if it is "convention" as he says. Which is why my Chief Engineer Rob Bob the Corncob and I said "no one cares about convention if you comment it enough" because if you comment it out the wazoo they'll know what you mean!

[nighterfighter]

Originally Posted by King Nerd III

Which is why my Chief Engineer Rob Bob the Corncob and I said "no one cares about convention if you comment it enough" because if you comment it out the wazoo they'll know what you mean!

If you have to comment your code out the wazoo, because you are breaking the conventions, you might be doing something wrong...

[King Nerd III]

Originally Posted by nighterfighter

If you have to comment your code out the wazoo, because you are breaking the conventions, you might be doing something wrong...

Oh, obviously. Good code should speak for itself! But we were just pointing out if you do something weird there is always the option to comment it!

[nighterfighter]

Originally Posted by King Nerd III

Oh, obviously. Good code should speak for itself! But we were just pointing out if you do something weird there is always the option to comment it!

Good code *probably* shouldn't break the conventions, unless it's really necessary. And if it is necessary, maybe reconsider your approach.

And commenting isn't really an option, it's more of a requirement, for anything! Think of it like homework that is assigned, but not collected. Sure, you MIGHT be okay not doing it every now and then, but really, you have to do it.

[King Nerd III]

Originally Posted by nighterfighter

Good code *probably* shouldn't break the conventions, unless it's really necessary. And if it is necessary, maybe reconsider your approach.

And commenting isn't really an option, it's more of a requirement, for anything! Think of it like homework that is assigned, but not collected. Sure, you MIGHT be okay not doing it every now and then, but really, you have to do it.

Usually my commenting system is describe variables, say what functions do, and explain certain things. But I went through a phase where I was super commenter, commenting every line! I think I was so tired once I commented a curly bracket. I think it said something like "I don't know why this is here, but I think it ends a function"
Turns out it ended an if statement. Boy was I tired.

[wireties]

Originally Posted by King Nerd III

Usually my commenting system is describe variables, say what functions do, and explain certain things. But I went through a phase where I was super commenter, commenting every line! I think I was so tired once I commented a curly bracket. I think it said something like "I don't know why this is here, but I think it ends a function"
Turns out it ended an if statement. Boy was I tired.

Too many comments is as bad as too few. Use descriptive variables, function names and constants then comment on the algorithm.

[wireties]

Originally Posted by John

I would disagree that you shouldn't care about how elements of a multidimensional array are stored. Knowledge of the underlying structure in physical memory can make a significant difference in performance of code.

I didn't say that you should not care but that you should not argue about it. As Ether commented knowledge of the underlying structure can help with certain kinds of algorithms.

Originally Posted by John

Each element is at a particular "address" in memory, which is usually expressed as a hexadecimal number. The elements of the array will be stored sequentially. This means that if element 'a' is stored at 0x1AFF3114, then (in C/C++) element 'b' will be stored at 0x1AFF3115, 'c' at 0x1AFF3116, and so on. In Fortran, 'd' would be at 0x1AFF3115, 'g' at 0x1AFF3116, 'b' at '0x1AFF3117' and so on.

The addresses increment by the size of the elements, not one at a time unless the elements are characters or unsigned characters in C/C++.

Originally Posted by John

Why does this matter? It is much faster to access elements sequentially than nonsequentially for most physical storage media, sometimes even orders of magnitudes faster. It won't make much of a difference for simple problems with 3x3 or other small matrices, but when dealing with very large matrices with thousands or even millions of elements (which appear in many real engineering problems, for example, the matrices created by FEA software-) it becomes very important.

Storage in memory and storage on "physical storage media" are very different problem domains.

Originally Posted by John

As a result, it is useful to know what order your programming language lays out its multidimensional arrays in memory, and to write your algorithms to access them in sequential order when possible.

Agreed but that is not at all what the OP was talking about.

[King Nerd III]

Originally Posted by wireties

Too many comments is as bad as too few. Use descriptive variables, function names and constants then comment on the algorithm.

I think it really depends on who's going to be reading it. I usually comment as much as I can for teaching examples. But for personal projects I usually write the code and then go back and comment. If what I did doesn't make sense to me I will probably try to rewrite it in a less confusing manner, but if that isn't possible I'll comment it. I try to do this because if it doesn't make sense to me, the author, then it won't make sense to anyone!

[wireties]

Originally Posted by Ether

Unless you're trying to write efficient linear algebra algorithms. Then you better know whether your language is row major or column major.

The OP was talking of basic concepts, not efficient linear algebra algorithms.

[wireties]

Originally Posted by King Nerd III

I think it really depends on who's going to be reading it. I usually comment as much as I can for teaching examples. But for personal projects I usually write the code and then go back and comment. If what I did doesn't make sense to me I will probably try to rewrite it in a less confusing manner, but if that isn't possible I'll comment it. I try to do this because if it doesn't make sense to me, the author, then it won't make sense to anyone!

Express your solution in a diagram or notation of some sort (UML or simple flow diagrams and so on) first. When you start coding, comment first and fill in the code afterwards. If your style is good, the code is readable and the comments explain the algorithm. Little else is really necessary no matter the audience.

[King Nerd III]

Originally Posted by wireties

Express your solution in a diagram or notation of some sort (UML or simple flow diagrams and so on) first. When you start coding, comment first and fill in the code afterwards. If your style is good, the code is readable and the comments explain the algorithm. Little else is really necessary no matter the audience.

I've started to draw out the code before hand, but never thought of the comment first. I think I'll stick to a bunch of comments for examples, though, at least for the first few programs with teaching kids. So far it's been really helpful to be able to say here's a program to look at, the comments should explain what's happening, as usually in the first few weeks we have too many programmers at different levels to teach all at once.

[Spoam]

Since I guess no one else has mentioned it, the only reason OP is "correct" is because in Java "2d" arrays neither row-major nor column-major. Java arrays aren't truly multidimensional (all data contiguously stored in rm or cm order) they're just arrays of arrays.