Re: Quotes from the Chief Engineer and I
 

True.

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

Re: Quotes from the Chief Engineer and I
 

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.

Re: Quotes from the Chief Engineer and I
 

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!

Re: Quotes from the Chief Engineer and I
 

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!

Re: Quotes from the Chief Engineer and I
 

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

Re: Quotes from the Chief Engineer and I
 

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!

Re: Quotes from the Chief Engineer and I
 

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.

Re: Quotes from the Chief Engineer and I
 

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.

Re: Quotes from the Chief Engineer and I
 

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

Re: Quotes from the Chief Engineer and I
 

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.

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++.

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

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

Re: Quotes from the Chief Engineer and I
 

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!

Re: Quotes from the Chief Engineer and I
 

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

Re: Quotes from the Chief Engineer and I
 

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.

Re: Quotes from the Chief Engineer and I
 

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.

Re: Quotes from the Chief Engineer and I
 

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.