Quotes from the Chief Engineer and I

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

[Ether]

Originally Posted by wireties

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

Understood. My post was mostly for the benefit of other readers, particularly high school students, who may have been left with the impression that row-major vs column-major storage never makes a difference.

[techhelpbb]

http://zone.ni.com/reference/en-XX/h...sing_matrices/

Matrices a la LabView.

http://www.mathworks.com/help/matlab...nd-arrays.html

Matrices a la MatLab.

Sometimes arguing about the visual representation of data is basically a course in UI and graphics arts.

You can spend literally your entire life arguing which view is the best one. Like any communications - the 'right' one is that one that manages to deliver the right messsage as fast as possible to the audience to which it was intended.

[Ether]

Originally Posted by techhelpbb

You can spend literally your entire life arguing which view is the best one. Like any communications - the 'right' one is that one that manages to deliver the right messsage as fast as possible to the audience to which it was intended.

Since your post is linked to mine I'll assume that was the intended context, since no other context was given.

I'll try to be clearer:

My post had nothing to do with "arguing which view is the best one". It was simply pointing out that there are domains in which a knowledge of how your programming language stores matrix elements is important.

[techhelpbb]

Originally Posted by Ether

Since your post is linked to mine I'll assume that was the intended context, since no other context was given.

I'll try to be clearer:

My post had nothing to do with "arguing which view is the best one". It was simply pointing out that there are domains in which a knowledge of how your programming language stores matrix elements is important.

It's no problem, I did not intend for my post to be linked to yours at all.
I intended to address the topic in general.

However to go back to your point, if you consider the computers 'view' of the data you are absolutely correct.
Just as it wouldn't make sense to fight little-endian / big-endian it doesn't make any sense to fight the way your language works.

http://en.wikipedia.org/wiki/Endianness

Danny Cohen's "On Holy Wars and a Plea for Peace" published in 1980[7] ends with: "Swift's point is that the difference between breaking the egg at the little-end and breaking it at the big-end is trivial. Therefore, he suggests, that everyone does it in his own preferred way. We agree that the difference between sending eggs with the little- or the big-end first is trivial, but we insist that everyone must do it in the same way, to avoid anarchy. Since the difference is trivial we may choose either way, but a decision must be made."

[SousVide]

Don't forget that OP is in a AP CS course. Java is a tool to teach basic concepts in CS, not just programming, not just a specific language.

It's basically beginning course, in which you are learning the basic building blocks, vocabulary, and conventions. This is how people in the trade communicate with each other.

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

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